Jump to content
OpenSplice DDS Forum
Karl Bube

Only samples with lowest topic key value are published

Recommended Posts

I have created a topic that includes a source and destination ID.  The intent is to uniquely identify the source and destination components of each sample.  Both the source and destination IDs are defined as keys for the topic.

 

As I understand it, each unique pairing of source and destination ID should define a unique instance.  So, if source component 1 publishes a sample with a destination ID of 10 then publishes a second sample with a destination ID of 20, this creates two separate instances within the DDS domain, one with a key of (1,10) and the second with a key of (1,20).  At that point, the source component should be able to publish multiple samples to each instance.

 

The problem I'm encountering is that only samples with the lowest-valued destination ID seem to be published.  The source can start publishing samples with a key of (1,20) but once it publishes a sample with a key of (1,10) only those samples are published, it can no longer publish samples with a key of (1,20).

 

The DataWriter::write() calls in the source component always return DDS::RETCODE_OK.  So, the writes appear to succeed.

 

I've verified this behavior using a subscriber that I implemented and by using the OpenSplice Tuner.  Both show the same behavior.

 

I've tried publishing samples to three destination IDs and always only the sample with the lowest key value is published.  The order doesn't seem to matter. However, I have noticed that the first sample of each instance is always published.

 

Publish to (1,30) --> Tuner sees the sample

Publish to (1,30) --> Tuner sees the sample

Publish to (1,30) --> Tuner sees the sample

Publish to (1,10) --> Tuner sees the sample

Publish to (1,30) --> Tuner DOES NOT see the sample (will no longer see samples with key of (1,30)

Publish to (1,10) --> Tuner sees the sample

Publish to (1,30) --> Tuner DOES NOT see the sample

Publish to (1,10) --> Tuner sees the sample

Publish to (1,30) --> Tuner DOES NOT see the sample

Publish to (1,20) --> Tuner sees the sample (only first sample of this new instance is visible to the Tuner)

Publish to (1,10) --> Tuner sees the sample

Publish to (1,30) --> Tuner DOES NOT see the sample

Publish to (1,20) --> Tuner DOES NOT see the sample

Publish to (1,10) --> Tuner sees the sample

Publish to (1,30) --> Tuner DOES NOT see the sample

 

This doesn't make any sense to me.  Am I misunderstanding something fundamental about topic keys and instances?  Is there some way that topic QoS could be causing this?  I'm using the default QoS and OpenSplice 6.5.

Share this post


Link to post
Share on other sites

I also verified that I get the same behavior using the Tuner to publish data samples.  I run two instances of the Tuner:  one to read topic samples and one to write samples.  If I start by publishing to (1,30) then publish to (1,20) the writer can no longer publish to (1,30); i.e. the Tuner setup to read samples sees the initial samples with the (1,30) key then sees the samples with the (1,20) key but never again sees samples published with the (1,30) key.

 

Seems like something odd about the topic definition, keylist, or QoS, but I don't know what would cause this type of behavior.

Share this post


Link to post
Share on other sites

This was a configuration error on my part.

 

After installing OpenSplice 6.5.0, I did notice that starting the daemon (ospl start) would output the error message, “ddsi2: error while loading shared libraries: libssl.so.10: cannot open shared object file: No such file or directory”.  I initially ignored this issue, thinking that it only secure networking would be affected, which I didn't care about.  Plus, things seemed to be working fine – I could successfully run a common, end-to-end functional test on our system.

 

Obviously, things were not working fine.  After installing libssl on my system, everything is now working as I would expect.  The issue is resolved.  I obviously shouldn’t have ignored that installation issue in the first place, but this was a rather odd way for the issue to manifest.  Live and learn.

 

To be clear, I installed libssl-dev on my Ubuntu system, which installed libssl.so.0.9.8 and libcrypto.so.0.9.8 into /lib.  I then created symbolic links in /lib for libssl.so.10 and libcrypto.so.10,which were the specific shared libraries mentioned in the error messages.  That seemed to satisfy the OpenSplice daemon, as it now starts without error.  Is that a satisfactory solution, or should I be installing a different version of the SSL libraries in a different fashion?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×