-
March 10th, 2022, 10:45 PM
#1
Connection stalled
Hi support,
I'm receiving these messages:
16:44:31 Connection stalled
16:44:34onFailure(PushServerException e)
16:44:34 com.lightstreamer.ls_client.PushServerException: No data from server
When is it considered stalled? Is there a way to configure that so it won't be considered "stalled" using a certain time?
Thanks
-
March 11th, 2022, 09:39 AM
#2
Hi baalbaki,
A client entered "Stalled" status when no actual data and no keepalive packets arrived within the KeepaliveInterval + StalledTimeout that for factory configuration is 7 seconds.
Maybe that your client has been disconnected for a long time or for whatever reason stuck for several seconds without consuming packets from the network?
By the way you can change the default values of the parameters involved with this APIs:
- keepaliveMillis : https://sdk.lightstreamer.com/ls-javase-client/2.5.2-1107/api/com/lightstreamer/ls_client/ConnectionInfo.html#keepaliveMillis
- probeTimeoutMillis : https://sdk.lightstreamer.com/ls-jav...eTimeoutMillis
These APIs refer to Java Client version before 3.x since I assume you are using such an old version from the code you posted. With later versions the interface has changed quite a lot.
Regards,
Giuseppe
-
March 11th, 2022, 02:29 PM
#3
Great thanks for the help!
-
March 14th, 2022, 05:19 PM
#4
Hi,
I simulate a disconnect by shutting down the lightstreamer server and the client gets these logs when this happen (look bellow). I have several table AbstractHandyTableListener public void onUnsubscrAll() but sometimes they happen way later instead of them happening all when this event happen. How can i force this callback to happen right away and not at random time of my code?
Thanks
12:49:33 PM com.lightstreamer.ls_client.ServerManager waitEvent
SEVERE: Error while listening for data in session S023d29eb241e38dfM126T4642597
12:49:33,279 ERROR ConnectionListener:: onFailure(PushConnException e)
12:49:33,279 INFO AbstractHandyTableListener:: Unsubscribe all from url http://MY_USER@localhost:8081
12:49:33,279 INFO AbstractHandyTableListener:: Unsubscribe all from url http://MY_USER@localhost:8081
12:49:33,279 INFO AbstractHandyTableListener:: Unsubscribe all from url http://MY_USER@localhost:8081
-
March 14th, 2022, 05:53 PM
#5
Hi baalbaki,
This is obviously not the expected behavior. Notifications of onUnsubscrAll events following a client session termination should all be simultaneous.
There is no configuration or code to change this behavior.
What could happen is that the library or the client app gets stuck in some way, leading to delays in handling events.
Do you think something like this is plausible in the cases you mentioned?
Regards,
Giuseppe
-
March 14th, 2022, 07:40 PM
#6
Hi Giuseppe, yes its plausible that the client app gets stuck in some way delaying the handling of those events.
What can happen if in my client if onUnsubscrAll events are not called yet and I connect to another source, then the callbacks are received later:
1-Will I receive values from the old source?
2-Will the new source still be connected properly?
3-If after I received all those callbacks, will we get all the new values from the new source normally?
Thanks
-
March 15th, 2022, 09:29 AM
#7
Hi baalbaki,
It is not very clear to me when you say "if in my client if onUnsubscrAll events are not called yet and I connect to another source":
did you mean that your client received the onFailure event con the connection but not the onUnsubscrAll events?
Or the client does not receive the onFailure event and nor the onUnsubscrAll events.
Indeed in this latter case it could be that the client library does not detect the failure of the connection with the server and would therefore be waiting for the timeouts.
Specifically for your questions:
1. yes there might be the possibility to receive some further onUpdate call.
2. - 3. About the new connection you should rely on the onSessionStarted event after which you can be confident of a fully active client session with the server (regardless of the situation of any old sessions.).
That said, I would like to ask if you have the chance to upgrade the client library to the latest available version.
I am aware that the API has changed radically, and therefore would require some effort in updating the client code; but please note that the version in use is now very old and out of support.
You will also benefit from new features (as the websocket transport), enhancements and bug fixes introduced in the years.
Regards,
Giuseppe
-
March 15th, 2022, 12:37 PM
#8
Updating the client version is not a priority for now, since it's a big task and the basic features we need are there.
Thanks Giuseppe for the help!
Similar Threads
-
By baalbaki in forum Adapter SDKs
Replies: 15
Last Post: April 29th, 2022, 10:04 PM
-
By pratik in forum Client SDKs
Replies: 4
Last Post: June 26th, 2015, 08:56 AM
-
By Matan Poreh in forum Client SDKs
Replies: 1
Last Post: July 11th, 2013, 01:35 PM
-
By Mone in forum Client SDKs
Replies: 2
Last Post: October 17th, 2008, 09:22 AM
-
By dkumarbabu in forum Client SDKs
Replies: 2
Last Post: August 6th, 2008, 09:32 PM
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
All times are GMT +1. The time now is 12:11 AM.
Bookmarks