LSClient disconnection handling [Java]

Hello,

When I call LSClient.openConnection, am I guaranted that there will always be a connection?
In other words, if onEnd or onFailure of the associated ConnectionListener is called, is the reconnection automatically handled?

Thanks.

Hi, The LSClient class only handles the protocol layer, so, it does not provide automatic reconnection handling.
This is something that an application may need to control directly.
The Java Client SDK also features the LSProxy class, which leans on LSClient and provides services like automatic reconnection and resubmission of the subscription requests. But consider that the policies adopted there (in particular for managing the consequent holes in the received data) may or may not be compliant with the application requirements.

Thanks Dario, LSProxy seems to be what I was looking for.
The seamless updates won't be a problem; on the contrary, it was a feature targetted.

Hi,

I would like a clarification for this extract from the Javadoc of LSProxy :

Quote:

---

For items subscribed in MERGE or DISTINCT mode with filtered dispatching allowed, in case of reconnection, the updates flow can continue seamlessly, with just some possible temporary data loss (which is allowed, however).

---

What is the meaning of the "temporary" word?
Does that mean that the events will be delayed, lost or something else?

Thanks.

Hi, When we talk about a reconnection, we mean the recovery after an unexpected interruption of the previous connection, which is operated by the library and implies that the previous session has closed and a new one is established.
Hence, we talk about something that was not supposed to happen, but might have been caused by an external (e.g. network) problem.

We define "temporary" the condition in which a session has closed and the new one hasn't been established yet.
It is a temporary state because it is not permanent; but, actually, we have no control on the real duration of this state.

Upon such recovery, the LSProxy tries to fill the gap in updates in some way.
In particular, in MERGE mode, it asks for the snapshot on the new session and this restores the current state.
From the application point of view, it receives a single update which is the merging of all updates occurred during the gap
(or nothing at all, if no updates occurred or the state has finally remained the same).
Unless unfiltered dispatching was requested, this is still consistent with the subscription "contract".
The recovery is more complicated in DISTINCT mode; if you are interested in what happens exactly, please confirm.

Hi Dario,

Thanks for your detailed answer.

I'm also subscribing to DISTINCT items with filtered dispatching allowed, so I'm very interested about how the recovery works.

For DISTINCT items, if you interrupt a session and reopen another one subsequently, you can resubscribe to the item and ask for the item snapshot, which consists in a recent history.
As Lightstreamer does not persist the client state (for this heavier task we provide the JMS Gateway), the client can only decide the length of the snapshot to request, subject to the maximum length that the Server is allowed to keep by the Metadata Adapter (see getDistinctSnapshotLength).

This recent history may fill the gap, but more likely it will be longer or shorter than the gap.

• If it is shorter, some events will be lost, but this is still consistent with the subscription "contract".
• If it is longer, the client will turn out to receive some subsequence of events twice.
  This can be detected by the application, provided that it identifies the events in some way; Lightstreamer does not provide such identification.

The LSProxy interface has a simple approach.

• It assumes that the subscription is aimed at filling a static list on the screen and that the initial snapshot requested by the application, if specified through setRequestedDistinctSnapshotLength, corresponds to the size of the list.
  Hence, upon internal reconnection and resubscription, it requests the same snapshot as in the original request.
• If, based on the above rule, it requests a nonempty snapshot, then it issues a special call to "onLostUpdates" to the UpdateListener to warn the application of the case (see the method documentation for details).

Thanks Dario.

Based on the Javadoc, onLostUpdates is called in case of MERGE or DISTINCT items with unfiltered dispatching requested.

With unfiltered dispatching, is the recovery working the same way as you described for items with filtered dispatching allowed?

Hi, Yes, the recovery is attempted in the same way.
In fact, the second sentence:

Quote:

---

Also, notifies a restart in the Updates flow for a DISTINCT Item, such that some Updates may be missing or duplicated.

---

refers to DISTINCT mode in general, regardless of the unfiltered flag.

For unfiltered subscriptions the first sentence also holds, which covers the case in which either client slowness or network problems or a bandwidth setting causes the Server not to send updates in time and causes the internal buffer to fill. This is not notified for subscriptions that allow filtering.

Thank you Dario, your answers really helped.