Internal cause codes & Session callbacks

jonasby1

Is there any documentation on what the internal cause codes seen in the lightstreamer log mean?

I'm following this to see why the below happened and what callback is triggered on the client when LS server destroys a session:

02-Sep-11 08:22:25,320|INFO |LightstreamerLogger.requests |FOR PUMPS PARKING DESTROYER|Closed session S702f5726fd2822bT2156944 with internal cause code: 38

This looks like a some kind of LS session timeout? The circumstance is a browser sitting idle receiving live stock prices for several hours, then the user returns to the browser (whose ASP.net session is still active) and he isn't getting LS updates, which is confusing :Smile_Ab:

Does this do callback onServerDeny, or maybe result in the client attempting a re-subscribe that in our circumstance would result in onServerDeny?

Thanks

Dario Crivelli

We don't document such internal aspects.
Anyway, the Server issues that log line when it detects a connection interruption. Hence, from the Server point of view, the client has detached first and there is no way (and no point) for sending a notification.

I don't understand why the user action causes the connection to be interrupted but the page not to be reloaded. What exactly is done by your code when the user returns to the browser after a long while? Can you confirm that the PushPage object is still active? In such a case, the client application should receive a onStatusChange() or onEngineLost() notification.

ekrutz

Dario, we are seeing several instances of the following in our logs:

20-Jan-12 14:07:52,695|INFO |LightstreamerLogger.requests |FOR PUMPS PARKING DESTROYER|Closed session Se6150bc443e107beT5831853 with internal cause code: 38

This is similar to the issue above. Can you clarify that this means the LS server thinks the client disconnected from it? And therefore, the LS server will stop sending updates to the client.

What are typical root causes when seeing a high number of these?

Dario Crivelli

I confirm that, upon the above kind of closure, the Server finds the socket closed by the client.
So, the Server can no longer send updates to the client and it can only wait for the client to connect again and open a new session.
When the client resubscribes to the same items, the lost updates can still be sent to it as part of the snapshot. The way depends on the subscription mode and other subscription settings.

If you see many 38 closures at the same time, that could be caused by an interruption at network level.
Serious problems on the Server side, leading to repeated "current delay ..." log messages could also cause that.
If you see many subsequent 38 closures for the same client, client side problems are also possible; see this thread, for instance.

faa666

Dario Crivelli I confirm that, upon the above kind of closure, the Server finds the socket closed by the client.
So, the Server can no longer send updates to the client and it can only wait for the client to connect again and open a new session.
When the client resubscribes to the same items, the lost updates can still be sent to it as part of the snapshot. The way depends on the subscription mode and other subscription settings.

If you see many 38 closures at the same time, that could be caused by an interruption at network level.
Serious problems on the Server side, leading to repeated "current delay ..." log messages could also cause that.
If you see many subsequent 38 closures for the same client, client side problems are also possible; see this thread, for instance.

Dario Crivelli

A post here was moved to a new thread