-
December 28th, 2012, 05:57 PM
#1
Event/message loss when the Light Streamer connection disconnect/reconnect
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
-
December 31st, 2012, 10:01 AM
#2
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
-
December 31st, 2012, 10:11 PM
#3
-
January 1st, 2013, 01:13 PM
#4
Originally Posted by
snatarajan
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
-
January 2nd, 2013, 02:00 AM
#5
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
-
January 2nd, 2013, 09:30 AM
#6
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.
-
January 4th, 2013, 09:23 AM
#7
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
-
January 9th, 2013, 02:01 AM
#8
Working with network team and we have support from TIBCO too.. I will update once we have some more information.
Can you please let me know the difference between STREAMING and POLLING?
We have noticed sometime application is going to STALLED-->CONNECTING-->STREAMING.
And sometime its going to CONNECTING-->POLLING... after that is not returning to STREAMING again. Its there anyway to go back again to STREAMING?
-
January 9th, 2013, 09:27 AM
#9
Hi,
take a look to the "Lightstreamer and AJAX" section of this document: http://www.lightstreamer.com/docs/Li...r_Paradigm.pdf
The document itself is quite old and partially obsolete but that depiction of differences between polling and streaming is still valid.
You can get back to streaming by re-issuing the changeStatus("STREAMING") but the client may fall back to POLLING again if for some reason it is unable to establish a streaming connection (e.g.: a blocking proxy in the middle) so this is not a suggested approach.
HTH
Tags for this Thread
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 10:36 PM.
Bookmarks