Results 1 to 2 of 2
  1. #1

    Inorder event delivery

    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

  2. #2
    Administrator
    Join Date
    Jul 2006
    Location
    Milan
    Posts
    953
    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.

 

 

Similar Threads

  1. Replies: 7
    Last Post: June 7th, 2010, 09:38 AM
  2. sending multiple snapshot (true) event in smartUpdate()
    By Pradeep Chahal in forum Adapter APIs
    Replies: 6
    Last Post: October 12th, 2009, 12:25 PM
  3. Bandwidth and event pushing
    By churrusco in forum General
    Replies: 10
    Last Post: May 8th, 2007, 02:04 PM
  4. Unexpected snapshot event for MERGE
    By churrusco in forum General
    Replies: 2
    Last Post: May 4th, 2007, 03:19 PM

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
All times are GMT +1. The time now is 06:50 PM.