Event/message loss when the Light Streamer connection disconnect/reconnect

[snatarajan]

Hi,

I noticed/found, we have event/message loss when the Light Streamer connection was disconnected and then automatically reconnected in browser. We have a two different connection ids at bottom of browser between initial open browser and after the issue occured.

This happened randomly but when it happened the disconnect/reconnect cycle was quite often. Any events/Messages happened during the disconnect period were lost even after the connection was successful.

Why browser is disconnect and reconnect again? How do we prevent this? Is there is a anyway to set timeout for connection? like don't create the new connections for 7 hours.

How the event/messages are maintained in that time?

Can you please advise how do we proceed further?

Other informations:

I have searched lightstremer forum and found that people are suggesting to extend the session_timeout_millis value in AMS server lightstreamer_conf.xml.

I believe it’s currently set to 5 sec in our AMS server.
<!-- Mandatory. Longest time a disconnected session can be kept active
while waiting for the Client to rebind such session to another
connection. -->
<session_timeout_millis>5000</session_timeout_millis>


Regards
Suresh N

[Mone]

Hi,

Let's split the problem:

1
First we need to understand why the client disconnects, do you have a server log showing both the first and second session?
On what browser(s) does this happen?

2

Why browser is disconnect and reconnect again? How do we prevent this? Is there is a anyway to set timeout for connection? like don't create the new connections for 7 hours.

(Assuming you're using the latest version of the client library) Once the connect method is called the client will always make the best effort to ensure that there is a streaming connection available. As soon as a disconnection occurs the client will try to reconnect to the server. To stop the reconnections you must call the disconnect method.


3
As per what happens to the updates while the client disonnect/reconnects, is probably more a logical problem than a practical one and it depends on many factors:
How long the client remains disconnected
Whenever there are other clients subscribed to same items or not
The Subscription mode
The snapshot configuration

Please take a look to the General Concepts document and let me know if it clears things up: http://www.lightstreamer.com/latest/...20Concepts.pdf

[snatarajan]

Hi,

Thanks for the quick response. Please find the below requested response and other details.

1
First we need to understand why the client disconnects, do you have a server log showing both the first and second session? No. I will try to find one share it you as soon as possible.But i have attached the two browser information image.

Its happens on IE8 browser. I believe it’s happening when there is no activity on the browser. User open the application and left the browser for some time ideally.

2

Why browser is disconnect and reconnect again? How do we prevent this? Is there is a anyway to set timeout for connection? like don't create the new connections for 7 hours.
(Assuming you're using the latest version of the client library) Once the connect method is called the client will always make the best effort to ensure that there is a streaming connection available. As soon as a disconnection occurs the client will try to reconnect to the server. Yes it does. It reconnect successfully with in 2 or 3 sec. but we have loosed all the events in between connect and reconnect.

To stop the reconnections you must call the disconnect method. How do we do this? I don’t understand this. Can you please share some sample on this?


3
As per what happens to the updates while the client disonnect/reconnects, is probably more a logical problem than a practical one and it depends on many factors:
How long the client remains disconnected – I believe it’s probably 2 or 3 sec.
Whenever there are other clients subscribed to same items or not – Yes in many case.
The Subscription mode - DISTINCT
The snapshot configuration - True

And also I here with attached some sample client side code, Version numbers ..etc for your reference.

Please take a look at this and let me know how do we proceed further?

Regards
Suresh N

[kpturner]

To stop the reconnections you must call the disconnect method. How do we do this? I don’t understand this. Can you please share some sample on this?

http://www.lightstreamer.com/docs/cl...tml#disconnect

[snatarajan]

Thanks for the response. I believe the disconnect() operation will completely disconnect the connection to the Lightstreamer server.
Actually, we need to reconnect to server automatically without losing any events/message but currently we are losing when this happens.

I am looking for solution to prevent the event/message loss when reconnection occurs. Please help me on this.

Regards
Suresh

[Mone]

Well,

from a general point of view you can't prevent losing events while disconnected.
Depending on the number of events generated while the client is offline you may enlarge the DISTINCT snapshot length but you'll never be certain that you did not lose any event.

From the code you share I see that you are probably handling seats for booking, am I right? What you need is not "not lose any event" but to have the current status of the seats upon connection/reconnection.
In this case I think that DISTINCT is not the correct subscription mode to use. As you need both newly connected client and disconnected/reconnected clients to receive the current status of the seats you'll be better off with a COMMAND mode subscription (each seat being a key in the item) or MERGE subscription (each seat being an item).

Please check the document I pointed you at (http://www.lightstreamer.com/latest/...20Concepts.pdf), on section 3.1 it explains the subscription modes, let me know if that makes sense to you.

[snatarajan]

Thanks Mone... Yes, we are using this for flight operation...I will look into PDF and get back to you... we have actually used MERGE subscripation mode before DISTINCT.. We had some probleam when client receive group of events at a time.. The DISTINCT is helped us on this...
I had spent some more time on this and found,
The onStatusChange() callback method its getting called when this issue occurred. The browser status is automatically changed to STALLED and then CONNECTING and finally again back to STREAMING with new connection id.
I would like to have your thought on this.Thanks

[Mone]

The STALLED status is entered if no data is received for a certain amount of time (see http://www.lightstreamer.com/distros...eoutForStalled and http://www.lightstreamer.com/distros...utForReconnect )

This may happen if the connection is broken for some reason (e.g.: the computer entering a sleep status). On newer versions of the library we changed the transport used on IE8 and are able to detect such broken connections earlier.
In your case you can only change the above timeouts to reduce the disconnected time.

You may monitor the application to see if you can find a pattern that leads to the broken connection (e.g.: connection is broken when user clicks on a button) we may try to find a work-around.
On the other hand note that a broken connection is always possible, that's why the library reconnects to the server as soon as it detects one.

[snatarajan]

Thanks Mone... We will always send heart beat data to client every 2 sec... So am not sure about what you mean by no data. In my application its happening when on pick time of data flow.. I will check and share more details on this...

I am trying to use the above timeout in my app but am not able to find any sample piece of code.. Can you please share some code to configure these timeouts?

I am not quite sure how to get Policy object to set this configurations.

I tried like below, its always coming as undefined...

var thisPage = this.@com.delta.acs.snapp.gates.web.client.lightst reamer.setup.LSGWTPushPage:age;
thisPage.policy.setTimeoutForStalled()...

thisPage.policy - this is coming as undefined..

Here is the pattern i observed till now,

"This may happen if the connection is broken for some reason (e.g.: the computer entering a sleep status). On newer versions of the library we changed the transport used on IE8 and are able to detect such broken connections earlier.

You may monitor the application to see if you can find a pattern that leads to the broken connection (e.g.: connection is broken when user clicks on a button) we may try to find a work-around.
On the other hand note that a broken connection is always possible, that's why the library reconnects to the server as soon as it detects one."

The connection is broken mostly happening when we don't user is not doing on the browser(Example: Open a application and navigate to one screen after that working something else in other IE8 browsers or left the application browser idly for some time.) Note: We will be always getting some events/messages.
Let me know if you think any workaround for this.

Regards
Suresh N

[Mone]

Thanks Mone... We will always send heart beat data to client every 2 sec... So am not sure about what you mean by no data. In my application its happening when on pick time of data flow.. I will check and share more details on this...

I mean that data does arrive not from some reasone outside our or your control

I tried like below, its always coming as undefined...

With reference to your LSGWTPushPage file, the policy property is a property of engine, not of thisPage
Let me stress that this will not prevent disconnection, may only speed up the detection of the case.

The connection is broken mostly happening when we don't user is not doing on the browser(Example: Open a application and navigate to one screen after that working something else in other IE8 browsers or left the application browser idly for some time.) Note: We will be always getting some events/messages.
Let me know if you think any workaround for this.

So we need to try and understand where/why the connection is broken.
I would start taking a packet sniffing on the client, is it possible for you to collect it?
It would be useful to compare at least a couple of cases