About the content-length:
Continuously rebinding after about one and a half minute
may still be consistent with your setting.
It means 1 MB of update traffic within 90 seconds.
About the session_timeout_millis:
I was mistaken. If a rebind request is affected by a delay,
the first timeout involved is on the client side.
After a reconnection request has not provided an answer in 4 seconds,
the client gives up and retries with a new connection request,
which, however, would open a new session.
Hence, the unexpected replacement of the session
is still consistent with the assumption of a delay
in the client-server communication.
For instance, the brwser might have been overwhelmed by the updates
and might hava not been able to elaborate the Server answer in time.
And, as said, any trailing control request that was also delayed
would have experienced the "sync error".
The exception after the session replacement is the only event
that cannot be explained in terms of overload.
Let us know if the issue happens again.
I am getting a similar case of 'Sync error: Can't find session from '
I am not able to identify if the client or server delay causes the session get closed and create new session.
From this thread, I understood that client server communication delay may cause this issue and can be solved by changing content-length and session_timeout_millis
I have tried both and getting same issue still. I am attaching server log with default configurations and config changes.
Please help me to identify the casue of the issue.
First of all, in the attached file you mention a value of 10 ms for <session_timeout_millis>, but I assume you mean 10 seconds.
Indeed, your client seems to be receiving a lot of data to be elaborated, about 300KB in 15 seconds at least.
This may cause the browser to be overwhelmed. May you please confirm that by direct observation of the client machine?
This would explain the "Sync error", as the page would issue the request of rebinding to the session long time after the previous connection has closed.
Note that you might increase the <session_timeout_millis> and the content-length, but that would just postpone the problem. In fact, in the third case (with the increased content-length), before the whole content-length has been consumed, the client opens a new session in polling mode. This is a recovery mechanism adopted by Lightstreamer web client library when it detects that the update processing is slower than the incoming update rate.
Just in case, the log shows that you have not configured a free license properly.
This causes the Server to work with some annoying limitations.
First of all, in the attached file you mention a value of 10 ms for <session_timeout_millis>, but I assume you mean 10 seconds.
Yes it is 10 seconds. not 10 ms.
Originally Posted by DarioCrivelli
Indeed, your client seems to be receiving a lot of data to be elaborated, about 300KB in 15 seconds at least.
This may cause the browser to be overwhelmed. May you please confirm that by direct observation of the client machine?
This would explain the "Sync error", as the page would issue the request of rebinding to the session long time after the previous connection has closed.
Server is sending approximately 80 KB in first control request
and After adding tables to page, it is expected upto 170 KB of data to be pushed in second request.
In such case, If we use default 5 seconds session_timeout_millis and 300 KB of content-length will be ok?
Originally Posted by DarioCrivelli
Note that you might increase the <session_timeout_millis> and the content-length, but that would just postpone the problem. In fact, in the third case (with the increased content-length), before the whole content-length has been consumed, the client opens a new session in polling mode. This is a recovery mechanism adopted by Lightstreamer web client library when it detects that the update processing is slower than the incoming update rate.
Because as you said, increasing session_timeout_millis and the content-length just postpones the issue.
Bookmarks