5.1. What’s New in 7.2.0

5.1.1. Persistence Service compatible with Monitoring Library 2.0

RTI Monitoring Library 2.0 can now be enabled in Persistence Service so that all DDS entities created by this service will provide monitoring data to RTI Observability Framework.

To enable Monitoring Library 2.0 in Persistence Service, add the XML code snippet shown below to an XML QoS profile, then run Persistence Service from the folder containing the profile. Add the snippet to any of the following XML files:

NDDS_QOS_PROFILES.xml, located in the Persistence Service working directory
USER_QOS_PROFILES.xml, located in the Persistence Service working directory
Any XML file included in the NDDS_QOS_PROFILES environment variable

<?xml version="1.0"?>
<dds>
    <qos_library name="MonitoringEnabledLibrary">
        <qos_profile name="MonitoringEnabledProfile"
                    is_default_participant_factory_profile="true">
            <participant_factory_qos>
                <monitoring>
                    <enable>true</enable>
                </monitoring>
            </participant_factory_qos>
        </qos_profile>
    </qos_library>
</dds>

5.1.2. Support for dynamic certificate revocation and renewal without needing to restart Persistence Service

A running Persistence Service instance can use the new authentication.crl_file_poll_period.millisec and authentication.identity_certificate_file_poll_period.millisec properties in the Security Plugins to specify certificate revocations and renewals without the need to restart the service. (In release 7.3, these two properties are replaced by a single property, files_poll_interval.) These properties must have a value greater than zero for the participant to periodically poll the provided security-related files for changes.

For more information, see Advanced Authentication Concepts in the RTI Security Plugins User’s Manual.

5.1.3. New Library API functions in C allow get/set QoS operations on internal DomainParticipants

Persistence Service supports a new set of Library API functions in C that allow updating the QoS values DomainParticipants use to receive and publish data for the Persistence Groups contained in participants (<participant> is the corresponding tag in the XML configuration). These new APIs can provide additional flexibility in use cases that require changing a DomainParticipant QoS. For example, you could use them to update:

QoS properties
Transport configuration
Participant partitions

In addition, you can use these APIs to change the configuration of the two DomainParticipants associated with a <participant> tag in XML separately. This option was not possible using XML.

The new Library API names are:

RTI_PersistenceService_get_participant_qos
RTI_PersistenceService_set_participant_qos

For more details, see the Persistence Service API Reference.

5.1.4. New Library API functions in C allow get/set QoS operations on internal Publisher/Subscriber entities

Persistence Service supports a new set of Library API functions in C that allow updating the QoS values of the Publisher/Subscriber entities belonging to Persistence Groups (<persistence_group> is the corresponding tag in the XML configuration). These new APIs can provide additional flexibility in use cases that require changing the Publisher/Subscriber QoS. For example, you could use them to update:

QoS properties
Endpoint partitions

The new Library API names are:

RTI_PersistenceService_get_publisher_qos
RTI_PersistenceService_set_publisher_qos
RTI_PersistenceService_get_subscriber_qos
RTI_PersistenceService_set_subscriber_qos

For more details, see the Persistence Service API Reference.

5.1.5. Persistence Service now allows you to set rtps_app_id, giving you greater control over value of DomainParticipant’s GUID prefix

Persistence Service now allows you to set the value for rtps_app_id in a DomainParticipant’s WIRE PROTOCOL QoS policy. In previous releases, if you tried to set this value, Persistence Service would log an exception and override the value with DDS_RTPS_AUTO_ID.

This new capability allows you to have greater control over the value of a DomainParticipant’s GUID prefix. It can especially be helpful if you want to use your own rtps_app_id to identify the DomainParticipants created by an instance of Persistence Service by looking at the GUID prefix encapsulated as part of the RTPS wire packet’s header. For example, a layer 7 load balancer could make routing decisions based on the value of the rtps_app_id of the DomainParticipant’s GUID prefixes.

Note that Persistence Service still ensures that the GUID prefixes for all its DomainParticipants are unique, even if they share the same rtps_app_id, by automatically generating the rtps_instance_id, which is the last part of the GUID prefix. This last part is not user-configurable.