Results 1 to 10 of 10
  1. #1
    Power Member
    Join Date
    Nov 2012
    Posts
    182

    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.

  2. #2
    Power Member
    Join Date
    Nov 2012
    Posts
    182
    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.

  3. #3
    Administrator
    Join Date
    Jul 2006
    Location
    Milan
    Posts
    1,090
    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.

  4. #4
    Power Member
    Join Date
    Nov 2012
    Posts
    182
    Quote Originally Posted by DarioCrivelli View Post
    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.

  5. #5
    Power Member
    Join Date
    Nov 2012
    Posts
    182
    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?

  6. #6
    Administrator
    Join Date
    Jul 2006
    Location
    Milan
    Posts
    1,090
    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?

  7. #7
    Power Member
    Join Date
    Nov 2012
    Posts
    182
    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?

  8. #8
    Administrator
    Join Date
    Jul 2006
    Location
    Milan
    Posts
    1,090
    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.

  9. #9
    Power Member
    Join Date
    Jul 2006
    Location
    Cesano Maderno, Italy
    Posts
    784
    Hi,

    touching base just to confirm that everything looks correct.

  10. #10
    Power Member
    Join Date
    Nov 2012
    Posts
    182
    Thanks.............

 

 

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
All times are GMT +1. The time now is 10:45 PM.