I am working on a toy example that essentailly follows publish-subscribe tutorial, but attempts to mix in the use of Routing Service. My goal is to ascertain the viability/ease of connecting to Kafka. But for now, I'd just be happy to have two domains talking to each other. However, the second domain does not show up in the RTI Administrator Console, and the output of the DataWriter on the second domain cannot be seen via rtiddsspy.
Note: I am doing all of this on a single VM, not across multiple machines.
Here is my publishing app, running on domain_id=0
Next, here is my subscriber running on domain_id=1 which reads the reaw data, multiplies it by 0.1 and writes it back out:
Here is my Routing Service Configuration:
The file structure of my project is:
And finally, I run the following commands to start the publisher, subscriber, and routing service:
Publisher: ./build/dds/publisher
Subscriber: ./build/dds/subscriber
Spy: ../rti_connext_dds-7.5.0/bin/rtiddsspy -printSample COMPACT -topic AlertTopic
Routing Service: ~/rti_connext_dds-7.5.0/bin/rtiroutingservice -cfgFile alert_routing_service.xml -cfgName AlertRoutingService
Hi,
rtiddsspyjoins a single DDS domain. By default it isdomainId=0so it will not see things published indomainId=1. You can change that behavior passing the command-line parameter-domainId 1Admin Consolecan be configured to autojoin all domains it sees are being used. I believe it is the default setting. So I am not sure why it is not seeing domainId 1. Maybe it is an issue with your applications running in the VM and AdminConsole running on the host? How is the guest network configured? I think the first step to troubleshoot would be to run rtiddsspy -domainId 1as this can also be run in the VM.To remove variables I would use an <autoroute> (see the Routing Service manual section Auto Route). That way all topics will be routed without having to explicitly configure their names and types. Otherwise if you mistype something, for example the registered type name, the routing service will not forward the data. You can also enable a higher vervosity in the routing service (passing the -verbosity <LEVEL> to the command line). To make sure the route is being created correctly.
Are you aware of the Kafka gateway example we have in the community github repo (https://github.com/rticommunity/rticonnextdds-gateway)? This could help you with the actual bridging to Kafka once you get past the current issue you are facing...
I'm happy to report that I just needed to point spy at the right domain. It is now seeing the output of the data writer on domain 1. However, I am still curios as to why the administration console doesn't show all domains and activity? It only shows Domain 0, the publisher on that domain, and the routing service. I verified that the default setting is indeed for automatic discovery.
P.S. had not seen that Kafka example yet. It looks like it requires Confluent to work, which I'm not inclined to add to the stack, at least not during this exploratory phase. It might be helpful anyway, so thank you.
A few comments...it seems that you're indirectly testing if RoutingService is routing the SensorTopic by using rtiddsspy on the AlertTopic which is published if the application in Domain 1 receives the SensorTopic data via RoutingService.
Why not directly use rtiddsspy to subscribe to the SensorTopic in Domain 1 to see if RoutingService is routing the data of SensorTopic from Domain 0 to Domain 1?
As to Admin Console, is it running in the same VM as the applications? If so, it should have detected that there are applications in Domain 0 and Domain 1. What domains does it show that it has joined (per the preferences dialog)? What does the Physical view look like?
Hi Howard,
To answer your question about the Admin Console: It is running on the same VM as the demo publisher and subscriber. I think Gerardo asked the same question, but I didn't notice it until just now.
It only shows Domain 0 in the preferences unless I turn off automatic discovery and add Domain 1 manually. I am happy to see it works with manual addition and that will serve well enough for now.
Thanks!
The automated feature in Admin Console depends on the ability of Admin Console to receive multicast UDP packets from DomainParticipants (apps).
If the VM OS does not support multicast on any interfaces or doesn't support multicast-loop-back in the case that Admin Console is running on the same host as the apps, then the automated join feature won't work...can't work...