DataReader.lookup_instance returning nil

4 posts / 0 new
Last post
Offline
Last seen: 5 years 2 days ago
Joined: 10/01/2015
Posts: 17
DataReader.lookup_instance returning nil

Is DataReader.lookup_instance supposed to work with keys that have not been received by the reader yet?

I would like to use lookup_instance at the start of my application to cache InstanceHandle's for future calls to read_instance.  lookup_instance is returning a nil handle if it has not received data for that instance yet.

If that is correct behavior of lookup_instance, is there another way to get an InstanceHandle for a key?

Juanjo Martin's picture
Offline
Last seen: 1 year 7 months ago
Joined: 07/23/2012
Posts: 48

Hi Seymour,

The documentation associated with lookup_instance is here. For your reference, it says:

If the instance has not been previously registered, or if for any other reason the Service is unable to provide an instance handle, the Service will return the special value DDS_HANDLE_NIL.

Can you please elaborate further about your use case? Isn't it enough with just calling read_instance after lookup_instance once you know that for sure the instance is already received in the DataReader? I don't think that this will add a lot of overhead to your implementation.

Thanks,
Juanjo Martin

 

Offline
Last seen: 5 years 2 days ago
Joined: 10/01/2015
Posts: 17

Thanks for responding.

I did not understand the bit about registering the instance, as readers don't register instances.

My application is configured with a set (more than 1, less than the total) of keys that it cares about on a topic, and will periodiclly poll each instance for the latest sample.  It's not overhead, just coding convenience and keeping my main loop clean, to calculate and cache the InstanceHandles for each.  Instead, in the main loop, I'll need to check if it's seen that key before, and call lookup_instance before read_instance. 

I'm under the impression that the InstanceHandle is derived from (a hash of) the key values only, and not any other state, which makes it seem like this is somthing that should be possible.  But I may be mistaken about this.

Offline
Last seen: 2 months 2 weeks ago
Joined: 02/11/2016
Posts: 144

Hey Seymour,

I can only guess that the reason you get a null for an instance that has not been received before is to avoid confusion for users (that would give a good indication of whether a certain instance is being actually handled or not, as opposed to just telling you the result of some hash fucntion).

Regarding the methodology of keeping your code clean and lean, I feel that instead of periodically trying to poll ALL of the possible keys it's better to use some set and update it when new instances are "detected".

One way to detect new instances would be using a data reader listener, although I leave it up to the RTI team to say whether they think it would work well for his case and if so, link you to some explanation of how to set it up.

One benefit you could gain from using a listener would be that when instances are no longer being updated / used, you can also receive a notification (granted that you use unregister or dispose on them from the writer side) allowing you to stop polling them.

 

Another option i could think of is simply polling your reader with a generic instance handle and then looping over everything that was updated between consecutive polls.

 

Another approach would be to avoid polling and instead use a listener to be notified when new data is available (although this can be tricky to do right).

 

I hope this helps,

Roy.