Results 1 to 2 of 2
  1. #1
    Join Date
    Jul 2006

    Adding recovery capability to the supplied Proxy Adapter

    The Adapter Remoting Infrastructure makes it possible to run Data and/or Metadata Adapters as separate processes, by defining and supporting a communication protocol based on sockets.
    The supplied Proxy Data and Metadata Adapters take the burden of adapting this protocol to Lightstreamer Adapter interface.

    However, they don't provide any clever recovery mechanism to face the case in which the remote adapter process crashes or the communication is interrupted: in such cases, they just cause Lightstreamer Server to exit (so that it can be restarted later) and the Client to reconnect (in case of a cluster, another Server instance would be immediately available).
    This is because the Server/Adapters interface contract is quite stringent. For instance, a Data Adapter should guarantee that, after subscription, no updates can be lost; ensuring this even in case the connection to the remote adapter is lost is, when feasible, a strongly application dependent task and only a custom Proxy Adapter could do it.

    [>>> ADDED ON 14/11/2008: Something changed with ARI 1.2 <<<]

    In order to save the protocol handling work made by the supplied Proxy Adapters, it is possible to write custom Proxy Adapters which lean on them. Unfortunately, the supplied Proxy Adapters don't expose a proper interface for extension. The following are guidelines on how they can be reused:

    1. The supplied Proxy Adapters are included in "ls-proxy-adapters.jar"; the socket-based versions can be addressed as:
      • com.lightstreamer.adapters.remote.metadata.Network edMetadataProvider
        (let's call it NMP)
      • taProvider
        (let's call it NDP)

      Note that NDP implements the SmartDataProvider interface.
    2. The supplied Proxy Adapters can only manage one connection throughout their life.
      In order to reopen the connection, a custom Proxy Adapter should wrap an NMP or NDP instance and replace it with a new instance each time a new connection is needed.
      The newly created instance, however, should inherit the state from the previous instance and forward it to the new remote adapter as well.
      • For the NMP case, the notifyUser, notifyNewSession and notifySessionClose affect internal NMP caches. Hence, upon initialization of the recovered NMP, a playback of notifyUser and notifyNewSession calls for the currently active sessions should be submitted to the recovered NMP; one call to notifyUser for each distinct user would be enough.
        However, other methods (like notifyNewTables, notifyTablesClose and notifyUserMessage, for instance) may affect the remote adapter state. All those cases should be managed in a similar way.
      • For the NDP case, upon initialization of the recovered NDP, a playback of subscribe calls for all the currently subscribed items should be submitted to the recovered NDP.
        The NDP always sends back a snapshot, thought it may be empty in case the remote adapter cannot provide one. The snapshot should not be forwarded to the Server, though it may be used in order to recover the update hole.

      In both cases, the list of active users/sessions or subscriptions cannot be directly asked for to the inner Proxy Adapter. So, the custom Proxy Adapter has to keep them.
    3. The supplied Proxy Adapters, upon a socket disconnection, automatically try to close the whole Server.
      This behaviour should be suppressed and replaced with a graceful local closure. This has to be implemented by subclassing the NMP and NDP classes and using these subclasses as the real inner Proxy Adapters.
      The code below shows the Data Adapter case:

    The class shown can also be directly used as the Data Adapter (after commenting the final call to "failure"). In this case, when the connection is lost, no recovery is performed and no more updates will come for the subscribed items; however, this behaviour may be preferred to Lightstreamer Server closure in order to preserve other Data Adapters currently running.

    The code below shows a working example of a recovery-capable Adapter. The Data Adapter case is faced.
    All the recovery stuff has been delegated to a custom ItemFlowManager class. In this simple case, the update flow is just resumed, with no attempt to fill the update hole.

    Of course, the purpose of this code is to document what can and cannot be done while interacting with the supplied Proxy Adapter; it is not a recommendation on how to write a recovery-capable Adapter.

  2. #2
    Join Date
    Jul 2006
    Milan, Italy
    The recovery capability for the Proxy Data Adapter has now been made available as part of a new out-of-the-box Proxy Adapter. See this post for full details.



Similar Threads

  1. Viewing IP supplied in HTTP header
    By johnffoley in forum Client SDKs
    Replies: 1
    Last Post: November 21st, 2011, 09:59 AM
  2. Replies: 3
    Last Post: May 27th, 2010, 10:57 AM
  3. New Proxy Data Adapter with recovery
    By Alessandro in forum Adapter SDKs
    Replies: 0
    Last Post: November 14th, 2008, 05:04 PM
  4. Replies: 0
    Last Post: November 14th, 2008, 04:53 PM
  5. Cross domain capability
    By achimabeling in forum General
    Replies: 1
    Last Post: August 20th, 2007, 03:08 PM


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 02:42 PM.