PradeepChahal
On sending the multiple snapshot(true) event for same item, LS throwing warning message "Unexpected snapshot event".
In our architecture we can get snapshot (multiple time) while we are getting update for particular item.
Why LS show "Unexpected snapshot event" while we return always true for isSnapshotAvailable() function.
Dario Crivelli
By snapshot we mean one or multiple update events
that don't represent real-time updates
but rather the state of the item at time of subscription.
Hence, in response to a call to subscribe(),
snapshot events can only precede real-time events,
otherwise, they are unexpected to the Server.
Note that if you returned false from isSnapshotAvailable()
even the initial snapshot events would be unexpected.
Moreover, in case your item is subscribed to in MERGE mode,
the snapshot can only be made of a single event.
If your feeds, while providing real-time updates,
sometimes sends unsolicited snapshot information
which is just a redundant resume of the item state,
then you can ignore them and not forward them to Lightstreamer.
In case your item is subscribed to in MERGE mode,
you could also forward the resuming events as normal updates,
by setting the isSnapshot flag as false.
PradeepChahal
Thank you Dario,
As it is taking redundant snapshot as an update this is fine with us.
Is there a way to configure LS so that it don't show unexpected snapshot event on output console while keeping the same behavior.
Regards,
Pradeep
Dario Crivelli
This is what I meant by
you could also forward the resuming events as normal updates, by setting the isSnapshotflag as false
.
The
isSnapshotflag is the last parameter to
update or
smartUpdate.
This does not refer to the first, "true" snapshot event.
PradeepChahal
Hello Dario,
Thank you for replying.
I understood it very well.
It is costly for us to check every time that we had sent snapshot before on each update.
What we want that if we can configure LS logging, we want to disable its "Unexpected snapshot event" message, so that it don't show this message on receiving a redundant snapshot event
Regards,
Pradeep Chahal
PradeepChahal
Hi Dario,
Looking at a previous post, I have seen that you mentioned that the following logic is implemented in the Lightstreamer server:
if isSnapshotAvailable(item) == true
[SNAP] [EOS] UPD*
else
UPD*
with the following comment:
"However, redundant SNAP events, after generating the reported log line, are just converted into UPD events; so, they are NOT DISCARDED."
I would like to understand if there is any special reason why Lightstreamer is reporting the exception in the logs for the additional snapshot provided and if this has any effect in the behavior / performance of the Lightstreamer Server, apart the line in the logs.
As in the case of our data adapter, I see it as a possible common behavior in certain publisher/subscriber APIs to provide multiple snapshots to "resume" or "refresh" an item, therefore I would like to understand whether Lightstreamer is thinking of managing this, with either a configuration or an extension of your API.
The alternative for our own data adapter would be to implement a stateful logic as opposed to the current stateless one, converting to simple updates all the snapshots of an item following the first one.
Let me know if you need any further detail to better understand by request.
Thanks a lot in advance,
Pradeep
Dario Crivelli
If Lightstreamer Data Adapter interface is implemented correctly,
any snapshot event sent in the middle of the update flow for an item in MERGE mode
cannot add any new information and might even not reach the client.
So, there would be no advantage in extending the Data Adapter interface to add this case.
On the other hand,
if a snapshot event sent in the middle of the update flow for an item in MERGE mode
happened to add new information,
then some update would have been missed in the middle
and the new event would behave as a normal update.
This is why, in a case like yours,
we ask the Data Adapter to adapt the feed interface to Lightstreamer interface,
which means to govern the isSnapshot flag
in such a way that it is sent as false for all but the first event.
However, as a recovery action for an incorrect application of the interface specifications,
we decided not to discard the abovementioned events,
but rather to ignore the isSnapshot flag (with no other effects) and issue a warning.
Notwithstanding that, the warning should be considered as targeted to the implementer/tester,
so as to fix the Data Adapter to become Lightstreamer-interface compliant.