Adding or Removing Subscriptions

[subuta]

Hello,

I have just started working with Lightstreamer, and so far I am using tables to establish client subscriptions as in:

myClient.subscribeTable(new SimpleTableInfo(groupName, "MERGE", schemaName, false) . . .

Perhaps this is not the best/only way. I don't know.

As I understand it, one of the defining features of a table is the group of items that it includes. Suppose the client wants to add or remove an item. Is it necessary to unsubscribe the table and then create and subcribe a new table with the adjusted group of items? That seems like it would be an expensive operation.

Or is there a better alternative than using tables in this situation?

Thank you.

-Dan

[Mone]

Hi subuta,

in your case we usually suggest to make mono-item tables so that you can add/remove items one by one.
If the use of a single table for all the items is a necessity I confirm the only way is to unsubscribe from the entire table and then subscribe to a new one.

Please also take a look to the COMMAND mode that may fit your case better; Section 3.1 in the General Concepts.pdf file explains it.

HTH

[subuta]

Thanks Mone. A few follow-up questions if you don't mind:

1. I picture tables as being created on the client side and sent
to the server for it to use when processing update events. Is
this correct?

2. Is the monotable approach scalable? For my use case I hope to
have hundreds of thousands of concurrent users, with an average of
perhaps 10 monotables per user. Of course I recognize that I may
have to spread the users over two or more Lightstreamer instances,
but I am trying to get a sense of how using monotables will affect
scalability.

2. Is it ok to share a schema across mono-tables?

3. I see that your code examples make heavy use of double brace
initialization (!) for table info and table listener objects. Is
this just a matter of coding taste, or is double brace
initialization better for these cases than other styles of
initializing objects?

4. I have not been able to understand some aspects of command mode
as it is described in the General Concepts document (and I haven't
started experimenting with it yet - as I mentioned, I am new to
Lightstreamer). Two sections of the description of command mode
in particular puzzle me:

a) "The itemEvents are interpreted as commands that indicate how
to progressively modify a table or a list."

As far as I know, Lightstreamer exposes a table construct but no
list construct. Is the documentation saying that command events
can modify the contents of the server-side table data structure,
or is it saying "If you are maintaining your own
(non-Lightstreamer) table or list in your client code, here is a
convenient way to trigger changes to it."?

b) "Notice that a field of the schema in a COMMAND subscription
could contain the itemName of a
different item. This way, it is possible to perform a multi-level
push, where a change in the
first-level item can provoke subscription or unsubscription to
different second-level items (and
so on)."

Does this mean that a command event can cause an item to be added
to (or removed from) a Lightstreamer table, and that the added
(removed) item will be automatically subscribed (unsubscribed)?

-Dan

[Mone]

Hi Dan,

1 depends what you mean by "created on the client"; A table simply represents a subscription; is the duty of the data adapter to receive the subscriptions and to send the updates to the server kernel (that in turn will send the updates to the clients)

2 short-answer: yes, it scale.
The mono-item table approach only adds some small overhead on the client for the computational cost of handling more objects.
That approach also adds some overhead to the data sent to the server to perform the subscriptions. This is only done upon subscription. Moreover it is possible to batch subscriptions together to diminish even more the small effect ( see http://www.lightstreamer.com/docs/cl...hRequests(int) )

From any other perspective to have 10 mono-item tables or to have one table with 10 items is exactly the same.

2
on the current Java SE client the TableInfo objects are very simple descriptor objects; there is no problem if you share the same schema String with more than one TableInfo. (did you mean something else?)

3
we usually try to make the examples as readable as possible, no need to initialize objects that way.

4
sorry I didn't point to it previously, but is probably better to look to an example to understand COMMAND mode.
If you open http://www.lightstreamer.com/demo/PortfolioDemo_Basic/ you'll see a table. That table is generated by one single item.
This item has two special fields, key and command; using the appropriate values of key and command it is possible to add/remove/update all the rows in that COMMAND table.

Now if you open http://www.lightstreamer.com/demo/PortfolioDemo/ you'll see again a COMMAND table driven by one single item, but there is a difference this time. Each time an ADD command is received by the said item a new MERGE subscription is made using the key field as item name and a configured subschema as schema. In this case each time an add is received a subscription to the items of the StockListDemo is made.

(Note: some clients handle this 2-level push automatically, while others, like the JAVA SE one, do not so that the second-level-subscription logic has to be implemented in the client code).
Let me know if something is unclear

[subuta]

Thank you for all of this information. I will think about it carefully, and study the examples you have suggested.

-Dan