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)