OpenSplice - unprocessed topics PreviousNext
Data Distribution Service (DDS) Forum > DDS Technical Forum >
Next message Jonathan  posted on Wednesday, January 27, 2010 - 03:51 pm
If you take the OpenSplice Community Edition chatter as an example.

When sending out messages (Chatter), if you change the Sleep() delay to say 10ms, not all topics will be received by the MessageBoard.

Even reducing the Sleep() in MessageBoard, eventually it will start losing topics.

I tried creating a DataReaderListener as well but this had the same problem. Checked with Wireshark and the packets were all received, just not 'processed'.

What is the reason for this? Is some buffer getting full and not getting emptied quick enough?

I'm sure it's something silly I'm overlooking.

Next message Hans van 't Hag  posted on Wednesday, January 27, 2010 - 05:18 pm
Hi Jonathan,

You're actually not loosing topics, you're overwriting topic-samples in the reader's cache since a history-depth of 1 is used in the example.

Something that could go by unnoticed easily is that unlike typical ‘messaging’ middleware, DDS is much more like a distributed database in the sense that a dataReader cache is organized like a database where arriving data (samples) are inserted (in this case following successful reliable delivery) according to their KEY attributes (where a KEY is a list of zero or more topic-type attributes who’s values uniquely identify samples of an ‘instance’ of that topic).

In DDS, key-fields are identified already in the IDL-file that defines the types that are used as topics. Now, when you look at the Chat.idl code of the chatroom tutorial, you’ll notice that there’s only one attribute used as a key-field which is the userID. This is done to separate chat-messages from multiple chatters so that they’ll be stored at different locations (would be ‘rows’ in a regular database and are called ‘instances’ in DDS terminology) in the dataReader’s cache. Now here’s whats happening when you remove the ‘sleep’ in the Chatter: you’ll write the 10 samples very very fast and very likely so fast that the MessageBoard applications doesn’t even get a chance to see them all arriving as they are all inserted at the same location in the dataReader’s cache and therefore ‘overwrite’ each other upon arrival. This is very typical of ‘any’ database, i.e. new data will replace old(er) data. If that’s unexpected, then the good news is that there’s also something like the HISTORY QoS-policy (of dataReaders in this case) which allows you to specify how many ‘historical’ samples should be preserved i.e. very much like a ring-buffer or ‘queue’ that will hold the ‘n’ newest samples rather than just the single newest sample (which is tied to the default HISTORY_DEPTH value of 1). You could even specify a KEEP_ALL history policy for a dataWriter which would imply a end-to-end frequency coupling between publishers and subscribers which is typically something you don’t want as the ‘decoupling in space and time’ is one of the ‘driving concepts’ behind the DDS specification.

So what you’re experiencing is the separation of ‘delivery’ and ‘storage’ of information (which is very similar to the ‘real-world’ where you can ask for reliable/acknowledged delivery of a letter to be mailed, yet which doesn’t imply that once delivered, the letter will be actually read by the recipient J)

You might want to check-out the mailing-list thread on OSPL RELIABILITY that explains the above in great detail, see ?hl=en#
Next message Jonathan  posted on Thursday, January 28, 2010 - 09:14 am
Thanks for your explanation, it cleared that up. I'll head over to the OSPL group in future.

Thanks very much for your time.
Back to top
Add Your Message Here
Username: Posting Information:
This is a private posting area. Only registered users and moderators may post messages here.
Options: Post as "Anonymous"
Enable HTML code in message
Automatically activate URLs in message