Hi ManKeer,

Delays can have two different origins, either on the server-side or on the client-side.

If the origin is on the server-side, it would affect all clients indiscriminately first and should be relatively easily traceable in the server log.
Could you please send us (support@lightstreamer.com) an excerpt from the lightstreamer.log of a server to which these clients who experienced the issue were connected?
A portion covering approximately one hour of time should be ok.

If the issue is on the client-side, the right way to avoid data queuing is to use the MERGE mode.
In this way, the server does not maintain a data buffer, and for each user subscription, only the most recent image is retained.
However, this mechanism does not exclude the possibility that the client itself, in its TCP buffer, may accumulate some data, assuming it is slow in processing and presenting this data delays can still occur in this case.
In this scenario, it may be useful to reduce the update frequency on the client side, by replacing setRequestedMaxFrequency("unlimited"); with a lower frequency setting. For example, you can request only 1 or 2 updates per second and check if the problem is mitigated.

setRequestedMaxFrequency(1);

or

setRequestedMaxFrequency(2);

On the other hand, requesting the snapshot should not make any difference during the data streaming unless it is an extremely large amount of data that triggers a delay in the application from the beginning. However, I would tend to exclude this.