Accumulated Delay

[giuseppe.corti]

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 unless the 'unfiltered' mode is explicitly requested.

Regards,
Giuseppe

[ManKeer]

Hi giuseppe,

I have sent you an email on support@lightstreamer.com

the email contains two attachments of the server logs [I have enabled the DEBUG mode for the pump], one for an accumulated delay customer and the other for normal customer.

I hope we can solve this issue ASAP.

Regards

[giuseppe.corti]

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 volume between the two scenarios can only be explained this way.
In the case with delays, we have the same subscription repeated six times:

Line 739: 08-Oct-23 09:43:14,553|INFO |L.requests |SERVER POOLED THREAD 69 |Serving request: control -> LS_reqId=7 &LS_op=add&LS_subId=3&LS_mode=MERGE&LS_group=tad.m arket_status tad.indices.TASI tad.list_prices&LS_schema=prices&LS_snapshot=true& LS_requested_max_frequency=unlimited&LS_session=S9 c405df8ade4eebeMa4dT4314240& on "Lightstreamer HTTP Server" from 10.244.210.1:9819
Line 740: 08-Oct-23 09:43:14,553|INFO |L.requests |SERVER POOLED THREAD 50 |Serving request: control -> LS_reqId=8 &LS_op=add&LS_subId=5&LS_mode=MERGE&LS_group=tad.m arket_status tad.indices.TASI tad.list_prices&LS_schema=prices&LS_snapshot=true& LS_requested_max_frequency=unlimited&LS_session=S9 c405df8ade4eebeMa4dT4314240& on "Lightstreamer HTTP Server" from 10.244.210.1:9819
Line 741: 08-Oct-23 09:43:14,553|INFO |L.requests |SERVER POOLED THREAD 35 |Serving request: control -> LS_reqId=9 &LS_op=add&LS_subId=6&LS_mode=MERGE&LS_group=tad.m arket_status tad.indices.TASI tad.list_prices&LS_schema=prices&LS_snapshot=true& LS_requested_max_frequency=unlimited&LS_session=S9 c405df8ade4eebeMa4dT4314240& on "Lightstreamer HTTP Server" from 10.244.210.1:9819
Line 743: 08-Oct-23 09:43:14,553|INFO |L.requests |SERVER POOLED THREAD 50 |Serving request: control -> LS_reqId=12&LS_op=add&LS_subId=9&LS_mode=MERGE&LS_ group=tad.market_status tad.indices.TASI tad.list_prices&LS_schema=prices&LS_snapshot=true& LS_requested_max_frequency=unlimited&LS_session=S9 c405df8ade4eebeMa4dT4314240& on "Lightstreamer HTTP Server" from 10.244.210.1:9819
Line 746: 08-Oct-23 09:43:14,553|INFO |L.requests |SERVER POOLED THREAD 39 |Serving request: control -> LS_reqId=10&LS_op=add&LS_subId=7&LS_mode=MERGE&LS_ group=tad.market_status tad.indices.TASI tad.list_prices&LS_schema=prices&LS_snapshot=true& LS_requested_max_frequency=unlimited&LS_session=S9 c405df8ade4eebeMa4dT4314240& on "Lightstreamer HTTP Server" from 10.244.210.1:9819
Line 747: 08-Oct-23 09:43:14,553|INFO |L.requests |SERVER POOLED THREAD 71 |Serving request: control -> LS_reqId=11&LS_op=add&LS_subId=8&LS_mode=MERGE&LS_ group=tad.market_status tad.indices.TASI tad.list_prices&LS_schema=prices&LS_snapshot=true& LS_requested_max_frequency=unlimited&LS_session=S9 c405df8ade4eebeMa4dT4314240& on "Lightstreamer HTTP Server" from 10.244.210.1:9819

instead the 'no delay' case only one:

Line 227577: 08-Oct-23 09:44:54,768|INFO |L.requests |SERVER POOLED THREAD 159 |Serving request: control -> LS_reqId=3 &LS_op=add&LS_subId=2&LS_mode=MERGE&LS_group=tad.m arket_status tad.indices.TASI tad.list_prices&LS_schema=prices&LS_snapshot=true& LS_requested_max_frequency=unlimited&LS_session=S5 2e4fe9b5763e735Ma4dT4454753& on "Lightstreamer HTTP Server" from 10.244.210.1:9526

That, for example, causes the number of snapshot images sent immediately after the subscriptions to be around 70 for the 'no delay' case compared to approximately 430.

I cannot know whether this repetition is something normal and perhaps handled during the processing of getItems, or if it simply generates subscriptions for duplicate items. Looking at the logs, I also noticed identical updates twice.

To address this issue, you can take action on the client side by ensuring that your application does not generate duplicate subscriptions, especially during disconnection and reconnection.
Alternatively, you can also handle it on the adapter side by enforcing, in your metadata, the rejection of subscriptions to the same group if a user already has an active subscription for the same.

That being said, The message frequency doesn't seem to be that high, approximately 10 updates per second, but we fear that you performed a grep for the session ID, and this way, many updates sent might have been missed. And so, we are unable to establish with certainty the data repetition rate.
Could you provide us with a snippet, even just 10 seconds, of the complete log within the same interval as the ones you sent us, say around 08-Oct-23 10:02:00?

Regards,
Giuseppe

[ManKeer]

Thanks giuseppe,

I will try to send you the log by tomorrow morning.

Now, how can I detect if this user already subscribed in this group from adapter side?

Regards

[giuseppe.corti]

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 groups for the involved user in the notifyNewTables method and subtracting the groups from the same user as the notifyTablesClose is called, you can use this map to make decisions in the notifyNewTables method to reject any duplicates (by throwing a CreditsException).

- https://sdk.lightstreamer.com/ls-ada...bleInfo%5B%5D)
- https://sdk.lightstreamer.com/ls-ada...bleInfo%5B%5D)

Regards,
Giuseppe