Issues in running MonitorData.java incase we start rtireplay first

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 

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

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.