![sp_Feed](https://forum.prosysopc.com/wp-content/sp-resources/forum-themes/default/images/sp_Feed.png)
![sp_TopicIcon](https://forum.prosysopc.com/wp-content/sp-resources/forum-themes/default/images/sp_TopicIcon.png)
17:20, EEST
![Avatar](https://forum.prosysopc.com/wp-content/sp-resources/forum-avatars/defaults/userdefault.png)
February 21, 2014
![sp_UserOfflineSmall](https://forum.prosysopc.com/wp-content/sp-resources/forum-themes/default/images/sp_UserOfflineSmall.png)
Good afternoon,
I am experiencing some unexpected behavior of an uaClient. The client has a serverStatusListener added to it, which, after making the connection, properly updates the serverState to “RUNNING” (and the ServerStatus accordingly). After calling uaClient.disconnect(), the serverStatus/state are not updating – they continue to show the RUNNING state.
Shouldn’t the serverState/serverStatus return something like “UNKNOWN”?
SDK version is 5.1.0
Thanks for your insights.
Hans-Uwe
13:59, EEST
![Avatar](https://forum.prosysopc.com/wp-content/sp-resources/forum-avatars/defaults/moderatordefault.png)
April 3, 2012
![sp_UserOfflineSmall](https://forum.prosysopc.com/wp-content/sp-resources/forum-themes/default/images/sp_UserOfflineSmall.png)
Hi,
The design is old (10+ years), but in my personal opinion it is also sort of wrong that we use the com.prosysopc.ua.stack.core.ServerState in the first place for a “client-side status”. That ServerState comes from https://reference.opcfoundation.org/Core/Part5/v105/docs/12.6, but each of the values are a “valid status” for the server (and in theory could be Read after connecting). Or well it is a merge of both: the ‘Running’ part is “server-side”, but ‘CommunicationFault’ in the case of a connection break is “client-side”.
UaClient.getServerStatus() throws when not connected.
UaClient.getServerState() returns ServerState.Unknown when not connected i.e. when we do not have a status/state (before .connect, after .disconnect; is CommunicationFault if connection break happens).
So I understand the confusion that the ‘Unknown’ doesn’t come from ServerStatusListener.onStateChange as well. I would say the ServerStatusListener sort of … only have had a meaning between UaClient.connect and disconnect and ‘Unknown’ just has been used instead of ‘null’ when there isn’t anything better.
From the “technical side”, the PublishTask Thread of UaClient is responsible for checking the status periodically and is also the one that calls the ServerStatusListener. The PublishTask thread also handles the automatic reconnects. Thus, it must be the first thing to internally be terminated before the disconnect can continue, otherwise it can accidentally reconnect the to-be-disconnected-connection. Then later as part of the .disconnect, the previously status is cleared, effectively causing a side-effect getServerState() to once again return ‘Unknown’.
I see this could be implemented either as part of the “clearing status” (above), that would mean whatever thread calling .disconnect would be the one to call the listener. Or the PublishTask thread as it’s last action could call the listener (though at this point the connection would still be up).
Though, I do see some danger that there could be listener impls out there that do something if the state is not Running, which would cause the .disconnect to also trigger that behaviour. Thus, somewhat unclear should we change anything. I’ll discuss with others, might take some time.
P.S.
While not maybe optimal, you could call the listener yourself after .disconnect returns.
15:59, EEST
![Avatar](https://forum.prosysopc.com/wp-content/sp-resources/forum-avatars/defaults/userdefault.png)
February 21, 2014
![sp_UserOfflineSmall](https://forum.prosysopc.com/wp-content/sp-resources/forum-themes/default/images/sp_UserOfflineSmall.png)
Thanks for your reply.
I agree with your thoughts about implementing the ServerStatusListener.
As you suggested in your P.S. I implemented a periodic background read of the ServerStatus and return a kind of Bad_ServerDisconnected in case the read call throws or has an otherwise bad status code. This works quite well, in particular, because I can control when the “polling” starts and ends (there is no need to issue read ServerState call when the client is knowingly disconnected). Plus there is no subscription to take care of.
Many thanks,
Hans-Uwe
Most Users Ever Online: 518
Currently Online:
20 Guest(s)
Currently Browsing this Page:
1 Guest(s)
Top Posters:
Heikki Tahvanainen: 402
hbrackel: 142
pramanj: 86
rocket science: 85
Francesco Zambon: 83
Ibrahim: 78
Sabari: 62
kapsl: 57
gjevremovic: 49
Xavier: 43
Member Stats:
Guest Posters: 0
Members: 724
Moderators: 7
Admins: 1
Forum Stats:
Groups: 3
Forums: 15
Topics: 1495
Posts: 6352
Newest Members:
armandovarley, dole, rustyhammer, braydenaquino6, blaircleveland0, maribelkeeler7, Nicky, rickymeade2, niamhtoussaint0, adamq0505309Moderators: Jouni Aro: 1017, Pyry: 1, Petri: 0, Bjarne Boström: 1003, Jimmy Ni: 26, Matti Siponen: 337, Lusetti: 0
Administrators: admin: 1