Results 1 to 6 of 6
  1. #1
    Member
    Join Date
    Aug 2010
    Location
    Kuala Lumpur
    Posts
    4

    Error 39 - The session has been forcibly closed by server

    Hi guys,

    Referring to the error code above, have anyone encountered this before? it may seem that whenever this error popped, the connection is dropped immediately and will not attempt to reconnect. Any workaround on this? Please advice.

    Thanks!

  2. #2
    Administrator
    Join Date
    Jul 2006
    Location
    Milan
    Posts
    1,090
    You can forcibly close a session on the server side in several ways, but, obviously, this is not your case.
    Apart from that, the message is supposed not to occur, but it is possible, in principle, that the client issues this message upon unexpected events that cause the session to close.
    We have observed that, a few times. For instance, one case was when an intermediate node was sending unsolicited duplicates of client requests.

    If you can identify the involved session, client and time, you could send us a Server log snippet, centered around the event time, for a check.

    I confirm that when a "session forcibly closed" event is received, the client library does not try to recover.
    It is up to the application to react to the notification and perform a reconnection; for coherency, this should be restricted to code 39.
    (the way depends on the version of the client library you are using; please specify it if you need more details).

  3. #3
    Member
    Join Date
    Aug 2010
    Location
    Kuala Lumpur
    Posts
    4
    Hi Dario,

    I'm currently using lightstreamer moderato 4.0.1 and client library 5.0. Please refer to the snippet attached below, hope that would help.

    27-Jul-12 10:26:08,229|INFO |LightstreamerLogger.requests |SERVER POOLED THREAD 15 |Serving request: /lightstreamer/create_session.js --> LS_phase=9405&LS_cause=timeout&LS_polling=true&LS_ polling_millis=0&LS_idle_millis=0&LS_client_versio n=5.0&LS_adapter_set=#adapterName#& from #IPAddress:Port#
    27-Jul-12 10:26:08,229|INFO |LightstreamerLogger.requests |SERVER POOLED THREAD 19 |Starting new session: Scb565c6604038920T2608229 from 116.235.201.98:56212
    27-Jul-12 10:26:08,291|INFO |LightstreamerLogger.requests |FOR PUMPS PARKING DESTROYER|Closed session Sb9b87b46c6a7243cT2558291 with internal cause code: 39
    27-Jul-12 10:26:08,400|INFO |LightstreamerLogger.requests |FOR PUMPS PARKING DESTROYER|Closed session Sb00d0012cba77f3aT2558400 with internal cause code: 39
    27-Jul-12 10:26:08,525|INFO |LightstreamerLogger.requests |FOR PUMPS PARKING DESTROYER|Closed session S120bea8050f85c8cT2558510 with internal cause code: 39

  4. #4
    Administrator
    Join Date
    Jul 2006
    Location
    Milan
    Posts
    1,090
    I expected a longer log snippet, on the order of a few dozens of seconds, also because it might have been difficult to determine with sharp precision the exact time in which you saw the "error 39" message on the client. Sorry for not being clear about that. You could send the snippet as a private email to support@lightstreamer.com, provided that you can identify at least the client involved and the approximate time at which the client received the message.
    Can you replicate the issue in a test environment?

    About the log shown, we cannot relate the issue with it. Can you confirm that the "error 39" message happened at the exact time of the snippet?
    Note that the "internal cause code: 39" messages that you see in the Server log cannot be directly related with the "error 39" message that you see on the client side.

    With reference to client library 5.0, you can be notified of the "error 39" by implementing the onServerError callback.
    From there, you can force the recovery with a new session by invoking changeStatus appropriately.

  5. #5
    Quote Originally Posted by DarioCrivedlli View Post
    You can forcibly close a session on the server side in several ways, but, obviously, this is not your case.
    Apart from that, the message is supposed not to occur, but it is possible, in principle, that the client issues this message upon unexpected events that cause the session to close.
    We have observed that, a few times. For instance, one case was when an intermediate node was sending unsolicited duplicates of client requests.
    test link
    If you can identify the involved session, client and time, you could send us a Server log snippet, centered around the event time, for a check.

    I confirm that when a "session forcibly closed" event is received, the client library does not try to recover.
    It is up to the application to react to the notification and perform a reconnection; for coherency, this should be restricted to code 39.
    (the way depends on the version of the client library you are using; please specify it if you need more details).
    I'm getting error 39 quite a lot now. I don't want to have to keep forcing recovery. Is there no fix for this?
    Last edited by Oxbridge; March 25th, 2020 at 09:51 AM.

  6. #6
    Administrator
    Join Date
    Jul 2006
    Location
    Milan
    Posts
    1,090
    Please confirm that you refer to a client side notification of error code 39.
    In fact, the Server side notification is different and it is caused by blocks in the communication.

    The client side notification was provided just in case, to catch unexpected responses received from the Server.
    This may include wrong behavior at communication level, something that we cannot fix but only mitigate with some workaround if the problem manifests itself often.
    But this hasn't happened yet and even this forum thread had no follow up.
    Since the underlying process that causes the issue is outside the client control, we cannot perform a reconnection directly from the client library, because this might cause a loop.

    If you see the message often, please send us more information.
    To begin with, we would like to see in the Server log (with factory settings) the behavior of the session closed because of this error.
    Do you have enough information (e.g. exact time, client user name or IP address) to identify the session?
    Otherwise we should try to take a client side log too; which client library version are you using?

 

 

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 03:14 PM.