Hi Richard
The Server expects that the Data Adapter sends the update messages for each item by following this general rule:
if isSnapshotAvailable(item) == true
SNAP* [EOS] UPD*
else
UPD*
where:
SNAP represents an update call with the isSnapshot flag set to true
EOS represents an endOfSnapshot call
UPD represents an update call with the isSnapshot flag set to false
However, more stringent rules apply based on the item mode (remember that the mode pertaining to each item is defined by the Metadata Adapter through the modeMayBeAllowed method; at most one out of the MERGE, DISTINCT and COMMAND modes can be associated; furthermore, in each of these 4 cases, the RAW mode can be associated, leading to 8 possible cases, one of which associates no modes to the item and is not meaningful).
In MERGE mode, the rule becomes:
if isSnapshotAvailable(item) == true
[SNAP] [EOS] UPD*
else
UPD*
where a missing snapshot is replaced by an empty snapshot.
However, redundant SNAP events, after generating the reported log line, are just converted into UPD events; so, they are NOT DISCARDED.
In RAW mode, on the other hand, isSnapshotAvailable is ignored and the rule is always:
UPD*
And all SNAP and EOS events are IGNORED.
Note that if the same item is enabled in both MERGE and RAW modes, then each event follows two distinct routes, where the two rules are applied independently.
Also, note that this update interpretation rule is restarted after each different subscription of the same item. The Server ensures that, for a single item, the subscribe and unsubscribe calls to the Data Adapter are issued in sequence and follow the pattern:
(subscribe unsubscribe)*
After each subscribe call, the interpretation rule is restarted until unsubscribe is issued. Then all events are discarded until subscribe is issued again. If the Data Adapter enqueues some updates and sends them to the Server asynchronously, then some problems may arise in case of a fast unsubscribe/subscribe sequence. Using smartUpdate, however, is safe from this point of view.
May you please check the subscribe/unsubscribe/update sequences occurring in your system?
You can have the Server log these events by setting the "LightstreamerLogger.subscription" logger priority as "DEBUG" in Lightstreamer Server logging configuration file.
Consider, however, that the reported warning may be unrelated to your problem.
A mismatch in the field names used may be the cause as well.
You can compare the events received from the Data Adapter and the events sent towards the client by setting the "LightstreamerLogger.pump" logger priority as "DEBUG" too.
Dario
