Results 1 to 2 of 2
  1. #1

    Unexpected snapshot event for COMMAD item

    In our system the Data adapter give the initial snapshot as the first client subscribes,
    the snapshot is multiple events sent with "Add" command and 'isSnapshot' flag set to true,
    The snapshot ends by sending "endOfSnapshot" call.

    Please clarify the lightstreamer behavior:

    1. Pre-Processor Snapshot life time: does the snapshot is hold in the server until all the client are unsubscribed ?

    2. When first client is subscribed to an item, if we send update
    during/before the snapshot we will get the warning of "unexpected snapshot" but still it will be saved in the server, correct?

    3. What happened if the second client subscribe to the same item and before sending the snapshot
    the pre-processor will get another update from the remote adapter? will we still get the error?

    4. how do we handle unsubscribe followed by fast subscribe action if as update sent between requests?

    5. what are all the scenarios which we can get the "unexpected snapshot"?
    (beside cases of an update done before snapshot is sent)
    consider we are also using cluster of LS.

  2. #2
    Join Date
    Jul 2006
    Please find the corresponding answers below:
    1. Yes, as long as at least one client is subscribed to, the subscription is kept.
      When the last client unsubscribes, the server invokes unsubscribe() to the Data Adapter and, contextually, it discards the current snapshot.
    2. Yes. For the sake of precision, the "Unexpected snapshot event" warning is sent when the snapshot is complete and a new event with the snapshot flag is received.
      If you send an event without the snapshot flag while the snapshot is being sent, the event implicitly terminates the snapshot and it is treated as a real-time event. This happens silently. If, after that, more events with the snapshot flag are sent, the warning is issued and the new event is considered as a real-time event. The EndOfSnapshot event would also trigger the warning in this case.
      From the Server point of view, this is not important at all. All events received, regardless that they are part of the snapshot or real-time updates, concur in keeping aligned the internal shapshot.
      The difference between a snapshot event and a real-time event is that the snapshot represents data that originated before the subscription whereas real-time updates originate after the subscription; and this information is sent to the client. So, when the Data Adapter messes up the snapshot, whether or not this is a problem only depends on the client application requirements. The Server just warns.
    3. No, the checks in 1) only regard the Server-to-Data-Adapter interaction and are independent from client activity.
      When a second client subscribes, usually the Data-Adapter has finished sending the snapshot and is sending real-time updates. In this case, the preprocessor sends the snapshot cumulated internally. Any real-time update that has occurred before, has already been integrated in the internal snapshot. On the other hand, any real-time update that occurs concurrently is enqueued properly and sent to the client, as a real-time update, after the snapshot.
    4. The Data Adapter should not send updates after receiving unsubscribe() and before receiving subscribe().
      However, since this cannot be completely prevented, such updates would be just discarded.
      This case is best handled if you use the smartUpdate() call, where you specify the "handle" of the related subscribe() call. Hence, even after a subsequent call of subscribe(), a late update pertaining to the previous subscribe() can be identified and discarded.
      In case you use the update() call, this check is not possible and it may happen that a late update pertaining to a previous subscribe() falls within a subsequent subscribe(). In this case it would be accepted and it could disturb the update flow.
    5. The only case is that in 1). The use of a cluster is not relevant, as the Server is not aware of this.
      To resume:
      The expected sequence is: subscribe() - snapshot phase - real-time phase - unsubscribe().
      The EndOfSnapshot event terminates the snapshot phase.
      Any real-time event (i.e. event without the snapshot flag) received in the snapshot phase also terminates the phase and initiates the real-time phase.
      Any snapshot event received in the real-time phase is treated as real-time and triggers the "Unexpected snapshot event" warning.
      An EndOfSnapshot event received in the real-time phase is ignored and also triggers the warning.



Similar Threads

  1. Unexpected DELETE event for key... event discarded.
    By paulwiersema in forum General
    Replies: 2
    Last Post: February 1st, 2019, 12:52 PM
  2. Event that traps an unexpected disconnect
    By kpturner in forum Client SDKs
    Replies: 2
    Last Post: September 26th, 2013, 10:27 AM
  3. Replies: 7
    Last Post: June 7th, 2010, 09:38 AM
  4. < WARN> Unexpected null event ???
    By mohamida in forum Adapter SDKs
    Replies: 2
    Last Post: December 10th, 2009, 06:57 AM
  5. Unexpected snapshot event for MERGE
    By churrusco in forum General
    Replies: 2
    Last Post: May 4th, 2007, 03:19 PM

Tags for this Thread


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 10:18 AM.