How to get list of fields subscribed using the In-Process adapter API?

rohan

Hello everyone!
When creating a subscription from the browser JS client, we supply a list of items and the fields we're interested in.
But the SmartDataProvider#subscribe method only gives us the item subscribed to, not the list of associated fields.
How does one get them?

Thanks

Dario Crivelli

Hello. This decoupling between the Data Adapter and the activity of the single clients is intentional.
The Data Adapter only manages items, whose fields only depend on the item characteristics.
In this way, multiple client subscriptions can share the same server-side "subscribe" invocation to the Data Adapter.

The client activity is available on the Metadata Adapter (see notifyNewTables).
If you want to modulate the Data Adapter activity based on the current client activities you should have the two adapters communicate at application level.
Alternatively, you should do without subscription sharing and define different items (by using different item names) when the involved field set is different.

rohan

Hi Dario, thanks for replying

>> multiple client subscriptions can share the same server-side "subscribe" invocation to the Data Adapter
Thanks for establishing this.
I tried an example, where multiple clients subscribe for the same item and it gave only one callback on the server-side DataAdapter, this is expected right?
I think my observation is wrong since the doc on SmartDataAdaptersays " Lightstreamer Kernel always uses different handles across subsequent subscriptions of the same item"
If it's right that would mean we publish ALL relevant fields of this item via the ItemEventListener and the kernel figures it out as to what client wants what field? (C1 wanting F1,F2; C2 wanting F3, F4 and we send F1,F2,F3,F4 via the listener) Is that correct?

>> you should do without subscription sharing and define different items (by using different item names) when the involved field set is different
But isn't it that usual for multiple clients to subscribe to same item (stock tick say "GOOGL") but with a different field set?
One app being interested in certain aspects of the item and the other on some other aspects?

There's another behaviour that I came across which I didn't expect:
Let's assume we have multiple instances of our webapp using the same LS backend

Client C1 subscribes for item X first, dataAdapter gets a subscribe callback and it gets the item event update U
Now client C2 (on different host) also subscribes for item X with same field set, but since the item name is same, the subscription is shared and hence dataAdapter doesn't get a callback for C2, hence C2 gets no fields?
In this case as well, do I need to use one of the MetadataAdapter's method calls to send C2 the same update U? Does kernel keep the last update for an item X?

Thanks

Dario Crivelli

Hi Rohan,
Yes, subscription sharing works as you have resumed.

What you found in the SmartDataAdapter documentation and turned out to be deceiving refers to a different aspect, that is, to subsequent invocations of "subscribe" due to the fact that the first invocation was later followed by "unsubscribe". In fact, if all clients that share the same item subscription should unsubscribe, the unsubscription would also be propagated to the Data Adapter. Then a new client may cause a new subscription.

Whether or not a single item should be defined to cover all client requests for some entity is left to the implementation.
We thing we have left enough degrees of freedom to let the implementer organize this aspect.

About the last question:
Lightstreamer sends real-time data, hence if C2 subscribes after U has occurred, U is now a past event and C2 should not receive it. If later the Data Adapter produces a U2 event, it will be sent to both C1 and C2.
However, we also manage the "snapshot", which is the current state of the item. If C2 subscribes and asks for the snapshot, it should receive U as the snapshot and the kernel takes care of this.
The concept of snapshot lends itself to various definitions. Please see paragraph 3.4.1 in the General Concepts document for details.

rohan

Thank you soo much Dario!