I have two legacy systems, both on different domains. Eventually, I will need to send messages between the two domains. For now, I am using a simple "Hello World" example but starting the DataWriter and DataReader on different domains, on the same Linux workstation. In between, I have the routing service, directing the publisher's topic to the subscriber's domain and topic. For QoS, I have StrictReliability selected but with the default VOLATILE durability. This setup works fine except for the fact that the discovery / connection process takes up to 10 seconds during which time, messages are lost.
I have attempted to remedy the situation by changing the durability to either TRANSIENT_LOCAL_DURABILITY_QOS or TRANSIENT_DURABILITY_QOS. With either setting for both the DataWriter and DataReader, the DataReader complains:
PRESPsService_isRemoteWriterLocalReaderCompatible: incompatible durability: writer 0 reader [1,2]
where the reader's value of 1 or 2 depends on whether the former or latter setting is used. However, the Reader and Writer connect up beautifully if they begin on the same domain. The problem only occurs when the participants are on different domains with the routing service in between. Is there some reason why I cannot have a durable connection over the routing service?
I am using RTI Connext 5.3.1 for legacy compatibility.
Thank you in advance for your help,
Alan
For this to work, you'll have to configure Routing Service's DataReader (to receive Durable data from your publishing app in it's domain) and DataWriter (to send Durable data to your subscribing app it it's domain) with the Durability Qos turned on. You only need to use TRANSIENT_LOCAL unless you are planning to use RTI Persistence Service to store the durable data.
Thank you, Howard. I have been trying to do as you suggested, but I haven't discovered how to change the routing service's DataReader and DataWriter to use TRANSIENT_LOCAL durability. I have only been able to change the incoming published data's QoS and the outgoing data's QoS, which still leaves me with a disconnect in the routing service. The DataReader in the routing service is still expecting volatile durability. I have tried to add TRANSIENT_LOCAL durability into the USER_ROUTING_SERVICE.xml with no luck. If you can point me to a workable example, I would really appreciate it.
Thanks,
Alan
So, here's a snippet. The best practice is to start with a BUILTIN QosProfile that sets up what you need and then customize if required.
<session name="Session1">
<auto_topic_route name="AllForward">
<publish_with_original_info>true</publish_with_original_info>
<input participant="1">
<allow_topic_name_filter>*</allow_topic_name_filter>
<allow_registered_type_name_filter>*</allow_registered_type_name_filter>
<deny_topic_name_filter>rti/*</deny_topic_name_filter>
<creation_mode>ON_DOMAIN_AND_ROUTE_MATCH</creation_mode>
<datareader_qos base_name="BuiltinQosLibExp::Generic.KeepLastReliable.TransientLocal"/>
</input>
<output>
<allow_topic_name_filter>*</allow_topic_name_filter>
<allow_registered_type_name_filter>*</allow_registered_type_name_filter>
<deny_topic_name_filter>rti/*</deny_topic_name_filter>
<creation_mode>ON_DOMAIN_AND_ROUTE_MATCH</creation_mode>
<datawriter_qos base_name="BuiltinQosLibExp::Generic.KeepLastReliable.TransientLocal"/>
</output>
</auto_topic_route>
</session>
You probably will want to modify the <history><depth> QOS parameter to configure how much data needs to be durable.
Thank you, Howard. This auto_topic_route was exactly what I needed. I was trying to use a domain_route and it never connected.
Hmm, a domain route should have also worked...but you do need to modify the datareader_qos for the input and the datawriter_qos for the output of the route appropriately. Glad it is now working.