Light streamer send only subscribe if remote adapter looses connection

[gal_nitzan]

Hi,

I noticed that when remote adapter goes down or looses connection with Lightstreamer, Then Lightstreamer would send only the subscribe message.

This seems to be reasonable behavior, however when close monitoring of who is using/subscribed to items, and the server did actually went down, when it starts again, it has lost all information about sessions/subscribers unless it is persisted somehow.

What could be a best practice in this type of situation?

Sincerely,

Gal

[gal_nitzan]

I always find the answer in the forums after posting the question .

I guess the correct way is to enable table notification?

Gal

[Mone]

Hi,

can you please expand on the matter at hand?

What do you mean with

Then Lightstreamer would send only the subscribe message.

?

assuming you're using the robust version of the adapters, in the default adapters.xml it states that

this Metadata Adapter manages the case in which the remote
counterpart is missing, by just refusing all new requests from the
clients and storing all state change notifications that have to be
sent to the backend (namely, session closing and table closing
notifications).

In any case to track which client has subscribed to which item(s) you have to enable the tables notifications regardless of the remote adapters behavior


HTH

[gal_nitzan]

Hi Mone,

I thought I figured it out, apparently not.

I have enabled NNT.

However, I know that I'm missing something.

If I take down the server and bring it up again, I get only SUB messages.

Does it mean I need to persist the session information?

I have some private channel which send user's specific data. To make the items of the user unique, I prepend the user's is to the item name like 38_user.svc.channel

However, since the server went down, I no longer have the session information I gathered in the metadata adapter during the NNS.

Could you please help to understand what could be the best way to approach this?

Regards,

Gal

[DarioCrivelli]

So, your problem is that the Robust Metadata Adapter does not instruct the replacing Remote Metadata Adapter on how to recover the current state of the user sessions.
We confirm that there is such limitation in the Robust Metadata Adapter, which, in fact, assumes that the Remote Metadata Adapters persist the current state.

The Robust Metadata Adapter only guarantees that if a Remote Metadata Adapter answers to the notifications after persisting the information, then the newer Adapter will receive all the notifications occurred in the downtime that will not have been persisted (with a few possible duplicates). Note that this only includes session and subscription closings, because other requests must have been refused during the downtime.

The above, however, leans on the assumption that the new instance of the Remote Metadata Adapter is able to know when it is in replacement of a previous instance.
Could you manage this information?
Admittedly, the Robust Metadata Adapter does not help in this regard at the moment.

[domainkeys]

Anyway, it has served me, even if it's not the official thread, thank you.