zperak
Hi,
we are switching to ARI. On Lightstreamer side we use RobustNetworkedDataProvider and on application side we have implemented counterpart adapters/provides. COMMAND mode is used to push data.
When connection between Lightstremer and application server breaks (e.g. due to application restart), LS correctly reloads new NetworkedDataProvider and waits on ports.
Newly created NetworkedDataProvider is loaded with "state" of old (shut down) provider. When application connects to LS, new provider sends all subscribe requests. Application sends all "active" command records (ADD) and we get warning for each ADD: "Item already contains the key xxx.".
Problem is that remote data provider does not know which items is cached in LS when it starts. Hence, it cannot issue DELETE commands to delete old data. Another (minor) problem is these warnings.
I'd like RobustNetworkedDataProvider not to reload newly created NetworkedDataProvider with state of its predecessor, rather to start it as if LS server was restarted. That would create short break in data feed on client side but since that happens rarely it is acceptable.
Is there some configuration parameter so that RobustNetworkedDataProvider behaves this way? I tried setting events_recovery to both leave_hole and use_snapshot with no difference.
Regards,
Zoran Perak
Dario Crivelli
Indeed, the RobustNetworkedDataProvider faces the worst consequence of a Remote Data Adapter crash (i.e. prevents the Server from closing), but at the cost of possible inconsistencies in the data flow.
The inconsistency may be accepted for items in MERGE mode, but usually not for items in COMMAND mode.
As documented in the sample adapters.xml provided, neither with the "leave_hole" nor with the "use_snapshot" policy can the missed "DELETE" event be recovered. The latter policy, at least, allows you to recover the missing "ADD" and "UPDATE" events at the cost of some warning messages.
In order to recover those cases fully, a far more sophisticated implementation of RobustNetworkedDataProvider would be needed, such that it could keep the state of the COMMAND mode items it supplies.
In fact, the RobustNetworkedDataProvider does not keep the state of any item: the state is only kept internally by Lightstreamer.
As an alternative, your new Remote Data Adapter could, at startup, try to recall, in some way, the state of the item at the time the old instance failed, so as to send the old state as the snapshot and all the deltas as the first updates;
"leave_hole" should be configured for this case, as the RobustNetworkedDataProvider should consider the snapshot as redundant.
If recovering the old state of the item is not possible on the backend side (as in your case), you could still try asking for the state to the Lightstreamer Server instance itself, by opening a session and subscribing to the item, then waiting for the snapshot until the "End Of Snapshot" signal is received.
Note that this would be far simpler with the Prestoor Vivace edition, which supplies various kinds of client libraries.
zperak
Dario, thank you for clarification. I've forgot that item cache is in the server, not in the data provider.
