control.js synch error

I hope you can help me understand what is causing this problem in Firefox.

I have a simple log in page with a Lightstreamer listener on it. If I navigate away from the page, then return to it, everything is fine. If I navigate away again the client freezes for several seconds. Eventually I can see in the console a call to lightstreamer/control.js where the request is

Code:

---

LS_cause    api
LS_op        destroy
LS_session  blah
LS_unique    5

---

and the response is

Code:

---

window.LS_lastError = {}; window.LS_lastError[1] = "sync error";

---

but I cannot fathom out what is causing it. I am not knowingly doing anything with the connection itself during page navigation.

For the sake of clarity, when I say "navigate away", what actually happens is an xmlhttprequest fires off and replaces some elements of the dom with the response. The "freeze" also seems unconnected to anything Lightstreamer is doing because it still does it when I comment out the code that starts the listener. So really I am just after an understanding of the sync error and if it is something to be concerned about.

The reported request for control.js, with LS_op=destroy, can be made by the Client Library anytime a session gets closed.
The purpose is to make sure that the session is also closed on the server side, because there may be intermediate nodes in the path to the Server that keep their socket open.
So, the request is most of the time redundant and it may end up in a "sync error", which is not an error indeed.

If I understand well, in the described situation it is expect that some session closes.

On the other hand, the LS_session=blah parameter would be strange; I assume "blah" is your own placeholder.

Quote:

---

Originally Posted by DarioCrivelli

The reported request for control.js, with LS_op=destroy, can be made by the Client Library anytime a session gets closed.
The purpose is to make sure that the session is also closed on the server side, because there may be intermediate nodes in the path to the Server that keep their socket open.
So, the request is most of the time redundant and it may end up in a "sync error", which is not an error indeed.

If I understand well, in the described situation it is expect that some session closes.

On the other hand, the LS_session=blah parameter would be strange; I assume "blah" is your own placeholder.

---

Ignore the "blah" :) That is just me replacing the real session with something meaningless. It normally says something like Sf89215ee622fba6fT0508444

I am wondering why the session is being closed. Does this imply that I am closing something somewhere without actually realising it? As far as my code is concerned, nothing is being closed from a lightstreamer perspective unless I have a bug of course.

I lie like a cheap watch! :)

I have found a potential example were a connect is attempted before a previous disconnect is completed. Could that be the cause?

In library version 6 (where connect and disconnect are available) the API invocations are executed asynchronously, but anyway they are serialized.
A disconnect is instantaneous from the client point of view, though the closure on the server side, obviously, will occur after a delay (usually, short).

If we are looking for the reason for a disconnection, an invocation of disconnect is a good reason, regardless of the context in which it occurs.
A freezing on the client side could also account for a disconnection, in case it prevents the client from receiving anything from the Server for many seconds.

But I'm not sure the above addresses your question; may you please restate it from scratch?

Yes. My client was freezing, and I was blaming it on the this synch error - but the two are unconnected. I think the sync error is occurring because I am issuing a disconnect to a lightstreamer connection followed instantly by a connect. If I wait until the listener tells me that the server has disconnected before connecting again it seems to be OK. Would this be correct?

As the request with LS_op=destroy is part of the internal communication protocol, in principle, you may expect that the JavaScript Client Library will issue that request or not, depending on minor changes in your application code, as in your case.

As said, the fact that a request with LS_op=destroy causes a "sync error" is also to be expected in many cases and it is not an issue.
So, this "sync error" should be considered as a low-level error which is not an error at application-level.

I will check with my colleagues if the behavior you have observed is perfectly consistent with the library implementation.

Hi,

touching base just to confirm that everything looks correct.

Thanks.............