Alessandro Alinone The Lightstreamer Server ensures sequential delivery of the updates pertaining to each single subscription of an item by a client; this is done by keeping internal queues at subscription level. Hence, updates that cannot be delivered immediately are queued; this can happen, for instance, during the time between subsequent client polls in polling mode, hence the type of session is not a factor; in fact, delays due to polling or, for instance, bandwidth constraints are managed in the same way. Note that the internal Server queues are not unlimited; the hit of the configured limit is handled in different way depending on the subscription done: If filtering is allowed, it is performed; this is done in different ways depending on the subscription mode. Data integrity, in this case, is ensured even with fewer updates by definition (in fact, by allowing filtering, you accept the filtering rules). If filtering is not allowed, the Server discards the updates, but ensures that the client will receive, in place of the discarded updates, a notification that some updates have been lost. Then it is left to application code any decision as to how to handle the case. In case of connection issues with the client, the session could be truncated and replaced by Client Library code. This could cause some updates to be lost. However, the client application is notified of the session replacement; afterwards, if its subscriptions require the snapshot, it will receive a new snapshot, which it may use in order to restore the state of the item. Note that, until the session replacement is completed, the Server may issue unsubscribe() and again subscribe() to the Data Adapter for some items; hence, in order for the Server to provide a correct snapshot to the client, the Data Adapter has, in turn, to provide the current snapshot to the Server correctly. Anyway, upon the notification of the session interruption, the application code has the opportunity to react in a different way. See also the following post for a deeper description: http://forums.lightstreamer.com/showthread.php?2119-Does-Lightstreamer-offer-guaranteed-delivery In case Remote Adapters are in use, connection issues may also affect the communication between the Remote Data Adapter and the Server. In this case, no recovery action is possible and the default action is to close the whole Server, so that the client will fall in the aforementioned "session replacement" case. If you handle the Remote Data Adapter through a "Robust Proxy Adapter", then a connection issue will be recovered, but the data integrity is not guaranteed in this case. For details, see the "events_recovery" parameter in DOCS-SDKs\sdk_adapter_remoting_infrastructure\conf\sockets(robust)\adapters.xml [Originally written by Dario Crivelli]
Deann yeah thank you so much the connection just recovered by handling remote data adapter through robust proxy adapter
