LS sending EOS before all snapshots arrives

EmersonPardo

Hello,

Our client received a EOS before all snapshot data has arrived. Here's a dump on the client side:

U,4,1,ADD|11|26.99|200|19:40:23|308
U,4,1,|12||14000|19:40:28|16
U,4,1,|13||2600|19:40:34|3
U,4,1,|14||10700|19:40:40|16
U,4,1,|15||300|19:40:41|238
U,4,1,|16||1000|19:40:43|147
U,4,1,|17||12600|19:40:56|16
U,4,1,|18||500||8
U,4,1,|0||5200|19:41:02|16
U,4,1,|1||100|19:39:46|238
U,4,1,|2||400|19:39:49|16
U,4,1,|3||12800|19:39:50|
U,4,1,|4||100|19:39:53|3
U,4,1,|5||8200|19:39:58|16
U,4,1,|6||14900|19:40:02|
U,4,1,|7||700|19:40:03|85
U,4,1,|8||100|19:40:06|308
U,4,1,|9|||19:40:12|27
U,4,1,|10||300|19:40:17|238
EOS,4,1 <------------------------- should this be here??
U,4,1,|19||3600|19:40:56|120
U,4,1,|20||300||16
...

On the server side we assure that ItemEventListener.smartEndOfSnapshot is called only when all snapshots has been sent:

                        sendSnapshot(item, listener, itemHandle);
                        listener.smartEndOfSnapshot(itemHandle);

sendSnapshot just get the items and calls ItemEventListener.smartUpdate:

    for (final HashMap<String, String> linha : linhas) {
                    final HashMap<String, String> upd = new HashMap<>(linha);
                    upd.put(DataProvider.KEY_FIELD, pos.toString());
                    upd.put(DataProvider.COMMAND_FIELD, DataProvider.ADD_COMMAND);
                        
                    listener.smartUpdate(itemHandle, upd, true);
     }

The subscribe mode is COMMAND in our scenario.

Fortunately our client knows how to deal with this but we want to know if it is supposed to work this way.

Thanks.

Giuseppe Corti

Hi Emerson,

I can confirm that the observed behavior is not the one expected.
Please let me ask you for some details that can clarify your scenario:

- Can you confirm that the isSnapshotAvailable returns true for the specific Item?
- Can you confirm that all the smartUpdate and the smartEndOfSnapshot are executed in a tight sequence and all in the same thread?
- Is the client for which you have reported the dump log the one responsible for the first subscription for the Item, and therefore of the snapshot recovery?

If you got same behavior after confirming the first two observations above, please could you provide us with a snippet of the server log reproducing the issue after changing these logger levels (lightstreamer_log_conf.xml):

<logger name="LightstreamerLogger.subscriptions" level="DEBUG"/>
<logger name="LightstreamerLogger.subscriptions.upd" level="DBUG"/>
<logger name="LightstreamerLogger.preprocessor" level="DEBUG"/>

Thank you,
Giuseppe

EmersonPardo

Hello, Giuseeppe.

Yes, I can confirm that the answer to the two first questions is yes.

I cannot confirm the third question but we have this necessity: more than one client can subscribe to the same item at anytime and both have to receive the current snaphot. This third question led me to another: only the first subscriber of an item (should) receive the snapshot from the data-adapter?

Giuseppe Corti

Hi Emerson,

Yes, I confirm that more than one client can subscribe to the same Item and all these will receive the snapshot, upon request, based on the current status of the Item.

The difference is that for the first client the Lightstreamer server must rely on the Data Adapter to retrieve the current status of the Item, and expects one or more updates marked as snapshot and eventually an EOS signal.
For all the subsequent clients, the snapshot will be provided directly by the Lightstreamer server leveraging the current status of the Item maintained in its internal memory.

In other words, the subscribe method of the Data Adapter will be called only once.
The first client subscribing to a specific Item will trigger the call to the subscribe of the Data Adapter. All subsequent subscription requests of clients for the same Item will no trigger any subscribe call. When there will be no more clients subscribing that Item then will be called the unsubscribe method.
After that, an eventual new request for the same Item will cause a new call to subscribe.
Please refer to the schema at page 38 of General Concepts documentation for a concrete scenario of Data Adapter workflow.

Please let us know if you need any further clarifications.

Regards,
Giuseppe