Sorry, I have to correct myself.
Even with unfiltered dispatching, there is no guarantee that the initial snapshot received by the client is in the same order as the snapshot sent by the Data Adapter, even for the first subscriber.
This is because, in the internal implementation, the start of the kernel-to-client flow is slightly deferred with respect to the start of the adapter-to-kernel flow. Hence, the very first events sent by the Data Adapter, rather than being directly forwarded to the client, are temporarily accumulated in the cached snapshot and this makes them lose the ordering.
We can improve the management of this case in the next release update,
so as to ensure that, at least, the first subscriber receives the events in the same order in which the Data Adapter sends them.
For now, the best thing you can do is:
- request the item by the client in "unfiltered" mode (as said before)
- use different item names for different subscriptions of the same item (as said before)
and, upon a subscription request to the Data Adapter:
- send an EOS event as the first event
- then send the snapshot in the form of regular updates
- then send the real-time updates
while at the client side:
- still request the snapshot
- check if snapshot events are received and cache them; as a consequence of what said before, this is still possible, but should hopefully be limited to a few events
- upon reception of the end-of-snapshot notification, manually sort the cached snapshot events and finally process them
- then process the forthcoming events normally, as they now keep the original ordering
Dario