Hi,
I created two duplicates of the "defaultbothways" routing service from the default Routing Service configuration file, to simulate this configuration (within the same config file);
With the domain_routes of each service containing the participants [P1: domain 6, P2: domain 0] and [P1: domain 5, P2: domain 0] respectively.
When a publisher on domain 6, a subscriber on domain 5, and the two routing services are running (all on the same box), the data isn't being routed to the subscriber.
However, if I start a subscriber on domain 0 then the subscriber on domain 5 starts receiving (routing from 6 to 0 works regularly)
Regards,
Chris
Hi Chis,
If I got this right you are copying one of the configurations found on the RTI_ROUTING_SERVICE.xml file that is shipped, specifically the one that is defined in the tag:
If this is the case what you are seeing is what is expected from that configuration. The routes in that configuration define inputs and outputs with the "creation mode" ON_DOMAIN_AND_ROUTE_MATCH.
This means that for the route to be created inside the routing service it has to have first discovered the producer of the data in one of the domains and the corresponding consumer in the other domain. This configuration is used to avoid unnecessary work in the routing service so that it does not receive data that it has nowhere to forward.
This will work just fine a situation where you have a single routing service in play. But it gets trickier in the situation where you chain multiple domains as you have in your picture:
Domain 6 <=> [RS1] <=> Domain 0 <=> [RS2] <=> Domain 5
The situation that you observed "works" does so because as soon as you create a Publisher in Domain6 and a Subscriber in Domain0 then RS1 sees the producer and consumer on both domains and creates the route. Then as soon as you create the subscriber in Domain5 RS2 also sees the producer in one domain (Domain0--this is the producer created by RS1) and the consumer in the other domain (Domain5) and also creates the route.
The original situation that "does not work" is explained by the fact that if you only create a Publisher in Domain6 and a subscriber in Domain5 then RS1 does not see a consumer in Domain0 so it does not create the route, and similarly RS2 does not see any producer in Domain0 so it also does not create the route.
To handle these chains of routing services you have to configure some of the routing services to create routes more "aggresively" even if they have not found the full match. For example you can configure the routes in RS1 to have creation mode ON_DOMAIN_OR_ ROUTE_MATCH.
With this configuration as soon as you create the publisher on Domain6 the route will be created in RS1. This will cause RS1 to create the DataWriter in Domain0 and this and the presence of the subscriber in Domain5 will cause the route in RS2 to also be created.
You can read more about creation modes in Section 2.4.6.4 of the RTI Routing Service User's Manual.
Gerardo
Hi,
I’m having problems in a similar scenario so I hope it’s ok if I’m posting here instead of creating a new thread.
In my scenario, there are four DDS domains (1, 2, 3 and 4). All publishers and subscribers for domains 1 e 2 are running on a server whose IP address is 10.100.201.138, while publishers and subscribers for domains 3 and 4 are running on a second server (IP address 10.100.201.69)
Two routing services are running, one on each machine.
The routing service on 10.100.201.138 defines the following bidirectional routes:
Domain 1 – domain 2
Domain 1 – domain 3
Domain 1 – domain 4
Domain 2 – domain 3
Domain 2 – domain 4
The other, running on 10.100.201.69, only defines the remaining route between domains 3 and 4
What I noticed is that sometimes (unfortunately, I have not been able yet to recognize a clear pattern in the correct/incorrect behavior of the system) samples are lost on routes between domains that run on different machines, but only in one direction, specifically when the sample is published from 10.100.201.69.
So, for example, a sample published from domain 3 is always received by a subscriber in domain 4 (both on 10.100.201.69), but it is sometimes not received by subscribers in domains 1 and 2, which run on the other machine (which, not coincidentally, I guess, is the machine on which the routing service defining those routes is running)
What is even stranger is that there are two topics involved, with an identical qos configuration, but only one topic (AllegatoMsg) is experiencing problems.
There is no specific creation mode configuration, so it should default to IMMEDIATE.
For further information:
SimoMsg subscribers are instantiated on startup by a Java application.
AllegatoMsg subscribers are instantiated on startup by a web application running on Tomcat as a Windows service.
Publishers for both topics are instantiated (by the Java app and the web app respectively) on demand, that is when the first sample needs to be sent.
Any idea of a possible cause? Maybe something concerning producer/consumer discovery? Is there a configuration that guarantees the creation of all the routes on routing service startup?
Or should I choose a different configuration for this scenario?
This is a snippet from the routing file configuration, showing the domain route 1-3 definition. All the other routes are defined likewise.
<?xml version="1.0"?>
<dds xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="../../resource/schema/rti_routing_service.xsd">
<routing_service name="Simo_RS">
…
<domain_route name="DomainRoute_1_3" enabled="true">
<participant_1>
<!-- Internal domain -->
<domain_id>1</domain_id>
<participant_qos base_name="QosLibrary::BaseParticipant" >
<property>
<value>
<element>
<name>dds.transport.UDPv4.builtin.parent.allow_interfaces_list</name>
<!-- INSERIRE SOTTORETE -->
<value>10.100.201.138</value>
</element>
</value>
</property>
</participant_qos>
</participant_1>
<participant_2>
<!-- External domain -->
<domain_id>3</domain_id>
<participant_qos base_name="QosLibrary::BaseParticipant">
<discovery>
<initial_peers>
<!-- INSERIRE IP MACCHINA -->
<element>builtin.udpv4://10.100.201.69</element>
</initial_peers>
<multicast_receive_addresses>
</multicast_receive_addresses>
</discovery>
</participant_qos>
</participant_2>
<session name="Inbound" enabled="true">
<topic_route name="Message">
<route_types>true</route_types>
<publish_with_original_info>true</publish_with_original_info>
<input participant="2">
<registered_type_name>SimoMsg</registered_type_name>
<topic_name>SimoMessage</topic_name>
<datareader_qos base_name="QosLibrary::SimoProfile" />
<!-- FILTER: route accepts only samples whose recipient domain = 1 -->
<content_filter>
<expression>domainIdDest = 1</expression>
</content_filter>
</input>
<output>
<registered_type_name>SimoMsg</registered_type_name>
<topic_name>SimoMessage</topic_name>
<datawriter_qos base_name="QosLibrary::SimoProfile" />
</output>
</topic_route>
<topic_route name="Allegato">
<route_types>true</route_types>
<publish_with_original_info>true</publish_with_original_info>
<input participant="2">
<registered_type_name>AllegatoMsg</registered_type_name>
<topic_name>Allegato</topic_name>
<datareader_qos base_name="QosLibrary::AllegatiProfile" />
<!-- FILTER: route accepts only samples whose recipient domain = 1 -->
<content_filter>
<expression>domainIdDest = 1</expression>
</content_filter>
</input>
<output>
<registered_type_name>AllegatoMsg</registered_type_name>
<topic_name>Allegato</topic_name>
<datawriter_qos base_name="QosLibrary::AllegatiProfile" />
</output>
</topic_route>
</session>
<session name="Outbound" enabled="true">
<topic_route name="Message">
<route_types>true</route_types>
<publish_with_original_info>true</publish_with_original_info>
<input participant="1">
<registered_type_name>SimoMsg</registered_type_name>
<topic_name>SimoMessage</topic_name>
<datareader_qos base_name="QosLibrary::SimoProfile" />
<!-- FILTER: route sends only samples whose recipient domain = 3 -->
<content_filter>
<expression>domainIdDest = 3</expression>
</content_filter>
</input>
<output>
<registered_type_name>SimoMsg</registered_type_name>
<topic_name>SimoMessage</topic_name>
<datawriter_qos base_name="QosLibrary::SimoProfile" />
</output>
</topic_route>
<topic_route name="Allegato">
<route_types>true</route_types>
<publish_with_original_info>true</publish_with_original_info>
<input participant="1">
<registered_type_name>AllegatoMsg</registered_type_name>
<topic_name>Allegato</topic_name>
<datareader_qos base_name="QosLibrary::AllegatiProfile" />
<!-- FILTER: route sends only samples whose recipient domain = 3 -->
<content_filter>
<expression>domainIdDest = 3</expression>
</content_filter>
</input>
<output>
<registered_type_name>AllegatoMsg</registered_type_name>
<topic_name>Allegato</topic_name>
<datawriter_qos base_name="QosLibrary::AllegatiProfile" />
</output>
</topic_route>
</session>
</domain_route>
…
</routing_service>
</dds>
This is the qos configuration, identical on both machines, except for the specific IP address:
<?xml version="1.0"?>
<dds xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="C:/rti5.1.0/ndds.5.1.0/scripts/../resource/rtiddsgen/../qos_profiles_5.1.0/schema/rti_dds_qos_profiles.xsd"
version="5.1.0">
<!-- QoS Library containing the QoS profile used in the generated example.
A QoS library is a named set of QoS profiles. -->
<qos_library name="QosLibrary">
<qos_profile name="BaseParticipant">
<participant_qos>
<transport_builtin>
<mask>UDPv4</mask>
</transport_builtin>
<discovery>
<initial_peers>
<element>builtin.udpv4://</element>
<element>127.0.0.1</element>
</initial_peers>
<!-- Note multicast receive address is nulled out -->
<multicast_receive_addresses />
</discovery>
<discovery_config>
<participant_liveliness_assert_period>
<sec>2</sec>
<nanosec>0</nanosec>
</participant_liveliness_assert_period>
<participant_liveliness_lease_duration>
<sec>5</sec>
<nanosec>0</nanosec>
</participant_liveliness_lease_duration>
<max_liveliness_loss_detection_period>
<sec>5</sec>
<nanosec>0</nanosec>
</max_liveliness_loss_detection_period>
</discovery_config>
<property>
<value>
<element>
<name>dds.transport.UDPv4.builtin.parent.allow_interfaces_list</name>
<!-- INSERIRE IP DELLA MACCHINA/SOTTORETE -->
<value>10.100.201.138</value>
</element>
</value>
</property>
</participant_qos>
</qos_profile>
<qos_profile name="MonitoredParticipant" base_name="BaseParticipant">
<participant_qos>
<property>
<value>
<element>
<name>rti.monitor.library</name>
<value>rtimonitoring</value>
</element>
<element>
<name>rti.monitor.create_function</name>
<value>RTIDefaultMonitor_create</value>
</element>
<element>
<name>rti.monitor.config.skip_monitor_entities</name>
<value>false</value>
</element>
</value>
</property>
</participant_qos>
</qos_profile>
<qos_profile name="SimoProfile" base_name="BuiltinQosLibExp::Pattern.Event">
<datawriter_qos>
<publication_name>
<name>SimoWriter</name>
</publication_name>
<publish_mode>
<kind>ASYNCHRONOUS_PUBLISH_MODE_QOS</kind>
<flow_controller_name>DDS_FIXED_RATE_FLOW_CONTROLLER_NAME</flow_controller_name>
</publish_mode>
<durability>
<kind>TRANSIENT_LOCAL_DURABILITY_QOS</kind>
</durability>
<history>
<kind>KEEP_LAST_HISTORY_QOS</kind>
<depth>1</depth>
</history>
</datawriter_qos>
<datareader_qos>
<subscription_name>
<name>SimoReader</name>
</subscription_name>
<durability>
<kind>TRANSIENT_LOCAL_DURABILITY_QOS</kind>
</durability>
<history>
<kind>KEEP_LAST_HISTORY_QOS</kind>
<depth>1</depth>
</history>
</datareader_qos>
</qos_profile>
<qos_profile name="AllegatiProfile" base_name="BuiltinQosLibExp::Pattern.Event">
<datawriter_qos>
<publication_name>
<name>AllegatiWriter</name>
</publication_name>
<publish_mode>
<kind>ASYNCHRONOUS_PUBLISH_MODE_QOS</kind>
<flow_controller_name>DDS_FIXED_RATE_FLOW_CONTROLLER_NAME</flow_controller_name>
</publish_mode>
<durability>
<kind>TRANSIENT_LOCAL_DURABILITY_QOS</kind>
</durability>
<history>
<kind>KEEP_LAST_HISTORY_QOS</kind>
<depth>1</depth>
</history>
</datawriter_qos>
<datareader_qos>
<subscription_name>
<name>AllegatiReader</name>
</subscription_name>
<durability>
<kind>TRANSIENT_LOCAL_DURABILITY_QOS</kind>
</durability>
<history>
<kind>KEEP_LAST_HISTORY_QOS</kind>
<depth>1</depth>
</history>
</datareader_qos>
</qos_profile>
</qos_library>
</dds>