Table.onEndOfSnapshot not being called

[DarioCrivelli]

I have found an error in our distribution process,
so the predeployed portfolio demo jars were not updated after the abovementioned fix.
However, the copies of the same jars under
DOCS-SDKs\sdk_adapter_java\examples\Portfolio_Adapters\ Deployment_LS\Portfolio\lib
did get updated.
Hence, you can refresh the two jars in adapters\Demo\portfolio\lib with the corresponding ones under the DOCS-SDKs tree.

[jweber]

Thanks! That did the trick. And to correct my last post, this wasn't happening with my own adapters; I was just using the Portfolio adapters with my own JavaScript. So problem solved.

[jweber]

One more question on this topic. That onEndOfSnapshot function gets called when the main table's snapshot is finished, which is when all rows have been added to the table. But at that point, the rows are mostly empty.

As I understand it, each row gets its own subscription, and its own snapshot. So after onEndOfSnapshot is called, you'll get an update for each row, with a CHANGE command, and itemUpdate.isSnapshot set to true.

What's the best way to detect when all of those snapshots have been received? I'd like to know when the table is fully populated with data, not just when it has the names of all the row items. I can think of two ways:

1) Look for the first update where isSnapshot is false. This seems to only happen after all of the rows' snapshots have been received, but I'm not sure whether that's guaranteed to be the case. Also, this means you have to wait for the first non-snapshot update before you can know that the snapshot is done.

2) Count the number of rows that were ADDed, and wait until you get an UPDATE with isSnapshot=true for each one. This seems more reliable, although it involves more work on the client side.

Or is there a way to listen for the onEndOfSnapshot for each individual row's table?

Thanks,
Jacob

[DarioCrivelli]

You are referring to a MultiDynaMetapushTable, which implements two level push.
Indeed, the onEndOfSnapshot notice refers to the first level,
i.e. the COMMAND mode item that governs the table structure;
if there is any custom operation that you have to perform anytime the table structure changes,
this lets you know when the table initial population has completed,
so that you can perform your custom operation only once in the population phase.

However, no notification is available when the table contents are completely filled.
Note that a normal OverwriteTable made of multiple lines also lacks this information.

Your analysis is correct. Technique number 2 can be used, whereas there is no guarantee that technique number 1 will work.
onEndOfSnapshot for the individual rows is not provided, as the second level items are always subscribed to in MERGE mode, hence referring to the isSnapshot method is enough.
Admittedly, the documentation for isSnapshot is not clear enough for the MultiMetapush case and will be expanded. However, the method behaves as you described.

[jweber]

Dario -- thanks again for all your help.

[Cerogil]

Have a few questions related to the end of snapshot / whether all of the data has been pushed:

1) It looks like the only functional difference between onEndOfSnapshot and OnSnapshotEnd (Lightstreamer .NET Client version) is the removal of itemPos. Is this correct? Do they essentailly provide the same functionality?

2) The onEndOfSnapshot (using COMMAND) only seems to trigger when a client first makes a connection to Lightstreamer. If it is a new subscription, it triggers before any of the items are sent. If it the subsciption is being reused, it triggers after all of the items are sent. This is because the snapshot is only data that has accumulated before subscription time, yes?

3) So is there a way to tell when all of the items an adapter is passing to a client have been recieved? The onEndOfSnapshot seems to work ONLY if the subscription had already been made and only on init (not for any updates). This answer was unclear from the previous post since a two level push was used and this is just referring to the 'one level push'. An alternative would seem to be to have Lightstreamer send the number of upcoming pushes beforehand and then do a count on the client side.

Thanks.

[DarioCrivelli]

1) It looks like the only functional difference between onEndOfSnapshot and OnSnapshotEnd (Lightstreamer .NET Client version) is the removal of itemPos. Is this correct? Do they essentailly provide the same functionality?

Yes.
About itemPos, it is always supplied; in some overloads the item name is not available.

2) The onEndOfSnapshot (using COMMAND) only seems to trigger when a client first makes a connection to Lightstreamer. If it is a new subscription, it triggers before any of the items are sent. If it the subsciption is being reused, it triggers after all of the items are sent. This is because the snapshot is only data that has accumulated before subscription time, yes?

As you correctly point out, the snapshot is only data that has accumulated before subscription time.
However, the Data Adapter, upon subscription, can initially send some events and declare them as part of the snapshot, by leveraging the isSnapshot flag in update or smartUpdate. This is probably not the case with your Data Adapter.

3) So is there a way to tell when all of the items an adapter is passing to a client have been recieved? The onEndOfSnapshot seems to work ONLY if the subscription had already been made and only on init (not for any updates). This answer was unclear from the previous post since a two level push was used and this is just referring to the 'one level push'. An alternative would seem to be to have Lightstreamer send the number of upcoming pushes beforehand and then do a count on the client side.

If, by saying "when all of the items an adapter is passing to a client have been recieved" you still refer to the snapshot, then the previous point gives you the answer.
If you refer to a custom set of keys that are expected to come as real-time updates, then the notification of the set completion can only be handled at application level.