Issues in running MonitorData.java incase we start rtireplay first

7 posts / 0 new
Last post
Offline
Last seen: 7 years 2 weeks ago
Joined: 11/02/2015
Posts: 4
Issues in running MonitorData.java incase we start rtireplay first

Hi,

      We are using DDS to communcate data to different modules . I am in process of writing a service which can read the messages on DDS . I came accross MonitorData.java which fits the neds pretty well .
 The only issue i am having is when i run the rtireplay first and then start the Monitor data . In this case non of the DDS messages are read. It seems to be waiting for waitForDiscoveredDataWriters.

I am attaching the file . Please review .


thanks,

Pankaj

 

 

AttachmentSize
File monitordata.java17.74 KB
Gerardo Pardo's picture
Offline
Last seen: 1 month 2 weeks ago
Joined: 06/02/2010
Posts: 600

Hi Pankaj,

I took a quick look at the file you attached. Nothing there stands out as an obvious problem.

Are you saying that if you start the MonitorData.java before rtireplay then you receive the messages but if you start rtireplay first you do not?

Did you try the original MonitorData.java application from http://community.rti.com/filedepot?cid=6&fid=20? does it have the same problem?

Can you try running rtiddspy instead of the MonitorData.java application? Does it exhibit the same behavior of not seeing the data if it gets started after the rtireplay ?

Some additional questions to help determine if this may be a discovery problem:

  • Are you configuring NDDS_DISCOVERY_PEERS or are you leaving the default values?
  • Are you running in the same computer or different?
  • Is multicast enabled (this is the default) does your network support it?

Gerardo 

Offline
Last seen: 7 years 2 weeks ago
Joined: 11/02/2015
Posts: 4

Hi Gerardo,

Please look at answers inlined in red

I took a quick look at the file you attached. Nothing there stands out as an obvious problem.

Are you saying that if you start the MonitorData.java before rtireplay then you receive the messages but if you start rtireplay first you do not?

Yes thats correct .

Did you try the original MonitorData.java application from http://community.rti.com/filedepot?cid=6&fid=20? does it have the same problem?

Yes it also has the same problem.

Can you try running rtiddspy instead of the MonitorData.java application? Does it exhibit the same behavior of not seeing the data if it gets started after the rtireplay ?

I ran rtiddsspy and it does not have the same problem. I can read the messages anytime before and after running rtireplay.

Some additional questions to help determine if this may be a discovery problem:

  • Are you configuring NDDS_DISCOVERY_PEERS or are you leaving the default values?
  • I am using default value.
  • Are you running in the same computer or different?
  • Same computer ( Its actually a VM)
  • Is multicast enabled (this is the default) does your network support it?
  • Yes

rgds,

Pankaj

Gerardo Pardo's picture
Offline
Last seen: 1 month 2 weeks ago
Joined: 06/02/2010
Posts: 600

Hi,

Thank you for the additional information. I identified the problem. It seems like there is a bug in the way we configure the WaitSet.

Please open the MonitorData.java file and look for the function waitForDiscoveredDataWriters (see below)

    private void waitForDiscoveredDataWriters() {
        Duration_t waitDuration = 
            new Duration_t(Duration_t.DURATION_INFINITE_SEC, Duration_t.DURATION_INFINITE_NSEC);
        
        System.out.println("waitForDiscoveredDataWriters");
        try {
            discoveryWaitSet.wait(activeConditionSeq, waitDuration);
        } catch (RETCODE_TIMEOUT timeoutRetcode) {}
    }

Edit the function replacing:

        Duration_t waitDuration = 
                new Duration_t(Duration_t.DURATION_INFINITE_SEC, Duration_t.DURATION_INFINITE_NSEC);
 

With:

        Duration_t waitDuration = 
                new Duration_t(Duration_t.DURATION_INFINITE);
 

This should solve the problem. Somehow we are processing the first syntax incorrectly and we get into an infinite wait as you had observed. I have also filed an internal issue to correct this problem. In addition I uploaded a new version of MonitorData.java (https://community.rti.com/filedepot?cid=6&fid=20) to the File Exchange with this fix.

Thank you for helping us troubleshoot this!

-Gerardo

Offline
Last seen: 7 years 2 weeks ago
Joined: 11/02/2015
Posts: 4

Thanks for suggesting a solution. Though its not complete solution as still it gets stuck 1 out of 5 times. So this solution does not works all the times. Please help !!

Offline
Last seen: 7 years 2 weeks ago
Joined: 11/02/2015
Posts: 4

I am still seeing this issue.

The current fix only works sometime and then it fails 1 out of 5 times.

Please give some pointers for the complete fix.

rgds,

Fernando Garcia's picture
Offline
Last seen: 6 months 3 weeks ago
Joined: 05/18/2011
Posts: 200

Hi Pankaj,

I think the problem is that in the example we were not explicitly attaching the modified DomainParticipantFactory's QoS settings to the DomainParticipantFactory. As a result, the DomainParticipant and all its contained entities were enabled upon creation. When this happens, by the time we retrieve the built-in entities, discovery information may have been received and we may miss the data types of the first discovered entities. That is probably why your are running into this problem only 1 out of 5 times -- sometimes discovery happens before you have retrieved the built-in entities, but most of the times it happens after.

This snippet contains the fix. Note that we have added calls to  factory.get_qos() and factory.set_qos():

        DomainParticipantFactoryQos factoryQos = new DomainParticipantFactoryQos();
        
        // This instructs the DomainParticipantFactory to not enable the DomainParticipant
        // entities it creates automatically. This is needed so that we have a chance to
        // retrieve the builtin data-readers before the participant starts receiving
        // discovery data. Later it is explained why this is needed
        factory.get_qos(factoryQos);
        factoryQos.entity_factory.autoenable_created_entities = false;
        factory.set_qos(factoryQos);

Please, let me know if this fixes your issue.

Thanks,
Fernando.