Liveliness of routing service

4 posts / 0 new
Last post
Offline
Last seen: 11 months 2 weeks ago
Joined: 04/13/2023
Posts: 2
Liveliness of routing service

I have two applications, APP1 and APP2, using Java RTI DDS 6.1.2. Each app operates in a separate domain. There is a specific Liveliness topic (let's say LivelinessApp1 and LivelinessApp2) with a data type of keyedString created so that each application publishes its name, and it can be identified and detected if it's alive or dead.

A routing service (more than one) will be added between them. I created two routes for each liveliness direction, and everything works without issue.

The goal right now is to detect the liveliness of the routing service. So, each application will be able to distinguish if the other app or the routing service is dead.

Some thoughts:

  1. Using the liveliness_status_change of the readers  of topic LivelinessApp1 and LivelinessApp2, for example:
final LivelinessChangedStatus status = new LivelinessChangedStatus();
dataReader.get_liveliness_changed_status(status); 
var status = status.alive_count;

The problem with this is that it does not give more information about the routing service name.

  1. Enabling the administration and subscribing to topic command_request or command_response, but I can't send data through those topics, and I can't enable administration for two domains. So, it gives me the same issue as the 1st suggestion.

  2. Creating a custom adapter or processor that publishes data every x seconds.

Is there another way to tell the routing service (using the config XML file) to start a publisher or writer that writes some data every x seconds? Do you have any ideas on how we can handle this?

Thank you.

Howard's picture
Offline
Last seen: 1 day 11 hours ago
Joined: 11/29/2012
Posts: 565

Not sure what you mean by "Enabling the administration and subscribing to topic command_request or command_response, but I can't send data through those topics, and I can't enable administration for two domains."

You should be able to send command_requests and command_responses for the Routing Service Adminstration interface.  If you run RTI Admin Console and Routing Service with the Administration and Monitoring interfaces enabled for Routing Service (via the cfg file), you will see Admin Console is able to show the status of Routing Service.  And Admin Console uses that same Routing Service Administration interface that you could use.

However, another, and easier way, is to use the standard Liveliness or Deadline QoS policies as they apply directly between a DataWriter and DataReader.  So if your application's DataReader is notfified that a Routing Service DataWriter has lost Liveliness or missed a Deadline, then your application will know directly that the application is disconnected from the Routing Service.

Offline
Last seen: 11 months 2 weeks ago
Joined: 04/13/2023
Posts: 2

Enabling administration in routing service using the following config: 

<routing_service name="Routing_Service">

<annotation>
<documentation>
Routing Service
</documentation>
</annotation>
<administration>
<domain_id>1</domain_id>
<distributed_logger>
<enabled>true</enabled>
<filter_level>WARNING</filter_level>
</distributed_logger>
<participant_qos base_name="QosLibrary::QosProfile"/>
</administration>
...

</routing_service>

 

This exposes the command_response topic so I can use the liveliness events directly from that writer.  See attached picture as an example.

Regarding you suggestion, I think it is the same idea (1) that I have mentioned in my first post. Also, I mentioned that this solution wont give me a lot of information about the routing service, I need the name of that participant or the hostname to identify it.

Howard's picture
Offline
Last seen: 1 day 11 hours ago
Joined: 11/29/2012
Posts: 565

Routing Service Administration is enabled for the Routing Service.  You use it to find out about the status of the Routing Service instance as well as sending commands to dynamically configure the Routing Service instance (create/delete/start/stop routes).  You send command_requests and subscribe to command_responses in your app.   You are not in control of sending command_responses...Routing Service will automatically do so in response to a request.

https://community.rti.com/static/documentation/connext-dds/7.1.0/doc/manuals/connext_dds_professional/services/routing_service/remote_admin.html

You can also subscribe to Monitoring topics to get statistics like bytes/sec.

https://community.rti.com/static/documentation/connext-dds/7.1.0/doc/manuals/connext_dds_professional/services/routing_service/monitoring.html

 

With respect to the on_liveliness_changed Status, when notified, you get an instance handle to the DataWriter whose's liveliness has changed.

https://community.rti.com/static/documentation/connext-dds/7.1.0/doc/api/connext_dds/api_cpp2/classdds_1_1core_1_1status_1_1LivelinessChangedStatus.html#af6eb702b40d149550279200fdb34ef45

With the handle, you can get information about the remote DataWriter (aka publication) that's lost its liveliness using

https://community.rti.com/static/documentation/connext-dds/7.1.0/doc/api/connext_dds/api_cpp2/classdds_1_1sub_1_1DataReader.html#a62195eaf0aa94ab4ada984966c3ac7eb

https://community.rti.com/static/documentation/connext-dds/7.1.0/doc/api/connext_dds/api_cpp2/classdds_1_1topic_1_1PublicationBuiltinTopicData.html

which you can access things like the publication_name, which you can set as a QoS in the configuration of the Routing Service.