3. What’s New in 7.7.0

This section describes what’s new in Persistence Service 7.7.0 compared to release 7.6.0.

Connext 7.7.0 is the first production release in the 7.7 long-term support (LTS) series. It is built upon and combines all of the features in releases 7.4.0, 7.5.0, and 7.6.0 (see Previous Releases). See the Connext Versions and Lifecycle page for more information on RTI’s software release model.

For what’s new and fixed in other products in the Connext suite, see those products’ release notes on the RTI Community Portal or in your installation.

3.1. XML option to enable new synchronization built-in content filter

A new configuration option, <enable_sync_builtin_filter>, has been added under the <data_synchronization> tag in Persistence Service. When set to true (the default), this option enables a new, more efficient built-in synchronization filter. Setting it to false reverts to the previous built-in SQL filter for synchronization. The following snippet demonstrates how to use it:

<persistence_service name="DisableSyncBuiltinFilter">
    <synchronization>
        <data_synchronization>
            <enable>true</enable>
            <enable_sync_builtin_filter>false</enable_sync_builtin_filter>
        </data_synchronization>
    </synchronization>
    ...
</persistence_service>

For more information, see Synchronizing of Persistence Service Instances in the RTI Connext Core Libraries User’s Manual.

3.2. Improved performance when <purge_samples_after_acknowledgment> set to TRUE

This release improves the Persistence Service execution time and CPU usage when these are true:

Persistence Service is configured with Durable Subscriptions.
Persistence Service is configured with purge_samples_after_acknowledgment set to TRUE.

The performance improvement occurs when Persistence Service is adding samples to a large database. The improvement is more noticeable when there are many historical samples in the database that are being delivered and acknowledged while Persistence Service is adding more samples to the database.

3.3. Ensure proper synchronization of dispose messages when <propagate_dispose> and <data_synchronization> are enabled

If you enabled <data_synchronization> as follows:

<synchronization>
    <data_synchronization>
        <enable>true</enable>
    </data_synchronization>
</synchronization>

and also set <propagate_dispose> to true for a <persistence_group>, you may have observed that some dispose messages were not properly synchronized.

This issue could be resolved by explicitly setting <propagate_dispose_of_unregistered_instances> to true in the <datareader_qos> of the <persistence_group>. However, this workaround was not obvious and could cause confusion.

Starting with this release, Persistence Service automatically sets <propagate_dispose_of_unregistered_instances> to true when synchronization is enabled. This setting ensures dispose messages are always propagated consistently without requiring additional configuration.

3.4. Performance improvements with Application Acknowledgement enabled in Persistence Service DataWriter

This release may improve Persistence Service performance when Application Acknowledgement is enabled in the DataWriter of a Topic group by setting reliability.acknowledgment_kind to APPLICATION_AUTO_ACKNOWLEDGMENT_MODE or APPLICATION_EXPLICIT_ACKNOWLEDGMENT_MODE.

For more information about Application Acknowledgment, see the RTI Connext Core Libraries User’s Manual.

3.5. Monitor Persistence Service health with lightweight HTTP server

Persistence Service now includes an optional lightweight HTTP health check server for monitoring service availability. The server responds to HTTP requests with an HTTP 200 OK status, allowing container orchestrators (for example, Kubernetes) to verify the service is running and responsive.

Usage:

rtipersistenceservice -cfgName defaultDisk -healthCheckPort 9000

The health check server is disabled by default (port 0) and is supported on Linux and macOS platforms only.

For more information, see Verifying a Running Persistence Service in the RTI Core Libraries User’s Manual.

3.6. Reduced discovery traffic between participants and Persistence Service when synchronization enabled

When the synchronization protocol was enabled using <data_synchronization> (see Synchronizing of Persistence Service Instances), a Persistence Service may have created and deleted its DataReaders to apply different ContentFilteredTopics. These operations generated discovery traffic that was visible to other applications, even though the traffic was not functionally relevant to them.

This release introduces a performance improvement that prevents applications from being notified of these internal discovery events when using unicast discovery. To achieve this, the Persistence Service now creates two DataReaders: an application-facing DataReader and an internal DataReader. Only the internal DataReader is created and deleted as part of synchronization.

3.7. Improved diagnostics with extended SQLite error codes in Persistence Service database

Errors detected in SQLite database files created by Persistence Service when configured in PERSISTENT mode now include SQLite extended error codes. This additional information improves diagnostics and helps identify the underlying cause of database-related issues.