Finding existing topics on the network (Java)

My comments assume that you didn't supply all the code you have.  For example, activeConditionSeq is never shown being defined, so it must be defined as a class variable elsewhere. 

private void waitForDiscoveredDataWriters(Duration_t waitTime)
{
    try
    {    
        discoveryWaitSet.wait(activeConditionSeq, waitTime);
    } catch (RETCODE_TIMEOUT timeoutRetcode)
    {
        // no publisher found within the time
    } catch (Exception ex)
    {
        // publisher found OR other error has occured while waiting
    }
}

1) Doesn't do anything, and

2) is never actually called in the code you've shown.

Here it is doing something after the waitset is unblocked:

private void waitForDiscoveredDataWriters(Duration_t waitTime)
{
    try
    {    
        discoveryWaitSet.wait(activeConditionSeq, waitTime);

        // a bunch of code that determines if the ON_DATA_AVAILABLE condition exists
        // and if so:
            processDiscoveredDataWriters();
        // probably more code

    } catch (RETCODE_TIMEOUT timeoutRetcode)
    {
        // no publisher found within the time
    } catch (Exception ex)
    {
        // publisher found OR other error has occured while waiting
    }
}

the "// publisher found OR other error has occured..." comment is probably not correct (might just be comment rot, but it would be better served to simply remove it) because a new publisher triggering the condition change that releases the wait... that isn't an exception since that is, by definition, its purpose.

 example code for WaitSets

rip

Hi Mike,

I noticed in your snippet that you are not setting the DomainParticipantFactoryQos that we modify to create a disable DomainParticipant. We recently realized that we were not doing this in the original example and posted the a response with solution and an updated version of the example.

In a nutshell, since we were not setting the DomainparticipantFactoyQos, the DomainParticipant was enabled upon creation. When this happens, by the time you retrieve the built-in entities, discovery information may have been received and we may miss the data types of the first discovered entities. This should solve your problem:

        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 works,
Fernando.

Locally all the RTI tools pick up the participant but on other machines it's not seen. However, once created I can "see" new publishers by receiving their "i'm a new publisher on the network" message (built in publisher topic). So if you have any advice on that, I'd appreciate it. I'll post back if I make any progress.

"Locally", so you mean via shmem.  Interesting.  The behavior you describe is correct if outgoing is blocked somehow from reaching the other machines (unidirectional multicast permitted across a router? no multicast permitted, but the other participants have your IP address in their initial hosts list? Unexpected TTL?)

I'd be running Wireshark both locally and remote, looking for discovery packets going out locally and being received on the remote.  If you see them going out but not coming in, then the problem is unrelated to DDS, and I would start looking at network topology (routers, switches, TTL settings, etc).

Left field:  if the packets are being seen on the remote machine, check the remote participant's accept_unknown_peers QoS (or look for <participant>.ignore_participant(pHandle,...) in the remote machine's code).  Stranger things have happened...

"on my machine", in the singular, is problematic.  Specifically, outgoing traffic may be seen but you can't guarantee that it is received because it is UDP and might be dropped by an intersticial router or switch.  You need to be able to run wireshark on both the source and target machines (not necessarily at the same time).  You need to be able to see the incoming packets on the machine that isn't responding.  ie:  Proof of Sending is not Proof of Receipt.

Sorry, I'm kind of a pedant. 

"... thought it wasn't a new participant."  This will happen if the restarting participant ends up with the same Participant ID, which can happen on deterministic RTOS boards (there is some randomness in the ID selection, but if the board and its OS are deterministic, then the same random decisions are made at the same exact times each time you boot... so the same paths are followed and you end up with the same Participant ID.  The receiver assumes that this is the same participant entity and ignores it.

1) Why can't you edit the XML? That's the simplist and best solution, since it means you won't have to recompile everything.

2) There are examples for the various languages in the sidebar, under Documentation, find the API link for your language.  For Java, for example, it would be in Modules -> Programming How-Tos -> Participant Use-Cases ... BUT:  There isn't a sub-header for "how to change qos", because it's covered in the PDF documentation.  I use those API pages and read between the lines (grab all the boilerplate code from the examples, but ignore the example QoS changes as not relevant to what I'm trying to do, and substitute in the qos changes I need).

On the Participant Use-Cases link there is something relevant -- how to disable auto-enabling of child entities.  In this case, you need that code -- disable the auto-enable, make the changes in the Participant Factory Qos that you need and then create the Participant entities.  After editing the Qos there (for those that can be edited after creation, but before enable), and then enable the participant.

r