Results 1 to 3 of 3
  1. #1

    How to recover from subscription:didLoseUpdates:forItemName:itemPos:


    The LSSubscriptionDelegate includes the method `- subscription:didLoseUpdates:forItemName:itemPos:`. The documentation says: "By implementing this method it is possible to perform recovery actions." What are the recommended recovery actions?

    Eric Baker

  2. #2
    Join Date
    Jul 2006

    The callback is invoked only when you subscribe to an item and specify that you want to receive all updates, without any filtering (i.e. RAW mode or "unfiltered" frequency specified; this also applies to all items subscribed to in COMMAND mode, but limited to ADD and DELETE messages).
    In these cases, we suppose that missing an update has important consequences on your application, hence that the application should be informed of the issue.
    Obviously, Lightstreamer does its best effort to keep all updates, by buffering them if the client is not ready to receive them or the bandwidth is low. However, it also imposes a configurable limit on the buffer (<max_buffer_size>), hence losing updates is possible.

    In our documentation we meant to stress that, by knowing the issue, the application can step in and react.
    But what can be done depends only on the nature of the data, hence on the application.
    The simplest thing is to alert the user of the hole.
    A real recovery, that is, the rescue of the lost updates, cannot be done through Lightstreamer. You can unsubscribe and resubscribe to the item, but this just ensures that you restart from a clean state.
    Note that we are talking about a critical restriction of bandwidth or client processing power, hence the goal of sending all updates may be just not feasible.
    In general, you should rely on unfiltered subscriptions only for items with infrequent updates, so that losing an update is nearly impossible.

  3. #3
    Join Date
    Jul 2006
    Let me clarify that another important case that can lead to lost updates is when the Server itself imposes a frequency limit because of licensing restrictions. In fact, this restriction also applies to items subscribed to in RAW mode or with "unfiltered" frequency specified.
    In this case, you still cannot recover the issue at runtime, but you can prevent it from happening by designing the application in such a way that the limitation is taken into account.
    For instance, if the limit is one update per second and you want to send up to 2 updates per second without loss, you can spread the updates on multiple items and then restore the update sequence on the client side.



Similar Threads

  1. Subscription Problem, I think
    By jcroston in forum Client SDKs
    Replies: 4
    Last Post: October 7th, 2008, 04:06 PM
  2. recommened usage - multiple item subscription
    By tstojano in forum Client SDKs
    Replies: 1
    Last Post: August 13th, 2008, 04:12 PM
  3. subscription came to late
    By michaelvb in forum Adapter SDKs
    Replies: 1
    Last Post: May 29th, 2008, 10:07 AM
  4. Replies: 6
    Last Post: May 30th, 2007, 11:47 AM


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:21 AM.