command mode latency

PradeepChahal

Hello,

as I read in LS white paper, it has been mentioned that, in command mode, a ADD event will not be send to client if a DELETE event arrive with in 10th of a second. Does it mean any ADD event will be having minimum 10th of a second latency ? what if a UPDATE and then a DELETE event arrived ON same key with in a 10th of a second after a ADD event?

Dario Crivelli

The timespan of a tenth of a second was cited because it is so small that the human eye cannot appreciate states occurring for that timespan only. So, it was argued that compensating events occurring within a similar timeframe would be advisable and could provide benefits on the performance side.
However, the timespan associated with filtering behavior is fully configurable in Lightstreamer Server and 100 ms is not the default; in fact, you have to explicitly assign the maximum update frequency from your Metadata Adapter.
Note that, unless you use Vivace edition, a maximum update frequency (for each single key) of 3 updates per second, or even 1 update per second, cannot be exceeded, hence compensation times even longer than 100 ms are involved and can't be reduced.

That said and assuming that 10 updates per second are configured,
note that events are not necessarily delayed for 100 ms:
when an UPDATE is sent by the Server, a new UPDATE immediately received is not sent until 100 ms have elapsed, but an UPDATE which does not immediately follow the previous one is not delayed.
Moreover and most important, ADD and DELETE events are not delayed at all.

So, it's unlikely that in cases like the ones you describe the events are cancelled against each other and nothing is sent.
However, both cases can happen if the events cannot be sent immediately to the client because of other causes; for instance: configured bandwidth limits, real bandwidth limits, client slowness because of CPU exhaustion and so on.

If your update flow is not just targeted to a screen table and your client needs to keep track of every event occurred, you have to subscribe to the item in unfiltered mode.
This has only one drawback:
unless you use Vivace edition, the maximum update frequency of 3 updates per second, or even 1 update per second, still applies (though with no filtering, but rather enqueueing of frequent updates);
moreover, the limitation applies to the whole item, not to each single key, which is far more stringent.

msignorini

I'm using COMMAND mode to subscribe an item.

I'd like to receive all update regarding ADD and DELETE commands, but it's not necessary for all UPDATEs. In other words, I don't want that LS merges ADD and UPDATE, or ADD and DELETE.

Is there any possibility to set this mode?
If I use unfiltered mode, client will receive all UPDATEs and it's not good.

Alternatively, is there a possibility to change the value of a field in case of LS merge an ADD and a UPDATE event?

In all cases, I can't use different keys for add and updates, because I have to store all add_keys to be able to remove them at the end.

Dario Crivelli

Unfortunately, all kinds of filtering may apply (even DELETE+ADD or UPDATE+DELETE) and the behaviour is not customizable.
Note that ADD and DELETE events are not subject to frequency limits, so it's unlikely that ADD+DELETE or DELETE+ADD pairs are filtered, but it can happen, for instance if bandwidth limits are in place.

As long as [ADD-UPDATE] filtering is concerned, you can detect it by adding a field with a different value for ADD and UPDATE type events.
Lightstreamer ensures that the latest value of the field is forwarded,
hence if your client gets an ADD event with the UPDATE-related value, it can infer that the original ADD event was merged with at least one UPDATE.

Alessandro Alinone

Another solution is to use "two-level push", if you are not already using it.

This is a very common technique, which is illustrared in the Portfolio Demo.

IF you subscribe the first-level item as unfiltered COMMAND, and the second level items as MERGE, you will achieve the behavior you need, but only is the first-level updates (changes of quantity in the example above) can avoid conflation too.