Search:

Hi ManKeer,

It is strange i have both replied to your emails. Anyway find below my first email:

Hi Mahmoud,

We have analyzed the various information you sent us, and what seems to emerge...

Hi ManKeer,

I have replied to your persoanal mail.

Regards,
Giuseppe

I suppose that was the client buffer involved (few updates already received and not elaborated yet); or maybe is the snapshot of the new client session.
But please clarify if it is a browser...

By leveraging the notifyNewTables and notifyTablesClose methods of the Metadata you can maintain an updated map of users and their respective active subscriptions.
By adding the list of requested...

Hi ManKeer,

Thank you for the logs.
We have analyzed them and it appears evident that for the client experiencing delays, there are duplicate subscriptions.
In fact, the difference in the data...

Hi ManKeer,

Yes, server-side queuing occurs independently for each individual subscription of each user session. But as I mentioned, for MERGE-mode subscriptions, there is no server-side queuing...

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...

It means that the Lightstreamer server receives an update from the Data Adapter for an item name that actually doesn't currently have an active subscription for.

Regards,
Giuseppe

Hi ManKeer,

If you are expecting only one client session, there are two strange things that can be inferred from this request list:

1) It seems that there are two streams of parallel requests...

Hi ManKeer,

If the delays involve only a subset of the clients and then we can exclude a general problem affecting the whole server you should look for the "NIO write queue" and "NIO write queue...