Unknown Source error

Hi,

The line:

 final DomainParticipant = participant;

 looks like a copy-paste error as it does not compile.

Other than that the code you have seems fine. I created similar code by modifying the Java example that rtiddsgen creates and it runs with no errors.

You could add the following line to the beginning of your program and then re-run it:

        Logger.get_instance().set_verbosity(LogVerbosity.NDDS_CONFIG_LOG_VERBOSITY_STATUS_LOCAL);

This will enable a high level of verbosity messages. Perhaps the printouts it produces will shed some light on what the error is...

Gerardo

Hello Herb,

Sorry, I did not mean compile errors. I meant that I executed the Java code you provided and it run, enabling the DomainParticipant and sending messages without generating any errors.

I think the "Unknown Source" indicates that the error was generated in the core C library and not in the Java layer. It seems like the DomainParticipant.enable() is returning RETCODE_ERROR. The question is why...

When you said:

I should also add that the problem occurs as I add more "participants" (i.e. more domains).

Do you mean this happens (1) when you create multiple DomainParticipant entities from within the same Java application? Or (2) do you mean different Java applications in the same machine? Or (3) do you mean something else?

If (1), is it always the same DomainParticipant that does not get enabled (e.g. when you start the 3rd participant)?

You are right in that it could be a resouce problem... In order to troubleshoot it would be helpful to have additional information.  Did you try adding the line of code I suggested in the previous posting to configure Logging with high verbosity prior to enabling the DomainParticipant?  If so, can you copy and paste the relavant output here?

Gerardo

Hello Herb,

It does appear resource related. But it is not so easy to figure our which resource without additional information. 

One thing that confuses me is that I am not seeing any of the outoput I would expect it should be coming out of the logger. I am only seeing the exceptions but with the high versobity we should be seeing a lot of other things. Maybe your application or Java VM is redirectiong the output somewhere else as this is why we are not seeing it... If that is the case a way around that would be to configure logging to output to a file. You an do this by adding the line:

        try {
        	Logger.get_instance().set_output_file( new java.io.File("MyLogOutput.txt"));
        } 	catch (Exception e) {
        	System.err.println("File exception: " + e);
        }

After this the "MyLogOutput.txt" should contain the logging output I was hoping to see... Gerardo

Hello,

Thank for for including the ZIP file. I took a look at it and I could only find twio kinds of errors:

Several ones that start with  [D0014|ENABLE]NDDS_Transport_UDPv4_create_recvresource_rrEA:!create socket for example in line 6074, 6087, etc.

And the one that starts with  [D0014|ENABLE]REDADatabase_createCursorPerWorker:!create worker-specific object as found in line 6258

The !create socket is not fatal. This happens because you must have started multiple participants in that domain and it is not finding a free port. So it keeps iterating trying teh different ports that correspond to domain 14 in sequence (that is ports 10910, 10912, 10914, and so on) until it finds a free one at 10936 and it continues.

The second one, the !create worker-specific object is the one that causes the domain creation to fail. You were right to suspect the max_object_per_thread. Looking at the source this would be the resource limot that is causing the  !create worker-specific object to fail.

The reason you were getting a RETCODE_IMMUTABLE on the set_qos is that you must change this on the DomainParticipantFactory prior to creating any DomainParticipant on that process (i.e. from that instance of TheDomainParticipantFactory) . Once you have created a DomainParticipant from the facture the max_object_per_thread is "fixed" and can no longer be changed.

From your posting I think you already know how to change it, but I will add it here for completeness:

// This must be done before creating any DomainParticipant from the factory 
// otherwise you will get a RETCODE_IMMUTABLE because max_objects_per_thread is immutable
DomainParticipantFactoryQos factoryQos = new DomainParticipantFactoryQos();
DomainParticipantFactory.TheParticipantFactory.get_qos( factoryQos );
factoryQos.resource_limits.max_objects_per_thread = 2048;
DomainParticipantFactory.TheParticipantFactory.set_qos( factoryQos );
  
// After this the DomainParticipant (s) can be created

Let us know if this works!

Gerardo

Hello,

Yes, you can add the code I pasted in my previous posting right before, or right after the DomainParticipantFactory.get_instance().load_profiles();

It should work as long as it is called before you create the first DomainParticipant which is done in the line

domainParticipant = DomainParticipantFactory.get_instance().create_participant_with_profile(...);

If the call to DomainParticipantFactory.TheParticipantFactory.set_qos( factoryQos )  fails then it should throw the com.rti.dds.infrastructure.RETCODE_IMMUTABLE_POLICY exception right there, so you should be able to see if that works immediately. And you can also re-fetch the DomainParticipantFactory and check it as you mentioned.

The max_objects_per_thread is can be changed as long as it is done before the first DomainParticipant is created. I just tested that with a simple snipped of Java code just in case...  So perhaps there are other places where you are creating DomainParticipants that you did not notice?  Is there a way to set a breakpoint or use the log messages to make sure you are changing the DomainParticipantFactoryQos before you create the first Participant?

Gerardo 

Hello Herb,

Glad to hear you finally got that working! Yes, as we were discussing the max_objects_per_thread is and immutable property of the DomainParticipantFactory and for this reason it can only be modified prior to creating any DomainParticipants in that process.

Regards,

Gerardo

Dear Gerardo,

I was also encountered with the following error:

DDS_DomainParticipantFactoryQos_check_immutableI:ERROR: Trying to change immutable policy resource_limits.max_objects_per_thread

In general you should be able to initialize reference types with dds::core::null, like the article explains. However there seems to be a bug and that constructor is not compiling for Waitset and Condition. For that reason, in this particular case it is a valid workaround to declare your variable as a pointer.

Hi Alex,

Thanks for your answer. But I was wondering why waitset and guardcondition implicitly creat a domain participant and prevent me to change the factoryqos. Can you explain that? Also, as you know, waitset and guardcondition don't provide the operations close(). So by defining them as pointer in my class definition, I think I would have some dangled pointers somewhere in my program. How should I handle the destruction of these entities? 

Best Regards,

Bonjefir