Events per UpdateEvent relative to the same item

Hi,

Can you please elaborate on this subject as I can't get it from the docs. What does it actually mean?

Especially this part is confusing: In case a grantedMaxFrequency limit is active, RAW mode and unfiltered dispatching are also subject to the limitation of 1 Event per UpdateEvent relative to the same item. Is Event here the data coming from provider to LS? Is the frequency limiting the number of UpdateEvents per second? If so, I'd assume that with limited frequency, LS would join even more Events into one UpdateEvent, in order to send as much provider data as possible in a single push. But the docs say the opposite.

Tnx

Hi Dejan,

In case a grantedMaxFrequency, ie in the case of "Allegro" or "Moderato" edition, only 1 update per second for each Item is sent to the client.
So the meaning of that sentence of the doc is that regardless of the frequency of the updates from the DataAdapter to the Lighstreamer server (ItemEvent) updates to the client (ItemUpdate) will be sent at the rate of 1 per second.
No more than one ItemUpdate for the same Item will be packed in the same UpdateEvent sent to the client.
In case of RAW mode (or of another subscription mode but with "unfiltered" dispatching) and high ItemEvent freqeuncy this might result in an unlimited growth of the queued updates in the EventBuffer.

Please let me know if you need further clarifications.

Regards,
Giuseppe

Hi Giuseppe,

Tnx for the quick reply, but I'm still confused by the docs. I think I understand how this works now, just it's not very well documented.

So the frequency is defined as number of ItemUpdates (sent to the client) per second:

Each item subscribed by a Client (in a Table, within a session) is characterized by a maximum frequency (maxFrequency) to send updated events to the Client.

Further down, the docs say:

...only one event can be released in a single updateEvent (unless the allowed maxFrequency is very high or unlimited, or the dispatching mode is unfiltered).

My question is why doesn't LS pack them even more when the frequency is limited, i.e. when the benefits of packing would be even greater? Or you should change the definition of grantedMaxFrequency (and all of the frequency params) to something like "processing X updates received from the data provider per second".

BR,
Dejan

Hi Dejan,

I am very sorry that the documentation generated confusion in you.

The frequency limits are an imposition of the license (for commercial purposes) or an application choice implemented by the allowedMaxFrequency (in the Metadata Adapter) or by the requestedMaxFrequency (in the client).
In these latter cases the intent is to send a limited amount of data on the network, to save bandwidth or to be lighter on the processing of the client, and it is for this reason that no more than one update is packed in a single UpdateEvent.

Your statement "processing X updates received from the data provider per second" is not correct. The updates from the Adapters are received, processed, and finally, in the case, queued in the itemEventBuffer in real time regardless of the frequency limits for the client.
And this has very significant application effects. Please consider the case of an Item subscribed in MERGE mode, with a frequency limit for the client of 1 upd/s but a rate of incoming updates from the Adapter much higher.
In this case the values of Item fields in the itemEventBuffer will be continuously updated and once per second the client will be updated with the freshest data available.
A dramatically different situation from the case of processing an update from the Adapter per second.

Regards,
Giuseppe

Hi again,

Thanks for clearing it up, now I understand the logic behind it.

I'd still suggest that you update the docs to be more precise or to have some examples for this.

BR,
Dejan

Hi Dejan,

Thanks a lot for your feedback on the docs. We will update them to improve clearness, based on your suggestions.

Cheers,
Alessandro