Group presentation and ReadCondition

We are working on the component based architecture using RTI DDS as a middleware.  Our component is defined by the domain ID and its domain participant. Every component has a single participant that creates one subscriber and one publisher. Subscriber can create many data readers and publisher can create many data writers. On the receive side, our component is using wait sets. Subscriber part of the component creates a single receiver thread used by all readers. Every reader has a condition that we use for triggering wait set when new data arrives. We started by using status condition for this purpose, but because of some problems (not related to the problem described in this post), we changed our implementation to be based on the read condition.  We would like to use Presentation policy in order to insure the right order of samples. For that purpose, we use Group presentation and ordered access. But, then we have experienced some strange behavior.

 Our application creates all DDS entities with the according QoS policy. As described in the documentation, we use Group Presentation policy for both publisher and subscriber. At the moment, we are experimenting with only one topic. We create a read condition for this topic at the same time when we create a data reader, but we do not immediately attach it to the waitset. We use the following parameters for creating the read condition:

        m_Condition = m_Reader->create_readcondition(DDS_NOT_READ_SAMPLE_STATE, DDS_ANY_VIEW_STATE, DDS_ANY_INSTANCE_STATE);

 The scenario is then

1. We write a sample on our topic
2. We attach the read condition to the waitset

We would then expect that the waiset is triggered right away. We are using TRANSIENT_LOCAL durability and RELIABLE reliability. But this does not happen right away, the waitset seems to be triggered after an arbitrary time ranging from around 10 to 60 seconds.

 If we instead use topic presentation the problem disappears, and the waitset is triggered right away.

 If we use status condition instead of read condition the problem also disappears and the waitset is triggered right away. But as previously mentioned this is not currently an option for us (see above).

 If we attach the read condition before writing the first sample, we get the update immediately after writing the sample.

 From all tests that we have made, the problem seems to be that the read condition is not triggered, or that the trigger is severely delayed.