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:
- Using the
liveliness_status_changeof 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.
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.
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.
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.
Enabling administration in routing service using the following config:
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.
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.