Printable View
Hi everyone, It's seems to me that i don't understand something. I have following use case:
1) I receive data updates during 5 minutes,
than
2) I lost connection with server
than
3) I connected to the server again
and now i want to receive just NOT received updates.
In which mode should I work? How i should config subscriptions (in javascript)?
(I know that i can work in DISTINCT mode in this case, but how i can receive not received updates?)
Hey, where are you, guys?(((
We are here!;)
The way to recover lost updates during a disconnection, or rather, to update the client with the latest situation of every Items is through the snapshot. The concept of a snapshot may vary depending on the type of subscription and is present both for MERGE, DISTINCT, and COMMAND mode. Please refer to section 3.4.1 for full details.
A JavaScript client can call this method setRequestedSnapshot to request the snapshot from the server and so it will receive all snapshot updates and then the real time updates.
Yes, I know it, but i receive all updates in DISTINCT mode(because the snapshot buffer size is set to big value). Is there a function or config parameter to receive not received updates in DISTINCT mode?Quote:
Originally Posted by giuseppe.corti
You're right, indeed the purpose of the snapshot is to allow the client every time it connects, or reconnects, to reconstruct a complete and consistent state of the Item subscribed at that moment. In case of DISTINCT mode the snapshot consists of a list with a predefined maximum length, which contains the latest itemEvents received from the supplier Data Adapter. This raises two side effects: the first is not to receive some updates if the buffer is too short, the second is to receive messages already received before disconnection in case of a wider buffer.
I confirm you that there is no config parameters that allows you to receive only messages that are not received in the past. In fact, management of this kind, involving the story of a client session is assigned to the application level.
This can be achieved by adding logic in the adapter. You can add a unique identifier to each message so that the client can easily discard any possible duplication. Or a more complicated mechanism of messages acknowledge and consequently the persistence logic appropriate for any resending. This second hypothesis is very suitable for queuing and acknowledge capabilities of JMS. About this, we are developing a new product, Lightstreamer JMS Gateway, which will allow you to use all the JMS features across the Internet, by leveraging HTTP and WebSockets to carry JMS messages.