PARTICIPANT_QOS_DEFAULT

Hi Allen,

There is an underlying, default "compiled in" QoS set.  This set is compiled into the nddscore library.

The compiled-in set is overlayed, starting with the NDDS_QOS_PROFILES.xml details.  While it is possible to edit NDDS_QOS_PROFILES.xml, I don't recommend it.  Reason 1: It's has a global effect and may induce side-effects because our tools don't expect it to be modified, and 2: unmodified, it can be used as a reference to see what the compiled-in QoS set is.

If you need global behavior on a given node, use the $NDDS_QOS_PROFILES environment variable to point to an XML configuration file (probably a USER_QOS_PROFILES.xml, but can be any name).  This is loaded over the top of the NDDS_QOS_PROFILES(Compiled-In).

The last place sourced is the USER_QOS_PROFILES.xml file in the working directly.  Remember that "working directory" does not mean "where the application is", but where you are calling the application from.  Yes, if you mis-spell USER_QOS_PROFILES.xml, then your settings from that file will not be used.  The end result is USER_QOS_PROFILES(Env_Var(NDDS_QOS_PROFILES(compiled-in))).

Actually, that isn't the end result, because you can load the profile (which does the above), and then modify the values in code.  So it's now Code(USER(Env(NDDS(compiled-in)))), ie changes made to a QoS structure, done in application code, take precidence over everything else, if you then go on to use the modified QoS structure in a factory create call.

If on the other hand, you use the magic flag {entity}_QOS_DEFAULT (check the API for the actual flag label, it changes based on the language you are using, and what you are creating) and not a code-modified structure, then which default QoS set is used is based on the is_default_qos="true" attribute in some XML someplace (in USER_QOS_PROFILES.xml, or in the file pointed to by $NDDS_QOS_PROFILES, or in NDDS_QOS_PROFILES.xml, or if none of those were found, in the compiled in set in the core library).

Does that help?

Regards,

Rip

Hi there,

I have a similar question to Allen's. I have put my USER_QOS_PROFILES.xml file in my project's directory but it did not affect the project.It still uses the default QoSs.
I also added an enviroment variable with the location of my xml file, but it did not help either. According to the  user manual, I can modify the NDDS_QOS_PROFILES.example.xml which is located in $NDDSHOME\resource\qos_profiles_5.0.0\xml and rename it to NDDS_QOS_PROFILES, but when I attemp to do so an arror accors saying I dont have permisson to change it.
what am I missing? Shall I specify my Qos file's path in the application code?

Thanks a lot for your assistance,

Hello Randy,

The documentation in profile loading given in the User's Manual "How to load XML-Specified Qos Settings" is a bit confusing so I will try to explain the recommended practice.

The first thing to check is whether you are modifying the DomainParticipantFactory Qos and specifically the ProfileQosPolicy it contains. This can affect the behavior and selectively enable/disable the loading of QoS profile files from the current working directory, the $NDDSHOME\resource\qos_profiles_5.0.0\xml directory, etc.  I am assumming that you have not modified this...

If the ProfileQosPolicy has not been modified, then RTI Connext DDS will always look for a file called USER_QOS_PROFILES.xml in the current working directory where the application is run from. Note that this is not the same directory where the executable is. Rather the dirctory from which it is run. For example if you had your executable called "myExecutable"  the directory  myDDSApplication/objs/x64Darwin10gcc4.2.1/myExecutable

Then if you run the executable from /home/randy/myDDSApplication as this:

cd /home/randy/myDDSApplication
./objs/x64Darwin10gcc4.2.1/myExecutable

Then RTI Connext DDS will look for the USER_QOS_PROFILES.xml under the directory /home/randy/myDDSApplication

On the other hand if you run from /home/randy/myDDSApplication/objs/x64Darwin10gcc4.2.1 as in:

cd /home/randy/myDDSApplication/objs/x64Darwin10gcc4.2.1
./myExecutable

Then RTI Connext DDS will look for the USER_QOS_PROFILES.xml under the directory /home/randy/myDDSApplication/objs/x64Darwin10gcc4.2.1

A simple way to make sure this file is loaded is to put an error in the file. For example replace the first <dds tag with <ddsXXX and run your application.  If the file is being loaded the application will print the parsing error and abort.

You should never copy the   NDDS_QOS_PROFILES.example.xml file into $NDDSHOME/resource/qos_profiles_5.0.x/xml/NDDS_QOS_PROFILES.xml and edit that. The User's Manual  states this wrongly!  Apologies for this. Hopefully we are fixing this in the next release... The intent of the   NDDS_QOS_PROFILES.xml is to provide system-wide default configurations that replace the ones that are hard-coded into RTI Connext DDS.  This is something that should be done with care because it will impact all DDS applications that share that $NDDSHOME. It is for this reason that this directory is not normally editable by regular users and you need to be administrator to write to it.  

Even if you decide to create the file $NDDSHOME/resource/qos_profiles_5.0.x/xml/NDDS_QOS_PROFILES.xml  you should not do this starting with   NDDS_QOS_PROFILES.example.xml as a baseline. The NDDS_QOS_PROFILES.example.xml contains the full list of all QoS with teh values hardcoded by default into the RTI Connext DDS and it is intended as a reference so you can easily see what all the values are.   The   NDDS_QOS_PROFILES.xml if present should only contain the QoS policy values that are different from the default ones. So it should be a much smaller file, similar in content to the auto-generated USER_QOS_PROFILES.xml so you would be better off starting with one of those as a default.

I normally recommend the use of the USER_QOS_PROFILES.xml rather than the   NDDS_QOS_PROFILES.xml because it can be fine-tuned to the needs of a single application without impacting all the other applications. If you decided to use the NDDS_QOS_PROFILES.xml then I would use a technique similar to the one I described for USER_QOS_PROFILES.xml  (i.e. introduce an error) to ensure it is being loaded.

Assuming that your QoS profile file (say the USER_QOS_PROFILES.xml)  is being loaded, then in order for one of the QoS there to be used there is a couple of more things  that affect with Qos and profile are used:

(a) Does your application-code always use the "default" Qos as a baseline? That is either uses the  XXX_QOS_DEFAULT pre-defined values or call get_default_xxx_qos() to get the QoS before modifying it.

If you do this, then you need to have a "default" QoS profile defined in the USER_QOS_PROFILES.xml . This is done setting the attribute is_default_qos="true" see the XML snippet below:

<qos_profile name="hello_Profile" is_default_qos="true">
    <!-- QoS used to configure the data writer created in the example code --> 
    <datawriter_qos>
        ....
    </data_writer_qos> 
    ...
</qos_profile>  

(b) If your application does specify a profile name. Note that this can be done either explicaitly using the calls create_xxx_with_qos()  or by calling set_default_profile operation on the DomainParticipantFactory.  Then you need to define a profile with that same name in the  USER_QOS_PROFILES.xml .

Gerardo

Hi Randy,

There are four levels of DURABILITY:  VOLATILE, TRANSIENT_LOCAL, TRANSIENT and PERSISTENT.  Both of the higher levels (transient and persistent) require the persistence service to work.  Transient keeps the information available in memory (the persistence service's memory).  Persistent stores the data to disk, backed by an RDBMS.  With Persistent, you can turn off the persistence service, and later turn it back on and still have the information available.  This is not the case with transient, since the data is volatile and turning it off will release the memory.

Transient_Local tells the original publishing datawriter to maintain the information (in memory) for late joiners.  If you don't want the persistence service to be running, you can set the value for both writer and readers to TRANSIENT_LOCAL and the data will be available, so long as the original writer is around. 

Volatile tells the datawriter that the data is for known readers only, and no data will be available for late joiners.

Note:  DURABILITY_QOS at any setting higher than VOLATILE implies (and so requires) RELIABLE_RELIABILITY_QOS.

Please post the applicable parts of the USER_QOS_PROFILE.xml file that you are using.  Also, ensure that the applications (the writer, the persistence service, and the readers) are all using the same value (TRANSIENT or PERSISTENT), and make sure that the entities are actually sourcing the right XML file.  The quickest way to do this is to inject some known error into the XML (ie, malformed XML) and try to run your applications.  If they do run fine, then they aren't sourcing that XML file, as the malformed XML would have caused the create_participant to fail.

Also, Analyzer will show mismatched quality of service, which should tell you if one of your entities isn't set to the correct value.

Regards,

rip

Hi Rip,

Thank you so much for your assistance. The problem was not related to the XML file itself; my publisher and subscriber were not sourcing the same XML file as you mentioned. Thanks again for your reply.

Regards,