4. What’s Fixed in 7.3.0 LTS

4.1. Crashes

4.1.1. [Critical] Persistence Service could potentially crash if a Durable Subscription name was longer than 512 characters

Persistence Service could potentially crash if a Durable Subscription name was longer than 512 characters. This was due to the absence of bounds checking when performing an internal copy operation.

[RTI Issue ID PERSISTENCE-337]

4.1.2. [Critical] Crash in Persistence Service when using ContentFilteredTopics and sharing type codes for discovery

Persistence Service could crash if the configuration used ContentFilteredTopics and type information was shared through discovery via Type Codes.

[RTI Issue ID PERSISTENCE-332]

4.2. Memory Leaks/Growth

4.2.1. [Major] Persistence Service could leak a file handle on Windows when purging sample logs upon startup

Persistence Service had a resource leak on Windows where a file handle wasn’t closed when purging the sample logs (see Sample Logging Tags in the RTI Connext Core Libraries User’s Manual) for a Persistence Group upon startup. Sample log files from a previous execution are typically purged when starting the Persistence Service.

[RTI Issue ID PERSISTENCE-336]

4.3. Other

4.3.1. [Critical] Configuring persistence group’s DataWriter QoS to use compression and XCDR2 encapsulation caused samples to not be received from Persistence Service

QoS of a persistence group did not work. For example:

<persistence_group name="HelloWorldGroup">
  <filter>*</filter>
  <datawriter_qos>
    <representation>
      <value>
        <element>XCDR2_DATA_REPRESENTATION</element>
      </value>
      <compression_settings>
        <compression_ids>LZ4</compression_ids>
      </compression_settings>
    </representation>
  </datawriter_qos>
</persistence_group>

Using the above configuration could have caused DataReaders to not receive samples from the DataWriter associated with the persistence group.

For DataReaders using a ContentFilteredTopic, you may have seen the following error in Persistence Service:

DDS_SqlFilter_evaluateOnSerialized:deserialization error: sample"

For DataReaders not using a ContentFilteredTopic, you may have seen the following deserialization error in your applications:

PRESCstReaderCollator_storeSampleData:deserialize sample error in topic 'MyTopic' with type 'MyType'

For a Routing Service DataReader receiving samples from Persistence Service, you might have seen the following error:

DDS_DynamicData2_from_cdr_buffer:deserialization error: sample

[RTI Issue ID PERSISTENCE-318]

4.3.2. [Critical] <content_filter> tag caused segmentation fault in Persistence Service if filter expression was invalid

Using the <content_filter> tag in Persistence Service, which applies Content Filters on the incoming DataWriter samples, crashed if the filter expression was invalid. The expression could have been invalid if:

  1. The published topic’s samples didn’t contain the fields specified in the value of <content_filter>.

  2. The filter expression specified in the <content_filter> was syntactically incorrect based on the Queries and Filters Syntax section in the API Reference.

[RTI Issue ID PERSISTENCE-281]

4.3.3. [Critical] DataReader stopped receiving samples from Persistence Service DataWriter that uses DDS fragmentation when Persistence Service ran in PERSISTENT mode

A DataReader may have stopped receiving samples from a Persistence Service DataWriter configured to use DDS fragmentation (asynchronous publishing with samples that exceed the minimum mesage_size_max across all installed transports) when Persistence Service ran in PERSISTENT mode (the DataWriter stores the samples on disk). The issue occurred when a sample fragment was lost, which is more likely to occur in lossy networks.

[RTI Issue ID PERSISTENCE-323]

4.3.4. [Critical] Error when receiving compressed batch samples

Persistence Service failed to deserialize compressed batch samples. You would have seen errors like these:

[0x01013446,0xCA403602,0xE81D6C90:0x80000107{E=DR,I=24}|RECEIVE FROM 0x01019DBE,0xD54C0C6F,0x1A7264AB:0x80000002] PRESCstReaderCollator_storeSampleData:!update stream offset [0x01013446,0xCA403602,0xE81D6C90:0x80000107{E=DR,I=24}|RECEIVE FROM 0x01019DBE,0xD54C0C6F,0x1A7264AB:0x80000002] PRESCstReaderCollator_storeSampleToEntry:!store sample data [0x01013446,0xCA403602,0xE81D6C90:0x80000107{E=DR,I=24}|RECEIVE FROM 0x01019DBE,0xD54C0C6F,0x1A7264AB:0x80000002] PRESCstReaderCollator_newData:!get entries [0x01013446,0xCA403602,0xE81D6C90:0x80000107{E=DR,I=24}|RECEIVE FROM 0x01019DBE,0xD54C0C6F,0x1A7264AB:0x80000002] PRESCstReaderCollator_storeSampleData:!update stream offset [0x01013446,0xCA403602,0xE81D6C90:0x80000107{E=DR,I=24}|RECEIVE FROM 0x01019DBE,0xD54C0C6F,0x1A7264AB:0x80000002] PRESCstReaderCollator_storeSampleToEntry:!store sample data [0x01013446,0xCA403602,0xE81D6C90:0x80000107{E=DR,I=24}|RECEIVE FROM 0x01019DBE,0xD54C0C6F,0x1A7264AB:0x80000002] PRESCstReaderCollator_newData:!get entries

[RTI Issue ID PERSISTENCE-321]

4.3.5. [Minor] <configuration_variables> tag not supported in Persistence Service

The <configuration_variables> tag was visible and accepted by the Persistence Service .xsd file, but it had no effect: the parsing of an XML file with this tag to set the value of XML-defined environment variables failed. This problem has been corrected. Now, the <configuration_variables> tag can be used to define default values for XML-defined environment variables, which will take effect if those environment variables are not set on the terminal.

For example:

<dds>
    <configuration_variables>
        <value>
            <element>
                <name>STORAGE_LOCATION</name>
                <value>/tmp/persistence_service_storage</value>
            </element>
        </value>
    </configuration_variables>
    <persistence_service name="defaultDisk">
        <persistent_storage>
            <filesystem>
                <directory>$(STORAGE_LOCATION)</directory>
            </filesystem>
        </persistent_storage>
        <participant name="defaultParticipant">
            <persistence_group name="persistAll">
                <filter>*</filter>
                <single_publisher>true</single_publisher>
                <single_subscriber>true</single_subscriber>
                <datawriter_qos base_name="SystemPersistenceQosLib::QosProfile"/>
                <datareader_qos base_name="SystemPersistenceQosLib::QosProfile"/>
            </persistence_group>
        </participant>
    </persistence_service>
</dds>

[RTI Issue ID PERSISTENCE-306]

4.3.6. [Minor] Memory Leak when parsing environment variable in XML that does not exist

When parsing an environment variable in XML, if the environment variable does not exist, Connext logs an error and terminates parsing of the XML containing the error. The code handling this error condition did not properly free memory allocated during the parsing of the XML up to the point of the error, resulting in a memory leak.

[RTI Issue ID PERSISTENCE-309]