I got the second log from Giuseppe, but this log is not manageable, as in the 2 hours spanned by the log too many things happen.
If you can spot
- one of the covered session IDs,
- the time of one of the various interruptions (supposedly application sleep phases) that occurred,
- and the behavior observed in terms of delays and their evolution,
then we can look at that case in detail.
Staying on general terms, we see that, after a client application sleep episode, the client reads all the updates that the Server sent during the sleep phase, which may be a lot.
After that, the client session in some cases is closed and replaced by a new session whereas in some other cases it stays alive.
But, in both cases, the client application receives all the delayed updates, which also clutters the application and causes the new updates to be delayed as well.
This seems an unexpected side effect of the way the sleep phase is handled by the system. In practice, the system seems to keep the connections to LS Server active and to keep filling the TCP input buffer regardless that the application is not able to consume.
In this scenario, the client timeout settings that you reported above are not useful.
What we could try is to setup the reverse hearbeats from the Client to the Server.
In this way, when the client goes to sleep, it doesn't send heartbeats and the Server closes the session after a few seconds. This reduces the number of delayed updates that are read when the sleep terminates.
When the sleep terminates, after the pending updates are consumed, the client cannot find the session and eventually opens a new one, restarting with fresh data.
To do this experiment, please invoke
setReverseHeartbeatInterval before opening the session on the client.
For instance, you can set 10000 ms, which is quite low. Note that a low value could cause an increase of the traffic, hence an increased load on the Server, but this is significant only if there are thousands of clients.
