Unusual scenario with lightstreemer client

Hi,

I have some unusual scenario. I have js (gwt) slider that helps the user to choose time for example slider could be moved from 0 to 60 min. I must have 2 data feeds that sends data to the client, and for example if the slider arrow is less that 20 min i must use the first feed, when the user slides after 20 min i must use the second feed.
I think i have 2 approches:
I) switch the feeds i.e. unsubscribe from one and subscribe to the second.
II) I use one feed and send all the data to the client and filter it there.

I must note that the subscribed items are the same (the data from the 2 feeds has the same format, but comes from different external sources).

If i use the I) i will loose time for subscribe/unsubscribe/subscribe and that will be visible to the user (and also he will move that slider very frequently).
if i use the II) i will send unneeded(double it) data to the client(but that is the point with LS, LS is constructed to avoid exactly that).

Help me decide, or if you have other better solutions?
Note: i have 2 external data generators, that must send the messages to one ls feed, which will send the data to the adapter. In the first approach i will have two items and only one will be subscribed at a time.
In the second apprach i will have only one item and i will filter the incoming data onItemUpdate function with my custom logic.
Regards.

Hi,

You could go with ii), but doing the filtering on the Lightstreamer-Server side, not on the client side.

There are several mechanisms on Lightstreamer to filter a data flow. For example:

- You can allocate a maximum bandwidth to each user. The bandwidth can be changed in real-time (see this demo). How the data is filtered depends on the subscription mode and on the allocated buffer size.

- You can allocate a maximum update frequency to each item/user. The maximum frequency can be set only at subscription time. So, to change it, you should unsubscribe and resubscribe from/to that item. These operations are very fast on Lightstreamer (so also option i) could work well). Again, how filtering works depends on subscription mode and its related parameters.

- You can set a Selector in the Metadata Adapter to decide for each individual event for each user whether to filter it or not. The client specifies the selector at subscription time. To change it without unsusbcribing, it could simply send a message to the Metadata Adapter at any time. Notice that selectors are recommended only if the total throughout (data flow multiplied by the number of users) is not too high, otherwise this could be too heavy.

Consider that some of these features may not be present is all the editions of Lightstreamer.

If you already have two feeds and you just want to switch between them, without imposing other intermediate filtering frequencies, I suggest you to try with i) first and see if the result is acceptable. A trick to reduce thrashing is to only fire the actual unsubscription/subscription only when the user releases the slider.
In any case, to have an idea of how fast it is to unsubscription and subscription, check out this other demo.

Hi, very good example, i suppose the code for this is only in the client side and it is trivial(we just create OverwriteTables for each item. So in fact i will have only to items. One other thing, i am using NonVisualTables (where could i find docs about these tables?), is it possible to be done with NVT?
From the demo it looks like that may I) approach could work well! I do not want to limit the messages send to the client , in fact they must be as real time as possible. Also the messages freq is about 3-7 per sec from feed i.e. about 11 if i send them all to the client.
I will try to implement it like the demo.

Could you tell me when the subscription is done? Here is my code:

Code:

---

                var page = new $wnd.PushPage();
                        page.context.setDomain(prop['domain']);
                        page.onEngineCreation = function(engine) {
                                engine.connection.setLSHost(prop['host']);
                                  engine.connection.setLSPort(prop['port']);
                                engine.connection.setAdapterName(prop['adapter_root']);
                                engine.changeStatus("STREAMING");
                        }
                        page.bind();
                        page.createEngine("ManualBetApp", "/js/ts/2/ls/", "SHARE_SESSION");
                        var nvt = new $wnd.NonVisualTable(group, schema,"DISTINCT");
                        nvt.setDataAdapter(prop['adapter_name']);
                        nvt.setSnapshotRequired(true);
                                nvt.onItemUpdate = function(item, itemUpdate, itemName) {
                        if (itemUpdate.isValueChanged("message")) {
                                var msg = itemUpdate.getNewValue("message");
                                thiz.@claire.web.util.client.PricingManager::onTickData(ILjava/lang/String;)(0, msg);
                        }

---

Is it when this is called : engine.changeStatus("STREAMING"); ?

We suppose you refer to the second demo example, i.e. the GridDemo.
In general, using NonVisualTables is simpler than using OverwriteTables
when switching subscriptions, as you are trying to do.
In fact, in the GridDemo, which is based on OverwriteTables,
each time new subscriptions are performed to replace the previous ones,
we need to work on the page DOM in order to create new cells to associate to the new OverwriteTable instances.

With NonVisualTable, you put values on the page directly on your onItemUpdate callback,
so you can reuse the same DOM elements from callbacks associated with subsequent instances of NonVisualTable.
We provide additional help on using NonVisualTables in this forum thread.

The subscription and unsubscription requests are issued to the Server
in association with the addTable and removeTable calls,
not reported in your code snippet.
Only in case you issue addTable before engine.changeStatus("STREAMING")
(possibly at page startup),
the subscription requests are issued after the latter call.