Lightstreamer DataAdapter initial snapshot

trader-123

Hello,

Surely this is a simple question.

I'm using Lightstreamer-Server/6.0.3 build 1803. I'm having a lot of trouble understanding what the isSnapshotAvailable method for (in the DataAdapter interface).

I've read the documentation and JavaDocs, but still can't make sense of it. Let me put an example:

Client 1 connects to element A, we have isSnapshotAvailable to true, so in the subscribe method, we call listener.update("A", hashMap, true) and then we finish by calling the endOfSnapshot method. All good.

Client 1 has a snapshot of the data for A, and we'll start streaming data to him, like this: listener.update("A", hashMap, false). See that the isSnapshot flag is false now.

Now Client 2 connects to element A. As that element is already subscribed, LightStreamer won't call the subscribe method, but will directly start streaming, and receive the latest values sent to Client A.

So what's the point of the snapshot in the first place? I could just skip the snapshot and send item updates, what's the use case for a snapshot?

Page 38 of http://www.lightstreamer.com/docs/base/General%20Concepts.pdf explains the flow, and as you can see when client 2 connects, he doesn't receive the snapshot, but the latest value.

Can you think of a good reason for using snapshots? Building the initial state can be done by sending updates without the snapshot flag, so... what's the point?

I basically want to understand what's the advantage and benefits of using them, and how they behave with multiple clients connected to the same element.

Thanks a lot.

Giuseppe Corti

Hi trader-123,

Basically the meaning of snapshot flag is to distinguish a hot update received in real-time from a cold information, recovered somewhat from your back-end, already available at the time of subscription.
For all client from the number 2 and on, this information is determined by the Lightstreamer server, that if a client has required the snapshot provides the current image of the Item.
But for the first client subscribing an Item the Lightstreamer server needs the collaboration of the Adapter to determine if the information is hot or not.
Of course, if the client has no interest in this kind of information, you could just skip the snapshot and send regular item updates immediately.

Furthermore please consider that for some subscription modes, the behavior of updates with the snapshot flag set to true is slightly different.
For example, in DISTINCT mode, the Lightstreamer server could wait until DistinctSnapshotLengt snapshot updates (or an endOfSnapshot event) before start to push to the clients.

Please let me know if you need any further clarifications.

Regards,
Giuseppe

trader-123

Hello Giuseppe, merry Christmas!

It's kind of clear. I still have some questions over your answer:

For all client from the number 2 and on, this information is determined by the Lightstreamer server, that if a client has required the snapshot provides the current image of the Item.

Do you mean that for the second client, there will be no call to get the snapshot? Is the isSnapshotAvailable method only called for the first client subscribing to an item?

But for the first client subscribing an Item the Lightstreamer server needs the collaboration of the Adapter to determine if the information is hot or not.

Cool, so for the first client we send the snapshot, and for all new clients, that method won't be called. I get the same as from the last sentence, really :Smile_Ae:

Cheers!

trader-123

Or should we be updating the snapshot periodically for the next client as in this example? https://github.com/Lightstreamer/Lightstreamer-example-Chat-adapter-java/blob/master/src/src_chat/chat_demo/adapters/ChatDataAdapter.java

Giuseppe Corti

Hi trader-123,

I confirm that the isSnapshotAvailable method is only called for the first client subscribing to an item, and that for each subsequent client, there will be no call to get the snapshot.
This is because the Lightstreamer server already knows the snapshot.

Please consider this very simple example: a Data Adapter handling a single Item, let's call it A, with only a field last_price subscribed in MERGE mode.

The first client, C1, subscribes to Item A and requires the snapshot.
The Lightstreamer server knows nothing about of this Item and then to retrieve the current state asks the Data Adapter to provide the current value for last_price.
The Data Adapter retrieves from the back-end, maybe stored in a DB, the current price for Item A, 15.99, and sends an update with the snapshot flag to true.
The Lightstreamer server sends to C1 an update with last_price=15.99 but snapshot flag set to true so as to indicate that it is not a actual real-time update.
The Data Adapter sends to Lightstreamer server all the updates received from the market feed for the last price of Item A, let's say, 16.02, 16.29 and then 16.23.
The Lightstreamer server sends to C1 the updates with last_price=16.02, last_price=16.29, and then last_price=16.23 but snapshot flag set to false so as to indicate that they are actual real-time updates.
Some time later a second client, C2, subscribes to Item A and requires the snapshot.
The Lightstreamer server does not need to retrieve the snapshot from the Data Adapter because it is 16:23 (it knows already).
The Lightstreamer server sends to C2 an update with last_price=16.23 but snapshot flag set to true so as to indicate that it is not a actual real-time update.
The Data Adapter sends to Lightstreamer server a new update received from the market feed for the last price of Item A: 16.34.
The Lightstreamer server sends to C1 and C2 the update with last_price=16.34 with the snapshot flag set to false so as to indicate that it is an actual real-time update.

The clearSnapshot should not be used to update the snapshot, but only to clear all the fields in the case their value has lost its meaning.
For example consider that the market has closed, and you do not want to publish anymore the value 16.34 as last_price.

Regards,
Giuseppe

trader-123

That really makes sense now, thanks!