Long wait on CONNECTED:STREAM-SENSING in firefox

Hello

If my Lighstreamer server stops (i.e. I bounce it), my client goes into a reconnect cycle until the server is available again.

However, when I test with Firefox, after the server comes back up, the connection state becomes CONNECTED:STREAM-SENSING and stays that way for ages (like 2 minutes or so), before eventually doing this:

Quote:

---

DISCONNECTED:WILL-RETRY
CONNECTING
CONNECTED:STREAM-SENSING
CONNECTED:WS-STREAMING

---

Very occasionally it goes to some akin to HTTP-POLLING (cannot remember the exact status).

With Chrome (for example) I go backto CONNECTED:WS-STREAMING instantly.

Any ideas what might be the issue with FF?

Thanks

I think I need to put some more analysis into the circumstances that might lead to this scenario, because it is not consistent.

It seems to happen when the server is down for a longish period of time (like 5 minutes) - where the client is doing several of these:
CONNECTING
DISCONNECTED:WILL-RETRY

When the server comes up, that is when it sticks at CONNECTED:STREAM-SENSING for a long time before either going to CONNECTED:WS-STREAMING or

Quote:

---

CONNECTED:STREAM-SENSING
CONNECTED:HTTP-STREAMING
CONNECTED:HTTP-POLLING

---

Is there any way to upgrade the connection to streaming again once it goes to HTTP-POLLING? I have no idea why it does this, because everything appears to be fine (no looping javascript or anything).

I would like to be able to automate something that will attempt to change back to WS-STREAMING if possible. I have tried disconnecting and reconnecting but that does not work.

Also, I think this needs to be in a different forum. Please move it if required - probably to http://forums.lightstreamer.com/foru...ipt-Client-API

The CONNECTED:STREAM-SENSING should not last more than a few seconds, what do you mean with "long time"?

As per what is happening, probably the client heuristically decided to disable websockets, that's why even if you disconnect-reconnect you can't get a WebSocket connection. A server going down, may cause such behavior if it goes down when the websocket is open but no data was yet exchanged. If you attach a server log (with at least LightstreamerLogger.requests at INFO level) I may be able to verify if the behavior is expected or not.

Quote:

---

Originally Posted by Mone

The CONNECTED:STREAM-SENSING should not last more than a few seconds, what do you mean with "long time"?

---

As I mentioned in the original post, it can last for up to 2 minutes (an approximation - I have not timed it).
I will see if I can replicate it and produce the log for you.

Quote:

---

Originally Posted by Mone

.....that's why even if you disconnect-reconnect you can't get a WebSocket connection

---

I can get a connection OK - it is just that it is an HTTP-Polling connection rather than a WS-STREAMING connection (or is that what you mean?)

OK - here is an example. It does not match my 2 minute estimate (which, since I did not measure it, may be an over exaggeration). I stopped the server and left my client cycle through its attempts at a reconnect for about 5-10 minutes. I then started the server, and got this:

Code:

---

DISCONNECTED:WILL-RETRY
CONNECTING
CONNECTED:STREAM-SENSING  <-----waited for about 30-40 seconds
DISCONNECTED:WILL-RETRY
CONNECTING
CONNECTED:STREAM-SENSING
CONNECTED:WS-STREAMING

---

Here is the log from that time is attached.
It looks like the delay is evident in these information messages:

Code:

---

17-Dec-12 21:11:05,638|INFO |LightstreamerLogger.requests    |SERVER POOLED THREAD 3    |Serving request: /lightstreamer/create_session.js --> LS_phase=675&LS_cause=timeout.11.0&LS_polling=true&LS_polling_millis=0&LS_idle_millis=0&LS_client_version=6.0&LS_adapter_set=RNS&LS_user=NT0X4DMMTI&LS_container=lsc& on "Lightstreamer HTTP Server" from 10.2.0.173:61743
17-Dec-12 21:11:05,871|INFO |LightstreamerLogger.requests    |SERVER POOLED THREAD 6    |Starting new session: Sdec6d3861cdb4654T1105811 on "Lightstreamer HTTP Server" from 10.2.0.173:61743
17-Dec-12 21:11:15,941|INFO |LightstreamerLogger.requests    |FOR PUMPS PARKING DESTROYER|Closed session Sdec6d3861cdb4654T1105811 with internal cause code: 39 (Timeout)
17-Dec-12 21:11:40,280|INFO |LightstreamerLogger.requests    |SERVER POOLED THREAD 4    |Serving request: bind_session -> LS_session=Sdec6d3861cdb4654T1105811&LS_phase=677&LS_cause=loop1&LS_keepalive_millis=5000&LS_container=lsc& on "Lightstreamer HTTP Server" from 10.2.0.173:61793

---

From the log I see that the bind_session request reaches the server 35 seconds later than expected.
Also, since I do not see a control.js?LS_op=force_rebind request looks like the client lib didn't notice any problem as if the browser was completely frozen during that pause. Is the CPU high when that happens?

You may try to add the following pieces of html anbd JS to your page and check if, when the client is blocked on the CONNECTING:STREAM-SENSE status, the counter goes on.

<div id="frozenTestDiv">-</div>

setInterval(function(){<br /> document.getElementById("frozenTestDiv").innerHTML = new Date().getTime();<br /> },500);

nevermind, looks like I was able to reproduce the issue, I'm looking into it right now.

Hi Mone

I included the extra HTML and JavaScript and repeated the problem. It "frozenTestDiv" continued to tick over without any issues. There was no evidence of any high CPU usage either.
However, what I did notice was that the problem appears to be isolated to FF sessions that are running on remote PCs. If I may explain what I mean. I ran the test on two PCs simultaneously:
1) On a PC on the same local network as the Lightstreamer server - this reconnected instantly (no noticeable delay between STREAM-SENSING and WS-STREAMING)
2) On a PC that is remote, but connected to our network via a VPN - this appeared to hang on STREAM-SENSING, before eventually disconnecting and reconnecting. The ticker was fine.

Once connected, the remote PC interacts with Lightstreamer with the same level of performance as those on the local network, so it does not appear to be connected to poor internet speed.

Occasionally the PC on the local network reconnects with HTTP-POLLING instead of WS-STREAMING.



Rgds
Kevin

I'm still looking into it, anyway looks like adding
<br /> yourLightstreamerClientInstance.connectionOptions. setEarlyWSOpenEnabled(false);<br />
prevents the issue from appearing
(more info about the method here: http://www.lightstreamer.com/docs/cl...yWSOpenEnabled )

Mone

Which issue does that prevent? The hanging, or the occasional switch to HTTP-POLLING after a reconnect?

Thanks
Kevin

What we have noticed is that it prevents the hanging.

The occasional switch to HTTP-POLLING is not clear yet and it may be a consequence of the hanging issue.
Anyway, if we remove the problems with websocket opening after Server restart, the switch to HTTP-POLLING will no longer be needed.

Mone is working on an ultimate fix on this.

Hi,

The fix is ready and will make it to the next Lightstreamer release that should be ready later today.