DISTINC mode and pre-filtering issue

WorkingMan

I am very confused about how data are filtered before they are sent to the client. This results in unchanged items being passed to the client as empty entry even in DISTINCT mode. Is there a way to allow the adapter to send all data to the client for each update sent to the client?

From client side it seems that no matter how I configure the subscription it's's always receiving filtered data.

So basically I want the data sent to the client in full even if the data is unchanged.

Example of filtered data:

1,1|item1|item2|item3
1,1||itemNew|

I want the above to be unfiltered (ie: receive unchanged data as well):

1,1|item1|item2|item3
1,1|item1|itemNew|item3

What is the solution?

Giuseppe Corti

You are right, by default configuration, a field of an Item that is unchanged with respect to the previous delivery to the Client it is transformed into an empty string.
It is left to the clients the burden of retrieving the value sent previously for that field of that specific Item.

However, this default behavior can be changed by setting the <delta_delivery> parameter to N in the server configuration.

But, please note that this holds for clients based on the "SDK for Generic Client Development" and for all items subscribed in the server.
Please also refer to inline documentation of <delta_delivery> parameter in lightstreamer_conf.xml configuration file.

WorkingMan

Are you saying this won't work for generic client (which is what I I am doing and what we need)? I am testing with Allegro-Presto-Vivace v5.1.1 1623.2. I changed the value to 'N' and restarted LS and tried to test this with MONITOR adapter and it didn't seem to work (was using curl from command line).

In the conf file it says "holds" does it mean it "doesn't apply" or "wont work" for generic client?

Giuseppe Corti

WorkingMan you are right the <delta_delivery> parameter should work for clients based on the "SDK for Generic Client Development".

You have found a bug that affects recent versions of Lightstreamer.
Specifically, it is that the <delta_delivery> is ignored because the client request parameter, LS_delta_delivery, takes precedence and the default for the client request is "true".

So a simple workaround for you would be to add to each client request this parameter: LS_delta_delivery=false.

From our experience and from Lightstreamer users feedback we know that the use of the parameter <delta_delivery> set to 'N' is very unusual and therefore the bug can be considered non-critical. Anyway, the correct precedence of the <delta_delivery> server parameter will be fixed in the next Lightstreamer release.

Sorry for the inconvenience.

WorkingMan

Outstanding, that worked great.

Thanks