Inorder event delivery

[rajesh.palanisamy]

In command mode , the events received by the clients is out of order. I assume the LS behavior is, the first client who invokes snapshot call get the ordered events and consecutive clients fetch data from kernel get the events dispatched in random order. Do you have any suggestions for us to retain the ordered delivery.?

Example Scenario Client A invokes first subscription:

Adapter Snapshot retrieval send smart Update in the order	Item1, item2, item3
Client A receives	Item1, item2, item3 ( subscription initiator receives in order delivery )
Client B receives	Item2, item1, item3
Client C receives	Item2, item3, item1 or Item2, item1, item3

Are we missing something in configuration level to achieve this?

Thanks
Rajesh

[DarioCrivelli]

Hi Rajesh,

I confirm that Lightstreamer does not associate any ordering to the keys that compose the snapshot of an item in COMMAND mode.
To avoid confusion: I assume here that when you write "item1, item2, item3" you are not referring to three "items" in Lightstreamer terms, but to three "keys" pertaining to a single item subscribed to in COMMAND mode.
Likewise, I assume that when you "receive" the key "itemX", you actually receive an ADD event for this key.

In your scenario, the first client gets the events as real-time events, so it gets them in the same order in which they arrive from the Data Adapter (although this is not always guaranteed, depending on the subscription attributes).
The subsequent clients get the events as part of the accumulated snapshot, so they get them in a random order decided by the Server, regardless of their past arrival time.

As far as the COMMAND mode snapshot is concerned, there is no way to instruct the Server to stick to a particular order for the keys, hence the client is responsible for ordering the snapshot, once it has completed, based on some field.
Note that if your criterion is based on the arrival time (for instance of the ADD; or of the last UPDATE of the key), then the timestamp information should be added as a custom field, as it is not provided natively.