Jump to content
OpenSplice DDS Forum
ray_t

instance handles beginner question

Recommended Posts

Hello

I'm trying out OpenSplice community using Java5, particularly instances. I'd like to clear up some confusion that I have, but just can't figure it out.

C_System instance = new C_System();
instance.A_sourceID.A_resourceId = 250;

InstanceHandle instanceHandle1 = writer.registerInstance(instance);

try { Thread.sleep(2000); } catch (InterruptedException e) { e.printStackTrace(); }

InstanceHandle instanceHandle2 = reader.lookupInstance(instance);

assert(instanceHandle1.equals(instanceHandle2)); // FAILED

I was wondering, shouldn't the instance handle after looked up by the reader, be equal to the one registered by the writer?

What I'm trying to achieve is I have a DataReader (reading all instances), and at some later point I would like to figure out which of the instances are still registered (Some of them might have been disposed by the writers). For that I would like to check if they can be looked up by the readers, but I can't even get the simple case above working.

Thanks for your time.

-Reinhard

Share this post


Link to post
Share on other sites

instance-handles are 'local constructs' so can't be shared/looked-up remotely.

Instance-awareness doesn't require any notion/knowledge of handles as you can/will be notified about liveliness-changes and/or can query for alive/not-alive/disposed instances.

Share this post


Link to post
Share on other sites

Hi Reinhard,

What Hans is trying to say is that instance handles are always local to the Entity in which they operate, so if I have two readers subscribing to the same topics, their instance handles will be different even when expressing the same instances. Try to see the instance handle as kind of a pointer into the reader administration: although both readers will have a replicated store, they manage their own instance tables and therefore have their own handles. That is why the content of one Reader is left untouched when you take data out of the other Reader. Likewise, the instance handles from the Writer side are separate from those on the Reader side.

I don't really understand your usecase though: why do you need to know the instance handle of an instance to determine whether it is still registered? The instance lifecycle state can tell you exactly that without having to resort to its handle: if its instance_state is still ALIVE, it is still registered.

Regards,

Erik Hendriks.

Share this post


Link to post
Share on other sites

First, thanks for your quick and informed replies. I had a wrong assumption about instance handles, thought of them as something like a domain wide managed handle for instances.

Instance_state is what I'm after. So my revised plan would be:

reader reads (not takes!) the instances in the data_available callback

at some point when one of the instance writers goes down, I get notified with the reader's liveliness_changed callbaclk

at this point, I read the instances once again to check which ones are still alive using sample.instance_state.

I hope I'm on the right track with that.

Thanks again and best wishes

-Reinhard

Share this post


Link to post
Share on other sites

Hi Reinhard,

I guess you want to read ALIVE data, but take NOT_ALIVE data as to release the resources from instances that will no longer be updated? If that is indeed the case, why not simply do the read call using the ALIVE instance_state mask, followed by a take call using the NOT_ALIVE mask in your data_available_callback?

Regards,

Erik Hendriks.

 

Share this post


Link to post
Share on other sites

Hi Erik,

my plan was to update a user interface to see as a direct feedback when a writer/instance goes down, I think the event of the writer going down would not trigger data_available.

I hope I can do exactly as you suggest in the liveliness_changed though, while still using ANY in data_available. Will be trying that next!

Thanks -Reinhard

Share this post


Link to post
Share on other sites

Hi Reinhard,

The data_available callback will trigger on any incoming update, so either on an incoming sample or on an instance lifecycle event. That means that you don't need an additional triggering event to catch the NOT_ALIVE events, and you can handle both the samples and the instance state changes in the same callback.

Regards,

Erik Hendriks.

Share this post


Link to post
Share on other sites

Great, that makes it really easy. Thanks a lot this has been a really helpful discussion.

I'll drop a quick line once I got everything working :D

Best wishes - Reinhard

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...