Degrade from STREAMING to POLLING

riwang

Hi,

I noticed my Javascript web app degraded from STREAMING to POLLING for pushing server data while running. In FireBug, it was a long running request to control.html. But suddenly, as if triggered by something which was unknown to me, there were one request for bind_session.js every second. I understood this was polling due to the fact that Moderato limits one push per second.

What I don't understand is why this degrade happened. What could have caused it?

In my Javascript code, I tried to re-connect to use STREAMING as soon as I detect the POLLING occurs. Is this a recommended practice? Below is my code snippet:

onStatusChange = function(newStatus)
{
    if(newStatus == 'POLLING')
    {
            globalLSEngine.changeStatus('STREAMING');
    }
};

Thanks a lot.

Richard

Dario Crivelli

The client library can degrade automatically to POLLING because of the "Stream-sense" feature or because of an unresponsive client machine.
In the first case, streaming is not supported by the environment; in the second case, streaming causes continuously increasing processing delays.
In both cases, switching back to streaming would probably lead to a new degradation.

Note that the polling frequency is governed by the setPollingIntervaland setIdleTimeout settings.
If a single item is continuously sending updates, which are limited by Moderato edition to one per second, and polling settings are at their defaults, then you will see one poll per second.

riwang

Hi DarioCrivelli,

Thanks for your prompt reply. Here is my follow-up question:

I noticed the LightStreamer connection was disconnected and then automatically reconnected in my web app. This happened occasionally but when it happened the disconnect/reconnect cycle was quite often, sometimes once or twice per minute. Any LS server events happened during the disconnect period were lost even after the LS connection was re-connected.

Can you please advise what could cause the frequent LS connection disconnect/reconnect? Also, what should be done when this problem occurs?

Richard

Mone

hi,

if you're talking about a client that degraded to polling due to an overload on the client machine, it could happen that if the machine is still in difficulties the LS client retards so much that its session expires on the server while the client is preparing for the next poll.
You know that you're in this situation if on the server log you see "Synch error" messages.
You can extend the session timeout changing the <session_timeout_millis> element inside the Lightstreamer_conf.xml configuration file.

Another reason for disconnection/reconnection could be a delay in the response from the server (e.g.: problems on the network) but as per your previous post this should not be your problem.

riwang

Hi Mone,

We had a Javascript bug that used to keep the browser frozen for 10 seconds or even longer when it does a long blocking calculation. I guess when the Javascript thread was busy doing this long processing, there is no chance for the LS Javascript client to talk to LS server.

Could this cause the degradation from STREAMING to POLLING or the disconnect? Can you please explain how the JS client/server decides to disconnect?

Fortunately I found the bug and fixed it. Now our app won't go into a 10 seconds loop any more.

Thanks,
Richard

Mone

yes, as javascript is mono-thread, blocking the browser in a long execution blocks also the communication with the server and so can cause the coonection to be reinitialized in POLLING.

The client library passes from STREAMING to POLLING in two cases:

the STREAMING connection can't be initialized (ie after opening the connection no data is received before a certain timeout).
see also setBufferedStreamingHandled
there is a heavy load on the machine and the client tries to degradate to POLLING in the hope to diminish such load
see setSlowingEnabled

HTH

riwang

Hi Mone,

That explains the degradation from STREAMING to POLLING. Thanks.

But I'd still like to understand how the connection disconnect/reconnect happens when javascript enters a long running execution block. And how changing <session_timeout-millis> could help mitigate this issue. Can you please advise?

Thanks,
Richard

Alessandro Alinone

Hi Richard,

If the client code cannot consume the heartbeats sent over the stream connections, it will go into STALLED state, and after a while while disconnect and automatically go into CONNECTING state (trying to reconnect).

You can control these timeouts through the setTimeoutForStalledand setTimeoutForReconnect methods.

riwang

Hi Alessandro,

Thanks for the info. That's very helpful.

I'm curious how <session_timeout_millis> comes into play with disconnect/reconnect. Does the default value of 5 seconds mean that the connection disconnects after 5 seconds of no heartbeat? Can you please explain?

Richard

Alessandro Alinone

The <session_timeout_millis> is unrelated to disconnections and reconnections. It's used when the configured content-length is exhausted, in order to wait for a rebind connection. The only benefit the <session_timeout_millis> provides after a disconnection is to keep the items subscribed toward the Data Adapter for a while, optimizing the next reconnection phase.