Is there any way to know that user somehow lost connection to LS server in Data Adapter? Now if client is killed/closed etc. it calls unsubscribe or system closes connection so in Data Adapter unsubscirbe method is called. But how to get the same if client lost internet connection?
Hi salat,
First of all note that the subscribe method is only called when the first client subscribes to a certain item while the unsubscribe method is only called when the last client unsubscribes from the same item.
As an example:
Client 1 subscribes to Item A
subscribe A is called on the adapter
Client 2 subscribes to Item A
Client 1 unsubscribes from item A
Client 2 unsubscribes from item A
unsubscribe A is called on the adapter
To track clients subscriptions you need to implement a Metadata Adapter. You can use NotifyNewTables and NotifyTableClose (note that you need to enable WantsTableNotifications for such methods to be called).
Hi Mone,
Thanks for reply.
In my app each client has his own item and there is no possibility for client to subscribe to item that belongs to other client. So subscribe/unsubscribe method is always called on the adapter when client subsribes/unsubscribes.
I have already implemented my own Metadata Adapter and I'm using NotifyNewTables, NotifyTableClose and WantsTableNotifications.
The problem is when connected client loses internet connection - no method is called on any adapter. But when client's internet connection is up again and he is trying to reconnect to Lightstreamer first unsubscribe method from DataAdapter is called. I have changed <subscription_timeout_millis> in config file to 500.
Is there any way to get information in DataAdapter that client is not connected due to internet connection problems?
Hi salat,
The server makes the best effort to detect broken connections, unfortunately sometimes from its point of view the socket looks healthy and thus the session is not closed on the server; as a consequence you don't get the unsubscription call until the server detects the issue.
The client coming back online may help the server detect the broken socket.
In any case sorry but there is no way for the adapter to know that a session was closed due to connectivity issues.
If you want to explain us why you need such details we may be able to suggest an alternative.
HTH
Hi Mone,
For few months I didn't see any problem with this - unscubscribe method was always called. But from few days I've got 5-10 such issues.
I need this beacuse I'm changing state of client in database (online/offline) after calling subscribe/unsubscribe. This is very important information to me - whole application depends on it.
Is there any alternative that I can use?
As already noted by Simone in a previous post, there are cases in which, despite its best efforts, the server is not able to detect instantly a broken connection with a client.
If for your application this is a major issue then we can suggest you, as workaround, to add application heartbeats, from client to server.
So, briefly, you should add, on the client side, the sending (via sendMessage) of messages at regular intervals.
In your Metadata Adapter you should add an implementation of NotifyUserMessage method that receives client messages and checks if from a client it does not receive messages for an interval of time that you feel in your environment sufficient to establish that the connection is broken.
In this case, from your adapter you should force the disconnection of the client. Please refer to this post.
We are indeed considering adding the heartbeat messages, on the client side, in a future release of Lightstreamer.
Thanks for this solution. I will check if it works for me.
As for notice this issue can be reproduced using virtual machines. If client runs on virtual machine and such machine is powered of in LS clien is still visible as connected.
Also, when do you plan to release new version of Lightstreamer with heartbeat messages?
Hi salat,
We were aware of a few cases like yours, but these are special cases and from our experience quite rare.
For example, I tried to replicate the case illustrated by you. I run a client on a virtual machine (Ubuntu on Oracle VM Virtualbox) and when I turn off the virtual machine the Lightstreamer server has detected the disconnection immediately.
For these reasons, it would be useful to further investigate your case to determine whether there is any hitch in your configuration / infrastructure that affect this behavior.
What client technology do you use? If you were using the JavaScript library is the connection via WebSockets? Between the client and the server there are network intermediaries such for example a proxy?
Thank you.
Machine with LightStreamer - Windows Server 2008 (actually 2 machines over load balancer)
Client machines - any Windows system from XP
Client app is written using C++ based on NetworkProtocolTutorial.pdf
But this issue occured also using local machine as LS server and VirtualMachine started using VMWare from the same physical machine as LS server. No intermidiaries were there.
Hi salat,
So you can replicate the issue in two very different scenarios:
1. LS_server <-> Load Balancer <-> Physical machine client
2. LS_server <-> Virtual machine client (on the same box of the server)
This puzzles me a lot, since the latter case is very similar to my test except for the type of virtualizer.
If you can replicate the test it would be appropriate to gather the server log, after setting the logger "LightstreamerLogger.connections" at INFO level. And even more useful would be to cross the log information with a network packet sniffing.
You can also send these info to support.
Thank you.