Accumulated Delay

[DarioCrivelli]

About the first log sent, we can't find any evidence of delays.
We just compared the timestamps of the log lines which report the new messages received from the Server and the timestamps included in the message payloads.
What we see it that the two timestamps are very similar, with a delay of much less than a second that is steady throughout all the log.

This means that any delays must occur after the reception of the updates.
After the reception, the updates are added to an "event thread" which invokes the application SubscriptionListener. So we have to suspect that the block or delay is inside the application listener.
To ascertain this, we need more log that, unfortunately, is not available in LS SDK library. You should add some logging inside your listener and in particular in the onItemUpdate callback to report each invocation and the data received.

Can you also provide information on your observations?
The log sent spans a time interval from 13:20 to 13:40. Could you report how was the observed delay between 13:20 and 13:40 and the behavior in time (for instance, did it increase with time)?

The second log was not received. I suspect that you sent it to Giuseppe's address rather than LS support address.

Anyway, if the problem is that delays are caused by the machine going into sleep mode, this should be clarified better.
Obviously, during sleep mode the application is not being supported by the system, so we don't provide any guarantee on that state.
Do you mean that, when resuming after the sleep mode, the application shows all the updates occurred during the sleep phase and that it is unable to catch up and keeps sending delayed data?

[DarioCrivelli]

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.

[ManKeer]

Hi Dario,

I have attached two logs today, I have used setReverseHeartbeatInterval but it seems still we face the same issue. I have logged onItemUpdate once an update has been received.

Would you please check?