Difference between two adapters

[DarioCrivelli]

The log snippet includes 5 sessions, whereas I understood that two sessions were enough to exploit the issue.
This complicates the analysis. Can you please produce a log with only two sessions?
Then, assuming that it will be short, you can send it to support@lightstreamer.com
Please ensure that the log includes the Server startup and, in particular, the subscription requests by the two clients.

Note that, unless the client explicitly requests all updates, updates not sent are not lost, but just filtered out in order to always send the latest state.
This is possible also when specifying "unlimited" frequency. Only the "unfiltered" setting forces all updates.
Obviously, such filtering is expected only when there is some bottleneck or some race condition.
With these conditions, it is possible that two different clients receive a different number of updates.
Apparently, these conditions don't apply to your case; but perhaps the full log can help to clarify.

[ManKeer]

Hi Dario,

By two sessions, you mean that only two subscriptions [not two clients] are connected to the LS server, Am I right? please confirm...

if the above is correct, I will reproduce the logs again.

BTW, what will happen if I configuered both clients for "unfiltered" subscriptions, how this will affect the performance?

[DarioCrivelli]

Sorry; if my reference to "two sessions" raises doubts, then please disregard it and send what you have available.
What's important is that the subscriptions are included in the log, so that we can better compare subscriptions and updates received.
On the other question I will answer tomorrow.

[DarioCrivelli]

BTW, what will happen if I configured both clients for "unfiltered" subscriptions, how this will affect the performance?

Preventing filtering can have an effect when the overall update flow to a client is so huge (or the client/network so slow) that it is impossible that all available updates are processed by the client.
In this case, some updates have to be filtered out and this requires that some subscription with a huge flow is not "unfiltered".
But other items with a low flow can still be subscribed "unfiltered".
As long as the update flow is manageable, there is no significant performance difference between "unlimited" and "unfiltered".
Only in rare cases of race conditions (like two subsequent updates in short sequence), "unfiltered" prevents possible filtering-out of some update.

Another case in which "unfiltered" makes the difference is when there are licensing restrictions that put an a-priori limit on the update frequency of an item.
But, in this case, this only works if the average update frequency of the item is lower than the license limit.

Note that, for MERGE mode, you can reduce filtering in almost the same way by enlarging the buffer, which by default is 1, through setRequestedBufferSize.

That said, I'm still not sure what of the above applies to your scenario.