##### Vortex OpenSplice

- Introduction
- User Guides
- Changes
- Supported Platforms
- Known Issues
- DDSI Release Notes
- Rebuilding the APIs
- Upgrading OpenSplice
- Examples
- Third party licenses
- License

## Release Highlights

This page contains a list of all bug fixes and changes incorporated in OpenSplice V6.x series of releases
- Fixed Bugs and Changes not affecting API
- Fixed Bugs and Changes affecting API / behaviour

## Vortex OpenSplice V6.9.2p2 contains the following new feature:

- Beta implementation of the Node.js DCPS API more information can be found in the Node.js DCPS API Guide inside the docs directory
Known issues with the Node.js DCPS API:
- Listeners are not supported
- The current packaging does not bundle npm package dependencies on installation. The required npm packages are installed using the "npm install" command, which requires internet access.
- JavaScript classes do not support destructor like functionality. When a qos object is dereferenced, the C99 QoS handle is not automatically cleaned up. In the Beta, users must explicitly call delete on QoS JavaScript class instances.

## Vortex OpenSplice V6.9.2p1 contains the following new features:

- Changed time format to UTC representation in the OpenSplice log and trace files. The previous format was 'seconds,nanoseconds` since EPOCH (1-1-1970) The new format is: YYYY-MM-DDThh:mm:ssZ S.MS YYYY = four-digit year MM = two-digit month (01=January, etc.) DD = two-digit day of month (01 through 31) hh = two digits of hour (00 through 23) (am/pm NOT allowed) mm = two digits of minute (00 through 59) ss = two digits of second (00 through 59) Z = +/- UTC offset (4 digits) S = number of seconds since EPOCH time base. SM = number of micro second fraction of a seconds since EPOCH time base
- Implemented configuration option for logging of discovered entities. This option allows to specify a logfile which will contain a log line for each builtin topic update of all discovered entities. This option is documented in the configurator. Example of the configuration:

      <OpenSplice>
      <Domain>
      <Name>LOGROTATE</Name>
      <BuiltinTopics enabled="true" logfile="builtin.log"/>
      </Domain>
      </OpenSplice>

- The OpenSplice log and trace files can now be used together with logrotate to get this working the option copytruncate has be set in the logrotate configuration for OpenSplice log/tracefiles. Usage of logrotate can be found in the logrotate manual.

## Vortex OpenSplice V6.9.2 contains the following new feature:

- The Java 5 examples and the Java(5) API are now build with Apache Maven 3.x. Apache Maven 3.x can be obtained here.
- Support for the '/' character in topic names
- [Launcher] Configurations tab - UI improvement to indicate invalid OpenSplice config files

## Vortex OpenSplice V6.9.1 contains the following new feature:

- Node Isolation - Vortex OpenSplice 6.9.1 includes support for isolating a node from the network by using the set_property extension on the API. When the newly introduced property (named isolateNode) is enabled, network services will stop sending to the network and will drop all incoming traffic.

## Vortex OpenSplice V6.9.0 contains the following new features:

- LabVIEW DDS Binding - Vortex OpenSplice 6.9.0 includes a DSS binding for National Instruments LabVIEW, allowing LabView 2017 applications to connect to a DDS domain and exchange data with other DDS applications. The binding includes a LabVIEW VI Package (located in the tools/labview subdirectory of a Vortex OpenSplice installation). Once installed, the VI Package enables the creation of DDS applications, including the compilation of IDL into LabVIEW virtual instruments and controls. See the Vortex OpenSplice LabVIEW Guide for more information. The LabVIEW binding is available on Vortex OpenSplice Windows and Linux builds compatible with LabVIEW 2017.
- Python DCPS API - The Python DCPS API is now taken out of beta and considered GA.

## Vortex OpenSplice V6.8.3 contains the following new features:

- This release includes beta support for Mac OS X using Clang V7
- In order to support certain simple uses cases without the need for IDL, code generation or type registration, our product is extended with 4 new builtin types: Bytes, _String, KeyedBytes and KeyedString these are the built-in types that exist in the X-Type spec.
- For MQTT-like API and general-purpose topics for IoT usecases a beta release of pre-defined generic IoT type called IoTData is introduced, which can carry data in the form of name value pairs. The IoTData type can be used in the C#, C99, IsoCpp2 and Java5 API. This IoTData type is subject to change for the 6.9 release.
- This release includes a beta of the Python binding for DDS. The binding is a Python package that enables Python 3.4 or later to connect natively to a Vortex OpenSplice domain to register topics, and then read and write topic data. In the beta, topic types are described by IDL. However, you do not need to run IDLPP; instead, a python function (ddsutil.get_dds_classes_from_idl) returns Python classes and topic descriptors directly. More information on the binding may be found in the tools/python directory under your Vortex OpenSplice installation.
- Added examples for the C99 API

## Vortex OpenSplice V6.8.2 contains the following new features:

- C# Language binding now supports the use of unions in your IDL data model.
- The license for Vortex OpenSplice has been changed from LGPLv3 to Apache 2.0.

## Vortex OpenSplice V6.8.1 contains the following improvements related to the MATLAB/Simulink integration:

- Simulink Coder is now supported for the Vortex DDS block set. Users with a Simulink Coder license (available from MathWorks) can now generate C code from their Simulink models. Note that such C programs will require an OpenSplice installation in order to compile and execute on the desired target platform.
- Vortex DDS Block Set for Simulink has been enhanced to support various wait conditions on read (wait for historical data, wait for data available) and write (wait for matching subscribers). In addition, IDL sequences are now supported.
- The MATLAB API for Vortex DDS has exited beta. Improvements include generation of MATLAB classes from IDL files via IDLPP. In addition, IDL sequences and bounded strings are now supported. Finally, more robust error checking has been implemented.

## Vortex OpenSplice V6.8.0 contains the following new features:

- MATLAB/Simulink integration - Via its standardized Data Distribution Service (DDS) interface, Vortex OpenSplice now provides integration with MATHWORKS MATLAB and Simulink products. MATLAB classes as well as Simulink BUS definitions are automatically mapped to their corresponding Topic definitions in DDS. To ensure type agreement between DDS and MATLAB/Simulink applications,MATLAB classes and Simulink blocks can be exported to the IDL format that is well-known for DDS applications. The integration allows users to create DDS entities in their MATLAB/Simulink model and associate them with desired Quality-of-Services in separate XML files to provide maximum flexibility and control how and when data is exchanged. These capabilities allow users to transparently share any data between different MATLAB/Simulink applications and/or pure DDS applications no matter where they have been deployed in the network.
- Durability master priority configuration - Up till now it was almost impossible to control which durability service becomes master. This leads to situations that durability instances that should not become master can become master. Furthermore, it is currently not possible to indicate that a durability instance can act as aligner, but should not take up the responsibility to act as master for other instances. To provide more control which node becomes master for a namespace, the //OpenSplice/DurabilityService/NameSpaces/Policy[@masterPriority] attribute can be specified. This is an optional attribute that specifies a value between 0 and 255. Value 0 means that a node will never become master, and value 255 indicates that the legacy master selection will be used. The default is 255. When the masterPriority is specified between 1 and 254, nodes with a higher masterPriority should become master. See the deployment manual for more information.Note that there are currently a few limitations:
  - Mastership handover in case a better but late joining master arrives is currently unsupported.
  - In case of mixed deployments with legacy nodes, the nodes that support masterPriority must use masterPriority=255.

## Vortex OpenSplice V6.7.2 contains the following new features:

- The OpenSplice configuration allows for the specification of a report plugin which is a dynamically loaded library to which all the report messages are forwarded. A report plugin is associate with a particular domain. To enable the plugin to associate a report message to a particular domain the message that is reported is extended with the domain_id of the domain from which the message originates. Further report messages are only forwarded to the plugin associated with the domain the report message originates. In a multi-domain configuration this enables the report plugin to determine the corresponding domain. Note that not all report message can be associated with a particular domain. In that case these message will be forwarded to all plugins with a domain_id of -1.
- The validation of the OpenSplice XML configuration file has been made more stricter. On startup of OpenSplice the provided configuration file is validated and OpenSplice is not started when the configuration file contains errors. For example the validation of the configuration file checks for missing mandatory elements and attributes, unknown element or arttributes, or the specification of incorrect. When the validation finds errors then these errors are reported in the error log.

## Vortex OpenSplice V6.7.1p3 newly introduces support for the following new platforms:

- Raspberry Pi 3 Raspbian Jessie (32 bit) Host and Target, gcc 4.9.2, ARMv7 (Debian 8)
- RHEL7.1 host, ElinOS 6.1 hypervised by Pike OS 4.1 Core i7 x86_64 target
- Ubuntu 16.04 64 bit host and target

## Vortex OpenSplice V6.7.1 contains the following new features:

- The C99 DDS API (beta) - Instead of the legacy C API which is based on the OMG IDL to C mapping, the C99 API offers a more natural and modern DDS API for the C programming language. This allows users to be more productive. Besides thatm the API allows users to switch their existing applications between Lite and OpenSplice products without changing their code (a recompile suffices).

## Vortex OpenSplice V6.7.0 contains the following new features:

- Group coherency support for Tuner and Tester - Both of these tools now has the ability to publish and subscribe with custom Presentation policies. New UI workflows have been established for working with coherent and ordered sets of data for group and topic level access scope. See the new sections in the Tuner user guide and the Tester user guide for more details.
- Vortex OpenSplice previously used internally time stamps that would wrap around somewhere in the year 2038. To allow time stamps that exceed 2038 OpenSplice now uses a new internal time representation. This time representation will wrap around somewhere in the year 2262, which is believed to be sufficient for all applications that are being written today. The internal time representation will by default not be exposed to applications to avoid backward compatibility issues, so existing applications should not notice this change. However, users can enable these extended time stamps to be exposed, so that applications can use these extended time stamps. This is explained in more detail in the DeploymentGuide section 'Time stamps and year 2038 limit'.
- New TimeBasedFilterQosPolicy behaviour (See Fixed Bugs and Changes affecting API / behaviour).

## Vortex OpenSplice V6.6.4p3f17 contains the following new features:

- Coherency outside name-space, error reporting - When creating group coherent writers a check is done to determine if the writer is in a single name-space and if all other writers part of the group coherent publisher are in the same name-space, if not an error is reported. This helps ensure that all group coherent writers for a single publisher are all in the same name-space so that durability is able to correctly align group coherent transactions.

## Vortex OpenSplice V6.6.4p3f16 contains the following new features:

- Notification of sample lost on writer side - A new feature has been implemented that allows notifying publishers when a reader becomes unresponsive (reliable communication is lost and the reader may miss samples). The mechanism is implemented using the already existing publication-matched status, i.e. the count will be lowered when reliable communication with a reader is lost. This feature is only supported when using the DDSI networking service. Note that the default configuration of //DDSI2Service/Internal/ResponsivenessTimeout is infinite, which means readers will never be considered unresponsive and the sending will simply wait for the reader to become responsive again. Only when a valid non-infinite responsiveness timeout is set, the newly implemented mechanism is enabled.
- Scalability improvements for historical data alignment - It is now possible to configure content filters in the configuration file using the //OpenSplice/Domain/Filters element. These content-filters are applied within the complete local federation meaning that all data that does not match a filter is not maintained within the federation. As a result of this, none of the local data-readers, including services, will not receive non-matching data, i.e. filtered out data will not exist. Different filters can be specified for different partition-topic combinations using //OpenSplice/Domain/Filters/Filter elements. By using filters, the data-set that is maintained and aligned can be reduced and therefore less memory, bandwidth and CPU resources are required. This is useful for use cases where it is known up-front what part of the data for a given partition-topic is required for a given federation. Please note that when a filter is set for a given partition-topic combination, the Durability Service can no longer act as a master for the name-space that contains the given partition-topic combination as it is incomplete by definition.
- Ability to include wall-clock timestamps in reports in case a Userclock hase been configured - A new configuration attribute //OpenSplice/Domain/UserClock[@reporting] has been introduced. This attribute identifies if messages reported in the ospl-info/ospl-error logs will include timestamps obtained from the UserClock library or use the standard system clock for time reporting. When set to true, which is default the userclock will be used. When set to false the system clock will be used for time reporting in the log files.

## Vortex OpenSplice V6.6.4 contains the following new features:

- Future Airborne Capability Environment (FACE) Transport Services Segment (TSS) V1.2 API for Java and C++ (BETA) - The FACE Standard defines the software computing environment and interfaces designed to support the development of portable components across the general-purpose, safety, and security profiles. FACE uses industry standards for distributed communications, programming languages, graphics, operating systems, and other areas as appropriate. The goal of FACE is to reduce software development and integration costs and reduce time to field new avionics capabilities. FACE establishes a common computing software infrastructure supporting portable, capability-specific software components across Department of Defense (DoD) avionics systems.
  The FACE C++ and Java API's supplied with OpenSplice are targeting developers and integrators who want to take advantage of the Data Distribution Service (DDS) standard. For more information on usage, please check the examples/face directory within your OpenSplice installation.
  Please note that more documentation will be added in a future release.

## Vortex OpenSplice V6.6.3p3 contains the following new features:

- Added Yocto 3.0.6.32 Freescale P4080ds (e500mc) target platform for RHEL 6.4 64 bit host
- Added RedHat Enterprise Linux 7.2 for Intel 64 bit host and target

## Vortex OpenSplice V6.6.3 contains the following new features:

- Client-side durability - In OpenSplice, the realization of the non-volatile properties is the responsibility of the durability service. This service is on one hand responsible for maintaining the set of historical data and on the other hand responsible for providing historical data to late-joining subscribers. The configurations of the different services drive the behavior on where and when specific data will be maintained and how it will be provided to late-joiners. To prevent the need of equipping each application with a full durability service in single process mode, it is now possible to equip applications only with a client-side durability part and run the server part on a different location in the system (or on multiple locations driven by fault-tolerance requirements). This reduces resource usage in single process applications drastically. See section 12.2.27 "DurablePolicies" in the deployment guide for more details about the configuring client part and section 12.3.2 "ClientDurability" about enabling the server part.
- Launcher updates:
  - Product release information is now accessible in Launcher through the "Documentation" section under the new "Product Information" tab. The tab contains references to the Vortex OpenSplice Intro, the release notes and the known issues.
  - All guides and manuals are now available in Launcher.
  - The "Memory Statistics" tool is now available in Launcher under the "Tools" section alongside Tester, Tuner, Configurator and the Console. Clicking on the mmstat button opens up a command prompt and run the "mmstat" command. Upon termination of the command, the command prompt holds to allow the user to further interact with it.
  - Add ability to open the Visual Studio example solution files to Launcher - On Microsoft Windows platforms, users now have the ability to open the example solution files for the Vortex OpenSplice examples in order to inspect and build them. The new section is only displayed on Windows platforms in the Examples pane. Clicking on the Open Visual Studio solution file icon will open the selected example solution file in the Microsoft Visual Studio editor. The version of Microsoft Visual Studio that is used to open the example solution files is used by either inferring from the VCINSTALLDIR environment variable or by looking in the PATH to see if devenv.exe is found. If the executable cannot be found in either locations, a notification will pop up instructing the user to set the appropriate environment variables. Note: The example solution files will no longer be available to users from the Start Menu in Windows.
- Improved reference docs for DDS API's - the reference documentation for ISOC++v2, Java5 and C# DDS API's have been significantly improved.
- Added Windows 7 - Visual Studio 2015 support (64-bit)
- Added Windows 10 - Visual Studio 2015 support (64-bit)
- Google Protocol Buffers support for Tuner - The Tuner tool has been extended with functionality to be able to write/read Topics that have been modeled using Google Protocol Buffers (instead of OMG IDL) similar to the support already available in the Tester tool. Refer to the new section in the Tuner user guide for more details.
- C++ RMI service threading and scheduling policies and service priority - Different threading and scheduling policies have been added to the C++ RMI library. The threading policies control the way a RMI server allocates threads to handle the incoming requests, whereas the scheduling policies control how these threads are scheduled within the operating system. Three threading policies have been defined: 'Single Thread', 'Multi-thread' and 'Thread Per Service'. In addition, the notion of service priority has been introduced to express the business importance of each service w.r.t. the others. Requests coming to a service with high priority should be handled before the ones coming to services having less priority value. These new features have introduced some additions to the RMI C++ API. Please, refer to the RMI documentation for more details.

## Vortex OpenSplice V6.6.2 contains the following new features:

- Detach from all domains - A new operation has been added to the DomainParticipantFactory in the DDS API. The operation allows you to detach your application safely from all Domains it is participating in with one single call.
- Improved entity naming - The naming of DomainParticipant, Publisher, Subscriber, DataWriter and DataReader entities has been improved. Tooling visualizes these names and the improved naming makes it easier for users to relate entities to their applications.
- Launcher - In Vortex OpenSplice Launcher, a new section called "Controls" has been introduced. This section contains buttons to easily start and stop an OpenSplice domain based on the active ospl config file in Launcher. The start and stop buttons are disabled if the active ospl config file describes a single process deployment. When the user clicks on the start/stop button, a progress bar is displayed in the bottom tool bar to indicate that Launcher is processing the request. When Launcher has completed the operation, notification pop-up messages are displayed indicating the result of the requested operation. Note: in general all items that are now available in the Launcher no longer appear in the start menu on Windows platforms.

## Vortex OpenSplice V6.6.1p1 contains the following new features:

- Added debian6 ARMv6 target platform for debian6 ia32 (x86) host
- Added debian7 ARMv7 hardfloat target platform for debian7 ia32 (x86) host

## Vortex OpenSplice V6.6.1 contains the following new features:

- Improved out-of-memory handling for shared memory - operations that require memory now reserve memory prior starting the operation to be able to ensure beforehand whether or not the operation will succeed. This removes the need for configuring large memory thresholds in dynamic systems with large shared memory segments.
- Improved mutex and condition variable implementation for Windows platforms. This improves overall performance of the product on those platforms.

## Vortex OpenSplice V6.6.0 contains the following new features:

- ISOC++ DCPS API version 2 - A brand new version of the ISOC++ specification (dcpsisocpp2) has been implemented. This implementation replaces the initial ISOC++ DCPS API (dcpsisocpp), which is deprecated now and will be removed in a future release. The new version addresses various issues in the initial version of the specification. Check out what you need to do to migrate in the ISOC++V2 migration guide
- Full PresentationQosPolicy support
  - GROUP-level coherence support - The GROUP level access_scope of the PresentationQosPolicy is now supported. This allows representing changes to data instances of different DataWriters underneath a single Publisher to be presented to the subscribing application as a single (coherent) set. Please check out the API reference manual for your favorite programming language for more details on the PresentationQosPolicy.
  - Ordered access for group and topic level access scope - The ordered_access property of the PresentationQosPolicy has now been implemented for topic and group level access scope (instance scope already existed). As a consequence applications now have the ability to see the relative order of (coherent) changes. The reference manuals contain further details about the behavior related to the ordered_access property.
- Google Protocol Buffers integration
  - Google Protocol Buffers integration for Java5 and ISOC++V2 PSM's - OpenSplice is capable of using the Google Protocol Buffer (GPB) mechanism for modelling types in a DDS system. This makes it possible to use GPB as an alternative to OMG-IDL for those who prefer to use GPB rather than IDL. With the seamless integration of GPB and DDS technologies there is no need for OMG-IDL knowledge or visibility when working with GPB data models, and no OMG-DDS data-types are needed in the application (no explicit type-mapping between GPB and DDS types is required). Additionally, the GPB data structure can be evolved without breaking deployed programs that are compiled against an ‘old’ format. Check out the OpenSplice Google Protocol Buffers Tutorial for more details.
  - Google Protocol Buffers integration for the Tester tool - It is able to display its samples as regular field name and value pairs, just as if it were from a regular IDL defined topic. This feature is enabled for versions of OpenSplice that support Google Protocol Buffers. For more information, please see the new chapter on Google Protocol Buffers in the OpenSplice Tester Guide.
- Durability historical data alignment efficiency improvements
  - Until recently, a late joining durability service would always request the data set from its master. This would even happens in case the exact same set is already available on disk in its local persistent store. Rather than aligning the data set, the late joining durability service could better inject the data from its own persistent store in this case. This optimization reduces network bandwidth and increases startup time. This feature relies on the ability to compare data sets using the //OpenSplice/DurabilityService/NameSpaces/Policy[ @equalityCheck] attribute in the deployment guide.
  - The durability service now supports so-called 'align on change' functionality. temporary disconnections can cause durability services to get out-of-sync, meaning that their data sets may diverge. To recover from such situations merge policies exist that allow users to specify how to combine diverged data sets when they become reconnect again. Many of these situations involve the transfer of data sets from one durability service to the other. This may generate a considerable amount of traffic for large data sets. In case the data sets did not get out-of-sync during disconnection (because no data was written during the period of disconnection), it is not necessary to transfer data sets from one durability service to the other. A new configuration option has been implemented to force the durability service to compare data sets before alignment. When enabling this check a hashes are calculated of the data sets and compared for equality. When equal, no data will be aligned. This may save valuable bandwidth during alignment. If the hashes are different then the complete data sets will aligned.For further explanation and details on configuration, please check section about 'prevent aligning equal data sets' and the //OpenSplice/DurabilityService/NameSpaces/Policy[ @equalityCheck] attribute in the deployment guide
  - Durability service static content filtering - The durability service has been extended with support for static filtering of historical data. This allows for a reduction of the amount of aligned historical data if only a subset is required. Only data matching the statically configured filters will be aligned.
- Durability service CATCHUP merge-policy - The durability service now supports a new merge policy flavor called CATCHUP, which is similar to the existing REPLACE, but any instances that already exist in your local data-set and still exist in the 'remote' data-set, will not be marked with a NEW instance state as a result of the merge. This is useful in scenario's where one knows that an instance, once in use, is not re-used to describe a different object during the life-time of the data-set. For further explanation and details on configuration, please check section about merge-policies in the deployment guide
- The new Python Scripting Engine is now available. Python Scripting is a scripting environment for running unit tests and adhoc scripts against a Vortex OpenSplice environment and is meant as an alternative to the product specific Scenario language found in Vortex OpenSplice Tester. Python Scripting connects to the Vortex OpenSplice environment through the Configuration and Management API. It is based on the Python scripting language, and requires Jython 2.7.0 or later, the Java-based implementation of Python. For more information, please see the new chapter on the Python Scripting Engine in the OpenSplice Tester Guide.

## Vortex OpenSplice V6.5.2p1 contains the following new features:

- Support for Ubuntu 14.04 64 bit host to Ubuntu 14.04 for custom ARM V7 Marvell

## Vortex OpenSplice V6.5.2 contains the following new features:

- Source-specific multicast support for DDSI2E (Prototype) - DDSI2E now supports SSM on platforms that support it (all tier-1 platforms, i.e., Linux, Windows). It is enabled by specifying an SSM address in a network partition instead of a regular multicast, and only used when both reader and writer have it enabled. Interoperability with other vendors is limited to those also supporting the proposal informally known as "D84". Please note that although we'll do our best to solve any issues, this feature is not officially supported as it has only been marginally tested and is supplied without official documentation.. For more details on how to use this functionality, please check SSM notes
- RnR service support for QoS transformations - This feature allows replaying data that was recorded earlier with different QoS settings compared to the QoS settings of the recorded data. For more details check the RnR API guide
- RnR service support to split recordings over multiple files - This feature allows limiting file sizes (particularly useful when recording large volumes of data). For more details check the //OpenSplice/RnRService/Storage/rr_storageAttrXML/MaxFileSize or //OpenSplice/RnRService/Storage/rr_storageAttrCDR/MaxFileSize settings in the Deployment guide

## Vortex OpenSplice V6.5.1p1 contains the following new features:

- The generation of the OpenSplice system id can now be influenced through settings in the Domain/SystemId section of the OpenSplice XML domain configuration file. The Range element allows limiting the range, the UserEntropy element allows adding an arbitrary string to the initial entropy pool. This can be useful on platforms where all of the default inputs can be the same on two machines or across runs.

## Vortex OpenSplice V6.5.1 contains the following new features:

- Support for dynamic network partitions for RTNetworking - This feature allows users to amend the configuration of the RTNetworking service at runtime by means of a Topic-API. For more details, check the RTNetworking dynamic partitions guide
- Compression support for durability KV-persistence - The durability service currently has a KV-persistency implementation that allows persisting data to disk in either SQLite or LevelDB. Testing performance indicates that the disk is the bottleneck when trying to achieve a high throughput in some use cases. To improve throughput, samples can now be compressed by durability before persisting them (and obviously uncompressed before re-publishing them in DDS). Durability supports compression as a configurable option for KV persistence. For more details on how to configure it, please check section 4.3.3.9.3 of the Deployment Guide
- Support for Ubuntu 14.04 Linux For Tegra Nvidia Tegra K1 CPU ARM Cortex-A15 R3 host and target

## Vortex OpenSplice V6.5.0p10 contains the following new features:

- Support for Ubuntu 14.04 64 bit host to Ubuntu 14.04 for custom ARM V7

## Vortex OpenSplice V6.5.0 contains the following new features:

- A major refactoring of the API implementations (Java, C++, C#) to support future maintenance and feature extensions. This does not affect the API signature. A small performance benefit is also introduced.
- Following the introduction of C++ Streams at V6.2, this feature has now been added to the ISO C++ API. The ISO C++ Streams API provides a mechanism for batching samples together into a stream. This has the effect of increasing data throughput due to a reduced overhead which occurs when transmitting samples individually. The samples are appended to a stream and then later flushed which causes the samples to be written together as one batch. It is performant when a large number of samples need to be sent continuously. Full documentation is included in the ISO C++ documentation.
- Due to a bug fix in OpenSplice, Vortex Gateway 2.1.1 (and above)is required to route with OpenSplice V6.5 and above.

## OpenSplice DDS V6.4.3 contains the following new features:

- Java 5 language PSM for DDS - Next to the already existing OMG Java IDL language PSM for DDS API, OpenSplice now also supports the new OMG Java 5 language PSM for DDS (see http://www.omg.org/spec/DDS-Java/1.0/). The API is shipped as dcpssaj5.jar (stand-alone) / dcpscj5.jar (CORBA-cohabitated).
- Google Protocol Buffers integration for Java 5 PSM (BETA) - OpenSplice now also supports transparent publishing/subscribing of data types modeled in Google Protocol Buffers IDL (Java5 PSM API only for now). For more information about Google Protocol Buffers, click here. An example on how to use protocol buffers with OpenSplice can be found in the examples/protobuf directory within your OpenSplice installation. More elaborate documentation as well as support for other DDS language bindings will be introduced in future versions of the product.
- Networking bridge service - The new OpenSplice NetworkingBridge is a pluggable service that allows bridging of data between OpenSplice networking services. When a networking service is selected that best suits a specific deployment, sometimes a part of the data needs to be obtained from or disclosed to a system that is using a different kind of networking service. The NetworkingBridge allows DCPSPublications and DCPSSubscriptions to be matched and the related data forwarded between a (secure) RTNetworking system and a DDSI2(E) system and vice versa. More background information about the service as well as details on configuration can be found in the OpenSplice Deployment Guide.

## OpenSplice DDS V6.4.2 contains the following new features:

- OpenSplice is now robust against time discontinuities caused by adjusting the clock forward/backward or resuming after being hibernated/suspended. Read Section "Time Jumps" of the Deployment guide for more detailed information.
- Support for QNX 6.5

## OpenSplice DDS V6.4.1 contains the following new features:

- The new Launcher tool (accessible from bin/ospllauncher or the Windows Start Menu is available to make the evaluation process of OSPL easier). Only available on Windows and Linux.
- A new Node Monitor application is available that publishes the following system-monitoring data into the OpenSplice backbone:
  - CPU information and statistics
  - Memory statistics
  - Network interface information and statistics
  - Operating System information
  - Process information and statistics
  For more information, please see the Node Monitor Guide
- DDSI2 secure communication via SSL/TLS is now supported. This uses the OpenSSL library which can be enabled in conjunction with TCP support. The certificates and keys required for communication should be placed in a PEM format file, which is then referenced from the SSL component for the DDS configuration file. The pass phrase for this file should also be configured. By default clients verify servers by checking their X509 security certificates, however server verification of clients can also be configured. It is also possible via configuration to disable the validation of certificates, or enable self signed certificates, which by default are rejected. The set of Ciphers that can be used for encryption can also be configured if required, as can a file used to contain entropy (randomness) for the encryption ciphers. It is recommended that the O'Reilly book "Network Security with OpenSSL" is used as a reference to understand how SSL is best configured and deployed. See the Deployment Guide for further information.
- DDSI can discover entities and can generate builtin topic information. This enables non-OSPL Enterprise nodes in the DDSI network to become visible. Also, in cases where DDSI generates builtin topic information there is no need for durability to align builtin topic information, which saves bandwidth.
- RTnetworking now supports Differentiated Services Code Point (DSCP) field in IP packets on windows.
- Exception handling

  Up to this release, in a shared memory deployment mode, each process that used OpenSplice would attempt to clean up its shared resources in case it crashed. If for some reason the clean up failed, some of the shared resources could leak or in some edge cases the process could end up in a deadlock situation while cleaning up. In the V6.4.1 release, a new mechanism has been introduced that allows asynchronous clean-up of shared resources by the splice-daemon. The splice-daemon now detects when crashed processes leave shared resources behind and will try to cleans up if it is certain these resources have been left in a consistent state. In case (part of) the resources have not been left in a consistent state (this happens when a process crashes while modifying shared resources), it will terminate the entire middleware and return an error code.

  Together with the introduction of this garbage collection mechanism a new configuration element //OpenSplice/Domain/InProcessExceptionHandling is introduced. This element controls whether processes will try to release its shared resources upon a crash or not. By default processes will try to release resources, this is useful in case of application crashes which are unrelated to DDS operations, it will give any ongoing DDS operations time to become consistent before leaving the system and avoid any unnecessary system shutdown. In case an accurate core file is required this configuration element can be set to TRUE, meaning that processes will terminate immediately and leave all shared resources to be released by the service.

  For now, this feature only works on POSIX-compliant operating systems, but in the future this mechanism will be implemented for other operating systems as well.

Please note: Due to a Java IDL bug fix (OSPL-4333) introduced at 6.4.0p5, any customer using the Java API and upgrading to 6.4.1 from version 6.4.0 to 6.4.0p4 inclusive will need to recompile their IDL using idlpp. Application code does not need to be recompiled.

## OpenSplice DDS V6.4.0p4 contains the following new features:

- The ISO C++ PSM API's has been extended with a QoS provider API that allows users to define QoS settings for DCPS entities in an XML file as standardized in the DDS For Lightweight CCM OMG (DDS4CCM) standard.

## OpenSplice DDS V6.4.0 contains the following new features:

- The ISO C++ API has been taken out of beta status and is now the primary C++ API for OpenSplice DDS. Additionally, the new DDS-PSM-CXX specification IDL type mapping is now implemented. This allows simplified usage of IDL generated types through full compatibility with the STL. The older CORBA compatible types are also supported. Please see the ISO C++ Release Notes for further details
- A performance boost has been made to OpenSplice. The libraries are now consolidated to a single dcps library ddskernel, but the other libraries are still available as stubs to avoid user build system changes. Additionally, other optimisations have been introduced to increase performance and reduce CPU.
  Note: If you are using a static library OpenSplice build and 'ddskernel' is before any of the other dds libraries e.g. -lddskernel -lddsrrstorage -lddsos then you may get unresolved symbols that were previously satisfied by the 'ddsos' at the end of the link line. To resolve this move 'ddskernel' to the end of the link line.
- TCP support for DDSI has been implemented. Configuration options are available to run DDSI over a single connection.
- The CORBA cohabitation libraries have been upgraded to use TAO 2.1. Where customer demand exists for TAO 1.6 support, these have been left at TAO 1.6.
- The DCPS API's for Java, C, C++ and C# have been extended with a A QoS provider API that allows users to define QoS settings for DCPS entities in an XML file as standardized in the DDS For Lightweight CCM OMG (DDS4CCM) standard. Please see the Reference manuals for more information.
- Support for Visual Studio 2012 and 2013 on both 32-bit and 64-bit Windows platforms.
- Support for Raspberry Pi.
- New evaluation and benchmarking guide and examples. Please see the RoundTrip and Throughput examples.

## OpenSplice DDS V6.3.3p2 contains the following new features:

- The DCPS API's for Java, C, C++ and C# have been extended with a QoS provider API that allows users to define QoS settings for DCPS entities in an XML file as standardized in the DDS For Lightweight CCM OMG (DDS4CCM) standard.
- Support for Visual Studio 2013 on both 32-bit and 64-bit Windows platforms.

## OpenSplice DDS V6.3.2 contains the following new features:

- The Durability Service now supports the REPLACE and DELETE merge policies.
  - With the REPLACE merge policy it is possible to dispose and delete historical data on a node, and replace it with the transient and persistent data from another node. Immediately after successful completion of the REPLACE merge action the replacement data will be available to late joining readers, the data in the reader queue of existing readers will be disposed and replaced with the replacement data, and the generation count of the replacement data is increased.
  - With the DELETE merge policy it is possible to dispose and delete historical data on a node. Immediately after successful completion of the DELETE merge action the historical data in the reader queue of existing readers will be disposed and is not available any more to late joining readers.
  Please see the deployment guide for more details.

## OpenSplice DDS V6.3.1 contains the following new features:

- The Durability Service has new pluggable persistent stores. In previous versions, XML was allowed on all platforms and Memory Mapped File was also available on Linux only. From V6.3.1, Memory Mapped File is now deprecated. The new persistence stores are:

- SQLLite
- LevelDB

- The ISO C++ API (beta) has had a new set of features added. See the ISO C++ Release Notes for further details
- Support for Yocto Linux on Freescale P4080ds.

## OpenSplice DDS V6.3.0 contains the following new features:

- Record and Replay is taken out of beta and now considered a GA service. It includes the following new features:

- Compitability with the DDSI2/DDSI2E Services.
- The ability to remove record and/or replay interest without stopping a scenario.
- The ability to clear the contents of a storage during a scenario.

- DDSI2 and DDSI2E are now taken out of beta and considered as GA services. In completing the work on DDSI2 and DDSI2E, which includes adding support for IPV6, there has been a change to the configuration options. In all previous versions DDSI2 and DDSI2E used "Unsupported". This has now been changed to "Internal". Old configuration files will still be supported on V6 series, but a WARNING message will be raised to highlight the deprecated "Unsupported". The Internal configuration parameters are marked as such as they are subject to change in the future.
- A beta version of the ISO C++ PSM for DDS is now available. Documentation on what is supported in this beta version is available here.
- Performance optimisation for Java and C++ DataReaders to allow them to specify the number of threads to use when demarshalling data. Demarshalling data to a language-binding specific format can take considerable processing depending on the type of the data. Before this change this process was single-threaded and would therefore limit throughput, especially on multi-core platforms. See OSPL-1078 in the API changes section.
- The ospl tool is enhanced (see ospl -help for detailed info). It no longer returns negative error numbers. Its default is no longer stop, but -help.
- Support for kernel mode is added to the RTP support for VxWorks V6 series.
- Support for SMP (Symmetric MultiProcessing) on VxWorks V6 series.
- DLRL is deprecated. It will be removed from the product at V6.4.

## OpenSplice DDS V6.2.3 contains the following new features:

- Support for PikeOS 3.1.7 on PowerPC for Windows hosts..
- Support for VxWorks 6.9 on Pentium for Windows hosts.
- Support for VxWorks 6.9 on Pentium3 for Windows hosts.
- Support for VxWorks 6.9 on PowerPC P1010/P1013 for Windows hosts.

## OpenSplice DDS V6.2.2 contains the following new features:

- Support for PikeOS 3.3. As part of this, the PikeOS port builds against the BSD Posix library rather than the NewLib implementation which is removed in 3.3.

- Changes to the way read- and take-operations access data. The read- and take-operations now provide data circularly, meaning that these operations will 'resume' a previous read just as if read_next_instance was successively called. This way all instances can be read even when for example lower key-values get updated between two read-operations with a max_samples limit.
- Support has been added for kernel mode for VxWorks 6.8 PENTIUM4 target.
- Support has been added for SMP kernels for the VxWorks 6.8 PENTIUM4 kernel mode build.

- Adds configurability for data compression in the networking service. This allows tuning of the existing (zlib) method, adds two alternative fast compressors (lzf and snappy) and provides a plugin api for using other mechanisms.

- Recording and Replay Service (beta version)
  A second beta version of ADLINK's new recording and replay service. This version supports:
  - Replay the recorded data with different speeds
  - The ability to add time conditions to a command that can delay its processing
  - Statistics on the record and replay of data

## OpenSplice DDS V6.2.0 contains the following new features:

#### New product add-ons:

- DDSI-Extended (ddsi2e): DDSI2E is a new beta version of the extended version of ADLINK's DDSI2 networking service, giving extra features for:
  - Network partitions : Network partitions provide the ability to use alternative multicast addresses for combinations of DCPS topics and partitions to separate out traffic flows, for example for routing or load reduction.
  - Security : Encryption can be configured per network partition. This allows configuring encrypted transmission for subsets of the data.
  - Bandwidth limiting and traffic scheduling : Any number of "network channels" can be defined, each with an associated transport priority. Application data is routed via the network channel with the best matching priority. For each network channel, outgoing bandwidth limits can be set and the IP "differentiated services" options can be controlled.
- OpenSplice Streams : OpenSplice Streams API supports a common data-distribution pattern where continuous flows or streams of data have to be transported with minimal overhead and therefore maximal achievable throughput. For more information see the OpenSplice Streams Reference Manual.
- Recording and Replay Service (beta version)
  A first version of ADLINK's new recording and replay service. This version supports:
  - Record topics to an xml storage
  - Manipulate the recorded data
  - Ability to control the recording and replay service remotely
  - A new tool (separate installer) to drive the recording and replay service and view its output.

#### Other new features:

- Extensible and Dynamic Topic Types annotations now handled in IDL : As a first step to the implementation of the OMG standard for Extensible and Dynamic Topic Types for DDS, a developer can now annotate their IDL as per the specification and when the implementation of the specification becomes available (OpenSplice DDS V7) then no further IDL changes should be required.
- OpenSplice RMI extensions:
  - Instances Management: Requests/Replies topic instances are per-client basis. The topic key is {client_name, client_instance}. To support multithreaded clients a configuration option named '--RMIClientThreadingModel' has been added to take two possible values 'ST' (Single Thread) or 'MT' (Multi Thread). The MT option will set the history qos to KEEP_ALL and allow then the client to be multithreaded.
  - Service activation: The server activation has been changed to decouple the service activation from the service registration. This activation supports two modes: a blocking mode where the run operation blocks the calling thread, and a non blocking mode where the calling thread can perform other tasks after calling "run".
  - Error handling and exceptions: Error reporting has been enhanced with the definition of two new exceptions : INTERNAL_ERROR to report any internal operation failure and SERVICE_NOT_FOUND to report the failure to find a requested service.
  - The default Replies waiting timeout has beed increased to 10min (it was set to 1millisec).
  - Asynchronous invocation mode has been added, which is similar to the CORBA Asynchronous Messaging Interface (AMI) call-back model, in addition to the conventional synchronous mode. The RMI documentation has been updated and new examples (Printer and HelloWorld) have been added to illustrate the usage of this invocation mode.
  For more information see the OpenSplice RMI GettingStarted Guide.
- Windows Services improvements and it is now able to write to the System Event Log, for more details see OSPL-593 below.

#### Potential upgrade change:

- In previous releases only a subset of the OpenSplice CORBA co-habitation DCPS Java API (dcpscj.jar) was generated using a CORBA ORB. Starting from this release (issue ospl-347), the entire CORBA-Java API is generated by the ORB IDL compiler. This enables customers to use internal types like ReturnCode_t and InstanceHandle_t in a CORBA environment, i.e. Helper and Holder classes are now available for those types as well. This changes the steps required to process your application Topic definition IDL files, to compile the generated and application source code, to run applications, and how Listener classes must be written. Additionally extra care must be taken not to mix the CORBA and Standalone DCPS APIs on the same compilation or VM classpath.
  - IDL to Java code generation changes

    Given the below IDL definition:
    /* @file: Foo.idl */
    struct Bar {/
    long key;/
    };/
    #pragma keylist Bar key/

    At OSPL 6.1 the required CORBA-Java DCPS code-generation steps were:
    1 / $JACORB_HOME/bin/idl Foo.idl/
    This produced files:/
    BarHelper.java/
    BarHolder.java/
    Bar.java/
    2/ $OSPL_HOME/bin/idlpp -C -l java Foo.idl/
    This produced files:/
    BarDataReaderHelper.java/
    BarDataReaderHolder.java/
    BarDataReaderImpl.java/
    BarDataReader.java/
    BarDataReaderOperations.java/
    BarDataReaderViewHelper.java/
    BarDataReaderViewHolder.java/
    BarDataReaderViewImpl.java/
    BarDataReaderView.java/
    BarDataReaderViewOperations.java/
    BarDataWriterHelper.java/
    BarDataWriterHolder.java/
    BarDataWriterImpl.java/
    BarDataWriter.java/
    BarDataWriterOperations.java/
    BarMetaHolder.java/
    BarSeqHolder.java/
    BarTypeSupportHelper.java/
    BarTypeSupportHolder.java/
    BarTypeSupport.java/
    BarTypeSupportOperations.java/
    Now at OSPL 6.2 the required steps are:
    1/ $JACORB_HOME/bin/idl Foo.idl
    This step is the same as 6.1 and produces the same files.
    2/ $OSPL_HOME/bin/idlpp -C -l java Foo.idl
    This step is the same command as 6.1 however the files produced are now: BarDataReaderImpl.java
    BarDataReaderViewImpl.java
    BarDataWriterImpl.java
    BarMetaHolder.java
    BarTypeSupport.java
    FooDcps.idl
    3/ $JACORB_HOME/bin/idl -I$OSPL_HOME/etc/idl FooDcps.idl
    This step is new at 6.2 and processes the *Dcps.idl file now produced by step 2 with the ORB IDL compiler. This produces the below files, per the IDL to Java mapping: BarDataReaderHelper.java *
    BarDataReaderHolder.java *
    BarDataReader.java *
    _BarDataReaderLocalBase.java
    BarDataReaderLocalTie.java
    BarDataReaderOperations.java *
    BarDataReaderViewHelper.java *
    BarDataReaderViewHolder.java *
    BarDataReaderView.java *
    _BarDataReaderViewLocalBase.java
    BarDataReaderViewLocalTie.java
    BarDataReaderViewOperations.java *
    BarDataWriterHelper.java *
    BarDataWriterHolder.java *
    BarDataWriter.java *
    _BarDataWriterLocalBase.java
    BarDataWriterLocalTie.java
    BarDataWriterOperations.java *
    BarSeqHelper.java
    BarSeqHolder.java *
    BarTypeSupportInterfaceHelper.java
    BarTypeSupportInterfaceHolder.java
    BarTypeSupportInterface.java
    _BarTypeSupportInterfaceLocalBase.java
    BarTypeSupportInterfaceLocalTie.java
    BarTypeSupportInterfaceOperations.java
    Files marked with an * were previously produced by step 2 (i.e. idlpp); note the file BarTypeSupportOperations.java is no longer produced by any step.

  - CORBA co-habitation Java DCPS compilation
    At 6.1 it was sometimes possible to compile code generated as above and / or applications like:
    javac -classpath javac -cp .:$OSPL_HOME/jar/dcpscj.jar BarDataReader.java
    For compilation errors to be avoided this must now always be:
    javac -endorseddirs $JACORB_HOME/lib/endorsed -cp .:$OSPL_HOME/jar/dcpscj.jar BarDataReader.java
    ...or...
    javac -Djava.endorsed.dirs=$JACORB_HOME/lib/endorsed -cp .:$OSPL_HOME/jar/dcpscj.jar BarDataReader.java
    See http://docs.oracle.com/javase/7/docs/technotes/guides/standards/
  - Running CORBA co-habitation Java DCPS applications
    At 6.1 it was possible to sometimes run applications like:
    java -classpath .:$OSPL_HOME/jar/dcpscj.jar FooApp
    At 6.2 this form must be used instead:
    java -classpath .:$OSPL_HOME/jar/dcpscj.jar -Djava.endorsed.dirs=$JACORB_HOME/lib/endorsed FooApp
    See http://docs.oracle.com/javase/7/docs/technotes/guides/standards/
  Because all classes are now properly implementing CORBA interfaces and inheriting from CORBA base classes, derived classes will be required to provide an implementation for all abstract operations mentioned in the generated interface from the LocalObject base.
  One option is to add no-op implementations of the abstract Object base methods e.g.:
  public org.omg.CORBA.Object _set_policy_override(org.omg.CORBA.Policy[] policies, org.omg.CORBA.SetOverrideType set_add) { return null; }
  public org.omg.CORBA.DomainManager[] _get_domain_managers() { return null; }
  public org.omg.CORBA.Policy _get_policy(int policy_type) { return null; }
  public org.omg.CORBA.Request _create_request(org.omg.CORBA.Context ctx, java.lang.String operation, org.omg.CORBA.NVList arg_list, org.omg.CORBA.NamedValue result, org.omg.CORBA.ExceptionList exclist, org.omg.CORBA.ContextList ctxlist) { return null;
  public org.omg.CORBA.Request _create_request(org.omg.CORBA.Context ctx, java.lang.String operation, org.omg.CORBA.NVList arg_list, org.omg.CORBA.NamedValue result) { return null; }
  public org.omg.CORBA.Request _request(java.lang.String operation) { return null; }
  public org.omg.CORBA.Object _get_interface_def() { return null; }
  public void _release() {}
  public org.omg.CORBA.Object _duplicate() { return null; }
  public int _hash(int maximum) { return 0; }
  public boolean _non_existent() { return false; }
  public boolean _is_equivalent(org.omg.CORBA.Object other) { return false; }
  public boolean _is_a(java.lang.String repositoryIdentifier) { return false; }
  public org.omg.CORBA.Object _get_component() { return null; }
  public org.omg.CORBA.InterfaceDef _get_interface ( ) { return null;
  Alternately, for the case of Listeners, OpenSplice supplies the ListenerBase class as a convenience. When Listeners extend from this base class they are no longer required to implement these operations themselves. So a Listener defined like:
  public class MyReaderListener implements DataReaderListener {
  ...
  could instead be defined:
  public class MyReaderListener extends org.opensplice.dds.dcps.ListenerBase implements DataReaderListener {
  ...
- CORBA & Standalone Java DCPS API jar incompatibility
  Previously the dcpscj.jar & dcpssaj.jar were largely identical and could often reside safely on the same CLASSPATH. In fact, the release.com/.bat script provided with OpenSplice placed both jars on the exported/set CLASSPATH environment variable. This is no longer the case - users must take care to specify the correct jar on their CLASSPATH when building and running applications as they are now incompatible. For this reason the release.com/.bat scripts no longer exports/sets any CLASSPATH value.

## OpenSplice DDS V6.1.1p7 contains the following new features:

- Support for Client Side Durability with Vortex Lite. Vortex Lite can now act provide a persistence capability using a running instance of the OpenSplice Durability Service.

## OpenSplice DDS V6.1.1p5 contains the following new features:

- Support for Secure Networking on LynxOS 5.0 added

## OpenSplice DDS V6.1.1p3 contains the following new features:

- Support for Linux host to WindRiver Linux PowerPC and x86 targets.

## OpenSplice DDS V6.1.1p2 contains the following new features:

- Support for Windows host to VxWorks 6.9 PENTIUM 4 target.

## OpenSplice DDS V6.1.1p1 contains the following new features:

- Official support for ElinOS 5.1 with gcc 4.4 for x86

## OpenSplice DDS V6.1.1 contains the following new features:

- Official support for RHEL 6.0 platform with gcc 4.4

## OpenSplice DDS V6.1.0 contains the following new features:

- A new OpenSplice DDS deployment architecture which offers daemon-less deployment to go alongside the existing daemon (shared memory) deployment is now available. The new daemon-less library mode is what we call a Single Process deployment option where an application will dynamically link at runtime all OpenSplice libraries and services into a single operating-system process. For more information see Chapter 1 of the Deployment Guide. The choice of daemon or daemon-less architecture can be made by simply changing the ospl configuration file, and therefore does not require any application code changes nor re-generation of the application. Users on windows will find this particularly useful to avoid the need to find a free location in shared memory for the nodal administration database.
- OpenSplice RMI, a new set of APIs available with OpenSplice DDS that complement the pub/sub integration pattern of DDS with a new/client server pattern, but over 1 middleware. For more information on this exciting new addition to the OpenSplice DDS product line, please see the OpenSplice RMI Getting Started Guide.
- OpenSplice Tester, a tool aimed at automated regression testing and debugging of OpenSplice DDS based systems is now available. For more information on this exciting new addition to the OpenSplice DDS product line, please see the OpenSplice Tester Guide and/or use the builtin help of the Tester itself.
- Support for data reader TIME_BASED_FILTER Qos Policy
- The OpenSplice configurator is context sensitive to the enabled features and will only allow access to attributes of relevance (for either the community or commercial edition used).
- DDSI2 now allows setting the multicast time-to-live for outgoing packets using the General/MulticastTimeToLive element. Setting the time-to-live differently for each multicast address is not yet possible.
- Code for a plugin for Wireshark, which will allow decoding of Real Time networking packets is provided. For more information see the README in tools/wireshark-plugins/ospl.
- New platform support

- Support for Windows x86 64 bit.
- Support for Solaris SPARC 32 bit with gcc compliler.
- Support for RTEMS 4.10.0 on leon3 SPARC architecture.
- Support for LynxOS 5 on PPC architecture.
- Support for PikeOS 3.2 on x86.

- Changes to source code available

- DLRL is now open source.
- SOAP Service is now open source.
- As stated in later 5.x series releases, the DDSIv1 code has been removed. It was replaced by DDSiv2.
- As DDSIv2 is the interoperable standard and open source, Real Time networking is closed source.
- As daemon-less architecture is now commercial quality and open source, shared memory is now closed source.

## Fixed Bugs and Changes not affecting API

## 6.9.2p6

Report ID. | Description
--- | ---
OSPL-11809 / 00018836 | Possible crash after detaching domains in a multi-domain application A second case was discovered in the user-layer code that protects access to the kernel (see previous OSPL-11809 release note). A small window exists that allows a thread to access kernel memory while the domain is already detached. Solution: The previous fix involved protecting access for threads leaving a protected (kernel) area. Entering the kernel also contained an issue, fixed by storing the relevant data in the user-layer so it can be accessed safely.
OSPL-12342 | Crash of the spliced service when using OSPL_LOGPATH. Possible crash of the spliced service (in shared memory configuration) or application (in single process configuration) when the the user sets the environment variable OSPL_LOGPATH. Solution: Crash was caused by the spliced which tried to free the memory of the variable returned by the getenv operation. It is not required and not allowed to free the returned variable. The problem is solved by removing the free from the code.
OSPL-12454 | Similar conflicts are not always combined, which may potentially lead to slow or failing alignment. The durability service is responsible for keeping states consistent. Whenever an event happens that requires the durability service to take action (e.g., a disconnect/reconnect) a so-called conflict is generated that needs to be resolved. Under certain circumstances multiple but similar conflicts can be generated. Because these conflicts are similar it is sufficient to only resolve one of them. However, due to a bug is was possible that multiple similar conflicts are generated and resolved sequentially. In particular, it was possible that multiple conflicts are generated with a rate that effectively causes the conflict queue never to become empty. Because the durability service only advertises group completeness when the conflict queue is empty, this could effectively lead to stalling alignment. Solution: The algorithm to decide when conflicts are similar is changed, so that similar conflicts are now being discarded.

## 6.9.2p5

Report ID. | Description
--- | ---
OSPL-12252 / 00019073 | Out of memory due to memory leakage Various memory leaks in shared memory caused out of memory errors when calling API functions Memory leaks fixed

## 6.9.2p4

Report ID. | Description
--- | ---
OSPL-12211 | Durability service with legacy master selection not directly slaving to existing master A durability service with the highest fellow id and an unconfirmed master starts legacy master selection it fails to slave to the existing master until it start majority voting Solution: Existing master selected sooner
OSPL-12133 / 19018 | After reconnect durability not aligned when fellow returns within 2*heartbeatPeriod and legacy masterselection algorithm is used When a fellow connects to a durability service a connect conflict is created. When this happens within twice the heartbeatPeriod after a fellow got disconnect the durability service potentially lost its master. When it lost master the connect conflict is discarded because no master selected, this could lead to inconsistent data states. Solution: Connect conflict is not discarded when no master selected. The conflict remains until a merge-action is applied

## 6.9.2p3

Report ID. | Description
--- | ---
OSPL-11873 | Possible application crash when using OpenSplice as windows service. In V6.9.2p2 a fix was made for the issue that when OpenSplice was used as a windows service and when an application was started an access violation could occur. Unfortunatly a part of the fix was not put into the V6.9.2p2. This is now corrected. Solution: The complete solution is now added and the crash should not occur anymore.

## 6.9.2p2

Report ID. | Description
--- | ---
OSPL-12016 | Logrotate not working correctly with OpenSplice log files. When using logrotate with the RTNetworking service the rotating works ok but the truncate function does not work properly. Solution: The problem is fixed and the RTNetworking service now can be properly truncated.
OSPL-12007 | When the idl contains a union with an unsigned short as discriminant, then serialization may fail on big endian hosts. If the idl contains a union with an unsigned short discriminant (and only an unsigned short), the constants for the case labels are represented in the OpenSplice metadata as a different type than the type of the discriminant itself. In the process of converting the type into instructions for the serializer VM, the case labels are read from memory as-if their representation is that of the discriminant type (even though the values carry a type indication themselves, and this type indication is correct for the actual value). On a big-endian machine, it therefore reads all case labels as 0. Consequently, any case that differs from 0 will be handled as case 0. This will lead to an invalid serialization. User may experience this as a communication problem. Solution: The constants for the case labels are now correctly represented in the OpenSplice metadata.
OSPL-12010 | Tester, Tuner, and Jython scripting fail to write samples containing sequence of enum When writing a sample with any of the above tools, whose type contains sequence of enumeration type, then any readers will receive the sample with the sequence empty. This is due to an error in the writing side serialization for sequence of enum types. Solution: Fixed the serializer in the underlying api to account for sequence of enum types.
OSPL-11965 | Possible crash in durability termination when handling an event The durability service could crash during termination when handling an event in the "AdminEventDispatcher" thread during termination as the "conflictResolver" thread was stopped first and the events could be dependent on this threads administration Solution: Stop "AdminEventDispatcher" thread before "conflictResolver" thread
OSPL-11873 | Possible application crash when using OpenSplice as windows service. When using OpenSplice as a windows service under a different user as the application a possible application crash can occur due to a permission problem. An indication of when this is occurring can be when the following message occurs in the error log: "Failed to allocate a wait handler on process handle, System Error Code: 87" Solution: The permission problem is fixed and the user application can now correctly communicate with the service.
OSPL-11829 | RnR service property file incompatibility When using the RnR service on windows the property file thats being created has windows line terminating endings (^M) When using this propery file under linux this can cause problems. Solution: The problem is fixed and the property file incompatibility is now gone.
OSPL-11809 | Possible crash in write after detach_all_domains It was possible that a multithreaded application would crash when calling detach_all_domains and a other API call that would access the domain concurrently. I was possible that the other API call accessed the domain while it was detaching which caused the crash could crash when it called a DataWriter_write function after it called detach_all_domains because Solution: No longer possible to access the domain while detaching
OSPL-11807 | No SSL support for ddsi in Community Edition According to the documentation, it should be possible to configure ddsi to use SSL, even in the Community Edition. Also the ddsi code base in the Community Edition contains everything needed to support SSL. The only reason why SSL support is not available in the Community Edition was that the build files were not explicitly including this feature by passing the appropriate macro and including the required SSL libraries. Solution: The build files have been modified: if SSL support is available on the build platform, SSL support will be enabled by default on the Community Edition.
OSPL-11778 | Merge state incorrectly updated when last partition.topic in namespace did not change while others did OSPL-10113 addressed an issue where merging with an empty set could lead to a state update even when a data set was not changed. It only looked at the last aligned partition.topic in the namespace for changes in stead of all partition.topics part of the namespace and thus something didn't update the namespace state while it had to Solution: Look at all partition.topics in the namespace to determine if the namespace state needs to be updated
OSPL-11690 | A booting node with an aligner=FALSE policy may not reach the complete state in case it has not detected all namespaces from its aligner in time. If a node has a namespace with an aligner=FALSE policy then the node should only reach completeness in case an aligner becomes available. Due to an unlucky timing it is possible that the node detects an aligner but has not yet received all of its namespaces. In that case the node will not request the completeness state of the group (i.e., partition/topic combinations) from its aligner while traversing its initial startup procedure. Because it does not request the groups from the aligner, the node will not known that the aligner has all its groups complete, and therefore never requests data from the aligner. This causes the node to never reach the completeness state. Solution: Group information is now always requested from aligners if not done so already.
OSPL-8553 | Shared memory java applications not working on windows 10 64 bit with Java 8 When using Shared memory with windows 10 64 bit and Java 8 it can happen that java applications wont connect to the shared memory. Solution: The OpenSplice default shared memory address for windows 64 bit is now changed to 0x140000000. The old default 0x100000000 shared memory address was in the memory range of the Java 8 jvm.
OSPL-11913 | Dynamic namespace not learned when only received once The durability service is able to learn namespace published by fellow durability services, these are called dynamic namespace. Dynamic namespace were only learned by the durability service when the fellow was in approved communication state and this state was only reached when all namespace were received. Solution: When the fellow reached approved communication state the received dynamic namespaces are now learned.
OSPL-11540 | When client durability and ddsi is used between OpenSplice nodes alignment of historical data may fail if relevant readers are not discovered in time. One way to obtain historical data is using client durability. When ddsi is used as networking service, a precondition of a durability service to sent historical data is that the client's historicalDataReader must have been discovered. By default, a durability client in OpenSplice sends requests with a timeout of 10 ms, so that a server will answer the request within 10 ms. However, in case the server has not discovered the historicalDataReader from the client within this time, the server sends an error message. Consequently, the client will not receive the data. This situation typically appears when the server is unable discover the cleint's reader on time, e.g., when network latencies are "large". Solution: Whenever the server receives a historicalDataRequest from a client and the remote readers have not yet been discovered the client's historicalData reader, then the server will sent when the reader is discovered or send an error notification when 30 seconds has passed, whatever comes first.

## 6.9.2p1

Report ID. | Description
--- | ---
OSPL-11708 | Out of order delivery of invalid message might corrupt instance state In the V6.9.1, a bug was introduced where out-of-order delivery of an invalid message might corrupt the instance state, resulting in undefined behavior. Out-of-order delivery occurs when your Reader is using BY_SOURCE_TIMESTAMP ordering and a message with a source timestamp older that the currently stored message is being delivered. Solution: The ordering algorithm has been modified so that this scenario no longer corrupts the instance state.
OSPL-9054 | Leakage of JNI local refs when using the Java API When using the Java API and taking a lot of samples at once it could happen that the JNI local refs exceed the JNI local ref limit. Solution: The leakage is fixed and will not occur anymore.
OSPL-11671 | Missing initial dynamic network configuration state When using RT Networkservice in combination with dynamic network configuration it could happen that the initial publication of the dynamic network configuration state would not happen. Solution: The problem is fixed and the initial dynamic network configuration state is now always published.
OSPL-11718 | The dcpsPublicationListener is not freed correctly when durability terminates When client durability is enabled, the durability service creates a reader that listens to DCPSPublication messages. When durability is terminated this reader was not cleaned up correctly, which could lead to a memory leak. This problem can only surface when client durability is enabled. Solution: The reader is cleaned up correctly.
OSPL-11550 | Inefficient alignment in case of master conflicts for the same namespace with different fellows When nodes becomes temporarily disconnected, they may choose different masters to align from. When reconnected again this leads to a situation where there are multiple masters in the system. To resolve this situation a master conflict is scheduled that needs to be resolved. Resolving a master conflict leads to choosing a single master again, and in many cases leads to alignment between nodes. Currently, a master conflict is generated per namespace per fellow (i.e., a remote durability service). In case there are many fellows this will lead to many conflicts, and hence many alignments. It is not necessary to generate a conflict per fellow to recover from such situation. Solution: Whereas in the past two master conflicts for the same namespace with different fellows led to different conflicts that each needed to be resolved, they now lead to a duplicate conflict that is dropped. This decreases the number of master conflicts in case there are many fellows, and hence may decrease the number of alignment actions that will occur.
OSPL-11531 | Similar conflicts can be resolved multiple times The durability service monitors the state of fellow durability services to detect any discrepancies between them. If there is a discrepancy, a conflict is generated to resolve this discrepancy. Before a conflict is added to the queue waiting to be resolved, a check is done to see if a similar was not already queued. If so, the newly generated will not be added to the queue of pending conflicts. What is not checked is whether the conflict that is currently being resolved is similar to the one that is generated. Consequently, if a conflict (say conflict 1) is being resolved and another conflict (say conflict 2) is being generated, and conflict 1 and conflict 2 are similar in the sense that they should resolve the same discrepancy, then conflict 2 may still be added to the queue of pending conflicts. This may cause that the same conflict is being resolved multiple times. Solution: Before a conflict is added to the queue it is checked whether the current conflict is similar.
OSPL-11606 | Sample validation by DataWriter may cause compilation issues when enabled By default the ISOCPP2 DataWriter does not validate sample input against for example the bounds specified in IDL. In order to enable bounds checking, the macro OSPL_BOUNDS_CHECKING should be set when compiling the idlpp output. However, when setting this macro it might turn out that some of the generated code might not compile. Solution: Bounds validation has been corrected, and is now also enabled by default. This is because the importance of bounds checking far outweighs the tiny bit of extra overhead introduced by it.

## 6.9.2

Report ID. | Description
--- | ---
OSPL-11753 | Dispose all data not processed by remote nodes When doing a dispose_all_data call on a topic, local instances are disposed and a DCPSCandMCommand sample is published on the network, for other nodes to dispose instances of that topic as well. The sample is processed by the builtin-subscriber of spliced, which in turn disposes relevant instances. A bug in spliced, related to setting the event-mask, causes it to not wake-up when new data is available, and therefore no instances are disposed on remote nodes. Solution: The bug was fixed by properly setting the data-available event-mask.
OSPL-11500 | The mode to store data in human-readable format in the KV store was undocumented, and trying to use it would lead to an error. The KV store is an efficient implementation of a persistent store that by default stores data as blobs that are difficult to interpret by humans. The KV store can be configured to store the data in human-readable format, but unfortunately this mode was not documented. Because only valid configurations can be used to start OpenSplice and this option was not documented, it was considered invalid. Therefore, it was not possible for a user to configure the KV store in human-readable format. Solution: The option to configure the KV store has now been documented and does not lead to an error any more. See //OpenSplice/DurabilityService/Persistent/KeyValueStore[@type] for more information.
OSPL-11398 | idlpp generated code for C# has several issues with respect to handling IDL collections and unions. The idlpp backend for C# generates code that has several issues when dealing with IDL collections and unions. Examples of things that would fail to compile or fail to work were: Sequences of arrays and arrays of sequences. Sequences of boolean and sequences of char in unions. Sequence of unions. Inner types (structs/unions inside of other structs/unions). Sequence of enumerations in unions. Solution: The C# backend of idlpp has been modified to generate code that does solve these cases correctly.
OSPL-11533 | C99: dds_instance_get_key seg faults with generic copy-out method When using the C99 dds_instance_get_key function on a generic data writer, a seg fault happens in the generic copy out function due to a null pointer Solution: Added the code missing to copy data to the DDS_DataWriter_get_key_value so that it now works when using generic copy routines. DDS_DataWriter_get_key_value is called by the C99 dds_instance_get_key, causing the seg fault in the copy our routine
OSPL-11774 | Added <Verbosity> tag to the native NetworkingService <Tracing> configuration. Before the NetworkingService only supported tracing categories where for each category a trace level 0..6 could be specified. All other services provided a <Verbosity> tracing option where a trace level 0..6 could be specified. Solution: The new NetworkService <Verbosity> option is an additional way to set tracing levels besides the existing tracing category configuration option. The category options specify the trace level per category whereas the new verbosity option set the trace level for all categories.
OSPL-11799 | Dbmsconnect incompatibility with MS SQL 2017. When using the Dbmsconnect service replication functionality with MS SQL 2017 triggers do not function as expected. Solution: The fault in the replication functionality in dbmsconnect is now fixed.
OSPL-11593 / 18657 | Potential race condition between threads creating/deleting DomainParticipants. When an application has multiple threads that are creating and deleting participants into the same Domain in parallel, a race condition may occur between the thread deleting the last participant to that Domain (and thus implicitly deleting the Domain itself) and a thread that is creating a new participant to that Domain (and thus implicitly creating the Domain that is in the process of being deleted). Solution: The race condition has been removed by synchronizing threads that create and destroy DomainParticipants.
OSPL-11707 / 18758 | Representation of IDL constants not correct in many language bindings of idlpp. The representation of IDL constants in many of the language bindings of idlpp was incorrect. For example, negative numbers in in C/C++ could result in compilation warnings and in Java in compilation errors. Also the representation of an enumerated constant would result in compilation errors in ISOCPP2, C# and Java. Solution: Representation for constants has been corrected in all the above languages.
OSPL-11124 / 18494 | ISOCPP2 Topic proxies do not correctly handle their reference to the DomainParticipant. When creating topic proxies of type dds::topic::AnyTopic or of type dds::topic::TopicDescription using the dds::topic::disover_all() function, then releasing the participant before releasing the proxies themselves results in a NULL pointer dereference and a subsequent crash. Solution: All Topic proxies now correctly manage their reference to the participant so that they keep the participant alive for as long as the proxy is alive itself.
OSPL-11289 / 18567 | Idlpp generates ISOCPP2 code that may not compile for an Array with elements that are a typedef to some other type. When using the ISOCPP2 backend of idlpp to compile an IDL model that has an array with elements that are a typedef to some other types, the generated C++ code will not always compile with a C++ compiler. Solution: The ISOCPP2 backend has been modified to generate C++ code that does compile correctly for these types of IDL constructions.
OSPL-11639 / 18694 | Invalid memory access when caching is disabled on client-durability policies. An issue with memory allocation in the client-durability thread of spliced can lead to a buffer overrun resulting in undefined behaviour. The issue can be triggered by enabling client-durability and configuring a policy with disabled historical data caching. Solution: The code responsible for the buffer allocation was fixed.
OSPL-11647 / 18694 | Data-available and data-on-readers events not triggered when mask includes other events. When a mask is set to include i.e. liveliness or other events, in addition to data-available and/or data-on-readers events, the latter may not be triggered when a different event is queued and not processed yet by relevant listener(s) . This issue mostly occurs directly after creation of a DataReader for which an active writer exists. Creation triggers liveliness and subscription matched events, when a sample is delivered before these events are processed, the data-available and data-on-readers events are not raised. Note that in the C99 API, entities are created with an "ANY" mask by default, therefore it is much more likely to occur. Solution: The issue was fixed by improving the code responsible for merging events, taking into account different event types.
OSPL-11703 | Python binding: Segmentation violation when attempting to read/take topic data with zero-length sequences. For statically generated Python code (via idlpp -l python), a segmentation violation my result if topic data is read that contains a zero-length sequence. This could occur as the result of reading or taking a sample that corresponded to a disposed instance (in which only key fields are set), as well as with actual instances that have been written with an empty sequence. Solution: Empty length sequences are now handled correctly on read/take.
OSPL-11601 / 18659 | Compile warnings in Corba-Java code generated by idlpp. When compiling classes generated by idlpp in Corba-Java mode, with a recent compiler, warnings occur because certain classes, inheriting from a Serializable base-class, lack the required serialVersionUID member. Note that it is auto-generated if missing, so does not cause any runtime issues. It does trigger compile warnings if compiled with -Xlint:all. Solution: The serialVersionUID was added to relevant idlpp templates so that generated code can be compiled warning-free.
OSPL-11651 | The ISOCPP2 API had one file that was published using the LGPL license. The implementation of the dds::core::array was taken from the std::array and was therefore referencing the LGPL license under which it was released. For OpenSplice users that want no dependency on LGPL this could have undesired legal consequences. Solution: The code that was published under LGPL has been removed, and is replaced by references to the std::array, the std::tr1::array or the boost::array, depending on the context of the compiler.
OSPL-11711 | Possible deadlock in multidomain waitset during object destruction. When using a waitset in a multidomain scenario it was possible that the internal multidomain runner thread caused the application thread to deadlock when trying to delete an object attached to a waitset as the internal thread could miss the deletion trigger. Solution: Made the deletion trigger persist so that it can no longer be missed.
OSPL-11815 | IDLPP generating incorrect Python on Windows platforms. The IDLPP Python language binding (-l python) produces incorrect Python code when run on Windows platforms. The generated python includes numerous references to $s, which is invalid python syntax. Solution: Python generation on Windows has been fixed.

## 6.9.1p1

Report ID. | Description
--- | ---
OSPL-11581 | OpenSplice doesn't communicate with OpenDDS DDSI rejects all incoming RTPS messages which have a different RTPS version than the OpenSplice DDSI implementation, were it should accept messages with equal or newer RTPS implementation versions. DDSI now accepts incoming RPTS messages that have an equal major version and an equal or newer minor version
OSPL-11651 | The ISOCPP2 API had one file that was published using the LGPL license The implementation of the dds::core::array was taken from the std::array and was therefore referencing the LGPL license under which it was released. For OpenSplice users that want no dependency on LGPL this could have undesired legal consequences. The code that was published under LGPL has been removed, and is replaced by references to the std::array, the std::tr1::array or the boost::array, depending on the context of the compiler.

## 6.9.1

Report ID. | Description
--- | ---
OSPL-11629 | Missing historical data when using alignee is ON_REQUEST On wait_for_historical_data the reader generates a HISTORICAL_REQUEST event. When the durability service receives this event is sends out a historical data request. The durability service never received the event due to an error in the internal waitset implementation, it was not thread safe. Made the internal waitset thread safe
OSPL-11595 | Wrong master selected for federations with same master priority Master selection is done based on 3 variables, namely in priority order: master priority, store quality and systemId. I was possible that on federations with same master priority and no store the federation with the lowest systemId was selected as master because the store quality was set to a random value instead of zero. Set the store quality to zero when no store is used
OSPL-11236 | Instance purged before auto-purge delay is expired. When using an autopurge_nowriter_samples_delay or autopurge_disposed_samples_delay in a DataReader QoS, an instance can be purged before the delay is expired. The time comparison to determine if a delay is expired, uses the monotonic clock implementation. This means an invalid time-stamp can be returned if the "current" monotonic time is less than the autopurge delay. The monotonic time represents time since an unspecified starting point, which is often the time the system is started, so the issue occurs when the system uptime is less than the autopurge delay. Solution: The issue was fixed by checking for an invalid timestamp, before using it's value to calculate if the instance should be purged.
OSPL-11559 | Missing release note in V6.9.0 release In our V6.9.0 release we fixed an issue and forgot to add a release note. We now added this release note for ticket OSPL-11502 to our V6.9.0 release notes
OSPL-11503 | Potential Deadlock releasing Python DDS entities The DDS Python API method that releases DDS entities (dds.Entity.close) would occasionally hang the main Python thread. This could only occur if a child entity registered a 'listener', and that listener gets triggered as part of closing the entity. Solution: The deadlock has been removed.
OSPL-11268 | IDLPP Python language binding ignored Constant declarations In release 6.9.0, the Python binding for IDLPP ignored Constant statements. Solution: In release 6.9.1, IDLPP now generates appropriate Python declarations.
OSPL-11130 | Python API: unable to create data readers and writers directly from a participant In release 6.9.0, the Python API did not support creating data readers and writers directly from a domain participant. Instead, the user had to create a publisher (data writers) or subscriber (data readers), first. Solution: The dds.DomainParticipant now has methods create_datareader and create_datawriter
OSPL-11264 | Python API: Simplified method to find and use existing topics In release 6.9.0, multiple steps were required to find an existing topic, and setup it up so that a Python program could read and write data from that topic. Solution: A new method, ddsutil.find_and_register_topic has been created. It is a one-step solution to finding and locally registering an existing topic.
OSPL-11269 | Improved type checking in Python code generated by IDLPP In release 6.9.0, IDLPP for the Python language generated code that had little type checking. It was possible to set field values to inappropriate data types and/or value ranges. Solution: Type checking in generated Python code has been improved. Python exceptions are now thrown if inappropriate values are set.
OSPL-11271 | Full support for listeners in DCPS API for Python The 6.9.0 release of the DCPS API for Python included support for the on_data_available listener, only. Solution: All listener methods have been implemented.
OSPL-11280, OSPL-11279 | Python API documentation and example location The native Python API for DCPS had documentation and examples stored as a ZIP file within OSPL_HOME/tools/python. Solution: To improve accessibility of this documentation, API documentation and examples are now in subfolders of OSPL_HOME/tools/python. The Python API user manual is located with all other OpenSplice manuals.
OSPL-11513 | DDS Communication Status methods in Python API The Python API for DDS did not implement the DDS Communication Status methods described in the DDS specification. Solution: All DDS Communication Status methods have been implemented. See the Python API documentation for details.
OSPL-11512 | Initialization of dynamically generated Python topic data instances In the Python DDS API, dynamically generated topic classes initialized all fields to None. This was both inconsistent with statically generated topic classes (created via IDLPP), but made such classes difficult to use. Solution: Fields in dynamically generated topic classes are now initialized to appropriate defaults: numeric fields to zero, strings to empty strings, sequences to empty lists, and arrays to appropriately sized arrays.
OSPL-11521 | Python API did not implement 'instance methods' The Python DDS API did not implement methods that accessed instance handles. Solution: Instance handle methods are now implemented.
OSPL-11520 | Python API did not support read_cond or take_cond The DDS Python API did not support data reader methods read_cond or take_cond. This made it difficult for users of the ReadCondition or QueryCondition classes to find appropriate data when such conditions were triggered. Solution: The read_cond and take_cond methods have been implemented.
OSPL-11522 | Python API sources not included in distribution Source code for the Python DCPS API was not included in all installers. Solution: The source code for the Python DCPS API is now included in all installers for Vortex OpenSplice. In this form, it is possible to compile and install the API on any platform for any version of Python above the minimum supported. Please see the README.txt in /tools/python/src for build instructions.

## 6.9.0

Report ID. | Description
--- | ---
OSPL-11502 | When a durability service generates a nameSpaceRequest on behalf of a fellow, the fellow's state can be incorrect. A durability service may decided to cache a nameSpaceRequest from a fellow if it has not discovered all relevant protocol readers and received the capability topic from the fellow. Only when the all relevant protocol readers have been discovered and the capability topic has been received a durability service will answer the cached nameSpaceRequest. In answering a cached request the durability service wrongly uses its own state instead of the fellow's state. This may result in a wrong fellow state. Since the state of the fellow plays a role in alignment and master election this may impact alignment, and potentially cause alignment to fail. Solution: Instead of using the durability service's own state it now uses the state of the fellow on whose behalf the cached nameSpaceRequest is sent.
OSPL-11245 | License checks are inconsistent Licensing of components is not consistently checked which may result in improperly counted licenses Solution: License checking has been improved NOTE: Please check you license before applying this update since the enhanced license may cause your application not to work
OSPL-11160 | Qos mismatch between OpenSplice and Lite using the C99 API A Writer does not match a Reader and vice versa when the Topic QOS's are configured as "RELIABLE" and "TRANSIENT_LOCAL" this causes late joiners not to receive any samples although the Topic Durability QOS was set to "TRANSIENT_LOCAL" and the Topic Reliability QOS was set to "RELIABLE" on both sides. Solution: The QoS mismatch is fixed and OpenSplice and Lite now can communicate correctly using the C99 API
OSPL-11199 | Idlpp spins indefinitely when compiling an IDL data struct with indirect recursion When you try to compile an IDL data model that has indirect recursion (i.e. a datatype has a reference to another datatype that eventually refers back to the original datatype), the IDL compiler starts to spin indefinitely, trying to walk through the recursive cycle over and over again. Solution: The algorithm used to handle recursive datatypes has now been modified to also support indirect recursion in a correct way.
OSPL-11157 | Installer asks for License file even if user declines to supply one Installation process asks for License file even when user answers N to providing license file. Solution: The installation process will no longer ask for an existing license file if the user declines to supply one.
OSPL-11028 | Python language support for IDLPP The Python language binding shipped in Vortex OpenSplice 6.8.3 did not support compilation of IDL into Python classes. Instead, the binding provided a method for dynamically creating Python classes, given an IDL file. While dynamic generation of Python classes is functionally equivalent to having IDLPP create Python code, source-code aware editors can provide better content assistance while editing if they have access to source code. Solution: IDLPP now supports a python language binding: idlpp -l python [other-idlpp-options] idl-file
OSPL-11026 | Using topics defined in other DDS applications In Vortex OpenSplice 6.8.3, the Python binding for DDS did not allow a Python application to access a topic without having access to the IDL defining that topic. Solution: The Python binding now supports a mechanism for registering a topic found via DomainParticipant.find_topic as a local topic. A local topic is a topic for which locally defined Python classes exist. The process for creating a local topic from a found topic are illustrated in the following example: dp = dds.DomainParticipant() found_topic = dp.find_topic('OsplTestTopic') # defined by Tester local_topic = ddsutil.register_found_topic_as_local(found_topic) gen_info = ddsutil.get_dds_classes_for_found_topic(found_topic) OsplTestTopic = gen_info.get_class(found_topic.type_name) # proceed to create publishers, subscribers, readers & writers by referencing local_topic
OSPL-11135 | Inconsistent treatment of character data in Python binding In the Vortex OpenSplice 6.8.3 beta of the Python binding, Python properties corresponding to IDL fields of type 'char' and 'string' were inconsistently treated. Sometimes, they would accept, expect or return a Python bytes value. At other types, a Python str (string) would be used. Solution: Treatment of IDL string and char values has been standardized as mapping to Python str values. You should always use a Python str when writing such properties, and always expect a str to be returned by such properties. For arrays or sequences of IDL char, the Python equivalent is a list of str, where each Python string is exactly one (1) character long.
OSPL-11238 | QoS parameter mandatory on some Python APIs The beta version of the Python DCPS API (Vortex OpenSplice 6.8.3) included several methods where quality of service (QoS) parameters were mandatory. This was inconsistent with other methods, where you could rely on appropriate defaults being generated. Solution: All QoS parameters in the Python DCPS API have been made optional, and, if not provided, then an appropriate default is used.
OSPL-11248 | Python API has no way to explicitly delete entities The beta version of the Python DCPS API (Vortex OpenSplice 6.8.3) did not provide a mechanism for explicitly deleting entities. Instead, all entities were release at the end of the Python session. Solution: A close method has been added to all entity classes (DomainParticipant, Publisher, Subscriber, Topic, DataReader and DataWriter), that will explicitly release the entity, and all it's child entities.
OSPL-11248 | Python support for DCPS built-in topics The beta version of the Python DCPS API (Vortex OpenSplice 6.8.3) did not include support for built-in DCPS topics. Solution: Vortex OpenSplice 6.9.0 release includes support for the built-in topics. Because the DCPS topics are pre-registered in every domain, you may find that using 'over-the-wire' topic discovery to use these topics. See the documentation ddsutil.find_topic, ddstuil.register_found_topic_as_local and ddsutil.get_dds_classes_for_found_topic as well as the Python DPCS API Guide.
OSPL-11496 | Durability crash during termination When durability is terminating it could crash when during this termination a heartbeat is received from another node. Solution: The crash during termination is fixed by changing the termination order of the durability threads.

## 6.8.3p1

Report ID. | Description
--- | ---
OSPL-11388 | Invalid or empty description in log reports produced by XML report-plugins. A bug in building the XML document that is forwarded to report plugins, caused the description element of the report to contain invalid XML syntax. Depending on the report-plugin implementation, this can cause i.e. a crash during XML parsing or outputting an empty description element. Solution: The bug was resolved so that proper XML data is provided to report plugins.
OSPL-11241 | Unable to start durability service on macOS. Unable to start the durability service on a macOS as the libleveldb-ospl.dylib had a build path set as library location. Solution: Build path replaced with @rpath.
OSPL-11240 | Java tools which require a license not working on macOS. When starting the tuner or tester on macOS a rlm licensing error is shown and the tools cant be used. Solution: The problem is fixed by changing the ospltun and ospltest scripts to include the rlm library.
OSPL-11287 | Race condition during fellow discovery that could prevent communication with a fellow. When a durability service discovers another durability service (called a fellow) it first has to confirm the fellow before it is allowed to talk to the fellow. In the unfortunate event that first a status message is received from the fellow (causing the fellow to be confirmed) and later on remote readers from the fellow are discovered, the fellow becomes unconfirmed again. If the fellow sends a request during the short period that the durability service was confirmed, the durability service may never respond to the request if it has become unconfirmed when it receives the request. Solution: An unconfirmed fellow can become confirmed, but never the other way around.
OSPL-11232 | When a durability client requests historical data and the durability server is still initializing the alignment may fail. When an application is started which uses client durability at the durability server is still initializing then this may cause that the durability client does not align correctly. For example when the durability client sends an historical data request for a group that is not yet known at the durability server because the server is still learning the local available groups the server responds by sending a response with no data and an error code that indicates that it is not responsible. The durability client does ignore the error code contained in the response and marks the group incorrectly complete. Solution: When a durability client issues a historical data requests and the durability service answers with a response indicating an error then the durability client ignores the response and issues a new historical data request when it receives a state change indication from the server.
OSPL-11158 | The builin topics are not aligned when client durability is used in combination with RT networking. The client durability implementation does not align a number of builtin topics. This is not necessary when used in combination with the ddsi service because the ddsi service provides these builtin topics. However in case RT networking is used these builtin topics will not be available. This causes for example that the publication matched and subscription match statusses will not function properly. Solution: In case the RT networking service is configured client durability will also issue historical data request for the alignment of the builtin topics.
OSPL-11150 | A full network queue may cause that the durability service does not updates it's lease in time. The durability service periodically writes a status message to inform the other durability services about it's state. When the network queue is full the write of the status message may timeout and the durability service will retry the write of the status message. This continues until the write of the status message is successful. However the thread that performs the periodically write of the status message is also responsible for updating the lease which informs the spliced daemon that the durability service is still alive. When it takes too much time to successfully write the status message it may occur that the lease is not updated in time which causes that the spliced daemon declares the durability service as died and performs the configured failure action. Solution: The function that writes the status message returns an error when the write of the status message times out instead of constantly retrying to rewrite the message. The error return will cause that a rewrite of the status message is rescheduled directly after checking if the lease should be updated.
OSPL-11193 / 11194 | Listeners called before DataReader creation is completed, resulting in 'not-enabled' exceptions when accessing the DataReader. When a listener is supplied as a parameter when creating a DataReader (as opposed to setting a listener after creation of an entity), there's a possibility that a listener callback is executed by the listener-thread, before the DataReader creation has finished in a different thread. When the callback accesses the DataReader, i.e. to read/take data, a 'not-enabled' status will be returned (or exception raised). Solution: During creation the DataReader is enabled before events are triggered. This assures that listener callbacks will only be executed after the DataReader is enabled.
OSPL-10931 | A late joiner with masterPriority="0" can wrongly align from an already existing node with masterPriority="0" if no master is available. The configuration setting //OpenSplice/DurabilityService/NameSpaces/Policy[@masterPriority] specifies the "willingness" to become a master for other nodes. The special value 0 is reserved for nodes that are not willing to act as aligner for other nodes. In case there exists a node (say A) with masterPriority 0 and a late joining node (say B) with masterPriority > 0 joins, then the late joining node B will successfully take mastership and node A will save to it. But in case B also has masterPriority=0 configured, then no alignment should take place. However, due to bug in the algorithm to determine a suitable aligner two nodes with masterPriority=0 could still align from each other. Solution: The bug has been fixed so that two nodes with masterPriority=0 do not align from each other.
OSPL-10651 | Invalid network interface name causes crash. When configuring a network interface name for RT networking that doesn't exist (and no alternative available), networking crashes. Solution: Due to incorrect annotation of a function, the compiler removed a result check, assuming the interface lookup would always succeed. This causes a crash in case the interface lookup did fail.

## 6.8.3

Report ID. | Description
--- | ---
OSPL-9967 | Possible crash when loading XML storage files in Durability service There's a possibility that the Durability service crashes at startup. The root cause of this issue is that the buffer where the file name of the XML storage file is stored, is limited. Solution: The defect of the limited buffer is fixed and is now dynamically allocated.
OSPL-11113 | Possible SignalHandler crash during termination of an application The SignalHandler within an application listens to signals posted to an application (like Ctrl-C). When an application shuts down, the SignalHandler also shuts down. The application should therefor not accept any new signals. In the case that after the SignalHandler was terminated a new signal was 'posted' to the application, the application could crash. Solution: When the SignalHandler of an application terminates, no new signals are accepted.
OSPL-11094 | Possibly missing persistent samples in persistent store. If during startup of the durability service a persistent writer was created it was possible that data written by that writer was never stored in the persistent store. This happened when the writer created a group and the group existed before the persistent data reader, groupQueue, was created. The groupQueue only attached to groups via the NEW_GROUP event which could have been missed for already existing groups. Solution: Made the persistent data reader, groupQueue, attach to already existing groups.
OSPL-11101 | The legacy master selection by durability may not converge when the master selection is based on majority. When the durability service is configured to use the legacy master selection algorithm then depending on the situation the master selection algorithm may resort to selecting the master based on the master that is proposed as master by the majority of known fellows. Under certain circumstances (for examples fellows become disconnected temporarily) this may cause that some fellows select different masters. Solution: When a durability services detects that another durability service has selected another master then a master conflict is raised which triggers an reevaluation of the selected master.
OSPL-11114 | Possible memory leak in domain participant destructor in IsoCpp2. Sometimes during closing a domain participant an "ALREADY DELETED" exception was generated. As this exception wasn't handled, further clean-up of the domain participant wasn't performed which causes a memory leak. Solution: The exception is now handled and a proper clean up will be performed.
OSPL-10769 | Threads that cause an error when accessing shared memory detach the shared memory before generating a core. When a thread that is accessing shared memory causes an exception to be raised, then the signal handler will detach from the shared memory prior to dumping the core. That makes the core pretty useless in many cases. Solution: The signal handler no longer detaches from shared memory when the thread that is raising the exception is accessing the shared memory at that moment in time. In all other cases the signal handler will still detach the shared memory in an attempt to leave the shared memory in a consistent state for other processes using the same federation.
OSPL-10935 | Add X-Types built-in Topic types to IsoCpp2. The X-Types specification provides a few simple built-in Topic types: BytesTopicType, StringTopicType, KeyedBytesTopicType and KeyedStringTopicType in the dds::core namespace. These types should be available within the IsoCpp2 API. X-Types built-in Topic types are added to IsoCpp2.
| OSPL-11067 | No documentation for the create_persistent_snapshot() exists for IsoCpp2. A proprietary API function exists to create a snapshot of the persistent store. The IsoCpp2 API implements this function, but no documentation for this feature was provided. Documentation for the create_persistent_snapshot() API function call is provided for IsoCpp2.
OSPL-10715 | delete_contained_entities fails when the reader listener has an outstanding loan. When using the Classic C++ API and using a DataReader with a listener for DATA_AVAILABLE it is possible that if during the listener callback the delete_contained_entities function is called it fails with PRECONDITION_NOT_MET if the listener callback does a read with a loan. The deletion of the reader did remove the listener interest but did not wait until the callbacks were finished. Solution: The deletion of the reader now waits until the listener callbacks are finished
OSPL-10717 | Unable to create readers for a topic starting with '_'. Unable to create readers for a topic starting with '_', which is allowed in the DDS spec. Solution: Added '_' as allowed first character in topic names.
OSPL-10810 | Using nested idl files on windows for Classic C++ could cause build errors. The idlpp/cppgen generated header files for Classic C++ contained an #undef of the import/export macro for Classic C++. When using nested idl files on Windows this could result in the import/exports not correctly set which could cause a build error. Solution: Removed the #undef from the generated header file.
OSPL-10301 | Error running vcredist when installing on Windows. Any errors running vcredist on windows at installation time result in a warning prompt and final steps of the installation process are aborted. This occurs even if the error is because the vcredist pack is already installed. The cause of the error cannot be determined at installation time. Solution: Do not display warning or abort installation process if there is an error running vcredist.
OSPL-10746 | In a single process deployment mode a deadlock may occur when an application installs a signal handler to trigger a guard condition. The deadlock occurs when a signal interrupts a thread that is currently accessing the guard condition and invokes the signal handler, in that case the lock of the guard condition is already taken and the trigger operation will deadlock when it tries to take the lock again. This problem only exists in the single process deployment mode because in shared memory deployments the signal handling is always outsourced to a dedicated signal handling thread. Solution: Enabled usage of the dedicated signal handler thread in single process deployment mode.
OSPL-10771 / 18286 | Group transactions may end up consuming a lot of memory. When using group coherency features with a lot of writers in a group and a lot of non-overlapping transactions, the amount of memory needed to store redundant End Of Transaction messages (EOTs) may become quite big. Solution: Remove the redundancy between duplicate EOT messages on the receiving side.
OSPL-10860 | When using Java based tools license checking didn't check all locations. When using a Java based tool and the prismtech_LICENSE was set to an invalid/expired license the secondary license location (OSPL_HOME/etc) was never checked to see if it contained a valid license, instead only the tertiary (VORTEX_DIR/license) was checked. This could lead to the tool not starting with a license error while a valid license was present in the secondary location. Solution: Made sure all license location are checked.
OSPL-10929 / 18400 | Customlib IsoCpp2 Debug platform configuration crashes when using with an OpenSplice release build. When compiling the IsoCpp2 customlib for a debug platform configuration and use this build with a release OpenSplice version if can crash due to a missing preprosessor define. Solution: The issue is now fixed and the customlib for the Debug platform configuration is now generated properly.
OSPL-10702 / 18253 | Sequence of typedef'ed char results in incorrect data received when using ISOCPP2 The copy out route for sequences was incorrectly adding data to the end of the newly created sequence i.s.o the beginning. As the sequence was first initialized with zero, the end marker was placed after the initialized data, creating a sequence twice as long as needed with the first elements to be zero. Solution: Instead of adding data to the sequence, assign is now used. This will place new data at the beginning of a sequence.
OSPL-8465 | Google Protocol Buffers embedding inner messages with keys multiple times fail If you have keys in an embedded message and then try to use that message more than once in your top-level message, only the first occurrence will become part of the key. Solution: It is now possible to embed inner messages that contain keys and they all will become part of the key.
OSPL-10712 | Durability native state conflict after initial alignment could trigger second merge When the master federation had a durability namespace with a merge state which was not equal to the default, a fellow durability service with a queued native state conflict resolved instead of discarded the conflict after the initial merge had completed. This resulted in same data being aligned twice. Solution: After the initial merge is completed the namespace merge state on the fellow durability service is updated to match its master.
OSPL-10924 / 18398 | CPP generated code results in an error messge when using klocwork. When using CPP as language during idlppp generated code compiling using klocwork an error "there is a copy constructor but no assignment operator" can occur. Solution: The problem is fixed and the correct assignment operator is now used.
OSPL-9572 | Launcher failed to run in Windows XP 32 bit operating system environment. Launcher would not run on Windows XP 32 bit systems. The java packager generated an exe file that only supported os verions for Windows 7 and up. Solution: The .exe file was modified after generation to support Windows XP. Launcher is now supported for Windows XP 32 bit operating system environments.
OSPL-9521 | Launcher: Java Tools buttons disabled the first time launcher is opened after installation. The code doing the check of the JAVA_HOME was using a 1 second timeout. On the first call, it would timeout, and the check would fail. Solution: The JAVA_HOME check code is done on a separate thread, then notifying the listeners (UI panes) that the check is complete.
OSPL-10502 | Launcher: In the Tools tab, provide an RnR Manager button to open the RnR Manager product. Launcher provides a Tools tab that allows users to open OpenSplice tools. If RnR Manager is installed, display a tools button to open RnR Manager. Solution: Search for an RnR Manager installation in the expected default directory derived using OSPL_HOME. Check the version numbers, and select the highest version number. When an RnR Manager installation is found, in Launcher's Tools tab, display an RnR Manager button to open the RnR Manager product.
OSPL-8069 | Launcher: Make the file and directory choosers smarter in the Settings dialog / environment tab. The file and directory choosers had no logic for the initial directory when choosing a file or directory. Solution: The file and directory choosers use the current value to set the choosers' initial directory. Smarter initial directory defaults are also provided if applicable.
OSPL-10523 | Tuner: Actions should automatically refresh tree views. After user initiated actions, the user has to then also initiate a "Refresh entity tree" action. Make the refresh happen automatically where possible. Solution: For the actions: "Import data" and "Import metadata", the entity trees are automatically refreshed.
OSPL-10513 | Tuner: Should provide an option to filter out internal topics. Tuner always displays all topics, including specification topics (DCPS), and OpenSplice product internal topics (CM, d_, q_, rr_). Solution: Added a Topic Filters tab in the Preferences dialog. This tab allows users to filter which topics are displayed in the tree views. By default all DCPS topics are shown, and all OpenSplice internal topics are hidden (CM, d_, q_, rr_).
OSPL-10667 | Tuner: Default partition empty string displayed as "null" in QoS tab. The cmapi internally stores the default partition policy value as literal java null. So in Tuner, when it sees the partition value null, it would show use the string "null" as the value in the QoS view table. Solution: In the QoS view table, the null is now displayed as an empty string.
OSPL-10345 / 17884 / 17883 / 17882 / 17880 | Added filtering for server ID to Dynamic network configuration for RT Network service. To effectively utilize dynamic network configuration updating, filtering on server ID needs to be added. Always updating all OpenSplice instances on a network with a new network configuration does not provide practical functionality. Solution: The new filtering has been added to the RT Network service.
OSPL-10371 / 17881 | New network partition does not result in updated partition mapping for RT Network service. When dynamically updating an RT Networking network configuration, adding a new network partition does not result in the proper updating of the partition mappings. The partition mappings need to be updated prior to notifying the channels of the new network partition and mappings. The symptom of this problem is that the new network partition is added, but a topic message is sent over the global network partition rather the new network partition. Solution: The defect is now fixed and a new network partition now results in an updated partition mapping.
OSPL-10396 | Idlpp crashes when compiling a sequence of a typedef to a sequence to C or C99. The IDL compiler idlpp crashes when it needs to generate the C or C99 representation for a sequence of a typedef to a sequence, or it generates code that doesn't work correctly. Solution: The idlpp code has been modified to generate the correct C/C99 representation and to no longer crash during this generation process.
OSPL-10576 | Leakage measurements on single process applications show a lot of heap leakage. Most of the heap leakage found is allocated by the internal database. In single process deployment the database allocates data on heap instead of in a separate shared memory storage as within the shared memory deployment, meaning that destruction of the database itself doesn't automatically free all remaining allocated data. This leakage is in fact not a resource problem but makes it hard to identify real issues. Solution: The database shall free all remaining data objects on destruction.
OSPL-10659 | When a node is rebooted persistent data may be inserted as unregistered even if there is no evidence that the original publisher has left. When a node that has configured persistency is rebooted and the data in its persistent set is the same as the set that would otherwise be provided by the aligner, then it is more efficient to load the data from disk than requesting the data form the aligner. Currently, the persistent store always assumes that data published from the persistent store is unregistered. Since the unregistered state is taken into account when calculating a hash over the set, hashes are likely to differ causing alignment. To prevent this situation the injected data should marked as implicit, which also better matches the semantics that the injecting node deduces that there is no writer. Solution: When messages are injected from the persistent store they are injected as being implicitly unregistered instead of explicitly unregistered.
OSPL-10688 | Simulink: Reader block may miss samples when configured to wait for available data. A Reader block configured to wait for available data always creates a wait set in every step, and only reads samples if the wait set is triggered. This implementation misunderstands the nature of the triggering of the 'data available' status condition. Data available is only triggered when DDS places new data into the reader's local buffers. It is possible for a Reader block to wait unsuccessfully for available data, but still have unread data locally available. Solution: The Reader block has changed to do the following: 1) attempt to read or take (as configured); 2) if no samples are returned, wait for available data (if so configured); 3) if available data is triggered in step 2, then read or take samples (as configured).
OSPL-10689 | Simulink: Writer block does not write samples in step in which it waits for a publication match. A Writer block configured to wait for a publication match will not write samples in the same step in which it waits for a publication match. This may result in an application failing to write samples some samples. Solution: The Writer block was changed to write after waiting for a publication match, so long as a match was found or the block was configured to write even if a match was not found.
OSPL-10699 / 18251 | Network service failed to start due to missing system clock. There is a mis-match between the platform configuration specified by the tool chain and what the platform actually supports. This causes clock_gettime to return an error code. As there is no error checking on this call, a fail will not be detected and the clock isn't working. Solution: In case the call fails because of using the BOOT_CLOCK, retry the call using MONOTONIC clock.
OSPL-10756 | Simulink: Compilation errors in Simulink Coder concurrent execution models when using Reader block. Simulink allows you to configure a model for 'Concurrent Execution'. The basic requirement for this is that each thread of execution is represented in a separate Simulink model, and then these models are referenced from a top-level Simulink model using the 'Model' block. The top-level model is then configured for concurrent execution. The details of doing this are described in the following MathWorks article: Configure Your Model for Concurrent Execution. When such concurrent models are built into executables with Simulink Coder, compilation errors result if the DDS Reader block was used in any of the referenced models. The error indicates that the include file "dds.h" cannot be found, and occurs as Coder attempts to compile the C code for the top-level model. Solution: The generated code for the Reader block has been changed so that "dds.h" is no longer required when compiling the top-level model.
OSPL-10865 | Durability services fail to align in Device-to-Device deployment with Cloud. Durability doesn't consider fellows behind a Cloud service responsive because it fails to match a fellow's readers with that fellow's id. The readers and writers are properly discovered and data will flow. Solution: The issue is now fixed and the durability service will align when using the cloud service.
OSPL-10954 / 18403 | On the classic C++ API the registration of an already registered typesupport leaks memory. When a typesupport is registered then the existing typesupport collection is searched to find if the typesupport is already registered. When an already registered typesupport is found it reference count in increased but not released after being used. This causes a memory leak. Solution: The found typesupport is released after being used.
OSPL-10967 | Issues with sequence/array of enums and multi-dimensional arrays in C#. The IDL compiler idlpp generates incorrect C# marshaling functions for the following IDL constructions: arrays or sequences of enums multi-dimensional arrays in general where #dimensions > 2 The issues cause either idlpp to crash when generating the code, the marshaler to crash when executing the code, or the wrong data to be written into or read out of the system. Solution: The idlpp code used to generate the C# marshalers has been corrected and no longer suffers from these issues.
OSPL-11083 | C# compilation failure in PingPong example prior to .NET 4.0. The PingPong C# example calls Stopwatch.restart in pinger.cs. The stopwatch.restart method was not added until .NET 4.0 Solution: The problem is fixed and the restart call is replaced with a call that works in .NET 3.5
OSPL-11020 | Identical sample requests from the same alignee are combined by an aligner durability service. A durability service can combine sample requests to optimize alignment efficiency. When two sample requests for the same data originate from different alignees the sample requests should be combined. However, when two identical sample requests originate from the same alignee it makes no sense to combine them. Combining them does not lead to a inconsistent state, but it may cause that other nodes receive such. Solution: Before actually combining the request, the aligning durability service checks if it already has a pending request that addresses the requesting alignee. If so, the request is not combined.
OSPL-10871 | The unregister resulting from the delete of writer may be ignored on systems with low time resolution. When a writer is deleted directly after writing an instance for the first time and the clock resolution of the system is very poor then it may occur that the unregister message resulting from the deletion of the writer gets the same timestamp as the sample and the sequence number of the unregister message is set to 0. This cause that the unregister message is considered older and is ignored. Solution: The sequence number of the unregister message is set the maximum value which cause that the unregister message is processed correctly.
OSPL-11087 | Issues with unions having a sequence of char or sequence of boolean in C#. When using idlpp to compile a union that has a branch with a sequence of char or a sequence of boolean, the C# backend either crashes, or generates code that does not compile properly. Solution: The C# backend for idlpp now generates the correct code for handling these cases and no longer crashes on them.
OSPL-11131 | Idlpp backend for C# may generate incorrect marshaling code for sequences The C# Marshalers generated by idlpp do not always contain the correct way to obtain the type description for attributes of type sequence: the function call that looks up the type description uses the C# attribute name rather than the IDL attribute name that is used to index the types. In most cases both names are equal, and so there will be no impact, but when both names differ, the Marshaler may crash with a System.NullReferenceException when writing samples. The IDL attribibute name and its C# counterpart may differ when the IDL name is based on a C# keyword (in which case its C# representation is prefixed with an underscore) or when the idlpp option "-o custom-psm" is used, in which case C# attribute names may be modified using the PascalCase notation. Solution: Idlpp now always uses the IDL attribute name when looking up a type descriptor.
OSPL-10728 | The use of inline arrays of pointers to structured types that have an alignment not equal to 4 bytes on a 32 bits platform may cause data corruption or crashes. The problem is caused by an incorrect alignment calculation for arrays of pointers. The array alignment should be equal to the alignment of the pointer (4 bytes on a 32 bits platform) but is actually equal to the alignment of the pointed type. As a result the memory offset of the array can be incorrect causing data corruption or crashes. Solution: Fixed the alignment calculation.
OSPL-10795 | Build error when building from source on Windows with Visual Studio 2015 update 3. The IsoCpp2 API could not be built on Windows with Visual Studio 2015 update 3 because of a dependency on the in Visual Studio 2015 update 3 not set _HAS_CPP0X. This caused C++11 to be disabled for some parts. Solution: Removed the _HAS_CPP0X dependency for Visual Studio 2015 and later for enabling C++11 support.
OSPL-10818 / 18358 | Typedef of a Sequence of a struct generation for C99 is faulty. When using C99 and an idl which contains a typedef of a sequence of a struct the generated code by idlpp omits the definition of the struct. Solution: The problem is fixed and a correct definition is now generated by idlpp.
OSPL-10958 | Writing samples that contain a sequence of a primitive type in C# could lead to an application crash. When using C# and having a structure in IDL that contains a member of type sequence(octet, long, double, float), A write of this data could lead to an application crash due to wrongly generated code by idlpp. Solution: The problem is fixed and correct C# code is now generated by idlpp.
TSTTOOL-485 | Tester created readers unable to receive historical data samples from transient durability topics. An error in the way Tester was creating data readers resulted in historical transient data to never be read and displayed in the sample list. Solution: The error is fixed and historical data is visible in the sample list on reader creation once again.

## 6.8.2

Report ID. | Description
--- | ---
OSPL-10489 | Reader port removed from Vortex DDS Reader block for Simulink The optional 'reader' port on the Vortex DDS Reader block for Simulink served no purpose. Solution: The port has been removed. Existing models that include a reader port will have the port removed. Any connectors connected to the reader port must be removed.
TSTTOOL-474 | Python Scripting: Exception on exit In the Python scripting environment (osplscript), creating a 'Recorder' (osplscript.recorder.Recorder) that is never used will result in an error on exit indicating a java.lang.NullPointerException. Solution: Guard code has been introduced to ensure that clean-up code is called only when needed.
TSTTOOL-470 | Tester cannot write enum values whose labels start with its type name. In some cases it was possible for the Tester to fail to write certain samples of certain types. The triggering type of data is an enumeration type whose label names start with the name of the enum type. When encountered, that type name string is cut out of the outgoing data value for the enum, which results in a failure because the middleware no longer recognizes the enum value it is trying to write. Solution: Tester no longer strips out the type name from the enum label.
OSPL-10499 | Launcher Configurations tab User Interface Improvements In the Launcher "Configurations" tab, the purpose of a configuration may not be clear to a user. Also, some of the functionality in the tab may not be intuitive to a user. Solution: Changes were made to the "Configurations" tab to address usabilty. These include: adding descriptive text, adding a link to the deployment guide, highlighting the ACTIVE configuration, disabling buttons when they are not applicable, a new right click menu for the configuration selection, and changing double click functionality to open a configuration instead of setting ACTIVE.
OSPL-10497 | Launcher Tools and Controls tabs should explain why certain options are greyed out and disabled. In the Launcher "Tools" and "Controls" tabs, access to tools and controls is done using buttons. In certain conditions, these buttons are disabled and shown as greyed out. It may not be clear why they are disabled. Solution: Tooltips were added on mouse hover to give users an explanation as to why the buttons are disabled.
OSPL-10496 | Launcher Tools and Controls tabs - provide a description of the tools and controls. In the Launcher "Tools" and "Controls" tabs, access to tools and controls is done using buttons. It may not be clear to the users what these tools and controls are for. Solution: Tooltips were added on mouse hover to give users a description of button functionality.
OSPL-10487 | Error Dialog from DDS Topic block for Simulink In MATLAB/Simulink R2017a, Simulink models using the Topic block from the Vortex DDS Block Set could see an error dialog with the following text "Error evaluating 'MaskDialog' callback of SubSystem block (mask)". The error arises from API changes between MATLAB R2016b and R2017a. Solution: Solved the problem by correctly calling the revised APIs.
OSPL-10486 | Vortex DDS block labels displaying incorrectly in MATLAB R2017a In MATLAB/Simulink R2017a, Simulink models that use the Vortex DDS Block Set blocks, and that hide one or more of the optional block ports, question marks (???) were overlaid on the block icon. Note that this behaviour did not impact execution of blocks. Solution: With the OpenSplice 6.8.2, all DDS blocks now display their block labels correctly.
OSPL-8573 | Tuner - Various errors and exceptions thrown through regular UI actions. Certain UI actions in the Tuner tool consistently cause exceptions to be printed to the console, and the expected UI action to fail. Particularly the Export Data menu items in the main window and some child windows. Solution: The causes of the exceptions being thrown have been fixed, and the corresponding UI menu actions work properly.
OSPL-4705 | Launcher preferences need to be stored in a separate location for each OpenSplice installation. Launcher stored all preferences in a .olauncherprefs file in the user home directory. If a user has multiple installations of OpenSplice, Launcher will reuse that file for all installations. This caused some confusion. (ex. licensing, resetting OSPL_HOME) Solution: The OSPL version was appended to the .olauncherprefs file name, so that each installation will have its own launcher preference file. For example: .olauncherprefs6.8.2. If the OSPL_HOME variable is not set, the preferences file name will default to .olauncherprefs.
OSPL-10595 | Error when compiling ISOCPP2 with Visual Studio 2015 Update 3 or higher When trying to compile the ISOCPP2 library, or any ISOCPP2 based application using Visual Studio 2015 Update 3 or any higher version, several compilation errors are encountered. Solution: The compilation flags required to successfully build on Visual Studio 2015 Update 3 and higher are now added to the build system.
OSPL-10366 | Unclear when persistent snapshot if successfully created. The function create_persistent_snapshot on the Domain object operates asynchronously: a thread in the durability process is responsible for making the snapshot, and the function create_persistent_snapshot returns immediately after the durability service has been instructed to make the snapshot. Therefore, it is unclear to the caller when the snapshot has safely been flushed to disk. Solution: The durability service will now log a message to the ospl-info.log when it successfully flushed the snapshot to disk. This log references a unique sequence number for each snapshot and can easily be made available for inspection by an application by configuring a ReportPlugin in your OpenSplice config file.
OSPL-10645 | The AutoBuiltinTopic namespace created by the durability service uses the legacy master selection algorithm which may cause problems when the others use the priority master selection algorithm. When the durability service configuration contains a namespace which includes the builtin topics and it is not configured as an aligner for that namespace then the durability service will create an AutoBuiltinTopic namespace for the builtin topics. However this namespace always uses the legacy master selection algorithm. When another durability service is configured as aligner for a namespace containing the builtin topics and which uses the priority master selection algorithm a mismatch between those namespaces is detected and reported. Solution: When the durability service creates the AutoBuiltinTopic namespace it should used the configured master selection algorithm.
OSPL-10644 | CM java API Entity toString could return null The CM java API could return null when the Entity.toString function was called for an entity without a name. When trying to print an Entity this function was called but not all jvm implementations are able to handle a null string which could lead to a NullPointerException. Solution: When toString() is called on an Entity with no name the simple name is returned.
OSPL-10641 | Incorrect log messages when bringing down network interface Incorrect log messages occur when using the RT Networkservice and having multiple virtual adapters configured and bringing one of the virtual devices down. In the ospl-info log it is reported as that the main adapter went down which is not the case. Solution: The incorrect adapter name has been fixed and the log now only reports information when changes occur on the actual used adapter by the RT networkservice.
OSPL-10596 | In case a durability service receives many unrequested chains then its log file could get polluted When a durability service combines sample requests it will send the combined answer to all durability services. The answer is only intended for the durability services that requested for the data, all other will drop drop the data. In case a durability service receives such unrequested answer this results in a log message for every message that is received. In case there are many unrequested answers this lead to many message and hence polluted the durability log file. Solution: The line that was responsible for log pollution has been removed
OSPL-10590 | ospl tool might miss spliced termination The ospl tool has a 2 second period it initially waits for the splice daemon. When the splice daemon terminated within those 2 seconds because of a normal termination request the ospl tool missed the termination and kept waiting for maximum time of 60 seconds before exiting. Could only happen when ospl start and ospl stop where called form different threads. Solution: ospl tool is now aware of normal termination within 2 seconds.
OSPL-10585 | Writing samples that contain a sequence of a primitive type in C# does not work When using C# and having a structure in IDL that contains a member of type sequence(octet, long, double, float), the C# writer can’t write the content of the sequence. Solution: The problem is fixed and a writer in C# can now write the sequences.
OSPL-10573 | Unable to create a shared memory segment larger than 1.9 GB SetFilePointer is used to set a pointer in memory. Only the low pointer is used, limited the range to 2 GB Solution: SetFilePointer also accepts a (optional) second 32 bit value which can be used to access file locations beyond the 2GB barrier. The code have been changed to used this 2nd parameter.
OSPL-10571 | OpenSplice refuses to start when using a decimal human readable size value in the configuration When having a configuration with a decimal human readable size value i.e. a database size set to 0.2G OpenSplice refuses to start. Solution: The fault in the configuration checker was fixed and now decimal human readable sizes are accepted.
OSPL-10563 | When the master selection algorithm is unable to select a master in time it chooses a master based on majority voting without generating a warning. Also, the threshold to resort to majority voting was ridiculously high. When there are multiple durability services in a system these durability services will have to choose a master for each namespace. The master is the one that is responsible to align the other other durability services. In case of the legacy master algorithm several iterations are being carried out if there is disagreement who should be the master. If after a fixed number of rounds there is still no agreement then majority voting is used to force a master. Because this situation may lead to improper alignment the fact that majority voting is used justifies a warning in the log files. However, this situation was not logged. Solution: A warning will be printed in the ospl-info.log when majority voting is used to choose a master, and the threshold to decide when majority voting will be used has been reduced.
OSPL-10534 | ddsi2(e) may crash due to potential corruption of internal hash table. In certain scenario's the ddsi2(e) service may crash due to corruption of an internal hash table. This is caused by the hash table not resetting slot pointers when an entry needs to be moved to another slot. In most cases the bogus pointer will quickly be overwritten by another entry and no harm is done. However, if this is not the case and the original entry is removed, a dangling pointer remains in the hash table which may crash ddsi2(e). Solution: The slot pointer is now reset to NULL after an entry is moved to another slot.
OSPL-10522 | Tuner import of transient data isn't received by late joiners When the tuner imports transient data it is not received by late joining readers because the imported data is published by a writer with auto_dispose_unregister=true and is thus purged from the system. Solution: Tuner publishes imported data with a writer with auto_dispose_unregister=false
OSPL-10465 | ospl start terminates splice daemon before it has the chance to become operational the ospl tool had a hardcoded 10 second timeout in with the splice daemon had to become operational, if not it would terminate the splice daemon and report an error. In some occasion this timeout had proven to be to short. Solution: Increased the timeout to 60 seconds, this is a worst-case value in most situation this won't effect behavior.
OSPL-10462 | NullPointerException during listener termination. When using the Java API with listeners a NullPointerException can occur when deleting an entity which has a listener attached. Solution: The cause of the fault is still unclear but a workaround has been implemented to catch the exception so the listener will terminate correctly. When this happens a trace will also be added to the ospl-error.log
OSPL-10423 | Sending out an array of a typedef of a string in C may cause an application crash When you model an array of a typedef of a string in your IDL and generate C code from this model, then the resulting code may corrupt/crash your application when you try to write samples containing such an array due to incorrect dereferencing of its pointer. Solution: Correct operator precedence has now been enforced by explicitly using brackets in the generated code.
OSPL-10425 | Possible error return by ospl tool while splice daemon is started When the ospl tool started the splice daemon and the starting took longer then the maximum allowed start time the ospl tool returned an error while the splice daemon was still running. Solution: When the maximum allow start time has passed the ospl tool now kills the splice daemon and reports an error.
OSPL-10423 | For sample attributes of type array only the first 4 or 8 bytes are actually marshaled out in ISOCPP. In ISOCPP (not ISOCPP2), sample attributes of type array are only marshaled out using the first 4 bytes (for 32-bit platforms) or the first 8 bytes (for 64-bit platforms), the rest of the array may be filled with garbage. This might cause data corruption or even a crash of the marshaling algorithms on either the sending or the receiving side. This was caused by an incorrect way to establish the size of the array, which returned the size of the pointer to the array instead of the size of its content. Solution: The algorithm now correctly establishes the size of an array.
OSPL-10420 | Wait for historical data timeout when using multiple readers and transient local with DDSI2(E) When using the DDSI2(e) network service with transient local durability set on a topic it can happen that in the situation when creating 2 nodes where 1 node is the writer and the other node creates 2 or more readers that wait for historical data call on the secondly created reader returns timeout when there is no data in the system for that topic. Solution: The problem is fixed and when this scenario happens the created readers will not return timeout anymore when there is no data for them.
OSPL-10413 | When using delayed alignment the durability service it may occur that a master conflict is not resolved. When the durability service configuration contains a namespace which is configured to use delayed alignment it may occur that the master selection for that namespace does not converge. The cause for this problem is that when delayed alignment is used the master selection does not take into account the system id and the quality of the namespace. This causes each time a durability instance detects a master conflict it will first select it self as the new master. This may cause a master conflict at another durability instance. This process repeats it self and results that no final master is selected. Solution: In case of delayed alignment the master selection algorithm should use both the quality of the namespace and the system id in to account when selecting a master.
OSPL-10382 | Missing metaconfig error message logged when running iShapes demo The metaconfig.xml file is missing from the iShapes demo installer. Solution: Added the metaconfig.xml file to the iShapes demo installer and added a priority search location for it in the current directory
OSPL-10376 | Wrong display of octet in Tuner When writing an octet field with the Tuner it is not possible to writer values > 127. Solution: The problem is fixed and the Tuner can now write values for octets from 0 to 255.
OSPL-10362 | NullPointerException in the Tuner. When using the Tuner to read a sample which contains a union inside a nested structure a NullPointerException could occur. Solution: The Tuner cannot handle some cases where a union is inside a nested structure as a workaround the NullPointerException is being catched so the Tuner wont crash and the sample can be read only the value of the union wont be displayed correctly in such a case.
OSPL-10361 | Google Protobuffer meta data injecting not efficient on isocpp2 Google Protobuffer meta data was generated into a hex string and runtime translated into a byte array using the sscanf function, for big types this were many sscanf calls. Solution: The Google Protobuffer isocpp2 meta data is now generated in a byte array so no runtime translation is required.
OSPL-10360 | On vxworks a condition variable may remain blocked after being signaled. On vxworks for each thread that uses a shared condition variable a named semaphore is allocated that is used to wake up this thread when it waits on a shared condition variable. When a thread starts waiting on a shared condition variable it registers this thread specific semaphore with the condition variable and waits on this semaphore. When another thread signals the condition variable it will post the semaphore that is registered with the condition variable to wake up the corresponding thread. The name used for this thread specific semaphore should be unique. However threads created withi the same RTP could generate the same name for this semaphore which could cause that the wrong semaphore is released when triggering a condition variable. Solution: The name generated for the named semaphore which is used for each thread is determined atomically within a RTP.
OSPL-10359 | Fault in QoSProvider schema. The provided DDS_QoSProfile.xsd contains an element dds_ccm this element is not suitable for OpenSplice and needs to become dds. The dds_ccm is introduced by an inconsistency in the OMG spec itself. Solution: The element changed from dds_ccm to dds fixing the inconsistency.
OSPL-10358 | Possible stack overrun when returning the loan after reading a large amount of instances When having a large amount of instances and do a single read it is possible to get a stack overrun when returning the loan after a read. Solution: The internal free of the loans was changed to behave iterative in stead of recursive.
OSPL-10188 | Memory leak in flex/bison generated parser Memory leak in flex/bison generated parser in path to make it thread safe. Solution: Removed memory leak by making parser reentrant (requires bison version >= 2.7)
OSPL-10174 | Master selection algorithm takes too long to decide on master The legacy master selection algorithm (which is selected by default and which should be used when communicating with nodes that run < V6.8.1) may sometimes take too long to decide on who becomes the master. When a node needs to confirm its vote, it resets its master selection in the mean time, resulting in a non-resolved conflict and another master selection cycle until finally majority voting finally kicks in. However, all these extra voting cycles may cause increased alignment times. Solution: The master selection is no longer reset between the establishment of the master and its confirmation.
OSPL-10169 | The RT networking service does not use active garbage collection of buffers used by a best-effort channel. The networking packets (fragments) received by a RT networking channel are stored in defragmentation buffers. When messages are fragmented over several packets and when a packet is lost the best-effort channel will maintain packets it has already received because packets may arrive out of order. However the networking service does not apply active garbage collection of these buffers. It will apply garbage collection when the number of free buffers becomes low. Because no active garbage collection is applied to the buffers of a best-effort channel the number of used buffers my increase considerably when large number of packet loss occurs on the network. Solution: For a best-effort channel apply garbage collection of defragmentation buffers containing incomplete messages at regular intervals. The garbage collector will free defragmentation buffers that contain incomplete message when a threshold is exceeded. This allows that packets that arrive out of order can still be delivered to the application.
OSPL-10168 | Ownership transfer may fail when using a deadline. Ownership transfer occurs when an instance is unregistered, or when it misses its deadline. When a disconnect occurs to an instance that also has a deadline applied to it, and the deadline expires before the loss of liveliness is detected, then the deadline mechanism is the first to transfer the ownership away from the disconnected owner. However, when later the loss of liveliness is also being processed while no new ownership has been claimed in the mean time, then the unregister message that communicates the loss of liveliness will reclaim ownership for the now disconnected owner. Lower strength writers that try to transmit messages afterward will never be able to claim ownership over the instance anymore, and thus will not be able to deliver their data. Solution: Unregister messages will no longer be able to claim ownership for instances that currently have no owner.
OSPL-10157 | Coherent historical EOT purging inefficient (high load) In a system with a large number of transient/persistent topic/group coherent writers the EndOfTransactions (EOTs) purging could take a long time as it was implemented as a loop within a loop with reference checking which was called often called both synchronous and asynchronous. Solution: Simplified the purging by removing the loops and making it synchronous only
OSPL-10143 | Creating a group coherent writer in the default partition always created an error log message When creating a transient/persistent group coherent writer in the default partition an error message was logged stating: " is in zero configured nameSpaces" even when it was in a nameSpace. Solution: Updated the group coherent partition nameSpace matching so that it correctly handles the default partition
OSPL-10139 | The isocpp2 read/take operation using a selector in combination with an iterator returns the incorrect number of samples The isocpp2 read/take operation using a selector in combination with an iterator ignores the provided max_samples parameter which causes the operation returns the incorrect number of samples. Instead of using the provided max_samples parameters it uses the max_samples attribute set on the selector. Solution: The provided max_samples parameter is used to limit the number of samples returned.
OSPL-10113 | Merging with an empty set could lead to a state update even when a data set was not changed. This triggers unnecessary alignment and may cause resurrection of data. In case a durability service has configured a MERGE policy and it merges with an empty set, then the durability will still publish a state update of its set even though its state has not changed. The state update in turn may cause other nodes to initiate alignment and hecne cause resurrection of data that was already aligned an taken before. Evidently, using the MERGE policy with an empty set does not change its set, and no state update should be generated. Solution: When a MERGE policy is applied with an empty set no state update is generated any more.
OSPL-10101 | Possible hang in delete_domainparticipant when splice daemon would not join in singleprocess mode If the splice daemon thread (only singleprocess) would not exit the join on it would block indefinit Solution: The join on the splice daemon is conditional, when unjoinable an error is returned.
OSPL-9706 | Unattended installer ignores providedLicenseFile argument When doing an unattended install of OpenSplice and providing a valid providedLicenseFile argument. The installer ignores the argument. Solution: The problem is fixed and the installer now uses the given providedLicenseFile argument to set the license file.
OSPL-7563 | The Custom_Lib solution files for MS Windows do not contain a Debug configuration. To build the various custom_lib's on MS Windows solution files are included. These solution files contain only a Release configuration. To support the debugging of customer applications a Debug configuration should be added to the provided solution files. This allows the customer to build a debug version of the custom libraries. Solution: A Debug configuration is added to the custom_lib solution files. The library name of the debug version of the custom lib is extended with the letter 'd'. For example the debug version of the standalone C++ API will be called dcpssacppd.dll instead of dcpssacpp.dll. The same applies to the other custom libraries.
OSPL-10343 / 17878 | The durability service of a node that is configured as a non-aligner for a namespace may not become complete even if there is an aligner available. In case a durability service of node is configured as a non-aligner for a namespace is initializing and it encounters an aligner that is already complete, then the non-aligner may have missed the message where the aligner indicates that its group are complete. Even though the non-aligner notices that it needs to request the state of the groups from the aligner, this is blocked by the non-aligner waiting for all its groups to get complete. This effectively may lead to a situation where the durability service does not make any progress. Solution: In case the non-aligner is not complete any new events are not being blocked anymore. This causes the non-aligner to request the groups when the aligner appears, notices that they are all complete, and proceeds again.

## 6.8.1

Report ID. | Description
--- | ---
OSPL-8444 | Unable to set the "Don't fragment" bit on outgoing UDP packets No configuration option to set this bit. Solution: Added a configuration option "DontFragment", located at (S)NetworkingService/Channels/Channel/Sending and NetworkingService/Discovery/Sending
OSPL-9882 | Linux: MATLAB/Simulink hangs when connecting to shared memory domain On Linux, a MATLAB script or Simulink model connecting to a Vortex OpenSplice domain via shared memory will hang. Solution: MATLAB, like Java applications requires that the environment variable LD_PRELOAD be set to reference the active Java installations libjsig.so library. The MATLAB user interface uses Java, and thus requires the same signal handling strategy as Java applications connecting to Vortex OpenSplice. The precise syntax for setting the LD_PRELOAD environment variable will depend on th shell being used. For Oracle JVMs, LD_PRELOAD should contain this value: $JAVA_HOME/jre/lib/amd64/libjsig.so
OSPL-9893 | Simulink unbounded string default dimension A Simulink user needs to be able to specify the maximum dimension of the character arrays created by IDLPP for the DDS 'string' type. Currently IDLPP generates a maximum dimension of 256, which is not user override-able. Solution: The IDLPP tool has been updated with additional functionality for generating Simulink bus definitions. For unbounded strings (and sequences in general), the IDLPP tool generates a .properties file that can be edited with Simulink specific bounds for these string and sequence types. See the DDSSimulinkUserGuide for more information on the IDL properties file.
OSPL-9895 | IDL types must have unique names before importing into Simulink to create the Simulink Bus. Currently all IDL types must have unique names so importing IDL into Simulink does not overwrite bus types, since Simulink bus types must have unique names. The IDLPP tool has been updated with additional functionality for generating Simulink bus definitions. When the tool detects a potential clash in struct names, it generates a .properties file that can be edited with Simulink specific struct name overrides for the bus definition. See the DDSSimulinkUserGuide for more information on the IDL properties file.
OSPL-9932 | Warnings reported in MATLAB when invoking idlImportSl after a fresh MATLAB restart running idlpp the first time after starting MATLAB causes the following warning. Running the same command again, the warning is gone. >> Vortex.idlImportSl('zz.idl', 'data.sldd') Warning: Cannot use definition of enumerated type 'Color' in dictionary '/home/prismtech/git/osplo/src/tools/matlab/examples/idl/data.sldd' because it is defined externally. You must remove the externally defined MCOS class before you can use the dictionary definition. > In Vortex.idlImportSl (line 14) Warning: Cannot use definition of enumerated type 'Enum_Day' in dictionary '/home/prismtech/git/osplo/src/tools/matlab/examples/idl/data.sldd' because it is defined externally. You must remove the externally defined MCOS class before you can use the dictionary definition. Solution: The Vortex.idlImportSl script has been fixed so as to avoid producing this warning.
OSPL-9994 | Setting a QoS file in Simulink block parameter uses an absolute path to specify the file URI An absolute path is used to specify the file URI. This means the QoS profile has to be set for each block without the default QoS. Solution: The Simulink DDS blocks have been updated such that Qos file uri is now set during each block's initFcn instead of at selection time of Qos file name in the mask dialog. Uri is also always relative to matlab's current working directory, which is re-resolved during diagram update/simulation start.
OSPL-10100 | Spliced can crash during termination when thread not alive When the splice daemon was termination it was possible that it crashed when on of its threads was deadlocked. When it was deadlocked it was not joined and the resources where freed, when the deadlock thread became alive again due to the freeing it could crash because it used freed memory. Solution: A timed thread join is now always performed when the join fails cleanup is stopped and spliced exits
OSPL-10137 / 17800 | Error when using multiple participants in single process deployment. When using single process deployment and creating domainparticipants for the same domain in multiple threads spawned from the main thread an Exception : Error: Failed to create DomainParticipant appears. Solution: It is now possible to create multiple participants at the same time for the same domain in single process.
OSPL-10185 | The classic C++ leaks memory that is allocated for the default QoS values The default QoS values in the C++ API are stored in static variables. When the application exits the memory allocated for these default QoS values is not freed. The same occurs for the DomainParticipantFactory. Solution: The identified leakage has been resolved.
OSPL-10315 | When a service exits some memory is leaked When a service is started it registers a cleanup handler. When the service exits the associated memory is not freed causing a small memory leak. Solution: The identified leakage has been resolved.
OSPL-10324 | Simulink - remove "status" ports from Domain, Topic, Publisher and Subscriber blocks The status port for the participant, topic, subscriber, and publisher blocks does not offer any value. The status is only used to detect errors - that when they occur, the simulation stops. Solution: The status port value for these blocks have been made not accessible to the simulation.
OSPL-10367 / 17969 | JVM crash when using multiple definitions of the same Enum value. When using the Java API and use different idls which have multiple definitions of the same Enum value in the same namespace the JVM crashes where it should give an error report. Solution: The problem is fixed and when this scenario happens a valid error report will be logged and the JVM will not crash anymore.
TSTTOOL-469 / 17530 | Max Samples Kept Per Reader preference not always respected In certain use cases, the max samples kept per reader preference does not work. The sample list tab table can have more than the expected number of samples per reader. This can be seen when a reader has a high number of samples coming in, at a fast rate. Solution: The back end data model was not removing samples from the display list correctly.

## 6.8.0p3

Report ID. | Description
--- | ---
OSPL-9497 | When the durability namespace equality check is enabled a merge action may fail when combining alignment requests When the equality check is enabled for a namespace the durability service will check if the aligner data set is the same as the data set from the alignee when applying a merge policy. However when the aligner tries to combine requests, which is controlled by the RequestCombinePeriod, it incorrectly compares only the data set from the first request which may cause that it concludes that the data sets are the same and no merge of the data sets has to be performed however the other request may have a data set which is not equal. Solution: When the durability service tries to combine the data requests associated with a namespace it checks if all the associated data sets are the same or not. It may combine requests that either are the same as it's own, thus those sets that do not require an alignment of the data, and it may combine data sets that are not equal to it's own set and which will require an alignment.
OSPL-9553 / 17187 | When a wildcard partition is used for a datawriter data samples may be sent twice. When a datawriter is created using a publisher which has a partition QosPolicy set to a wildcard partition then depending on the situation (timing) it may occur that the datawriter is attached to the same partition (group) when matching the partition expression with the existing partitions. This will cause that each sample will be written twice. When the datawriter is created it will try to match the partition expression with the existing partitions. However the spliced daemon will also try to match existing datawriters with newly created partitions. This may cause that the datawriter is attached to the same partition (group) twice. Solution: When matching the datawriter with a partition it is checked if the datawriter is already connected to that partition.
OSPL-10183 | Some memory leaks in the durability and networking service. When terminating the durability service it may leak the memory associated with the configured policies and merge state. When terminating the networking (ddsi) service may leak the memory allocated which is used to associate the networking service with a topic and partition combination. Solution: The identified leakage has been resolved.
OSPL-10200 / 17818 | Unable to start a service using a script. With the introduction of the configuration validator, it is impossible to use a script to start a service. Solution: When the service executable name isn't one of the defaults (durability, networking etc) but a shell script or other executable, check if the specified file exists and is executable (proper flags set). In that case, also accept that as a valid input.
OSPL-10201 / 17819 | Out of resources when creating and destroying a domain participant. In a very rare situation during closing of the domain just after opening it, a thread that has exited was not joined due to the fast shutdown after startup. This leads to memory not being freed. After about 32768 of this cases, the system runs out of resources, no new threads can be created anymore. Solution: Always wait for the thread in case we expect it to have run. If it's running, we will wait for it to exit. If it already has exited, the wait will return immediately, but does free the resources held by the thread.
OSPL-10272 | Not all ddsi2 threads are able to track CPU progress. Ddsi2 has the ability to track progress of its thread in terms of the number of CPU cycles spent by these threads. This helps in identifying the root cause of a "Failure to make Progress" notification: if no cycles were spent for a long time a thread might be in a deadlock, otherwise it might be loosing out when competing with higher priority processes/threads for the CPU. However, this ability can currently only be applied to a limited subset of the ddsi2 threads. Solution: All relevant ddsi2 threads now have the ability to track CPU progress.
OSPL-10281 | ISOCPP2 API is missing functionality to locate existing participant by its domainId. The ISOCPP2 API offers a function dds::domain::find() that allows you to pass a domainId and that will return an existing participant attached to the Domain identified by that Id (and null when no match can be found). However, in OpenSplice the implementation for this function was still missing. Solution: OpenSplice now implements dds::domain::find() function correctly.
OSPL-10282 | DurabilityClient reports error on NO_DATA DurabilityClient reports an error message when taking data from a built-in topic returns NO_DATA. NO_DATA is not an error and expected behavior in this situation. Solution: When take of builtin topic for DurabilityClient returns NO_DATA don't treat is as an error.
OSPL-10289 | Crash when reading sequence of sequence of primitives in ISOCPP2 When using ISOCPP2 and an idl with a sequence of a sequence of a primitive or struct with only primitive fields a Segmentation Fault can occur when a read is done on this sample. Solution: The problem is fixed and the application will not crash anymore and the sample can now be accessed properly.
OSPL-10318 | Durability may select wrong namespace master when using the same master priority and no persistent store configured. When the durability service is configured with a namespace with a master priority set and the same or highest master priority is used for each durability instance and when these durability services have no persistent store configured then the master selection may fail. Besides the master priority the quality of the data set is taken into account when determining which durability instance becomes the master for a particular namespace. When no persistent store is configured the initial quality of the namespace is not initialized correctly which causes that each durability instance selects it self as master. Solution: When determine the master for a namespace in case the master priority is set for that namespace then the initial quality of the namespace is initialized to 0 when no persistent store is configured.

## 6.8.0p2

Report ID. | Description
--- | ---
OSPL-7783 OSPL-9602 OSPL-9837 / 17627 | idlpp hangs if the IDL file being processed ends with a #pragma line If the last line in an IDL file is a #pragma, idlpp will consume 100% of cpu cycles and eventually fail. Solution: Add a newline after the #pragma and save file.
OSPL-9814 | The ddsi service incorrectly uses the reception time to unregister the instances of a terminating remote writer. When a remote writer terminates the corresponding instance written by that writer are unregisters. The ddsi service will unregister these instances when it is notified that the remote writer has terminated. However it will use the reception time of the notification as the source time for the unregistration of the corresponding instances. This may cause that the unregister is considered out-dated when the nodes are not time-aligned. Solution: Use the source timestamp that is present in the protocol message that indicates the termination of a writer as the source timestamp for the unregistation of the corresponding instances.
OSPL-9957 | The creation of a topic, datareader or datawriter using an inconsistent resource-limits QoS policy succeeds. The max_samples and max_samples_per_instance settings of the resource-limits QoS policy should be consistent which means that the max_samples should be greater of equal to the max_samples_per_instance setting. However the creation of an entity or the setting of the QoS of an entity using a resource-limits with inconsistent max_samples and max_samples_per_instance succeeds. Solution: The consistency of the resource-limits QoS policy is checked when creating an entity or setting the QoS of an entity and respectively return no entity or BAD_PARAMETER.
OSPL-10011 | Durability service with XML persistent store crashes during termination. When a large amount of data is written to the XML persistent store and the disk drive containing the files is slow, operations like fsync, required to guarantee consistency of the files after i.e. power failure, can take a considerable amount of time. The durability service would incorrectly determine a thread has not made any progress, when it is blocked on disk I/O. When at the same time the service is terminated, it could potentially crash while releasing thread resources. Solution: The issue is resolved by temporarily disabling thread liveliness monitoring during disk I/O. The same mechanism was already in place for the KV persistent store.
OSPL-10078 | The ddsi garbage collector may block on a full writer history cache (WHC). When ddsi garbage collector is used to cleanup the administration related to local and remote entities that are being deleted. Under certain circumstances it may occur that the garbage collector is blocked on a writer which still has data available in it's history cache (WHC), e.g. unacknowledged data. Solution: Allow the garbage collector to continue when it encounters a writer with a full WHC.
OSPL-10115 | DDSI time+duration implementation assumes signed overflow wraps around. DDSI's code for adding a duration to a time relies on signed overflow wrapping around, but what happens on signed overflow is actually undefined behaviour in C. Many combinations of platform and compiler do the "expected" thing by wrapping, some provide switches to guarantee this, but in the end the code really should not rely on it. Solution: Algorithm has been modified and is no longer relies on signed overflow wrapping around.
OSPL-10116 | A deadlock may occur in ddsi when the LogStackTraces option is enabled The ddsi service monitors the progress of it's threads. When it notices that a thread fails to make progress the ddsi service can log the stacktrace of the corresponding thread when the LogStackTraces option is enabled (on selected platforms only). To retrieve this stacktrace a special signal and corresponding signal handler is used. However in this signal handler a memory allocation is performed which may cause a deadlock. Solution: Pre-allocated memory is used by the signal handler to store the stacktrace.
OSPL-10133 | DurabilityClient accesses freed memory When enabled, the DurabilityClient functionality could attempt to access already freed memory, causing random crashes. Solution: The accessed memory has been protected to prevent it from being freed while still being accessed.
OSPL-10135 / 17788 | Merge policy "Catchup" may crash the durability service in case of Exclusive ownership. When a durability service has to apply a "Catchup" policy, and some of the instances it already contains are not covered by the set that is currently being aligned, it must conclude that these instances must have been disposed on the durability master, since otherwise they would have been covered by the set that is currently being aligned. In that case it will create its own implied dispose messages for those missing instances, which may be left partially uninitialized because it is no longer able to establish the exact writerGID, timestamp and inline-qos of the original dispose message that was used to dispose the instance. However, in case of exclusive ownership the missing inline-qos may cause a segmentation violation when the durability service tries to extract the writer strength from it. Solution: The durability service will no longer try to extract the writer strength from the inline qos of an implied dispose message.
OSPL-10155 | Use of non-keepall coherent writers may lead to sample loss in combination with resents When a coherent writer is used which has a history QoS policy set to KEEP_LAST then it may occur that due to resents a sample in the writer history is overwritten by a new sample. When this occurs the corresponding transaction will not become complete because of the gap that occurs in the sequence numbers that are assigned to the subsequent samples. To prevent this to occur the writer should be created with a KEEP_ALL history QoS policy setting. Solution: The creation of a group or topic coherent writer is only allowed when the corresponding history QoS policy is set to KEEP_ALL. Otherwise the creation the creation will fail or the enabling of the writer will return PRECONDITION_NOT_MET.
OSPL-10163 OSPL-10167 / 17806 | Segmentation Fault when using libconfig in combination with OpenSplice and DDSI. In some cases it is possible that a Segmentation Fault can occur when using DDSI and an OpenSplice application in Single Process mode that is linked with libconfig (-lconfig). Solution: The problem was that libconfig and DDSI both have similar functions that have a different signature. The DDSI functions have been renamed to avoid this issue.
OSPL-10184 | Possible Durability service crash during termination when Networking service failed to start. A few Durability service threads enter an infinite write attempt loop (that only quits when Durability terminates) if the Networking service did not start. Within this loop, the threads are not signalled to be alive. This will force an alternative path when Durability terminates, which can cause a crash. Solution: Signal the threads to be alive during the write attempt loop.
OSPL-10236 | The durability service over-aggressively requests groups from remote nodes The durability service needs to exchange group information in order to request data for these groups from remote nodes. To exchange group information, group request messages are initiated, and the remote node responses with group messages. The durability service sends such request for groups way too many times, even in cases when it already knows about the groups of the remote node. Especially in situations where there are many disconnects and many groups, the number of superfluous group exchanges may increase network load and decrease performance. Solution: The number of superfluous group requests is significantly reduced in case the groups of the remote node are already known.
OSPL-10238 / 17837 | Potential crash in durability service during peer discovery There is a race condition in the peer discovery of the durability service, where a partially discovered (and thus partially still uninitialized peer) may already be pulled through a matching algorithm and trigger a segmentation violation. Solution: The matching algorithm has been modified to avoid processing of uninitialized peers.
OSPL-10250 | When there are no writers for a sample, the writer registration for data that is being aligned must be removed. When there are no writers the writer registration must be removed so that the correct liveliness state is set for the data that is being injected by the durability service. To remove the writer registration and unregister message is generated. However, the unregister message did not fill the key fields correctly, causing the unregister message to be flawed. Solution: The key fields of the generated unregister message are set correctly.
OSPL-10252 | Potential crash during startup or permanent incompleteness of durability service. A race condition during initialization between the conflict resolver thread and listener threads in the Durability Service can cause a crash in the Durability service or missing events that lead to a permanent incomplete state of kernel groups. Solution:Staring the conflict resolver thread is delayed until the listeners are initialized.

## 6.8.0p1

Report ID. | Description
--- | ---
OSPL-7942 / 38552 OSPL-9825 / 17621 | Thread specific memory leaking away after thread end Threads that are created from a user application doesn't use our thread wrapper. Thread specific memory allocated by our software stack isn't freed when these threads exits. Solution: Use OS supplied callback functionality to call a destructor function when a user created thread exits to free allocated memory.
OSPL-9631 / 17524 | On vxworks a deadlock may occur when creating an datareader. On vxworks the implementation for condition variables that are located in shared memory make use of a named binary semaphores. For each thread one named semaphore is allocated to be used to notify the thread when it is waiting on a condition variable. However when a thread starts waiting on a shared condition variable it could register the wrong name (id) with the condition variable. This would cause that the thread was not waken when this condition variable was signalled. Solution: For each thread a named binary semaphore with a unique name is allocated. The correct name (id) is registered with a condition variable when the thread starts waiting on that condition variable. This allows another thread or RTP to find the correct binary semaphore when signalling the condition variable and awake the thread that is waiting on that condition variable.
OSPL-9743 / 17579 OSPL-9775 / 17600 OSPL-9776 / 17599 OSPL-9793 / 17607 OSPL-9847 / 17628 OSPL-9854 / 17633 | Durability service crash when deleting a reader. The Durability service will obtain historical data from a remote durability service and deliver it to all local datareaders. When it has completed delivery of all historical data, it will signal to all local datareaders that it has completed delivery of all historical data. When a datareader related to the topic for which alignment has completed, is deleted at that specific time, it is possible that the Durability service will crash due to a dangling pointer. Solution: When notifying completing of the historical data alignment, individual readers are claimed first to ensure they cannot be deleted during the notification process.
OSPL-9771 | Group coherent transaction purging no longer depended on the GroupCoherentCleanupDelay configuration option. The GroupCoherentCleanupDelay configuration option should be removed as all information to deduct the delay is available internally without the need to externally configure it. Solution: Group coherent transaction purging is the removal of transactions which cannot become complete anymore. A transaction cannot become complete anymore when a following transaction is completely received. Only when durability is in the process of alignment it is possible that an older transaction becomes complete, so no purging will be done while aligning. This is a replacement for the GroupCoherentCleanupDelay configuration option which always postponed purging the configured time.
OSPL-9798 | Improper use of a property in durability namespace administration One of the properties of a durability namespace is not properly taken into account, when the namespace is received from a fellow durability service. This causes potentially undefined behavior, including the possibility that a merge conflict is not properly resolved for that namespace. Solution: The namespace admin is now fully copied when a namespace is received by the namespaces listener thread of the durability service.
OSPL-9807 / 17616 OSPL-9809 / 17614 OSPL-9821 | For namespaces with a non-legacy masterPriority a delay is used in the algorithm to select a master. This delay may prevent alignment taking place. When durability services discover each other they negotiate which one (the master) will take up the responsibility to align other durability services. Before a master is being elected there is a period where no master exists. When previous generated conflicts are being resolved in this period, they might get dropped because no master is present yet. This may result in alignment not taking place once the master has been elected. Note that the period of not having a master is unnecessary in case it is clear who will become the master. Solution: The delay to choose a master has been reduced to 0 for namespaces with a masterPriority, so that there is no risk that conflicts are getting dropped because the master is not yet selected.
OSPL-9811/17613 OSPL-9944 | Durability service and application deadlock or durability may crash when concurrently deleting a datareader and marking alignment complete Once the durability service finishes alignment of historical data, it notifies the datareader the process has completed. If that datareader is deleted by the application at the same time, both the durability service and the application deleting the datareader may run into a deadlock due to the fact that deletion of the datareader and marking completeness of historical data alignment take two locks in opposite order. Solution: The algorithm to mark historical data alignment complete has been refactored to ensure avoid pushing completeness to the readers altogether by keeping track of incomplete groups in a separate structure and letting wait_for_historical_data rely on that instead.
OSPL-9826 | Out of order delivery of invalid sample might throw away later history When an invalid sample is delivered out of order to a Reader that has history depth > 1, and newer samples for the same instance are already present, then the invalid sample may legally be dropped. However, it will currently also drop all samples for the same instance that are newer than the invalid sample. Solution: Only the invalid sample itself will now be dropped in this scenario.
OSPL-9840 | Possible uninitialized memory reads when using Replace merge policy. When using a replace merge policy, in some cases a sample could be evaluated right after it had been freed, resulting in uninitialized memory reads. Solution: The sample evaluation is now always performed before the sample is freed.
OSPL-9841 / 17625 | The creation of a Query or QueryCondition with a '(single quote) in the expression fails. When the expression used to create a DDS query of querycondition contains an escaped '(single quote) then the creation of the query fails. Note that a single quote in a query expression should be escaped by another single quote. The cause of this error is the evaluation of the regular expression used by the query expression parser. It appears that the evaluation of the used regular expression interprets the first quote it encounters in the string as the end delimiter of the string instead for matching with the longest possible match. Solution: The regular expression used by the query parser is changed to accept the occurrences of escaped single quotes. Thus when a query string contains two consecutive single quotes this is converted to one single quote. Note that the documentation still has to be updated that it will be allowed to include a single quote in a query expression by escaping it.
OSPL-9865 / 17634 | Linking problem when application uses function named os_sleep which is also defined by OpenSplice. When an application defines a function os_sleep this function may provide a conflict with the internal OpenSplice function os_sleep. This may cause a linking problem when linking the application code with the OpenSplice libraries. Solution: The name of the os_sleep function has been renamed to os_ospl_sleep.
OSPL-9875 | Sample requests are not combined with an already combined sample request To reduce network load during alignment the aligner durability service attempts to combine sample requests from the alignees before it sends its response. The period to combine can be configured using configuration setting //OpenSplice/DurabilityService/Network/Alignment/RequestCombinePeriod. So if two alignee durability services requests the same data during this period, then the aligner combines these requests. If a third request appears during the period then this should also be combined, and the when the period expires all three alignees should be aligned in a single go. Due to a bug the aligner did not recognise the third request as being similar as the first two and hence the third request would not be combined. This leads to multiple responses for the same set and contributes to inefficient alignment. Solution: The algorithm to combine requests has been fixed so that combined request can also be combined.
OSPL-9921 | Durability may crash when datareader is deleted shortly after creation Once the durability service finishes alignment of historical data, it notifies the datareader the process has completed. If that datareader is deleted by the application at the same time, durability may crash. Durability claims the datareader before accessing it and this prevents the datareader from being freed even if the application calls for deletion. Even though the the datareader is not freed while it is still claimed, the datareader is 'disconnected' from the subscriber during deletion. The algorithm to disconnect the datareader from the subscriber does free part of the datareader datastructure in memory and leaves the datareader in a state where that part of the datastructure is still accessible although it is already freed. Once the durability service accesses this already freed datastructure it crashes. Solution: The algorithm to disconnect the datareader has been modified to ensure the part of the datastructure that is actually freed is no longer accessible after completing the disconnect.
OSPL-9929 | After removing the GroupCoherentCleanupDelay option it was possible that an obsolete group transaction was flushed to the kernel without accessLock The removal of the GroupCoherentCleanupDelay and its replacement by not being allowed to removal obsolete group transactions during alignment shifted responsibility for the removal of the obsolete group transactions to durability. It was possible that when an obsolete group transaction contained samples that could not be discarded those samples where flushed to the kernel without accessLock, this could lead to late joining readers receive only part of the obsolete group transaction. Solution: Before flushing undiscardable samples from an obsolete transaction the kernel accessLock is taken
OSPL-9930 | Potential crash in resendManager When the configured networking service(s) have not attached to a new combination of a topic and partition yet, then any sample written to this combination are rejected (and hence retransmitted by the resendManager at a later time) until all configured networking services have successfully attached to it. When one of the rejected messages is an Unregister message, then the resend manager may crash while trying to retransmit it. Solution: The algorithms used to handle message rejection and retransmissions have been modified to correctly handle Unregister messages now, and thus the potential crash will no longer occur.
OSPL-9958/17656 | Durability not completing capability handshake after asymmetrical disconnection Before durability services can start alignment they must exchange capabilities. Thus, capability exchange is as handshake before alignment can occur. To detect an asymmetrical disconnect multiple capabilities (>2) from the same fellow durability service must have been received. The only way this could have occurred is when the fellow was disconnected. In that case a durability service should resend its capabilities to the fellow, so that the fellow can participate again in alignment activities. However, the capability was not resend in case of an asymmetrical disconnect, and the fellow would not participate in alignment anymore after an asymmetrical disconnect withe the fellow was detected. Solution: The capability is resend to the fellow when an asymmetrical disconnect with the fellow has occurred.
OSPL-9963 / 17660 | WaitSet not triggered when a dispose is followed by an unregister. When a ReadCondition was added to a WaitSet that should trigger when a sample is disposed, then it was possible that the waitset would not wake up when a dispose was followed by an unregister. This would only happen when the related reader contained only one instance. Solution: Re-evaluate the attached conditions when a matched invalid sample (a dispose or unregister) is replaced by another invalid sample.
OSPL-9990 | Multiple asymmetric disconnects in a row could prevent exchange of capabilities and prevent alignment A precondition for alignment to start is that capabilities must have been exchanged and readers must have been discovered (handshake). If an asymmetric disconnect occurs multiple times after capabilities have been exchanged, then capabilities of the node that got disconnect must be exchanged again once it gets reconnected. This, however, would only occur after the first asymmetric disconnect. When multiple disconnects occur a fellow would not resend its capability because he thinks he has already did it. Furthermore, rediscovery of readers would not occur because the readers the associated DCPSSubscription messages are not available anymore, because they have been taken during the previous iteration. Both the failure to resend capabilities and the failure to rediscover the fellow's readers prevents the handshake to complete after multiple asymmetric disconnects, and hence prevents realignment. Solution: The capability message is extended with an incarnation number to differentiate between the different incarnations of fellows. In that way fellows can determine to which incarnation a capability message belongs. Furthermore, the DCPSSubscriptions to detect the readers of the fellow are not taken but read, so that they remain available for future incarnations. Both mechanisms are sufficient to determine whether the handshake has completed and realignment can start again.
OSPL-1004 / 17669 | Crash on cortexa9t.yocto after building custom_lib When building the product, NDEBUG was not defined while it was when building the custom_lib. This causes binaries mismatch when linking the libraries, which in turn can cause all kinds of problems like crashes. Workaround is removing "-DNDEBUG" from the custom_lib makefiles. Solution: Define NDEBUG when building the product.
OSPL-10012 | DDSI sometimes sends a GAP when sample still available In DDSI, the response to an ACKNACK requesting a retransmission consists of a samples in DATA (and DATAFRAG) submessages, and of GAP submessages to indicate samples that are no longer available in the writer history. The GAP is encoded as a range of sequence numbers [A,B) combined with a bitmap starting at B, where bit k indicates that the sample with sequence number B+k is no longer available (k starting at 0). In the specific case where the request is for [A,B] and all samples in [ A,B - n ] are present and those in [ B - n+1,B ] are not, and so the GAP message simply contains the interval \ [B - n, B +1 ) and no bitmap, the DDSI2 service attempts to grow the interval by locating the next available sequence number to reduce the number round-trips required between the reader and the writer. However, because of an off-by-one error, when B+1 exists, and the writer has published more data since, B+1 is erroneously included in the gap. This will (with a rare exception) cause the reader to move forward to at least B+2 and never request a retransmit of sample B. This is caused by the writer starting looking for the next sequence number beyond the gap, but taking B+1 as its starting point instead of B. (The exception is that when packet loss occurs in the retransmit and the gap was not stored in the reorder buffer for lack of space, the reader will not move forward as much and re- request samples, possibly but not necessarily recovering B+1_._) Solution: The off-by-on error is fixed.
OSPL-10088 | Wrong .NET version for some windows builds. In some windows versions of OpenSplice the C# languagebinding was linked against the wrong .NET version. For example the Windows 7 VS2010 build was linked with .NET 4.5 in stead of .NET 4.0. Solution: The OpenSplice installers do now comply with the following versions. Windows 10 / VS2015 / .NET framework V4.6 Windows 8.1 / VS2013 / .NET framework V4.5.1 Windows 8 / VS2012 / .NET framework V4.5 Windows 7 / VS2010 / .NET framework V4.0 Windows Vista / VS2008 / .NET framework V2.0 Windows XP SP3 / VS2005 / .NET framework V2.0
OSPL-10125 / 17790 | Networking service does not halt when binding a socket failed. It is quite essential for the Networking service to be able to bind to its desired sockets. If not, then communication will fail. The Networking service continued to run when such a socket bind failed, indicating problems only by means of an error trace. The application being none the wiser. The Networking service should halt when it fails to bind sockets. Solution: Networking service will halt in an error state (using the FailureAction/systemhalt configuration will halt the complete domain in that case) when a socket bind fails.
TSTTOOL-448 / 17651 TSTTOOL-449 / 17654 TSTTOOL-452 / 17648 | New shell command simplifies Vortex Tester Python Scripting installation and usage In order to use Vortex Tester Python Scripting, a user had to download, install and configure a Jython engine, and then at each use, start that engine with specific command line options. Doing this was error prone. Solution: A new osplscript command is now included with Vortex OpenSplice. To install and configure Python Scripting, the user must only download the Jython installer to the current directory, and run osplscript from a console window. Once configured, osplscript will start the Python Scripting environment; no special command line options are required. Finally, osplscript accepts all standard Python/Jython command line arguments.
TSTTOOL-456 | Creating a group coherent subscriber in Tester fails to add readers, and throws exceptions in log. When specifying "Create as group" from the add readers dialog, the data readers fail to initialize and the DDS poller thread throws exception logged in OSPLTEST.log. This is because from OpenSplice 6.8.0, subscribers that have the presentation policy set to access scope = GROUP and coherent access = true are created in the disabled state. Solution: Tester now prevents operations being invoked on the group coherent subscriber until it is enabled, which is done automatically after the data readers are created. Also added error message to add reader dialog to prevent creating new readers under existing group coherent subscriber.

## 6.8.0

Report ID. | Description
--- | ---
OSPL-4891 | Java and C++ RMI incompatibility. The RMI bindings for Java and C++ use different topic names. Therefore a Java server and C++ client (or vice-versa) are not compatible with each other. Solution: A parameter (--RMILegacyTopicNames) has been added to the C++ RMI binding. By default it is enabled to ensure backwards compatibility with previous releases. When disabled, topic names will match the Java binding therefore a C++ RMI client/server will be able to communicate with a Java RMI client/server. For more information please check the RMI Getting Started Guide (section "Runtime Configuration Options").
OSPL-9183 | Java 5 API read/take gives back already processed samples. In the Java 5 API when doing a read or a take with an own allocated result list it might be possible that already processed data is returned in the result list. Solution: Only not processed data will be returned
OSPL-9274 | Remove already deprecated MMF durability persistency option The MMF store for durability has long been deprecated and now has been removed. Solution: Support for the MMF store has been removed from the durability service after beeing deprecated for a long time. Switch to the new KV-persistency is transparant.
OSPL-9383 | Missing flags in SAC DDS_STATUS_MASK_ANY DDS_SUBSCRIPTION_MATCHED_STATUS and DDS_PUBLICATION_MATCHED_STATUS are not included. Solution: The missing flags have been added.
OSPL-9625 | DDSI asynchronous delivery mode behaviour change The DDSI2 service delivers data to the kernel either synchronously or asynchronously, depending on the latency budget and the transport priority QoS of the writer. If the latency budget is large enough or the transport priority is low enough (both configurable), delivery is asynchronous. Solution: The behaviour of asynchronous delivery has been changed to not drop data when the delivery queue is full, but rather to wait until there is once again room available in the queue. This behaviour more closely resembles the behaviour with synchronous delivery when a reader has reached its resource limits, but more importantly it significantly increases the stability of the throughput at very high sample rates. The default settings are such that all data is by default delivered synchronously. This change only has an impact if asynchronous delivery has been explicitly enabled and previously samples were dropped because of a full queue.
OSPL-9626 | DDSI now gives allows configuring Heartbeat timing The DDSI2 service did not allow configuring the timing of the Heartbeats sent by writers to inform the matching readers of the presence of (unacknowledged) data. While the timing parameters were fine for most networks, on long-latency networks they could result in multiple Heartbeats being sent before an acknowledgement could have been received. This is obviously bad for network utilisation. Solution: The parameters are now configurable in the Internal/HeartbeatInterval setting. The default values are identical to the previously used values, and there is no change in behaviour unless different values are configured.
OSPL-9627 / 17521 | Application crash during write When inserting a writer sample in the writer history first the position where the sample should be inserted is determined. When the history is full then an older sample is removed from the history. A crash occurs when the sample that has been removed is also the position in the history where the new sample has to be inserted. Solution: When the insertion point equals the sample that is removed the insertion point should be updated to point to the next sample in the history.
OSPL-9736 | QoS Provider now accepts durability-service policy in DataWriter QoS. The OMG DDS4CCM Specification defines the QoS Provider API as implemented by OpenSpliceDDS (See QoS Provider documentation). An oversight in the specification resulted in the inclusion of a durability-service policy in the DataWriterQoS. OpenSpliceDDS used to reject QoS profiles that include this policy, since it is not a valid DataWriterQoS policy. However since it is included by the specification (and also in many example xml profiles), this behaviour was deemed inconvenient. Solution: The OpenSpliceDDS QoS Provider implementation was changed to no longer reject this policy, it is now ignored, reported in the info log but does not prevent creating and using a QoS Provider.
OSPL-9737 / 17559 | DDSI transmission blocks on high watermark without warning. When //OpenSplice/DDSI2Service/Internal/ResponsivenessTimeout is infinite (which is the default), then the DDSI transmission will block on the high watermark without a warning trace when there is an unresponsive reader in the system. Solution: A warning is added that will be traced after a small while when DDSI is waiting on the high watermark.
OSPL-9747 | C99 api function dds_readcondition_create returns null. Implementation does not correctly copy the mask, causing creation of read condition to fail. Solution: Fixed the error in the mask copy routine.
OSPL-9756 | C# RoundTrip example reports wrong roundtrip times The C# example is using the C# DateTime.Ticks property, which is increased each 100nSec. The example was dividing this with 1000 before using it for calculation, loosing resolution and incorrectly assuming this would results in uSec. Solution: Now, the full 100nSec resolution clocktick is used in the calculation, the conversion to uSec is done during printing of the results by dividing the result by 10.
OSPL-9910 | Shapes Demo cannot set Best Effort DataWriters The Shapes Demo was only able to set the Reliable policy while assuming that the default would be Best Effort. The Shapes Demo was ported from using isocpp to using isocpp2. The default QoS values of isocpp2 are different from isocpp and follows the standard but that meant that the default is now Reliable (for DataWriter). The result was that the Shapes Demo was not able to change the default Reliable to Best Effort. Solution: Shapes Demo does now set the various QoS settings explicitly and does not dependent on default QoS values any more.
OSPL-9911 OSPL-9956 | Unused variable warning when building application using isocpp2 API Warning at include/dcps/C++/isocpp2/dds/domain/detail/TDomainParticipantImpl.hpp:45:57 Solution: Removed unused variable.
OSPL-9930 | Potential crash in resendManager When the configured networking service(s) have not attached to a new combination of a topic and partition yet, then any sample written to this combination are rejected (and hence retransmitted by the resendManager at a later time) until all configured networking services have successfully attached to it. When one of the rejected messages is an Unregister message, then the resend manager may crash while trying to retransmit it. Solution: The algorithms used to handle message rejection and retransmissions have been modified to correctly handle Unregister messages now, and thus the potential crash will no longer occur.
OSPL-9950 | When the c99 read/take operation returns no samples then calling return_loan may cause a crash. When the c99 read/take operation does not return samples and the return_loan operation is called then a crash may occur when the same buffer is used again to read/take samples. The cause is that when no samples are read no buffer is allocated however the not allocated buffer is incorrectly added to the loan administration. Solution: When the read/take operation returns no samples then the provided buffer should not be added to the loan administration.
OSPL-9953 / 17653 | Including the DCPS C-API header file in a C++ program may give a compilation warning An include file that is included by the DCPS C-API header file dds_dcps.h defines the struct os_stat and a function with the name os_stat. When included in a C++ program the name of the struct shadows the name of the function. This may cause a compilation warning. Solution: The name of the struct is redefined to be different from the name of the corresponding function.

## 6.6.3p4f17

Report ID. | Description
--- | ---
OSPL-9708 | Built-in topics included in all namespaces. When using RTNetworking, all namespaces would be considered to contain the built in topics. This could cause way too many conflicts as well as improper behaviour on merging the built in topics. Solution: The built-in topics are only contained in the automatically created namespace that is intended to properly merge built in topics.
OSPL-9768 | Userclock configuration name and reporting attribute types mixed up in the configurator. The Userclock configuration name and reporting attribute types are mixed up in the configurator. The name is set as Boolean and the reporting attribute is set as String. Solution: The defect is fixed and the name is now a String again and the reporting a Boolean.
OSPL-9769 | Alignment not taking place due to unfortunate timing. When two nodes see each other, one of them is going to be selected as the master for the other. The alignee node that does not become master waits for the master to update its state before it will acquire the data from the master. It is possible that the master raises its state before the alignee node starts waiting for the update. Effectively, this means that the alignee node will wait for an update that never comes, because it already has occurred. Solution: The node that does not become master will always request data from its master instead of waiting for a state update.
OSPL-9785 | CATCHUP policy may incorrectly dispose recently arriving data. When the durability service performs a catchup policy, it intends to replace its current data set with the set from its aligner. Every instance that is in its current data set but not in the aligned data set should be disposed. However, the algorithm used to insert this dispose message might incorrectly apply it to data that has arrived AFTER the request for the catchup but BEFORE the completion of this request, thus accidentally disposing data that should still be considered ALIVE. Solution: The algorithm used to insert the DISPOSE message has now been modified to apply it only to data that is older than the time of the catchup request.
OSPL-9208 | DDSI not sending an SPDP ping at least every SPDPInterval DDSI has a Discovery/SPDPInterval setting that is meant to set an upper bound to the SPDP ping interval, that is otherwise derived from the lease duration set in the //OpenSplice/Domain/Lease/ExpiryTime setting. The limiting only occurred when the lease duration is > 10s. Solution: The limiting has been changed to ensure the interval never becomes larger than what is configured.
OSPL-8958 | DDSI can regurgitate old T-L samples for instances that have already been unregistered DDSI maintains a writer history cache for providing historical data for transient-local writers and for providing reliability. An instance is removed from this cache when it is unregistered by the writer, but its samples are retained until they have been acknowledged by all (reliable) readers. Already acknolwedged samples that were retained because they were historical data could survive even when the instance was removed. When this happened, a late-joining reader would see some old samples reappear. Solution: deleting an instance now also removes the already acknowledged samples from the history.
OSPL-9097 | DDSI transmit path can lock up on packet loss to one node while another node has crashed A successful retransmit to one remote reader while another remote reader that has not yet acknowledged all samples disappears (whether because of a loss of connectivity or a crash), and when all other remote readers have acknowledged all samples, and while the writer has reached the maximum amount of unacknowledged data would cause the transmit path in DDSI to lock up because the writer could then only be unblocked by the receipt of an acknowledgement message that covers a previously unacknowledged sample, which under these circumstances will not come because of the limit on the amount of unacknowledged data. Solution: deleting a reader now not only drops all unacknowledged data but also clears the retransmit indicator of the writer.
OSPL-9096 | Durability service DIED message even though the durability service is still running The d_status topic is published periodically by the durability service to inform its fellows of its status. By using a KEEP_ALL policy, the thread writing the status message and renewing the serivce lease could be blocked by a flow-control issue on the network, which could cause the durability service to be considered dead by the splice daemon when in fact there was no problem with the durability service. Solution: use a KEEP_LAST 1 history QoS policy for the writer.
OSPL-9067 | Large topics are sent published but not received Loss of the initial transmission of the final fragments of a large sample failed to cause retransmit requests for those fragments until new data was published by the same writer. Solution: ensure the receiving side will also request retransmission of those fragments based on heartbeats advertising the existence of the sample without giving specifics on the number of fragments.
OSPL-9077 / 00016820 | Potential crash in durability service during CATCHUP policy The durability service could crash while processing a CATCHUP event. This crash was caused by the garbage collector purging old instances while the CATCHUP policy was walking through the list of instances to do some bookkeeping. Solution: The CATCHUP policy now creates a private copy of the instance list while the garbage collector is unable to make a sweep. This private list is then used to do the bookkeeping.
OSPL-9068 / 00016813 | Catchup policy may leak away some instances When a node that performs a catchup to the master contains an instance that the master has already purged, then the node catching up would need to purge this instance as well. It would need to do this by re-registering the instance, inserting a dispose message and then unregistering this instance again. However, the unregister step was missing, causing the instance to effectively leak away since an instance is only purged by the durability service when it is both disposed AND unregistered. Solution: The durability will now both dispose AND unregister the instance at the same time.
OSPL-9081 / 00016824 | Potential deadlock in the OpenSplice kernel The OpenSplice kernel has a potential deadlock where two different code paths may claim locks in the opposite order. The deadlock occurs when one thread is reading/taking the data out of a DataReader while the participant's listener thread is processing the creation of a new group (i.e. a unique partition/topic combination) to which this Reader's Subscriber is also attached. Solution: The locking algorithm has been modified in such a way that the participant's listener thread no longer requires to hold both locks at the same time.
OSPL-8956 | Temporary blacklisting of remote participants in DDSI2 The DDSI2 service now provides an option to temporarily block rediscovery of proxy participants. Blocking rediscovery gives the remaining processes on the node extra time to clean up. It is strongly advised that applications are written in such a way that they can handle reconnects at any time, but when issues are found, this feature can reduce the symptoms. Solution: A new setting in the DDSI section of the configuration has been added: Internal/RediscoveryBlacklistDuration along with an attribute Internal/RediscoveryBlacklistDuration [@enforce]. The former sets the duration (by default 10s), the second whether to really wait out the full period (true), or to allow reconnections once DDSI2 has internally completed cleaning up (false, the default). It strongly discouraged to set the duration to less than 1s.
OSPL-9071 | v_groupFlushAction passes a parameter that is not fully initialized. Valgrind reported that the v_groupFlushAction function passes a parameter that is not fully initialized. Although one of these parameters was evaluated in a subsequent function invocation, it never caused issues because the value was only used as an operand for a logical AND where the other operand was always FALSE. Solution: All attributes of the parameter in question are now explicitly initialized.
OSPL-9055 | Potential Sample drop during delivery to a local Reader In some cases, a dispose followed by an unregister does not result in NOT_ALIVE_DISPOSED state on a Reader residing on the same node as the Publisher. In those cases, the Reader has an end state set to NOT_ALIVE_NO_WRITERS, and reports that a sample has been Lost. Solution: We have no clue what could cause this behaviour, but added some logging to capture the context of the erroneous sample drop. This is just a temporary measure, and will be reverted when the root cause has been found and fixed.
OSPL-9056 | Potential deadlock during early abort of an application When an application aborts so quickly that the participant's leaseManager thread and its resendManager thread have not yet had the opportunity to get started, then the exit handler will block indefinitely waiting for these threads to exit the kernel. However, both threads are already blocked waiting to access a kernel that is already in lockdown. Solution: The constructor of the participant will not return before both the leaseManager and resendManager threads have entered the kernel successfully.
OSPL-8953 | Potential deadlock between reader creation and durability notification A thread that creates a new DataReader and a thread from the durability service that notifies a DataReader when it has completed its historical data alignment grab two of their locks in reverse order, causing a potential deadlock to occur. Solution: The locking algorithm has been modified so that these two threads do no longer grab both locks in reverse order.
OSPL-8886 | Durability failure to merge data after a short disconnect When the disconnection period is shorter than twice the heartbeat a durability service may not have been able to determine a new master before the node is reconnected again. In that case no master conflict is generated. In case the durability service is "late" in confirming a master it might even occur that the master has updated its namespace, but the namespace update is discarded because no confirmed master has been selected yet. As a consequence no request will for data will be sent to the master, and the durability service will not be aligned. Solution: In case a durability service receives a namespace update for a namespace for which no confirmed master is selected yet, the update is rescheduled for evaluation at a later time instead of discarding the update.
OSPL-8948 / 16755 OSPL-8987 | Race condition between durability data injection and garbage collecting of empty instances The durability service cached instance handles when injecting a historical data set in a way that could result in the historical samples being thrown away if the instance was empty and no known writers had registered it. Solution: the instance handle is no longer cached..
OSPL-8971 | Catchup policy may incorrectly mark unregistered instances as disposed. When an instance is unregistered on the master node during a disconnect from another node that has specified a CATCHUP policy with that master, then upon a reconnect that unregister message will still be delivered to that formerly disconnected node. However, the reconnected node will dispose all instances for which it did not receive any valid data, so if the unregister message it the only message received for a particular instance, then its instance will be disposed. Solution:The Catchup policy is now instructed to dispose instances for which it did not receive any valid data OR for which it did not receive any unregister message.
OSPL-8984 | DDSI handling of non-responsive readers needs improvement When a writer is blocked for ResponsiveTimeout seconds, DDSI will declare the matching proxy readers that have not yet acknowledged all data "non-responsive" and continue with those readers downgraded to best-effort. This prevents blocking outgoing traffic indefinitely, but at the cost of breaking reliability. For historical reasons it was set to 1s to limit the damage a non-responsive reader could cause, but past improvements to the handling of built-in data in combination with DDSI (such as fully relying on DDSI discovery for deriving built-in topics) mean there is no longer a need to have such an aggressive setting by default. Solution: The default behaviour has been changed to never declare a reader non-responsive and maintain reliability also when a remote reader is not able to make progress. The changes also eliminate some spurious warning and error messages in the log files that could occur with a longer timeout.
OSPL-8920 | DDSI2 Crash Version 6.6.3p4 introduced a fix for OSPL-8872, taking the sequence number most recently transmitted by a writer when it matched reader into account to force heartbeats out until all historical data has been acknowledged by the reader. The change also allowed a flag forcing the transmission of heartbeats informing readers of the availability of data to be set earlier than before in the case where the writer had not published anything yet at the time the reader was discovered. While logically correct, this broke the determination of the unique reader that had not yet acknowledged all data in cases where there is such a unique reader. This in turn could lead to a crash. Solution: the aforementioned flag is once again never set before a sample has been acknowledged.
OSPL-8974 | Durability conflict scheduling fails when multiple namespaces have the same policy and differ only in topic names Durability checks for conflicts between fellows (master, native and foreign state) that may require merging data whenever it receives a "d_nameSpaces" instance. If a conflict is detected, it enqueues it for eventual resolution, but only if an equivalent conflict is not yet enqueued. Testing for equivalency is done by checking: conflict kind, roles and local and fellow namespaces. However, the name space compare function (d_nameSpaceCompare) did not take the name into account, nor the full partition+topic expressions. The consequence is that when namespaces A and B have identical policies and differ only in the topic parts of the partition/topic expressions, a conflict for namespace A would be considered the same as a conflict for namespace B. The result would be a failure to merge data in B. Solution: The comparison now takes the name of the namespace into account. The configuration is required to have no overlap between namespaces and to have compatible namespace definitions throughout the system. The name alone is therefore sufficient.
OSPL-8973 | Additional durability tracing when verbosity is set to FINEST Durability has been extended with additional tracing in the processing of namespace definitions received from fellows, in particular when checking for master conflicts.
OSPL-6112 | An asymmetrical disconnect may lead to an inconsistent data state. The durability service relies on a reliable and symmetrical network topology. Every once in a while it is possible to experience temporary network hickups resulting in temporary asymmetrical network topology (durability service A sees B, but B does not see A). This can typically occur due to high load on one of the machines, or a networking problem. Such asymmetrical disconnects may lead to an inconsistent data state. To recover from such situation the durability service must recognize when such asymmetric disconnect occurs, and trigger the alignment actions to make the data state consistent again. Solution: Asymmetric disconnect situations are detected and the correct alignment actions are triggered to recover from the inconsistent data state.
OSPL-9136 | Protobuf isocpp2 example fails to build on E500mc build The isocpp2 protobuf example fails to build on E500mc due to the fact that the wrong compiler is referenced in the example build script. Solution: The build script has been modified to reference the correct compiler.
OSPL-9267 / 16945 OSPL-9270 / 44079 OSPL-9334 | Coherent set create, delete, unregister, recreate causes the recreate to be lost When an unregister message was received from a coherent writer the connection (pipeline) between the group instance and reader instance was always destroyed immediately while the registration for the group instance was not removed immediately. The destruction of the pipeline with a still valid registration could cause samples written after the unregister to be dropped. Solution: On unregistration from a coherent writer immediately destroy the pipeline and process the unregistration for the group instance, like done for non-coherent writers.
OSPL-9299 | Durability shall allow configuring a master priority Currently it is almost impossible to control which durability service becomes master. This leads to situations that durability instances that should not become master can become master. Furthermore, it is currently not possible to indicate that a durability instance can act as aligner, but should not take up the responsibility to act as master for other instances. To provide more control which node becomes master for a namespace, the //OpenSplice/DurabilityService/NameSpaces/Policy[@masterPriority] attribute can be specified. This is an optional attribute that specifies a value between 0 and 255. Value 0 means that a node will never become master, and value 255 indicates that the legacy master selection will be used. The default is 255. When the masterPriority is specified between 1 and 254, nodes with a higher masterPriority should become master. See the deployment manual for more information.Note that there are currently a few limitations: Mastership handover in case a better but late joining master arrives is currently unsupported. In case of mixed deployments with legacy nodes, the nodes that support masterPriority must use masterPriority=255. Solution: A masterPriority has been implemented on the namespace policy that specifies the eagerness of a durability service to become master for a namespace. This gives a user more control. Note that mastership handover in case a better but late joining master arrives is currently unsupported. This will be addressed in the next release (see OSPL-9358 in known issues list).
OSPL-9329 | Multiple concurrent topology changes may cause durability to switch to majority voting The current implementation of the master selection algorithm in durability falls back to majority voting in case no agreement for a master can be established in a limited number (4) of election rounds. When various topology changes occur concurrently then it is likely that no agreement is reached in the maximum number of rounds. The master selection algorithm then falls back to majority voting. Because different durability services may have a different view of their world, majority voting may lead to different masters in the system and an inconsistent end state for the data on various nodes. Solution: To decrease the likelihood that the master selection algorithm falls back to majority voting we have increased the maximum number of rounds to 50 before the fallback will occur. This may lead to a longer master selection phase in case multiple topology changes are occurring concurrently, but increases the possibility that the end state is consistent.
OSPL-9333 / 17011 | DDSI2 private memory growth when unregistering T-L instances/deleting entities without any peers present The DDSI2 service was holding on to the unregister messages for transient-local instances inside the writer history while disconnected from the rest of the world. When another node showed up, it would receive and acknowledge all these messages, but without significant effect on the receiver as they only described the unregistering of unknown instances/entities. Reception of an acknowledgement of a new T-L message or creation of a new entity sent while another node is connected would clear out these unregisters. Solution: When no peer exists, do not retain the unregister messages in the writer history cache.
OSPL-9335 / 17009 | Spliced not inheriting priority from "ospl start" TThe "ospl start" command always started spliced with a default priority in a default scheduling class (timeshare on typical platforms), independent of the actual priority of the "ospl" tool itself. This is contrary to what one would expect, and moreover made it impossible to force the threads that are not independently configurable to run at a certain priority. Solution: The behaviour of "ospl start" has been changed so that "spliced" now inherits its priority.
OSPL-9365 | The durability service can hang when requesting data from multiple fellows and some of them leave after having provided a partial set When the durability service determines it needs to request samples from multiple fellows to align with them (typically after becoming a master), it greedily dedups the incoming samples to reduce memory requirements before applying the configured merge policy. When a fellow disappears after providing some but not all samples in the set, the ones already received need to be removed from the received set. The administration of the received, dedup'd set was lacking the information needed to do this correctly. This then potentially resulted in the durability service waiting forever for the set to become complete. Solution: The durability service now annotates each sample with the set of fellows that have provided it.
OSPL-9388 / 17030 | Durability service might deadlock when the networking queue is flooded. When the network queue is overrun by the durability service, the normal mode of operation is to sleep a bit and retry again later. However, there is a slight chance that the sending thread of the network service that needs to make room again by consuming elements in the queue will indirectly block on the sleeping thread in the durability service itself. Solution: The network service can no longer indirectly run into a lock that is held by the durability service while the network queue is flooded.
OSPL-9408 | Memory is leaked when readers request historical data. If a reader requests historical data, some internal administration is created. A small part of this is not freed, resulting in a memory leak. In case readers are created and destroyed in a loop, the total amount of memory that is lost can become significant. Solution: The identified leakage areas have been fixed.
OSPL-8017 | DDSI2 did not renew a participant lease for every received message The DDSI2 service discovers remote participants and automatically deletes them if they do not renew their leases in time. The lease renewal was tied to reception of data and of explicit lease renewal messages, and hence reception of, e.g., an acknowledgement would not lead to a lease renewal, even though it obviously requires the remote participant to be alive. Solution: DDSI2 now renews leases regardless of the type of message
OSPL-9485 | Durability may mark aligned samples as duplicates while they are not and drop them Durability combines incoming samples into a set while filtering out duplicates, but fails to take into account all fields that determine its uniqueness. This can lead to dropping samples from the set that would have affected the state of the system or result in durability never considering the set complete. Solution: The function to compare samples to determine uniqueness has been modified to ensure all relevant attributes are taken into account.
OSPL-9501 | Durability service may wait forever on asymmetric disconnect with a fellow When a fellow is asymmetrically disconnected while samples are being requested it is possible that one or more of these sample requests are not received by the fellow, or that the response is lost. The durability service that sends the sample requests will be waiting for answers until all answers are received. But since the fellow was asymmetrically disconnected and requests or responses may have been lost, the durability service may wait forever for answers that will never come, thereby blocking progress of the durability service. Solution: When a fellow is asymmetrically disconnected all pending sample requests are discarded. In that case the durability service will not wait for answers anymore and continue operation. Reappearance of the fellow may lead to new alignment actions that are handled consecutively.
OSPL-9502 | Durability not always syncing with new master Durability services negotiate a master to align data from. It has been observed that a deceased fellow got chosen as master. It is evident that chosing a deceased fellow as master will not lead to alignment and may lead to inconsistent data state. Solution: The algorithm that caused the deceased master to be chosen has been modified to prevent this situation from happening.
OSPL-9503 | Durability may wait for responses from already disconnected fellow To keep a consistent state durability services may request data from each other. When a durability service is waiting for answers to such requests from a fellow and that fellow 'leaves', the durability service cleans up the pending requests correctly. However, when the fellow leaves while the durability service is concurrently sending out the requests, it is possible that not all requests are cleaned up correctly. In that case the durability service will keep waiting for data from the fellow that has left forever. This stalls the alignment process until the service is completely restarted. Solution: Slight changes in the locking strategy prevent concurrent sending of requests and cleaning them up on fellow disconnection.
OSPL-9514 | Memory leak in core Each time a DataReader is created a small amount of memory is leaked due to a missing free. Solution: The missing free has been added.
OSPL-9522 | DDSI2 transmit path can lock up when two partially asymmetric disconnections overlap Consider a situation where: on node A the lease of B expires, and then on node B the lease from A expires while A rediscovers B, and then B rediscovers A. Then imagine that just before the lease of A expires on B, a heartbeat by a transient-local or endpoint discovery writer on A is multicasted and received, processed and responded to by B, ACK'ing everything. Then, in the particular case where A receives that acknowledgement just after rediscovering B, A will assume that B has received and ACK'd everything, and not send heartbeats out on B's behalf. In this situation, B will still send pre-emptive ACKs until it receives a heartbeat from A; this will trigger a retransmit of the missing data. If some of this data is lost on the network, and no other readers exist to force A to multicast heartbeats, then the DDSI specification requires B to wait with requesting a further retransmit until a heartbeat is received. (The most likely reason for this to happen is writing new data on A.) In the particular case where the lost data concerns endpoint discovery data, full connectivity will then not be established properly. If B has missed out on the definition of a data writer, then B will not acknowledge any data writer by that writer as it doesn't know the writer, which may cause the transmit buffers on A to fill up, and hence may lock up the DDSI transmit path on A until the reader on B is declared non-responsive. Solution: DDSI2 will now automatically re-request a retransmit after a configurable amount of time, by default 1s, but this may be disabled for strict compliance with the specification. Under normal circumstances, the retransmits will arrive much sooner, and so no additional network traffic will typically be generated by this change.
OSPL-9533 | Durability with master priority 0 not retrieving data after master reconnect The durability service clears the merge-state and master of its local namespaces when it is not an aligner (or has taken a mastership poison pill) and a fellow is removed with the same role even if that removed fellow was not the master of the name-space. Effectively this means the master is cleared even though it is still connected. Secondly, the durability service does not request the data from the new master if its master priority = 0. Solution: Only reset the master and clear the state of a nameSpace if the removed fellow actually is the master of the nameSpace. Additionally, durability with master priority 0 now requests data from master after resolving a master conflict.
OSPL-9433 / 17161 | Purging instances while merging hasn't finished may result in wrong end-state of an instance When an instance is purged because it reached its end-state while merging, the merge may reintroduce the instance falsely. This can for example happen when an instance is contained in the merge, but while the merge is ongoing, the instance is disposed and unregistered. In that case the instance can disappear. When the merge is finished, there is no way for the middleware to tell whether the instance contained in the merge isn't valid anymore. Solution: While there is a merge or regular alignment action ongoing, purging of instances that have reached their end-state is deferred. There is a known limitation to the current implementation w.r.t. the use of RTNetworking. Furthermore, there is a small time-frame in which this suppression may not be effectuated correctly if a node is (re)connecting at the end of merging. This will be fixed in an upcoming release and is covered in OSPL-9612.
OSPL-9542 | Raising the namespace state for a namespace while there are still pending conflicts for the namespace may cause scalability issues. Whenever nodes (re)connect the durability service has a potential inconsistent state. To solve these the durability service will generate conflicts and handles them one by. When a conflict has been handled the durability service currently can raise the state of one or more namespaces for which it is master. Raising the state causes the slaves to acquire data. Currently, the state is potentially raised after each conflict. In case there a pending conflicts for the same namespace, raising the state is is not very smart because is causes slaves to request data multiple times. A better approach would be to raise the state after the last conflict for the namespace has been handled. This would cause slaves to requests the data only once instead of multiple times. Doing this will improve scalability. Solution: The state of a namespace is now only raised when there are no more pending conflicts.
OSPL-9561 | When unregistration creates implicit registration the unregistration is not processed When an unregistration message is the first message received it is used to create a registration message. This registration message has the same write time, gid and sequence number as the unregistration and even though the state differed it was dropped as duplicate. Solution: When comparing messages the state is now also used to determine if its a different message.
OSPL-9566 | Possible durability crash when injecting transactions when for one of the writers the DCPSTopic is not yet received When injecting an EOT message via durability a crash could happen when the list of writers available in the EOT was evaluated and for one of the writers in the list the DCPSTopic was not yet received while the DCPSPublication was. The combination of DCPSPublication and DCPSTopic was used for discovery of the writer and the implementation assumed the it always received the DCPSTopic before the DCPSPublication, this assumption would lead to the crash. Solution: When discovering the writers in the EOT now only the DCPSPublication is used.
OSPL-9593 | Overflow of internal metadata reference counts Loading the same topic type into OpenSplice in a loop could overflow the reference counts of some internal metadata objects. This in turn could lead to freeing important metadata, eventually crashing the application Solution: The reference counts are now forced to a maximum value if they would otherwise overflow.
OSPL-9598 | Deletion of DomainParticipant in ISOC++v2 API may trigger invalid handle detected error report When an ISOCPP2 application creates 2 participants, and closes the 2nd participant, the info log will contain a message like this: "invalid handle detected: result = U_RESULT_ALREADY_DELETED, Entity = 0x7ffed4c045f0 (kind = U_LISTENER)". This was caused by the fact that the explicit deletion of the Listener in question was postponed til AFTER the deletion of its participant, which already implicitly deletes it as well. So the Listener effectively got deleted twice. Solution: The listener in question is lo longer deleted explicitly, but its deletion is left to the participant which will eventually delete it implicitly. This way the listener can never be deleted twice.
OSPL-9621 | When all data for a partition/topic combination has become complete, this new state is not always advertised The durability service is responsible for keeping durable data sets consistent. When a durability service has retrieved all data for a particular partition/topic combination, the data set is marked is complete. In some cases the event that the data is complete is not advertised. This may stall other durability services that wait for the data set to become complete. Solution: When the set of data for a partition/topic combination has become complete, the completeness is advertised. This may trigger alignment from remote nodes.
OSPL-8883 OSPL-8970 / 16949 OSPL-9105 / 16841 | Semantics for instance state not clearly defined after reconnect. The effects of a disconnect on the instance state of your data is clearly defined: all data originating from the disconnected node(s) becomes NOT_ALIVE_DISPOSED in case it was written with a writer using auto_dispose_unregistered_instances=TRUE or NOT_ALIVE_NO_WRITERS in case it was written with a writer using auto_dispose_unregistered_instances=FALSE. However, the effect of a reconnect to the previously disconnected node on these instance states was not clearly defined. Solution: We have now specified the following behavior for a previously disconnected instance: In case of VOLATILE data, the instance state remains the way it was (NOT_ALIVE_DISPOSED or NOT_ALIVE_NO_WRITERS) until an new update for that instance arrives, that will set the instance state back to ALIVE and the view state to NEW. In case of TRANSIENT/PERSISTENT data, previously consumed samples may re-appear due to re-alignment to the disconnected node. However, these re-aligned samples will appear as NOT_READ, and will set the instance state back to ALIVE and the view state to NEW. Of course, any previously unseen samples will so the same thing. Although it might seem weird that previously consumed samples re-appear as NOT_READ, this actually allows you to use standard mechanisms (e.g. a read/take with sample state NOT_READ) to filter out all instances whose instance state has been impacted by the reconnect. (a read/take with sample state READ would just have returned all instances, also the ones whose state did not get modified as a consequence of the disconnect/reconnect cycle).
OSPL-9069 / 16818 | DDSI2 reports an inscrutable error when presented with a topic definition it doesn't support DDSI2 reported errors such as "handleDataReader: new_reader: error -1" for topics it doesn't support. This typically means the length of the serialised key exceeds 32 bytes (counting strings as 4 bytes), but this was not in any way expressed by the error message. Solution: The error messages now properly identify the problem, including topic and type names.
OSPL-9111 | In case client durability is configured no historical data is retrieved when a non-volatile reader is enabled. The reference manuals indicate that when a non-volatile reader is enabled, a request for historical data should be send out. In case client durability is configured this request was not sent out. Consequently, no historical data is retrieved when the reader becomes enabled. Only after an explicit call to wait_for_historical_data historical data will be retrieved. Solution: When a non-volatile reader becomes enabled a request for historical data is being send out, causing historical data to be retrieved.
OSPL-9243 / 16947 | Instances may keep track of unlimited amounts of invalid samples. When an event occurs on a reader instance (like a dispose or unregister) an invalid sample carrying the event context is inserted in the history of this reader instance. These invalid samples may eventually be pushed or taken out of the history, but there are scenario's in which neither will occur (for example when I repeatedly disconnect/reconnect to the producer of the instance without any new data being added in the process while I do not actively take the resulting invalid samples out of the reader). In such cases the Reader might collect an unlimited amount of invalid samples claiming more and more resources in the process without any restrictions. Solution: Each instance can now only have 1 invalid sample at most and an invalid sample can only be located at the tail of the instance. Newer invalid samples will simply replace older invalid samples. However, even a removed invalid sample will still cause an increment in the generation counts of the samples following it.
OSPL-9358 | Mastership handover. Until now late joining nodes always slave to an existing master. With the introduction of master priorities (see //OpenSplice/DurabilityService/NameSpaces/Policy[@masterPriority]) it is possible to assign a mastership preference to nodes. In case a late joining node has a higher preference than the existing master, the late joining node should become master instead of slaving to the existing node. This requires handover of mastership. Solution: Late joining nodes with a higher mastership preference than the current master now trigger a merge so that handover of mastership is established.
OSPL-9437 | When using a topic with history depth (default) it is possible that a group coherent transaction never becomes complete when live data and alignment data are received simultaneously. When the durability service aligns a group coherent transaction for which samples have been pushed out of the history due to history limits and part of that same transaction is received via live communication it is possible that the transaction never becomes complete on the federation that's being aligned. When the aligned federation received the EOT via live communication and a special EOT via alignment, the internal EOT counter gets an invalid value which results in the group never being marked as complete. Solution: Reception of EOT via live communication and alignment is now handled correctly.
OSPL-9478 | Reader not getting locally stored transactional historical data when last message was an unregistration. When creating a reader on a federation that has open historical transactions and the last message in that transaction is an unregistration the historical open transaction is not injected in the reader as the injection tries to use a non-existing pipeline. Solution: No longer use the pipeline for injecting locally stored transactional historical data into the reader.
OSPL-9486 | Complete group coherent set not flushed when completed by publicationInfo notification on the reader When a publicationInfo notification on the reader completes a group coherent set the set was not flushed when it became complete. In case no transactions would follow the readers or subscriber would never be notified. After calling begin_access the set was available for the readers. Solution: PublicitionInfo notification on the reader now flushes the set to the readers
OSPL-9534 | The reader operation take_next_instance might skip instances with invalid samples. The reader operation take_next_instance is expected to return the next matching instance starting from the instance identified by the specified instance handle. However, in case the next matching instance contained only an invalid sample, instead of returning this invalid sample the instance would be skipped and the next matching instance would be returned instead. Solution: The algorithm to identify the next matching instance has been corrected to no longer skip an instance that has only got an invalid sample.
OSPL-9562 | Fake heartbeat unregistered while never written The splice daemon is responsible for writing fake heartbeats on receiving a DCPSParticipant form a remote federation, the writing of these heartbeats happens conditionally based on existing heartbeats. The splice daemon unconditionally unregisters its fake heartbeat. From version V6.5.0p5 and up DDSI and RTNetworking services write a heartbeat before forwarding any samples so in that case the splice daemon will not write a fake heartbeat but does unregister the fake heartbeat. The unregistering of the fake heartbeat lead to an invalid liveliness state (to high). Which could cause missing of disconnects on application level Solution: Unregistering of the fake heartbeat is now also conditional
OSPL-9652 | When an asymmetric disconnect occurs while there are pending sample requests, alignment may not progress. Asymmetric disconnects may occur at any time. In particular, it is possible that an asymmetric disconnect occurs while a durability service has outstanding sample requests to another durability service. In case a durability service (say A) has lost connection with another durability service (say B) but not vice versa, and B is waiting for answers to outstanding sample requests from A, then B might not receive an answer because A has lost connection to B. This may stall alignment. In such situation B must cancel the pending sample requests to A, and re-initiate alignment as soon as bidirectional communication is established again. Solution: When an asymmetrical disconnect is detected pending sample requests to the asymmetrically disconnected node are cancelled.
OSPL-9676 | Creating (enabling) a data writer in a non-coherent publisher between begin/end coherent set sets transactionId on writer Creating (enabling) a data writer in a non-coherent publishe between begin/end coherent set copies the next sequence number (1) to the transactionId on the writer, which then causes all published data to be treated as-if part of a transaction that will never be committed. The data will be delivered because the only matching readers are non-coherent, but transient data will be retained in the transaction administration in the group. Solution: A transactionId is no longer set when creating a writer in a non-coherent publisher.
OSPL-9677 | The durability service does not parse the //OpenSplice/Domain/GeneralWatchDog and //OpenSplice/DurabilityService/Watchdog configuration items correctly. Watchdog threads are used to track progress of services. Users can specify the properties of the watchdog thread using the generic //OpenSplice/Domain/GeneralWatchDog setting. Individual service like the durability service service can override these values by specifying //OpenSplice/DurabilityService/Watchdog. The durability service did not parse these settings correctly, causing the specified values to be non-effective. Solution: The parsing has been changed so that changes to these settings now take effect.
OSPL-9701 | The auto_dispose setting of a DataWriter is not always processed atomically. When the DataWriter uses and auto_dispose_unregistered_instances setting of TRUE, the reader side would not expect to see an instance state of this Writer to ever become NO_WRITERS. However, because the auto_dispose setting is not always handled atomically, in certain scenario's we might end up with a reader instance whose instance state is NO_WRITERS nevertheless. An example of such a scenario is when an autodisposing DataWriter explicitly disposes and then unregisters an instance. If a late joining node requests alignment between the dispose and the unregister, then the unregister message might be received first through the normal network connection, while the older dispose message arrives later as part of the alignment process. That means the instance state will first go to NO_WRITERS, and the older DISPOSE message can no longer undo this. Solution: An unregister message from an autodisposing writer will now always be treated as a combined DISPOSE and UNREGISTER message. That means that is the unregister arives before the explicit dispose, it will still set the instance to DISPOSE and not to NO_WRITERS.

## 6.7.2

Report ID. | Description
--- | ---
OSPL-9085 / 16827 | Race condition between multiple simultaneous started OpenSplice daemons with the same domain configuration. Starting multiple OpenSplice daemons in shared memory mode for the same domain configuration at the same time could lead to a crash. Solution: The race condition between the multiple OpenSplice daemons is fixed and a consecutive started daemon will be detected correctly and exit properly.
OSPL-9672 | Java5 Helloworld example creates topic with wrong QoS. The Java5 Helloworld examples creates a topic with the default QoS. This differs from all other language binding HelloWorld examples. As a result of this an error message will be reported when this example wants to communicate with other language binding HellowWorld examples. Solution: The defect is fixed and the Java5 example now creates a topic with the correct QoS so it can also communicate with the HellowWorld examples from other languages.
OSPL-9684 | A failing networking service does not always restart with FailureAction configuration restart. When a networking service detects a failure, it'll terminate as gracefully as possible. The splice daemon was not able to detect whether the networking service terminated due to a valid stop or due to a detected failure. This means that the splice daemon did not restart the networking service when it failed gracefully. Solution: Set the networking service state to died when it failed gracefully.
OSPL-9738 | When the durability service terminates a mutex is not cleaned up properly and potentially causes a memory leak. The durability services uses various mutexes to protect access to shared resources by different threads. One such mutex is used to protect updates to a sequence number. This mutex is not cleaned up properly. Solution: The mutex is now cleaned up properly.
OSPL-9797 / 17608 | DataWriter deletion is not always reflected in the instance_states of the DataReader. When two nodes have unaligned clocks and are using BY_RECEPTION_TIMESTAMP destination ordering, and the clock of the sending node runs ahead of the clock on the receiving node, then the deletion of the DataWriter on the sending node may not always correctly be reflected in the instance_states of the DataReader. These instance_states should go to either NOT_ALIVE_DISPOSED or NOT_ALIVE_NO_WRITERS, depending on the auto_dispose_unregistered_instances setting of the DataWriter. However, when the clock skew is bigger than the lifespan of an instance, its instance_state might remain ALIVE after deletion of the DataWriter. Solution: The algorithm now always applies the correct instance_state in the above mentioned case.
OSPL-6636 / 17203 | In the Isocpp2 API a deadlock may occur when a listener is removed when a listener callback is in progress. When using the Isocpp2 API a deadlock may occur when removing a listener. Before a listener callback is called a mutex lock is taken to prevent that the listener can be destoyed when the listener callback is active. When in the listener callback an Isocpp2 operation on the corresponding entity is called the associated entity mutex lock may be taken. When at the same time the entity is being closed from another thread a deadlock may occur because both involved mutex locks are performed in different order. Solution: For all listener operations a separate mutex is used to prevent the listener to be removed when a listener callback is active. This lock is used outside of the normal entity lock which ensures that no deadlock can occur.
OSPL-9675 / 17534 | Unnecessary error trace in the classic C++ API. An error will be traced when getting the listener of a Subscriber, Publisher, DataWriter or DataReader when no listener was set. This isn't really an error and the traces are unnecessary and even unwanted. This error is also traced when calling Subscriber::notify_datareaders(). Solution: The error traces are removed.
OSPL-9730 / 17556 | Out of sync dispose_all_data. The dispose_all_data is an asynchronous C&M operation that is not part of a coherent update. It is advised to use BY_SOURCE_TIMESTAMP as destination_order when using dispose_all_data to negate the asynchronous behaviour of it. However, the dispose_all_data still uses the BY_RECEPTION_TIMESTAMP of the built-in C&M operation. This introduces a small timing issue when another node executes the dispose_all_data and immediately writes a new sample. If the write overtakes the dispose_all_data, it is possible that the dispose_all_data will dispose of that sample, while in fact the sample is newer than the dispose and should be retained. Solution: The dispose_all_data handling now uses the source timestamp in stead of the reception timestamp regardless of the built-in topic destination_order.
OSPL-9823 | C# API reports "Detected invalid handle" in error log during onDataAvailable callback. When the C# API performs an onDataAvailable callback on a DataReaderListener, it also logs a message in the error log that states that an invalid handle was detected. The error reported is harmless and totally irrelevant, and your application will continue to function properly. Solution: An onDataAvailable callback will no longer cause this error to show up in the log.

## 6.7.1p3

Report ID. | Description
--- | ---
OSPL-9430 / 17158 | The isocpp2 API does not report an error when the generated discriminant setter related to a union is used incorrectly. For a union type the idl preprocessor generates an setter for the discriminant of the union. This is the _d(val) function. However, this setter may only be used to set the discriminant to a label that corresponds to the current state of the union. A union case may have more than one label associated with an certain case. With the use of the _d(val) function it is only allowed to set the discriminant to one of the alternative labels associated with the current selected case. However when this setter is used incorrectly the isocpp2 API does not raise an exception and it may cause a crash of the application. Solution: The generated discriminant setter function _d(val) checks if the specified value corresponds with the current state of the union and raise an exception otherwise.
OSPL-9444 | Move iShapes example from isocpp to isocpp2. The iShapes example should work on top of the isocpp2 i.s.o. the deprecated isocpp API. Solution: The example has been ported to the isocpp2 API

## 6.7.1p2

Report ID. | Description
--- | ---
OSPL-8405 / 16519 | The discovery channel of the networking service may miss disconnects when it is configured for a very small detection period. When the discovery channel of the networking service is configured to detect the death (disconnect) of an node within a few 100 msec, then it may occur that the disconnect is not detected. In that case the discovery channel may not detect the disconnect because of an incorrect scheduling of the time the evaluation of the discovery heartbeats occurs. This may cause that a reliable channel becomes stalled when a reconnect of a node occurs which is not detected. Solution: The scheduling of the heartbeat evaluation is moved to the receive thread of the discovery channel to make it independent of the scheduling of the main networking thread. Furthermore, the heartbeat evaluation time is made more strictly related to the maximum interval in which a heartbeat should have been received from a node.
OSPL-9027 | idlpp is not robust to paths with whitespace. The idlpp tool is not able to handle paths that contain whitespaces when compiling for cpp and thus using cppgen. Solution: Add quotes to the arguments for cppgen, which are generated by idlpp.
OSPL-9030 | OSPL_URI not set correctly in console run. The OSPL_URI can be set using the Launcher Settings dialog. The user can select a file using the browse dialog by clicking the "..." button. The file path must be prepended with "file://". When using the browse dialog, the "file://" was not being included. Solution: When using the OSPL_URI browse dialog, the "file://" is now prepended to selected file path.
OSPL-9363 / 17024 OSPL-9075 / 16821 | Possible spliced deadlock when other services crash. When another service or application crashes and leaves the kernel in an undefined state, it can happen that the splice daemon will deadlock and will never shutdown. Solution: Added a thread watchdog to spliced and abort when the shutdown-thread deadlocks.
OSPL-9389 | Potential crash when removing certain entities concurrently in classic java PSMs When a datawriter or datareader is removed by one thread, while a different thread is removing the corresponding subscriber or publisher, in Classic Java PSMs (SAJ and CJ), the application can crash. Solution: The issue was resolved by changing the locking strategy so that a publisher/subscriber cannot be removed when one of its datawriters or datareaders is in use by a different thread.
OSPL-9491 | Terminating Streams example causes invalid memory free When the Streams subscriber or publisher example is terminated before it completes, i.e. by pressing Ctrl-C, it can trigger an invalid free of the partition name. Solution: The issue is resolved by using a copy of the partition string that can be freed under all circumstances.
OSPL-9506 | RnR service crash when replaying DCPSTopic The RnR service can crash when replaying DCPSTopics. This is due to an improper free. Solution: The improper free in the RnR service is fixed.
OSPL-9540 / 17190 | The networking service exits with a fatal error when a best-effort channel runs out of buffer space. When the situation occurs that all the defragmentation buffers for a best-effort channel are in use and a new buffer is needed then the networking service will first reclaim fragment buffers from messages which are not yet complete (fragments missing) or from the list of buffers waiting to be defragmented. When it fails to free a buffer then the networking service will terminate with a fatal error indicating that it has run out of defragmentation buffers. Solution: When the situation occurs that a best-effort channel runs out of defragmentation buffers and is not able to reclaim a buffer then it will stop reading from the socket until buffers become available again. Note that this may cause that fragments will be lost when the maximum receive buffer size of the socket is exceeded. For a best-effort channel this is allowed.
OSPL-9551 | Some buttons on Tuner's Writer Pane are connected to wrong Writer functions Some Buttons on the Tuner's Writer Pane are connected to the wrong Writer functions: The Register button is connected to the Dispose function (Should be register). The Unregister button is connected to the Dispose function. (Should be unregister) Solution: The handlers for the various buttons have been corrected.
OSPL-9552 / 17191 | The networking service should log the selected network interface. The networking service does not report the network interface that is has selected. To support the analyses of problems on hosts which have more than one network interface configured it the networking service should report the selected network interface. Solution: On startup of the networking service the selected network interface is reported in the info log. The name of the interface is also included in the report which indicates that networking has detected a state change of the network interface (down/up).
OSPL-9608 | Samples can be purged prematurely Purging samples depends (among other things) on the service_cleanup_delay. If opensplice is started when the up time of the node is smaller than the service_cleanup_delay, then disposed samples will be purged permaturely. Solution: Improve check between node up time and the service_cleanup_delay.
TSTTOOL-437 / 17181 | OpenSplice Tester crash When running tester scripts in headless mode, ArrayIndexOutOfBoundsExceptions are sometimes thrown and logged to the console. The exceptions were the result of a race condition on startup. Solution: A fix was made in the MainWindow to prevent the race condition when populating filtered topics.

## 6.7.1p1

Report ID. | Description
--- | ---
OSPL-9047 / 16793 | Deadline-missed events are not necessarily triggered per instance When multiple deadlines are missed around the same time and a listener is used to monitor these events, only a single listener callback may be performed. Solution: A separate listener callback is performed for each missed deadline.
RNR-704 / 17155 | RnR CDR recording cannot be imported RnR is not properly processing the situation where there is no active union case. Solution: RnR now accepts the option of not having an active union case.

## 6.7.1

Report ID. | Description
--- | ---
OSPL-7942 OSPL-9207 / 16854 | Thread specific memory leaking away after thread end Threads that are created from a user application don't use the ospl internal thread wrapper. Thread specific memory allocated by the ospl software stack isn't freed when these threads exit. Solution: Use OS supplied callback functionality to call a destructor function when a user created thread exits to free allocated memory.
OSPL-8425 / 16551 | When a lot of fragmented, best effort data is received, the receiver will run out of buffer space Defragmentation buffers is shared with the receive buffer. In case a lot of data is received, the networkstack isn't able to free claimed buffer space as it doesn't get to time to defragment data in the buffers. As a result, incoming data can not be stored and networking can't recover from this situation as these buffers remain locked. Solution: In case no buffers can be freed, drop data in buffers to create free space to be able to receive new data and continue to function. Data in the dropped buffers is lost but as this is best-effort data, this is allowed.
OSPL-8813 | Calling RMI C++ CRuntime::stop() can cause deadlocks When RMI C++ CRuntime::stop() is called, it can deadlock due to timing. Two threads will wait until the other is stopped. Solution: By caching certain information, it's not necessary for one thread to wait for the other while stopping.
OSPL-8958 | DDSI can regurgitate old T-L samples for instances that have already been unregistered DDSI maintains a writer history cache for providing historical data for transient-local writers and for providing reliability. An instance is removed from this cache when it is unregistered by the writer, but its samples are retained until they have been acknowledged by all (reliable) readers. Already acknolwedged samples that were retained because they were historical data could survive even when the instance was removed. When this happened, a late-joining reader would see some old samples reappear. Solution: deleting an instance now also removes the already acknowledged samples from the history.
OSPL-9058 / 16796 OSPL-9206 / 16852 | Incompatibility with versions before V6.5.0p5 An internal change to builtin heartbeat topic caused an incompatibility with older versions. When adding a node running a recent version of OpenSplice to a domain with nodes running a version before V6.5.0p5, the existing nodes would incorrectly dispose participants (and corresponding entities) belonging to the new nodes after a single heartbeat period, normally done only when a heartbeat expires. Solution: To resolve this, the change to the heartbeat topic was reverted.
OSPL-9059 / 16803 | Custom Lib missing for ISOCPP2 on DDSCE-P708-V6x-MV-A Custom LIb missing for ISOCPP2 on DDSCE-P708-V6x-MV-A target platform. Solution: Custom lib got added for this platform too.
OSPL-9113 | When the persistent store contains an unfinished transaction a non-coherent reader may not receive the corresponding historical data. When the durability service injects persistent data and the persistent data set contains unfinished transactions and there is a non-coherent reader present then this reader will not receive the data of these unfinished transactions. For persistent data the durability service unregisters each instance after injecting. However, the injection the historical samples of a transaction expect that the instance is still registered. Solution: When retrieving historical data and the historical data contains unfinished transaction then the corresponding samples are injected into the non-coherent reader independent from the existence of a registration for the corresponding instance.
OSPL-9208 | DDSI not sending an SPDP ping at least every SPDPInterval DDSI has a Discovery/SPDPInterval setting that is meant to set an upper bound to the SPDP ping interval, that is otherwise derived from the lease duration set in the //OpenSplice/Domain/Lease/ExpiryTime setting. The limiting only occurred when the lease duration is > 10s. Solution: The limiting has been changed to ensure the interval never becomes larger than what is configured.
OSPL-9216 | Calling RMI C++ CRuntime::run() can cause deadlocks When RMI C++ CRuntime::run() is called when the runtime is already running, then the running state is detected and that call will leave the runtime immediately. However, it does so without unlocking a mutex. Further interaction with that runtime is likely to hit that locked mutex and thus deadlock. Solution: Unlock the runtime when a problem is detected during the run() call.
OSPL-9240 / 16923 | Memory leak in entities with listener The listener administration shared by all language bindings, leaks a small amount of heap memory each time an entity is removed that has a listener attached to it. Solution: The issue was resolved by properly freeing admin data when a listener is detached from an entity manually or when the entity is removed.
OSPL-9248 | Error while building FACE C++ example on windows 64 bit When building the FACE C++ example on windows 64 bit an error LNK2001: unresolved external symbol coming from the DataState class could occur. Solution: The defect in the DataState class has been fixed and the error will not occur anymore.
OSPL-9250 / 16928 | RMI Java runtime stop can cause NullPointerException. By external interference of the RMI internals or specific timing, it is possible that RMI Java runtime stop() can throw a NullPointerException. Solution: Added various null pointer checks.
OSPL-9291 | Possibly wrong durability master confirmation due to not waiting heartbeat expiry period. When a reconnect occurred it was possible that durability services confirmed a federation as master while the one they confirmed themselves confirmed a different federation as master. This would lead to durable data not being aligned until a new durability conflict is triggered. The cause of this problem was that the durability service should wait the heartbeat expiry period before confirming a master, however the wait did not occur. Solution: During master selection the wait heartbeat expiry period now works again.
OSPL-9361 / 17014 | Incorrect IDL code generation for IDL that contains an array of a typedef which refers to a string type. For an IDL definition that contains an array of a typedef and the typedef refers to a string then the copy-in routines generated by the IDL preprocessor (idlpp) is incorrect. The string members are copied to a wrong memory location. Solution: The code that is generated by the IDL preprocessor for this array type is corrected.
OSPL-9388 / 17030 | Durability service might deadlock when the networking queue is flooded. When the network queue is overrun by the durability service, the normal mode of operation is to sleep a bit and retry again later. However, there is a slight chance that the sending thread of the network service that needs to make room again by consuming elements in the queue will indirectly block on the sleeping thread in the durability service itself. Solution: The network service can no longer indirectly run into a lock that is held by the durability service while the network queue is flooded.
OSPL-9413 | Memory leak in RnR service when using XML storage. The RnR service leaks memory for every data update when using XML storage. Solution: Free internal RnR service variable.
OSPL-9441 | IsoCPP dds::sub::CoherentAccess destruction will throw an exception when end() was called on that object. The dds::sub::CoherentAccess destructor will end a coherent access. When the coherent access was already ended by a call to dds::sub::CoherentAccess::end() prior to the destruction of that object, the destructor will throw an precondition_no_met exception when it tries to end the already ended coherent access. An exception in a destructor can cause undefined behaviour (like a crash on VS14). Solution: Check if the coherent access is already ended before ending it again in the destructor.
TSTTOOL-434 | Participant reader and writer tables - QoS column display and tooltip incorrect In the Browser tab, if the user navigated to a participant, the corresponding reader and writer tables did not display the qos values correctly. Solution: This regression was introduced in 6.7.0 and has been fixed in 6.7.1.

## 6.7.0

Report ID. | Description
--- | ---
OSPL-8709 / 16660 | Problem with triggered read condition when order access is used When using order access there is a possibility that a reader continues to receive data available events, but reading or taking results in no data available. This is caused by a disposed not being purged, causing invalid samples to retain in the data reader. Solution: When taking data, purge invalid samples in stead of retaining them in the reader.
OSPL-8950 / 16756 | Memory increase of in-active RMI proxies An RMI proxy will receive replies (of the related service) meant for other proxies on other nodes. The middleware takes care of filtering the proper replies for the proxies on the local node. However, when the RMI proxy is in-active (it is created but not used to send requests), the replies are not cleared from the proxy reply reader memory. When the RMI proxy becomes active (sending a new request) all replies are taken from the reader and the memory is back to normal. However, the memory usage can increase on a node when the proxy is in-active. Solution: The proxy reply reader is always monitored and unrelated replies are removed from its memory.
OSPL-8438 / 16569 | Builtin types not properly supported in ISOCPP2 When using any of the builtin types (types defined in dds_dcps.idl or defined in its included files) in your own IDL file (properly including the relevant IDL file in which it is defined), then the copy functions generated by idlpp would have compilation issues where referenced functions could not be found. Solution: The previously missing referenced functions have now been added to the ISOCPP2 library.
OSPL-9122 | Error report during termination when LivelinessLost listener callback was set When using a LivelinessLost listener callback in your application it could happen that during termination of the application an error report "Internal error DataWriter has no Publisher reference" occurs in the ospl-error.log file. Solution: The defect is fixed and the error will not occur anymore.
OSPL-9015 | Deletion of a reader after all group coherent transactions were received and read could lead to new transactions never becoming complete. When deleting a group coherent reader, which was part of a previous complete and read group transaction, it was possible that other readers in that group coherent subscriber would not be able to read a newly send transaction. The new transaction was never marked complete since it still expected data for the deleted reader. Solution: Updated the coherent administration so that the reader is not longer part of future group transactions.
OSPL-8900 | Tuner - When writing data with the standalone writer frame, it is not possible to edit collections. Normally, in the reader-writer frame, right-clicking on a sequence user data field brings up a context menu to Add Details to the collection. The same action is missing from the standalone writer frame. Solution: The writer frame's table now has the ability to edit collections in the same manner as the reader-writer frame does.
OSPL-8577 | Tuner - When writing data with the standalone writer frame, the data model is not properly initialized. When writing data in the standalone writer frame, accessed via the context menu option "Write data" on any Writer tree entity, clicking the Write button without first editing any of the default table values results in write error. Solution: The table's backing DDS data object is properly initialized with the table's values when a writer action is called.
OSPL-8507 | Transactions with explicit registration messages never become complete. When doing begin_coherent_changes then register an instance and finally call end_coherent_changes the total transaction could fail because the register_instance is not always sent. Solution: The defect in the transaction mechanism is solved and registration messages are not properly sent.
OSPL-8930 | The lease manager has to support leases which use the monotonic clock and leases which use the elapsed time clock. The lease manager is used to handle events that have to be processed at a certain time. For example the monitor the liveliness of the services the lease manager has to evaluate the corresponding leases at regular intervals. These leases are using the monotonic clock to support hibernation. However the lease manager is also used to monitor the liveliness of instances or when the deadline QoS is set to monitor if the deadline settings are satisfied. For these leases the elapsed time clock is used. Internally the lease manager used the monotonic clock. This may cause problems for leases which use the elapsed time clock when hibernation occurs. Solution: The defect in the transaction mechanism is solved and registration messages are not properly sent.
OSPL-9171 | A Condition detach from a Waitset can block. If a thread is waiting on a waitset and another thread detaches a condition from that waitset, the waitset is triggered after which the detach can take place. However, if the first thread is very quick (or the detaching thread is slow), it can happen that the first thread already enters the wait again while the detach didn't detect the trigger yet. When that happens, the detach will block (at least) until the waitset is triggered again. Solution: Wait for a detach to finish when entering a waitset wait.
OSPL-7980 | DDSI2 retransmits full sample on a retransmit request for the sample, even if the sample is huge The DDSI reliable protocol offers two different ways of requesting a retransmit of some data: a sample retransmit request and, for fragmented data (i.e., large samples), a fragment retransmit request. DDSI2 would always retransmit the full sample upon receiving a sample retransmit, even if that sample is huge, instead of retransmitting a "reasonable" amount and relying on further fragment retransmit requests. Solution: The DDSI2 service now retransmits a limited amount of data when receiving a retransmit request for a full sample.
OSPL-8017 | DDSI2 did not renew a participant lease for every received message The DDSI2 service discovers remote participants and automatically deletes them if they do not renew their leases in time. The lease renewal was tied to reception of data and of explicit lease renewal messages, and hence reception of, e.g., an acknowledgement would not lead to a lease renewal, even though it obviously requires the remote participant to be alive. Solution: DDSI2 now renews leases regardless of the type of message.
OSPL-8636 | Streams throughput example hang on windows When using the streams throughput example on windows the subscriber application could hang on termination. Solution: The defect is fixed and the subscriber will not hang anymore.
OSPL-8660 | RMI cpp does not reduce thread pool size immediately. The threadPoolSize of the RMI cpp ServerThreadingPolicy can be reduced. The threads within the threadpool are quit after they handled a request task when the number of threads are larger then the required threadPoolSize. Because the request tasks are handled before the number of threads are reduced, it is possible for the Server to get more parallel calls then expected. Solution: Quit a thread within the threadpool until the number of threads are equal to the threadPoolSize. Then continue handling the request tasks.
OSPL-8739 / 16698 | Too generic c_insert symbol The c_insert symbol is exported in one of the OpenSplice libraries. This is too generic and causes clashes with other software packages. Solution: The c_insert function has been renamed by prefixing it with the ospl_ prefix.
OSPL-8828 | Possible bufferoverflow when using Google Protocol Buffers on Windows When using Google Protocol Buffers on Windows with Isocpp it can happen that the application crashes with a buffer overflow. This is due to a defect in the translation from gpb to dds datatypes. Solution: The defect is fixed and the overflow will not occur anymore.
OSPL-9097 | DDSI transmit path can lock up on packet loss to one node while another node has crashed A successful retransmit to one remote reader while another remote reader that has not yet acknowledged all samples disappears (whether because of a loss of connectivity or a crash), and when all other remote readers have acknowledged all samples, and while the writer has reached the maximum amount of unacknowledged data would cause the transmit path in DDSI to lock up because the writer could then only be unblocked by the receipt of an acknowledgement message that covers a previously unacknowledged sample, which under these circumstances will not come because of the limit on the amount of unacknowledged data. Solution: deleting a reader now not only drops all unacknowledged data but also clears the retransmit indicator of the writer.
OSPL-9096 | Durability service DIED message even though the durability service is still running The d_status topic is published periodically by the durability service to inform its fellows of its status. By using a KEEP_ALL policy, the thread writing the status message and renewing the serivce lease could be blocked by a flow-control issue on the network, which could cause the durability service to be considered dead by the splice daemon when in fact there was no problem with the durability service. Solution: use a KEEP_LAST 1 history QoS policy for the writer.
OSPL-9067 | Large topics are sent published but not received Loss of the initial transmission of the final fragments of a large sample failed to cause retransmit requests for those fragments until new data was published by the same writer. Solution: ensure the receiving side will also request retransmission of those fragments based on heartbeats advertising the existence of the sample without giving specifics on the number of fragments.
OSPL-9077 / 00016820 | Potential crash in durability service during CATCHUP policy The durability service could crash while processing a CATCHUP event. This crash was caused by the garbage collector purging old instances while the CATCHUP policy was walking through the list of instances to do some bookkeeping. Solution: The CATCHUP policy now creates a private copy of the instance list while the garbage collector is unable to make a sweep. This private list is then used to do the bookkeeping.
OSPL-9068 / 00016813 | Catchup policy may leak away some instances When a node that performs a catchup to the master contains an instance that the master has already purged, then the node catching up would need to purge this instance as well. It would need to do this by re-registering the instance, inserting a dispose message and then unregistering this instance again. However, the unregister step was missing, causing the instance to effectively leak away since an instance is only purged by the durability service when it is both disposed AND unregistered. Solution: The durability will now both dispose AND unregister the instance at the same time.
OSPL-9081 / 00016824 | Potential deadlock in the OpenSplice kernel The OpenSplice kernel has a potential deadlock where two different code paths may claim locks in the opposite order. The deadlock occurs when one thread is reading/taking the data out of a DataReader while the participant's listener thread is processing the creation of a new group (i.e. a unique partition/topic combination) to which this Reader's Subscriber is also attached. Solution: The locking algorithm has been modified in such a way that the participant's listener thread no longer requires to hold both locks at the same time.
OSPL-9064 / 00016808 | Changes caused by OSPL-8914 in 6.6.3p4f4 have been reverted OSPL-8914 in the 6.6.3p4f4 release has made several changes to the durability service in order to solve problems where a rapid disconnect/reconnect cycle would leave the durability service in an undefined state. In these situations, a disconnect had not yet been fully processed when the reconnect occurs. However, the solutions provided in 6.6.4 caused other, previously non-existing errors during normal operation. Solution: All changes made as part of OSPL-8914 in the 6.6.4 release have been reverted. As an alternative solution to rapid disconnect/reconnect cycle issues, ddsi has offered temporary blacklisting of recently disconnected participants (see OSPL-8956).
OSPL-8956 | Temporary blacklisting of remote participants in DDSI2 The DDSI2 service now provides an option to temporarily block rediscovery of proxy participants. Blocking rediscovery gives the remaining processes on the node extra time to clean up. It is strongly advised that applications are written in such a way that they can handle reconnects at any time, but when issues are found, this feature can reduce the symptoms. Solution: A new setting in the DDSI section of the configuration has been added: Internal/RediscoveryBlacklistDuration along with an attribute Internal/RediscoveryBlacklistDuration [@enforce]. The former sets the duration (by default 10s), the second whether to really wait out the full period (true), or to allow reconnections once DDSI2 has internally completed cleaning up (false, the default). It strongly discouraged to set the duration to less than 1s.
OSPL-9071 | v_groupFlushAction passes a parameter that is not fully initialized. Valgrind reported that the v_groupFlushAction function passes a parameter that is not fully initialized. Although one of these parameters was evaluated in a subsequent function invocation, it never caused issues because the value was only used as an operand for a logical AND where the other operand was always FALSE. Solution: All attributes of the parameter in question are now explicitly initialized.
OSPL-9055 | Potential Sample drop during delivery to a local Reader In some cases, a dispose followed by an unregister does not result in NOT_ALIVE_DISPOSED state on a Reader residing on the same node as the Publisher. In those cases, the Reader has an end state set to NOT_ALIVE_NO_WRITERS, and reports that a sample has been Lost. Solution: We have no clue what could cause this behaviour, but added some logging to capture the context of the erroneous sample drop. This is just a temporary measure, and will be reverted when the root cause has been found and fixed.
OSPL-9056 | Potential deadlock during early abort of an application When an application aborts so quickly that the participant's leaseManager thread and its resendManager thread have not yet had the opportunity to get started, then the exit handler will block indefinitely waiting for these threads to exit the kernel. However, both threads are already blocked waiting to access a kernel that is already in lockdown. Solution: The constructor of the participant will not return before both the leaseManager and resendManager threads have entered the kernel successfully.
OSPL-8953 | Potential deadlock between reader creation and durability notification A thread that creates a new DataReader and a thread from the durability service that notifies a DataReader when it has completed its historical data alignment grab two of their locks in reverse order, causing a potential deadlock to occur. Solution: The locking algorithm has been modified so that these two threads do no longer grab both locks in reverse order.
OSPL-8886 | Durability failure to merge data after a short disconnect When the disconnection period is shorter than twice the heartbeat a durability service may not have been able to determine a new master before the node is reconnected again. In that case no master conflict is generated. In case the durability service is "late" in confirming a master it might even occur that the master has updated its namespace, but the namespace update is discarded because no confirmed master has been selected yet. As a consequence no request will for data will be sent to the master, and the durability service will not be aligned. Solution: In case a durability service receives a namespace update for a namespace for which no confirmed master is selected yet, the update is rescheduled for evaluation at a later time instead of discarding the update.
OSPL-8914 | Durability failure to merge data after a short disconnect When a node becomes disconnected it may loose its master. As a result the node will look for a new master. In doing so, the node would first unconfirm its current master and then wait for other fellows to propose a new master. The time to look for a new master is specified in the configuration file (DurabilityService.Network.Heartbeat.ExpiryTime). When the disconnection was shorter than the DurabilityService.Network.Heartbeat.ExpiryTime, no merge is triggered. Solution: whenever a node is discovered that is not simply starting and it has no confirmed master, a merge is triggered, just like when there are conflicting masters. NOTE: This change has been reverted in 6.6.3p4f7.
OSPL-8948 / 16755 OSPL-8987 | Race condition between durability data injection and garbage collecting of empty instances The durability service cached instance handles when injecting a historical data set in a way that could result in the historical samples being thrown away if the instance was empty and no known writers had registered it. Solution: the instance handle is no longer cached..
OSPL-8971 | Catchup policy may incorrectly mark unregistered instances as disposed. When an instance is unregistered on the master node during a disconnect from another node that has specified a CATCHUP policy with that master, then upon a reconnect that unregister message will still be delivered to that formerly disconnected node. However, the reconnected node will dispose all instances for which it did not receive any valid data, so if the unregister message it the only message received for a particular instance, then its instance will be disposed. Solution:The Catchup policy is now instructed to dispose instances for which it did not receive any valid data OR for which it did not receive any unregister message.
OSPL-8984 | DDSI handling of non-responsive readers needs improvement When a writer is blocked for ResponsiveTimeout seconds, DDSI will declare the matching proxy readers that have not yet acknowledged all data "non-responsive" and continue with those readers downgraded to best-effort. This prevents blocking outgoing traffic indefinitely, but at the cost of breaking reliability. For historical reasons it was set to 1s to limit the damage a non-responsive reader could cause, but past improvements to the handling of built-in data in combination with DDSI (such as fully relying on DDSI discovery for deriving built-in topics) mean there is no longer a need to have such an aggressive setting by default. Solution: The default behaviour has been changed to never declare a reader non-responsive and maintain reliability also when a remote reader is not able to make progress. The changes also eliminate some spurious warning and error messages in the log files that could occur with a longer timeout.
OSPL-8920 | DDSI2 Crash Version 6.6.3p4 introduced a fix for OSPL-8872, taking the sequence number most recently transmitted by a writer when it matched reader into account to force heartbeats out until all historical data has been acknowledged by the reader. The change also allowed a flag forcing the transmission of heartbeats informing readers of the availability of data to be set earlier than before in the case where the writer had not published anything yet at the time the reader was discovered. While logically correct, this broke the determination of the unique reader that had not yet acknowledged all data in cases where there is such a unique reader. This in turn could lead to a crash. Solution: the aforementioned flag is once again never set before a sample has been acknowledged.

## 6.6.4p2

Report ID. | Description
--- | ---
OSPL-8425 / 16551 | When a lot of fragmented, best effort data is received, the receiver will run out of buffer space Defragmentation buffers is shared with the receive buffer. In case a lot of data is received, the networkstack isn't able to free claimed buffer space as it doesn't get to time to defragmentate data in the buffers. As a result, incoming data can not be stored and networking can't recover from this situation as these buffers remain locked. Solution: In case no buffers can be freed, drop data in buffers to create free space to be able to receive new data and continue to function. Data in the dropped buffers are lost but as this is best-effort data, this is allowed.
OSPL-8886 | Durability failure to merge data after a short disconnect When the disconnection period is shorter than twice the heartbeat a durability service may not have been able to determine a new master before the node is reconnected again. In that case no master conflict is generated. In case the durability service is "late" in confirming a master it might even occur that the master has updated its namespace, but the namespace update is discarded because no confirmed master has been selected yet. As a consequence no request will for data will be sent to the master, and the durability service will not be aligned. Solution: In case a durability service receives a namespace update for a namespace for which no confirmed master is selected yet, the update is rescheduled for evaluation at a later time instead of discarding the update.
OSPL-8914 | Durability failure to merge data after a short disconnect When a node becomes disconnected it may loose its master. As a result the node will look for a new master. In doing so, the node would first unconfirm its current master and then wait for other fellows to propose a new master. The time to look for a new master is specified in the configuration file (DurabilityService.Network.Heartbeat.ExpiryTime). When the disconnection was shorter than the DurabilityService.Network.Heartbeat.ExpiryTime, no merge is triggered. Solution: whenever a node is discovered that is not simply starting and it has no confirmed master, a merge is triggered, just like when there are conflicting masters. NOTE: This change has been reverted in 6.6.3p4f7.
OSPL-8920 | DDSI2 Crash Version 6.6.3p4 introduced a fix for OSPL-8872, taking the sequence number most recently transmitted by a writer when it matched reader into account to force heartbeats out until all historical data has been acknowledged by the reader. The change also allowed a flag forcing the transmission of heartbeats informing readers of the availability of data to be set earlier than before in the case where the writer had not published anything yet at the time the reader was discovered. While logically correct, this broke the determination of the unique reader that had not yet acknowledged all data in cases where there is such a unique reader. This in turn could lead to a crash. Solution: the aforementioned flag is once again never set before a sample has been acknowledged.
OSPL-8928 | Improve FACE documentation FACE documentation is very rudimentary. Solution: Getting started, API documentation, configuration documentation and example have been added.
OSPL-8948 / 16755 OSPL-8987 | Race condition between durability data injection and garbage collecting of empty instances The durability service cached instance handles when injecting a historical data set in a way that could result in the historical samples being thrown away if the instance was empty and no known writers had registered it. Solution: the instance handle is no longer cached..
OSPL-8953 | Potential deadlock between reader creation and durability notification A thread that creates a new DataReader and a thread from the durability service that notifies a DataReader when it has completed its historical data alignment grab two of their locks in reverse order, causing a potential deadlock to occur. Solution: The locking algorithm has been modified so that these two threads do no longer grab both locks in reverse order.
OSPL-8956 | Temporary blacklisting of remote participants in DDSI2 The DDSI2 service now provides an option to temporarily block rediscovery of proxy participants. Blocking rediscovery gives the remaining processes on the node extra time to clean up. It is strongly advised that applications are written in such a way that they can handle reconnects at any time, but when issues are found, this feature can reduce the symptoms. Solution: A new setting in the DDSI section of the configuration has been added: Internal/RediscoveryBlacklistDuration along with an attribute Internal/RediscoveryBlacklistDuration [@enforce]. The former sets the duration (by default 10s), the second whether to really wait out the full period (true), or to allow reconnections once DDSI2 has internally completed cleaning up (false, the default). It strongly discouraged to set the duration to less than 1s.
OSPL-8971 | Catchup policy may incorrectly mark unregistered instances as disposed. When an instance is unregistered on the master node during a disconnect from another node that has specified a CATCHUP policy with that master, then upon a reconnect that unregister message will still be delivered to that formerly disconnected node. However, the reconnected node will dispose all instances for which it did not receive any valid data, so if the unregister message it the only message received for a particular instance, then its instance will be disposed. Solution:The Catchup policy is now instructed to dispose instances for which it did not receive any valid data OR for which it did not receive any unregister message.
OSPL-8984 | DDSI handling of non-responsive readers needs improvement When a writer is blocked for ResponsiveTimeout seconds, DDSI will declare the matching proxy readers that have not yet acknowledged all data "non-responsive" and continue with those readers downgraded to best-effort. This prevents blocking outgoing traffic indefinitely, but at the cost of breaking reliability. For historical reasons it was set to 1s to limit the damage a non-responsive reader could cause, but past improvements to the handling of built-in data in combination with DDSI (such as fully relying on DDSI discovery for deriving built-in topics) mean there is no longer a need to have such an aggressive setting by default. Solution: The default behaviour has been changed to never declare a reader non-responsive and maintain reliability also when a remote reader is not able to make progress. The changes also eliminate some spurious warning and error messages in the log files that could occur with a longer timeout.
OSPL-9027 | idlpp is not robust to paths with whitespace The idlpp tool is not able to handle paths that contain whitespaces when compiling for cpp and thus using cppgen. Solution: Add quotes to the arguments for cppgen, which are generated by idlpp.
OSPL-9028 | Bug in serializing messages with sequences of 64 bit The SAC generic copy routines have an issue with alignment and empty sequences. Additionally, the legacy CDR serialiser (the only one up to but not including 6.4.1) has this issue because it always inserts padding for sequences of primitive and enumerated types even when the sequence is empty. Solution:The SAC copy routines have been modified to be able to deal with empty sequences. Even though the new CDR serialiser (since 6.4.1) does not have this issue and versions from 6.4.1 onward are not affected, the old code is still a compile-time option in the current versions for development purposes and so that one is fixed, too.
OSPL-9055 | Potential Sample drop during delivery to a local Reader In some cases, a dispose followed by an unregister does not result in NOT_ALIVE_DISPOSED state on a Reader residing on the same node as the Publisher. In those cases, the Reader has an end state set to NOT_ALIVE_NO_WRITERS, and reports that a sample has been Lost. Solution: We have no clue what could cause this behaviour, but added some logging to capture the context of the erroneous sample drop. This is just a temporary measure, and will be reverted when the root cause has been found and fixed.
OSPL-9056 | Potential deadlock during early abort of an application When an application aborts so quickly that the participant's leaseManager thread and its resendManager thread have not yet had the opportunity to get started, then the exit handler will block indefinitely waiting for these threads to exit the kernel. However, both threads are already blocked waiting to access a kernel that is already in lockdown. Solution: The constructor of the participant will not return before both the leaseManager and resendManager threads have entered the kernel successfully.
OSPL-9058 / 16796 OSPL-9206 / 16852 | Incompatibility with versions before V6.5.0p5 An internal change to builtin heartbeat topic caused an incompatibility with older versions. When adding a node running a recent version of OpenSplice to a domain with nodes running a version before V6.5.0p5, the existing nodes would incorrectly dispose participants (and corresponding entities) belonging to the new nodes after a single heartbeat period, normally done only when a heartbeat expires. Solution: To resolve this, the change to the heartbeat topic was reverted.
OSPL-9064 / 16808 | Changes caused by OSPL-8914 in 6.6.3p4f4 have been reverted OSPL-8914 in the 6.6.3p4f4 release has made several changes to the durability service in order to solve problems where a rapid disconnect/reconnect cycle would leave the durability service in an undefined state. In these situations, a disconnect had not yet been fully processed when the reconnect occurs. However, the solutions provided in 6.6.4 caused other, previously non-existing errors during normal operation. Solution: All changes made as part of OSPL-8914 in the 6.6.4 release have been reverted. As an alternative solution to rapid disconnect/reconnect cycle issues, ddsi has offered temporary blacklisting of recently disconnected participants (see OSPL-8956).
OSPL-9067 | Large topics are sent published but not received Loss of the initial transmission of the final fragments of a large sample failed to cause retransmit requests for those fragments until new data was published by the same writer. Solution: ensure the receiving side will also request retransmission of those fragments based on heartbeats advertising the existence of the sample without giving specifics on the number of fragments.
OSPL-9068 / 00016813 | Catchup policy may leak away some instances When a node that performs a catchup to the master contains an instance that the master has already purged, then the node catching up would need to purge this instance as well. It would need to do this by re-registering the instance, inserting a dispose message and then unregistering this instance again. However, the unregister step was missing, causing the instance to effectively leak away since an instance is only purged by the durability service when it is both disposed AND unregistered. Solution: The durability will now both dispose AND unregister the instance at the same time.
OSPL-9071 | v_groupFlushAction passes a parameter that is not fully initialized. Valgrind reported that the v_groupFlushAction function passes a parameter that is not fully initialized. Although one of these parameters was evaluated in a subsequent function invocation, it never caused issues because the value was only used as an operand for a logical AND where the other operand was always FALSE. Solution: All attributes of the parameter in question are now explicitly initialized.
OSPL-9077 / 00016820 | Potential crash in durability service during CATCHUP policy The durability service could crash while processing a CATCHUP event. This crash was caused by the garbage collector purging old instances while the CATCHUP policy was walking through the list of instances to do some bookkeeping. Solution: The CATCHUP policy now creates a private copy of the instance list while the garbage collector is unable to make a sweep. This private list is then used to do the bookkeeping.
OSPL-9081 / 00016824 | Potential deadlock in the OpenSplice kernel The OpenSplice kernel has a potential deadlock where two different code paths may claim locks in the opposite order. The deadlock occurs when one thread is reading/taking the data out of a DataReader while the participant's listener thread is processing the creation of a new group (i.e. a unique partition/topic combination) to which this Reader's Subscriber is also attached. Solution: The locking algorithm has been modified in such a way that the participant's listener thread no longer requires to hold both locks at the same time.
OSPL-9096 | Durability service DIED message even though the durability service is still running The d_status topic is published periodically by the durability service to inform its fellows of its status. By using a KEEP_ALL policy, the thread writing the status message and renewing the serivce lease could be blocked by a flow-control issue on the network, which could cause the durability service to be considered dead by the splice daemon when in fact there was no problem with the durability service. Solution: use a KEEP_LAST 1 history QoS policy for the writer.
OSPL-9097 | DDSI transmit path can lock up on packet loss to one node while another node has crashed A successful retransmit to one remote reader while another remote reader that has not yet acknowledged all samples disappears (whether because of a loss of connectivity or a crash), and when all other remote readers have acknowledged all samples, and while the writer has reached the maximum amount of unacknowledged data would cause the transmit path in DDSI to lock up because the writer could then only be unblocked by the receipt of an acknowledgement message that covers a previously unacknowledged sample, which under these circumstances will not come because of the limit on the amount of unacknowledged data. Solution: deleting a reader now not only drops all unacknowledged data but also clears the retransmit indicator of the writer.
OSPL-9388 / 17030 | Durability service might deadlock when the networking queue is flooded. When the network queue is overrun by the durability service, the normal mode of operation is to sleep a bit and retry again later. However, there is a slight chance that the sending thread of the network service that needs to make room again by consuming elements in the queue will indirectly block on the sleeping thread in the durability service itself. Solution: The network service can no longer indirectly run into a lock that is held by the durability service while the network queue is flooded.

## 6.6.4p1

Report ID. | Description
--- | ---
OSPL-9016 | Changes caused by OSPL-8914 in 6.6.4 have been reverted OSPL-8914 in the 6.6.4 release has made several changes to the durability service in order to solve problems where a rapid disconnect/reconnect cycle would leave the durability service in an undefined state. In these situations, a disconnect had not yet been fully processed when the reconnect occurs. However, the solutions provided in 6.6.4 caused other, previously non-existing errors during normal operation. Solution: All changes made as part of OSPL-8914 in the 6.6.4 release have been reverted. As an alternative solution to rapid disconnect/reconnect cycle issues, ddsi has offered temporary blacklisting of recently disconnected participants (see OSPL-8956).

## 6.6.4

Report ID. | Description
--- | ---
OSPL-8953 | Potential deadlock between reader creation and durability notification A thread that creates a new DataReader and a thread from the durability service that notifies a DataReader when it has completed its historical data alignment grab two of their locks in reverse order, causing a potential deadlock to occur. Solution: The locking algorithm has been modified so that these two threads do no longer grab both locks in reverse order.
OSPL-8636 | Streams throughput example hang on windows When using the streams throughput example on windows the subscriber application could hang on termination. Solution: The defect is fixed and the subscriber will not hang anymore.
OSPL-8886 | Durability failure to merge data after a short disconnect When the disconnection period is shorter than twice the heartbeat a durability service may not have been able to determine a new master before the node is reconnected again. In that case no master conflict is generated. In case the durability service is "late" in confirming a master it might even occur that the master has updated its namespace, but the namespace update is discarded because no confirmed master has been selected yet. As a consequence no request will for data will be sent to the master, and the durability service will not be aligned. Solution: In case a durability service receives a namespace update for a namespace for which no confirmed master is selected yet, the update is rescheduled for evaluation at a later time instead of discarding the update.
OSPL-8914 | Durability failure to merge data after a short disconnect When a node becomes disconnected it may loose its master. As a result the node will look for a new master. In doing so, the node would first unconfirm its current master and then wait for other fellows to propose a new master. The time to look for a new master is specified in the configuration file (DurabilityService.Network.Heartbeat.ExpiryTime). When the disconnection was shorter than the DurabilityService.Network.Heartbeat.ExpiryTime, no merge is triggered. Solution: whenever a node is discovered that is not simply starting and it has no confirmed master, a merge is triggered, just like when there are conflicting masters. NOTE: This change has been reverted in 6.6.4p1 because it may break other durability functionality.
OSPL-8920 | DDSI2 Crash Version 6.6.3p4 introduced a fix for OSPL-8872, taking the sequence number most recently transmitted by a writer when it matched reader into account to force heartbeats out until all historical data has been acknowledged by the reader. The change also allowed a flag forcing the transmission of heartbeats informing readers of the availability of data to be set earlier than before in the case where the writer had not published anything yet at the time the reader was discovered. While logically correct, this broke the determination of the unique reader that had not yet acknowledged all data in cases where there is such a unique reader. This in turn could lead to a crash. Solution: the aforementioned flag is once again never set before a sample has been acknowledged.
OSPL-8948 / 16755 OSPL-8987 | Race condition between durability data injection and garbage collecting of empty instances The durability service cached instance handles when injecting a historical data set in a way that could result in the historical samples being thrown away if the instance was empty and no known writers had registered it. Solution: the instance handle is no longer cached..
OSPL-8956 | Temporary blacklisting of remote participants in DDSI2 The DDSI2 service now provides an option to temporarily block rediscovery of proxy participants. Blocking rediscovery gives the remaining processes on the node extra time to clean up. It is strongly advised that applications are written in such a way that they can handle reconnects at any time, but when issues are found, this feature can reduce the symptoms. Solution: A new setting in the DDSI section of the configuration has been added: Internal/RediscoveryBlacklistDuration along with an attribute Internal/RediscoveryBlacklistDuration [@enforce]. The former sets the duration (by default 10s), the second whether to really wait out the full period (true), or to allow reconnections once DDSI2 has internally completed cleaning up (false, the default). It strongly discouraged to set the duration to less than 1s.
OSPL-8957 | Unnecessary heartbeat/acknowledgement traffic in DDSI with late joiners for transient-local data In DDSI, reliable writers send heartbeats to inform their readers of the existence of unacknowledged data, and keep doing so until the readers have acknowledged everything. The heartbeats indicate the range of sequence numbers available. The highest sequence number advertised in the heartbeat was the highest sequence number available for retransmit, leaving out any subsequent sequence numbers that are no longer available for retransmit. If a transient-local writer unregistered an instance and then became quiescent, it would be advertising a sequence number less than the latest sequence number it published, and this would lead to a late-joining reader never acknowledging all data up to this latest sequence number. As a result, the writer would keep sending heartbeats and the readers would keep acknowledging it. Sending new samples from the writer would break the cycle. Solution: the writer now advertises the latest sequence number it published. If there is a gap between the latest available for retransmit and the latest published, the reader will be informed that these sequence numbers are no longer relevant using a standard message.
OSPL-8958 | DDSI can regurgitate old T-L samples for instances that have already been unregistered DDSI maintains a writer history cache for providing historical data for transient-local writers and for providing reliability. An instance is removed from this cache when it is unregistered by the writer, but its samples are retained until they have been acknowledged by all (reliable) readers. Already acknolwedged samples that were retained because they were historical data could survive even when the instance was removed. When this happened, a late-joining reader would see some old samples reappear. Solution: deleting an instance now also removes the already acknowledged samples from the history.
OSPL-8971 | Catchup policy may incorrectly mark unregistered instances as disposed. When an instance is unregistered on the master node during a disconnect from another node that has specified a CATCHUP policy with that master, then upon a reconnect that unregister message will still be delivered to that formerly disconnected node. However, the reconnected node will dispose all instances for which it did not receive any valid data, so if the unregister message it the only message received for a particular instance, then its instance will be disposed. Solution:The Catchup policy is now instructed to dispose instances for which it did not receive any valid data OR for which it did not receive any unregister message.
OSPL-8972 | Durability fellow state may be incorrect A durability service keeps track of the state of each fellow it knows. In every message that fellow sends to a durability service the state of the fellow is included. The recipient has different threads to handle incoming messages. In rare cases, these messages are processed in the reverse order, thus ending up with a wrong conclusion about the fellow's state. Solution: The durability service now uses the source timestamp in incoming messages to determine the order in which they have been written to ensure it never updates the internal state using 'old' information.
OSPL-8973 | Additional durability tracing when verbosity is set to FINEST Durability has been extended with additional tracing in the processing of namespace definitions received from fellows, in particular when checking for master conflicts.
OSPL-8974 | Durability conflict scheduling fails when multiple namespaces have the same policy and differ only in topic names Durability checks for conflicts between fellows (master, native and foreign state) that may require merging data whenever it receives a "d_nameSpaces" instance. If a conflict is detected, it enqueues it for eventual resolution, but only if an equivalent conflict is not yet enqueued. Testing for equivalency is done by checking: conflict kind, roles and local and fellow namespaces. However, the name space compare function (d_nameSpaceCompare) did not take the name into account, nor the full partition+topic expressions. The consequence is that when namespaces A and B have identical policies and differ only in the topic parts of the partition/topic expressions, a conflict for namespace A would be considered the same as a conflict for namespace B. The result would be a failure to merge data in B. Solution: The comparison now takes the name of the namespace into account. The configuration is required to have no overlap between namespaces and to have compatible namespace definitions throughout the system. The name alone is therefore sufficient.
OSPL-8979 | DDSI incapable of receiving multicasts after restart in single-process mode The tracking of joined multicast groups DDSI could not handle the case where DDSI would be restarted in single-process mode (e.g., by creating a participant, deleting it, and creating another one), potentially causing the new sockets not to join the multicast groups. Solution: DDSI now explicitly leaves all multicast groups on termination.
OSPL-8980 | With DDSI remote participants expire independently on cable disconnect The DDSI protocol has lease expiry tied to participants and the DDSI service faithfully implemented this. This means that a cable disconnect occurs caused the leases of the various participants on the remote node to expire independently, and therefore also the automatic disposing and unregistering of data. A short disconnection where the lease of the durability service never expired, but where the lease of some application process did expire could lead to an inconsistent state of the data space, if that application published auto-disposed transient data. Solution: DDSI has been modified to implement only a single lease per remote federation for OpenSplice peers by internally tying the leases of the applications to the lease of the remote DDSI service.
OSPL-8984 | DDSI handling of non-responsive readers needs improvement When a writer is blocked for ResponsiveTimeout seconds, DDSI will declare the matching proxy readers that have not yet acknowledged all data "non-responsive" and continue with those readers downgraded to best-effort. This prevents blocking outgoing traffic indefinitely, but at the cost of breaking reliability. For historical reasons it was set to 1s to limit the damage a non-responsive reader could cause, but past improvements to the handling of built-in data in combination with DDSI (such as fully relying on DDSI discovery for deriving built-in topics) mean there is no longer a need to have such an aggressive setting by default. Solution: The default behaviour has been changed to never declare a reader non-responsive and maintain reliability also when a remote reader is not able to make progress. The changes also eliminate some spurious warning and error messages in the log files that could occur with a longer timeout.
OSPL-8989 | Non-atomic dispose+unregister operation on DCPSHeartbeat A race condition between auto-disposing/unregistering, taking data from a data reader and merging of historical data was resolved in OSPL-8684 by performing the an atomic dispose+unregister operation instead of two separate operations. This fix covered all cases except the DCPSHeartbeat built-in topic, which is handled specially by the splice daemon and still performed two independent operations. Solution: The atomic dispose+unregister is now also used for DCPSHeartbeat. There are no user-visible consequences of this change.
TSTTOOL-395 | Python scripting examples need to be updated to reflect the ability to create and specify QoS settings on entities. the example now shows: reading and writing to non-default partition use a waitset to poll some data pass some user data through one of the QoS use a check to show that a reader and a writer don't match on QoS

## 6.6.3p5

Report ID. | Description
--- | ---
OSPL-8920 | DDSI2 Crash Version 6.6.3p4 introduced a fix for OSPL-8872, taking the sequence number most recently transmitted by a writer when it matched reader into account to force heartbeats out until all historical data has been acknowledged by the reader. The change also allowed a flag forcing the transmission of heartbeats informing readers of the availability of data to be set earlier than before in the case where the writer had not published anything yet at the time the reader was discovered. While logically correct, this broke the determination of the unique reader that had not yet acknowledged all data in cases where there is such a unique reader. This in turn could lead to a crash. Solution: the aforementioned flag is once again never set before a sample has been acknowledged.
OSPL-8914 | Durability failure to merge data after a short disconnect When a node becomes disconnected it may loose its master. As a result the node will look for a new master. In doing so, the node would first unconfirm its current master and then wait for other fellows to propose a new master. The time to look for a new master is specified in the configuration file (DurabilityService.Network.Heartbeat.ExpiryTime). When the disconnection was shorter than the DurabilityService.Network.Heartbeat.ExpiryTime, no merge is triggered. Solution: whenever a node is discovered that is not simply starting and it has no confirmed master, a merge is triggered, just like when there are conflicting masters.
OSPL-8886 | Durability failure to merge data after a short disconnect When the disconnection period is shorter than twice the heartbeat a durability service may not have been able to determine a new master before the node is reconnected again. In that case no master conflict is generated. In case the durability service is "late" in confirming a master it might even occur that the master has updated its namespace, but the namespace update is discarded because no confirmed master has been selected yet. As a consequence no request will for data will be sent to the master, and the durability service will not be aligned. Solution: In case a durability service receives a namespace update for a namespace for which no confirmed master is selected yet, the update is rescheduled for evaluation at a later time instead of discarding the update.

## 6.6.3p4

Report ID. | Description
--- | ---
OSPL-8884 | Spliced assertion failure (_this->state & L_UNREGISTER) in v_registrationMessageCompare The record of a writer unregistering an instance is retained for a little before it is completely removed from the system. In the case of spliced and DCPSHeartbeat, if in this window the spliced needed to auto-dispose the DCPSHeartbeat, it could resurrect the registration but leave it in an inconsistent state, resulting in this assertion failure. Solution: DDSI now correctly tags the "unregister" events.
OSPL-8825 / 00016727 OSPL-8722 / 00016668 | Invalid timing during replay with non-default speed by Record and Replay service A regression caused by a previous fix caused the Record and Replay service to not compensate for a non-default replay speed in certain circumstances during replay. Solution: The issue was resolved by making some adjustments in the replay timing algorithm so the replay-speed is always factored in.
OSPL-8684 / 00016645 | Instances that were NOT_ALIVE due to a disconnect do not always become ALIVE after a reconnect When a disconnect occurs, all instances owned by the disconnected Writers should become NOT_ALIVE_DISPOSED (in case a disconnected Writer had its auto_dispose_unregistered_instances set to TRUE) or NOT_ALIVE_NO_WRITERS. However, when the disconnected node reconnects, and the topic is non-VOLATILE, you might expect the instances to go back to the ALIVE state. However, that did not happen in all scenarios. Solution: If the NOT_ALIVE instances are taken by the DataReader, they will now instantly be purged. When merge policies are configured to re-insert the missing messages back into the DataRerader after the connection is re-established, then these re-inserted samples will cause the instance to be re-created starting in the NEW, NOT_READ, ALIVE state. Note however, if the NOT_ALIVE samples are not taken out at the time of the disconnection, their instances will not be purged, and the re-inserted samples will be discarded as being duplicates of samples that are already there. In those cases the instance state will still not be changed back to ALIVE.
OSPL-8857 / 00016738 | Unable to start OpenSplice Tuner on Windows An incomplete classpath in the manifest of ospltun.jar causes a ClassDefNotFound exception when starting the Tuner. Solution: The issue was resolved by fixing the classpath handling in manifest file generation.
OSPL-8872 | DDSI transient local data retrieval may block indefinitely when packet loss occurs halfway through a fragmented sample if the writer is quiescent When the DDSI service is retrieving historical transient-local data from a remote writer (this includes DDSI discovery data), it depends on a constant back-and-forth between requests for retransmits (NACKs) and heartbeats from the writer that allow it to send NACKs. The writer adapts its heartbeat rate based on the state of the readers it surmises from the ACKs/NACKs it receives. On receipt of an ACK it concludes the reader must have received all data (otherwise it should have NACKed the missing samples), which may result in no more heartbeats going out. Requesting a retransmit of individual sample fragments is done using a message different from the standard NACK message. If a reader has received part of a fragmented sample, it will send such an alternative NACK for the missing fragments while sending an ACK for everything up to that point. This ACK caused the writer to incorrectly conclude the reader had received everything. Writing a single new sample would cause the back-and-forth to restart and continue until all data had been transferred. Discovery of a new reader would temporarily trigger heartbeats as well, restarting the sequence, but in a state that further packet loss could cause it to stop again. Solution: the writer requires that the ACK concerns a high enough sequence number before concluding it need not send any more heartbeats.
OSPL-8847 | When coherent transactions containing topics with strings as key are being aligned, the receiving durability service could crash Durability services are used to align historical data. In case coherent transactions exist, special messages called End-Of_transactions (EOT) are aligned to indicate which parts of the transaction is completed. If topics are aligned that have a string as key and that belong to a transaction, then the receiving durability service could crash because it tries to access unallocated memory. Solution: The code that was responsible for the illegal memory access is fixed.
OSPL-8803 | Durability tracing logs do not mention the OpenSplice version number The durability tracing log generated by the OpenSplice durability service (when tracing is enabled) does not mention the OpenSplice version number. Solution: The OpenSplice version number is now added to the durability tracing log.
OSPL-8819 | Memory rise with transient local data using DDSI When using transient local data in combination with DDSI, DDSI starts to allocate memory and never frees it. Solution: When using transient local, DDSI did not request the receiver site to acknowledge the sent data, but still kept it in a list, allocation more and more memory for each message sent. DDSI has been changed to request acknowledgment when using transient-local data.
OSPL-8771 / 00016706 | Memory leak after deleting a transient reader A reference counting error in determining whether a reader is entitled to transient data caused part of the data reader administration to be retained after deleting the data reader. Solution: The stray reference is now released.
OSPL-7244 | Tuner does not support writing samples containing multi-dimensional collections The Tuner tool does not support editing multi-dimensional sequences (in IDL, sequence<sequence<some_type>>, or some_type[x][y] ). When editing such data fields in the Tuner writer table, the fields will be uneditable. This also affects editing Google Protocol Buffer samples that contain a field defined as repeated bytes, as that is represented as a sequence of a sequence of octets in the data model. Solution: Support for editing certain multidimensional collections has been added, specifically editing of two dimensional unbounded sequences of primitives, such that the Google Protocol Buffer type "repeated bytes" is able to be edited. Other more complex types such as N-dimensional bounded/unbounded sequences or arrays of primitives or of structs are still not editable.
OSPL-8804 / 00016720 | Late joining DataReader receives 1 sample per DataReaderInstance per unfinished transaction at maximum When a transaction on a transient topic contains more than 1 samples per instance, and the transaction is not yet finished at the time a late joining Volatile Reader requests historical data, then the reader will receive only the first sample for each ReaderInstance in that transaction, regardless of the Reader's history depth. Solution:The Volatile Reader will now receive all samples of the unfinished transaction.

## 6.6.3p3

Report ID. | Description
--- | ---
OSPL-6961 | Cause of an unregister not correctly tracked when a DDSI lease expires There are two reasons why an "unregister" of an instance can take place: the first, most common one, is that a writer explicitly calls unregister_instance, or that it automatically happens when the writer is deleted; the second one is when a remote writer suddenly disappears and the other nodes have to synthesize one. The two are indistinguishable to applications, but the way the must be treated for transient data following a reconnect is different. DDSI did not properly distinguish between the two cases. Solution: DDSI now correctly tags the "unregister" events.
OSPL-8563 | OS_INFO payloads from Node Info samples contain invalid XML character on Windows 10 64bit, Java 8 When publishing OS_INFO information using NodeMonitor on Windows 10 in conjunction with Java 8, a form feed XML character is supplied by the underlying Sigar library, which cannot be processed by Vortex OpenSplice and throws the following exception:[error] o.o.a.c.t.xml - SAXException: Character reference " " is an invalid XML character. Solution:The NodeMonitor implementation now strips out the invalid XML form feed character for the OS_INFO description before publishing the data.
OSPL-8585 | Display the Topic Type definition wherever a GPB evolution can be selected Tuner does not support selecting a protobuf type evolution yet when writing/reading. Solution: Tuner's support for Google protocol buffers has been updated with the ability to directly view the type definition of the selected type evolution when choosing a type evolution to read/write data as.
OSPL-8666 / 16651 | Reading with QueryConditions could yield samples that shouldn't be read based on the masks provided. For instance, when an QueryCondition has the mask NOT_READ_SAMPLE_STATE, only samples with that state should be returned when reading or taking with that condition. However, the query implementation did not include testing the masks for trigger values. This means that when using a triggered QueryCondition with the NOT_READ_SAMPLE_STATE, you'd be able to read samples with the READ_SAMPLE_STATE. This was also applicable for the view state and instance state. Solution: Add masks checks for triggered QueryConditions.
OSPL-8691 | DDSI not properly retransmitting end-of-transaction messages. When using coherent updates, an end-of-transaction message is used to notify the subscribers that the set is now complete and may be committed. These messages may get lost and hence may need to be retransmitted, just like ordinary samples. The retransmit path of DDSI however failed to handle these correctly. In consequence, the subscribing side would automatically reconstruct an end-of-transaction message at a later stage, one that is sufficient for guaranteeing topic-level coherence, but not for group-level coherence. Solution: DDSI has been updated to properly retransmit end-of-transaction messages when required.
OSPL-8708 | Tuner cannot acquire key list for protobuf topics whose type contains a oneof. If the user creates a reader or writer frame for a topic whose type is a protobuf type containing a oneof declaration, the reader or writer frame will show a warning in the status bar that the key list could not be obtained. Consequently, the user data table would not have any highlighting for key or protobuf required fields. Solution: The underlying API that acquires protobuf specific properties for user data field (such as the required flag or default values) did not properly account for the switch field, which is an invented field for the mapping of oneof to union for representation in existing tooling data models. The tooling protobuf API was fixed to account for this switch field.
OSPL-8710 / 16663 | Issue with java waitset during termination of domain. When a java application is blocking on a waitset _wait() call, while at the same time OpenSplice is stopping, the application may run into an ArrayIndexOutOfBoundsException. All conditions in the waitset are supposed to trigger because they are detached from the domain, but the java binding does not properly resize the ConditionSeqHolder array supplied by the application, to contain all conditions. Solution: To resolve the issue a check on the array size was added, resizing if required.
OSPL-8724 | A crash could occur when the system terminates while there are pending events to process. Events are handled asynchronously. In the exceptional case where the system terminates while there are pending events, these events must be cleaned up. A bug could cause that an unmanaged piece of memory is accessed, which potentially causes a crash. Solution: When the system terminates while there are pending events, these events are now being cleaned up correctly.
OSPL-8728 | Unknown object kind error log when using isocpp2 listener. When using the isocpp2 API with listeners an Unknown object kind error log shows up when listening for the DATA_AVAILABLE status event. Solution: The isocpp2 listener mechanism is fixed and the error will not show anymore when using DATA_AVAILABLE status.
OSPL-8736 | Registering the same type twice in c sharp raises bad parameter. There was a code path in the C# API in which registering a type that was already known did not set the correct return value, causing a successful call to raise an exception. Solution: Added handling of the result code and return OK when all went well.
OSPL-8737 | Lag during replay by Record and Replay service. TWhen a reasonable load is placed on the RnR service, i.e. by replaying a storage with many samples recorded at a high frequency from different topics and/or writers, the service may not be able to keep up with the exact original 'recorded' timing and a sample is replayed with a delay. The delays of individual samples add up, resulting in a noticeable delay sooner or later, as the replay carries on. Solution: The replay timing has been improved to compensate for delays on individual samples, catching up lost time so the replay in general doesn't lag behind.
OSPL-8738 | Lease handling in the DDSI service is sensitive to time jumps. The DDSI service's handling of the leases of remote participants was still based on the wall clock time, and therefore a forward jump of the wall clock by more than a few seconds could cause lease expiry, and hence disconnections. Similarly, a backward jump of the wall clock time could delay lease expiry. Solution: The lease handling is now based on a monotonic clock that counts time elapsed since an arbitrary reference in the past.

## 6.6.3p2

Report ID. | Description
--- | ---
OSPL-7245 | Enable highlighting of required fields in GPB user data. Google Protocol Buffer samples in Tuner do not highlight so-called required attributes. This makes it difficult to see what needs to be edited before samples can be written. Solution: The Vortex OpenSplice Tuner UI has been updated to distinguish between key, required and optional fields for Google Protocol Buffer samples. Required user data fields in sample tables are highlighted with the cyan colour in the same fashion as in Vortex OpenSplice Tester.
OSPL-7392 OSPL-8450 | The durability service does not properly align open coherent transactions. As soon as a durability service joins an existing system it will retrieve all non-volatile historical data that is available within the system by requesting this data from an available durability service (the master). The master durability service should provide the historical data to the newly joined durability service (this is called alignment). Unfortunately, the master durability service did not align the non-volatile historical data that belongs to a coherent transactions that is not committed (finished) yet. In particular, the following problems were identified: historical data that is not committed yet was not aligned, only committed data was aligned end-of-transactions markers that are used to decide about completeness of a transaction were not aligned. As a consequence alignment of open transactions fails, and the late joining durability service may end up in an inconsistent state. Solution: Data that is part of a non-finished coherent transaction is now being aligned, just as the end-of-transaction markers. This allows the late joining durability service to reconstruct the same state as the master, and consequently completeness of transactions is handled correctly in various disconnect scenarios.
OSPL-8102 | Minimal configured database size required If a database size is configured below the minimal database size Opensplice will not start and stop with out of memory problems. Solution: If the configured database size is below the minimal required size, it will be increased to the minimal required size and a warning trace will be logged. Minimal database size for 32-bit builds is 2 MB and for 64-bit builds it is 5 MB. The default memory threshold size for free memory will be 10% of the configured database size if the configured database size is less than the default 10MB.
OSPL-8490 / 16602 | Compatibility issues with dcpssacsAssembly.dll When working with the dcpssacsAssembly.dll provided with the C# API there can be compatibility issues with Visual Studio versions. This is because the dcpssacsAssembly.dll is created with the use of the .NET framework 2.0. Solution: The dcpssacsAssembly.dll is now generated with the corresponding Visual Studio .Net Framework compiler.
OSPL-8528 | Closing a DDS entity containing closed entities intermittently results in an AlreadyClosedException When concurrently calling close methods on entities, the Java5 API may throw an AlreadyClosedException in case one of the children of the offending Entity already has been closed. Solution: The implementation of the various close methods has been modified to be able to deal with concurrent closing of multiple entities by the application.
OSPL-8544 | Ordered_access for GROUP scope does not handle lifespan expiry correctly. When a sample's lifespan has been expired in a Reader that belongs to a Subscriber with GROUP Presentation scope, it is not removed from the Reader cache at the start of a coherent_access block. Because of the fact that during a coherent_access block reader caches will be locked for any type of modification, the get_datareaders() function of the Subscriber and the read/take functions on individual Readers can still access samples that should have been expired. Solution: The start of a coherent_accesss block on the Subscriber will first test the contents of its Reader caches for expired samples. All samples that have been expired will be purged prior to locking their Reader caches.
OSPL-8566 / 16634 | Deployment Guide vs Configuration Guide In the set of documents delivered in the pdf directory of each OSPL version appears the Deployment Guide. This document refers about 56 times to "the separate Vortex OpenSplice Configuration Guide". The references should point to section 12 of the deployment guide itself instead Solution: The references in the document have been updated.
OSPL-8576 | TypeEvolution chooser should be hidden when the Google Protocol Buffers feature is disabled for the platform. In Vortex OpenSplice Tuner, when choosing to read or write data from a GPB-defined topic, the user is prompted with a dialog window to choose which type evolution to view the data as. If the Vortex OpenSplice installation does not have the Google Protocol Buffer feature enabled, then Tuner should not prompt the user for type evolution choice, since it wouldn't affect anything. Solution: If the Google Protocol Buffer feature for Vortex OpenSplice is not included in the installation, then the type evolution choice in Vortex OpenSplice Tuner will not appear.
OSPL-8583 | Possible memory leak when reader is removed with uncommitted transactions When a reader was removed that still had unread complete transactions it was possible that the transaction leaked. Solution: Updated the internal transaction administration so that when a reader is removed so are its transactions.
OSPL-8596 | Wrong dispose in protobuf example In the protobuf example, the 'Person' protobuf type has 2 key fields : name and worksFor.name. The publisher code first writes a sample with name="Jane Doe" and worksFor.name="Acme Corporation". Then it is supposed to dispose this instance but in fact disposes another instance as it only sets the name field to "Jane Doe" but does not set the worksFor.name field. Solution: The worksFor.name is now also set for the dispose.
OSPL-8609 | When coherent group access is used a resource claim regarding the resource limits of the group is performed twice. When coherent access is used then the resource counters maintained in the group regarding the resource limits set on the group are decremented twice. This may cause samples loss because of the incorrect resource counters in the group. Solution: The group resource claim on the resource limit is performed only once for each coherent transaction.
OSPL-8618 | When the durability client receives an event to request historical data while the subscriber is being destroyed, the durability client could crash when it tries to handle the event. When the durability client receives an event to request historical data from a reader, the durability client will asynchronously determine the partitions for which data must be requested from the reader's subscriber. In case the subscriber has just been destroyed then the durability client tries to determine the partitions from a non-existent subscriber. This inevitably leads to crash. Solution: Before determining the partitions from the reader's subscriber a check is added to see if the subscriber exists. If the subscriber exists it is made sure using refcounting and locking that the partitions can be obtained, even if another thread is in the process of destroying the subscriber.
OSPL-8640 | C++ RMI applications may crash on Windows when compiled with VS 2015 C++ RMI applications may crash on Windows platforms when compiled with the Visual Studio 2015 compiler. The problem is that constructors of classes call the default constructor of its virtual parent class explicitly. However, that default constructor is not implemented. Solution: These explicit calls to default constructors have been removed.
OSPL-8643 | A durability service that cannot act as aligner for a namespace does not merge when its fellow aligner re-appears within the expiry time A durability service can be configured as non-aligner (alignee) for a namespace, in which case it is dependent on a fellow durability service (master) to provide historical data for this namespace. When the alignee looses its master (e.g., due to a disconnect) there is no durability service to provide historical data for this namespace, and the namespaces of the aligner and aligner may diverge. When a reconnect appears the master suddenly becomes available again, and the alignee should trigger a merge action to resolve the potentially diverged state. This was not happening in case a master appears with the expiry time. Consequently, the alignee may end up in a diverged state. Solution: When a master of an alignee disconnects from the system, the namespace state is cleared and its master is reset. As soon as an aligner appears a master conflict is detected and a merge will be triggered.
TSTTOOL-372 / 16541 TSTTOOL-379 / 16578 | Python Scripting Engine should support reading or writing to non-default partitions The python scripting engine was connecting to on the default partition (the partition with an empty name) for all readers and writers. Solution: With this fix, the scripting engine connects by default using the partition name pattern '*', which is consistent with Tester's behaviour. In addition, it is now possible to explicitly create subscribers and publishers, and to explicitly provide the desired partition name/pattern.
TSTTOOL-373 / 16541 TSTTOOL-378 / 16578 | Python Scripting Engine should support setting QoS settings on entities The Python scripting engine did not allow specification of Quality of Service (QoS) policies when creating entities Solution: all readers and writers were configured with default policies. With the fix, it is now possible to specify QoS policies on the following entities: readers, writers, publishers and subscribers.
TSTTOOL-391 | Python Scripting Engine should support WaitSets The python scripting engine did not permit creation of wait sets. Solution: With this fix, a WaitSet class has been implemented, and it is possible to add Read Conditions to the wait set. Note that the WaitSet implementation does not yet support Status conditions or Query conditions.

## 6.6.3p1

Report ID. | Description
--- | ---
OSPL-8547 / 16628 | Topic definitions from KV-persistent store are not announced to other nodes Topic definitions from the kv-store are not announced to other nodes. If no application on that other node has already registered this type definition the situation can occur that the durability service will not reach the operational state. Solution: The kv store will announce the topic definitions found in the persistent store to all other nodes

## 6.6.3

Report ID. | Description
--- | ---
OSPL-7457 | Interoperable transient-local support. Transient-local was handled as transient data, but in combination with running DDSI as network protocol, data sometimes got delivered multiple times. Solution: In cases where DDSI is the network protocol, historical transient-local data is delivered by the DDSI2(E) service and no longer by the durability service.
OSPL-7515 / 15645 | When the merge policy for a namespace that is responsible for builtin topics is different from IGNORE or MERGE, the system state can become inconsistent. In the configuration a user can specify merge policies for namespaces. These merge policies specify how to resolve state diverge due to disconnections. If the merge policy that is specified for the namespace that is responsible for the builtin topics is different from IGNORE or MERGE then the internal state of the system can become inconsistent. This is undesirable and should be considered as an invalid configuration. Solution: The durability service now terminates when the merge policy that is specified for the namespace that is responsible for the builtin topics is different from IGNORE or MERGE. Termination will only occur when the durability service is responsible for builtin topic alignment.
OSPL-8044 | Undesired timeout on wait_for_historical_data without durability When durability is not enabled, a wait_for_historical_data call would still block during the timeout-period, even though no historical data will be delivered to a reader without a durability service. Solution: A check was added to determine if durability is used. If not, wait_for_historical_data will return precondition_not_met instead of blocking and returning timeout.
OSPL-8306 / 16511 OSPL-8096 / 16183 OSPL-8313 / 16513 OSPL-8314 / 16514 OSPL-8315 / 16512 | The networking service may crash when a reconnect occurs under high load conditions. When the networking service determines that another has not reacted in time and is removed from the reliable protocol and shortly thereafter the just removed node is reconnected it may occur that some variables related to this node are not correctly initialized to their default values. Solution: The state variables that the networking service maintains for the participating nodes are set to their default values when the node is removed from the reliable protocol. This ensures that when a node is considered alive again that the node related information has the correct state.
OSPL-8310 | Statistics not enabled when not explicitly setting enabled attribute to true. When not explicitly configuring the enabled attribute of the //OpenSplice/Domain/Statistics/Category element and setting it to true, the statistics for that category are not enabled. Solution: When not configuring the enabled attribute it is now interpreted as having the true value set.
OSPL-8311 | ThrottleLimit configuration does not accept human-readable sizes as input. The //OpenSplice/NetworkService/Channels/Channel/Sending/ThrottleLimit provides the lower bound for throttling and is really a size in bytes. Until now this value would not accept human-readable sizes. Solution: Human-readable sizes can now be used as input for ThrottleLimit
OSPL-8391 / 16538 OSPL-8462 / 16573 OSPL-8467 / 16579 | The reception of a dispose message may cause a crash when the corresponding instance has been removed. When a dispose message is received the corresponding datareader instance is lookup using the corresponding group instance. However in the mean time the datareader instance may have been removed. The dispose message will than trigger the creation of a new datareader instance but at that time the key information present in the dispose message is not available which may cause access to an invalid pointer value. Solution: When the datareader receives a dispose message for an instance that is removed the dispose message will be dropped because it will not result in any state change.
OSPL-8439 / 16570 | Include dependency for constant declarations missing in idlpp. When declaring a constant in an IDL file whose type is taken from an included IDL file, idlpp forgets to take the include dependency into account. This means that the generated code will refer to a type from another generated file, but the first file will not include the second file, resulting in compilation errors. Solution: The missing dependency has now been added to idlpp. The type of a constant declaration will now be properly included if located in another file.
OSPL-8477 / 16597 | Registering a protobuf-modelled type multiple times leaks memory When registering a type, its meta-data gets stored as well to allow tools to generically create datawriters and datareaders without the need for pre-compiling the type information into the tools. When registering a protobuf-modelled type with the same DomainParticipant multiple times, the definition leaks away though due to a missing deallocation. Solution: the missing deallocation of the duplicate type in the type registration algorithm has been added.
OSPL-8480 / 16599 | Ordered_access does not always suppress invalid samples correctly. When using ordered_access when reading/taking data, some additional (invalid) samples could appear that you would normally not see when reading from a similar Reader that is not using ordered_access. This is caused by the fact that normal DataReaders suppress invalid samples when they can mask those invalid samples by valid samples for the same instance. However, in case of ordered_access, this suppression mechanism was not being applied. Solution: The suppression mechanism for invalid samples is now also applied to DataReaders that use ordered_access.
OSPL-8488 / 16604 | Coherent access in combination with resource limits can results in not receiving sample updates. When using coherent access in combination with resource limits and max samples per instance is set to 1 it could be that samples are not being received by the datareader. Solution: The defect in the datareader mechanism is resolved and samples are being properly received.
OSPL-8497 / 16613 | ArrayIndexOutOfBoundsException can occur during termination when using waitsets in the Java API. When using the Java API in combination with waitsets an ArrayIndexOutOfBoundsException can occur during termination of the middleware. Solution: The defect in the waitset mechanism is resolved and the exception will not occur anymore.
OSPL-8508 | DCPSPublication samples maintained longer than necessary. In some cases, samples for the DCPSPublication topic were maintained longer than necessary by spliced. Even though eventually spliced would reclaim the memory, this appeared as if there was a memory leak. Solution: The processing of the samples by spliced has been changed, so that cleanup happens as soon as possible instead of deferred.
TSTTOOL-369 / 16350 | Tester in Jython does not support float.Nan values in check method In the provided Python Scripting Engine example, a Topic's float member with a NaN value could not be checked and the check function would return false. Solution: The _checkPyobj(pyobj, checkValues, logFailures = False) function in $OSPL_HOME/tools/scripting/examples/tester_compat.py has been modified to handle this case.
TSTTOOL-376 / 16517 | Install Jython for ospltest scripts. When installing Jython on Windows platforms following the instructions in the Tester User Guide, users would be unable to install the library due to spaces in the OSPL_HOME environment variable. Solution: Updated the documentation to have quotes around the environment variables that could have spaces on Windows.

## 6.6.2p4

Report ID. | Description
--- | ---
OSPL-8139 | Durability creates defaultNamespace when configuration is invalid. The durability service can silently ignore an invalid configuration (i.e. no namespaces and/or policies are included, or are not consistent). In that case the service applies the default configuration, i.e. a defaultNamespace with initial alignment and alignee policy. Since namespaces are also exchanged with other durability services in a domain, the resulting behaviour of the mis-configured node, but also other nodes, may be far from what the user expects. Solution: Instead of silently applying default configuration parameters, the service now refuses to start in case the configuration is missing or invalid, reporting relevant errors to the OpenSplice error log.
OSPL-8221 / 16391 | DataReader may crash when using ordered_access. The administration of a DataReader that has a PresentationQos with ordered_access set to TRUE may become corrupted when all available samples are taken out of the DataReader. This corruption might in turn result in a crash of the publishing (when on the same federation as the corrupted reader) or subscribing application. Solution: The ordering mechanism has been fixed so that taking the last sample out of a Reader with ordered_access set to TRUE can no longer corrupt the Reader's administration and therefore no longer crash your applications.
OSPL-8234 | Samples written without begin_coherent_changes broke ordering Samples (including implicitly created samples like unregister on writer deletion) written with a coherent writer without calling begin_coherent_changes first could be delivered out of order and during a begin_access. Solution: For a coherent writer every sample is now part of a transaction. A write without a previously called begin_coherent_changes now does this implicitly. This ensures in order delivery and samples are no longer delivered after calling begin_access.
OSPL-8288 / 16504 OSPL-8289 / 16503 | The use of the newly introduced detachAllDomain functionality occasionally resulted in processes blocking or crashing when detaching and terminating. The problem was caused by two reasons: some internal participant threads that remained active where they should have stopped during the detachAllDomain call. when an application listener callback blocks in application code OpenSplice failed to detect that it was safe to terminate. As a result the detachAllDomain failed and depending on the parameter values it could either hang or fail. In case of a failure the detachAllDomain returned with OK and the application process continued to terminate which then caused a crash because the remaining thread where still accessing shared memory while being unmapped from process space. Solution: The ordering mechanism has been fixed so that taking the last sample out of a Reader with ordered_access set to TRUE can no longer corrupt the Reader's administration and therefore no longer crash your applications.
OSPL-8442 OSPL-8435 / 16568 OSPL-8427 / 16564 | The method detach_all_domains may fail when a listener callback is blocking. The listener callback is called from shared memory context which means that the thread that is executing the listener callback is registered as using shared memory resources. The detach_all_domain method will try to have all threads that are executing from shared memory context to either leave the shared memory context or to block which would allow the shared memory to be detached safely. Thus when the listener callback is blocking in the application context the detach_all_domain method will fail with a timeout because this thread is still listed as using shared memory resources. Solution: When an application listener callback has to executed the thread that has to call this callback first releases the shared memory resources it is using and leaves the shared memory context before calling the callback.
OSPL-8443 | The function DDS_wait_for_historical_data_w_condition() does not handle the special value DDS_TIMESTAMP_INVALID correctly. The function DDS_wait_for_historical_data_w_condition() allows an application to provide conditions on the historical data to request. In particular, timestamps to indicate the interval when data was produced can be specified. The special DDS_TIMESTAMP_INVALID can be used for both the lowerbound and upperbound of the interval and should be interpreted as don't care. Due to an error these special values where not handled correctly, causing these values to be interpreted as invalid parameters and causing the DDS_wait_for_historical_data_w_condition() to return with BAD_PARAMETER return code. Solution: The error is fixed, so DDS_TIMESTAMP_INVALID is now considered a valid value. Note that this issue has currently only been fixed for the C language binding. Other language bindings will be fixed in a future release.

## 6.6.2p3

Report ID. | Description
--- | ---
OSPL-8205 / 16386 | Exception in thread ListenerEventThread causes NullPointerException. When using the Java API with listeners a NullPointerException can occur when deleting an entity which has a listener attached. Solution: The cause of the fault is still unclear but a workaround has been implemented to catch the exception so the listener will terminate correctly. When this happens a trace will also be added to the ospl-error.log
OSPL-8388 | dbmsconnect example configuration fails to get open with configurator The dbmsconnect example XML configuration contains a '<>' as part of an SQL filter expression, but this needs to be escaped in XML for the XML to be valid. Even though dbmsconnect is able to cope with this file, the configurator tool is not accepting this invalid XML. Solution: The '<>' statement has been escaped in the XML file as '&lt;&gt;'.

## 6.6.2p2

Report ID. | Description
--- | ---
OSPL-6586 | Coherent updates are not always delivered to DataReaders for a ContentFilteredTopic. ContentFilteredTopic DataReaders filter out samples that do not match the filter. Samples that are filtered out purely on key-value do not even get offered to the DataReader as they are filtered out a bit earlier in the process. For coherent sets, the DataReader, even though filtering out the sample, still needs to receive the sample to determine completeness of a coherent set as it counts all samples and compares this count with the expected number provided by the publisher. Therefore not receiving all samples results in an incorrect count and the complete coherent set not being made available to the application. Solution: For ContentFilteredTopic DataReaders, all samples are now delivered for counting purposes but immediately dropped afterwards so that no resources are consumed but completeness can be verified. Although samples are dropped, some additional administration is required to keep track of the data completeness and as a consequence some extra memory is kept during the time the coherent set is not completed yet.
OSPL-7601 | DDSI2 service lacks support for transient-local history settings of KEEP_LAST with depth > 1. The DDSI2 service maintains transient-local data in accordance with the DDSI specification, but only implemented support for KEEP_LAST with depth 1. For OpenSplice this is more-or-less a non-issue as the durability service handles the history correctly anyway, but when interoperating this could be a restriction. Solution: The history maintained by DDSI now fully supports all history QoS settings.
OSPL-7893 | The durability service may select conflicting masters after a reconnect. When a reconnect occurs the durability service has to determine a new master. When a reconnect occurs the master selection procedure will determine a new master in a number of rounds where information is exchanged between the durability fellows to reach conformity about the selected master for each namespace. However when the durability service is in the complete state the master selection procedure selects a master to early which causes that the durability fellows may select different masters causing the potential merge of historical data to fail. Solution: When in the complete state and a reconnect occurs, the master selection now waits during each stage of the master selection until all information has been received from the other fellows about their master selection.
OSPL-8114 | When publishing a coherent set during durable data alignment, transactions may never become complete. When publishing a transaction during alignment of durable data it is possible that a transaction never became complete as it could receive parts of the transaction in twofold, each received part of the transaction was counted and used to determine completeness. In this case the transaction never became complete as the expected count was lower then the actual count. Solution: The transaction mechanism has been updated to handle duplicate messages. The internal group must be complete before the readers receive the EOT markers.
OSPL-8126 | When the durability service terminates while rejected samples still need to be delivered to the readers, then termination is stalled until the samples are delivered. When the durability service receives alignment data it tries to deliver the data in the readers. When delivery is rejected (e.g., because the reader has reached its resource limits) then the durability service will periodically retry to deliver the data. In case the durability service must terminate while periodically retrying to deliver rejected samples, then termination will only succeed after all samples have been delivered successfully. This negatively affects responsiveness of the durability service in case of a termination request. To improve responsiveness the durability service should not wait until all samples have been delivered when it is requested to terminate. Solution: The durability service does not deliver rejected samples anymore when termination occurs.
OSPL-8136 | Possible missing of async RMI replies when server exits and starts again A C++ RMI client may miss replies from a server when a server replies to an asynchronous request and exits, then it is re-started again to process other requests whereas the client remains active. The reply instance is then disposed and as the client takes the replies, it receives an invalid sample that disturbs the replies management and makes RMI miss the following valid replies. Solution: Invalid samples for the RMI replies datareader have been disabled at the client side.
OSPL-8152 / 16371 | Crash in the shared memory monitor thread due stacksize limitation. When using a datamodel with a lot of indirections and nesting and experiencing an application, the shared memory monitor crashes too, because it runs out of stack space during its attempt to clean up application resources. Solution: It is now possible to configure the stack size for all splice daemon threads found in the configuration section //OpenSplice/Domain/Daemon. Each thread now has an additional element "StackSize" which can be set to the desired size. An example to set the shmMonitor stack to 1 Mb: <shmMonitor><StackSize>1048576</StackSize></shmMonitor> When this element is not specified the thread will use the default size of 512Kb.
OSPL-8172 | PublicationInfo for group coherent writer notification unsafe. When the splice daemon receives a PublicationInfo message that describes a coherent writer, a notification is sent to the publisher in an unsafe way, which caused potential multithreaded manipulation of the internal cached writer administration in the coherency mechanism. Solution: Made the notification threadsafe.
OSPL-8185 / 16385 | Potential crash during simultaneous creation and deletion of a shared DataReader/Subscriber There is a race condition in the implementation of shared DataReaders/Subscribers, where if you simultaneously delete the last occurence of a shared Reader/Subscriber while at the same time creating a new reference to it, the system might end up crashing. Solution: The race condition has been removed. It is now possible to safely remove the last occurence while at the same time creating a new reference to it.
OSPL-8189 | Group coherent reader can access subscriber after deletion. After deletion of the subscriber a group coherent reader may still try to access the subscriber, which causes a crash. Solution: The data reader has a back-reference to the subscriber , which is now removed in a threadsafe manner and checked before trying to access the subscriber.
OSPL-8191 | After calling begin_access, historical data could still be delivered to a group coherent reader. Reader creation retrieves historical data with the begin_access (read)lock instead of with the access (write)lock. This can cause data to change after a begin access in a multithreaded environment. Solution: Historical data is now retrieved within the access (write)lock.
OSPL-8208 | C# API Waitset.wait causes NullReferenceException. When using the C# DDS API with waitsets a NullReferenceException may occur when using the Waitset.wait call. Solution: The fault in the waitset handling for C# is fixed.
OSPL-8212 / 16390 | RTI/TwinOaks interoperability issue with "autodispose_unregistered_instances" QoS RTI and TwinOaks have a different interpretation of the "autodispose_unregister_instances" writer QoS, which could cause unexpected disposes of instances in OpenSplice when a RTI or TwinOaks writer disappears. Solution: The DDSI2 service has been modified to distinguish between ADLINK and non-ADLINK peers when defaulting the QoS setting, eliminating these unexpected disposes.
OSPL-8222 | Multi-partition Publishers don't disconnect properly from all targeted partitions. Publishers that are connected to multiple partitions can cause problems when they need to disconnect from one or more of their partitions (for example because the PublisherQos is changing one or more partitions or because the writer is deleted.) These problems manifest themselves by not properly sending unregister messages to all targeted partitions, which may cause the InstanceState not to go to NO_WRITERS when it should and which may cause v_registration objects to leak away in the shared memory. Solution: Multi-partition Publishers now disconnect properly from all targeted partitions, which should result in the correct InstanceState for all partitions and which should remove the leaking of v_registration objects.
OSPL-8224 | Spinning waitset when an empty coherent set is received. A data_available notification was sent to all readers part of a transaction even when it did not have data. A waitset with a following get_datareaders (which returned 0 readers) could then enter a spin loop when no read to reset the data_available flag was done. Solution: data_available notifications are now only sent to readers which have data.
OSPL-8233 | Completing a pending group coherent transaction could cause a crash after reader deletion. When a group coherent transaction becomes complete it is added to a pending list. This pending list is flushed to the readers upon call to begin_access. When a reader was deleted the begin_access still tried to flush the deleted readers part of transaction which could cause a crash. Solution: Data for the removed reader is now removed from the pending list on deletion of that reader.
OSPL-8267 / 16494 | DDS protobuf compiler fails when including more than one depth-of-directory. When proto files include others that are in different directories with more than one level difference, the DDS protobuf compiler plugin would fail to generate code as the output directory for the generated code was not created recursively, causing the directory creation to fail and therefore code generation would fail alltogether. Solution: The code generator has been modified to create directories recursively in all situations.
OSPL-8268 | detach_all_domains operation doesn't return a failure when something went wrong. The detach_all_domains function always return result OK. Even though no DDS call can be made afterwards, it may still prove useful to know if all was well. Solution: The function now doesn't return OK anymore in case of a detectable failure. In case it took too long to wait for threads to leave shared memory, TIMEOUT will be returned.
OSPL-8271 | isocpp2 target for idlpp crashes on enum in outer scope. When idlpp attempts to compile an IDL file that has an enum in the outer scope (i.e. not embedded in a module) to the isocpp2 target, it crashes with a segmentation violation. Solution: The crash has been fixed in idlpp.
OSPL-8302 / 16505 | The detach_all_domain operation may cause a process to crash due to a race condition. When detach_all_domains returns successfully it has detached the shared memory segments from the process. Before that, it will deny all threads access to the shared memory segments. However, a race condition exists, which may cause a thread still to be in a critical section after the unmapping the shared memory from the process. The aforementioned thread may try to access an object in shared memory, which causes a crash of the process. Solution: The detach_all_domain operation now waits for all threads to have left this critical section before unmapping the shared memory segment(s) from the process.

## 6.6.2p1

Report ID. | Description
--- | ---
OSPL-7947-1 | Transaction sample received twice, as historical data and as normal write, causing the transaction to never become complete When reader was created it asynchronously connected and requested historical data making it possible to receive the same sample via historical data and the normal path, this sample was counted twice which caused the transaction to never become complete. Solution: A reader now connects and requests historical data synchronously so that the sample is not received twice and the transaction now becomes complete.
OSPL-7947-2 | When discovering a transactionWriter implicitly is was possible that transactions with same writer never became complete The group transaction mechanism has two ways of discovering writers one via builtin topics and an implicit discovery when data from that writer is received. In the latter situation it was possible that transaction which were depended on the same writer never became complete. Solution: When a writer is implicitly discovered check all open transactions for dependency on the writer and mark the writer as discovered so that the transaction can become complete.
OSPL-6395 / 14540 | Integration with Rhapsody 8.x The name of the abstraction-layer header file ("os.h") was too generic and caused a collision with a file by the same name belonging to IBM Rhapsody. To prevent this, and other potential name clashes in the future, the file was renamed to "vortex_os.h" Solution: In case the C language-binding is used, this header file is included in idlpp-generated code. This means code generated by a previous version of OpenSplice cannot be compiled using the new header file and should be regenerated first. Applications already compiled for a previous version are not affected.
OSPL-7562 | Durability service does not handle default partition properly in name-space configurations The OpenSplice durability services exchange name-space information before starting alignment of historical data. If name-space contents do not match, services refuse to align each other. The algorithm that does the comparison of the expressions has a problem dealing with the so-called default partition (this is an empty string). This leads to an incorrect interpretation of ".<TOPIC>" expressions when comparing name-space contents. Solution: The flawed algorithm has been corrected to deal with the default partition properly too.
OSPL-7601 | DDSI2 lacks support for transient-local history settings of KEEP_LAST with depth > 1 The DDSI2 service maintains transient-local data in accordance with the DDSI specification, but only implemented support for KEEP_LAST with depth 1. For OpenSplice this is more-or-less a non-issue as the durability service handles the history correctly anyway, but when interoperating this could be a restriction. Solution: The history maintained by DDSI now fully supports all history QoS settings.
OSPL-7687 | bundled throughput-example doesn't work correctly on windows The bundled throughput examples uses a flawed algorithm to determine how long an action takes. Solution: The flawed algorithm has been corrected.
OSPL-8121 / 16218 | Incorrect publication_handle in received SampleInfo The publication_handle in the SampleInfo object of a recieved Sample was previously being set to the same value as the instance_handle, this was incorrect. Solution: The SampleInfo::publication_handle() now returns the correct publication_handle as expected.
OSPL-8124 | Improve group transaction flush mechanism. The group transaction flush mechanism was inefficient as it used an unnecessary list Solution:The unnecessary list has been removed
OSPL-8144 | Java5 listener may trigger before entity is fully initialised. Entities created throughout the Java5 API, which have a listener attached at creation time may cause problems as the listener may trigger before the entity is fully initialised. Solution: Listener callbacks are now blocked until the entity is fully initialised
OSPL-8149 | Server-part of client-side durability protocol must be enabled for all default shared memory configurations. The durability service has a feature to react to requests from clients that have an interest in historical data but are not able (or willing) to run a durability service themselves. To have a durability service react to such requests a configuration option //Opensplice/DurabilityService/ClientDurability[@enabled] exists that must be explicitly set to TRUE. This is not very user-friendly and hampers a seemless out-of-the-box experience. For that reason the client durability feature will also be enabled now when the //Opensplice/DurabilityService/ClientDurability-element is present without the [@enabled]-attribute. Furthermore, for shared memory configurations that are part of the distribution this feature is enabled by default. Solution: Durability services now will react to client requests when the //Opensplice/DurabilityService/ClientDurability-element is present without the [@enabled]-attribute. Furthermore, default shared memory configurations have been updated so that the client durability feature is enabled.
OSPL-8151 / 16355 OSPL-8159 / 16376 | JVM crash when creating a participant with an own set name for the thread creating the participant. When using the Java API and the thread creating the participant has an own set name the JVM crashes. Solution: The defect is solved and the JVM will not crash anymore on an own set thread name.
OSPL-8157 | Coherent updates do not get delivered when using a wildcard partition. When a Publisher is publishing coherent updates in a wildcard partition (a partition that uses a wildcard like '*' or '?'), or a Subscriber is subscribing to a wildcard partition, then coherent updates are not correctly matched between Publisher and Subscriber and the contents of the coherent update will be lost. Solution: Wildcard partition matching between Publisher and Subscribers has been improved: either the Publisher or the Subscriber can now use a wildcard partition without impacting the coherent update. However, if both Publisher and Subscriber use an unequal yet matching wildcard partition a mismatch may still take place. Fixing this scenario is left for a future update. The issue was already captured in the known issues list under OSPL-973
OSPL-8161 / 16377 OSPL-8071 / 16171 | NullPointerException in the ListenerThread when using Java When using the Java API and a listener is used on an entity it can happen that the ListenerThread causes a NullPointerException when the entity is removed. The info logfile will then also show the following messages "timeout or spurious wake-up happened x times." Solution: The defect is the listener mechanism is solved and the deletion of an entity will cause no more exceptions/info messages
OSPL-8169 | In case of group coherent updates where more than one transaction is involved and simultaneously both become complete by actions on different readers a deadlock occurred. A cross locking deadlock situation involving the reader lock and group lock caused the problem, when an action performed on a reader leads to a complete transaction it will lock the group to notify about the completeness, if the group itself then also become complete and notify all other readers, this last step takes the locks in reversed order and will lead to a deadlock when two transactions become complete by two simultaneous actions on different readers. Solution: The group now releases the lock before notifying all other readers.

## 6.6.2

Report ID. | Description
--- | ---
OSPL-5028-1 | Launcher - Choosing a file for OSPL_URI that is not an OpenSplice configuration file results in errors. In the Vortex OpenSplice Launcher Settings, under the Environment tab, if one were to use the file chooser to set the URI or the Lice nse field, and selected a file type that is not meant to go there, errors would be reported in the log and Launcher would otherwise not guard against any attempts to process the invalid files. Solution: For the file chooser dialogs for the URI and the License fields, an extension filter has been added to only show only .xml and .lic files respectively.
OSPL-5028-2 | Launcher - NullPointerExceptions get printed to console every time a configuration is selected. Whenever a OpenSplice config is selected from the configurations table, a NullPointerException and stacktrace would get printed to the console, due to a unchecked return from the examples table selection model. Solution: The accessed to the examples selection model are properly checked for null returns.
OSPL-7087 / 15090 | Adding support to an unexpected stopping of the underlying DDS middleware to the java RMI library. When the DDS middleware stops (normally or not) while a RMI server is waiting for or processing rmi requests, the RETCODE_ALREADY_DELETED error code should be handled properly. Solution: The RMI implementation shutdowns the RMI server in case it receives a RETCODE_ALREADY_DELETED that signals a stopping of the DDS middleware. This will unblock the server application thread that was running the RMI runtime to wait for the requests. Note that the DDS middleware must not be stopped before the RMI application has stopped, whatever it is at the client or the server side. Even if the RMI library has been updated to handle an expected stopping of the DDS middleware, the user application cannot continue to work well.
OSPL-7283 / 15405 | GettingStartedGuide is missing information about how to install OpenSplice on UNIX ARM platform. The procedure to install OpenSplice on a UNIX ARM platform is missing from the GettingStartedGuide. Solution: The GettingStartedGuide is extended with a description of the OpenSplice installation on a UNIX ARM platform.
OSPL-7317 | Not possible to create reader for builtin topic DCPSType Not possible to create reader for builtin topic DCPSType, because Typesupport for DCPSType was not mapped on the kernel representation as is required for builtin types, the typesupport was not registered and the DCPSType reader was not created for the Builtin Subscriber. Solution: DCPSType typesupport is now generated correctly and registered and a DCPSType builtin reader is created.
OSPL-7346 | Truncation of max file size configuration values on 32-bit platforms An issue in the configuration file processing caused truncation of the MaxFileSize RnR storage parameter on 32-bit platforms. Solution:To resolve the issue, configuration processing was improved. In addition to resolving the truncation, it now supports floating point values and the following list of units: b, B (bytes) , KiB, kB, K, k (=1024 bytes), MiB, MB, M, m (=1024KiB), GiB, GB, G, g (=1024MiB), TiB, TB, T, t (=1024GiB)
OSPL-7618 / 15802 | Readcondition and ContentFilterTopic could lead to a memory leak in isocpp2 When using a Readcondition or a ContentFilterTopic in isocpp2 it is possible that they are not properly cleaned up after removing them cauing a memory leak. Solution: The leak has been fixed.
OSPL-7627 / 15740 | Queries/Filters had problems with literals representing fields of type "unsigned long long" (uin64_t). Queries/Filters were not able to parse literals of type "unsigned long long" whose value were between MAX_INT64 and MAX_UINT64 correctly. Solution: The parser has been fixed.
OSPL-7686 / 15837 | Deleting a domain (last participant from a domain) doesn't free all used resources correctly in single process mode. Deleting a domain (last participant from a domain) doesn't free all used resources correctly in single process mode. Solution: By setting the database size in single process mode the database will be allocated on heap and used by the memory manager in opensplice. Deleting the domain with this database results now in a correct cleanup off all used resources. Note: In previous versions the Size attribute for the Database element in the configuration had no meaning and was ignored. All available heap memory was available for the domain service. With the current implementation the database size is limited to the configured size and memory is managed by the ospl memory manager. Size 0 is default and will force the old unlimited behavior where the operating system memory manager is utilised.
OSPL-7694 / 15847 | Problem with string writing in the Tuner. When using the Tuner and writing a string unbounded or bounded square brackets are always added to the input. Solution: The writing mechanism is changed and no more square brackets are added.
OSPL-7723 / 15852 | Suppress default logs true provides null data to report plugin. When using a report plugin with the option SuppressDefaultLogs set to TRUE and the element TypedReport set in stead of Report results in null data inside the specified report log. Solution: The report plugin is adjusted so that in this scenario the reports are passed to the specific log file.
OSPL-7743 / 15912 | Possible missing of some async replies when their server exits. The problem may occur when a server replies to an asynchronous request and exits, then it is re-started again to process other requests whereas the client remains active. The reply instance is then disposed and as the client takes the replies, it receives an invalid sample that disturbs the replies management and makes RMI miss the following valid replies. Solution: Disabling the invalid samples for the replies datareader at the client side.
OSPL-7762 | DDSI declaring readers on slow machines "non-responsive". DDSI2's flow-control was extremely sensitive to the configuration of the maximum allowed amount of unacknowledged data in a writer, the relative speeds of the machines and the networks and the socket receive buffers on the subscribing nodes. Solution: DDSI2 now dynamically adapts the maximum amount of unacknowledged data, based on retransmit requests. The adaptation can be disabled for increased predictability if required.
OSPL-7772 | Missing samples after CATCHUP or REPLACE merge has occurred. When nodes reconnect and a CATCHUP or REPLACE merge policy has been configured, then alignment takes place. It turns out that the alignment data contains the right amount of data, but after injection of the data in the system there are less samples than expected. This phenomenon was caused due to an incorrect administration of the last dispose time which prevented that data that has been produced before the last dispose time could be inserted. In case a foreign state conflict appears and there is no aligner, rediscovery of an aligner would not lead to a merge. Solution: The last dispose time is not set when alignment for CATCHUP or REPLACE takes place, and rediscovery of aligners in case of foreign state conflicts is fixed.
OSPL-7777 | Launcher should display the reason why tools cannot be started. If Java is not installed on the host machine from which Launcher is started, the tools cannot be started even though the buttons are enabled. Solution: In order to help troubleshoot incompatibilities between our tools and other Java implementations, Added another environment variable JAVA_HOME that would get picked up by Launcher from the user's environment (just like the other variables) and allow the user to specify/override their own JAVA_HOME path within the tool. Launcher will detected if a JRE and JDK are installed. When modifying the JAVA_HOME environment variable in Launcher or starting Launcher with a JAVA_HOME set to a non-officially supported Java implementation (OpenJDK, IBM Java, etc), a notification will come up indicating what Java implementation was picked up and that it is not officially supported for running the tools and building/running the examples. The tools and examples will remain enabled in this case. The tool buttons are disabled and a message is displayed that Java is not detected in JAVA_HOME. The buttons will re-enable once a valid Java install directory is specified in JAVA_HOME.
OSPL-7814 / 15970 | IllegalMonitorStateException when using the java API in combination with a listener When using the Java API in combination with a listener an IllegalMonitorStateException could occur. Solution: The cause of the exception is fixed in the listener handling.
OSPL-7816 / 15972 | Durability service doesn't notice disconnection. When using durability in combination with RTNetworking it could happen that when the network connection is lost the durability service is not notified about this. Solution: The defect in the disconnect mechanism is fixed and durability now gets the disconnect notification.
OSPL-7823 | As a user, I want to be able to preview all the environment variables. Allow the user to preview the environment variables that are available to the user through Launcher. Solution: A new Preview Environment Variables dialog is available to the user through the Preview button in the settings environment tab. The new dialog allows the user to preview the configured environment variables and copy to the clipboard.
OSPL-7839 / 15981 | Generation error in C# backend of idlpp When compiling an IDL file that specifies an array of enumerations, the C# backend of idlpp would generate a statement that contained a superfluous bracket, which caused a compilation error in the C# compiler. Solution: The C# backend of idlpp has been fixed by removing the superfluous bracket.
OSPL-7852 / 15991 | Warning during compilation in isocpp2 When compiling an application that uses isocpp2 a warning can occur in State.hpp. Solution: The warning has been fixed.
OSPL-7854 / 15990 | Coherent Set transaction do not proper process dispose messages. When a coherent set with a dispose message in it is used it can happen that the dispose is not proper handled causing late joiners to allign the disposed message with the status NOT_ALIVE_DISPOSE_INSTANCE_STATE where the message would be expected to be completly gone from the system. Solution: The coherent set mechanism is updated to handle dispose messages correctly.
OSPL-7857 / 15988 OSPL-7697 / 15841 | Memory could leak away when instances are recycled aggressively during an overflow of the networking queue. When an instance is unregistered but quickly brought back to life (by writing/disposing a sample with the same key), there is a small chance that in case of an overflow of the network queue some memory is leaking away. Solution: The memory leak has been fixed.
OSPL-7865 | Enable java debug symbols To improve readability of exception stack-traces and help with debugging java applications, symbols need to be included in the jars. Solution: symbols are now included in all jar files. As a result, the average size of jar files has increased ~25%. It is possible to rebuild the Corba-Java language-binding jar using the custom-lib build process. To create a jar without symbols please change the custom-lib build script, replacing -g by -g:none.
OSPL-7876 | RT networking crash when using scoped discovery RT networking configurations relying on roles and scopes to restrict discovery of nodes could crash on an invalid memory reference upon discovering a new node. Solution: The issue has been corrected.
OSPL-7877 | Durability merge policies can cause data loss For some merge policies durability needs to dispose all (or a particular subset) of the instances in a group, but it must not use the internal disposeAll functionality, as that implements the "dispose-all" operation that has an effect into the future. Because of that effect, old data could be lost following a CATCHUP/REPLACE/DELETE merge operation, including the data being aligned. Solution: The algorithm has been modified to no longer rely on this internal disposeAll functionality.
OSPL-7889 | idlpp may crash when generating for the isocpp2 target idlpp crashes for the isocpp2 target when specifying an IDL enum in the outer scope (i.e. not in a module). Solution: idlpp has been fixed to correctly handle enums in the outer scope.
OSPL-7890 | Group coherence: Avoid the partial alignment of historical group transactions A late joining Subscriber for group transactions may receive a group transaction partly as historical data and partly as incoming messages, this currently leads to invalid delivery of partially complete group transactions. Solution: Partly aligned group transactions now trigger full group alignment and remove all related transaction administration.
OSPL-7895 | Tooling entities are not cleaned up after disconnecting Entities created by tools are no longer deleted when disconnecting the tool due to an incorrect reference count of entities in the C&M API. As a result entities remained available in the federation the tools ever connected to until the federation stops. Solution: Corrected the reference count for entities in the C&M API.
OSPL-7924 | Add java5 and isoc++v2 DCPS examples to Launcher The titular DCPS examples were added to Vortex OpenSplice, but the Launcher tool currently does not have the capability to detect them and add them to the list of available language options. Solution: The Launcher tool has been updated to recognize the java5 and isocpp2 DCPS examples in a Vortex OpenSplice installation, and is able to execute build and run tasks for them.
OSPL-7931 | DDSI2 possible crash when lease expiry coincides with termination During termination, DDSI2 would delete all proxy entities explicitly, without accounting for the possibility that leases could still expire. This could lead to freeing a proxy participant prematurely, resulting in a use-after-free when deleting the one remaining endpoint. Solution: This issue has been solved.
OSPL-7932 | Group coherence: detect missing EOT message and discard associated pending transaction. As soon as a Subscriber receives a EOT message of a (group) transaction it knows for which writers it will receive EOTs, whenever an EOT or any data for other writer-transaction are missing but newer data for those writers is received then the Subscriber can conclude that the missing EOT and/or data is lost forever and subsequently discard the whole group transaction. Solution: Received messages of group coherent updates that will not become complete are now discarded.
OSPL-7933 | Group coherence: Subscriber-side re-evaluation of completed transactions to assure data meets latest user expectation. An initializing Subscriber can receive transactions that match the Subscribers readers before all readers are created, meaning that data belonging to the reader to be created is not considered and possibly not delivered. Solution: Completeness evaluation of ongoing group transactions now consider creation of additional DataReaders that may affect completeness.
OSPL-7938 | In situations where the builtin topics do not have to be aligned, they where still being aligned in case the AutoBuiltinTopics namespace is generated When no namespace for the builtin topics is configured, a namespace called 'AutoBuiltinTopics' is created automatically for the builtin topics. When no builtin topic aligned is needed (e.g., when DDSI takes care of the builtin topics) it could still happen that the builtin topics were being aligned, even though they shouldn't. Solution: Alignment of builtin topics is prevented for the AutoBuiltinTopics namespace in case no alignment is needed for them.
OSPL-7941 | Resource leak in application after closing domain in shared memory mode. If a domain is closed (last participant in an application for that domain is deleted) not all used resources were freed correctly in shared memory mode. Solution: Used resources are freed now for the closed domain.
OSPL-7946 | Group coherence: ddsi crash during connection changed A crash may occur in the DDSI2 service when a connection change happens during a coherent update by an application. Solution: Crash during connection change has been fixed.
OSPL-7947 | Group coherence: complete transactions sometimes do not get delivered Depending on timing, transactions, although complete, would not get delivered to application readers. Solution: Several bugs concerning race-conditions have been solved.
OSPL-7948 / 16142 | Limitation on supported network interfaces. When using DDSi with more than 32 network interfaces it is possible that the requested network interface is not found and DDSi will report an error. Solution: The number of supported network interfaces is increased to 128.
OSPL-7973 / 16144 | Java 5 QosProvider error reporting improvement. When using the QosProvider in Java 5 all errors with it resulted in a null pointer exception with no proper error message. Solution: The error reporting in Java 5 for the QosProvider has been improved. Each error now results in the proper java exception with a use full error message.
OSPL-7974 / 16145 | Waitset events potentially leak away when received after the Waitset's timeout value. If a WaitSet times out, and new events arrive before the unblocked Waitset thread gets the time to execute and report the timeout, the new events will be lost and their memory will leak away. The chances of this happening increase when a Waitset frequently times out while its thread has to compete for CPU time with one or more other threads that are generating events for that same Waitset. Solution: A thread that is unblocked by a Waitset because of a timeout, will first check for pending events prior to reporting the timeout. If pending events exist, each event is processed accordingly and the timeout is is not reported. If no pending events exist, the waitset will report the fact that it timed out.
OSPL-7978 | DDSI connection fail-over when using Vortex Cloud routing service. When DDSI is relying on the Vortex Cloud services, it should switch from one routing service instance to another in case of network or routing service failure. The Vortex Cloud discovery service provides its clients with new addresses to use in such situations, but the DDSI2 service would not actually switch to the new addresses. Solution: The DDSI2 has been modified to always use the most recent addressing information provided by the discovery service.
OSPL-8004 | Shared memory leak in set_qos operations. The OpenSplice kernel failed to release memory allocated in the process of changing the QoS of an entity, resulting in a memory leak each time a set_qos operation was used. Solution: The memory is now freed.
OSPL-8015 | Tuner export data throws exception. When attempting to export data using the Tuner, an exception is raised. This is caused by a change in the UI, where the QoS-ses to use are presented in a different manner. Solution: Updated internal algorithm to cope with the change in the UI to obtain QoS settings.
OSPL-8021-1 | DDSI2 crash in nn_address_to_loc when accepting TCP connection. The DDSI2 service could crash on accepting a TCP connection if requesting the peer address after accepting the connection failed, typically caused by the connection already having been closed. Solution: DDSI now handles this error condition correctly.
OSPL-8021-2 | Networking Bridge not enabling forwarding for a topic until new entities created/destroyed. The networking bridge processes the built-in topics describing the existing entities to determine what to forward. There existed cases in which the networking bridge would have been able to enable forwarding of data but instead would pause its discovery process until the arrival of new built-in topics. Solution: The networking bridge now always fully processes the available built-in topic samples before waiting for new ones to arrive.
OSPL-8021-3 | DDSI2 spamming the log with "malformed packet" warnings when interoperating with RTI Connext. RTI Connext sends many packets that are not well-formed RTPS packets, and these lead to "malformed packet" warnings from DDSI2. It appears that recent changes to RTI Connext have caused a significant increase in the number of warnings, leading to huge log files with little value to users. Solution: DDSI2 now no longer logs the "malformed packet" warnings for commonly encountered packets, except when run in "pedantic" mode.
OSPL-8021-4 | Phantom entities in OpenSplice with DDSI2 and the Networking Bridge when interoperating with other vendors' products OpenSplice internally operates using globally unique identifiers that antedate the DDSI specification, and hence DDSI2 translates between the identifiers as used in the DDSI specification and those used in OpenSplice. In combination with the Networking Bridge, the interaction could lead to the creation of "phantom" readers and writers as a consequence of an incomplete filter on the translated identifiers. Solution: The filtering now accounts for interoperating with other products.
OSPL-8021-5 | Networking Bridge discovery hang on topics used by other vendors' implementations The Networking Bridge requires complete topic definitions to be available, but the DDSI specification does not define interoperable type definitions. Therefore, the bridge can encounter readers and writers for topics that do not exist in OpenSplice. Solution: The networking bridge now skips endpoints that use undefined topics; if and when a topic becomes available, the endpoints are re-evaluated.
OSPL-8029 | When a client requests historical data using client-durability that matches multiple partition/topic combinations, multiple responses are generated. One of the ways to obtain is historical data is using the client-durability feature. When a client requests data that matches multiple partition/topic combinations the server responded with multiple data sets (one for each partition/topic combination). The intended behavior is that a single response is generated that contains the aggregated data from all requested partition/topic combinations. Solution: The problem is fixed and now a single response is generated that contains all requested data.
OSPL-8032 | Mmstat can report more memory available than configured Mmstat determines the amount of available memory through a fairly involved calculation, in which an mistake was introduced, causing it to potentially report more available memory than was configured. Solution: The calculation has been corrected.
OSPL-8034 | DDSI memory leak caused by a race condition between discovery and termination DDSI discovery runs in a separate thread that takes its input from the network. During termination, the network input was stopped, but the discovery thread could still be processing a participant discovery message. In this case, deleting all proxy participants could occur too soon, leaking a proxy participant. Solution: Processing DDSI discovery data is now forced to complete in time.
OSPL-8055 | Group coherence: transaction does not become complete In some scenarios transactions would not become complete and therefore not delivered due to an incorrect algorithm in the matching of writers and readers. Solution: Several scenarios that resulted in incorrect dropping group coherent updates are now solved.
OSPL-8058 | Group coherence: memory leakage The introduction of the group coherency feature introduces memory leaks in some scenarios, also in some situations where group coherence is not even used by any application. Solution: Several memory leaks concerning group coherent updates have been fixed.
OSPL-8072 | Maximum Domain ID value (230) is not enforced in the API or during startup of the domain. Maximum Domain ID value (230) is not enforced in the API or during startup of the domain Solution: The domain will refuse to start when the domain ID in the configuration file is out or range (larger then 230). Trying to pass an invalid domain ID in a function call will result in an error in the info log and the call to fail
OSPL-8091 / 16180 | Coherent Set transaction leaks v_transactionPublisher object Each time when a coherent set publisher is created a v_transactionPublisher object will leak. Solution: The coherent set mechanism is updated and the object is now properly freed.
OSPL-8095 / 16182 | Durability crash when inserting out of order disposed messages When durability is used to insert out of order disposed messages the service could crash. Solution: The defect is solved and durability will not crash anymore on out of order disposed messages.
OSPL-8123 | The persistent store retaining the wrong samples When committing a transaction on a KEEP_LAST history where the transaction contained more samples for a single instance than the depth of the history, the (KV) persistent store would not always retain the N latest samples. Solution: The persistent store has been fixed to retain the latest samples also in this case.
TSTTOOL-265 / 15462 | Implement built in script variables for current scenario/macro filename and path. The Tester scripting engine has facilities for calling on built in variables that can be referenced from any script execution. Two new variables that hold the value for the currently executing script file name and and the file path are needed. Solution:The new built in variables have been added to the Tester scripting engine as variable names "script_file" and "script_path". See Tester user guide section 6.1.2 for update.
TSTTOOL-343 | Tester's statistics browser can't display statistics information. Navigating to the statistics tab and attempting to view statistics information for DDS entities does not currently work. The Tester log file reports that the entities are not available. Solution: The CM objects that the statistics workers held to gather statistics from were being freed too early. The unintentional free has been fixed and the statistics view works again.

## 6.6.1

Report ID. | Description
--- | ---
OSPL-6050 / 14407 | DDSI2 MaxMessageSize and FragmentSize are no longer considered Internal options DDSI2 MaxMessageSize and FragmentSize are no longer considered Internal options and should therefore be moved from the Internal to the General section. Solution: The DDSI2Service/Internal/MaxMessageSize and DDSI2Service/Internal/FragmentSize options have now been moved to DDSI2Service/General/MaxMessageSize and DDSI2Service/General/FragmentSize. The old setting is still supported as a deprecated setting and causes a warning when used.
OSPL-6467 | When a client sends a historical data request to the client-durability server, the server did not respect the timeout that was specified in the reques When a client sends a historical data request to the client-durability server, the client can specify a timeout value to indicate the time that the server may take to answer the request. Up to now the server did not respect the timeout value and would always answer immediately. With this fix the server now respects the timeout value. Solution: The server now queues requests and answers them based on their timeout value.
OSPL-6983 | When a client sends a request for historical data to the client-durability server, the server must ensure that the client's historical data reader is discovered. One way for a client to obtain historical data is by publishing a request for historical data, and waiting for the response from the client-durability server. In case the server uses ddsi as the networking service, ddsi first must match readers and writers before communication can take place. If the server sends a response to a request, but ddsi has not yet discovered the reader to deliver the response to, then ddsi will drop the request. To prevent this from happening the server must either ensure that the reader has been discovered before sending the response, or send back a error indicating that no reader was discovered in time. Solution: The server know contains functionality to detect whether the reader of a client has been discovered.
OSPL-7348 | userClock is missing from the configurator. userClockService is not a service but an option for a domain in the configuration. The tag userClockService is confusing. Solution: The configuration tag userClockService is now changed to userClock. The old tag userClockService is still supported for backwards compatibility, but will result in a warning in the info log that a deprecated tag is used.
OSPL-7716 / 15848 OSPL-7708 / 15846 | Sometimes a RETCODE_ERROR was reported during the processing of a dispose_all_data request. When the durability service contained a sample with a newer timestamp than the timestamp for the dispose_all_data request, it would decide to exclude the newer sample from the dispose request. Its return status would clearly communicate that decision, but this was wrongfully interpreted as an unspecified error. Solution: The interpretation of the return status of the durability service has been corrected, and will no longer consider the exclusion of samples newer than the dispose_all_data request as an unspecified error.
OSPL-7733 | Premature deletion of a writer may cause that DDSI drops data when client-durability is used. When a client sends a historical data request to a server, the server is expected to deliver the response in the partition specified in the request. For that reason the server creates a writer, publishes the data, and destroys the writer again. If ddsi has not yet taken the data before the writer is destroyed then the data will not be delivered. To prevent this situation premature deletion of the writer must be prevented. Solution: The writer is cached for some time before it is being deleted. This gives ddsi sufficient time to take the data.
OSPL-7775 | ISOCPPv2 union generation from idl can fail. The generation of an IsoCpp2 union from an idl will fail if a) the union has char as switch type b) it has a default case and c) it is build on a platform on which char is unsigned by default and signed-char compiler flag is not used. The result can be a wrongly initialized union class, an ncompilable generated header file or an idlpp crash. All these problems were caused by the fact that idlpp expected the minimum and maximum values of a char to be -128 and 127 respectively. This is untrue when the char is unsigned. Solution: Maximum and minimum values of a char are now dependent on its default sign-ness.
OSPL-7782 | Memory leak using Java5 DDS API DataReader.Selector. Whenever a DataState or Content filter was applied to a Selector, an underlying ReadCondition got created. The ReadCondition had native resources associated with it and would only be freed when the DataReader associated with the Selector got deleted. This could lead to a serious increase of memory usage and eventually result in an OutOfMemoryError in case new Selectors were allocated frequently i.c.w. setting a DataState or Content filter. Solution: In case of just a DataState, no ReadCondition is allocated. This also improves performance of the Selector. Additionally, the finalizer of the Selector frees native resources associated with a ReadCondition now (only applicable if a Content filter is applied). Finally, the Selector implementation has been made thread-safe as well by returning a new Selector object every time a setter method is called.
OSPL-7785 / 15959 | JVM crash during deletion of data reader or data writer. A mistake in the reference counting of basic types in the code constructing samples of the built-in topics for the user_data, group_data, topic_data and partition name settings could eventually cause the freeing of a basic type that is supposed to remain in existence during the operation of the domain. Use of this type in subsequent operations could then cause a crash. The issue could only occur when these QoS are set to a non-empty value. Solution: The reference counting for these cases has been corrected. Note that the issue is not limited to Java and that the crash can also occur in situations other than deleting a data reader or writer.
OSPL-7794 | ISOCPP2 dds::core::Time::operator > and < are broken The > and < operators on dds::core::Time in the ISOCPP2 API are not working properly due to an incorrect algorithm for comparing the nanoseconds part. Solution: The internal algorithm has been fixed to make the operators work properly again.
OSPL-7808 | ISOCPPv2 domain_id function returned default_id The isocpp2 'dds::domain::DomainParticipant::domain_id()' function returned 'org::opensplice::domain::default_id()' when a the DomainParticipant was created with default_id. The DomainParticipant delagate kept a copy of the domain_id which was used during creation iso requesting the actual domain_id from the underlying core. Solution: The 'dds::domain::DomainParticipant::domain_id()' function now gets the actual domain_id from the underlying core.
OSPL-7822 | Possible crash due to double free in listener. The listener has a thread that waits for events and dispatches them. After dispatching, the events are freed. Events are also freed before dispatching when the source entity was destroyed in the meantime. It was possible that these events of the destroyed entity were still be handled and thus freed a second time. Solution: Fixed the wait for events loop.

## 6.6.0p4

Report ID. | Description
--- | ---
OSPL-7761 / 15836 | Illegal time is reported repeatedly when the native networking service is used. On some Windows platforms the native networking service does not serialize the source timestamp of the messages correctly, which causes the receiver to read an incorrect timestamp and will report the illegal time error. This is caused by a code construction i.c.w. an optimalisation made by a compiler in the order of parsing the second and nanosecond part of a messaged. This causes the seconds and nanoseconds to be sent on the wire in the wrong order. Solution: The code that serializes the source timestamp is changed to ensure that they are parsed in the correct order.

## 6.6.0p3

Report ID. | Description
--- | ---
OSPL-6481 | Launcher can not load User defined Files. When a user creates their own deployment xml file (e.g %OSPL_HOME%\etc\config\My_ospl.xml), Launcher can not load it and can therefore not apply it. Even if you stop the Launcher and you restart it, it does not see the new xml file. Solution: Updates to the user-specified configurations field in the directory setting panel, to the OSPL_URI field in the environment settings panel will trigger a refresh of the configurations list in teh Configurations page. Added a new Refresh button on the Configurations page. If the Refresh button is pressed, then the configurations list is rebuilt using OSPL_URI, user specified configurations directory, OSPL_HOME\etc\config directory. Duplicates are removed if they exist in more than one of these locations.Notifications added to warn users if a configuration no longer exists when trying to edit it or set it as default configuration.
OSPL-7664 | Memory leakage when using group coherence with volatile topics. Every group coherent transaction leaked memory as the EOT message, as opposed to other transaction message, created a new group owned transactionGroup which never became complete and was therefor never removed. Solution: Prevent EOT messages from creating group owned transactionGroups for volatile topics.
OSPL-7700 / OSPL-7714 / 15845 | Group coherence data possibly wrong during discovery. When group coherent data was written and not all writers had been discovered yet via builtinTopics it was possible data wrong data was flushed or data was never flushed as the mechanism for determining the completeness of a group was flawed. Solution: The mechanism for calculating completeness has been reworked so correct completeness can be determined.
OSPL-7728 / 15854 | Memory leakage on Waitset time-out. When monitoring shared memory using mmstat, it could be seen that v_proxy objects were leaking away every time a WaitSet timed out. Solution: The leak has been solved.
OSPL-7737 / 15858 | XML parser does not allow reference to DTD. The new XML parser introduced in V6.6.0p1 did not allow references or attributes that started with a '!' so that references to the DTD like <!DOCTYPE ...> would result in a validation error. Solution: Tag names and attribute names that start with '!' will no longer automatically result in validation errors.

## 6.6.0p2

Report ID. | Description
--- | ---
OSPL-5834 | Host side binaries included in target RTS installers Host side RLM binaries, rlm, rlmutil and pristmech were being included in target RTS installers unnecessarily. Solution: RLM binaries, rlm, rlmutil and ADLINK are no longer included in target RTS installers.
OSPL-7082 / 14835 | Tuner tool hangs when reading large sequences or arrays. The tuner tool can take a a few minutes when reading samples that contain large sequences or arrays. It is not responsive during that time. Solution: The performance of C&M (which the Tuner tool uses) is improved considerably by using StringBuilder instead of Strings where keys an values are concatenated and by adding happy paths to searches.
OSPL-7641 | Group coherence not working when used during discovery. When a group coherent writer starts publishing data before/during creation of the group coherent reader it was possible that no group coherent data was received during the livecycle of the reader. The transaction mechanism had an invalid (too high) writer count, because the discovery based on PublicationInfo and EOT message both increased the count for the same writer, the count is used determine if a transaction is complete and can be delivered to the reader. Because the count was too high the transaction never became complete and thus the transaction was never delivered to the reader. Solution: Updated the internal administration so that when a writer is discovered via PublicationInfo it removes it from a list so that the EOT message cannot add the same writer.
OSPL-7646 / 15812 | Issue with register_service in Java RMI with duplicate services. The register_service call of the Java binding of RMI did not properly check for duplicate services. When a particular service-name is already registered, the call would return true without considering the instance-id and class parameters. Solution: The behaviour was fixed by returning false when a service is registered with a name that already exists, but a different instance-id or class.
OSPL-7661 / 15813 | Unregistering of report plugin not done sufficiently. Participant creation failed after 10 registered report plugins due to incomplete cleanup on unregistrations and a hard limit of 10 plugins. Solution: Limits on number of report plugins are removed and unregistering report plugin has been improved.
OSPL-7673 / 15816 | Compiler warnings caused by idlpp-generated cpp code. C++ code generated by idlpp leads to warnings when compiling the code. Solution: Improvements to idlpp templates and code-generation (to remove unnecessary casts, among others) can result in compiler warnings regarding signedness of comparison operands. The signedness of length variables in generated code for sequence-of-sequences was changed to an unsigned type so the warning does not occur.

## 6.6.0p1

Report ID. | Description
--- | ---
OSPL-7610 | Durability crash when fellow running pre-V6.6 version is present The durability service contains a mechanism to determine compatibility with other durability services, which could be other versions with a different set of features. A flaw in this mechanism causes the durability service to crash when it receives a sample-request from a durability service with a pre-V6.6.0 version. Solution: The mechanism was improved to be more robust
OSPL-7557 | SOAP service not allowing connections in SP-mode Connecting any tool to a SOAP service, that is running as part of a single-process DDS application, fails with the error report that a participant could be created. This is due to a change in the SOAP service where it passed on an empty domain URI internally to prevent an extra unnecessary parse of the configuration file. Solution: The SOAP service now always passes on the full URI and domain id in all cases.
OSPL-7564 | Change default installdir/windows start menu for Vortex V2 For Vortex_v2 the directory/start menu structure must change. All Vortex products should now install into the same structure. The version number is the version of that product and has no leading "v". For OpenSplice the structure must be: ADLINK/Vortex_v2/Device/VortexOpenSplice/<version> Solution: The new structure has been applied.
OSPL-7565 | Durability crash when more than 2 roles present For each name space, durability maintains information about the various roles it has merged with. The way this set is represented could cause a crash when more than 2 roles were used in the system. Solution: The representation has been fixed.
OSPL-7616 | Interoperability problem with RTI Connext 5.2.0 DDSI2 is quite strict in its checking of the values it receives in the discovery messages, which can from time-to-time result in interoperability problems. With Connext 5.2.0, RTI appears to have appropriated part of OMG-reserved namespace for a new extension in the discovery data, DDSI2 flags it as invalid and discovery fails completely. Solution: DDSI2 now accepts unrecognised values unless the "pedantic" mode for StandardsCoformance has been selected.
OSPL-7630 | Coherent transaction shared memory leakage For every coherent transaction a kernelModuleI::v_transactionPublisher and child objects leaked in shared memory. Solution: Memory is now freed.
OSPL-7631 | Possible deadlock when using coherent transaction When an end-of-transaction (EOT) message was the only message in the resend list the 'end_coherent_changes' function could deadlock. The resending of an EOT message did cause 'end_coherent_changes' to re-evaluate its conditions. Solution: Resending EOT messages now causes 'end_coherent_changes' to reevaluate it's conditions.

## 6.6.0

Report ID. | Description
--- | ---
OSPL-139 | Retention-period for purging unregistered instances is too long and non-configurable Currently theres a fixed 5 seconds 'retention period' after which unregistered instances are actually deleted/memory-freed. The 'artefact' that this retention period prevents is the unwanted resurrection of unregistered-instances in case of out-of-order reception of network-traffic. The current value of 5 seconds is so long that its not hard at all to run out of the default 10 MB shared-memory segment if you create/delete instances in a rapid pace. Solution: A new option RetentionPeriod is added to the domain configuration (OpenSplice/Domain/RetentionPeriod). This option specifies how long the administration for unregistered instances is retained in both readers and the durability service before it is definitively removed. The default value is 500 ms
OSPL-5395 / 13742 | The dispose_all_data() (resp. on_all_data_disposed()) method is not supported under ISOCPP The dispose_all_data() (resp. on_all_data_disposed()) method is not supported in the ISOCPP, but must be supported in its successor ISOCPP2. Solution: The ISOCPP2 API now supports this feature.
OSPL-6338 | ISOCPP streams API may drops samples silently when flush of stream fails. The flush operation of the isocpp streams API will perform a write operation of the underlying datawriter. The write operation on this datawriter may return a timeout because of expiry of the reliability.max_blocking_time associated with this datawriter, which is default set to 100 ms. For example this may occur because of network congestion. In that case the sample are silently dropped. Solution: When the flush operation on the stream fails, because the underlying datawriter write operation returns a timeout then a timeout exception will be thrown. Also the append operation will throw a timeout exception when the append results in a flush operation that times out. The samples will not be dropped and will be sent when the application retries the flush operation.
OSPL-6436 / 14446 | Errors in generated Modeller code. C++ code generated for IDL where the same module scope was repeatedly opened and closed would be ordered such that all of the code for each module would be grouped together. This could lead to the generated code being invalid due to datatypes being used before they are defined. IDL generated by the Modeller application could be sensitive to this issue. Solution: C++ code is generated with a module scope structure corresponding to the IDL source.
OSPL-6808 | Java5 DDS API lacks support for proprietary DomainParticipant operations. The Java 5 API was missing support for the proprietary delete_historical_data() and create_persistent_snapshot() operations on a DomainParticipant for the Java 5 DDS API. Solution: The 2 missing operations have been added to the Java5 API.
OSPL-6943 | 1st and 3rd implementation of dds::domain::discover function potentially clash.s When invoking the 1st implementation of dds::domain::discover with 2 parameters (so time-out becomes default parameter), the function clashes with its 3rd overloaded implementation, which also has 2 parameters and which is preferred by the compiler. Solution: 3rd implementation of dds::domain::discover has been renamed to dds::domain::discover_all.
OSPL-6954 / 14900 | The concurrent handling of a terminate signal and cleanup performed by the application may cause a crash. When a termination signal is handled, which tries to detach the application entities from shared memory, and concurrently the application is performing a cleanup of the DDS entities a crash may occur when the signal handler tries to access memory that is already freed. Solution: A reference count is added to the objects that can be freed concurrently when the application is detaching from shared memory.
OSPL-7035 / 15067 | NullPointerException when using Java RMI API during shutdown. When RMI is used and a request is done during shutdown of the application it is possible that a NullPointerException can occur in the handleRequest call. Solution: The handleRequest function is adjusted so the NullPointerException will not occur anymore.
OSPL-7095 | Reader snapshot in Tuner returned incomplete history and provided unreliable sample info. The reader snapshot feature from the tuner did not present reliable sample info, in particular the sample, view and instance states could not be trusted. Moreover, the snapshot only showed a single sample per instance, rather than the full history in case of KEEP_ALL or KEEP_LAST n with n > 1. Solution: These issues have been addressed.
OSPL-7101 | Handling of leading/trailing white-space in configuration file. In the OpenSplice XML configuration-file, leading and trailing whitespace in configuration directives was not handled consistently. The raw value was stored, leaving the possibility for different services to interpret it in different ways. Solution: Whitespace is now trimmed from all configuration elements (not attributes) to get a consistent behavior, even though it doesn't strictly adhere to the XML specification, it is what most users expect.
OSPL-7109 | The default value of the durability StoreSleepTime is 2.0, it should be 0.0. In case data needs to be persisted, the StoreSleepTime and StoreSessionTime control the rate at which data is stored. In particular, the StoreSleepTime is intended to prevent that the thread that is responsible for persisting data eats up too much CPU time. The default used to be 2.0 seconds. This may potentially cause unnecessary delays. Since in many use cases persisting data will not cause a resourcing problem, it makes more sense to use a default of 0.0 seconds instead 2.0 seconds. Only if it turns out that the persistency thread takes up too much CPU time a non-zero value should be used. Solution: The default value for StoreSleepTime is set to 0.0 seconds.
OSPL-7130 / 15176 | Problem with listener notification at startup in ISOCPP API When creating an entity with a listener and events that should be notified to the listener occur immediately, they may not when using the ISOCPP DDS API. Solution: The ISOCPP DDS API is now deprecated and has been replaced by the ISOCPPv2 DDS API that does not suffer from the problem. Users who suffer from the issue should migrate to the new ISOCPPv2 DDS API.
OSPL-7198 / 15368 | Enum c_collKind elements are named too generic. The elements of c_collKind are named quit generic (f.i. C_LIST). This can conflict with customers' variable naming or their 3rd party libraries. Solution: The elements have been renamed by prefixing them with the OSPL_ prefix.
OSPL-7202 / 15365 | If a write with timestamp of a new sample is done after an unregister of the instance but with a timestamp before the unregister, this new sample is not received the reader Due to the unregister the communication path between the writer and reader(s) was destroyed, causing the write of the new sample being discarded. Solution: In case a write with timestamp is done after an unregister with a timestamp before the unregister, bypass the normal communication path and write directly to the reader(s).
OSPL-7210 / 15373 | Defining multiple protobuf messages in a single proto file fails for isocpp2 For each protobuf message in a proto file that is annotated to be used in DDS, the proto compiler back-end generates the required underlying trait when using the isocpp2 API. In case of multiple 'DDS-enabled' message structures, the generated traits end up in the same file, which is ok, but the surrounding ifdef's are the same for each traits. This leads to exclusion of all generated traits except the first, which on its turn leads to an invalid argument error when trying to use the trait at run-time. Solution: In case of multiple traits the ifdefs are only done once and surrounds the complete set of traits.
OSPL-7228 / 15377 | Creating Topics using ISOCPP2 with non-topic types results in cryptic error reports With the ISOCPP2 DDS API, templates and traits are used to deal with type-specific structures. This requires a pre-processing step that generates traits for data-structures that need to be published/subscribed in DDS. Whenever an attempt is made to create a Topic for a type without a trait, the code still compiles due to the fact a template exists. At run-time though, the creation fails due to the missing trait and this results in an exception being thrown (Note: the missing trait can also be caused by not including the correct header file in your application. The "<type>_DCPS.hpp" is the correct one to include). The fact that an exception is thrown is correct, but the corresponding error message is very cryptic and needs to be improved. Solution: The error message has been modified to "Topic type without traits detected. This can happen by using a non-topic type or including the wrong header file."
OSPL-7234 / 15376 OSPL-7336 / 15432 | The durability service may crash when not all namespace from a fellow are received and another fellow disconnect. The role of a fellow is set when all namespaces of that fellow are received. When another fellow is disconnected the namespace administration of all fellows is checked to see if the disconnected fellow was not an aligner. A crash occurs when the administration contains a fellow for which the role is not set. Solution: When the first namespace of fellow is received the role of that fellow is also set.
OSPL-7250 | Unable to terminate StreamDataReader applications. The get() method on a StreamDataReader can cause applications to block for a significant amount of time if a large timeout is supplied and no data is being delivered to the reader. Solution:A new method named interrupt() has been added to the StreamDataReader. Calling this method causes any threads blocking on get() to unblock immediately and return control to the application. For an example of using this method in a termination handler, please see the Streams Throughput example.
OSPL-7256 | Waitsets on Java API (classic and Java 5) would sometimes not unblock when the middleware is shutdown. Due to an error in handling the list of conditions, the check done to detach from a single domain might come up empty, causing the waitset to remain blocked. This was particularly likely on 64-bit platforms. Solution: The list of conditions is now passed correctly, causing the unblock to properly work.
OSPL-7263 | Isocpp2 can generate garbled information in exceptions. A few calls to isocpp2 would produce somewhat unclear reports and/or exceptions when they fail. Solution: The creation of exceptions and report stacks has been improved.
OSPL-7284 / 15404 | Unexpected and incomplete native log report. Some logs are written in the OSPL native report system in spite of the configuration SuppressDefaultLogs=True. Also, the information in the native log and report plugin are incomplete. Solution: The tracing functionality is improved regarding checking of SuppressDefaultLogs and regarding traces copying when SuppressDefaultLogs=True.
OSPL-7288 / 15399 | String <NULL> given as value to report plugins When the reporting functionality fails, it can generate "<NULL>" for certain information within the report. Reports are provided to report plugins by means of XML. This will clash, because the value "<NULL>" can now be seen as an XML tag. Solution:Generate "NULL" instead of "<NULL>" in a report functionality error situation.
OSPL-7293 | Crash in RnR service during remove-replay command containing transformations While processing a remove-replay command containing transformations, the RnR service could potentially crash due to memory corruption. This does not occur when replay is stopped by other means, i.e. by stopping a scenario or reaching end-of-storage. Solution: The issue was caused by a double free and fixed by improving the transformation cleanup.
OSPL-7303 | The secure networking service cannot find the security element in the configuration file. The secure networking service reads the security settings from the Security element in the configuration file. The XPath expression used to find the Security settings is incorrect. It tries to find the Security element under the NetworkService element instead of the SNetworkService element. Solution: First try to find the Security element under the SNetworkService element. When the Security element cannot be found under the SNetworkService element then the Security element is searched under the NetworkService element in order to be backward compatilble, in that case a deprecated warning is logged.
OSPL-7313 / 15414 | DDSI2 ExternalNetworkAddress error in a multicast configuration. The presence of the DDSI2 ExternalNetworkAddress option in a multicast configuration was deemed an error and DDSI2 would terminate during startup. Solution: Reduce the presence of DDSI2 ExternalNetworkAddress in a multicast configuration to a warning and ignore its value.
OSPL-7318 / 15416 | The durability service configuration parameter maxWaitCount is parsed incorrectly. The durability service configuration parameter maxWaitCount is not correctly interpreted. This may cause that the check performed by the durability service for the attachment of the networking services to a particular group may timeout to early. When that occurs the group involved is ignored. When this particular durability service has been selected as master for that group it will not align this group to the other nodes. Solution: Calculate the correct timeout value from the configured maxWaitCount.
OSPL-7337 / 15433 | DDSI configuration with SSM allowed and ASM disallowed causes attempts at sending to 0.0.0.0 A DDSI configuration that enables SSM but disabled ASM should (initially) send participant discovery (SPDP) packets to the explicitly configured peers only. Internally this is realised by setting the SPDP multicast address to the unspecified address (:: or 0.0.0.0), but enabling any form of multicasting caused the unspecified SPDP address to no longer be recognised as such, and hence to be considered a required destination for SPDP packets. This in turn caused the log to fill up with error messages, but was otherwise harmless. Solution: The error in the processing of the addresses has been fixed.
OSPL-7338 | Report 'no append' feature improvements. When using the <Report append="false"/> configuration in shared memory mode on Linux, only the traces of the last started process will be present in the log files. Also, the log files remained untouched until a process opened the log files. This means that the error log was sometimes not in sync with the info log file. Lastly, the OSPL_LOGAPPEND environment variable was not handled correctly. Solution: Delete stale log files as soon as OSPL_LOGAPPEND=false or <Report append="false"/> is detected. Only the first process (spliced or single process) is allowed to do the deletion.
OSPL-7341 | A durability configuration with aligner set to false may miss data on reconnect. A federation with a durability service which has the configuration aliger set to false (alignee) didn't receive data published during a disconnect after a reconnect when the master durability service does not detect a master conflict. The alignee detected a master conflict and assumed the master would raise its state while the master saw no conflict and has no reason to raise its state. Solution: The alignee now requests the latest state from the master when it recovers from a disconnect during which it had no master.
OSPL-7368 / 15476 | For the ISO C++ mapping the idlpp compiler generates incorrect code for a typedef of an array. When the idl specification contains a typedef of an array then the code generated by the idlpp compiler for the ISO C++ mapping is incorrect. In that case it partly generates typedefs for the array alias which are usually generated for the C++98 mapping. Solution: A condition is added to the idlpp compiler when generating code for a typedef of an array which checks if the code has to be generated for the ISO C++ or the C++98 mapping.
OSPL-7376 / 15469 | Idlpp generates sequence alloc functions twice when compiling different idl modules which contain a definition of a sequence of a type specified in another module. When different idl modules specify a typedef of sequence of a type which is defined in another module or the specify a typedef of a sequence of a basic idl type then the corresponding alloc and allocbuf functions are generated twice by the idlpp preprocessor. For example when two modules each specify "typedef sequence<long> LongSeq" then the corresponding DDS_sequence_DDS_long__alloc functions are generated twice. Solution: For sequence definitions the generate sequence alloc and allocbuf are prefixed with the scope name of the module in which they are defined.
OSPL-7445 | Cannot build ISOCPP custom lib on Windows On Windows the custom_lib for isocpp would fail to build due to an import/export conflict with the classic C++ API on which it was built. Solution: That conflict has now been resolved.
OSPL-7469 | Java5 DCPS API TopicQos.withPolicy() methods don't copy policies from original TopicQos The witPolicy() methods on the TopicQos are meant to return a copy of the original TopicQos with only the policies supplied as arguments to be overridden compared to the original TopicQos. The implementation returned the default TopicQos with the supplied policies overridden per supplied argument(s), but not using the original TopicQos as source meaning that non-overridden policies would be default instead of the value in the original TopicQos. Solution: The algorithm has been modified to use the original TopicQos as source instead of the default TopicQos.
OSPL-7480 / 15640 | ISOCPP C++11 should use defaulted functions. Since C++11, defaulted functions are introduced. But older Visual Studio versions did not support it completely. Constructors and assignment operators are generated by idlpp for these compilers. However, the compiler detection regarding this issue was not correct, resulting in all non-VS C++11 compilers using the generated functions. Solution: Compiler detection is improved so that all C++11 compilers that support defaulted functions actually use them.
OSPL-7527 | Invalid handle error in isocpp2 when getting an status from an entity When requesting an status from an entity which needs an instance handle and the status has not yet occurred results in an invalid handle error on isocpp2. Invocations of the offered/requested_deadline_missed() functions on Writer and Reader in the ISOCPP2 API would crash when no such event ever occurred before the invocation. Solution: That crash has now been fixed.
OSPL-7528 / 15653 | TimeoutException in ISOCPP2 should not be recorded in ospl-error.log The TimeoutException in ISOCPP2 should bot be recorded in the ospl-error.log, since it might result in massive amounts of undesired log messages in normal scenario's. Solution: When a TimeoutError occured, it would show up in the ospl-error.log file causing potentially lots of undesired messages in there since a timeout scenario can be totally valid and is by no means an inherent error. For that reason any TimeoutError is no longer logged into the ospl-error.log file.
OSPL-7533 | Alignment of durability service with aligner=false configuration by late joining master with persistent data intermittently fails When a late joining durability service with aligner=true configuration (master) joins a system with running durability services with aligner=false configuration (alignee) it could happen that the alignee nodes did not get alignment data from the master node. The alignee node detected a master conflict when the master node arrived and when it tried to resolve the conflict this intermittently failed because the master wasn't always ready to align. Solution: The alignee node now triggers a master conflict when the master is ready to align.
TSTTOOL-164 | Builtin topic filters do not take into account all CM* topics. If the user preference Hide Builtin (DCPS*) is set to true, the following topics would still be unfiltered: CMPublisher, CMSubscriber, CMDataWriter, CMDataReader. Solution: The filter pattern has been adjusted to filter out all DCPS* topics and all CM* topics. The preference page label has also been updated to reflect that.
TSTTOOL-207 | Partition combo boxes in Tester's AddReader Dialog does not always show all existing partitions If user starts Tester with the "ospltest" command (instructing Tester to automatically connect on startup to ospl target using JNI), it is possible for some existing partitions to be missing from the partition comboboxes in AddReader, AddReaders and AddTopic Dialogs. This behavior is more prominent, the more partitions there are. Solution: Tester's Partition Manager is now created before any of its dependent components to ensure partitions are properly managed and available right at connection time.
TSTTOOL-332 | Mismatch in handling of unbounded character sequences between script send and script check. In a scenario script, given a topic that has an unbounded sequence of characters in its type "cseq", the following script code would fail the check:
    send test_SimpleCollectionTopic (
    cseq[0] => a,
    cseq[1] => b,
    cseq[2] => c
    );

    check test_SimpleCollectionTopic (
    cseq[0] => a,
    cseq[1] => b,
    cseq[2] => c
    );
Passing in indexed parameters for unbounded character sequences is accepted for send, but not for check. Solution: The check instruction can now accept indexed parameters for unbounded character sequences
TSTTOOL-336 | New example Tester scripts needed to show how to manipulate the Record and Replay service. Solution: Composed some new example scripts that define record and replay scenarios, configures a storage, then allows to start and stop the scenarios on demand. They are now a part of the suite of example scripts.

## 6.5.2p1

Report ID. | Description
--- | ---
OSPL-7425 | Support for armv7-marvell-linux-gnueabi-hard Port for Ubuntu 14.04 64 bit host to Ubuntu 14.04 for custom ARM V7 board using Marvell Armada 385 processor and armv7-marvell-linux-gnueabi-hard_i686_64K_Dev_20131002 compiler

## 6.5.2

Report ID. | Description
--- | ---
OSPL-7134 / 15140 | Idlpp (cppgen) created ambiguous enum mutators. Idlpp (cppgen) generated both a value mutator and an r-value reference mutator for enum types. These mutators conflict when compiling. Solution: Idlpp (cppgen) will not generate the r-value reference mutator for enum type anymore.
OSPL-7155 | Failing group coherence on reconnects. During reconnect tests we discovered failures in the discovery of matching writers causing updates never to become complete. Solution: Improved discovery mechanism which solves several use cases of failing group coherent updates during discovery phase of communication end points.
OSPL-7160 / 15268 | Conditions cannot handle const functors. The different kinds of isocpp2 Conditions only supported non-const functors. This particularly caused problems when using lambda functions. Solution: Added support for const functors.
OSPL-7227 / 15378 | Multiple definitions of copy-routines in code generated by protoc gen-dds back-end The protoc-gen-dds back-end generates code to allow .proto messages to be transparently published/subscribed. When using multiple messages originating from different .proto files in a single application, some code gets duplicated causing symbols to be defined multiple times and linking of compiled code to fail. Solution: The offending code has been moved to a separate file, which is included by all files that use the construction instead of duplicating it in each file.
OSPL-6802 | A new merge policy called CATCHUP is available. This merge policy is similar to the already existing REPLACE merge policy, but the resulting instance states may differ. When nodes get disconnected their historical data sets may diverge. To recover from divergent states once the nodes get reconnected again, the durability service has defined various merge policies. One of these merge policies is the REPLACE merge policy. The REPLACE merge policy dispose and replace all historical data by the data set that is available on the remote node. Because all data is disposed first, a side effect is that instances whose state did not change will still be marked as NEW after the merge. For some use cases it is undesirable that instances which have not diverged are still marked as NEW. For that reason a new merge policy called CATCHUP is available now. Solution: The CATCHUP merge policy updates the historical data to match the historical data on the remote node by disposing those instances that are not available any more, and adding and updating all other instances. The resulting data set is the same as that for the REPLACE merge policy, but without the side effects. In particular, the instance state of instances that are both present on the local node and remote node and for which no updates have been done will remain unchanged.
OSPL-7106 | When durability terminates while persisting samples, a sample can be lost. When persistency is enabled, the durability service is responsible for writing samples to the persistent store. If durability terminates while writing samples to the persistent store, it may occur that a sample that has recently been extracted from the persistent queue but not stored yet, gets lost. Solution: The check to decide whether durability should terminate can now only occur before taking a sample from the persistent queue and after it has been written to the store, but not in between. This ensures that a sample that has been taken from the persistent queue will always be persisted.
OSPL-7093 | When a merge policy is applied, private groups are accidentally aligned. When a merge policy is applied, merge data must be requested from the master. It turns out that also data for private groups is requested when a merge is about to take place. This is not needed, as private groups are by definition local groups, and data for these groups should never be merged. Solution: When a group is marked as a private group, no data for that group will be requested anymore.
OSPL-7136 | Improved handling of nested GPB messages during proto files compilation. The compilation of nested GPB messages could cause compiler crashes when handling multiple proto files and/or proto files without the package keyword. Solution: The parsing part of the GPB compiler has been improved and made more robust.
OSPL-7153 | When durability terminates while a merge conflict is pending to be resolved, memory may be leaked. When a merge conflict is detected, the durability service creates a conflict object and stores it in a queue. A conflict resolver asynchronously takes conflicts from the queue and tries to resolve them. In case a conflict object is pending in the queue and the durability service terminates, pending conflicts in the queue are NOT destroyed. This may lead to leakage of the conflict object. Solution: When durability terminates any pending conflicts in the queue are cleaned up.
OSPL-7189 / 15316 | Networking receive thread can spin at 100% following a disconnect/reconnect The RT networking service keeps track of a list of ACKs waiting to be sent. The code to cleanup this list following a disconnect contained an error that could corrupt the list if packet loss had occurred just before the disconnect. Solution: the cleanup is now robust against packet loss.
OSPL-3817 | The idlpp preprocessor crashed when when the idl specification contains a sequence of a typedef of sequences. The idl preprocessor handles a sequence of a typedef of sequences incorrect which results in a crash of the preprocessor when it tries to parse such a construction. This caused by a missing condition in the preprocessor when it tries to pass this construction. Solution: The missing condition is added to the idlpp preprocessor to handle the sequence of a typedef of sequences correctly.
OSPL-4403 | Corrupt RnR storage when using a storage type that doesn't match contents of existing file Two RnR storage backends are available: XML and CDR. When configuring a storage, either by publishing RnR config commands or in the OpenSplice configuration file, it's possible the data files already exist on the filesystem and contain data recorded during a previous session. When the recorded data is in XML format, it's possible to configure a new storage to use CDR format, or vice-versa, and append new samples to the storage in a different format than those recorded earlier. This corrupts the storage and it will not be usable for replay. Solution: The issue was resolved by adding verification of attributes when existing files are found. Changing a storage in a way that conflicts with existing files is no longer allowed.
OSPL-7060 / 15088 | When OpenSplice is stopped an application may remain blocked on the WaitSet.wait operation. When an application is waiting in the WaitSet.wait operation and at that moment OpenSplice is stopped with the 'ospl stop' command or the spliced daemon is killed, then the WaitSet.wait operation will never return. This may occur even when the wait is performed with a timeout value. Solution: When the application is attached to the shared memory segment a callback is registered. When the spliced daemon which controls the shared memory segment is terminated the callback will be triggered. The callback detaches the application from the shared memory segment and triggers the WaitSet.wait to return OK together with the list of conditions that were detached from shared memory. When performing an operation on one of the returned conditions, ALREADY_DELETED will be returned.
OSPL-7090 | Publishing multiple RnR commands at once may result in some commands being rejected by the service An issue in the ordering of commands received at the same time, may cause commands to be rejected if they depend on each other. For example a config-command that defines a storage must be processed before an add-record command that uses this storage, or the add-record command would be rejected because the storage is undefined. Solution: The issue was resolved by processing the commands in the same order as they are delivered to the service.
OSPL-7126 / 15106 | Crash of watchdog thread on VxWorks RTP shared memory deployments The VxWorks support for shared mutexes and condition variables does not match the POSIX pthreads behaviour required by OpenSplice core, with the OpenSplice abstraction layer translating between the two. Because of an issue in the abstraction layer, reuse of a shared memory address for a mutex could result in different processes using different VxWorks kernel mutexes. This in turn caused race conditions and, under some circumstances, crashes. Solution: the abstraction layer has been updated to not dissociate the mutex names from the kernel mutexes, thereby ensuring that all processes always agree on the kernel mutex to use.
OSPL-7141 / 15185 | Crash when getting IsoCpp null listener. Calling the listener getter function in IsoCpp when no listener was set, will cause a crash because it tries to use a null pointer. This null pointer is of an internal object that is created when a listener is attached. Solution: A check is added to the getter functions that will return null when the internal data object is null, meaning that no listener was set.
OSPL-7142 / 15187 | First few samples written after discovery of a remote node not delivered Data is forwarded from the local writers (i.e., those attached to the same shared memory as the networking service in a shared memory deployment) only when the RT networking service has detected remote nodes, with some additional safeguards for data written while the system is starting up. When the first remote node was discovered, services (and applications) on the local node were informed of this event before the forwarding was enabled, which could cause data to be lost. A typical symptom is that the durability service fails to make progress. Solution: forwarding is now enabled before the existence of the remote node is announced.
OSPL-7151 | Error registering a non-scoped type in Java Attempting to register a type without a scope (so module-less) using the Java API no longer worked due to internal algorithm that simply assumed that each type was scoped. Solution: The internal algorithm has been modified to check whether the type that is registered has a scope.
OSPL-7189 / 15316 | Networking receive thread can spin at 100% following a disconnect/reconnect The RT networking service keeps track of a list of ACKs waiting to be sent. The code to cleanup this list following a disconnect contained an error that could corrupt the list if packet loss had occurred just before the disconnect. Solution: the cleanup is now robust against packet loss.
TSTTOOL-296 | Sample Display view and Check script instruction incorrect when char sequence field followed by field with same initial prefix. If a topic data type contains a string field (or a character sequence or array) followed by another string field whose field name starts with the field name of the previous field, then the internal data model would mistakenly concatenate both fields into one field. Solution: The string field concatenation involving similarly named fields has been fixed.
TSTTOOL-314 / 15087 | Tester bounded sequence fields always send the max length of the sequence. When Tester writes out a sample containing a bounded sequence, it always populates the full sequence length with values. Solution: The tool has been modified to only allocate sequence elements for elements that are actually defined, instead of allocating the full length with defaults first. NOTE: sequence elements must be defined in index order in a script. eg. send aTopic(seq[0] => 1, seq[1] => 1); is valid, while send aTopic(seq[1] => 1, seq[0] => 1); is not.

## 6.5.1p1

Report ID. | Description
--- | ---
OSPL-6616 / 14697 | Lack of reliability for first few packets on a channel can lead to unexpected behaviour Loss of the first few packets on a channel was not always detected and corrected. In case these packets belonged to the durability protocol for example, this could lead to unexpected behaviour. Solution: The reliable protocol is extended to support (re)transmitting packets to nodes that have not yet responded. Information about these nodes is shared across channels, so that when a single channel discovers reliable communication with a node on a NetworkPartition, all channels will. Furthermore, receiving nodes wait until they received the oldest packet they should receive before starting delivery of data.

## 6.5.1

Report ID. | Description
--- | ---
OSPL-4153 | Durability to support compression for KV-persistence The durability service currently has a KV-persistency implementation that allows persisting data to disk in either SQLite or LevelDB. Testing performance indicates that the disk is the bottleneck when trying to achieve a high throughput in some use cases. Therefore it should be possible to compress data when persisting. Solution: Samples can now be compressed by durability before persisting them (and obviously uncompressed before re-publishing them in DDS). Durability supports compression as a configurable option for KV persistence. For more details on how to configure it, please check section 4.3.3.9.3 of the Deployment Guide
OSPL-6519 | Durability service may not detect disconnecting federation The durability service could in some situation miss a dispose of DCPSHeartbeat, causing it to think that a remote federation is still running. That on its turn may prevent correct alignment of historical data. Solution: The algorithm that checks whether the DCPSHeartbeat is disposed has been corrected.
OSPL-6950 | DDSI2 not utilizing latency budget shorter than 1s The interface between the OpenSplice kernel and the networking services implements the latency budget, but requires the networking service to make a trade-off between idle wake-ups and efficient handling of short latency budgets. The DDSI2 service opted to have few idle wake-ups, but at the cost of essentially treating a latency budget setting < 1s as if set to 0s, which differs significantly from the RT networking service that puts the cutoff at 10ms by default (The RT networking service has useful work to perform in the idle wake-ups, hence the different trade-off). It should be noted that a high-rate writer typically manages to have some data in the network queue at all times, in which case it is not the latency budget that drives packing, but the sheer amount of data. Solution: DDSI2E now allows configuring this using the Internal/Channels/Channel[@name]/Resolution setting (similar to the RT networking setting). The default is unchanged.
OSPL-6984 | DDSI2 possible use-after-free following end_coherent_updates DDSI2 may find itself forced to grow a message buffer when sending an end-of-transaction commit message, which may result in the message header being relocated in memory. This could lead to the setting of a flag in the message header in freed memory. Solution: It now recomputes the address of the message header.
OSPL-6985 | Crash due to refcounting issue in large group-transactions The publishing side in group transactions larger than 50 writers may crash because of a refcounting issue in enlarging the group transaction administration. Solution: The refcounting issue has been fixed.
OSPL-7013 | DDSI2 limits max deployments on a node that are discoverable via unicast When DDSI2 tried to allocate a participant index when Discovery/ParticipantIndex = "auto", it limited itself to indices 0 .. 9. In practice, this meant that running more than 10 (single-process) deployments on a machine required multicast discovery and the ParticipantIndex option set to "none". The amount of unicast discovery pings sent out periodically is directly related to the maximum, which argues in favour of a small limit. However, it should provide a way of configuring a higher limit in cases where this is required. Solution: A setting has been added, Discovery/MaxAutoParticipantIndex, which configures the highest index to be tried automatically.
OSPL-7032 | C&M API does not allow creation of Publisher with one ore more non-default immutable policies The C&M API is internally creating a publisher as enabled and tries to apply the QoS afterwards. If any of the immutable policies are immutable, this fails. This prevents tools from creating publishers with non-default values for immutable QoS settings. The implementation should create the entity disabled, set the qos and then enable the entity. Solution: The C&M API now creates the publisher in disabled mode, sets the QoS and enables the publisher.
TSTTOOL-298 | Protobuf feature for Tester does not account key and filterable fields with name overrides. If a .proto data definition contains FieldOptions with "name" defined to override the name of the member in DDS, then Tester doesn't recognize it, and subsequently fails to read those fields. Solution: The feature now finds all the DDS specific FieldOptions defined in the protobuf metadata to find the real names of the key and filterable fields, and properly translates them between sample data view in tool, and sample reading/writing at middleware.
OSPL-7027 / 14930 | 100% CPU Usage network service when resending locally rejected samples When a local datareader uses resource limits and runs into these resource limits, the networking service may go to 100% load when attempting to re-deliver a sample that is rejected due to the fact that the maximum resource limits have been reached. Solution: The networking service now reschedules the delivery of a sample to a datareader for the next resolution tick instead of attempting the re-deliver in a busy-wait loop until it is delivered.
OSPL-7052 | Unmatching Qos messages in ospl log and remote group detection for client durability. The durability service uses various topic definitions for the implementation of the client-durability feature. The qos values for the max_blocking_time and lease_duration for these topics should be same as the defaults in the DDS specification, but due to a bug this was not the case. When a client generates a topic that does use the default qos values, a warning would appear in the ospl log file. Furthermore, the client durability server did not detect the creation of non-volatile writers on remote nodes. Consequently, the client durability server would not collect and align the data written by these writers. Solution: The durability service has changed the qos values for the topics related to the client-durability feature, so that the max_blocking_time and lease_duration qos values now conform to the DDS specification. Also, the durability service now detects the creation of non-volatile writers on remote nodes so that the server is able to collect and align the data written by these writers.
OSPL-7089 / 15092 | DURATION_ZERO_SEC and DURATION_ZERO_NSEC notation not recognized by QoSProvider. The QoSProvider does not recognize the DURATION_ZERO_SEC and DURATION_ZERO_NSEC time values defined in the XML syntax. Solution: The missing time values are now correctly parsed.
TSTTOOL-301 | Writing octal character codes in c_char fields in script scenarios fails validation. As of OpenSplice V6.5.0p7, a feature was introduced in Tester where values punched in to sample field parameters in a scenario script send or dispose command underwent a validation on execute to ensure that the typed in value fits in the known IDL type for that topic. The validation failed to consider the case for IDL char fields where octal character codes of the form was used as input. Solution: Script validation of topic fields of IDL type "char" now allows for values of the regex form \\[0-3][0-7][0-7] eg. a valid send instruction: "send aTopic(aCharField => '\000');"

## 6.5.0p13

Report ID. | Description
--- | ---
OSPL-5473 | Shared memory leak during alignment Implicit disposes weren't delivered for builtin topics, causing leakage in shared memory. There is a small chance other topics could potentially leak as well, but it was never observed. Solution: The implicit (internal) flag is now part of the equation to find duplicate messages.
OSPL-6284 / 14504 | Durability service fails to update service lease An issue in the durability service could result in a spinning thread during alignment of data from other durability nodes. The spinning thread triggers internal safety mechanisms, eventually preventing the service from updating it's service-lease which causes the spliced process to consider the service crashed or deadlocked. Depending on the configured failure-action, spliced may decide to terminate or restart all OpenSplice services. Solution: The cause of the spinning thread has been resolved.
OSPL-6519 / 14561 | Incorrect processing of DCPSHeartbeat by spliced and durability The durability service could in some situation miss a dispose of DCPSHeartbeat, causing it to think that a remote federation is still running. That on its turn may prevent correct alignment of historical data. The spliced thread responsible for processing the DCPSHeartbeat topic and thus monitoring the liveliness of other nodes in a domain, could get stuck reading old data. Depending on configuration (i.e. realtime thread priorities) this could result in unreasonably high CPU usage preventing other threads from running. This means the liveliness monitoring of other nodes is not reliable and removal of a node can possibly go unnoticed by the spliced processes on other nodes in the domain. Solution: The algorithm that checks whether the DCPSHeartbeat is disposed has been corrected in durability and spliced is now skipping data that has already been processed.
OSPL-6683 / TSTTOOL-208 | Tooling version compatibility constraint. Vortex OpenSplice Tester and Tuner need to connect to and read the necessary information present in C&M API minimum version of 6.5.0. Solution: When using C&M API to connect to a remote Vortex OpenSplice DDS system, a minimum version compatibility of 6.5.0 is now enforced in order to connect between local and remote.
OSPL-6992 | Some cross development installers are not built for the correct architecture. In some cases where the host machine is 64 bit in a cross-development environment, the installer would be generated for a 32 bit host. On a subset of machines without 32 bit compatibility libraries the installer would not run. Solution: The installer generation logic has been updated to build for the correct architecture.
OSPL-7010 / 14926 | Deadlock while terminating during initial alignment of durability. Durability did not notice a fellow being removed during initialization causing the initial alignment loop to be infinite. Solution: The durability service now checks if a fellow is still alive before deciding to wait for the communication state to change.
OSPL-7015 / 14928 | C# API sample marshalling issues The C# API was having problems marshaling samples that had an attribute that was a sequence of a sequence and of demarshaling a sample that had an attribute that was a sequence of strings. Solution: Both issues have now been fixed.
TSTTOOL-261 | As a user I would want to see reason for failure of QOS compatibility in Tester Tester does not how reasons for failure of QoS compatibility. Solution: Display reasons of incompatibility from the tooltip when highlighted as incompatible reader.
TSTTOOL-272 / 14761 | Slow sending of large strings from Tester Tester executed non-linear code when sending strings, char sequences and char arrays. A 'send' instruction that contained a string of about 10K characters would take several minutes to complete. Larger strings took exponentially longer. Solution: Code was reworked so that send behaviour is now no worse than linear with the string size. Casual observations suggests that a send is close to constant time. Typical send times for strings up to 64K characters where observed to be in the 30-60 ms time frame.

## 6.5.0p12

Report ID. | Description
--- | ---
OSPL-5473 | Small memory leak in DCPS api listener dispatcher for C and C++. The list of observables monitored by the listener dispatcher leaked. Solution: Create the list object at creation instead of on the fly.
OSPL-6867 | Historical data that was requested by a client using the client-durability feature could only be delivered to a single, fixed partition instead of the partition preferred by the client. When the durability service receives a request for a client for historical data using the client-durability feature, the historical data could only be delivered to a single, preconfigured partition. Some use cases require the data to be delivered to different partitions. For this reason it is now possible to deliver the historical data to the partition requested by the client. This feature only applies to client-durability, the behaviour between durability services is not affected. Solution: Clients for client-durability can now specify the partition to receive historical data on a per-request basis.
OSPL-6947 | Tools and SOAP service may crash. A piece of memory may be freed to soon when deleting proxy entities, like our tools do (potentially through a SOAP connection). This leads to free memory leads that can cause the tools or SOAP service to crash. Solution: The memory corruption has been solved.

## 6.5.0p11

Report ID. | Description
--- | ---
OSPL-6900 / 14883 | Leak of global references in Classic Java PSMs. A global reference was created for some Java classes related to DDS entities such as DomainParticipantImpl, TopicImpl etc. These references were never deleted so a class instance would leak every time an entity is deleted though the corresponding DDS calls like factory.delete_participant or participant.delete_topic. Solution: The issue was resolved by deleting the global reference when an entity is deleted.
OSPL-6896 / 14878 | Durability crash during alignment. When durability is used and during alignment of a fellow, the fellow disconnects durability could crash. Solution: The alignment functionality is adjusted so that this crash cannot happen anymore.
OSPL-6797 | DDSI2 needs to support multicast on platforms that incorrectly declare multicast unsupported. DDSI2 relies on the network interface capabilities it reads from the operating system kernel to determine whether or not multicasting is supported on the selected interface, but some platforms do not mark the interface as supporting multicasts even though it does in reality. The workaround of setting the flag manually on the interface requires elevated privileges, which is not always acceptable. Solution: An option Internal/AssumeMulticastCapable is now available in DDSI2, which can be set to a comma-separated list of interface name patterns (i.e., including ? and * wildcards) that are assumed to be multicast capable.
OSPL-6889 / 14875 | Crash of spliced during termination while application(s) still running. Normally when the spliced process is terminated, application participants have already detached from the shared database so the database can be removed and OS resources reclaimed during spliced termination. However it is also possible that applications are still running when spliced is terminated. In that case the database will be detached and OS resources can only be reclaimed after the last application participant has also detached from the database. An issue could lead to a crash during spliced termination in the latter case. Because the database is detached but not removed, another spliced thread would try to access it resulting in undefined behaviour. Solution: The issue was resolved by preventing the offending spliced thread from accessing administration data during termination stage.
OSPL-6912 / 14885 | DDSI2 can mismatch sockets and participants in "many sockets" compatibility mode. DDSI2 can operate in a compatibility mode in which each participant gets its own socket, in which case there is no requirement to include an explicit destination address in messages intended for just one participant, but the mapping from socket to participant could be done incorrectly. That results in the wrong participant being addressed, which typically results in dropping a message, but could also lead to data being considered acknowledeged when it fact it hadn't been. The problem is only known to occur when interoperating with TwinOaks CoreDX product. Solution: The mapping has been corrected.
OSPL-6909 / 14886 | Deadlock during durability exit. When durability is terminating it could end up in a deadlock when terminating its internal listeners. Solution: The listener termination mechanism within durability is adjusted and the deadlock cannot occur anymore.
OSPL-6894 / 14876 | The u_domain object is not freed causing a memory leak The u_domain object was not freed even though no other object had a reference to it. Solution: When the last participant is freed and thus all the references to the u_domain object are release the u_domain object is freed.
OSPL-6419 | Possible crash in C++ when calling find_topic and deleting participant in other thread When having a deplicated C++ participant and one thread blocks in a find_topic while the other deletes the participant a crash could occur because the domain was unaware of the deletion of the kernel participant object. Solution: The domain is now aware that the deletion of the kernel participant object.

## 6.5.0p10

Report ID. | Description
--- | ---
OSPL-6781 / 14838 | Possible deadlock during durability clean up. When delete_contained_entitites is called it is possible that durability could end up in a deadlock. Solution: The clean up mechanism of durability is adjusted so this deadlock cannot occur anymore.
OSPL-6707 | Perc JVM error when using waitsets. When using the Perc JVM in combination with waitsets an error occurs: java.lang.NoSuchMethodError: get_trigger_value. Solution: The error is fixed and will not occur anymore.
OSPL-6555 / 14568 | OpenSplice installer could fail when installing OpenSplice as service. When installing OpenSplice as service and the Microsoft Visual C++ Runtime redistributable is not installed on the system the installation could fail. Solution: The installer is adjusted to install the Microsoft Visual C++ Runtime redistributable before installing the service.
OSPL-4466 / 12862 | C# examples give warnings. When opening the OpenSplice C# example project files warnings with the text 'Load of property 'ReferencePath' failed' occur. Solution: The project files are adjusted so this warning will not occur anymore.
OSPL-6759 / 14832 | Typographical error in ospl traces. The durability service contained a typographical error in the traces. Solution: The typographical error is corrected.
OSPL-6839 / 14865 | Warning during termination of cmsoap service. When the cmsoap service is exiting a warning message "Received termination request, will detach user-layer from domain." in the info log can occur. The cmsoap service wrongly registers 2 exit handlers. Both of them are executed when the service is requested to terminate and eventually both do the same thing under the hood. The exit handler registration is adjusted and now only one handler is registered for the cmsoap service which also removes this warning message.
OSPL-6519 / 14561 | Incorrect processing of DCPSHeartbeat by spliced. The thread responsible for processing the DCPSHeartbeat topic and thus monitoring the liveliness of other nodes in a domain, could get stuck reading old data. Depending on configuration (i.e. realtime thread priorities) this could result in unreasonably high CPU usage preventing other threads from running. This means the liveliness monitoring of other nodes is not reliable and removal of a node can possibly go unnoticed by the spliced processes on other nodes in the domain. Solution: The issues were resolved by skipping data that has already been processed.

## 6.5.0p9

Report ID. | Description
--- | ---
OSPL-6541 | Tuner doesn't show entity-relations in the partition view The Tuner tool no longer shows entity-relations when selecting the 'partition' view. Solution: An internal algorithm to find dependant entities has been modified to support partitions again.
OSPL-6591 / 14606 | OSPL waits 10 seconds before exiting with a wrong report plugin When OSPL is started and a configured reportplugin is missing OSPL always waits 10 seconds before exiting. Solution: OSPL now directly exits and does not wait 10 seconds anymore.
OSPL-6628 / 14751 | SIGKILL on an application with listeners terminates OpenSplice in an unexpected way. When SIGKILL is used on an application which uses listeners OpenSplice terminates with a message that it could not properly clean up its resources. Solution: There was a problem in the listener cleanup mechanism. This is now fixed and all resources are now properly cleaned up.
OSPL-6682 / 14763 | The ospl tool help for return code 16 is incorrect. The ospl tool help says "not available" instead of "non existent" for code 16. Solution: Non-existent is now also reported in the ospl help for code 16.
OSPL-6743 | The calculation of a key hash for a key type that is 8-bytes could lead to a crash. The client-durability feature calculates a md5 key hash for topic keys that do not fit in 16 bytes. The hash calculation for an 8-bytes type key contained an error, leading an invalid key. Access to such key could lead to a crash. Solution: The hash calculation is changed so that the correct hash is calculated.
OSPL-6748 / 14821 OSPL-6760 / 14833 | Old sample erratically rejected causing weird resending behaviour. Due to an issue with handling the case that an old sample is not stored in the reader because there is already newer data available (KEEP_LAST), a writer (or service) would begin to retry delivering that sample. As long as the state of the reader/instance doesn't change, this will continue to behave wrongfully. Solution: The proper return-code is now returned, causing the sample to be accepted instead of rejected.
OSPL-6690 | Incorrect use of the '#' character in the RTNetworking protocol for topic-/group-coherency Due to a bug in the handling of transaction-markers in the RTNetworking protocol, partition-names starting with a '#' could cause problems. Solution: The processing of transaction markers in the RTNetworking protocol has been fixed. If coherency with access_scope V_PRESENTATION_TOPIC is used on a build since V6.5.0p5, this will not interoperate with this fix included and an upgrade must be performed to get the bug resolved.

## 6.5.0p8

Report ID. | Description
--- | ---
OSPL-6687 | When a sample request is received from an unknown fellow the durability service can crash When a sample request is received from an unknown fellow, the response that is generated contains flawed data which could cause the durability service to crash. Solution: The response now contains valid data so that the receiving durability service does not crash anymore.
OSPL-6685 | DDSI2 may "hang" reading from a socket When DDSI2 was configured to use only a single unicast port, it would attempt to read two packets from the socket corresponding to the unicast port when signalled that data was available. Usually, a packet would arrive in short order, but if it didn't happen DDSI2 would appear to hang (stop processing messages, fail to terminate properly). Solution: It now only reads when data is known to be available.
OSPL-6588 / 14609 | ExitRequest handler interferes with Java shutdown hook The exit request handler that OpenSplice installs runs before the JVM runs the shutdown hooks. This causes a problem for an application that tries to do some clean up when the JVM shuts down due to failing DDS operations in Java with ALREADY_DELETED as result. Solution: For Java OpenSplice now does nothing for the posix signals SIGHUP, SIGINT and SIGTERM and windows signals CTRL_C_EVENT and CTRL_BREAK_EVENT before the JVM runs the shutdown hooks. This way an application can still do some clean up. After the application clean up the JVM will then trigger the OpenSplice clean up.
OSPL-6622 / 14699 | Possible NULL pointer dereference could cause durability service to crash on segmentation fault Removal of a fellow assigned NULL to the request member of a chain object. This could cause the durability service to dereference a NULL pointer, causing it to crash with signal 11. Solution: Upon removal of a fellow the request member of a chain object is now copied. This fix ensures the request member is properly freed if the reference count of a chain object reaches zero.
OSPL-6662 | API call create_persistent_snapshot execution time When API call create_persistent_snapshot is called it will take always at lease one StoreSessionTime to execute. This could lead to extra or less data in the snapshot than would be expected. Solution: The snapshot will now be executed as soon as possible and will not wait at least one StoreSessionTime.
TSTTOOL-180 | Difficult to send amended topic instances in OpenSplice Tester Tester scenarios in which a topic instance is sent, and then repeatedly amended and resent were tedious, and error prone to write, as each send instruction had to repeat all sample fields, even if only a few had changed. Solution: A new 'update parameter' (composed of the topic name followed by _update) is now accepted by the send instruction. If the update parameter is present, the sample data sent will be preserved by the topic reader. At most one sample per topic instance is preserved. If the update parameter's value is 'true', then the sample to be sent is initialized from the previously preserved sample for that topic instance, provided the topic reader has retained it. In all other cases, the sample to be sent continues to initialized from topic defaults. If a send instruction without the update parameter sends a sample, then the topic reader clears the saved sample data for the topic instance sent. Disposing the reader clears all retained sample data for that topic.

## 6.5.0p7

Report ID. | Description
--- | ---
OSPL-3824 | C&M API cannot handle array of arrays, array of sequences, sequence of arrays and sequence of sequences The serializer contained bugs that caused the proper elements not to be found. Solution: Serializer now uses proper name generation functions where applicable and simplified retrieval of user data elements.
OSPL-5245 | Write of c_char field would fail on writing certain characters to ospl log files The log contained error messages when writing certain special characters, even though the write would actually succeed for some of them. Solution: Fixed a case in the serializer where memory would be released twice, stop write on validation errors, and fixed scanning for octal sequences
OSPL-6141 / 14430 | Deadlock in signal handler on trapping synchronous signal in signal handler The signal handler would deadlock if a synchronous signal was caught by the signal handler thread itself. Solution: The signal handler will not try to gracefully handle a synchrounous signal trapped by the signal handler itself.
OSPL-6156 | In order to retrieve historical data on a node a durability service must be configured. For nodes with limited resources running that still want to acquire historical data a full-fledged durability service may not be desirable. Until now, if a late joiner wants to receive historical data, the late joiner must run a fully-fledged durability service. If the late joining device runs on a platform with limited resources, running a fully-fledged durability service may not be desirable. Instead of running a full-fledged durability service, an alternative way to acquire historical data whilst being on a platform with limited resources has been implemented. This feature is called client-durability. Using client-durability, a client can send out a request for historical data to a durability service that implements the client durability protocol. The server will then provide the requested data to the client. To enable the client-durability protocol in a durability service the Opensplice/DurabilityService/ClientDurability[@enabled] must be set to true. More information is available in the deployment manual. The client-durability feature is currently an internal feature of OpenSplice and not available for applications. Solution: An alternative approach to acquire historical data has been implemented that does not require running a fully-fledged durability service on the client node.
OSPL-6626 | Heap and SHM leakage when using the tester in combination with the Soap service When using the Tester in combination with the Soap service topic related heap and SHM leakage occurs. Solution: The topic leakage has been fixed.
OSPL-6490 | Crash of RnR service when storage path doesn't exist The RnR service would not allow creation of a storage in a non-existing path. This caused the service to publish a storage-status update to indicate the storage is in an error state, but a bug caused the service to crash shortly after updating its state. Solution: The behaviour was changed and the service will now create the required path if it doesn't exist. If the creation fails, i.e. due to permissions or a corrupt path name, the service updates the storage-status topic accordingly without crashing. A config command can then be issued to correct the path name and make the storage accessible to record and/or replay commands.
TSTTOOL-260 | No reliable way to recheck the last sample of topic instance in OpenSplice Tester Tester instructions such as check_last and check_any would not reliably find the most recent sample for a topic instance. Solution: A new instruction, 'recheck_last' was introduced. It's syntax is identical to check_last, but it's behaviour is different: recheck_last will always check the most recent sample received, where as check_last fails if that topic has already been checked by a previous instruction.
TSTTOOL-180 | No way to invoke a JavaScript without invoking another instruction in OpenSplice Tester The scenario syntax did not allow for the direct invocation of a JavaScript (or other script language). Instead, users needed to include the script as part of another instruction, such as the log instruction. For scenarios making heavy use of scripts, this was both inconvenient, and resulted in unnecessarily large log files. Solution: Scripts are now allowed in scenarios at the same level of as other instructions. The script must be enclosed in back quotes (`). The script invocation block (script enclosed in its back quotes) must be terminated by a semi-colon.
TSTTOOL-179 | OpenSplice Tester provides no feedback on data conversion errors Sending a sample which included invalid data (e.g. sending a floating point value to an integer field) were silently ignored. No entries were made in the Tester log. Solution: Tester now checks for invalid values, and creates appropriate log entries.
TSTTOOL-194 | OpenSplice Tester fails reading scenario files in some cases Tester would fail to start if it did not have permissions on all the folders containing the specified script and/or macro paths. Tester could open the wrong script/macro file if a backup copy with a tilde (~) appended to the full name was present. Solution: Tester correctly opens starts and opens scenario and macro files for which it has at least read access.

## 6.5.0p5

Report ID. | Description
--- | ---
OSPL-5888 | Listener scheduling QoS settings were not being honoured Listener scheduling QoS (changes) where not applied to the listener dispatcher thread. Solution: The QoS operations involved in setting and updating listener scheduling changes have been reworked and the listener dispatcher code was altered to be event based.
OSPL-6156 | For nodes with limited resources running that still want to acquire historical data a full-fledged durability service may not be desirable. Until now, if a late joiner wants to receive historical data, the late joiner must run a full-fledged durability service. If the late joining device runs on a platform with limited resources, running a full-fledged durability service may not be desirable. Instead of running a full-fledged durability service, an alternative way to acquire historical data whilst being on a platform with limited resources has been implemented. This feature is called client-durability. Using client-durability, a client can send out a request for historical data to a durability service that implements the client durability protocol. The server will then provide the requested data to the client. To enable the client-durability protocol in a durability service the Opensplice/DurabilityService/ClientDurability[@enabled] must be set to true. More information is available in the deployment manual. The client-durability feature is currently an internal feature of OpenSplice and not available for applications. Solution: An alternative approach to acquire historical data has been implemented that does not require running a full-fledged durability service on the client node.
OSPL-6194 | When there are many pending sample requests the durability service becomes very slow. The durability service internally keeps a list of pending sample requests. Each time a new request is received the durability service will traverse the list to see if there exists a pending sample request for the same partition and topic. If so, these requests will be combined. The algorithm to find if a request is already pending used an inefficient implementation, causing high CPU load and unnecessary delays in situations where the list of pending sample requests is very long. Solution: The implementation to see if a request is already pending now uses an optimized algorithm.
OSPL-6258 | Liveliness of a remote node not always consistent among services, built-in topics A number of independent heartbeat mechanisms were used in parallel, resulting in different parts of a single federation having short-term inconsistencies between their views of the set of live remote nodes as well as introducing dependencies between the configuration of services to ensure dependencies between the services (e.g., networking and durability) in removing a node were handled correctly. Solution: The mechanisms have now been consolidated.
OSPL-6272 | Networking bridge log verbosity The configurator contains a non-existent value 'finer' for the networking bridge tracing level verbosity. Solution: The value finer is removed from the configurator.
OSPL-6320 | Bind error when reconnecting after a network adapter does down and then up. When trying to reconnect after an ethernet adapter went from down to up a 'bind returned errno 22 (Invalid argument)' message could occur in the ospl-error log. Solution: The reconnect mechanism is adjusted and the error will not occur anymore.
OSPL-6332/ 14527 | ISOCPP listeners might reference invalided entities ISOCPP listeners used a raw pointer to reference DDS entities on stack that might have been invalidated. Solution: ISOCPP listeners now use a dds::core::WeakReference to keep a reference to DDS entities.
OSPL-6385 | Durability service internal algorithm to read protocol samples should be optimised The durability service creates datareaders to receive information from fellow durability services to align historical data. The internal algorithm to read this data, takes one sample at the time where taking all samples at once would be more efficient processing-wise. Solution: The durability service has been modified to take all available samples at once.
OSPL-6408 | Invalid default max_blocking_time for DataWriter with BEST_EFFORT reliability in ISOC++ API The ISOC++ API set the default Reliability.max_blocking_time to zero instead of 100 ms for DataWriters with BEST_EFFORT reliability. Solution: DataWriters now always have 100ms as default max_blocking_time no matter their reliability.
OSPL-6437 | Topic-access feature behaves unexpectedly When using the Topic-access feature unexpected errors can occur in OpenSplice because the builtin topics are also slaved to this setting. Solution: The builtin topics ignore the topic-access setting so OpenSplice will keep working.
OSPL-6454 | Installer crashes in text mode A fault with the third party installer creation program causes OpenSplice to crash when text mode is used Solution: The install cration program for OpenSplice was fixed.
OSPL-6477 | Default Secure Networking configuration files contain an error The default secure networking configuration files contained a fault which could lead to an error when loaded into the configurator. Solution: The fault is fixed and the configurator can load the file without errors.
OSPL-6488/ 14510 | Tuner problem when writing a bounded character array There was a fault in the tuner when trying to write a bounded character array. When the array is written the data was ignored. Solution: The array is not ignored anymore and the data will be written.
OSPL-6491 | Remove dependency on CORBA::string_dup in RMI Vortex Lite shares some of the RMI codebase, but does not support CORBA co-habitation. rmipp generates code that includes CORBA::string_dup that Vortex Lite does not support. Solution: rmipp changes to generated DDS::String_dup instead that is supported by both Lite and OpenSplice.
OSPL-6496 | Adding RMI support to operate without a durability service RMI services registration and discovery relies on Transient DurabilityQosPolicy as provided by a durability service in OpenSplice. In some specific deployment conditions, that service is not available. RMI should be adapted to support that use case. Solution:A new command line option called "--RMIDurability = yes | no" was added to indicate the availability of the durability service. Please refer to the RMI documentation for more details.
OSPL-6531/ 14566 | DDS-RMI OSGi bundle not exporting all required packages An issue in the manifest for the OSGi bundle of DDS-RMI, caused the bundle to be incompatible with application bundles that contain code generated by rmipp. Solution: The DDS_RMI.Impl packages were added to the Export-Package manifest attribute
OSPL-6640/ 14547 | Problem with license files The information to get a license is not accurate for the Windows platform in the getting started guide. Solution: The getting started guide has been updated to reflect the proper command on Windows.

## 6.5.0p4

Report ID. | Description
--- | ---
OSPL-6464/ 14412 | Semaphore handle leak on Windows An issue in the OS abstraction layer of the product caused a leak of semaphore handles. When a condition variable, used in many areas of the product i.e. when notifying a WaitSet or acknowledging a synchronous write, is triggered while no other threads are blocking on the condition, a shortcut is possible. However this shortcut contains a bug and leaks a semaphore handle. Solution: The issue was resolved by making sure the handle is closed in all circumstances.

## 6.5.0p3

Report ID. | Description
--- | ---
OSPL-2967 | Deadlock in Java listeners Terminate from within a listener callback required a new Thread from within the callback and call System.exit() in that thread. Solution: The additional thread is no longer required.
OSPL-5684 | Reference guide update for SchedulingQosPolicy The reference guides did not mark SchedulingQosPolicy as ADLINK proprietary property. Solution: Minor updates to guides only.
OSPL-3936 | DDSI2 memory leak when retransmitting part of a fragmented sample because of retransmit queue limiting When DDSI2 attempts to retransmit a fragmented sample, but reaches the retransmit queue limit at the first fragment, it can leak one HeartbeatFrag message. Solution: Memory leak fixed.
OSPL-4471 | Configurator does not support fields other than string values to contain environment variables The configurator does not support fields other than string values to contain environment variables i.e. ${DOMAIN_ID} Solution: The configurator does now support environment values for every input type except enum types and booleans. However Enum types/boolean environment variables are supported by all services so by editing the configuration file manually it still can be used.
OSPL-5557 | Starting Tester in an environment where the data types for OsplArrayTopic and OsplSequenceTopic were already registered, caused errors to be printed in the ospl error log. Tester tries to register its topic types on startup. However, due to a slight change in the way the meta type is defined internally, if the topic types were registered previously, then trying to register them again caused a meta type mismatch error. Solution: The XML meta type definitions for OsplArrayTopic and OsplSequenceTopic have been updated. The error no longer appears.
OSPL-5575 | Begin/End Coherent Changes API calls did not return the correct return code in case of a failure. When using the Begin/End Coherent Changes API calls it was possible that an incorrect return code was returned. Solution: The calls now return a correct return code as per spec.
OSPL-5739 | When there are other users running OpenSplice then the command "ospl stop -a" may fail. The ospl stop -a command may fail when there are other users running OpenSplice. The ospl stop -a command tries to open all key files associated with the running OpenSplice instances. When it cannot open a key file because it belongs to another user the ospl stop -a command stops and reports an error. Solution: When the ospl stop -a command walks over the key files and finds a file it cannot open it should not stop and instead continue parsing the next key file.
OSPL-6030 | Java OSGI Support Only the standalone Java language binding had an OSGi compliant jar file. It was a separate jar file called dcpssaj-osgi-bundle.jar. Solution: The following jar files are now OSGi compliant: dcpscj.jar, dcpscj5.jar, dcpssaj.jar, dcpssaj5.jar, ddsrmi.jar and rlm.jar. These OSGi jar files can still be used as 'normal' jar files. No extra separate OSGi jar files needed. Only dcpssaj-osgi-bundle.jar is maintained for backwards compatibility.
OSPL-6192 | Incomplete error messages A review of error log output across the OSPL APIs has been completed and a number of reports have been improved.
OSPL-6285/ 14506 | Non terminated AsyncReplyWaiter threads in case of concurrent asynchronous methods invocations When the application invokes multiple asynchronous requests concurrently, multiple threads called AsyncReplyWaiter are created and not terminated by the runtime stop operation. The AsyncReplyWaiter thread is the thread that waits for asynchronous replies and dispatches them to the user asynchronous reply handlers. There should be only one AsyncReplyWaiter thread per process that is terminated at runtime stop. Solution: The AsyncReplyWaiter thread creation has been properly synchronized to avoid creating multiple AsynchReplyWaiter threads.
OSPL-6286/ 14507 | RMI asynchronous reply handler may be called back for an invalid reply This may happen when the rmi server stops running for some reason. If a client issues an asynchronous request after that, it may receive an invalid reply including random values. Solution: The RMI asynchronous reply has been updated to process only valid reply topics samples.
OSPL-6323 | Durability can deadlock on discovering an unclean shutdown of a remote fellow There are various ways in which the durability service can discover that a remote fellow no longer exists, and under most circumstances will detect this by the absence of a heartbeat. There are however some other ways that are only rarely used, and one of these would result in a deadlock in durability, and in such a way that it would have significant consequences for the rest of the federation. Solution: This deadlock has been fixed.
OSPL-6351/ 14533 | Shared memory monitor sometimes couldn't find specifyied domain name Shared memory monitor couldn't properly compare domain names because of trailing whitespace. Solution: Updated keyfile parser to trim lines before analyzing them.
OSPL-6352/ 14532 | Warnings when compiling c++ header files with-Wignored-qualifiers using gcc 4.8.2 When compiling code with OSPL c++ include headers files with the -Wignored-qualifiers compiler flag warnings show up. Solution: The c++ include files now compile without warnings when -Wignored-qualifiers is set.
OSPL-6371 | Unable to use Foo type name in classic C++ PSMs Compilation errors occur when building code generated by idlpp, if the application idl specifies a type named Foo. This type is also used internally, leading to name clashes with existing classes and methods. Solution: The issue was resolved by using fully scoped names in idlpp templates. This ensures the classes from the DDS::OpenSplice namespace are used instead of the application namespace.
OSPL-6387/ 14539 | Attaching conditions to a waitset during a wait could cause a crash Due to an error in the administration of the waitset, a crash could occur if the internal administration of the waiset grew to contain over 32 conditions while waiting on the waitset. Solution: The error in the administration has been resolved.
OSPL-6402/ 14542 | Wrong directory path in windows PATH variable When installing OpenSplice on Windows and choosing to let the installer set the environment variables the installer adds a non existing directory path (%OSPL_HOME%/host/lib) to the PATH variable. Solution: The installer does not add the non existing directory path anymore.
TSTTOOL-203 | Tester unable to handle bounded and unbounded arrarys and sequences of characters. Solution: Tester now properly reads in and write to the DDS, field data of bounded and unbounded arrays and sequences of characters. This feature is fixed in both the sample editor dialog (in the UI) and the scripting engine.
OSPL-6431 | An API_INFO report message is reported in the ospl-error.log but should be reported in the ospl-info.log. When an API_INFO report message is reported in the context of an API call then the API_INFO report is mistakenly reported in the ospl-error.log instead of the ospl-info.log. Solution: When an API_INFO message is reported the ospl-info.log file is selected instead of the default ospl-error.log.

## 6.5.0p2

Report ID. | Description
--- | ---
OSPL-5859 / 14325 | Durability alignment may require larger amount of shared memory than expected During the alignment process, the durability service may collect historical data from multiple sources and these sources may (partly) have overlapping sets of historical data. When these data-sets are received, durability needs to filter out the duplicates and once all data from all sources has been received, republish the set locally. Due to an issue in a durability algorithm, the duplicates where only filtered out at republishing time and not on reception time, causing an temporary, but unnecessary, need for a larger amount of shared memory. Solution: The flaw in the durability algorithm that filters out duplicate samples on reception has been repaired.
OSPL-5930 / 14351 | Invalid configuration of networking service not detected at startup and causing a crash at termination. In case the networking service is started with a missing or invalid configuration, the service would still run but a connection with other nodes is never established. At termination the service could crash on freeing internal administration related to configuration parameters. Solution: The service will now refuse to start when mandatory elements of the configuration, such as channels, are missing or invalid. An appropriate report is logged to the error log.
OSPL-6083 | iShapes example readers should be created with INFINITE latency-budget QoS To allow demonstrating (the effects of changing) LATENCY_BUDGET, the readers should be created with an infinite latency-budget as this is a RxO Qos. Solution: readers are now created with INFINITE latency-budget.
OSPL-6176 | Durability may report error if no persistent data exists on disk The durability service may report the error 'Unable to resolve persistent data version.' during start up when there is a topic definition on disk already, but no data yet. Solution: The error is now no longer reported under these particular circumstances that are deemed valid.
OSPL-6279 / 14503 | All XML documents received by registered report plugins start with an error element All XML documents received by registered report plugins started with an error element instead of using a string representation of the report type passed when generating the report Solution: The string representation of the report type is now properly used to start and end the XML document
OSPL-6280 | A non-OpenSplice reliable writer does not to deliver data to an OpenSplice best-effort reader using DDSI when on the OpenSplice side RnR is enabled. As RnR was using a reader with private QoS setting named QoS matching relaxing to receive both best-effort and reliable data. DDSI implementations that didn't understood this setting saw the reader as a best-effort reader. When a sample was lost, the RnR reader would request a retransmit, as this is required for the reliable data. However, as the reader was seen as a best-effort reader by the writer, this retransmit request was ignored, causing the data to be never delivered. Solution: RnR will now create separate readers for each non-matching QoS setting (reliable/best effort and shared/exclusive ownership)
OSPL-6282 | iShapes GUI badly formatted The publisher buttons of the iShapes demo application are badly formatted compared to the rest of the interface. Solution: Fixed the formatting.
OSPL-6288 | User data QoS empty in participants discovered via DDSI2 An issue in the processing of the participant QoS caused the UserDataQoS to be empty for all remote participants discovery via DDSI discovery. This issue did not affect systems using RTnetworking. Solution: UserDataQos is now exchanged again during discovery.
OSPL-6297 / 14516 | Find topic timing behaviour incorrect The find topic method on a DomainParticipant has a timeout parameter that specifies the maximum blocking time to wait for the topic to appear. In certain cases the method would block for 100 ms too long, which can have a noticeable impact on the application when called often on topics that don't yet exist. Solution: The implementation was changed to never exceed the maximum timeout.
OSPL-6295 | Windows start menu entry needs to be moved The location in the start menu on Windows does not match other Vortex products and needs to move to 'PrismTech/Vortex OpenSplice' Solution: Moved start menu entry to requested location.
TSTTOOL-167 | Tester hangs and won't close if soap connection fails Ospl tester hangs when the soap connection fails due to an issue in an internal algorithm. Solution: Tester does not hang anymore when soap connection fails.
TSTTOOL-182 / 14349 | Ospl tester appears to lock up Ospl tester appears to lock up due to the fact in runs out of memory when consuming large amount of samples. Solution: Added new preference to limit number of samples kept per reader under File>Preferences>Settings>Max Samples Per Reader The preference only takes only integer values. Default value is "0" which means infinite number of samples kept.
TSTTOOL-184 / 14348 | New instance not automatically displayed in tester In Tester, if an application data writer has a QoS of autodispose_unregistered_instances set to false and then unregister_instance is called on a data writer for some instance, a sample reaches matching data readers with the no_writers state and is ignored. Solution: A new boolean option has been added in the Preferences menu under the Settings tab, called "Ignore not_alive_no_writers samples" and is set to true by default. If the option is set to false, then these specific samples will be displayed in Tester.
TSTTOOL-190 | Tester does not show Vortex Lite ishapes instances in its topology unless user disconnects and reconnects Tester's Reader/Writer Tables (in the Browser Section) does not show all partitions for readers/writers with more than 2 partitions. Solution: Updated Reader Info and Writer Info to retrieve all the available partition names from the user data and display them properly in the Browser tab.
TSTTOOL-191 / 14350 | No convenient way to select an existing partition Ospltest tool does not provide a convenient way to select an existing partition when creating a reader. Solution: User can now select from a list of existing partitions when trying to create a new reader.
TSTTOOL-192 / 14352 | Ospltest gives errors on startup The script directories are not included in the RTS installers. Solution: Updated scripts and install directories to fix these errors.
TSTTOOL-194 / 14443 | Tester Script and Macro paths The Tester does not have permissions for every file/folder within and below the path specified for its script/macro area it will not start. Solution: Tester is now updated to read files with extensions .sd, .md and .bd.
TSTTOOL-195 / 14447 | Ospl tester and marks being treated as failures If Tester is receiving a very large amount of samples, and a mark command is run, the execution of the command wants to iterate through the sample list to mark all the samples it needs to ignore. However, if this iteration does not complete before the next sample comes in from the data reader, then it can throw this exception. Solution: Fixed tester to add marks properly.

## 6.5.0p1

Report ID. | Description
--- | ---
OSPL-6250 | Java5 Protobuf example Build.bat script is not working The Build.bat file that is delivered to compile the Java5 Protobuf example contains a copy-paste error from the one derived from Linux. Solution: Bat file has been modified to allow compilation of the example on Windows
OSPL-6250 / OSPL-6263 / OSPL-6270 | Java5, ISO C++ and C# applications may crash on termination Applications using the Java5 DDS API may crash at termination time due to an issue in the automatic clean up procedure. Solution: The issue in the automatic clean up procedure has been fixed.
OSPL-6253 | ISOC++ listeners may be deleted to soon Applications using the ISO C++ DDS API may experience that entities have already been deleted during listener call backs. Solution: The entity deletion procedure now waits for potential listener callbacks to finish before deleting the entity.

## 6.5.0

Report ID. | Description
--- | ---
OSPL-1722 | Synchronous reliability not supported when using DDSI2 OpenSplice DDS' synchronous reliability feature was not supported using DDSI2 and resulted in timeouts on the writer side because one of the built-in endpoints needed for processing the acknowledgements could not be discovered by DDSI2. Solution: The built-in endpoint is now discovered by DDSI2 and synchronous reliability is now supported.
OSPL-3837 | Tuner generates error when starting with the -uri argument When the Tuner is started with the -uri argument, an error is generated in the error log file. Solution: The error is not generated anymore.
OSPL-4841 / 12996 | Crash in WaitSet_wait for Java application In some situations a java application could crash in a Waitset_wait. Solution: The java api language binding has been rewritten. With this new implementation the code causing this crash is not present anymore.
OSPL-4383 | Serializer serializes wrong double/float values when LC_NUMERIC is not equal to the default "C" locale. The LC_NUMERIC of the "C" locale is '.'. OpenSplice assumes doubles and floats to always have a '.' as LC_NUMERIC. But a few locales use a different LC_NUMERIC (like fr_FR and nl_NL use ','). The (de)serializing of doubles and floats is locale dependent and thus this LC_NUMERIC difference will cause problems when a different one is set on the system. Solution: Make double/float to/from string conversions locale LC_NUMERIC independent.
OSPL-5095/ 13095 | No convenient RMI API for non default DDS domain Most of the RMI features are available via the org.opensplice.DDS_RMI.DDS_Service class, but this class works on the default DDS domain only. Solution: The Java and C++ RMI API has been extended so that the RMI applications can use any DDS domain id in a convenient way. As the CRuntime object is tied to the used DDS domain, a new method has been added to that class with the following signature : DDS_ServiceInterface getDDS_ServiceInterface() The DDS_ServiceInterface provides all the convenient methods to register/unregister services, run/shutdown them, and getting service proxies on the runtime-specific domain id, as does the DDS_Service class for the default domain. You can find a detailed description of that interface in the RMI API reference documentation. So, to use a non default DDS domain for RMI invocations, the developer should, first, get a CRuntime object for the wanted domain id as follows (in java): CRuntime runtime = CRuntime.getRuntime(domain_id); DDS_ServiceInterface dds_Service = defaultRuntime.getDDS_ServiceInterface(); then, dds_Service can be used to make the usual actions for client and server RMI applications.
OSPL-5265 | idlpp -j package prefix not applied to module-less types idlpp package prefixes specified using the -j option were not applied to module-less types. Solution: The behaviour of idlpp changed in version 6.5 and prefixes are now properly applied.
OSPL-5329 | Windows installation path On 64bit windows version a 64bit version is installed in C:\Program Files (x86) Solution: The 64 bit installation directory is changed to C:\Program Files\
OSPL-5424 | Windows Registry Keys not cleared on uninstall Registry key entries in HKEY_CURRENT_USER under Software -> PrismTech -> OpenSpliceDDS -> Version were not cleared when uninstalling. This was due to a bug in the uninstaller that prevented it completing. This could result in a number of entries in the HKEY_CURRENT_USER if multiple versions of OpenSplice were installed. Solution: The bug in the uninstaller has been fixed and uninstall now completes correctly. The Registry key in HKEY_CURRENT_USER is now cleared for any new installations but it will not clear historical entries.
OSPL-5605 / 14105 | Unable to attach shared memory in Java8 applications on 64-bit Windows The OpenSplice shared-memory database needs to be mapped to the same address in all applications. On 32-bit and 64-bit Windows, the same default address is used. This caused problems with recent Java8 on 64-bit platforms, where the default address is already occupied by the JVM. Solution: The default address was changed to 0x100000000, to make the product work out-of-the-box on 64-bit Windows platforms that use a recent Java8 JVM. Note the address can be changed through the Domain/Database/Address configuration parameter when the default is unsuitable.
OSPL-5678 | Networking service crash when compiled with VS2012 The networking service encountered a VS2012 C Runtime bug that let it crash: https://connect.microsoft.com/VisualStudio/feedback/details/782889/ Solution: Don't call strftime() with "%Z" when compiled with VS2012.
OSPL-5697 | Declaring multiple RMI operations having the same name in different interfaces lead to compilation errors of C++ generated code Declaring two or more RMI operations with the same name in different IDL interfaces makes the compilation of the generated C++ proxy classes fails because of a duplicate typedef declaration. Solution: The RMI C++ code generator has been updated to declare the typedef in the scope of the related RMI interface proxy class instead of the global scope.
OSPL-5789 / 14287 | Wrong error code returned by ospl The error codes, returned by ospl, did not reflect the information within the usage help text of ospl. Also, extended error codes and a small behaviour change were required as well. Solution: The normal ospl error codes have been improved. Also, the extended error codes will be returned when using the -e option.
OSPL-5793 / 14284 | Error missing field initializers in the OpenSpliceRMI header file dds_service_sdk.h gcc compilation could warn or fails (with -Werror=missing-field-initializers option) about missing filed initializers for member "DDS::ReliabilityQosPolicy::synchronous" in the RMI header file "include/rmi/dds_service_sdk.h" Solution: The missing field initialization has been added.
OSPL-5832 / 14298 | Termination issues while listener callback in progress. The listener callback implementation contains in concurrency issues which were difficult to resolve due to the internal design limitations. Solution: The mechanism has been redesigned, moving control of the listener thread into the PSMs.
OSPL-5844 | DCPS Java 5 PSM does not use correct default domain id The internal default domainId is 0x7fffffff. In this case this domain id is used, the OSPL_URI environment variable is inspected and the domain id in there is used. The Java 5 PSM always uses 0 as default domainId. As a result setting OSPL_URI i.c.w. a non-zero domainId did not allow applications to create a DomainParticipant. Solution: In case no domainId is provided on creation of the DomainParticipant, OpenSplice checks the domainId in the OSPL_URI and uses the domainId specified there. This is not always 0 as specified in the Java5 PSM as default id. As our default config files that we ship always use 0, this is deemed acceptable behaviour.
OSPL-5848 / 14321 | The durability service can crash i.c.w. dispose_all functionality The durability service could crash due to a null-pointer dereference in an internal algorithm related to the dispose_all functionality. Solution: The internal algorithm has been modified to deal with dispose all properly as well.
OSPL-5847 / 14320 | Unable to read sample that complies to readcondition Due to a locking problem in the product, a read call could return NO_DATA while actually there is data available Solution: The issue has been resolved by adding a lock while freeing internal data
OSPL-5849 | The Java5 DCPS implementation does not handle infinite duration correctly in Waitset.waitForConditions calls. The Java5 DCPS implementation internally converts durations to a different representation. In the Waitset.waitForConditions() operations the conversion algorithm was incorrect. Solution: Fixed the conversion routine to deal with infinite durations correctly.
OSPL-5880 / 14330 | Crash of RTSM tool The RTSM tool fails to attach to shared memory and crashes on a segmentation violation due to a mismatch in the layout of internal data-structures. Solution: The issue was resolved and the code has been updated to prevent similar issues from occurring in the future
OSPL-5893 / 14333 | The durability service could crash when running out of shared memory The durability service did not check in all cases whether the allocation of a sample in shared memory succeeded. As a result it could dereference a null-pointer and crash. Solution: The durability service did not check in all cases whether the allocation of a sample in shared memory succeeded. As a result it could dereference a null-pointer and crash.
OSPL-5905 | Selecting a network interface for DDSI2 using the network address fails on Linux The comparison of the specified address and the network interface address failed to take the network mask into account. Solution: Code fix applied.
OSPL-5910 / 14339 | A valgrind memcheck analysis of certain functionality reports: Invalid read of size 4 The copy subscriber qos out function from the gapi subscriber is creating a normal string for the name in the qos. This should be a gapi object string, as it is also freed as an gapi object. Solution: The copy out function is now creating the correct gapi object for the string.
OSPL-5913 | Transport priority in built-in topics for remote writers always 0 when using DDSI The DDSI2 service generates built-in topics for the remote entities it discovers, but failed to correctly set the transport priority QoS in the CMDataWriter topic, leaving it at the default value instead. Solution: DDSI2 now sets the transport priority.
OSPL-5999 | Tuner corrupts OSPL_URI when used with argument -uri= When starting the Tuner with the argument -uri=$OSPL_URI the OSPL_URI would be overwritten by the tuner property file. Solution: The OSPL_URI is no longer overwritten.
OSPL-6053/ 14398 | Errors reported about lack of multicast capability by networking service, when no multicast communication is configured The networking service checks multicast support when a partition is added to it's internal administration. Even when the network-partitions are configured to use broadcast or unicast, the service still performs this check, leading to error reports when it determines multicast is not supported. Solution: The check was moved so it is only performed after determining the address is in fact a multicast address.
OSPL-6069 / 6079 14409 / 14412 | Missing RMI asynchronous replies in some cases and their memory cleanup In case of an OpenSpliceRMI Java application that invokes multiple asynchronous calls intensively, some of the asynchronous replies could be lost. Furthermore, every asynchronous request is uselessly kept in memory, which increases dramatically the memory footprint of the RMI server. Solution: A bug in the asynchronous replies management of Java OpenSplice RMI has been fixed. The Java RMI generated code has also been updated consequently. So, existing java RMI applications should re-generate their code using rmipp.
OSPL-6119 | DDSI can spontaneously change best-effort max_blocking_time DDSI tries to minimise the discovery traffic by leaving out all QoS's that are set to the default (this can be overridden using Compatibility/ExplicityPublishQosSetToDefault), relying on the peers' filling in the defaults again. The decision whether the reliability QoS was at the default value or not was not correctly accounting for the max_blocking_time part of it. Solution: Reliability QoS value now set correctly.
OSPL-6134 | Documentation links in RTS don't work Documentation links in the RTS installer don't work as the target files are not available. Solution: The RTS should not include the documentation, so it has been removed.
OSPL-6145 | RnR replay crash Whenever RnR replay had to wait for the resources to become available or for the networking services to be ready to accept data for a partition/topic combination introduced by the replay, RnR could crash. Solution: The issue has been fixed.
OSPL-6160 | RnR replay fails when topic definitions are provided by recording RnR does not store/inject topics automatically, instead requiring the user to record and replay the DCPSTopic topic. Replaying a topic definition means that the topic becomes available once spliced has processed the sample, but this may be too late for the writer creation in RnR. Solution: RnR now creates the topics synchronously.
OSPL-6207 | Report plugin robust against null pointer exception The report plugin could crash if it experienced a null pointer exception. Solution: The plugin is now robust against the exception.
OSPL-5524 | Java Throughput example exception when running a 2nd publisher Due to an issue in the internal administration of the java subscriber-part of the throughput example, the subscriber would terminate with an exception in case the publisher is stopped and started for the second time. Solution: The algorithm to update internal administration has been fixed.

### 6.4.3p6

Report ID. | Description
--- | ---
OSPL-6075 / 14410 | Concurrency issue while freeing signal-handler administration When a process detaches from the user-layer, which occurs automatically when a process terminates, it deinits the signal handler administration. Since it is still possible the process receives a signal at the same time, the signal handler thread may still be running and depending on the administration that is freed by the exit handler. A crash or mutex deadlock is often the result. Solution: The issue has been resolved by removing the possibility of the administration being freed while still in use.
OSPL-6184 / 14467 | Missing event on data reader view query. Queries on data reader views could miss a trigger causing data not to be read. Solution: The trigger mechanism is corrected and the data reader views are now always correctly updated.
OSPL-6297 / 14516 | Find topic timing behaviour incorrect. The find topic method on a DomainParticipant has a timeout parameter that specifies the maximum blocking time to wait for the topic to appear. In certain cases the method would block for 100 ms too long, which can have a noticeable impact on the application when called often on topics that don't yet exist. Solution: The implementation was changed to never exceed the maximum timeout.
OSPL-6298 / 14515 | Crash when closing OpenSplice rtsm with ctrl+c The RTSM tool accesses the internal database to get information and statistics. When terminating RTSM with ctrl+c during such a period, then it'll corrupt the database and make the domain stop. Solution: The signal is now caught and the handler detaches the tool properly from the database before quiting when needed.
OSPL-6350 / 14531 | Deletion of entities while other threads are accessing causes a lot of exceptions Deletion of entities while other threads are accessing fails as a result of a race condition between unlocking and deleting an Entity. Solution: Deletion of Entities while other threads are accessing the Entity is delayed until ongoing access has finished.
TSTTOOL-184 / 14348 | New instance not automatically displayed in tester In Tester, if an application data writer has a QoS of autodispose_unregistered_instances set to false and then unregister_instance is called on a data writer for some instance, a sample reaches matching data readers with the no_writers state and is ignored. Solution: A new boolean option has been added in the Preferences menu under the Settings tab, called "Ignore not_alive_no_writers samples" and is set to true by default. If the option is set to false, then these specific samples will be displayed in Tester.
TSTTOOL-192 / 14352 | Ospltest gives errors on startup The script directories are not included in the RTS installers. Solution: Updated scripts and install directories to fix these errors.

### 6.4.3p5

Report ID. | Description
--- | ---
OSPL-6027 / 14397 | Crash of DataWriter for multiple generations of one instance When a DataWriter can't deliver messages because a peer has no resources to accept them, the writer will temporary store the messages in its history and try to deliver the messages at a later point in time. If for one instance multiple messages are 'delayed' for multiple generations of one instance then a crash may occur. This will only occur if a retry is able to deliver the first generation of the instance but not all messages of the newer generations. In this situation the system will detect that the instance of the first generation has ended and disconnect the writer unaware that more generations exist. As a consequence the DataWriter will crash when it tries to deliver the remaining messages. Solution: he solution to this problem is that the DataWriter actively reconnects when it successfully delivered a 'delayed' Unregister message but was not able to deliver all messages of newer generations.

### 6.4.3p4

Report ID. | Description
--- | ---
OSPL-5880 / 14330 | Crash of RTSM tool The RTSM tool fails to attach to shared memory and crashes on a segmentation violation due to a mismatch in the layout of internal data-structures. Solution: The issue was resolved and the code has been updated to prevent similar issues from occurring in the future
OSPL-5847 / 14320 | Unable to read sample that complies to readcondition Due to a locking problem in the product, a read call could return NO_DATA while actually there is data available Solution: The issue has been resolved by adding a lock while freeing internal data
OSPL-5936 / 14137 | Durability Service Alignment Improvement When a node becomes master it requests samples from all the fellows. The master will request data for the groups that it knows about. Data for groups that not known to the master are aligned later using a different and potentially slower code path, resulting in less efficiency alignment. Solution: If the master should request samples from a fellow and it does not have received all groups from this fellow yet, then it will first request the groups of the fellow in order to know as many groups as possible before requesting samples. That will result in more efficient alignment.
OSPL-6036 | Incorrect behaviour of shared DataReaders In case multiple shared datareaders are created (by setting the share QoS policy), in certain situations the internal administration could be freed while another shared reader still depends on it. This could lead to undefined behavior such as a crash, or even reading data of a different topic if the internal administration was reused for other readers on a busy system. Solution: The issue was resolved by fixing a bug related to refcounting

### 6.4.3p3

Report ID. | Description
--- | ---
OSPL-5602 / OSPL-5676/ 14112 / 14137 | Alignment of historical data intermittently fails in case multiple master conflicts simultaneously appear. When multiple durability services are started but communication between them is disabled they all operate in isolation. When suddenly communication between them is enabled multiple master conflicts appears. In an attempt to solve these conflicts alignment of data that was published takes place. When the volume of data that was published in isolation is large, the alignment can become massive. In some cases the alignment was flawed, leading to an incorrect end-state where different nodes have different views on the data that was published. Solution: The administration to keep track of alignment data has been changed, so that data of the same partition/topic from different durability services are not mixed anymore. Furthermore, the alignment procedure has been adapted which leads to a more efficient alignment scheme involving less alignment data.
OSPL-5817/ 14293 | RTNetworking service may crash on an interface status change Due to a lock being released twice on the detection of a change in the status of a monitored network interface, the RTNetworking service could crash. Solution: The relevant locking has been revised and the double-unlock has been removed.
OSPL-5818/ 14292 | Starting ospl deamon from different user accounts could result in a delay of 10 seconds. When 2 different users are working on the same node and both are able to attach to the same domain, a user could experience a delay of 10 seconds when the domain was started. Also the process monitor was not working correctly in this use case. This was caused by connecting the same domain, but a different named communication socket. Solution: The name of the communication socket used by the process monitor is now consistent with the name of the key file in the tmp directory.
OSPL-5827/ 14297 | Regular reports leading to a large info log Some info reports that don't convey any particularly interesting information are logged on application start. In a situation where applications are frequently (re)started this could quickly lead to a large info log file. Solution: The info reports about ignored signals and initialization of the user-clock-module have been removed
OSPL-5831/ 14296 | Unable to launch OpenSplice Tuner after installing RTS The script to launch the Tuner depends on another script, which wasn't included in the RTS but only in HDE installers. Trying to start the tuner triggers an error 'ospljre: command not found'. Solution: The RTS installer now includes the ospljre script so the tuner can be launched.
OSPL-5835/ 14299 | Crash of durability service during termination In specific circumstances, when durability is terminated while it is resolving the master of a namespace, the service could fail on a mutex lock that was already freed, and would still try to unlock it which resulted in undefined behaviour and potential crash of the service. Solution: The termination mechanism was revised to free internal administration in the correct order and only unlock the mutex when the lock was successful
OSPL-5851/ 14295 | Error log file is created if buildin topics are disabled When builtin topics are disabled an error log is created with the error: DataReader (name="DCPSParticipantReader") not created: Could not locate topic with name "DCPSParticipant" Solution: The DCPSParticipantReader is not created anymore if the builtin topics are disabled.
OSPL-5854/ 14323 | Lack of reporting when incompatible meta-descriptor is registered. When type-support is registered by an application for a type that's already known, the declaration needs to match the existing declaration. When this is not the case, the registration fails and an indescriptive error is logged by the serializer. Solution: A report was added that refers to a declaration mismatch and also mentions the incompatible part, so the user can find and correct the corresponding IDL declaration.

## 6.4.3p2

Report ID. | Description
--- | ---
OSPL-5673/ 14138 | On VxWorks RTP large delays may occur, even for threads running at the highest priority. Priority inversion is the phenomenon where a high priority threads runs into a lock that is taken by a low priority thread, the high priority thread will not proceed until the lock is freed by the low priority thread. The remedy to deal with priority inversion is priority inheritance. Priority inheritance temporarily increases the priority of the low priority thread until the lock is freed, thus allowing the high priority thread to proceed. Although VxWorks provides native support for priority inheritance, OpenSplice did not benefit from it. This could cause large delays, even in threads running on the highest priority. Solution: Priority inheritance for mutexes (which are used to implement locks) is now enabled in OpenSplice for VxWorks RTP. Priority inheritance can be enabled by setting OpenSplice/Domain/PriorityInheritance in the configuration. Note that no priority inheritance for condition variables is supported.

## 6.4.3p1

Report ID. | Description
--- | ---
OSPL-5219/ 13337 | When the system is terminated while types are being registered a crash can occur. When a system is started, types that have been specified in the idl specification are being registered. If during the registration of these types the system is terminated a crash may occur. The crash is caused because the registration process is using references to type definitions that may have been deleted already by the termination thread. Solution: References to type definitions are now properly protected so that it is not possible anymore to delete references to types that are still in use by another thread.
OSPL-5742/ 14164 | Stale information in ospl artifact file causing ospl to exceed ServiceTerminatePeriod When the ospl tool is used in blocking mode (-f option) the artefact file is not properly (un)locked and updated under all conditions. Stale administration data could cause the ospl tool to exceed the ServiceTerminatePeriod when stopping a domain or report an incorrect warning when starting the domain. Solution: The issue was resolved by making sure the artefact file is properly managed in blocking mode.
OSPL-5770 | RnR may cause a warning by spliced about resources on termination The RnR service doesn't properly clean-up one of the writers it uses. This causes the safety mechanism of spliced to kick in after RnR has terminated. Solution: The RnR service now properly cleans up the writer.
OSPL-5772 | NetworkingBridge may cause a warning by spliced about resources on termination The NetworkingBridge doesn't properly inform spliced that it has terminated. This causes the safety mechanism of spliced to kick in. Because the NetworkingBridge actually did clean up its resources, spliced can always successfully clean up after the NetworkingBridge Solution: The NetworkingBridge now properly informs spliced, so that the clean up routines and the superfluous report don't occur anymore.

## 6.4.3

Report ID. | Description
--- | ---
OSPL-5083 | CMPartiticipant built-in topic extended with federation and vendor ids The existing CMParticipant built-in topic needs to be extended with federation and vendor ids. Solution: The content of the CMParticipant built-in topic has been extended to include a string that may be used as a federation identifier. For Vortex Cafe, each process is considered a federation. For other vendors' products, the federation id is based on our current understanding of the identifiers used by them, and this may change as our understanding grows. Also included is the vendor id code assigned by the OMG to the various vendors for use in the DDSI protocol, thus allowing tooling to show the vendor or use vendor-specific knowledge. The vendor code consists of two unsigned integers separated by a decimal point. (The vendor code for OpenSplice Enterprise is "1.2".)
OSPL-5357 | Ignoring all topics in _BUILT-IN PARTITION_ in DDSI2E breaks all communication DDSI2E internally relies on a topic in the built-in partition, but failed to note the presence of this topic/partition when ignored. While it is possible to ignore just this topic/partition, in practice, it is most likely to happen when ignoring all topics in this partition. A work-around is to configure topics C* and D* in this partition, as this does not include this particular topic. Solution: The detection of the presence of this topic/partition has been updated.
OSPL-5430 / 13801 | Reference to OMG ISO C++ specification missing in documentation There is no reference in the ISO C++ PSM documentation to the OMG ISO C++ PSM specification. Solution: A link to the OMG spec has been added.
OSPL-5688 | Globally unique systemId needs to be generated with more care. Each federation generates its own id at start-up, which must be unique in the system. Sometimes id's could turn out to be the same causing undefined behaviour. Solution: Unique system id generation has been improved to prevent duplicates when two copies of opensplice are started simulateously on the same linux or windows node.
OSPL-5694/ 14141 | Insufficient checking in java native marshalling routines When a sample with uninitialized members of type union or enum is written in the Java PSM, the JVM may crash instead of receiving a proper error return code. Note that members are always initialized by default in the code generated by idlpp, but it is possible for the application to assign null to a member after initialization. Solution: The marshalling routines were changed to return a BAD_PARAMETER code when an uninitialized member is processed.
OSPL-5740 / 14163 | An incorrect error is logged when a library fails to load An incorrect error is logged when a library, such as a report-plugin, fails to load library names. Libraries (i.e. the report plugin), can be entered in the configuration file in a platform agnostic manner. OpenSplice will translate the name and when the library fails to load runs a fall-back mechanism to load the original name. In this process, details on the failure were lost. Solution: The product has been changed to record a proper error message to the OpenSplice error log when a library fails to load.
OSPL-5743 / 14165 | The durability service could crash in case a namespace to a fellow is added for which no aligner exists. When a durability service receives a namespace for a fellow it adds the namespace for this fellow to the internal administration. Part of this administration is the merge state of the namespace. When no aligner for the namespace is known the merge state is NULL. Due to a bug setting a NULL value for the merge state would lead to a crash. Solution: The code that deals with setting merge states of namespaces has been changed so that no crash occurs anymore.
OSPL-5744 | Classic Java PSM QosProvider get_participant_qos() may crash When using the Java QosProvider in combination with get_participant_qos with a non null id the JVM could crash. Solution: The problem in get_participant_qos is now fixed and the JVM will not crash anymore on a non null id.
OSPL-5745 | autopurge_disposed_samples_delay zero is not instantaneous When autopurge_disposed_samples_delay is zero, then the purge is not instantaneous. It will be purged only after the monotonic clock has progressed at least one tick. Solution: This is solved by changing a timing check in the purge handling from 'larger than' to 'equal or larger than'.

## 6.4.2p5

Report ID. | Description
--- | ---
OSPL-5616 | Added support for shared library builds on vxworks RTP Shared library support required for VxWorks RTP use on Pentium4 and E500V2. Solution: Added shared library support for VxWorks RTP. Due to symbol table restrictions with the GNU toolchain the ddskernel library has been split into ddskernel and ddskernel2 for PPC Shared libraries.

## 6.4.2p4

Report ID. | Description
--- | ---
OSPL-1167/ 10824 | The ospl tool has wrong exit and status codes Regarding the status of a domain, the ospl tool returns wrong exit codes and depicts wrong status codes when listing domains. Solution: The ospl tool has been extended with a status file that contains the states of the available domains.
OSPL-5374/ 13672 | Issues with RT Networking CPU usage when Record and Replay service is enabled. An issue in the Record and Replay service in certain circumstances could result in native networking using up all of the cpu resources. When a recording is stopped, Record and Replay stops reading samples matching the record interest expressions, but networking continues to deliver these samples until storage resources are exhausted. When exhausted, networking anticipates on resources becoming available again, and continues attempted delivery at an increased rate, resulting in cpu exhaustion. Solution: A bug was found and resolved so record interest is properly disposed of by Record and Replay, after which networking stops delivering samples that are never read by Record and Replay.
OSPL-5615/ 14114 | The networking service may crash when topics with a name exceeding 64 bits are used. The networking service uses an internal buffer to store the topic names associated with received messages. Initially this buffer is 64 bits wide. When a topic name larger than 64bit is received the buffer should be increased in size accordingly. However it may occur that not enough memory is allocated which causes memory corruption to occur. Solution: The issue is fixed by always allocating enough buffer space when a topic name is received which has a size larger than the current buffer size.
OSPL-5387/ 13669 | Non-default presentation QoS incorrectly refused by product. The middleware did not accept a publisher or subscriber QoS on which the presentation was set to instance scope with ordered_access enabled. This caused inter-operability issues with other DDS vendors, while in fact the implementation does by default support ordered access on instance level. Solution: The restriction has been lifted so that publishers and subscribers can now be created with enabled ordered_access setting, as long as the scope is set to instance.
OSPL-5482/ 14005 | Crash of ddsi service when a DataReader with SubscriptionKey QoS policy is used. Management of builtin topics by the DDSI service contained a bug that could potentially crash the service when a builtin-topic sample is created for a DataReader that has the (OpenSplice-specific) subscription key QoS policy. Solution: The implementation was fixed to correctly handle the subscription key policy.
OSPL-5552 | OSPL_HOME may not be set correctly when using an archived build Builds delivered in an archived format would still contain the installer macros to be expanded at install time, without the installer these macros would remain and cause the release.com to set an invalid OSPL_HOME. Solution: The release.com now attempts to set OSPL_HOME using Bash when not using an installer. For users without Bash, a message will be presented expecting them to manually adapt the release.com with a valid OSPL_HOME.
OSPL-5627/ 14118 | Possible crash after exception handler has cleaned up resources. There was an issue with the exception handler cleaning up used resources which where still in use by the lease and resend managers. Solution: Before the exception handler frees the used resources, first stop the lease manager and resend manager.
OSPL-5657/ 14126 | Bounds checking error on IDL sequences with #pragma stac When #pragma stac is applied to all members of a struct, it would also be applied to sequences in case the sequence contains strings (or a type that resolves to string). However the code generated by idlpp would not correctly handle this, leading to errors when a sample is published and bounds checking is enabled. Solution: There is no real performance benefit in applying stac transformation to sequence elements so the pragma is now ignored for struct members of type sequence.
OSPL-5660/ 14129 | The durability service could crash when the service is terminating When the durability service is terminating it tries to clean up its resources. One of these resources is the fellow administration. When a fellow is being removed from the administration because it failed to updated its lease in time while at the same time durability is terminating, it is possible that durability tries to reference a fellow that has already been freed. This leads to a crash. Solution: References to fellows are properly counted, and the fellow is only freed when no other threads keep a reference to the fellow object.
OSPL-5675/ 14139 | Open dynamic loaded libraries with RTLD_NOW. Dynamic loaded libraries were opened with RTLD_LAZY, which caused problems with external library loading (such as report libraries). Solution: Dynamic loaded libraries are now opened with RTLD_NOW.
OSPL-5693 | Durability servers that operate in different roles and detect conflicting states for a namespace might handle the conflict wrongly, possibly resulting in a crash of durability. When different durability servers take responsibility of the same namespace but for different roles, merge policies can be applied to resolve these conflicts. Due to an error in the condition to resolve the conflict it is possible that a different merge policy is applied than specified. Also, when the correct merge policy is applied a crash could occur due to an attempt to access an object that has already been freed. Solution: The condition to resolve the conflict has been changed s that the correct merge policies are triggered. Also, the crash has been prevented by properly refcounting the object.

## 6.4.2p3

Report ID. | Description
--- | ---
OSPL-4944 | ISO C++ documentation improved Solution: Resolved problems with API being described, added code samples, added new API descriptions.
OSPL-5194 | VxWorks RTP version now has descriptive thread names Solution: Added descriptive names to the OpenSplice threads on the VxWorks RTP builds.
OSPL-5338/ 13592 | Writing samples from the DCPS Java API can result in an overflow of the internal references table of the JVM. During a write, a lot of Java object references can be created, depending on the type of a topic. Though the JNI specification allows only 16 references, in practice there were never any issues on Oracle JVM with using more references. Therefore the product did not explicitly delete references in favor of performance benefits during the write call. The PERC JVM however does not allow this relaxation of the JNI spec. overflowing the references table results in memory corruption. Solution: The Java PSM (JNI layer) was changed, to free unused references so the table cannot overflow.
OSPL-5615/ 14114 | The networking service may crash when topics with a name exceeding 64 bits are used. The networking service uses an internal buffer to store the topic names associated with received messages. Initially this buffer is 64 bits wide. When a topic name larger than 64bit is received the buffer should be increased in size accordingly. However it may occur that not enough memory is allocated which causes memory corruption to occur. Solution: The issue is fixed by always allocating enough buffer space when a topic name is received which has a size larger than the current buffer size.

## 6.4.2p2

Report ID. | Description
--- | ---
OSPL-5220/ 13333 | Unfair claim of ownership by unregister message Unregister messages could claim ownership of an instance and in combination with the deadline QoS and liveliness lost, this caused data reception 'gaps' when another writer with lower strength had already taken over. Solution: Unregister messages will not claim ownership.
OSPL-5228/ 13336 | When the durability service terminates there is a possibility that the durability service crashes When the durability service terminates it will clean up all its resources. While doing so there is a possibility that the action queue is already destroyed while another thread still tries to access the action queue. This situation could lead to a crash. Solution: Before cleaning up most threads are stopped. This prevents that a thread accesses a piece of memory that has been freed by another process. Also, the order to cleanup resources has been changed so that the action queue is destroyed AFTER all threads that may use it are stopped. And finally initialization and deinitialization of objects in the durability service has been improved.
OSPL-5361/ 13599 | Difficulty determining if a Record and Replay service is finished replaying samples In case all samples in a storage were replayed, the Record and Replay service would continue to poll the storage in case new samples were recorded, in order to replay them. This meant the storage remained open and this 'polling state' was not discernible by monitoring the (storage) status topic. Solution: The behavior was changed to only enter the polling state in case a storage is used for recording as well, at the time the last sample is replayed. In case a storage is not used for recording, all replay-interest is removed, the storage is closed and a corresponding storage-status sample is published.
OSPL-5419/ 13594 | Liveliness detection and synchronization problem. When disconnecting a node, then the liveliness changed is not always triggered on the remaining node when using exclusive ownership. When the liveliness changed is triggered, then the instance state is (often) still 'alive' when 'not alive' is expected. Solution: Messages of low strength writers in a exclusive ownership setup are not handled. By not ignoring the 'unregister message of such a low strength writer, the liveliness is properly decreased. Also the the liveliness changed is now triggered after the related instance states have been set to 'not alive'.
OSPL-5459/ 13924 | With a (default) umask of 0022 different users on the same node interact with each other on a posix system. When 2 different users are working on the same node with a umask setting of 0022 the splice deamon will attach to the same shared memory segment. This is caused by the key file with user rights set to 666 with the key for the shared memory to attach to. Solution: If the umask gives only read or write rights to a user/group/others then the key file gets no rights at all for that part. This will result in a key file with user rights 600 on a default umask of 0022.
OSPL-5468/ 13933 | Customer code application build problem with 6.4.2 netdb.h system header file clashed with a symbol when building customer code. Solution: Avoided an issue with conflicting symbols by not including the netdb.h system header file when building customer code.

## 6.4.2p1

Report ID. | Description
--- | ---
OSPL-5365/ 12971 | Fixed startup failure with DDSI if configured to run using a single UDP unicast port DDSI would not start when configured to use a single UDP unicast port. Solution: Behaviour fixed.
OSPL-5413 | When using DDSI, the "dispose all" command was transmitted best-effort The QoS used for publishing a "dispose all" command throughout the domain caused it to be sent best-effort when using DDSI, creating the possibility of it reaching only a subset of the nodes. The different design of RT networking ensured that systems based o RT networking did not run this risk. Solution: The QoS has been changed to reliable.
OSPL-5416 | The DCPSHeartbeat writers should be best-effort For the OpenSplice-specific DCPSHeartbeat built-in topic, best-effort relability suffices. In OSPL V6.4.1 version it was changed to a reliable writer, which slightly affects behaviour when used with the RT networking protocol, in cases where the network is overloaded or very unreliable, as delivery of the DCPSHeartbeat may be blocked by preceding messages. Solution: The DCPSHeartbeat writer QoS is once again best-effort
OSPL-5450 | Deserialiser can incorrectly reject valid input because of an erroneous bounds check An issue in the CDR deserialiser can cause a valid input to be rejected by a sequence bounds check. The affected components are DDSI, durability with a KV persistent store, RnR with binary storage, and RT networking when using compression (not the legacy compression). Solution: The check has been fixed.
OSPL-5460 | Potential misaligned access in the CDR deserialiser for 64-bit objects The CDR deserialiser could access 64-bit objects without ensuring the access is properly aligned. On most platforms, and most notably on the x86 and x64 platforms, such misaligned accesses are entirely legal, but on some platforms, they cause a misaligned access exception. Solution: The CDR deserialiser now avoids misaligned accesses.

## 6.4.2

Report ID. | Description
--- | ---
OSPL-3957 | OpenSplice should support hibernation Modern platforms support the concept of hibernation and resuming. When hibernating, all processes are suspended and the complete RAM is written to permanent storage and during resuming that information is written back into RAM again with the purpose to have all processes continue where they left off before hibernation. However, during the period a system is hibernated, time elapses and as a result software may face time jumps when resuming again. OpenSplice is not able to cope with these time jumps, resulting in the potential termination of services or even a complete shut-down of the middleware. OpenSplice needs to be able to cope with hibernation to allow the product to be used in environments that rely on that functionality as well. Solution: The various notions of time have been updated throughout the entire product allowing it to cope with time jumps as well as resuming after hibernate/suspend.
OSPL-4196 | Timestamps on WinCE aren't guaranteed to be represented in UTC OpenSplice internally uses the WinCE GetLocalTime() operation, which returns time in local time-zone. Depending on time-settings of the operating system, this time may not match UTC, which is used on other platforms. Solution: The implementation now ensures the time is represented in UTC on WinCE as well.
OSPL-4325 | Error log about failure to remove DBF file on Windows after domain shutdown An issue with termination of OpenSplice services could result in a failure to remove the database (.DBF) file and corresponding message logged to the ospl-error logfile. Solution: The termination issue was resolved so that the database-file can be removed.
OSPL-4513/ OSPL-5285/ 12875/13407 | Shared Memory not detecting terminated or killed processes Terminated or killed processes on Windows are not detected, which may lead to corrupt shared memory and will then not update the liveliness state of writers. Solution: Updated the implementation of the shared memory monitor for Windows, using specific Windows API calls. Now the termination of a process is detected by the Splice daemon and proper action is taken to clean up after termination of the process. This might lead to a shutdown of Splice in case the terminated process was modifying shared memory when terminated, as shared memory is corrupted in this case.
OSPL-4590/ 12947 | When durability terminates, the durability service should try to persist as much data as possible in case the persistent data queue still contains samples to persist. Until now a durability service that terminates does not store persistent data that is waiting to be persisted. An improvement to this behavior is to try and persist as much of the remaining data as possible without exceeding the ServiceTerminatePeriod. Persisting as much data as possible is a best-effort attempt to save valuable data in case a durability service is terminated. Solution: The durability service uses part of the ServiceTerminatePeriod to store remaining data that has not yet been stored at the time the durability service starts to terminate.
OSPL-4695/OSPL-5262/ 13414 | RMI: Interface unregistration problem When an interface is unregistered then the runtime is shutdown, a NullPointerException was raised, and any attempt to register this same interface a second time fails and leads to "Interface X already registered". Solution: The interface is now properly removed from the runtime interface registry.
OSPL-4696 | Restarting an RMI runtime causes failure On Runtime stop, in CInterfaceRegistryImpl.java, the m_Reader reader is closed (directly or indirectly), but the field is not set to null. So after restart, the CInterfaceRegistry tries to resuse the reader with no success. Solution: Fixed the m_Reader in clear method.
OSPL-4871 | Reference guide update for WriterDataLifecycleQosPolicy WriterDataLifecycleQosPolicy missing autounregister_instance_delay and autopurge_suspended_samples_delay attributes. Solution: All reference guides have been updated with the descriptions.
OSPL-4960 | When Node Monitor is started it should publish all the enabled samples immediately When Node Monitor is started, the NodeStats and NodeInfoConfig writers should publish all the enabled samples immediately and have their DURABILITY QoS set to non-VOLATILE so that late-joiner DataReader configured also to non-VOLATILE to get the last sample per key, rather than wait (potentially for a long time) until all the intervals have elapsed after nodemon startup. Solution: The NodeStats and NodeInfoConfig topics' durability QoS policy kind was changed from V_DURABILITY_VOLATILE to V_DURABILITY_TRANSIENT.
OSPL-5146/ 13108 | Not all signals properly handled when using pthread_kill(...) When using pthread_kill(...), for example to abort a process, the process would continue to run. Solution: The signalhandler has been modified so that signals generated with pthread_kill(...) are properly handled too.
OSPL-5147 | User should be aware that a runtime installation of OpenSSL is required for OpenSplice licensed features and/or ddsi2e and snetworking - an update Addition of TLS in ddsi2 removes the static link to OpenSSL in previous versions of OpenSplice on non-windows systems. Solution: The requirement for the OpenSSL runtime now only applies to ddsi2e and snetworking on non-windows systems.
OSPL-5190 13188 | Disabling the Java shutdownHook Solution: The Java shutdownhook, used to clean up all created entities that have been created by a java application, but have not been cleaned up during the execution of the application can be disabled by a new introduced system environment property: "osplNoDcpsShutdownHook". See java reference manual for more details.
OSPL-5244/ 13406 | Waitset associated with wrong DomainParticipant causes problems during clean-up In case an application has multiple DomainParticipants participating in the same Domain and attaches a Status-, Read- or QueryCondition to a Waitset, the Waitset may be associated with the wrong DomainParticipant, because the algorithm to select one did it based on the DomainId instead of looking at the DomainParticipant associated with the Condition. This may cause problems when deleting one or both DomainParticipants and even lead to a crash of the application in some cases. Solution: The DomainParticipant is now selected based on the DomainParticipant associated with the Condition.
OSPL-5266 | DDSI2 warns about a message without payload DDSI2 used to emit warnings of the form "write without proper payload (data_smhdr_flags 0x2 size 0)" when receiving messages from a writer that have no content whatsoever. Such messages are allowed by the specification and hence should not result in a warning. Solution: The warning has been removed, it is still logged in the trace.
OSPL-5268 | C-language binding used wrong type for the "subscription_keys" of the CMDataReader built-in topic The C language binding accidentally used a sequence of strings where it should have been a single string to describe the subscriber-defined keys. This caused crashes for a C program trying to use the CMDataReader built-in topic, and additionally caused the C binding to differ from the other language bindings. Solution: The type has been changed.
OSPL-5321 | Issue with DSCP SAC code-generation The code-generation templates for typed DataReaders and DataWriters contained an error in the definition of 'FooDataReader_get_subscription_matched_status' and 'FooDataWriter_get_publication_matched_status' methods. Since these methods were not available users were forced to use the regular DDS_-prefixed methods, resulting in inconsistent code. Solution: The issue has been solved and the correct definitions are now generated by idlpp
OSPL-5335 | DDSI can flag dispose/unregister messages from Caf� for CM topics as invalid DDSI2 is designed to handle data containined "proper" payload, but some DDSI implementations in some cases do not provide a real payload, but only an alternative form of the key. DDSI2 translates these to well-formed payloads before interpreting them, but this translation was incorrect for some CM topics. Solution: The translation table has updated to cover all cases.
OSPL-5406/ 13796 | Unable to find an entry point in C# API When using a call like GetDiscoveredParticipants in the C# API, an "Unable to find an entry point named 'u_instanceHandleNew' in DLL 'ddsuser'." exception could be thrown. Solution: This issue has now been fixed by referring the entry point to the correct library.
OSPL-5411 | RT networking interoperability fix due to ospl-4345 (6.4.1) fix At 6.4.1, RT networking interoperability with older versions was degraded. Solution: RT networking now correctly handle version prior to 6.4.1.

## 6.4.1p9

Report ID. | Description
--- | ---
OSPL-3216 | Built-in CMParticipant Topic accessibility. The CMParticipant built-in Topic should be accessible, to applications, through a built-in DataReader. Solution: The CMParticipant built-in Topic and DataReader are added to all language bindings.
OSPL-4157/12727 | C DCPS generated API doesn't compile with g++ The C API no longer compiles when using g++ Solution: The fault has been fixed and g++ will now compile the C API again.
OSPL-4480/ 12870 | Upon repeated stop/start of OpenSplice, the application received the error "Max connected Domains (127) reached" In our user layer the connected domains are stored in an array of 127 items. When a domain is connected, the next entry is used, skipping entries that have been freed by a domain disconnect. After 127 connects, the end of the array is reached, which results in this error. Solution: When a domain is disconnected, the entry in the array will be marked free. When a new domain is connected, the array will be searched from the beginning for a free entry, re-using locations that were in used and were freed.
OSPL-5192/ 13191 | When the replace merge policy is invoked not all data is being replaced. When a fellow durability service that acts as master for a set of namespace leaves, a check is needed to see if an alternative aligner is available for each of these namespaces. If no alternative aligner is found the merge state for the namespace must be cleared to ensure that a merge action is triggered as soon as a new aligner joins the network. This check should be carried out for all namespaces. However, once no alternative for a namespace was detected the other namespaces were (wrongly) not checked anymore, resulting in the fact that the merge states for these namespaces are not cleared, and no merge policy is triggered for these namespaces. Solution: The code has been changed so that an alternative aligner is searched for all namespaces of the leaving fellow.
OSPL-5197 | CMSoap service can fail to terminate cleanly The timeout handling in accepting new conditions in the cmsoap service could cause cmsoap to fail to terminate cleanly, instead automatically killing itself after the (configurable) service termination period. Solution: The timeout specification has been updated to avoid this issue
OSPL-5202/ 13197 | Tuner does not accept character code input for c_char fields. If a user wanted to write a character value for a c_char field that was not found on the keyboard (like the NUL character or the LF character) there was no way to input it in the Tuner writer window. Solution: The Tuner writer input for c_char fields now accepts octal character codes (eg. \000 for NUL, \012 for LF, \141 for 'a', etc).
OSPL-5234 | Possible crash of networking service when running out of DefragBuffers The networking service could crash when it ran out of DefragBuffers and its garbage collector started releasing DefragBuffers. The crash happened when the garbage collector double released DefragBuffers that were still in use. Solution: The garbage collector no longer double releases in use DefragBuffers.
OSPL-5239 | DDSI could crash when a thread is killed When a thread was killed, where the participant was already deleted DDSI could crash trying to get subscriber/publisher out of this participant. Solution: Before trying to access the subscribers or publisher, check if the participant is still valid.
OSPL-5251/ 13405 | Using synchronous reliability could cause a crash due to a memory corruption Due to missing locking on a part of the synchronous reliability administration, the memory could become corrupted causing a crash Solution: Locking has been added to the relevant bits of the synchronous reliability administration.
OSPL-5253 | Recompilation rules broken for Java applications Java applications generated before V6.4.0p5 wouldn't run on later versions and required code to be regenerated and compiled. This was mentioned in the release notes (OSPL-4333). Solution: An overloaded constructor has been added that supports the old format of generated code, allowing the applications to be used according the the recompilation rules.

## 6.4.1p8

Report ID. | Description
--- | ---
OSPL-4614 / 12392 | In some situations it is possible that a durability service processes pending messages from another durability service (a fellow) that has been removed recently, causing the fellow to be added again. When a durability service is busy it cannot process any incoming message from a fellow immediately. In case a message from a fellow is received and the fellow is terminated before the message is processed, then the fellow will be removed as peer from the durability service. But when the pending message is processed the durability service notices that this came from a fellow that is not known, and will (wrongly) added again. Solution: When a fellow has terminated, its address will be remembered for some while. Messages originating from a fellow with an address that has recently terminated will not processed, thereby preventing that a 'new' fellow is added.
OSPL-4985 / 13053 | When multiple master conflicts appear at the same time, only one of them is handled, resulting in incorrect merges of historical data. In some cases it is possible that suddenly multiple nodes appear that are all master for the same namespace. This is for example the case when a firewall initially blocks traffic between 3 nodes A, B and C that all become master. When the firewall is disabled (thus enabling communication between all nodes) each nodes has 2 possible master conflicts. Both of these conflicts should be handled to ensure that data is correctly merged. Solution: No master conflicts are dropped anymore, and successive master conflicts are being re-evaluated because they may have been invalidated by resolving previous master conflicts.
OSPL-5125 | Termination of DDSI2 in shared memory deployments on Windows causes warnings DDSI2 creates various objects for its internal administration and its interaction with the OpenSplice kernel. Some of these were not released in the terminated path, causing the DDSI2 domain participant to not be deleted at the expected time because there were unexpected outstanding references to it. This would then lead to an apparent crash of DDSI2, which would be logged. The problem surfaced only on Windows because of the differences in the way atexit() is handled on Windows and on other platforms. On the other platforms, the domain participant would eventually be deleted properly for a clean shutdown. Solution: All objects are now released explicitly and the DDSI2 domain participant is deleted as planned on all platforms.

## 6.4.1p7

Report ID. | Description
--- | ---
OSPL-5152 | DDSI TCP interoperability with Vortex Cloud Routing Service When using OSPL clients with the Vortex Cloud where the routing service is involved then OSPL would fail to connect. Solution: TCP DDSI sends correct ENTITY_ID sub message to discovery and routing services, enabling cloud based routing

## 6.4.1p6

Report ID. | Description
--- | ---
OSPL-4583/4586/ 12946 | When durability is used in combination with DDSI and DDSI generates builtin topics, then durability may not align data because DDSI may drop durability messages. A durability service assumes reliable two-way communication with other durability services. This assumption is not true anymore when DDSI generates builtin topics (see the <GenerateBuiltingTopics>-tag). In this case it is possible that a durability service receives messages from another durability service, but responses to these messages are dropped by DDSI because not all readers have been discovered yet. If responses are dropped the durability protocol is broken, possibly leading to the inability to align data. Solution: If DDSI generates builtin topics then the durability service will only respond to a nameSpacesRequest message if all readers of the remote durability service have been discovered. Because the durability protocol always starts with the exchange of namespaces, discovery of all remote readers is now guaranteed.
OSPL-5068 | release.com/.bat override OSPL_URI If an OSPL_URI is set and then the release.com/.bat is executed, the OSPL_URI is over-ridden. Solution: OSPL_URI is now honoured.
OSPL-5130 | DDSI2 did not terminate within ServiceTerminatePeriod The DDSI2 service did not terminate within ServiceTerminatePeriod. The listen_thread was blocking on 'accept()' call. Solution: On termination wake the listen_thread so termination can continue.
OSPL-5141 | DDSI2 TCP and TCP with SSL not consistent on blocking read/write DDSI2 TCP and TCP with SSL not consistent on blocking read/write leading to inconsisten behaviour. Solution: A common timeout mechanism has been implemented for both TCP and SSL read and write operations that would block. TCP configuration options "ReadTimeout" and "WriteTimeout" have been added, these specify the timeout on a blocking read or write call, after which the call will be abandoned and the corresponding transport connection closed. These configuration options replace "ReadRetry", "ReadRetryInterval" and "WriteRetry" which have been removed.
OSPL-5143/ 13107 | Possible compiler warning in the C++ language binding An initialiser used in the initialisation of a number of mutexes internal to the C++ language binding can cause compiler warnings. Solution: The initialisation has been modified.

## 6.4.1p5

Report ID. | Description
--- | ---
OSPL-4983-1 | DDSI over TCP interoperating with Vortex Caf\E9 may drop connection after 10s When a Vortex Caf\E9 process was connected to an OpenSplice Enterprise node using TCP where Caf\E9 was acting as a TCP client and Enterprise as a TCP server, Caf\E9 could consider the Enterprise node dead because it was not receiving participant discovery data as it expects. Solution: Participant discovery data is now properly distributed over TCP connections.

## 6.4.1p4

Report ID. | Description
--- | ---
OSPL-4983 | DDS using TCP can not handle high data load Under high load, DDSI TCP connections could be dropped and recreated, losing samples in the process and with various long timeouts interfering with the correct operation. This was caused by incorrectly handling a full socket buffer at the start of writing a message. Solution: The code now correctly accounts for such events.
OSPL-5118 | Performance improvement for CDR deserialisation The CDR deserialisers all used a sub-optimal way of allocating sequences. Especially for sequences in small samples sent at a very high rate, this had a significant performance impact. Solution: The allocation of sequences has now been changed to use a faster method.

## 6.4.1p3

Report ID. | Description
--- | ---
OSPL-5104 | DDSI doesn't properly account transient-local data in its WHC DDSI stores unacknowledged samples and acknowledged but transient-local samples in a writer history cache. The amount of unacknowledged data is kept track of, but this was done incorrectly for transient-local data. This in turn could cause DDSI to lock up, in particular when a large amount of discovery data needed to be sent. Solution: The amount of outstanding unacknowledged data now reflects acknowledgements of transient-local data as well.
OSPL-5105 | DDSI can throttle a writer without ensuring an ACK is requested immediately When the amount of outstanding unacknowledged data in a writer reaches a (configurable) threshold, the throttling mechanism blocks further data from that writer from being sent until the amount of unacknowledged data is reduced to below a (configurable) level. This requires the readers to send acknowledgements, which they are only allowed to do upon request from the writer. The last packet sent before the throttling often, but not always, includes a request for acknowledgements, and if it doesn't a 100ms delay is incurred. Solution: The writer now forces out a request for acknowledgements before blocking.
OSPL-5106 | DDSI delays NACKs unnecesarily when requesting samples for the first time DDSI2 follows the specification in delaying NACKs a little but only if the previous NACK was within the NackDelay interval. However, if it detects a need to request a retransmission of samples not covered in the previous NACK, waiting only introduces an unnnecessary delay. Solution: The NACK scheduling now takes into account the highest sequence number in the preceding NACK.

## 6.4.1p2

Report ID. | Description
--- | ---
OSPL-5087/ 13087 | High memory by DDSI2 on WinCE. On WinCE, DDSI2 could require large amounts of memory when transmitting large samples because of an issue in platform-specific code. Solution: The underlying issue has been addressed.
OSPL-4506/ 12880 | The use of a content-filter topic causes a memory leakage. When creating a content-filter topic a memory leakage occurs when evaluation the filter expression. The key field list used when evaluating the filter expression is not released causing the memory leak. Solution: Release the key field list when evaluating the content-filter.
OSPL-4878/ 13001 | DeadlineQosPolicy when DataWriter is deleted keeps triggering Reader listener/waitset keeps getting triggered for deadline missed after instance is disposed and writer deleted. A v_dataReaderInstance was unintentionally re-inserted in the deadline list right after it was intentionally removed. Solution: Removed v_dataReaderInstance re-insert
OSPL-4974-1 | DDSI TCP on Windows fails with large messages When using large message payload, DDSI TCP would hang because the TCP buffer would overload. Solution: Error handling improved for blocking TCP write functions.
OSPL-4974-1 | Change default value for DDSI TCP configuration property NoDelay Solution: Changed the NoDelay DDSI TCP configuration property to true (from false) to reduce jitter.

## 6.4.1p1

Report ID. | Description
--- | ---
OSPL-4777-1/ 12989 | In some situations it is possible that the durability service sends out responses to requests in the reverse order. As a resul recipients of these responses may perceive a "wrong" state of groups and namespaces. Due to a threading issue it is possible that a durability service sends out responses to request in the reverse order. In particular, the state of groups and namespaces could be reversed, causing recipients to believe that a group is 'incomplete' while in fact the master has announced is completeness. In this case the recipients will wait forever to become complete. Solution: Once a group is complete it can never announce its 'non-completeness' anymore. Also, order reversal of announcing namespace states has been prevented.
OSPL-4942-1/ 13042 | In rare occasions a process could fail to detach properly from SHM due to a race condition Due to a race condition in checking whether a live process is ready to detach, the process could conclude that it still had threads in SHM, causing the detach to fail unexpectedly. As soon as this was detected by spliced, the domain was brought down. Solution: The race condition has been resolved.
OSPL-5053 | DDSI "malformed packet received" error with state parse:info_ts DDSI verifies the well-formedness of the messages it receives, logging a "malformed packet" error if it is not. The message validator would reject a short timestamp even when the INVALIDATE flag was set on the submessage. Solution: DDSI now accepts empty timestamp submessages with INVALIDATE set.

## 6.4.1p1

Report ID. | Description
--- | ---
OSPL-3868 | DDSI2 group instance leakage in shared memory The DDSI2 service caused a small memory leak in shared memory fo each group instance written. Solution: Memory is now freed.
OSPL-4095 | DDSI stops when creating many readers/writers and no peers exist The DDSI discovery protocol exchanges information on all endpoints, and does so by creating an instance in a reliable, transient-local writer (one for writers, one for readers) for each existing endpoint. An issue was discovered where this data is counted as unacknowledged data even when there are no peers, and creating readers/writers may cause DDSI to reach the maximum allowed amount of unacknowledged data in the writer. This in turn blocks various processing paths, and if there are no peers, there is no way out. Solution: When there are no peers, the data is no longer counted as unacknowledged data.
OSPL-4607/ 12961 | Deleting a writer does not free all shared memory allocated when creating it Solution: Memory allocation is now tidied
OSPL-4713-1/ 12978 | Readers not disposing after using built-in subscriber After termination, even after calling 'delete_contained_entities()' on the DomainParticipantFactory, the tester showed the participant as disposed with active DataReader for built-in topics. The 'delete_contained_entities()' function did not delete all contained entities and the built-in subscriber was not deleted. Solution: When calling 'delete_contained_entities()' on the DomainParticipant the built-in subscriber is now also deleted.
OSPL-4713-2/ 12978 | Shared memory runs out after running a very simple application in a loop A small memory leak (96bytes ::v_message<kernelModule::v_participantInfo>) made it possible to run out of shared memory when a very simple application (factory 'get_instance()', 'create_participant()' and exit) was run in a forever loop. Solution: Memory is now freed.
OSPL-4713-3/ 12978 | Shared memory leakage on Windows platforms On Windows platforms our exit handler was registered but never called when 'get_instance()' was called from the customer application context, this caused memory leakage. Solution: Our exit handler is now also called on Windows when our library is unloaded. However Windows terminate threads ungracefully which could still cause memory leakage if 'delete_contained_entities()' is not called before library unloading.
OSPL-4717/ 12982 | When using wait_for_historical_data_w_condition with OR codition its possible that not all matching samples are returned. When wait_for_historical_data_w_condition is used the evaluation of the condition is not correct. If the conditions consists of OR expressions then not all parts of the OR expression are evaluated. Solution: The evaluation of the condition now walks over all OR elements of the condition and does not stop when it finds a match.
OSPL-4727 | DDSI discovery heartbeat interval too long The DDSI specification gives a DDSI participant various ways of renewing its lease with its peers, one of which is a periodic publishing of a full participant discovery sample. To reduce the bandwidth needed, DDSI would instead send some other data, but this is not good enough to maintain liveliness with all other implementations. Solution: DDSI now sends the participant discovery sample at an interval slightly shorter than the participant lease duration, which itself is taken from the OpenSplice domain expiry time, but never longer than the configuration SPDP interval.
OSPL-4874 | RnR replayed data not arriving on remote nodes using DDSI When RnR replays a recording it relies on the networking service to distribute the data from the RnR service to any remote data readers. The writer instance handles used by the replay did not match known writers for DDSI, hence DDSI was unable to determine where to send the data, and ultimately causing DDSI to drop the data. Solution: RnR now creates local data writers and remaps the writer instance handles in the replayed data to correspond to these known writers, allowing DDSI to distribute the data throughout the network.
OSPL-4962 | Detecting which participant represents DDSI2 in a federation is difficult DDSI2 itself acts as a participant in the system, and hence creates a participant at the DDSI level as well. For other DDSI implementations it may be useful to be able to detect which of the remote participants is a DDSI2 service. Solution: DDSI2 has been enhanced to indicate in its discovery information which of the potentially many participants in a federation is the DDSI2 service itself. This enhancement is backwards compatible.
OSPL-4963 | Domain ControlAndMonitoringCommandReceiver/Scheduling/Priority setting applied incorrectly The value configured for the ControlAndMonitoringCommandReceiver/Scheduling/Priority for the domain was applied to the ResendManager thread rather than to the CandM thread. Solution: This has been fixed.
OSPL-4974 | DDSI TCP may fail under high load Under high load a DDSI TCP connection may fail and would not recover. Solution: The socket waitset has been made threadsafe. Under UDP only a single thread accessed the waitset, under TCP multiple threads are used.
OSPL-4995 | DDSI default socket buffer sizes increased The socket buffer sizes have a significant impact on performance, and in particular having a small receive buffer size when data comes in at a high rate can be a performance bottleneck. Unfortunately, there is no agreement across operating systems about the default maximum size, and hence in the past DDSI defaulted to a smallish buffer. Solution: The defaults and the warning policy for failure to set the buffer size has been changed. Without specifying a receive buffer size (or "default"), DDSI will default to requesting 1MB, but accept whatever the kernel provides. Explicitly specifying a buffer size will still result in an error message if the kernel refuses to provide it.
OSPL-5002 | Invalid messages accepted by DDSI2 The DDSI2 service verifies the well-formedness of the incoming messages, but two issue in the verification were discovered: firstly, it would accept invalid sequence numbers in data samples, even though the specification explicitly states such messages must be rejected, and secondly, it did not correctly verify that the start of the inline QoS or payload was indeed within the message. Solution: Both points have been corrected.

## 6.4.1

Report ID. | Description
--- | ---
OSPL-1084/ 10782 | When RTnetworking compression is activated the number of network frames is not reduced. When RTnetworking compression is activated then compression is applied to each network frame which causes that the size of the frames is reduced but the number of frames remains the same. Solution: When compression is activated the compression of the data is performed before fragmenting and the packing of data messages is performed before compression is applied to the data. Which results in a better compression ratio and a reduced number of fragments (packets).
OSPL-2023 | DataReaderView doesn't take modified default DataReaderView QoS when created (sacpp & ccpp) The default DataReaderViewQos can be changed by calling set_default_datareaderview_qos() on the related DataReader.When a DataReaderView is created with DATAREADERVIEW_QOS_DEFAULT, then it should take the QoS that was set with set_default_datareaderview_qos(). This didn't happen, the DATAREADERVIEW_QOS_DEFAULT was used as QoS. Solution: During reader->create_view(), check if DATAREADERVIEW_QOS_DEFAULT was provided. If that's the case, then the readers' internal default DataReaderViewQos is used instead.
OSPL-3789/ 12578 | The 'autopurge_dispose_all' value is added to the ReaderDataLifecycleQosPolicy. When calling dispose_all() an a Topic, then related readers will receive a disposed notification for all disposed samples. For performance reasons, it should be possible to block those disposed notifications and only trigger the on_disposed_all() notification on the ExtTopicListener. Also the samples should be disposed automatically. This should be controlled on a 'per reader' basis. Solution: The 'autopurge_dispose_all' is a new value in ReaderDataLifecycleQosPolicy, which is part of the DataReaderQos. When set to 'true' (default is 'false'), it makes sure that all related reader samples are purged when dispose_all() is called on a Topic. The related reader will not be notified that the samples have been disposed by a dispose_all().
OSPL-3976/ 12652 | If master selection in durability takes a long time the system could stall At start up, the durability service tries to determine masters for all its namespaces. If during the master selection phase fellows are removed this also triggers master determination. In this case, the latter thread waits for the master selection lock which has been taken by the first thread. If the first thread takes a long time to determine masters for its namespaces (which is typically the case for large systems with many nodes and namespaces) then the second thread is stalled for a very long time. If this time exceeds the thread liveliness assertion period then the second thread is declared dead, which may lead to system failure. Solution: While the second thread is waiting for the first thread to release its lock, liveliness of the second thread is asserted regularly. This ensures that the second is not declared dead, even if initial master selection by the first thread takes significant time.
OSPL-4041/ 12669 | Idlpp for C# generates incorrect code when using const to const assignment When generating code from an idl-file which contains a const variable which is used for assignment to another const variable, idlpp for C# generates incorrect code. The latter assignment was generated as (null), because the C# implementation was missing for this case. Solution: Adjustements made to idlpp tool, it now implements the const to const assignment case.
OSPL-4070 | RTNetworking supports setting the Differentiated Services Code Point (DSCP) field in IP packets on windows To provide the setting of the DIffserv (DSCP) field in the IP packets the networking service used the IP_TOS option for this purpose. However, since Windows Vista and Window server 2008 setting the IP_TOS option is no longer supported. To use the Diffserv functionality on these versions or later versions of windows the new QoS2 API has to be used. Solution: The networking service must map a configured Diffserv value on one of the Traffic Types supported by the windows QoS2 API. When administrative privileges are avalaible then the configured Diffserv value is set on the traffic flow associated socket which will result that the Diffserv field of the IP packets is set to the configured value. When no administrative privileges are available then the Diffserv field will be related to the Traffic Type that is selected.
OSPL-4282/ 12770 | When using OSGi without proper exports a crash will occur. When using two OSGi bundles, one contains dcps.jar (dcpssaj-osgi-bundle.jar) and the second by idlpp generated typed code without exports and an application. When the second bundle accessed the first bundle which then tried to access a class form the second bundle using the JNI FindClass function a crash occurred because of the thrown exception. Solution: To prevent this crash from happening the exceptions thrown by the JNI FindClass function are now caught and a log message is written to the error log explain what when wrong.
OSPL-4371/ 12817 | Unclear logging when services are killed because of elapsed serviceTerminatePeriod When the serviceTerminatePeriod elapses during shutdown the ospl-tool logged an ambiguous message to the info log. The Splice daemon should have logged a clearer service kill message, but this was never reached because the ospl-tool would terminate the Splice daemon prematurely. Solution: Clarified service kill messages for both ospl-tool and Splice daemon. Increased ospl-tool wait period before sending kill signal to Splice daemon process group. Additionally, durability now logs messages when it fails to assert its liveliness within the expiration period.
OSPL-4345/ 12809 | The adminQueue may overflow when receiving thread is busy processing messages and the sending thread is not scheduled in time. The sending thread is responsible for transmitting ACK messages. For that purpose the receiving thread uses the adminQueue to inform the sending thread of the data messages received. When the receiving thread is busy processing received data the adminQueue may get full because the sending thread (lower priority) is not scheduled in time. Solution: The receive thread is made responsible of sending the ACK messages. This has the effect that the timing requirements of the sending thread are relaxed.
OSPL-4385/ 12821 | When using edge case resource limits, OpenSplice didn't behave as expected. When using a resource setting of max_samples=1 and history = KEEP_LAST for the reader, samples weren't overwritten while as expected but an error was returned. Solution: The reader and writer resource limits are now better checked so that samples are overwritten when allowed.
OSPL-4423 | User should be aware that a runtime installation of OpenSSL is required for OpenSplice licensed features and/or ddsi2e and snetworking. Addition of TLS in ddsi2 removes the static link to OpenSSL in previous versions of OpenSplice on non-windows systems. Solution: At runtime an installation of OpenSSL is required for licensed features, however on most systems this is standard.
OSPL-4463/ 12863 | The use of sequences is not supported in multi-domain applications. The issue is located in the copy-in routines generated by the IDL pre-processor. The copy-in routines are used when the application performs a write operation. To improve the performance of the copy-in routines these routines cache some type information about contained sequences. This causes a problem when writing the same type to multi-domains because the cached type information is domain specific. Solution: An option (-N) is added to the IDL pre-processor which disables the type caching in the generated copy-in routines.
OSPL-4530 | Improved DDSI robustness In high-throughput situations, DDSI2 could behave quite badly, with retransmit storms and/or temporarily considering reliable readers unresponsive and treating them as effectively best-effort. The long default participant lease duration caused these effects to linger for a long time even after restarting part of the application. Solution: The risk of retransmit storms and the associated effects has been reduced by improving the mechanism used to control the rate of retransmit requests and improved control over the amount of outstanding unacknowledged data, by configuring bytes rather than samples. The default participant lease duration is now controlled by the ExpiryTime configured for the domain, and will therefore typically have a more reasonable value.
OSPL-4534 | In cases where DDSI generates builtin topics there is no need for durability to align the builtin topics. DDSI can discover entities and could generate builtin topic information. This enables non-enterprise nodes in the DDSI network to become visible. Also, in cases where DDSI generates builtin topic information there is no need for durability to align builtin topic information, which saves bandwidth. Solution: Durability will not align builtin topics in case ALL DDSI services generate builtin topics and no native networking services are configured. To force DDSI to generate builtin topics DDSI can set their value set to TRUE. In all other cases durability will align builtin topics to ensure backwards compatibility.
OSPL-4596/ 12954 | A sample predating the oldest sample in the history of a TRANSIENT or PERSISTENT instance could overwrite a newer sample Due to a fault in the mechanism used to insert a sample in the history of a TRANSIENT or PERSISTEN instance, a sample predating the oldest sample in the history would replace the oldest sample instead of being discarded. This would cause late-joining readers to observe an inconsistent history. Solution: The mechanism has been fixed to properly order the samples, so the oldest sample will be discarded when it doesn't fit in the history instead of overwriting the oldest sample.
OSPL-4596-1/ 12954 | After durablity alignment of a dispose_all message only the first instance is NOT_ALIVE_DISPOSED When the durability service needed to align a fellow, a stored dispose_all message was only sent to the first instance for the topic. The dispose_all sample for following instances was incorrectly marked as duplicate because it only tested for writerGid, writeTime and sequenceNumber. Solution: The durability service now also checks samples for keyvalues before marking as duplicate.
OSPL-4596-2/ 12954 | After durability alignment of a dispose_all message and a delete_dataWriter the instance_state does not go to NOT_ALIVE_NO_WRITERS When the durability service needed to align a fellow with a dispose_all message, an implicit registration message is created for a NIL writer. This NIL writer was never removed causing the dataReader instance_state to remain ALIVE. Solution: The durability service now also sends an implicit unregister message after it sent a implicit register for a NIL writer.
OSPL-4596-3/ 12954 | When a dataReader instance_state is NOT_ALIVE_NOWRITERS and it receives a dispose_all the instance_state does not transition to NOT_ALIVE_DISPOSED When a dataReader is in NOT_ALIVE_NOWRITERS instance_state and the last action was TAKE the instance pipeline is destroyed. The group updates it's state when a dispose_all message is received, but could not forward it to the dataReader. The dataReader instance_state did not change. Solution: The group now checks all dataReader instances, when a dataReader has NOWRITERS implicit registration and unregister messages are send so that the instance pipeline is reconstructed and destroyed after the dispose_all is received by the dataReader.
OSPL-4614/ 12392 | Durability does not handle merge policy correctly in some cases with terminating and (re)connecting fellows If durability detects a fellow is terminating, it removes the fellow from its administration. However, when receiving a new message from the fellow after it has been removed, resulted in adding the fellow to the administration again (even though the fellow is already terminating). This triggers faulty merge actions that cannot be completed. In case a merge action needs to be performed, durability sometimes needs to wait until to fellow to merge with reaches a certain state. Durability periodically checks whether that state has been reached. However, when the fellow terminates before it reaches that state, durability continues to wait for the desired fellow state even though it is clear that the fellow will never reach that state. When durability decides to remove a given fellow from the administration, it needs to check whether the 'merge state' of its name-spaces need to be cleared. This is required to ensure that a merge action is triggered once a new master is elected after the original one disappeared. A potential dummy fellow parameter (with no name-space information) was used in some cases to determine the name-spaces that require resetting. Obviously, name-space information may be missing from such dummy parameters causing name-space merge-states not to be reset. As a result durability may conclude that no merge action is required when a new master is elected. Solution: To prevent adding terminating fellows, the various paths that lead to adding a fellow to the administration have been modified to refrain from adding it if the fellow is in terminating or terminated state. The algorithm has been modified to cancel the merge when the fellow terminates or gets disconnected before it reaches the desired state. The actual fellow that is removed and not the dummy one is now used to determine further actions.
OSPL-4777/ 12989 | A deadlock can appear when durability tries to use the KV store during initial alignment, which causes durability to halt forever During initial alignment access to the KV store may be required. In this phase of the process two threads a competing for two resources, the durability administration and the store. These threads try to lock the resources, but in a different order. This could lead to a deadlock of the durability service. Solution: The KV store does not require a lock on the durability administration anymore. This will prevent the deadlock.
OSPL-4800/ 12990 | Multiple Ctrl^C can cause a crash in the exit-request handler. Termination requests received in rapid succession could cause a crash in the exit-request handler. Solution: The handlers installed by services are now executed only once.
OSPL-4896/ 13015 | The durability persistentDataListener thread failed to make progress when using the KV store, causing the system to terminate and execute its failure action. The KV store uses transactions to persist data. In case there are many samples to persist, the transaction can take a very long time. This may even outlive the time to assert liveliness. When the time to complete such transaction exceeds the time to assert liveliness the reposnsible thread is declared dead and no leases will be renewed anymore, causing the system to execute its failure action. Solution: To prevent that the persistentDataListener thread cannot make progress two improvements have been implemented. The first improvement is to use the liveliness expiry time instead of the heartbeat expiry time to decide if assertion of liveliness has succeeded or not. The first is typically larger than the second, causing the system to implement a more relaxed liveliness assertion policy. The second improvement is to ignore liveness checking in case of potential intensive operations on the KV store such as commit and delete.
OSPL-4916/ 13019 | OSPL Source build required MICO and had kvstore library names incorrect Customers with access to OSPL Source Build noted a dependency on MICO for building source code and that some libraries links were incorrect. Solution: MICO is now optional and links named correctly.
OSPL-4920/ 13020 | When networking compression is used then occasionally an error "Received incorrect message" is reported. When compression is activated in the networking service and when a compressed network frame that is received contains user data messages for which the type is not or not yet known on the node then the networking service is not able to de-serialize that user data message and should skip this message and continue with the next user data message in the frame. However in that case the buffer administration is not correctly updated resulting in the reported error and the rest of the frame to be dropped entirely. Solution: The buffer administration has to be updated correctly when skipping a user data message for which the type information is not known.
OSPL-4938/ 13038 | Overflow for network queue resulted in a stackoverflow during cleanup of network reader Unregister messages were not being obeying max queue size. Solution: Changed check for message size to reject a message when queue is equal or greater than max queue size as unregister messages can increase the queue size beyond max size.
OSPL-4942/ 13042 | Reason for termination of domain not reported in all situations The splice-daemon attempts to clean up shared resources of processes that terminated without cleaning them up. If it fails to do so, it does not report anything in the log files in some situations before stopping the domain. Additionally, if the cleaning up did not complete within 1 second, the splice-daemon assumed that cleaning up had failed. Solution: Extra logging has been added to ensure the reason for stopping is clear for users. Furthermore, the time out for cleaning up has been slaved to the existing lease expiry time-out (//OpenSplice/Domain/Lease/ExpiryTime) instead of a fixed period of 1 second.
OSPL-5020/ 13068 | Inconsistency between report level verbosity and reports for FATAL and CRITICAL verbosity Reports at levels FATAL and CRITICAL are emitted as "FATAL ERROR" and "CRITICAL ERROR" respectively. This is not consistent and causes open and close tags with whitespace included (e.g., "<FATAL ERROR>...</FATAL ERROR>" for the report-plugin. Solution: The reports are now emitted with text FATAL and CRITICAL, corresponding to the verbosity level.

## 6.4.0p7

Report ID. | Description
--- | ---
OSPL-4384/ 12820 | Nested IDL modules not properly handled by the C++ RMI compiler With rmipp, the handling of nested IDL modules was generating incorrect code. Solution: A bug in the rmipp code generators has been fixed, so that nested IDL modules map properly onto nested C++ namespaces.
OSPL-4517/ 12882 | Deadlock in listenerEvent when terminating domain and calling delete_contained_enties A deadlock could occur when an application created a domainParticipant with listeners and the domain was terminated while the application called deleted_contained_entities. The listernerEventThread would remain in infinite wait for never signaled waitset, because notify fails due to no longer running splice daemon. Solution: The listenerEventThread now has a polling wait loop, allowing it to detect stop requests.

## 6.4.0p6

Report ID. | Description
--- | ---
OSPL-4046/ 12643 | The cmsoap service crashes when there is no network connection present at startup of the service. The cmsoap service tries to determine the IP address through which it can be reached. These IP addresses are set in the user data field present in the DCPSParticipant builtin topic which enables other tools to connect to the soap service. However when no IP address a crash occurs because of access to uninitialized memory. Solution: When the cmsoap service cannot detect an IP address it should use the loopback IP address instead.
OSPL-4079/ 12677 | The write method incorrectly returns TIMEOUT in case there are not enough resources available or can be freed in time. When the write method detects that there are not enough resources available and it will not be possible that resources will be available in time, e.g. max instances exceeded is should return OUT_OF_RESOURCES instead of TIMEOUT. Solution: In case the max instance resource limit is exceeded return OUT_OF_RESOURCES
OSPL-4410/ 12826 | Deadlock in parallel demarshalling termination When starting and stopping parallel demarshalling within a short time window it was possible that the parallel demarshalling termination was stuck in a deadlock. Not all spawned threads would terminate, because the terminate flag was reset before all parallel demarshalling threads were operational. Solution: The API set_property function with property name parallelReadThreadCount is now blocking until all parallel demarshalling threads are started and operational and the terminate flag is now reset upon (re)start of parallel demarshalling.
OSPL-4464/ 12864 | "FATAL ERROR Open Splice Control Service status monitoring failed. Exiting." logged when sending signal to blocking OSPL tool. When "ospl -f start" was executed and a signal was sent to the OSPL tool, a FATAL ERROR message was logged. Not a real FATAL ERROR because the part of the OSPL tool that monitored the liveliness of the splice daemon wasn't aware of incoming signals and logged a FATAL ERROR while the splice daemon terminated normally. Solution: Made the part of the OSPL tool that monitors the liveliness of the splice daemon aware of termination caused by a received signal.
OSPL-4490/ 12859 | When DataWriter exits unnaturally LivelinessStatus is incorrect. When DataWriter exits unnaturally the LivelinessStatus was updated incorrectly when the DataWriter was Alive, this caused an illegal state transition. Solution: LivelinessState change for unnatural DataWriter exits now use the last known state before transitioning to DELETED.
OSPL-4509 | DDSI2E now accepts DDSI2 configurations Solution: DDSI2E required that the configuration in the OpenSplice XML configuration file was tagged "DDSI2EService", but this made it impossible to switch to the DDSI2E service without changing the configuration file. DDSI2E now also accepts configurations under the DDSI2Service tag.

## 6.4.0p5

Report ID. | Description
--- | ---
OSPL-878/ 10549 | The 'ospl start' command can exit before the DDS Domain is up. On somewhat slower systems, the 'ospl start' command can exit before the DDS Domain is up. This would mean that creating a DomainParticipant immediately after 'ospl start' can fail. Solution: The 'ospl start' command now waits until the DDS Domain is up before exiting.
OSPL-4333/ 12801 | Java language binding fails with multiple package redirects Java language binding fails when multiple packages are redirected and a type containing a type from a redirected package is registered. Solution: Pass all redirect instructions for all types to the Java language binding.

## 6.4.0p4

Report ID. | Description
--- | ---
OSPL-4116 | A potential crash could occur when durability terminates The durability service notifies the splice daemon too early in case durability is about to terminate. This could lead to a situation where the splice daemon already destroys shared memory while durability is still busy cleaning up objects and thus acessing the shared memory. This could lead to a system crash. Solution: The durability services will now notify the splice daemon after it has cleaned up all objects and no access to shared memory is needed any more. Now the splice daemon can safely destroy the shared memory.
OSPL-4250 /12744 | JNI attach listener crash results in OpenSplice crash without any error report When a crash occurs inside JNI call that attaches the listener thread to the application, OpenSplice crashes without a proper report Solution: A proper error report is now generated so the customer knows what went wrong.
OSPL-4251 /12753 | Late joining readers not getting complete historical data when more than one networking service configured When more than one networking service is configured duplicate message may be received. A reader will filter these duplicate message. However the group does not filter these duplicates and when the corresponding Topic QoS has a history depth greater than 1 this may result in that the duplicate message are stored in the group. This may cause that a late joining reader does not receive the correct number of samples. Solution: The group should check if a duplicate message is received and drop the duplicates.
OSPL-4270 /12765 | DDSI2 not supporting QoS changes not documented The DDSI2 networking service does not (yet) support QoS changes, instead silently ignoring them, but this was not mentioned in the documentation. Solution: This limitation is now stated clearly in the DDSI2 release notes.
OSPL-4320 | Java 7 linux 64 bit crash with Listener example When running the Listener example under linux 64 bit with java 7 it could crash. Solution: The default listener stacksize is 64k, for java 7 this needs to be at least 128k as a result of this the default listener stacksize is increased to 128k
OSPL-4342/ 12807 | Deserialisation issues with Java CDR-based copy-out, high-performance persistent store and RnR binary storage The CDR serialiser used for Java CDR-based copy-out, the new high-performance persistent store and RnR binary storage could introduce incorrect padding in the CDR stream under some circumstances. To a reasonable approximation, this requires a type of unbounded size, or one where the maximum size is several times the minimum size, AND where the content of the data results in a serialised size larger than 16kB, AND where a string, sequence or array with alignment of less than 8 bytes requires a new block at a time the CDR stream is not aligned to a multiple of 8 bytes. Solution: The CDR serialiser now maintains the alignment of the stream when it switches to a new block.
OSPL-4366 | Durability service may crash during termination During termination, the durability service stops its threads and cleans up its administration. Due to the fact the main thread cleans up some part of the administration that is used by the lease thread before ensuring that thread stopped, that thread may access already freed memory which may cause the service to crash. Solution: The main durability service thread now ensures the lease thread has stopped before freeing the administration.
OSPL-4390 | SOAP service may crash when concurrently using and freeing the same entity The SOAP service allows ADLINK tools to connect to a node or process remotely. Due to the multi-threaded nature of the service, multiple requests can be handled concurrently. When the same entity is concurrently accessed and freed during two or more requests, the service may crash due to the fact one of the threads is trying to access already freed memory. Solution: The internal API of the SOAP service has been re-factored to claim an entity when it is used and release it afterwards. When an entity is freed when one or more claims are still outstanding, new claims are denied and the actual deletion is postponed until all of the outstanding claims have been released.
OSPL-4421 | Error reports about instance handles are mixed up Each call that has an instance handle parameter as well as a sample parameter on the DataWriter entity (like for instance the write call), validate whether the provided instance handle belongs to the DataWriter and if so validates whether the key-values in the sample match the key-value that is associated with the instance handle. If one of these conditions is not true, an error is reported and the call fails. However, the errors that are printed in the two failure cases have been mixed up causing the wrong error message to be reported in both these cases. Solution: The error reports have been updated to match the actual error that occurred.

## 6.4.0p3

Report ID. | Description
--- | ---
OSPL-4286 12771 | The read_w_condition may incorrectly return no data when a read_next_instance_w_condition is called before. The read_next_instance_w_condition may incorrectly set the no data property of the associated query to indicate that no data matches the query, This may cause that a following read_w_condition may return no data when data is available. Solution: The read_next_instance_w_condition should only set the no data property of the associated query when a complete walk is performed on all the instances.
OSPL-4327 12797 | A crash of the durability service may occur when samples containing strings with non-printable characters are stored in the XML persistent store. When the persistent XML store contains samples with strings containing non-printable characters then the durability service by crash because the layout of the XML storage file is not as expected. Solution: The XML serializer used by durability to serialize the samples for the XML store should escape the non-printable characters.

## 6.4.0p2

Report ID. | Description
--- | ---
OSPL-4173 12731 | The notification of a sample lost event by the networking service may result in a crash of the networking service. When the networking service detects that samples have been lost it tries to notify the corresponding readers of this event. The sample lost event is recorded in the status of the reader. However there are internal readers used by Opensplice which do not have an associate status object causing the crash of the networking service. Solution: Apply all internal readers with an status object.
OSPL-4269 12760 | Ospl reports an error if no persistent file is present and using KV Store. With KV Store, at ospl startup, if no persistent file is available, ospl reports an error: getset_version: read of version failed. Solution: The error message has been fixed. It was not required. No behavior change.
OSPL-4319/4330/4344/4346 12778/12779/12808 | Crashes due to shared memory allocator issue A refactoring of common code introduced an issue in the shared memory sub-allocator dealing with allocating "large" objects that could result in crashes or reports of heap corruption under high-load scenarios. For crashes, this typically (but not necessarily) involves stack traces involving the "check_node" function. Solution: The specific changes have been reverted until they can be corrected and re-tested.
OSPL-4322 12747 | Nullpointer exception when creating a reader/writer using the Tuner When using the Tuner and creating a reader/writer it is possible to get a nullpointer excetion when selecting a different topic from the pulldown menu. Solution: The nullpointer is now being caught and will no longer appear.

## 6.4.0p1

Report ID. | Description
--- | ---
OSPL-3445 12408 | Inconsistent behaviour of service when handling signals. The service should handle asynchronous signals like SIGQUIT or SIGTERM as normal termination requests which should not trigger an failure action. However the handling of these termination request is not correct, which may result in a normal termination or may result in an exception which triggers the failure action. Solution: When a service receives a termination request signal like SIGQUIT or SIGTERM it will initiate a normal termination of the service and will not trigger an failure action. When the service receives a synchronous signal like SIGSEGV as result of an exception or send asychronously to the service then the service should detach from shared memory and trigger the failure action.
OSPL-3695/ 12553 | Shared memory consumption would increase to unacceptable high levels when using KV persistency When KV persistency is enabled shared memory consumption would reach unacceptable high levels. This was caused by the following two phenoma. First, the StoreSessionTime configuration option was not respected causing the system to store KV samples as long as there are samples available. Second, an inefficient algorithm to store samples on disk was used, resulting in (expensive) disk access for every sample. Together, these phenoma caused the system to pile up samples in memory that cannot be stored on time. Solution: A more efficient algorithm is used to store samples on disk, resulting in disk access for a set of samples instead of an individual sample. This will boost performance when writing samples to disk. This reduces the risk to pile up data in memory that caused the unacceptable high level of memory consumption. Also, the StoreSessionTime is respected.
OSPL-3866 | On windows, setting a long lease time in the configuration results in an large error log during ospl stop When a termination request was made, some services with long lease times set in their configuration would generate on windows a large amount of error messages, as the termination was not acknowledged during the lease time. Solution: The sleeping lease thread from ospld, durability and soap are signalled to stop during the sleep in case of a termination request.
OSPL-4075 12678 | The network partition mapping of the expression . does not function correctly. When the network partition mapping expression . is evaluated to find the best match the the global partition is selected instead of the configured network partition. Solution: Exclude the global partition from the search for a best matching network partition and select the global partition only when no other network partition can be found that matches the mapping expression.
OSPL-4205 12740 | The read_instance method sometimes returns ALREADY_DELETED but the reader entity has not been deleted. This situation occurs when the instance that is referenced by the instance handle supplied to the read_instance has been deleted. For example when the instance has become disposed and unregistered. In that case the instance handle becomes invalid. The return code ALREADY_DELETED is incorrect and should be BAD_PARAMETER to indicate that the instance is not valid anymore. Solution: When the read_instance detects that the provided instance handle has become invalid then return BAD_PARAMETER.
OSPL-4245 12748 | Linker error in custom library compilation for CORBA C++ cohabitation with V6.4.0 DDS_CORE is not set anymore in custom lib environment so cannot be used anymore by the linker. Solution: Changed custom lib makefiles by replacing DDS_CORE environment setting by ddskernel.

## 6.4.0

Report ID. | Description
--- | ---
OSPL-31 | idlpp did not generate valid java-code when a union had a case called 'discriminator' When an idl-union contained a case called 'discriminator', the generated java-code would contain two conflicting definitions for the 'discriminator' method. This method is always included in a class generated from a union to obtain the value of the union-discriminator. With a discriminator case an additional discriminator method is added with the same signature that returns the value of the discriminator field. Solution: The solution is according to the IDL to Java specification which prescribes that the function returning the discriminator-value should be prefixed with a '_' if the union contains a case called 'discriminator'.
OSPL-1631 11194 | Reporting does not include timezone information In scenario's where nodes are joining and/or leaving a domain The timestamps in the default info and error logs did not include timezone information. When the timezone of a system is altered while OpenSplice is running, the reports may appear out of order. Solution: To resolve any uncertainty the locale-dependent abbreviated timezone has been added to the date format.
OSPL-1705/1713/1714 | Durability service XML persistency handles topics with string keys incorrectly If multiple string keys exist for a Topic that is being persisted by the durability service, samples for different instances may be interpreted as samples for the same instance causing potentially samples to be overwritten while they both are supposed to be maintained. Secondly, if one or more key-values contained new-lines, storage in XML was also done in a way that prevented the data from being republished correctly after system restart. Finally, if the string key was matching the "" closing tag in the XML implementation, samples matching this key would not be persisted in all cases. Solution: Key-values are now escaped when storing them in XML. The change is backwards compatible meaning that the new version can cope with old persistent stores.
OSPL-2360 | Strange error message from DDSI2 for truncated packets on Windows On Windows, when a message is truncated because there is insufficient receive buffer space available, the error message produced by DDSI2 would be somewhat confusing, because Windows reports this as an error whereas DDSI2 assumed POSIX behaviour of treating this as an unusual situation rather than an actual error. The behaviour of DDSI2 was ok, in that it discarded the message regardless of the platform. Solution: The error reported by Windows is now recognised and reported properly.
OSPL-2485 | Idlpp generated invalid java for a union with only a default case When a union only contained a default-usecase, java-code was generated which did an invalid check on discriminator and therefore did not compile. Solution: The discriminator-check is not valid when there is only a default case. The applied fix removes the check in this scenario.
OSPL-2519 | OS_INVALID_PID is accepted as a valid processID in the abstraction layer The OS abstraction layer functions os_procDestory and os_procCheckStatus accepted OS_INVALID_PID as a valid input. Especially in os_procDestory, which is able to send signals to processes, this could have caused undesired behavior. Solution: The functions os_procDestory and os_procCheckStatus now return invalid when processID OS_INVALID_PID is passed.
OSPL-2616 | Internal change: File extension change for files generated for Corba co-habitation CPP When generating from your idl file, the tao idl compiler would generated .i. Solution: For the inline files these have now been changed to the default file extension used by TAO, which is .inl.
OSPL-3042 | The library versions of sqlite and leveldb supplied by Opensplice may conflict with system supplied builds. An Opensplice delivery contains particular versions of the sqlite and leveldb libraries on which Opensplice is dependent. These libraries are installed in the Opensplice install directory. owever the versions of these libraries may conflict with newer versions which are available on the system on which Opensplice is installed. Solution: The names of the supplied sqlite and leveldb libraries are made Opensplice specific by adding an ospl postfix.
OSPL-3151-1 | Receiving unidentifiable duplicate messages during durability alignment when using DDSI2 When using DDSI2 it was possible that during durability alignment a duplicate message was received which could not be identified as a duplicate because the sequencenumbers were different. DDSI2 increments the sequencenumber for each message it sends, this sequencenumber is unrelated to the message sequencenumber which is not communicated to the receiving node when using DDSI2. Solution: Communicate the message sequencenumber to the receiving node. Add a ADLINK specific flag to the SPDP to indicates that the message sequencenumber is send. Add the message sequencenumber to all messages transferred using DDSI2. Based on the existence of the ADLINK specific flag copy either the message sequencenumber or the DDSI2 sequence number into the internal messages.
OSPL-3151-2 | Publication/Subscription matched logic incorrect On every non dispose Publication/Subscription matched message (with compatible reader/writer) the Publication/Subscription matched count was incremented. Only with a dispose Publication/Subscription matched message the Publication/Subscription matched count was decremented. Solution: Now the Publication/Subscription matched count is only incremented when it's noticed for the first time or when QoS settings have become compatible when it was not before. The Publication/Subscription matched count is decremented on dispose Publication/Subscription matched message or on Publication/Subscription matched message when QoS settings are no longer compatible.
OSPL-3452/ 12411 | Limiting sample size with DDSI2 Solution: DDSI2 now allows setting an upper limit to the allowed size of the serialised samples, as an added protection mechanism against running into memory limits. The limit is applied both on outgoing and on incoming samples, and any dropped samples are reported in the info log. By default, the limit is 1 byte short of 2 GiB.
OSPL-3462 | idlpp issues compiling in standalone C++ mode Description: idlpp generated uncompilable code from anonymous sequence of sequences of basic IDL types following typedefs of those same basic types. It also produced incorrect definition of anonymous array slice types. Solution: idlpp generates the correct code in these circumstances.
OSPL-3463 | Durability using KV persistency may report error while backing up Description: When durability has been configured to use KV persistency and is backing up the persistent store an error may be reported when no data exists yet for a given name-space even though nothing goes wrong. Solution: The error message is not reported any more.
OSPL-3512/ 12427 | Potential crash during initial alignment after a dispose_all_data call. Description: The dispose_all_data call creates specific samples that were not compatible with durability alignment. The durability service could not handle these samples, while there are possible scenario's where these samples get stored in a persistent store. The service incorrectly forwarded all initial alignment data to the networking service, which could result in a crash since it could also not handle these samples, which are meant for local delivery only. A crash could also occur if the dispose_all_data sample was the first sample to be received, which could happen because of order reversal during alignment or in combination with lifespan QoS on the corresponding data. Solution: The durability service was modified to only exchange initial alignment data over the durability partition and not by directly delivering it to a networking service. Order reversal during initial alignment was changed such that samples are ordered first by timestamp, then by writer (instead of the other way around). Support was added for handling the case where it is still the first to be received, i.e. when the lifespan of data samples has expired.
OSPL-3520 | Opensplice host and target type for Linux OS's has changed from x86.linux2.6 to x86.linux and x86_64.linux2.6 to x86_64.linux Description: The installation path will be affected by this change, the top level directory on a linux platform would have been <ARCH>.linux2.6 it will now be <ARCH>.linux Solution: Before - PrismTech/OpenSpliceDDS/V6.3.2/HDE/x86_64.linux2.6/ Now - PrismTech/OpenSpliceDDS/V6.4.0/HDE/x86_64.linux/
OSPL-3587 | Durability exposes and aligns local DDSI2 partitions Description: The DDSI2 service creates some local partitions formatted as '__NODEBUILT-IN PARTITION__' that are purely local to the federation. The durability service however aligns them with others causing the local data to be exposed to other federations as well. Solution: The durability service now checks whether a partition has the aforementioned format and refrains from exposing them to other durability services.
OSPL-3601 | Extend support for network service data compression and durability datastores. Description: Windows, Enterprise Linux and Solaris distributions now include support for zlib, lzf and snappy compressors in the networking service, and for LevelDB (not windows) and SQLite (not solaris) datastore plugins for durability. Solution: Extra platform support added.
OSPL-3603 | Various internal trace messages are reported in ospl-info.log Description: The ospl-info.log shows various messages about internal threads being started and stopped. These messages make no sense nor are they relevant to users. Also these message makes it harder to find the actual messages that are important. Solution: These internal messages are no longer reported.
OSPL-3625/ 12529 | Spliced could crash when terminating under abnormal circumstances Description: The spliced exit handling must stop all OpenSplice threads accessing shared memory before detaching from the shared memory. However, if processes have been killed using the KILL signal, this did not always happen correctly because spliced would incorrectly assuming the shared memory to still be in use. Solution: The termination code now ensures thread termination.
OSPL-3644 | Durability service may perform alignment multiple times Description: The durability service aligns sample per partition-topic combination and in some cases could perform this alignment multiple times. Solution: The durability service now checks actively whether it already performed alignment for a given partition-topic combination before initiating the alignment.
OSPL-3755-1 12573 | Durability service does not terminate in time. Termination hung because listener termination is unable to stop with active listener actions. Listener actions remained active because they were unaware of termination. Solution: Listener actions are now aware of termination and stop.
OSPL-3755-2 12573 | Services are able to outlive the splice daemon When the splice daemon terminated without the use of the ospl tool, it was possible that a service outlived the splice daemon. Solution: The splice daemon now kills all services which remain alive after the service terminate period elapsed.
OSPL-3755-3 12573 | After failure action systemhalt it was possible that shared memory was not cleaned-up/deleted. When a service failed with failure action systemhalt set it was possible that shared memory and key-file were not cleaned-up/deleted. This occurred because the splice daemon incorrectly assumed that the died service was unable to decrease the kernel attach count upon its termination, the attach count was decreased twice causing failing calls to shared memory cleanup/deletion. Solution: The splice daemon no longer assumes died services are incapable to preform proper termination, it now only decreases kernel attach count during termination when all services are terminated.
OSPL-3761/4002 /12570 | OSPL_LOGPATH included in host:port check for tcp logging mode Description: Log file names are checked for host:port combinations twice. The second check is done when the path prefix and log file name are concatenated, which leads to incorrect behavior if the value specified in OSPL_LOGPATH contains a colon. Solution: Split prefix and log file name before checking for a host:port combination.
OSPL-3786 | Latency spikes on reliable channel Description: On some occasions the latency on a reliable channel would spike periodically (at most once per resolution) due to a mechanism used to limit bandwidth kicking in even when the limit didn't need to be enforced. Solution: The logic has been enhanced to only activate the mechanism when bandwidth needs limiting.
OSPL-3791/ 12576 | More strict SAC idlpp sequence support functions creation Description: SAC idlpp creates support functions for sequences (like allocbuf()). These are created when an idl file defines an actual sequence (like sequence) but also when the type is related to a Topic (in other words, '#pragma keylist' is added to the type) to be able to create readers and writers. When idl file A contains a topic Type and idl file B includes A and defines a sequence of that topic, then sequence support functions are created in both A and B result files. The effect is that the generated code doesn't compile due to 'multiple definitions'. Solution: When creating a sequence, check if the sequence is within the same file as the type. If not, check if the type has a keylist related to it. If so, then the type is a topic and the sequence support function have already been created: do not create them a second time.
OSPL-3851/ 12627 | DDSI uses more ports beyond those specified in the Deployment Guide Description: The Deployment Guide describes exactly which set of ports is used by DDSI and how this set can be configured. Some versions of OpenSplice (6.3.x except 6.3.0) additionally used two or more (one more than the number of configured channels) kernel-allocated port numbers strictly for transmitting data. Solution: The use of the additional ports has been eliminated and the behaviour is in line with the deployment guide again.
OSPL-3853 | Improve the performance of the waitset wait operation. Description: The performance of the waitset wait operation can be improved by evaluating the conditions trigger status within the kernel layer. Solution: Evaluate the trigger status of the conditions attached to the waitset within the kernel layer.
OSPL-3860 | Remove unnecessary allocation of a timestamp when updating the deadline administration. Description: When updating the deadline information of a writer or reader a new timestamp is allocated. By using the timestamps already present in the corresponding sample the extra timestamp allocation can be removed. Solution: Use the timestamps present in the sample when updating the deadline information of the corresponding instance.
OSPL-3861 | Improve the performance of the read/take operations by updating the corresponding administration without extra memory allocations. Description: A read or take operation will update the reader administration. For this update memory is allocated. The performance of the read or take operation can be improved by removing the extra memory allocation. Solution: Update the reader administration without allocating temporal memory during this update.
OSPL-3993 | The Java QosProvider constructor may throw a NullPointerException Description: When a parse-error occurs, the Java constructor explicitly throws a NullPointerException. This is not in line with the other API's and the language-mapping. Solution: The QosProvider constructor doesn't throw a NullPointerException anymore. Instead the constructor always succeeds and subsequent invocations on the QosProvider will return DDS.RETCODE_PRECONDITION_NOT_MET.The API furthermore has more thorough error-checking within JNI. If an exception occurs, DDS.RETCODE_ERROR is returned instead of an exception.
OSPL-3997 | Networking defragmentation buffers refcount issue Description: Static analysis of RTnetworking code revealed a potential issue with the administration of the defragmentation buffers. An atomically modified counter was accessed without atomic access, allowing a potential race-condition. Solution: The counter is correctly accessed now.
OSPL-4007 /12660 | Workaround for issue when using Jamaica VM Description: When OpenSplice is used with JamaicaVM, JamaicaVM crashes due to a differnece in how a jni call to NewStringUTF is handled. Solution: A workaround is implemented in OpenSplice to assure that JamaicaVM does not crash anymore.

## 6.3.3p3

Report ID. | Description
--- | ---
OSPL-3887 | SAC QoS-provider doesn't return DDS_RETCODE_NO_DATA When a QoS cannot be found, the SAC QoS-provider returns DDS_RETCODE_ERROR instead of DDS_RETCODE_NO_DATA. Solution: The API has been changed to return DDS_RETCODE_NO_DATA when a QoS cannot be found.

## 6.3.3p2

Report ID. | Description
--- | ---
OSPL-3732/ 12565 | DCPSPublication built-in Topic published unnecessarily Even when publication of built-in topics is disabled through the configuration file, the DCPSPublication instance that corresponds to a DataWriter is still write-disposed and unregistered as volatile data when the DataWriter is deleted to allow DataReaders to clean up the resources associated with that DataWriter. However, if no instances are registered by a DataWriter at the time it is deleted, there is no need to publish it. Solution:If built-in topics are disabled through configuration and no instances are registered by a DataWriter when it is deleted, no more write-dispose and unregister of the DCPSPublication are performed.

## 6.3.3p1

Report ID. | Description
--- | ---
OSPL-2452 | Sample loss using DDSI2 and readers with resource limits Description: DDSI2 could silently drop samples destined for readers at their resource limit, rather than blocking the writer and/or notifying the application or writing messages in the log. Solution: DDSI2 now blocks the data stream until the reader accepts the data, but for an unresponsive reader, it will eventually drop the data anyway. When this happens, a message to that effect will be logged.
OSPL-2823/3626/ 12526 | Sample lost administration memory leaks and unlocked modifications Description: The internal administration related to the sample lost mechanism would leak some memory each time it was accessed. Also it could be accessed by multiple threads at the same time without any locking, which could potentially lead to undefined behaviour. Solution: The issues were resolved by freeing the administration when required to prevent memory leaks, and only allowing access while a lock is taken.
OSPL-2960/ 12243 | Improved Durability alignment through DDSI2 Description: The Durability Service assumes that all writer/reader connections are available when one is discovered. DDSI2 however discovers one by one. This means that Durability sometimes sends data which DDSI2 will drop (because there's no related connection yet), which will cause Durability to never complete alignment. Also, DDSI2 had a problem that would sometimes increase the discovery time dramatically, which would trigger the Durability alignment issue. Solution: The Durability now creates all readers before enabling the listeners connected to them, meaning that required writer/reader connections are discovered before acting on incoming data. The DDSI2 service increases the writer heartbeat when a new reader is detected, making the writer/reader connection discovery more robust and quicker.
OSPL-3186 | DDSI2 could use freed memory in its reordering of incoming samples Description: The sample re-ordering mechanism internal to DDSI2 could use freed memory under very particular circumstances, requiring the number of buffered samples to have reached its maximum size as well as a particular order of arrival of out-of-sequence samples at the high end of the sequence number range. This is unlikely to occur in normal circumstances, using networks of "normal" reliability (such as Ethernet) and with receivers that generally keep up with the data flow. Solution: The algorithm has been adjusted to avoid referencing freed memory.
OSPL-3187 | DDSI2 fails to work with small WHC water mark settings Description: DDSI2 would completely fail to work when the WHC water marks were set very low. More precisely, if DDSI2 would block because the number of outstanding unacknowledged messages (N_UNACK) exceeded the high water mark, and its dynamic message packer had buffered so many samples that the readers would not yet be able to acknowledge enough samples to drop N_UNACK below the low water mark, communication would stop. This also affects endpoint discovery. One of the consequences of the inability to operate with low water mark settings meant that it was impossible to operate DDSI2 in the safest configuration, where each sample must be acknowledged before sending the next, thereby potentially causing many more retransmissions. This is especially problematic if the network is unreliable, or the receivers are unable to keep up with the influx of data. Solution: The samples are now always flushed to the network before blocking.
OSPL-3470/ 12422 | Compatible typeSupport is rejected without cause Description: When a type was being registered that conflicted with a type that was registered earlier (for example because they had a conflicting keyList), then a PRECONDITION_NOT_MET was being returned, but no descriptive message was included as to the root cause. Solution: A message is now written into the error log and also accessible through the ErrorInfo interface.
OSPL-3509 | Minimum networking ThrottleLimit is based on networking FragmentSize Description: When the fragmentsize > throttlelimit, a scenario with high load can cause the throttlevalue to go below the fragmentsize. At that point networking is unable to send any messages. Solution: The minimum value of the "OpenSplice/NetworkService/Channels/Channel/Sending/ThrottleLimit" config element is now based on the "OpenSplice/NetworkService/Channels/Channel/FragmentSize" value.
OSPL-3528/ 124264 | Excessive Lease manager logging Description: In some cases where a writer was using the autounregister_instance_delay, the info log file would be flooded with messages stating that the leaseManager did not wake up in time. Solution: Logging has been cleaned up.
OSPL-3596 | RnR storage has problem replaying types containing arrays The RnR storage does not correctly handle types which contain bounded array's or sequences. When the array or sequence contain references then the corresponding reference counts are not properly handled. Solution: The algorithm now correctly updates the reference counts when objects are copied. This includes references contained in bounded array's and sequences.
OSPL-3636/ 12534 | Communication does not restart after ethernet cable unplug/replug Description: When the network cable is unplugged and then replugged the reliable communication is not restored when reconnect is enabled and discovery is disabled. Solution: When discovery is disabled the send component of a channel detects the network communication problem and the recovery of the network communication. This status change should also be communicated to the receive component of the channel which should reset it's status in case a reconnect occurs.

## 6.3.3

Report ID. | Description
--- | ---
OSPL-3281/ 12378 | To monitor the behaviour of the networking service and the durability service additional statistics of the internal queues have been added. Description: The networking service maintains internal queues to provide reliability and fragmentation/defragmentation. The durability service maintains a queue for persistent data that has to be stored on disk. To monitor the behaviour of these queues extra statistics have been added which will be available through the C&M API. Solution: For the networking service additional statistic counters are available on the queues used by the resend administration (ResendQueue), the reorder administration (ReorderQueue) and the network queue between the writers and the networking service. For the durability service statistic counters are now on the persistent data queue (GroupQueue)
OSPL-3579 | Durability service may crash when aligning historical data Description: In some cases while aligning historical data with another durability service, some variable in an internal algorithm may not be initialised, but used and freed later on anyway. This causes undefined behaviour, but mostly leads to a crashing durability service. Solution: The internal algorithm has been modified to initialize the aforementioned variable in any case.

## 6.3.2p4

Report ID. | Description
--- | ---
OSPL-2362/ 11911 | Ownership strength changes in DataWriter's QoS go unnoticed Decreasing or increasing ownership strength would have no effect on ownership strength registered with instances on DataReader. Solution: Take into account ownership strength during evaluation of QoS updates.
OSPL-2480/ 11804 | When an idl files contains "too many" nested modules idlpp crashes when Java code is generated from the idl files. If an IDL file contains "too many" nested modules the IDL preprocessor idlpp crashes when Java is generated. This is because in Java nested modules will lead to the generation of path names containing the names of modules: the deeper the nesting, the longer the path names will become. Because a fixed size container for path names was used, an overflow would lead to memory failure which could result in a crash. Solution: By dynamically allocating the path names there is always enough room available to hold the complete path of a module, thus preventing an overflow.
OSPL-2482 | Removed possible deadlock in d_storeGroupStoreXML if result is D_STORE_RESULT_PRECONDITION_NOT_MET or D_STORE_RESULT_ILL_PARAM Lock on peristent XML store was not unlocked in case of a D_STORE_RESULT_PRECONDITION_NOT_MET or D_STORE_RESULT_ILL_PARAM result. This would have caused a deadlock. Solution: Lock is now always unlocked in all cases.
OSPL-2661 | Crash when using reliable-under-publisher-crash (RUPC) functionality When a publisher node crashes and RUPC is enabled then it appears that a node that has not received all messages from the crashing publisher is not updated by the other nodes. The problem occurs because the announce messages that the RUPC function uses are sent to the wrong network addresses. Solution: The announce messages used by the RUPC protocol have to be sent to all addresses associated with the global partition.
OSPL-3084/ 12328 | C++ copyIn/copyOut code generated from idl containing sequences of anonymous sequences failed idlpp generated invalid code for sequences of anonymous sequences. The copyIn/copyOut routines generated did not recurse into sequences and kept overwriting the base sequence resulting in memory corruption. Solution: Using the loop index to indicate sequence depth during code generation produces copyIn/copyOut routines that recurse into sequences.
OSPL-3085/ 12326 | Cast warning in generated idlpp c++ code due to cast from const pointer into non const pointer The generated c++ code from idlpp contains a copy function for arrays (if present) which cast away a const pointer into a non const pointer. This will cause a warning with strict compiler warnings set. Solution: Generated copy code in c++ for arrays contains now also a const pointer for the from pointer.
OSPL-3222/ 12371 | Available traces for the throttling mechanism enhanced to be less performance intrusive The trace level needed to obtain information on the throttling mechanism could be performance intrusive. Solution: A new tracing category "Throttling" has been introduced for both RTNetworking and secure networking, which allows throttling traces to be enabled separate from the other categories. On level 1 throttling traces are only emitted on change.
OSPL-3280/ 12379 | The domain service heartbeat properties should be made configurable seperately. Currently the properties of the domain service heartbeat are controlled by the settings of the lease element. We want to split this coupling because it is desirable to specify the heartbeat frequency independently. Further it should allow to specify the heartbeat transport priority and the scheduling parameters of the heartbeat sending thread. Solution: Added a Heartbeat configuration item to the Daemon element of the Domain service configuration which allows to specify the frequency (expiry time and update factor) of the heartbeat, the transport priority QoS setting of the heartbeat writer and the scheduling parameters of the heartbeat sending thread.
OSPL-3284/ 12382 | Manual start of networking doesn't allow communication. The kernel group write is only allowed if the number of registered services is equal to the number found in the configuration. This is done to be sure all networking services are up and running before actually doing group writes. Writes before they are up and running are done again later with a resend, but where a manual start of working is done later, communication doesn't occur. Solution: The number of registered services must be equal or greater then the number found in the configuration to perform a write. A manually started, but later networking service will now join the system.
OSPL-3355/ 12382 | When an aligner for a namespace appears and durability services exist that do not have a aligner for this namespace then no conflict is detected and no merge action is triggered, although it should. In the scenario where a durability service has its 'aligner="false"' -property set for a namespace and its last available aligner leaves, the durability service will notice that no aligner is available anymore. When an aligner (re)appears for the namespace the durability service should perform the merge action as specified in the configuration, because the aligner may have "injected" new data in the system. Solution: When the last aligner for a namespace has left, the state for the namespace and the role will be cleared. When a new aligner arrives its initial state for the namespace is set to zero. Because the cleared state differs from the initial state a namespace state conflict is detected as soon as an aligner appears and a merge action is performed (when specified in the configuration).
OSPL-3466/ 12420 | Report plugin configuration not applied to applications In certain scenario's, a user-defined report plugin was only used by OpenSplice services and not by applications using OpenSplice. Solution: The issue was fixed and the report-plugin configuration is now also used by applications

## 6.3.2p3

Report ID. | Description
--- | ---
OSPL-350/ bugzilla-44 | Segmentation fault when writing or registering a sample with a null member in Java saj_cfoiStruct did not check if structObject is NULL, which would result in a segmentation fault when writing or registering a sample with a null member in Java Solution: The saj_cfoiStruct function now checks if structObject is NULL.
OSPL-492/ bugzilla-49 | Invalid conversion of multidimensional arrays from IDL to C# Before invalid code was generated for multidimensional arrays, sequences of arrays, and operations on them for C# Solution: Some functions have been updated and use of snprintf has been removed.
OSPL-2243/ 11714 | Resend of unregister message may cause a crash. When an unregister message is rejected by the RT networking service then the resend of the unregister message may cause a crash because the corresponding instance administration is already freed. Solution: The RT networking service should not reject an unregister message which is consistent with the behaviour of the other readers.
OSPL-2799 | Maximum termination wait time is displayed incorrectly when doing ospl stop When terminating OpenSplice with ospl stop a message appears on the command line with the maximum waiting time. This message was not in line with the possible configured ServiceTerminatePeriod. Solution: The maximum termination time will now be displayed correctly.
OSPL-2789 | Compression may fail on Linux when using a large FragmentSize in RTNetworking When a large FragmentSize was configured in RTNetworking, the service might run out of stack on Linux platforms. Solution: Memory needed for handling the (de-)compression of packets is now (pre-)allocated on heap.
OSPL-2865/ 12165 | RT Networking dies when the status of an unused network interface changes to down. The RT networking service is reported dead when the status of a network interface that is not used changes its status; for example is configured down. This network state change triggers an event within the RT networking service which is not handled correctly which causes that the network service stops updating it's lease. Solution: The function checks the network interface status and correctly handles the network interface status events.
OSPL-3023.1 | Could not add priority_kind to Domain/GeneralWatchdog/Scheduling/Priority in osplconf osplconf did not know about priority_kind for Domain/GeneralWatchdog/Scheduling/Priority. Solution: osplconf metadata is updated.
OSPL-3023.2 | OpenSplice_DeploymentGuide.pdf referred to old style configuration paths OpenSplice_Deployment.pdf instructed the user to use Domain/Daemon/GeneralWatchdog, but user should use Domain/GeneralWatchdog. Solution: Documentation is correct now
OSPL-3023.3 | DDSI2 and DDSI2E services did not recognize both Scheduling element and the priority_kind attribute The parser for both services had no notion of the Scheduling element, while the common code in the user layer requires it in order to work. Solution: The parser code is updated now and the osplconf metadata file is corrected.
OSPL-3053/ 12324 | Crash on deletion of DataWriter. In some cases where a Reader or a Writer with an activated deadline or auto_unregister policy was being destroyed, the leaseManager would still try to notify about missed deadlines or actively send unregister messages to an already partially deleted Reader or Writer. This rarely occurred, but it is clearly unwanted and might crash or corrupt the system. Solution: By now stopping the deadline and auto_unregister algorithms before the actual destruction of the Reader or Writer, this particular sequence of events should no longer occur.
OSPL-3209/ 12368 | Durability may fail to align non-volatile data when configuring delayed alignment for one or more name-spaces With the delayed alignment enabled, durability accepts the introduction of a new persistent data-set in the system even after the start-up phase in case no data has been re-published from permanent storage by any durability service and no application has published any sample so far either. When a new data-set is detected in the operational phase and delayed alignment is required, the durability service marked all partition-topic combinations as incomplete instead of only marking the ones that match the name-space for which delayed alignment is required. As a result the partition-topic combinations that do not belong to the name-space will never be marked as complete again. In case another durability service wants to align from this durability service after that, it concludes that the set of data over there is incomplete, where it actually is complete. This leads the alignment process on the newly joining node to fail. Solution: The algorithm that marks the groups as incomplete (when detecting that delayed alignment needs to take place for a given name-space), has been modified to only mark those partition-topic combinations that match the name-space.
OSPL-3224 | Durability KV store may access memory that is already freed. When cleaning up the instance administration it may occur that an already freed reference is accessed. Solution: Set the freed reference to NULL and check if it is not NULL when accessing it.
OSPL-3254 | Failed termination messages on windows when closing OpenSplice When terminating OpenSplice with ospl stop on windows a number of messages with the following text "Failed to send the SIGTERM signal to the splice daemon process 0" could appear in the info log file. These messages appear for each service that is configured in the configuration file. In fact, the service is correctly terminated. Solution: These messages will no longer be reported when the services are terminated correctly.
OSPL-3290 | When rebuilding custom_libs with Visual Studio the dll files in $OSPL_HOME/bin are not replaced. When rebuilding custom_libs with Visual Studio the dll files in bin were not replaced. The dll files were produced to the $OSPL_HOME/lib directory and required manually copying into the $OSPL_HOME/bin directory. Solution: When rebuilding custom_libs with Visual Studio the dll files in $OSPL_HOME/bin are replaced.
OSPL-3342 | Potential uninitialized memory access in the Java language-binding In the Java language binding there were (internal) error paths in which uninitialized values could be returned. Solution: The return-values have been initialized for the error-case aswell.
OSPL-3351 | RT Networking : Parallel demarshalling administration may leak Due to an error in a method used by the cleanup routines to access the parallel demarshalling administration for Java, the related administration may leak if the number of threads is changed or the application stops. Solution: The error in the cleanup routines is resolved ensuring that the right pointer is returned.

## 6.3.2p2

Report ID. | Description
--- | ---
OSPL-2283/ 11750 | Memory leak in lookup_participant The domain identifier was not freed. Solution: The domain identifier is now freed before leaving gapi_domainParticipantFactory_lookup_participant.
OSPL-3158/ 12351 | Memory leak after deleting a waitset The common destructor in GAPI did not free object if object was of type waitset. Solution: Memory leak fixed.
OSPL-3188 | Error in throughput measurement of streams example The streams example measures throughput by taking the total amount of samples divided by the amount of time in one run. It consists out of a reader and a writer process which are started independently. Previously the reader would start the time-measurement when the process started, even though the writer-process was not yet running. This resulted in throughput that was too low because more time was spent measuring than was spent sending data. Solution: The example now starts the measurement when it receives the first sample.
OSPL-3198 | Durability could crash during startup when doing initial merge Due to a timing dependency on whether the role of a fellow was set the durability service sometimes assumed that the role was available when it wasn't, resulting in trying to read a NULL-pointer. Additionally, the service would use a fast spinning loop to determine whether communication with another fellow was approved and would loop forever if the fellow would not be approved. Solution: The role is now only accessed when it is available. Furthermore the spinning loop that determines whether communication with another service is possible is made less cpu-hungry (by introducing a sleep) and the loop skips a service for which the communication state is not approved instead of looping forever.
OSPL-3200 | Consistent final value not always guaranteed with BY_SOURCE_TIMESTAMP Where a single writer updates an instance with the same timestamp, a consistent final value for that instance was not guaranteed across all subscribers. Also when a time with all zeroes was supplied, the actual time would be used instead of the supplied time. Solution: When updating the administration of the readers the consistent final value is guaranteed by incorporating a writer-generated sequence number and time zero has no special meaning anymore.
OSPL-3218 | Streams API returns old sample multiple times After the streams get_w_filter API call returned NO_DATA, administration in the StreamReader caused a consecutive get_w_filter to return the last received sample. This pattern (NO_DATA, last sample) repeated itself until new data was received. Solution: The administration is now left in a correct state after NO_DATA is returned.

## 6.3.2p1

Report ID. | Description
--- | ---
OSPL-3096 | In single-process deployment CTRL-C doesn't work Due to a signal-handler being overruled on POSIX systems, termination requests like CTRL-C (e.g., the signals SIGINT, SIGQUIT, SIGTERM, SIGHUP and SIGPIPE) would not result in an immediate stop of the application. Solution: The signal-handler for single-process deployments is no longer overruled by handlers that don't stop the application.

## 6.3.2

Report ID. | Description
--- | ---
OSPL-10 4508 | TypeSupport with invalid type name causes crash during register_type When a type support object is created with an type name which is not known in the meta database the register_type function crashes. Solution: Code change made to prevent the crash and doc updated to improve descriptin of register_type.
OSPL-1430 7255 | Durability Service behaviour with no aligner The current behaviour of a durability service is: when no aligner is available a durability service that cannot act as aligner itself will wait until an aligner becomes available. This is not desirable in all cases. When no aligner is available a durability service that cannot act as aligner itself will wait until an aligner becomes available. If no aligner becomes available, the durability service will wait forever. In some situations it may be desirable to exit instead. This behaviour has been made configurable using the TimeToWaitForAligner-option. Currently two values are supported, 0.0 (exit if no aligner is available) and 1.0 (wait until an aligner becomes available). The default is 1.0 which matches the original behaviour. When the durability service exits error code 1 (recoverable error) is returned. Solution: The behavior of the durability service is configurable when no aligner is present.
OSPL-1431 10964 | idlpp multiple prefix support for Java idlpp did not support prefixing multiple modules for the java language binding using the -j option. Solution: idlpp now supports prefixing multiple modules.
OSPL-2307-1 11751 | Recursively resolved header files all present in top level header file. idlpp would include all generated header files for C++ for which it found an idl preprocessor directive. Solution: idlpp generated C++ code does not include all recursively resolved header files anymore and instead only references the top level include file.
OSPL-2307-2 11751 | idlpp sometimes forgets top level line markers in preprocessor output idlpp would forget to include top level line markers in preprocessor output if the included file contained a idl preprocessor include directive itself and no actual idl code was declared before the include directive. Solution: idlpp preprocessor now prints a line marker for the file it's in, as soon as it finds a preprocessor include directive and the line marker wasn't printed yet.
OSPL-2696 11998 | REPLACE and DELETE merge policy Solution: With the REPLACE merge policy it is possible to dispose and delete historical data on a node, and replace it with the transient and persistent data from another node. Immediately after successful completion of the REPLACE merge action the replacement data will be available to late joining readers, the data in the reader queue of existing readers will be disposed and replaced with the replacement data, and the generation count of the replacement data is increased. With the DELETE merge policy it is possible to dispose and delete historical data on a node. Immediately after successful completion of the DELETE merge action the historical data in the reader queue of existing readers will be disposed and is not available any more to late joining readers.
OSPL-2705 12008 | Java deadlock during shutdown Newly spawned thread in shutdown hook to delete contained entities causes a deadlock. Solution: In OSPL v6 a user should not request an exit from within a listener thread (until the final solution has been implemented - expected in v7). A solution is to spawn a thread that calls System.exit() instead of calling the method from within the Listener callback itself. OSPL now tries to detect this deadlock, reports an error and calls system.halt.
OSPL-2762 12045 | Deadlock on receiving SIGSEGV in Java language binding The signal handler used to install the default signal handler and re-raise SIGSEGV. This caused JVM to pass a SIGABRT to the signal handler thread itself which would try to notify itself, and as a result end up in a deadlock. Solution: Upon receiving a SIGSEGV (synchronous signal) asynchronously the signal handler thread does not change the signal mask and now invokes kill instead of raise to avoid possible deadlocks.
OSPL-2844 12163 | Alignment of transient data can cause a crash after several restarts on a second node where the first one keeps running Node a is started and publishes transient data. Node b is started and aligns with the first node. Result is stored in persistent file. After several restarts of node b the internal hash table in the durability service is out of sync caused by the data from the persistent file and the data received from node a and causes a crash. Solution: Internal hash table in durability service was out of sync with the reality.
OSPL-2889 12174 | Writing data with empty strings in Java may not result in correct data being received in DDS Due to an issue with the routines used by the Java language-binding to do empty-string interning, non-empty strings could show up in the data received in DDS. Solution: The empty-string interning mechanism has been fixed to prevent this issue.
OSPL-2891 12167 | Data reader statistic "numberOfSamplesTaken" not being updated The "numberOfSamplesTaken" statistic was not being updated correctly in the Tuner. Solution: Fix applied and Tuner works ok.
OSPL-2894 | Logger example failed to build on Solaris The logger example failed to build on Solaris due to make complications. Solution: Make file corrected.
OSPL-2900 12235 | Instances may be corrupted when using small reader_data_lifecycle.autopurge_*_delay In case a durability_service.service_cleanup_delay > 0.0 is used for a Topic in combination with a very small value (or zero) as reader_data_lifecycle.autopurge_*_delay by a DataReader for the same Topic, instances may be corrupted in that DataReader during the delivery of historical instances in case they had been disposed prior to delivery already, no more live writers exist for it and of which the service_cleanup_delay has not expired yet. Solution: The internal algorithm that deals with the above Qos policies has been altered and no longer causes memory corruption.
OSPL-2904 12236 | OSPL_LOGAPPEND does not work as expected The environment variable OSPL_LOGAPPEND does not work like expected. A "true" has the same effect as "false". Only if the variable is not defined do you get the append behaviour. Solution: The evaluation of OSPL_LOGAPPEND has been corrected.
OSPL-2919 12244 | Opensplice DDS services always wait worst-case terminate period in case of a service crash When using Opensplice DDS and for some reason a service crashes or is deliberately crashed, the Opensplice DDS services always wait the complete ServiceTerminatePeriod to exit. Solution: This extra delay in the termination of services has now been resolved and the services will now close as soon as possible.
OSPL-2972 | Invalid configuration values on Windows 64-bit On Windows 64-bit platforms, some configuration values were parsed incorrectly, leading to unexpected behaviour. For example the MaxBurstSize of the RTNetworking service didn't seem to work on Windows 64-bit platforms. Solution: The parsing and printing of 64-bit values has been fixed for Windows 64-bit platforms.
OSPL-2977 | Appending to a stream may return RETCODE_TIMEOUT if flush limit is reached Users of the Streams API should take into account that the append call may return RETCODE_TIMEOUT, as a result of an implicit flush that hits the writer resource limits. Solution: To handle this situation the following snippet of code is suggested:
    result = stream->append( ... );
    while (result == RETCODE_TIMEOUT) {
    result = stream->flush( ... );
    }
OSPL-2979 | Out of range user-friendly configuration values might result in strange values being used. When a out-of-range user-friendly size expression with the suffixes k/K/m/M was used, the reported replacement value wasn't actually used. Solution: When an out-of-range value is specified, the reported replacement value is actually used.
OSPL-3036 12173 | Applications using DCPS Java API may crash when creating a participant in case stack-traces are not available. The DCPS Java API is trying to resolve the class name of the main-class as name of the participant. The algorithm that determines this information was not robust against stack traces not being available causing an ArrayIndexOutOfBoundsException. Solution: Made algorithm robust against not being able to inspect the stack. In this case a warning is issued in the logs and an alternative name is chosen based on process id.

## 6.3.1p5

Report ID. | Description
--- | ---
OSPL-707/2546/2590/2735 10333/11875/11882/12037 | Crash in memory manager In case of concurrent allocating and freeing small blocks distributed over the memory in a particular way, a free operation could shrink the region of used memory by multiple blocks of memory where it should have shrunk by only one. This in turn could lead to the shared memory allocator to allocate a block of memory twice, most of the time leading to a crash in the allocator itself. Solution: The condition for shrinking the region has been fixed such that this can no longer occur. There is no effect on memory usage.
OSPL-2246/ 11720 | Topic content filter doesn't work with no-writers or disposed events Data is not filtered as expected when using a content filtered topic and the events are disposed or the writer is deleted. Solution: Changes have been made to the content filtered topic code so that now the instance part of the filter will be always be evaluated, but the data part of the filter will only evaluated when a valid sample is written.
OSPL-2303/ 11761 | OpenSplice DDS services always wait worst-case terminate period in case of a service crash. When using Opensplice DDS and a service crashes or is deliberately crashed, the Opensplice DDS services always wait the complete ServiceTerminatePeriod to exit. Solution: This extra delay in the termination of services has now been fixed and the services will now close as soon as possible.
OSPL-2535 | New reader statistic numberOfSamplesLost Solution: The new reader statistic numberOfSamplesLost counts the number of samples that have been lost for that reader during network transportation.
OSPL-2631 | wait_for_historical_data_w_condition accepted DURATION convenience types as Time input. The reference manuals advocated the use of DDS_DURATION_ZERO and DDS_DURATION_INFINITE as valid input arguments for the Time_t min_source_timestamp and max_source_timestamp parameters. This is confusing because timestamps are expected, but durations are considered valid input. Furthermore, supplying DDS_DURATION_INFINITE leads to an uninitialized variable, which could potentially lead to non-deterministic behavior. Solution: The reference manuals have been updated, so now it is more clear what parameters are expected. Also the initialized variable bug has been fixed.
OSPL-2720 | Configurator Tool does not handle lower case values for sizes Values such as 32k are not accepted by the configurator, but are valid by OpenSplice. Solution: Setting size values with k, m and g are now valid in the configurator.
OSPL-2754/ 12042 | ospl tool updated to ensure orphaned key files on unix are cleaned On Windows ospl tool ensures that any orphaned key files (i.e. where there are no running processes present that match the key file) are deleted before starting OpenSplice. Solution: Extended the Windows functionality to Linux, but additionally only tidy orphaned files that belong to the same user starting OpenSplice.
OSPL-2781 | Configurator doesn't recognize throttle_limit as a number The Configurator did not allow the use of k, m or g when setting its value. Solution: Configurator fixed.
OSPL-2787/ 12056 | DCPS C++ CORBA co-habitation custom library rebuild failed to re-build The DCPS C++ CORBA co-habitation custom library failed to re-build because of a missing macro definition in the supplied makefile. Solution: The missing macro definition has been added to the makefile.
OSPL-2790/ 12047 | Missing PID when displaying Java participants in the tuner When using the Tuner in the participant view and the participant application is a Java application which is not a DDS service like the Tuner or the Tester, only the name of the class is displayed, not the PID. When several instances of the same application are running on the same node, it is not possible to distinguish one from another. Solution: The java participant applications now show also a pid behind their name to make it easier to distinguish them. The participant naming is now also consistent with the C, C++ and C# applications.
OSPL-2804/ 12123 | Alignment of transient data failed in multiple writer-scenario In a scenario with two writers writing the same instance where the 2nd writer is deleted, alignment of transient data failed because the registration for the first writer was not aligned while the unregistration of the 2nd writer was. Solution: For each registration that has no samples anymore in the store, durability sends an extra registration for that writer.
OSPL-2816/ 12145 | Deadlock involving groups using synchronous write Incorrect initialisation of a lock involved in processing acknowledgements on synchronous writes could cause a deadlock when different processes were trying to access the data structure. At the point where this occurs, a lock on the group with which that synchronous write is associated may be held, which could cause hanging processes in various configurations and for seemingly unrelated reasons. Solution: The initialisation of the lock has been corrected.

## 6.3.1p4

Report ID. | Description
--- | ---
OSPL-2763 | Shared memory leaks on deletion of DataReader. Under certain conditions memory would leak when a DataReader was deleted. Solution: The leak has been fixed.

## 6.3.1p3

Report ID. | Description
--- | ---
TSTTOOL-123 | Quoted partition name in Tester script is interpreted as part of actual partition name. If a user wanted to execute a reader command in a Tester script that specified a partition with dots or stars in its name, then the only way for compilation of the script to be successful was to surround the partition name in quotes. However, the quotes were then interpreted as part of the partition name when the reader is created. Solution: In a reader command, if the partition name is wrapped in quotes, then the quotes are dropped after compilation. If a user still wanted to include quotes as part of the actual partition name, then they can escape the quotation marks in the partition name in script.

## 6.3.1p2

Report ID. | Description
--- | ---
OSPL-2733 | Issue in Streams API could result in crash on Windows. A problem was found in the Streams API with the initialization of mutexes and condition variables, that could result in data not being published and/or undefined behaviour of applications build on top of the Streams API on Windows. Solution: The incorrect initialization was fixed.

## 6.3.1p1

Report ID. | Description
--- | ---
OSPL-2729 | Problems starting OpenSplice when OSPL_URI is quoted. OpenSplice DDS will not start with an OSPL_URI surrounded by quotes (" "). Solution: OSPL Tool now handles a quoted OSPL_URI.

## 6.3.1

Report ID. | Description
--- | ---
OSPL-614/OSPL-1843/ 10335 | New durability persistence store implementation using a key-value storage To store durable data the durability persistency store implementation should be extended with a robust and fast storage mechanism which will replace the MMF store implementation which is known to suffer from robustness issues when a crash occurs. Solution: The new persistency store implementation is based on a key-value storage which makes use of third-party products like Sqlite or Leveldb to store the durable data on disk.
OSPL-1430/ 7255 | Durability crashes when starting a new instance of ospl if there is no aligner A fix was applied for this issue n 6.3.0p5. This fix has been removed in 6.3.1 and a new fix will be applied in a subsequent release. Solution: N/A
OSPL-2131/ 11470 | Improvement in read performance of certain complex Java CORBA DDS data structures Solution: An option has been added to improve the read performance of certain complex Java CORBA DDS data structures by limiting the overhead caused by JNI invocations during data passing from C to Java.
OSPL-2244 | IPv6 interface detection in Windows causes a crash If an application in Windows used the networking service and tried to detect available IPv6 interfaces a system crash occurred. This made IPv6 on Windows unusable. Solution: The implementation of the IPv6 interface detection is improved so that it no longer causes crashes.
OSPL-2474 | Default RMI ServiceDiscoveryTimeout needs to be increased. Due to some changes in the default timing for the alignment of historical data, alignment takes a bit longer to start by default. This sometimes causes RMI to fail to locate services as the default time-out of RMI no longer matches the default durability configuration. Even though the discovery period of RMI can be influenced by using the --RMIServiceDiscoveryTimeout= command-line option, the default of RMI should match the default durability settings. Solution: The default time-out of RMI service discovery has been increased from 10 to 30 seconds.
OSPL-2504/ 11790 | Issues with recording and replaying particular data types and content Serialization/Deserialization used by the XML-storage component of the Record and Replay service causes issues if particular character-data is present in DDS samples which are recorded and or replayed. Specifically newline characters and unbounded character sequences containing illegal XML content are not supported. Solution: Relavant parts of the product were changed and the limitations are lifted.
OSPL-2660 | The durability service may crash when using dynamic name-spaces. When a new durability service joins the domain, it may introduce a new namespace in the domain that did not exist on the existing nodes in the domain. In this situation an already running durability service may crash when it has a matching durability policy configured for the new name-space (so when using the dynamic name-space feature). In this situation the existing durability service dynamically registers the new name-space as well and applies the configured policies to data that matches that name-space. One of the internal algorithms assumed that all name-spaces for a given durability service are fixed after start-up. Solution: The internal algorithm in the durability service has been changed to be robust against a changing set of name-spaces.
OSPL-2676/ 11993 | Deployment guide on OSPL behavioue for signals incorrect. The deployment guide for SIGINT was incorrect in the deployment guide. Additionally, SIGQUIT behaviour was incorrect in the codebase. Solution: Deployment guide and codebase corrected for signals.

## 6.3.0p5

Report ID. | Description
--- | ---
OSPL-1430/ 7255 | Durability crashes when starting a new instance of ospl if there is no aligner Durability did not check if there was an aligner when dds is started. If there is no aligner and a new nodes starts, then the two nodes will reach a inconsistent state. Solution: Durability will now check if there is a aligner. If durability service cannot find an aligner, then it will send a signal to splicedemon to perform system halt.
OSPL-2106/2361/ 11859 | Wrong evaluation of depricated enable_invalid_samples QoS When the enable_invalid_samples Qos is set to false, this QoS is evaluated as true. Solution: The defect in QoS evaluation algorithm is fixed and will now be evaluated correctly.
OSPL-2126/ 11591 | Illegal time messages are reported Injecting disposed AND unregistered transient/persistent data into a late joining reader that had its autopurge_disposed_samples_delay set to a very low value (zero or very close to zero) could in some cases corrupt the shared memory because the instance dispose message would already purge the instance before its corresponding unregister message could register itself into it as well. Solution: This loophole in the purging algorithm has now been closed.
OSPL-2125 | Durability Memory Leaks Fixed a memory leak during configuration parsing in durability. Additionally fixed reading of an uninitialised value in the service termination thread in the user layer. Solution: Code fixed.
OSPL-2210/2305 11702 | Remove level 4 warnings caused by parallel demarshalling on windows Parallel de-marshalling, introduced after V6.3.0 caused some W4 on windows. Solution: Warnings have been resolved.
OSPL-2541 | The tuner always displays the value 0 in the SampleSequenceNumber field When reading a sample with the Tuner the field SampleSequenceNumber in the sampleinfo table is always 0. Solution: The value of the SampleSequenceNumber field now displays the correct value
OSPL-2545/ 11872 | Durability does not apply merge-policies with other roles after initial alignment Durability assumed that all federations in the domain would be able to communicate with each other directly and therefore assumed merge policies did not need to be applied during initial start-up. Furthermore, it selected an initial source of alignment independent of role where it should select one with the same role as itself. Solution: Durability now selects an initial aligner with the same role and applies the configured merge policies with other roles immediately after start-up.
OSPL-2617/ 11894 | idlpp-generated C-code does not compile with C++ compiler The idlpp-generated code for standalone C contains code that assigns the result of a malloc directly to a character-pointer variable. Even though assigning a void-pointer to any other pointer is allowed in C, it is not in C++ and this makes it impossible to compile the generated C code with a C++ compiler. Solution: The result of a malloc is now casted to a character-pointer before the assignment.
OSPL-2618/ 11895 | idlpp-generated functions for the standalone C API don't compile with .NET 2008 C++ compiler External symbols are used within idlpp-generated functions for the standalone C API preventing the code to compile when using in C++. Solution: External symbols have been moved outside the function.

## 6.3.0p4

Report ID. | Description
--- | ---
OSPL-1697/ 11351 | Durability periodic report leads to fast growing trace file The trace file is growing as result of a periodic report at the level FINE. Solution: Increase the level of this report to the FINEST level.
OSPL-1897/ 11066 | When an invalid handle is applied to read_instance it should return BAD_PARAMETER instead of PRECONDITION_NOT_MET When read_instance is called with an instance handle that is not associated with an known instance then the operation should return BAD_PARAMETER instead of PRECONDITION_NOT_MET. Solution: When detecting that the provided instance handle is not valid because it does not reference an instance associated with the data reader then the return code is changed to BAD_PARAMETER.
OSPL-1990/ 11560 | Cppgen crash under windows when using a path larger than 1024 characters When using idl with c++ generation and a path lager than 1024 characters is used cppgen will crash under windows. Solution: Cppgen is fixed.
OSPL-2051/ 11575 | Potential crash while removing synchronous readers and writers A race condition existed in the product which could, in specific circumstances, result in a crash of the spliced process. The crash could occur when a pair of synchronous reader and writer are deleted at roughly the same time. A lock was introduced to protect shared parts of the administration related to synchronous readers and writers. Because of this lock, the race condition can no longer occur.
OSPL-2134 | The durability service adds a small delay between handling alignment requests which may cause a longer alignment time when there are requests waiting to be served. After handling each alignment (sample) request the durability service adds a small delay. This delay is not necessay when there are still requests waiting to be served. Removing this delay will improve the alignment time. After handling an alignment (sample) request check if there are still request waiting.When there are requests waiting start handling the first request from the waiting list immediately.
OSPL-2326/ 11766 | Report plugin gives unhelpful message at runtime if not built correctly If OpenSplice was built without the directive INCLUDE_PLUGGABLE_REPORTING set to 'yes', then enabling the report plugin feature would result in an obscure error message 'ReportPlugin registration failed: -1' and the splice daemon will not start. Solution: The error messages related to this issue have been changed. Now a more explanatory message indicating what happened, and what should be done to resolve the issue, is produced. In particular, the error message will now state that the INCLUDE_PLUGGABLE_REPORTING directive should be set of 'yes' in order to use the pluggable reporting capability of OpenSplice.
OSPL-2484/ 11819 | Namespace mismatch in durability service The namespace configuration of the durability service allows catch-all partition expressions and also more specific partition.topic expressions. By mixing these two methods on different nodes in a domain, a durability service could incorrectly determine a topic does not belong to a particular namespace and enter an infinite loop waiting for namespaces from remote nodes that do include the topic. Solution: The matching algorithms in the durability service were made more robust to deal with this situation and now determine the correct namespace for a particular topic.
OSPL-2510 | Memory leak when using CReader.read and CReader.take The CReader.read and CReader.take leaked memory by creating a new readCondition with every call. Solution: The creation of the readCondition is moved to the same location as the creation of the Reader itself. Typically a reader is only created once, now the readCondition is also only created once, which minimizes leakage.
OSPL-2530 | RT Networking control port not set on first message The control port is determined when the interface becomes available. This occurs after the first message is initialized. In a single process configuration this may cause that the ACK messages are sent to the wrong control port. Solution: When the send channel is notified that the interface has become available set the control port into the current write buffer in case of a reliable channel.

## 6.3.0p3

Report ID. | Description
--- | ---
OSPL-2410/ 11793 | Potential inconsistency of builtin-data when nodes are concurrently leaving and joining a domain An issue in the product could result in inconsistent state related to a node that has left a domain, between nodes still present in the domain. The problem occurred when a node leaves the domain and a new node joins a domain before all remaining nodes are aware of the node that left. Solution: The product was modified w.r.t. processing of builtin- data, to properly handle this situation.
OSPL-2409/ 11792 | Durability never reaches the state 'operational' in a scenario containing two or more nodes without the explicit configuration of a namespace for the builtin topics. When the durability configuration file does not configure a namespace for the builtin topics, a namespace called AutoBuiltinTopics should be created automatically. This namespace should be responsible for aligning various builtin topics. Due to a flaw one of the builtin topics, CMParticipantInfo, was not included in the namespace. Also, a policy for the namespace was not provided. As a consequence the nodes initially would try to align their namespaces, but would never reach a 'complete' state because the CMParticipantInfo topic could never be aligned. This causes the system to indefinitely try to align the namespace for this topics, and never reach the 'operational' state. Solution: The CMParticipantInfo has been added to AutoBuiltinTopics namespace. Also a policy for this namespace has been added. Now durability will reach the 'operational' state in a scenario containing two or more nodes without the explicit configuration of a namespace for the builtin topics.
OSPL-2408/ 11791 | Enhanced bind behaviour control By allowing more control over the behaviour of the RTnetworking services regarding the bind-address and port reuse, more advanced deployments can be supported. Two attributes have been added to the General/NetworkInterfaceAddress section of the RTnetworking service: 'bind' and 'allowReuse'. The 'bind' attribute controls whether the networking service binds to the wildcard-address or ('any'), or to the NetworkInterfaceAddress ('strict'). The boolean 'allowReuse' attribute specifies whether the SO_REUSEADDR option is specified before binding a socket. (Note: The deployment manual will be updated at a later release regarding these options. The configurator tool can be used to configure the options).

## 6.3.0p2

Report ID. | Description
--- | ---
OSPL-2150/ 11428 | When a disconnect occurs samples are marked as NOT_ALIVE. After a reconnect the samples should become ALIVE again, but this does not occur for existing datareaders in the case where the BY_RECEPTION_TIME policy is used. In the case where a reader and a writer are running on different nodes and the nodes are disconnected, then samples at the reader are marked as NOT_ALIVE. When the connection is re-established and durability is configured to re-align the lost samples, the reader is expected to show the samples again. Because the unregistration of a sample is treated as a new sample and this sample has the policy BY_RECEPTION_TIME, the unregistration is treated as a new sample that needs to be aligned by the durability. Consequently, the unregistration incorrectly reverts the aliveness of the sample. Additionally, the process to determine a new master durability service is not taking into account the proper time-outs causing temporary conflicting masters and that results in superfluous alignment of data to take place. Solution: The durability service is changed. It now prevents to process updates of samples from writers with your own ID. This means that you do not process data from anybody that tells something about your data. The durability service now also takes into account the proper heartbeat expiry-time when determining a new master to prevent superfluous alignment of data. As a consequence the default heartbeat time-out has changed to prevent alignment in default configurations to take longer. The default expiry-time is now 4 seconds instead of 10. The deployment guide has not been updated yet to reflect this change.
OSPL-2219 | Restart failure action on networking service causes communication error When the restart failure action on the networking service is enabled and the networking service is restarted. Communication errors can be observed with the new networking service. Solution: The defect in the service restart mechanism is now fixed and the networking service will correctly communicate.
OSPL-2220 | Memory leak of the database type v_message<kernelModule::v_participantInfo> In the case that a restart failure action is enabled on a service it can be observed that the database object count of v_message<kernelModule::v_participantInfo> rapidly increases. Solution: The defect in the service restart mechanism is now fixed and the v_message<kernelModule::v_participantInfo> will not leak anymore.
OSPL-2315/ 11768 | C++ ping examples does not communicate with Java pong example The C++ ping application does not initialise its string parameter leading to errors in the Java pong application. Solution: The C++ ping example has been updated to initialise all sample data before writing it.
OSPL-2317/ 11767 | Durability service issue with multiple namespaces of a remote node There was an issue with the durability service's management of a remote node's namespaces. It may incorrectly determine a remote namespace already exists and so it may not be added to the node's administration. Solution: The issue has been corrected by comparing the namespace names that are offered by a remote node rather than comparing the namespace properties as was being done before.
OSPL-2327/ 11774 | idlpp compiler generating non-compilable code with '-l isocpp' from IDL containing structs that aren't topics The idlpp compiler was generating non-compilable code with '-l isocpp' or '-l isoc++' from IDL containing structs that aren't topics. The code did not compile because REGISTER_TYPE_TRAITS entries were being generated for these structs in error. Solution: The idlpp compiler has been fixed to not generate REGISTER_TOPIC_TRAITS entries for non-Topic types; such definitions now generate compilable code.
OSPL-2431 | During the alignment process durability performs new, but superfluous alignments while being busy in an existing alignment. When a node is busy in an alignment action and it is triggered to align the durability service will perform this action. This is not always necessary and causes alignment data to flood the network. Solution: Superfluous alignment request during an existing alignment are ignored. This prevents flooding the network.

## 6.3.0p1

Report ID. | Description
--- | ---
OSPL-1478/ 11042 | idlpp OSPL_BOUNDS_CHECK NULL detection error log incorrect idlpp generated incorrect tracing for OSPL_BOUNDS_CHECKing. When a variable was initialized to NULL the BOUNDS check reported an out of range instead of NULL Solution: Updated idlpp so it logs the correct message when NULL is detected.
OSPL-1673/ 11578 | DDSI2 sometimes logs socket error 10035 on Windows Socket blocking and waiting behaviour on Windows does not really support waiting for packets to arrive on a number of sockets in one thread, while trying to send packets in blocking mode on another thread, as the socket is either blocking or non-blocking. The auxiliary data transmission used a socket that was also in use for receiving data. Consequently, once the socket send buffer filled up, the Windows kernel could return error 10035, EWOULDBLOCK. In such a case the packet would be dropped. The protocol is such that these lost packets would not affect correctness, but it does impact timing and is generally undesirable. Solution: All outgoing traffic now uses dedicated transmit sockets.
OSPL-2026/ 11571 | Windows Service access rights Application running as normal user is unable to create a participant or topic when running OpenSplice as a service on Windows. Solution: The communication pipe for the service thread was created using default access rights, which blocks writes from low-privileged users. This rights have been changed so that every user can write to the pipe.
OSPL-2123 | DDSI2E mapping of transport_priority to channel incorrect DDSI2E internally maps transport priorities to channels for processing protocol messages, retransmits and incoming data on the threads that best correspond to the priority of the message. This mapping differed from the mapping of samples to channels which is done internally by the kernel. In consequence, processing could take place on a different thread than intended by the configuration. This only affected scheduling, especially under very high CPU loads. In the particular case that channels were defined in order of descending priority, the mapping was always correct. Solution: The mapping function has been fixed.
OSPL-2244 | IPv6 interface detection in Windows causes a crash If an application in Windows used the networking service and tried to detect available IPv6 interfaces a system crash could occur. Solution: The implementation of the IPv6 interface detection is improved so that it no longer causes crashes.
OSPL-2257 | Broader use of empty-String interning in Java copy routines Solution: The empty string interning optimisation for the Java copy routines has been applied to bounded strings as well, improving performance when the data includes a lot of empty bounded strings.

## 6.3.0

Report ID. | Description
--- | ---
OSPL-28/ 4767 | Wrong returncode in register_type API call When calling the API register_type function with a type name that is already registered but with a different metadescriptor retcode DDS_RETCODE_OK is returned. This should be DDS_RETCODE_PRECONDITION_NOT_MET. Solution: The defect in the register_type function is solved and the correct returncode is returned.
OSPL-148 | Improve Windows/WindowsCE condition variable implementation The Windows and Windows CE condition variable implementation contained a bug where if there were no threads waiting on the condition variable, an open handle from a semaphore would not be closed when returning from the function. Solution: The condition variable signal algorithm has been improved to test whether there are any waiting threads before opening the handle. This resolves the bug and improves performance slightly because it avoids opening the semaphore when it is not required.
OSPL-528/ 9909 | Memory leak in create_querycondition Creating and deleting a QueryCondition leads to a memory leak. Solution: The memory leak has been fixed.
OSPL-885/1645 | C# idlpp crash when no module given in IDL When defining idl for C# and a structure is defined without a module the idlpp compiler crashes. Solution: The defect in C# Idlpp is now fixed and it is now possible to define structures without a module tag.
OSPL-1046 | Data send on a particular network partition should not be received by DDS instances that are not connected to that network partition When network partitions are configured and data is sent on a specific partition (not the default partition) then other DDS instances should not receive this data when they are not connected to that specific partition. Currently when networking receives data from a partition which is not connected or unknown then networking delivers this data in the default partition. Solution: When networking receives data on a network partititon that is either not connected or unknown to that networking instance then the data should be dropped.
OSPL-1187 | Removal of Sun Code snippet and license acknowledgement OpenSplice Tuner and Tester used a code snippet from Sun that had a license accreditation. Solution: Removal of the code means license acknowledgement is removed.
OSPL-479/OSPL-1435/ 10963 | DDSI2 support for IPV6 Solution: Support is added for IPV6 on DDSI2.
OSPL-1438/ 10974 | Visual studio limitation on large topic structure definitions For very large topic structure definitions, the Visual Studio compiler runs into a limitation of the maximum length of a string. If the metaDescriptor character string data exceeds 64k in size, the Visual Studio C++ compiler fails to build the generated code. Solution: The metaDescriptor string is replaced by an array which resolves the maximum string limitation in Visual Studio.
OSPL-1526 | Try automatic repairing option of the configurator did not work for number values When loading a config file into the configurator with faulty number values the configurator asks if it should repair those faulty values. After this is done the corrected values are not written to the config file when this is being saved. Solution: The defect in the configurator is now fixed and the corrected values are now being stored.
OSPL-1537/ 11089 | spliced may crash after a service with the "systemhalt" failure action dies If a service dies it may not have performed a detach from the OpenSplice kernel/database and so the attached services count may be incorrect. That could lead to a crash of a database thread because the spliced may get detached too early. Solution: When spliced detects that a service has died, it ensures that attached services count is correctly maintained, so such a crash cannot occur.
OSPL-1549/ 11096 | Durability report about name-space backup unclear When the durability service on start-up detects that the current set of persistent data on disk is not complete due to the fact that the service did not manage to fully complete the alignment of the set of persistent data during the previous run, it will check if there is an older but complete set still available on disk. If so it will replace the newer but incomplete set with the older but complete set after which durability services in the domain will determine who has the latest complete set and use that one everywhere. In case there locally is no older complete set, the error is reported. The report is not deemed very clear though and besides that it is not considered an error but merely a warning. Alignment will still be able to continue. Solution: The report has been rewritten to make situation clearer and is now reported as warning instead of as error.
OSPL-1591/ 11165 | Services do not use the shared memory threshold correctly When the shared memory database is configured to have a threshold, the services are entitled to use half of that region meaning they are able to continue to run when shared memory gets low. The issue was that the services were in fact using that threshold region in the same way as regular applications - i.e. they were unable to use any of that region. There was also a bug where terminating services with a failureAction of "kill" were being left in a zombied state and not necessarily exiting. Solution: A fix has been applied that allows the services to correctly use up to 50% of the threshold region. A fix has also been applied to the monitoring of the died/terminating services so that they cannot be left in a zombied state.
OSPL-1615 | Durability service does not reach COMPLETE state when some partition-topic combinations are not covered by the name-space configuration In case the durability service is configured with name-space settings that do not cover all locally available partition-topic combinations, the service did not reach the COMPLETE state that indicates that all partition-topic combinations that the durability service manages have been fully aligned. Solution: The state of locally available partition-topic combinations that are not supposed to be managed by the durability service are no longer included in determining whether or not the alignment is complete.
OSPL-1634 | New command line parameter for the configurator The OpenSplice Configuration Editor now contains a new command line instruction.
    -uri=[URI] the domain config file that needs to be opened e.g. osplconf -uri=$OSPL_URI
OSPL-1642/ 11224 | C++ memory leaks of the default QoS sets stored for the DDS Entities The statically initialized default QoS set for each DDS Entity (Publisher, Data Writer etc) are stored as pointer types and they are not deallocated, so they will appear as a leak when main exits. Solution: Storing these default QoS sets as _var types means that the container class takes care of the deallocation, even for the statically initialized types.
OSPL-1644 | Inappropriate warning when retrieving network interface information on Windows When a network interface is present but not connected or configured then a warning is given which is not appropriate. Solution: The discovery of the network interfaces should only consider network interfaces that are available and the warning is now only output when required.
OSPL-1654 | Networking crashes when a network partition is configured without an explicit name Networking crashes when a network partition is specified without a name. The name attribute of a network partition is optional, when not specified the address should be set to the address of the network partition which is omitted. Solution: When the name of a network partition is not set the name is set to the address attribute of the network partition.
OSPL-1668 | Dispose/writedispose action returns error in the Tuner When creating a reader/writer in the Tuner and then clicking on the Dispose or WriteDispose button an error message may be shown in the status pane stating that the dispose failed while the dispose from system-perspective was successful. Solution: The algorithm for showing this message is fixed and the message will not be displayed anymore.
OSPL-1708 | Default MMF persistency configuration settings don't work i.c.w single-process mode When selecting MMF as persistency and running in single-process mode, the durability service would not start due to wrong default settings for mapping address and size of the store. Solution: The default settings are changed in case of single-process mode to ensure proper functioning of the durability service in that deployment mode as well.
OSPL-1751 | DDSI2 configuration defaults incompatible with various locales When starting DDSI2 in a locale in which the decimal separator character was different from "." (for example, the French locale, in which it is ","), some DDSI2 default values would be flagged as erroneous, preventing DDSI2 from starting. Solution: DDSI2 has been modified to avoid this problem.
OSPL-1806/ 11373 | Tuner crash when trying to read samples which contain a lifespan that is not set to infinite The Tuner crashes when trying to read samples which have a limited lifespan set. Solution: The defect is now fixed and the Tuner will not crash.
OSPL-1889 | An IDL file that contains a typedef to an enum causes problems in Java. If the IDL contains a typedef to an enum, then the middleware should unwind the typedef to retrieve the definition of the enum. This was not done properly, which effectively caused the system to crash. To avoid this, customers had to rewrite their IDL in such a way that it did not contain any typedef to enums. Solution: The implementation of the IDL processing function for Java has been modified so that the issue does not cause crashes anymore in Java.
OSPL-1913/ 11463 | Issue performing dispose or writedispose as last operation in coherent set The completion of a coherent set is signaled to the DataReader side by way of sending a new sample that contains the transaction information. That sample is created as a clone from the last sample sent from within the set. That sample was not being stored correctly in the case of a dispose or writedispose so was not being sent. Solution: The algorithm has been corrected so that any form of a writing a sample will store the sample so it can be resent when the transaction is completed.
OSPL-2000/ 11528 | The wait_for_historical_data_w_condition() call on the DataReader is not working properly The wait_for_historical_data_w_condition can return BAD_PARAMETER even when all input parameters are correct due to the fact the durability service is not ready to receive the request from the DataReader at the time it was issued. Furthermore, the durability service may also fail to deliver all historical data that matches the condition if the condition contained a filter expression. Solution: The wait_for_historical_data_w_condition algorithm now waits until all configured durability services are operational before issuing the request. If none have been configured or one or more that have been configured are not operational before the given time-out expires, PRECONDITION_NOT_MET is returned. Furthermore, the internal algorithm to evaluate the filter expression has been modified to ensure correct evaluation of the expression plus parameters against the set of available historical data.
OSPL-2004 | Exception handling is broken on POSIX Even though the application signal handler is properly called from the thread that caused synchronous signal, it is ALSO called from within the signalHandlerThread before that. It is obviously not supposed to do that. Solution: Modified POSIX signal handler to not invoke application signal handler from within our dedicated signal handler thread in case of a synchronous signal that was raised from within the application itself.
OSPL-2010 | Wireshark on windows Wireshark for RT networking was extremely difficult to build by a user on Windows platforms. Solution: ADLINK has decided to provide this now pre-built on its website. We continue to leave the source code and build files in place, should a user want to use them.
OSPL-2052/ 11569 | Incorrect dependencies for dcpssaj.jar The manifest file of the dcpssaj.jar file contains a lot of dependencies which are not needed. Solution: The unrequired dependencies are now removed.

## 6.2.3p1

Report ID. | Description
--- | ---
OSPL-2110/ 11592 | On Windows the disconnection or connection of a network interface cable causes large memory loss A status change of the network interface triggers an event. A memory leak occurs when handling this event. Because the status of the event is not automatically reset the function to handle event is called repeatedly. Solution: The memory leak is removed and the network interface status change event notification is re-enabled to allow new network interface status changes to be detected.

## 6.2.3

Report ID. | Description
--- | ---
OSPL-948/ 10679 | DDSI2 sends duplicate samples for writers that publish in multiple partitions simultaneously A write in multiple partitions simultaneously is received by DDSI2 as a number of messages from a single writer, one for each partition. All these message were forwarded by DDSI2 and filtered out by the subscribers running OpenSplice. However, this required extra bandwidth and besides caused other vendors' implementations of the DDSI protocol to report them as independent updates. Solution: This behaviour has now been changed, so that DDSI2 filters out such duplicates in the vast majority of cases. In particular, as long as the writer, its local subscribers and the networking services do not run into resource limits, it is guaranteed to filter out all duplicates. The filter can, under very unlikely circumstances, conclude a message is a duplicate when in reality it is not. This requires publishing more than 4 billion samples with a single writer while carefully controlling the behaviour of the writer history cache using resource limits on local readers; a situation no real system is likely to ever encounter. We advise that on systems that may run into this, the Unsupported/ForwardAllMessages setting be set to true.
OSPL-966/ 10707 | The RTSM tool is no longer working As a protection mechanism the RTSM tool does not continue processing when it thinks that a given address is not valid. One of the steps it takes to determine whether an address is valid, is to check whether the address lies in the virtual memory range that is expected based on the configured size of the shared memory segment. However, the tool determined the size of a shared memory segment in the wrong manner. Due to this issue the tool reports perfectly valid addresses as 'faulty' and no further processing is done. Solution: The algorithm that calculates the size of the shared memory and correct range for addresses has been repaired to ensure valid addresses are no longer reported as 'faulty' and all further processing can be done.
OSPL-991/ 10735 OSPL-1771/ 11395 | take() and take_w_condition() do not have the same behaviour/random crash on take next instance The dispose_all_data operation on the topic was not treated identically to sending a separate dispose message for every entity. This manifested itself especially in the way the disposed data was delivered to late joiners (which sometimes couldn't see that the data was actually disposed) and in the way disposed data ignored the cleanup delay specified on the durability service. Solution: The new implementation of dispose_all_data is much more inline with sending separate dispose messages for every instance, and thus late joiners will always see the correct instance state. Furthermore the dispose messages obey the same cleanup delays as normal dispose messages. However, the dispose_all_data function will still be me more efficient with respect to the utilization of network network bandwitdth, CPU cycles and memory than the manual transmission of separate dispose messages.
OSPL-1205/ 10845 | Terminating applications report pthread_join failed with error 35 When an application with a defined exithandler terminates and this exithandler contains an exit call the ospl-error file will report the message: pthread_join failed with error 35. Solution: The defect in the OpenSplice signalhandling is fixed and this error will not be reported anymore.
OSPL-1334/ 10898 OSPL-1335/ 10899 | PurgeList may illegally remove a groupInstance. The purgeLists are sometimes populated by the same instance multiple times (for different generations). Although the purgeList expiry algorithm should handle these situations correctly, it seems some scenario's are not properly handled yet, and a groupInstance from the emptyPurgeList may be freed while it is already reincarnated as a new generation. Solution: New code has been added that prevents outdated generations from being inserted into the emptyPurgeList, thus preventing this list from having duplicate entries and thus preventing it from deleting a groupInstance that is already reincarnated.
OSPL-1341 / 10914 OSPL-1930 / 11473 | The reliable network communication may not operate correctly when the first messages of a sending node arrive out of order. When reconnection is enabled and when the first messages of another starting node arrive out of order and also the discovery heartbeats arrive later then the first message the reliable network channel will not operate correctly. Solution: The notification that a node has become alive by the discovery protocol should not reinitialize the reliable channel administration associated with that node when the reliable channel had already detected that the node was alive.
OSPL-1445/ 10981 | Possible deadlock when using the API find_topic function When in a multithreaded application, one thread uses the API find_topic function while the topic is not defined and the timeout is set, and another thread executes a function that needs the domain participant, the last thread will get blocked because the API find_topic function locks the domain participant and does not release it until the topic is found. Solution: The defect in the find_topic API function is now fixed and no deadlock will occur.
OSPL-1495/ 11040 | In DBMSConnect the mapping from DDS unsigned types to database record fields is not correct When a topic contains unsigned integer fields the mapping to the corresponding database schema is not correct. This means that the data written from DDS to database is not equal to the data that is stored in the database. This mapping is dependent on the DBMS used. For example MySQL supports unsigned integer fields while Microsoft SQL does not. Solution: The mapping of the DDS Topic fields to the corresponding database schema should be made dependent on the type of DBMS that is used. This also applies to the reading and writing of the database records.
OSPL-1557/ 10734 | Crash of durability during initial alignment Unregistrations that are aligned by the durability service are stored without any data to reduce footprint. These unregistrations can only be re-published locally when an instance handle is provided by the durability service while doing so. In some scenario's, the durability service did not use an instance handle while doing so, which made the service crash while locally republishing an aligned unregistration. Solution: The durability service now ensures an instance handle is created in any case while also making sure a registration is created in the instance for the writer that originally wrote the aligned sample.
OSPL-1512/ 11066 | PRECONDITION_NOT_MET doc update The reference manuals did not correctly document all cases where PRECONDITION_NOT_MET could be returned. Solution: Manuals updated.
OSPL-1595/ 11664 | Not receiving data locally when networking is configured but network interface is disconnected When networking does not find an suitable and available network interface networking will terminate. Because the configuration specifies networking to be present the sending of data by a publisher will be affected because it will wait until the network service becomes available. Solution: When networking finds a suitable network interface but the interface is currently not connected then networking has to continue and monitor the status of the networking interface to become available and notify the system that it is available.
OSPL-1669 | Merged historical data is not delivered to active datareaders. When configured for merging after re-connecting, the durability service does not deliver the aligned samples to existing data-readers. Only newly created data-readers from that point forward will get the data. This is caused by some internal optimisation mechanism between the transient store and existing data-readers. The connection between transient store and existing data-readers can be closed in some situation where remote nodes disconnect and the durability service does not re-instate this connection when the node reconnects. Solution: The connection between transient store and existing readers is now checked and re-instated in case a node reconnects.
OSPL-1681/ 11284 | leaseManager reports lease update is behind schedule It was possible that the ospl-info log file reports numerous warnings that the lease is behind schedule. These invalid warnings are comming from the leasemanager that had a fault in the evaluation algorithm of deadline leases which caused these warnings to be displayed while the lease was correct. Solution: The defect in the leasemanager algorithm is now fixed and these invalid warnings will not occur anymore.
OSPL-1682/ 11291 | crash of spliced In certain scenario's the reader purgeList was doing invalid memory reads by trying to access already deleted purgeItems, thereby causing potential memory corruption of totally unrelated objects. Solution: The purge algorithm has been modified to prevent this situation, thus preventing the memory from becoming corrupted and improving the overall stability of the system.
OSPL-1703/ 11354 | Crash of networking when terminating as result of the reception of a signal. When the network service is terminated as result of a signal then the kernel objects created by networking are freed while some of the networking threads may still try to access these kernel objects. Solution: The termination of the networking threads is synchronised with the freeing of the networking kernel resources.
OSPL-1729 | Calling DomainParticipantFactory.set_qos(_) using the Java API segfaults. The underlying JNI layer of the Java DCPS API used the wrong jfieldID when getting a value from Java. Solution: The correct jfieldID is now used.
OSPL-1816 | Re-using a Record and Replay storage in consecutive replay scenarios A issue in the Record and Replay service caused unexpected behaviour when a storage is re-used while it is was previously set to pause using the setreplayspeed command. Solution: The issue is resolved so now a storage can be used multiple times during the lifecycle of a Record and Replay service without any constraints.
OSPL-1852 | Topic disappearance when topic created in parallel In a scenario where a specific topic was created for the first time in the system, but for which a duplicate was created by another application before the original could enable its topic, a refCount to the resulting topic got dropped and that topic could suddenly disappear while still being used by the system. Solution: A change in the refCounting algorithm has now solved this issue.
OSPL-1855 | Synchronous signals sent by external mechanism could cause deadocks. Solution: Signals that are raised by an asynchronous mechanism will now be handled in an asynchronous manner. That means that handling of the signal is delayed until all threads have successfully finished their consultations/modifications of the shared memory, leaving it in a consistent state. Also our signal handler will no longer be installed when an (ignorable) signal is set to SIG_IGN.
OSPL-1867/ 11443 | System termination fallback mechanism When a service crashes and system termination is set into progress, a safe system termination is not always guaranteed i.e. the service could end up in a deadlock stalling system termination. This is not acceptable and the system should always terminate. Solution: A new service termination thread is spawned when the system state of a process is set to terminating. This thread waits for 5 seconds to see if the process goes from the terminating state to the terminated state. If this has not happened after 5 seconds the process is being killed by means of _exit.
OSPL-1923 / 11472 | Application not detached from shm after deletion of all the participants. When an application creates 2 or more participants and all these participants are deleted using the delete_participant function, the application still hold a reference to the shared memory. Solution: The defect is now fixed and when all participants from an application are gone the connection to the shared memory is also gone.
OSPL-1926 / 11518 | Read of disposed instance may return null for key string fields on java When reading an disposed instance using the java API then it can occur that the returned sample has the key fields not set. This occurs when the topic contains a non key string field which precedes fields that are key fields. Solution: The copy function used when reading a sample has to walk over all fields of a sample and not stop at the first non key string field.
OSPL-1934 | Durability PartitionTopic configuration for a NameSpace is not available in configurator The ability to configure partition-topic combinations for NameSpace contents for the durability service has been added recently. The configurator tool was not updated to include this configuration option. Solution: The configurator tool has been extended with the missing PartitionTopic configuration option.
OSPL-1936/ 11509 | Reporting/tracing of networking service could be improved In case the networking service is configured to allow re-connections, it should report when a remote node re-connects. In addition, the networking service should also report the channel when reporting a missing packet in its trace (if configured) as well as report when and if the missing packet is received to be able to find out if the service recovered from the missing packet or not. Solution: The reporting and tracing extensions requested above have been added to the networking service.
OSPL-1946/ 11512 | With compression or encryption enabled lost packets may not be resent In some situations networking would try to access the compressed and/or encrypted content of a packet in its resend administration, causing packets to not be re-transmitted. Solution: All information needed for (re-)sending of a packet are read from the packet-buffer before compression and/or encryption.
OSPL-1952 | Re-creation of topic definitions from the XML persistent store can cause application and service to crash The XML persistency implementation of the durability service uses a deprecated (de)serializer to store topic definitions to disk and to recreate them after start-up. When using this particular serializer it is possible that types can be resolved from DDS already by other services or applications before they are finalized. When such an incomplete type is used the process that uses it crashes. Solution: The durability service now uses a new (de)serializer that ensures that types cannot be resolved before being finalised. For backward compatibility, the durability service is still able to read the old serialized format from disk. In that case it still uses the old serializer, but it ensures to write any new definitions using the new serializer and therefore the new format.
OSPL-1998/ 11540 | Durability and Memory Consumption When using the durability service in combination with the XML persistent store and the following topic QoS settings: durability_service QosPolicy: history_kind = KEEP_LAST_HISTORY_QOS, history_depth = 1 destination_order QosPolicy: kind = BY_RECEPTION_TIMESTAMP_DESTINATIONORDER_QOS. Memory leakage can be observed. Solution: The defect in durability service is now fixed and in the described scenario data will not leak anymore.

## 6.2.2

Report ID. | Description
--- | ---
OSPL-1682/ 11291 | crash of spliced In certain scenario's the reader purgeList was doing invalid memory reads by trying to access already deleted purgeItems, thereby causing potential memory corruption of totally unrelated objects. Solution: The purge algorithm has been modified to prevent this situation, thus preventing the memory from becoming corrupted and improving the overall stability of the system.
OSPL-1729 | Calling DomainParticipantFactory.set_qos(_) using the Java API segfaults. The underlying JNI layer of the Java DCPS API used the wrong jfieldID when getting a value from Java. Solution: The correct jfieldID is now used.
OSPL-1852 | Topic disappearance when topic created in parallel In a scenario where a specific topic was created for the first time in the system, but for which a duplicate was created by another application before the original could enable its topic, a refCount to the resulting topic got dropped and that topic could suddenly disappear while still being used by the system. Solution: A change in the refCounting algorithm has now solved this issue.
OSPL-774 | New rmipp option to export generated code Solution: A new command line option has been added to the RMI pre-processor to be able to create a Windows DLL from generated code. This option is: -P dll_macro_name[,] Only applicable to C and C++. Sets export macro that will be prefixed to all functions in the generated code. This allows creating DLL's from generated code. Optionally a header file can be given that will be included in each generated file.
OSPL-1076/ 10787 | Compression in networking is not configurable other than on/off. Data compression typically involves a trade-off between CPU usage and the amount of compression achievable. The utility of the compression feature would be increased by allowing more flexibility in terms of this trade-off. Solution: The compression "level" of the existing zlib compressor may now be configured. Other compression algorithms may also be used. See the Deployment Guide for details.
OSPL-631/ 10459 | Using read or take with max_samples limit set can cause some key-values to be never read. The read and take operations return instances starting with lower key-values. If not all available data is read at once (e.g., when having set the max_samples limit) and the lower key-values keep receiving updates, a subsequently performed read operation will return the updated instances, which may prevent the higher key-values to be read. Solution: The read and take operations are changed to provide data circularly from a cursor. This means that these operations will 'resume' a read as if read_next_instance was succesively called. This way all instances can be read even when lower key-values get updated between two read-operations with a max_samples limit.
OSPL-1023 | Service failure actions can be taken multiple times When multiple services are known to the service framework, a failure action can be taken multiple times. Solution: The defect in the service failure action algorithm is now fixed and the action will only be done once.
OSPL-1051 | OpenSplice RMI Services Activation/De-activation in one call Services activation was done in a per-service basis. A given service becomes active (waits for incoming requests) by calling 'DDS_Service::run(service_name, ...)' which could be either blocking or non-blocking according based on the provided arguments. To activate multiple services, the "run" operation must be called as many times as there are services. Solution: Two new operations has been added to the "CRuntime" class to activate and de-activate all the registered services in one call: - CRuntime::run() - CRuntime::shutdown(bool wait_for_completion = true) The "run" operation is a blocking operation that blocks the calling thread until the shutdown is called. DDS_Service::run operation is kept but it becomes non blocking. It is recommended to use the CRuntime object for services activation and de-activation.
OSPL-1166/ 10823 | Terminating the "ospl -f start" operation may not kill all services The algorithm in ospl that performs the shutdown of the splice daemon and its child services in the case of blocking mode did not correctly detect whether the splice daemon had been terminated. This meant that it was possible that the splice daemon and its services may not necessarily have been terminated when "ospl -f start" returns. Solution: The shutdown algorithm in ospl has been improved to correctly detect the termination status of the splice daemon in both normal and blocking modes.
OSPL-1172/ 10827 | Performance difference between the datareader listener and subscriber listener In certain scenarios the subscriber listener handling is faster than the datareader listener handling. Solution: The handling algorithm of the datareader listener is improved to match the subscriber handling.
OSPL-1341/ 10914 | The reliable network communication may not operate correctly when the first messages of a sending node arrive out of order. When reconnection is enabled and when the first messages of another starting node arrive out of order and also the discovery heartbeats arrive later then the first message the reliable network channel will not operate correctly. Solution: The notification that a node has become alive by the discovery protocol should not reinitialize the reliable channel administration associated with that node when the reliable channel had already detected that the node was alive.
OSPL-1384/ 10907 | OpenSplice logs errors when the XML configuration file contains DOCTYPE descriptors Solution: Thecode that logged the errors has been removed.
OSPL-1393/ 10907 | The DDSI2 service uses Watchdog scheduling parameters from RT networking config The DDSI2 service incorrectly used the NetworkService/Watchdog element instead of DDSI2Service/Watchdog element from the OpenSplice configuration file for determining the scheduling parameters of the watchdog thread. Solution: It now uses DDSI2Service/Watchdog.
OSPL-1051 | OpenSplice RMI Services Activation/De-activation in one call Services activation was done in a per-service basis. A given service becomes active (waits for incoming requests) by calling 'DDS_Service::run(service_name, ...)' which could be either blocking or non-blocking according based on the provided arguments. To activate multiple services, the "run" operation must be called as many times as there are services. Solution: Two new operations has been added to the "CRuntime" class to activate and de-activate all the registered services in one call: - CRuntime::run() - CRuntime::shutdown(bool wait_for_completion = true) The "run" operation is a blocking operation that blocks the calling thread until the shutdown is called. DDS_Service::run operation is kept but it becomes non blocking. It is recommended to use the CRuntime object for services activation and de-activation.
OSPL-1478/ 11042 | BOUNDS_CHECK does not report the name of the incorrect member when the member is null. The copyin routines for C and C++ did not check for null-values in string fields. Solution: Check for null-values in string-fields is added.
OSPL-1479/ 11041 | Bugfix to allow correct rebuilding of the C++ APIs ( customlibs ) on 64bit linux systems.. Rebuild would fail due to an incorrect makefile. Solution: Makefile corrected.
OSPL-1489/ 11042 | Licenses inconsistent. The $OSPL_HOME/LICENSE file was version 2.6, but the StdLicenseterms2.3.pdf is for 2.3 Solution: PDF corrected to 2.6.
OSPL-1511 | Setting the buffer size of the receive socket to the configured value may fail Setting the receive buffer size of the receive socket to the configured value may fail which may cause message loss in case of worst case expected network load. Solution: When setting the receive buffer size of the receive socket to the configured value a warning report is logged if the operating system doesn't apply the setting.
OSPL-1558 | Durability sometimes creates conflicting namespace for __BUILT-IN PARTITION__ when partitionTopic is used in namespace-definition. Durability could automatically create conflicting namespace for __BUILT-IN PARTITION__ when partitionTopic is used. Solution: Durability now only creates a namespace in which the builtin-topics are matched, instead of matching the whole builtin-partition.
OSPL-1597/ 10974 | DDSI2 external address setting refuses valid IP addresses The DDSI2 General/ExternalNetworkAddress configuration setting contained an error in validating the specified address, causing valid IP addresses to be rejected. Solution: The validation code has been corrected.
OSPL-1639 | The OpenSplice DDS Tuner can not write bounded strings. When a bounded string is written by the OpenSplice DDS Tuner and this value is read back by the system a null reference occurs where the text of the string should have been. Solution: The defect in the OpenSplice DDS Tuner is now fixed and bounded strings are now correctly written to the system.
OSPL-1621/ 11189 | Leakage of instances when built in topics not configured. When OpenSplice is configured not to transmit builtin topics the deletion of a datawriter was no longer reported to the rest of the Domain resulting in the leakage of instances that belonged to that datawriter and that were not unregistered explicitly prior to the deletion of that datawriter. Solution: A sample for the DCPSPublication topic is now always sent on the deletion of a datawriter, regardless of the configuration setting for builtin topics. However, this sample is non-transient and will be consumed immediately, so that it does not accumulate unnecessary resources.

## 6.2.1p2

Report ID. | Description
--- | ---
OSPL-626 | Allow configuration of the UDP port number ranges that networking may use for the reliable channels for receiving ACK and resend messages Each reliable network channel requires an extra UDP port which other nodes used to send their ACKs and resend messages to. When several single process instances are used each single process requires for each reliable channel an unique UDP port number for this purpose. This enables control over the used UDP port numbers which may be needed when firewall are used. Solution: A configuration element "AllowedPorts" is added to either the networking channels or channel configuration which specifies the range (list) of UDP port numbers available. When specified an available port from the configured port range is used. When not specified the configurated channel port+1 is used when it is avaliable, otherwise a dynamic allocated UDP port is used. (Note: Deployment manual will be updated at 6.2.2 release. Use the configurator tool for further information.
OSPL-1326 | Idlpp crashes when two types in different modules have the same name and one of them has a keylist When an idl is used with 2 or more types in different modules and they have the same name and one or more have a keylist idlpp will crash. Solution: The fault in idlpp has been fixed and it is now save to use multiple types with the same name and a keylist in idl.
OSPL-1474/ 11036 | Windows Event Log plug-in failure to initialise The Windows Event Log plug-in could fail with an access violation. This could prevent the OpenSplice daemon starting as a Windows service as this plug-in is configured to be used by default in this circumstance. Solution: The Event Log now initialises correctly.
OSPL-1488 | DDSI2 fails to handle keyed topics with 64 members (and some variations) DDSI2 potentially performs some key re-ordering to remove the dependencies between the ordering of keys in the original IDL topic definition, the order of in which the members of the topic are serialised and the order in which the key fields are serialised. An mistake was found in the arithmetic that caused it to refuse topics with more than 64 members, or one with a key inside a nested struct with 32 fields inside one with 33 fields, &c. In such a case, no DDSI DataReaders and DataWriters would be created and no communication would take place for that topic, and the error log showed a generic error message: "handlePublications: new_writer: error -1" or "handleSubscriptions: new_reader: error -1". Solution: It now performs as intended and handles large structs correctly.
OSPL-1521/ 11075 | Datareader deletion could cause memory leaks Under certain conditions datareaders would not clean up their resources when becomming deleted. These leaks could occur when readers refuse to connect to writers because of a partition mismatch. Solution: The defect in the cleanup algorithm of datareaders is now fixed and will not leak anymore.
OSPL-1522/ 11074 | A reader subscribing to transient data using the "*" (wildcard) partition when samples are written to multiple partitions may lead to duplicate samples at the reader When a reader subscribes to a newly created topic/partition combination, because a writer on that partition has just been created, it should also request the historical data associated with combination. The issue was that it was actually being delivered the historical data for all partitions, including those for which samples may have already been delivered and read/taken. Solution: The behaviour has been changed so that historical samples are only delivered for the specific topic/partition that the reader has just subscribed to.

## 6.2.1p1

Report ID. | Description
--- | ---
OSPL-1326 | idlpp crash when two types in different modules have the same name and one of them has a keylist When an idl is used with 2 or more types in different modules and they have the same name and one or more have a keylist idlpp will crash. For example;
                  module A {
    struct Z {
    long m;
    };
    };
    struct Z {
    long m;
    };
    #pragma keylist Z
Solution: The fault in idlpp has been fixed.
OSPL-1422 | Lookup_instance leaks memory The DataReader_lookup_instance call leaked one string for topics with string-keys, when a non-existing instance was looked up in a non-empty set. Solution: The leak is fixed.
OSPL-1424 | DDSI2 can stop accepting data when receiving fragments of old samples TDDSI2 defragmentation buffers have limited capacity and when full decide what to accept and what to drop on a policy that favours lower sequence numbers of higher ones in case of reliable communication. This policy causes the buffers to fill up slowly when every now and then a subset of the fragments of a sample arrive, but not all of them. This can only happen for "old" samples, as they have will been delivered to the data readers and no retransmits will be requested. Under normal circumstances it is very rare to receive some retransmitted fragments after receiving the full sample, but on networks with long delays, reordering and packet loss, such as a WAN, this problem is quite likely to surface. Solution: The current solution actively drops already accepted data from the defragmentation buffers, preventing uncontrolled build-up of incomplete samples.
OSPL-1425 | DDSI2 can request a retransmit of a full sample in addition to a retransmit of some of its fragments TDDSI2 considers the full state of a proxy writer and its data readers when generating a retransmit requests in response to a writer heartbeat, with the aim of generating the least costly retransmit request for the missing data. However, it can generate a retransmit request of some fragments of a sample while simultaneously requesting a retransmit of the full sample. Solution: The retransmit request for the full sample is now suppressed in cases where a retransmit of some fragments is requested.
OSPL-1426/ 10961 | DDSI2 can crash on topic creation On platforms where malloc(0) returns a null pointer, DDSI2 could crash on topic creation. Solution: DDSI2 now explicitly allows for this.

## 6.2.1

Report ID. | Description
--- | ---
OSPL-871 | Incorrect determination of the lifespan The lifespan expiry time is determined when a message is inserted in the reader. If the ReaderLifespanQos is enabled, the lifespan duration is always extracted from the ReaderLifespanQos. Both ReaderLifespanQos and the (inline) LifespanQos of the message should be considered. The earliest expiry time should be the one that is used. Solution: The expiry time determination algorithm has been fixed and will now also consider the (inline) LifespanQos of the message.
OSPL-997/ 10738 | ReaderLifespan QoS not rewarded in combination with read with condition When a read with condition is done and the ReaderLifespan QoS is set the Qos is not evaluated. This possibly results in that the reader can return samples that are already expired. Solution: The read with condition algorithm has been fixed and will now check the ReaderLifespan Qos when it is set.
OSPL-1181 | Record and Replay Service does not adhere to service lease settings The Domain configuration of OpenSplice contains a section on service leases: a mechanism that monitors the health of OpenSplice services. The RnR service did not correctly register with this mechanism, causing a message to appear in the ospl-info.log informing the user the R&R service has died while actually it was still running. Solution: The service now adheres to the 'Domain/Lease/ExpiryTime' configuration settings and the message is only printed to the OpenSplice info log when the service actually terminates unexpectedly.
OSPL-1302 | DDSI2 can miss local discovery events causing issues or blocking behaviour DDSI2 needs to react to the creation of readers, writers and participants on the same node, as well as to the creation of new partition-topic combinations and some housekeeping events. Under adverse timing conditions it may fail to process all events if some are combined into a single event record for efficiency. Solution: It now always processes all events in a single event record.
OSPL-1324 | Time-range not applied correctly in REPLAY commands An issue with processing time-ranges in REPLAY-commands caused problems when multiple interest-expressions are used in a single REPLAY-command. Time-ranges would only be applied to the first interest expression, causing data matching other interest-expressions to be replayed without the desired time-range constraints. Solution: Time-ranges are now applied to all interest-expressions in the command. In case the storage also contains data that should be replayed regardless of time-range constraints, a second REPLAY-command can be used.
OSPL-1392 | OSPL-XML metadescriptor optimizations The XML metadescriptor, which is used internally to communicate idl types, was using fully-scoped where a relatively scoped name would suffice, and did no optimization on the ordering of types, which potentially results in a lot of unnecessary module open and close tags. Solution: Relatively scoped names are used wherever possible. An algorithm is introduced that orders types based on their module, so the number of module-transitions is minimized.
OSPL-1392 | Time-range not applied correctly in REPLAY commands An issue with processing time-ranges in REPLAY-commands caused problems when multiple interest-expressions are used in a single REPLAY-command. Time-ranges would only be applied to the first interest expression, causing data matching other interest-expressions to be replayed without the desired time-range constraints. Solution: Time-ranges are now applied to all interest-expressions in the command. In case the storage also contains data that should be replayed regardless of time-range constraints, a second REPLAY-command can be used.
OSPL-1395 | VxWorks distribution incorrectly included duplicated header files Prior to this release the VxWorks distribution erroneously included a second copy of some files from $OSPL_HOME/include/include in the directory $OSPL_HOME/include. This resulted in compilation errors whenever the required OpenSplice product include directories were specified in the order: -I"$(OSPL_HOME)/include" -I"$(OSPL_HOME)/include/sys". Solution: The duplicated files have been removed. Compiler header directory include directives can be specified in any order.

## 6.2.0

Report ID. | Description
--- | ---
OSPL-511 | Default OSPL xml configuration files not available in RTS The xml configuration files suppolied by default with the HDE were not in the RTS installer. Solution: Configuration files standardised across HDE and RTS installers.
OSPL-532 | DDSI2 keyhash generation is wrong for some cases DDSI2 always generates the keyhashes included in the DDSI standard (they are spec'd as optional). For topics of which the (big-endian) CDR representation of the key is or may be longer than 16 bytes the keyhash is computed as the MD5 hash of the serialized key.DDSI2 produces an incorrect hash on little-endian platforms for keys containing bounded strings where the total serialized length of the key is >= 17 and <=32 bytes. In practice this affects interoperability when multiple nodes publish the same instance:- between little- and big-endian machines running DDSI2- between little-endian DDSI2 and any other DDSI implementation. Solution: Corrected the keyhash generation.
OSPL-511 | OpenSplice Threads should be named To assist users (especially in the single process architecture) to name the threads used by OSPL. Solution: Major OSPL threads have been named.
OSPL-558 | Narrow operation in examples leaking The use of the c++ _narrow operation on the created readers and writer entities in some of the OpenSplice examples led to memory leaks. Solution: These leaks have been resolved by better use of the _var helper type when calling the _narrow operation.
OSPL-593 | OpenSplice domain service installation as a native windows service At OpenSplice v6.1 running the OpenSplice domain services under the Windows Service Control Manager required the Windows Common Language Runtime. It also required the nomination on installation of a single global log directory that would hold all OpenSplice service and application process logs. When selecting to install the domain as a Windows service an incompatible 'single process mode' OpenSplice XML configuration file was installed by default. Solution: Installing and running OpenSplice services as a Windows Service now uses only unmanaged APIs so the .NET CLR is no longer required. A global log directory is no-longer required or prompted for during product installation. The installer will specify a 'shared memory' service configuration and will include a domain configuration entry to direct the log output from service processes to the Windows Event Log,for instance:
       <Domain>
    ...
    <ReportPlugin>
    <Library file_name="service_logger" />
    <Initialize symbol_name="service_logger_init" />
    <TypedReport symbol_name="service_logger_typedreport" />
    <Finalize symbol_name="service_logger_shutdown" />
    <SuppressDefaultLogs>True</SuppressDefaultLogs>
    <!-- Change below to 'False' if you wish to log OpenSplice system log events from application proceses
    to the EventLog also -->
    <ServicesOnly>True</ServicesOnly>
    </ReportPlugin>
    </Domain>
See the Deployment Guide for more information regarding log plug-in configuration. Note that by default OpenSplice log events from application processes will still now be written to ospl-error/info.log files in the local directory, just as when not running OpenSplice as a Windows Service, but that this can be changed as per the comment in the snippet above. Note also that this entry can still be added to your OpenSplice domain configuration when OpenSplice is not installed as a Windows Service to direct service (or service and application) log output to the Event Log.
OSPL-659 | The C++ using the standalone C DCPS API 'PingPong' example has been removed The C++ using the standalone C DCPS API 'PingPong' example duplicated the code already available in the standalone C DCPS API 'PingPong' example unnecessarily given that the use of a C API from C++ is trivial. Solution: The example has been removed. Users wishing to use the standalone C DCPS API from C++ should refer to the the standalone C examples. These can be compiled with a C++ compiler.
OSPL-711 / OSPL-788 | Scheduling parameters for the top level service threads does not work when using single process deployment When applying scheduling(OpenSplice/Domain/Service/Scheduling) properties when using single process deployment the scheduling properties are not applied on the service. Solution: The defect is now fixed and the service thread will get the configured scheduling settings.
OSPL-775 | Exceptions 'throw' statements in rmi C++ generated code For consistency and best practice, the C++ exceptions specification has been ignored and instead the IDL to C++ mapping rules followed. Solution: All 'throw' specifications were removed from the RMI C++ generated code.
OSPL-778 | DDSI2 does not always deliver data for wildcard-based subscriptions To deliver data from remote writers to subscriptions using partition wildcards, DDSI2 sometimes needs to locally register the actual partition used. However, the optimisation used to avoid doing so unnecessarily did not correctly handle case in which a wildcard reader was matched to writers in different partitions. Solution: Optimisation corrected.
OSPL-781 / 10369 | The reliable channel does not operate correctly when using IPv6 on the Windows platform For Windows a bind is performed on the sending socket using the same portnumber as used by the receiving socket. This may cause that ACK messages are not received and that the reliable communication fails. Solution: The bind is not necessary at the sending socket and is removed.
OSPL-801 | C API ReaderDataLifecycleQosPolicy QoS policy attribute inconsistency There is an inconsistency between the naming of the ReaderDataLifecycleQosPolicy QoS policy attribute 'invalid_sample_visibility' between the C (SAC) API and other APIs. In the other APIs it is called 'invalid_sample_visibility' and in C (SAC) API it is called 'invalid_samples_visibility' (in plural form). Solution: The ReaderDataLifecycleQosPolicy QoS policy attribute in the C (SAC) API is now also changed to 'invalid_sample_visibility'
OSPL-807/ 5725 | Durability resource_limits.max_samples QoSPolicy is not applied properly When a max_samples resource limit is set in the QoS of the Topic, samples could get rejected even though the limitwasn't reached. This was caused by the fact that the samples that overwrote a previous value sometimes resulted in an increasing number of samples in the administration that counted the samples where the counter should have remained at the same value. Solution: The counter for the number of samples is now not increased any longer when the sample overwrites a previous value.
OSPL-808/ 7136 | Tuner does not allow to edit array elements When connecting the Tuner and creating a reader/writer to a running system that contains a topic with array elements, it shows that in the Writer tab, the elements of the array can not be modified. Solution: The defect in the Writer tab is now fixed and array elements can be edited now.
OSPL-809/ 8239 | Durability does not allow to overrule alignmentKind for built in partition. The durability does not allow to overrule alignmentKind for the name space with the built-in partition. If set to Lazy, durability will create an extra name space with the built-in partition and alignmentKind set to Initial_And_Aligner. Solution: The durability service now no longer overrides the behaviour for the built-in topics, but only if they are disabled in the Domain configuration (//OpenSplice/Domain/BuiltinTopics[@enabled]).
OSPL-814/ | When spliced discovers a disconnecting node it only unregisters 1 DataWriter per partition-topic combination When spliced discovers a disconnecting node by its missing heartbeatst, it unregisters all writers belonging to the disconnected node. However, maximally only 1 DataWriter is unregistered for a specific partition-topic combination. If the disconnected node has more than 1 writer attached to the same partition-topic combination, only one of them will be unregistered. Solution: The internal algorithm that takes care of the unregistration of disconnected DataWriters has been changed to ensure all DataWriters of the disconnected node are unregistered.
OSPL-820 | ospl tool should ensure the environment is cleaned up before termination when started in blocking mode When the ospl tool is started in blocking mode (ospl -f start), it should ensure that both the shared memory segment and the key-file are deleted before terminating. In the normal case on UNIX-platforms where spliced is requested to stop with a SIGQUIT or SIGTERM, that service will clean up all resources itself. However, when spliced is terminated with a SIGKILL, ospl should take care of the clean-up. Solution: Ospl now ensures that key-file and shm segment are cleaned up when started in blocking mode, even when spliced is killed with a SIGKILL
OSPL-836 | DDSI2 fails to report configuration errors in error log DDSI2 configuration error handling lost the ability to write configuration-related error messages to the OpenSplice error log. It instead prints them on stderr which may be noticed on Unix boxes when using "ospl start", but is typically lost on windows. Solution: DDSI2 now reports configuration errors to the error log again.
OSPL-844 | Issues with starting OpenSplice Tuner and OpenSplice DCG Setting the SPLICE_TARGET environment variable could result in problems starting the OSPL Tuner and DCG tools. Solution: The SPLICE_TARGET is no longer set by the Tuner and dcg scripts.
OSPL-846 | SampleInfo should be extended with reception_timestamp for all language bindings For all language bindings, a new field has been added to the SampleInfo called reception_timestamp. This field represents the local time at which the corresponding sample has been delivered to the reader from which it is being accessed.
OSPL-854/ 10511 | read/take returns NO_DATA while the reader has data In case the data sequence and sample info sequence _maximum are set to 0 and the _release flag is set to TRUE, for a read or take call with max samples set to unlimited, The read or take call will always return with code NO_DATA. Solution: The defect in the read/take call is solved and now returns the correct data.
OSPL-890/ 10558 | Queried meta descriptor incorrect Sometimes a queried meta-descriptor string seems incomplete and is not equivalent with the original meta-descriptor. Solution: An internal error in the XML meta-descriptor (de)serializer has been repaired to fix incorrect behaviour on types with inter-module dependencies
OSPL-904 | Reader returns NO_DATA, while samples are available and not read When using read_next_instance_w_condition where a handle is NIL readcondition is set with sample state NOT_READ, view state ANY, instance state ANY the reader has more than one instance with one sample per instance then on first call it delivers the sample of the first instance, but the second time it returns NO_DATA although sufficient samples are available. Solution: The defect in the read function has been fixed and now returns a sample when available.
OSPL-908 | Crash when calling DDS_DataReader_create_view in combination with content filtered topics When calling the DDS_DataReader_create_view function and the system contains content filtered topics a crash can occur. Solution: The defect in the DDS_DataReader_create_view call has been fixed and will no longer crash.
OSPL-924 | Faulty masks evaluation on dataView The masks evaluation on dataView was faulty due to this queries could continuesly be triggering. Solution: The defect is now fixed and the masks are evaluated properly.
OSPL-942 | mmstat maintenance Minor work to improve mmstat It crashes when running in -t mode but without having a Domain running. When running in -M mode, a new header is generated for each line. This garbles up the output so it should be similar to the -m mode, where a header is printed every 15 lines When using the -o flag without the -n flag, no items are displayed. By default it should just display everything when no explicit number is specified The -n flag only works in combination with the -o flag. This should be indicated in the help. Solution: Changes applied for the above issues.
OSPL-958 | User clock module dlopen error in error log file. When a UserClockService is configured the configured library does not load and an error (dlopen error) gets reported in the error log. Solution: The configured library resolving algorithm contained a fault and is now fixed. The library resolving now follows the following rules: when the library name contains a path open this path. If this fails, add lib in front of the name and .suffix (depending on the host OS this can be so, ddl or dylib) behind it and try to open this library if that fails, try to open the given library name
OSPL-970 | Improvements to DDSI2 network interface selection In multi-homed systems it is often necessary to instruct DDSI2 which network interface to use using the General/NetworkInterfaceAddress setting. Until now, this required specifying the exact IP address of the host for that network interface, in essence requiring each host to have its own configuration file. Solution: New options for specifying the network interface have been added: The name of an interface (e.g., eth1) is now acceptable For IPv4 networks, if there is no exact match on the full IPv4 address, DDSI2 will attempt to match on the network portion only as determined by the network masks of the interfaces. It requires that the host portion of the specified address is all-zero for such a match. With these changes, in the vast majority of cases, there is no longer a need for a configuration file per host. Furthermore, a warning is appended to the info log whenever DDSI2 automatically selects an interface out of several available that have equal ranking. The ranking itself is unchanged, with multicast-capable networks preferred over others, then anything non-point-to-point, point-to-point and loopback interfaces.
OSPL-977 | DDSI2 can crash when a remote entity disappears DDSI2 can potentially crash when a remote entity disappears. This requires its lease to expire in parallel with processing an explicit notification of that remote entity being deleted. Solution: A fix is applied to prevent the crash.
OSPL-1008 | Applications may deadlock or crash during signal handling Applications may deadlock or crash when a signal is received within internal signal handling algorithm. Solution: The internal signal handling algorithm has been adapted to allow users to set their own signal handler. Furthermore, the algorithm ensures that handling of asynchronous signals is performed in a dedicated thread to prevent deadlocks during clean-up of DDS entities..
OSPL-1021 10758 | Clash with TEST macro from c_mmbase.h The database code referenced a macro named TEST which could possibly clash with other external software and application code. Solution: This has been renamed to a better scoped C_MM_STATS macro.
OSPL-1033 /10767 | Reference manuals incorrect for create_particpant The reference manuals still had the V5 API definition documented for create_particpant API. Solution: Reference manuals now correctly state the domainId is an integer.
OSPL-1035 /10764 | DDSI2 failure to deserialize bounded strings of maximum length DDSI2 validates all data coming in over the network, but the input validator erroneously considered strings in received network packets of which the length equalled the specified bound as being oversize. Solution: DDSI2 now handles this correctly.
OSPL-1049 /107678 | Java application crash on type register Randomly, on type register, a java application can crash with the following notice: malloc(): memory corruption. Solution: The type register memory allocation algorithm for java has been fixed and will no longer crash.
OSPL-1077 | The dynamic discovery protocol does not detect all nodes for RT networking. Dynamic discovery protocol makes use of unicast communication to find all the nodes and roles. However the data is sent to the wrong port number which depending on the configuration may mean not all nodes are detected. Solution: When sending point-to-point data on a best-effort channel the destination port should be the primary port of the channel.
OSPL-1085 | Secure Networking parsing of Credentials tag in XML configuration fails Solution: The spelling mistakes in the secure network configuration files have been corrected to be "Credentials" rather than "Credentails".
OSPL-1115 | Specific configuration may cause a crash of secure RT networking. When the configuration of secure networking does not contain specific elements then secure networking may crash because it frees un-allocated memory. Solution: Check if configuration elements are allocated or not.
OSPL-1125 | The OpenSplice installer no longer uses Windows SDK Global Assembly Cache Utility (gacutil.exe) to install the C# binding assembly. Previously, selecting an option when running the OpenSplice installer used the Windows SDK Global Assembly Cache Utility (gacutil.exe) to install the C# binding assembly into the Global Assembly Cache. The MSDN documentation says the following regarding this tool: "In deployment scenarios, use Windows Installer 2.0 to install assemblies into the global assembly cache. Use the Global Assembly Cache tool only in development scenarios, because it does not provide assembly reference counting and other features provided when using the Windows Installer." Solution: The installer option of using the gacutil.exe to install the assembly has been removed. If users wish to install the C# binding assembly into the Global Assembly Cache for development purposes they may use the gacutil.exe themselves to do this. Instructions for doing this are included in the Deployment Guide. Users should use a suitable approved method to install the assembly in deployment scenarios, if required.
OSPL-1127 | The supported Access Control Module for Secure RT networking is identified as "MAC" which is not correct in the implementation. In the configuration the currently supported Access Control Module is MAC. In the implementation an other name is used. Solution: The name of the supported Access Control Module is changed to "MAC".
OSPL-1131 | DDS_string_dup method added to the SAC DCPS mapping The DCPS SAC mapping did not have a convenient function that could be used to duplicate strings. Solution: A DDS_string_dup function has been added to the SAC DCPS mapping. Its signature is `DDS_char* DDS_string_dup (const DDS_char* src);`. The memory allocated must be freed using DDS_free().
OSPL-1148 | end_coherent_changes() may crash if the publisher contains a writer that did not write any samples in that coherent update There was an issue where calling end_coherent_changes() on a publisher may cause a crash if that publisher contained a data writer that had not written any samples as part of that coherent update. The algorithm assumed that every writer belonging to a coherent publisher would write samples within each coherent update. Solution: The algorithm in end_coherent_changes() has been fixed to also support data writers that were not active during that coherent update.
OSPL-1156 | The Secure RT Networking security policy file is not parsed correctly. The security profile should contain a classification element in the resource section. This element is not parsed correctly. Solution: Add the parsing of the classification element to the security profile parser.
OSPL-1157 | Secure RT networking may drop messages when authorization is enabled.. The secure RT networking implementation uses libcrypto. Further secure networking is multi threaded which may cause that multiple threads may access this library concurrently which causes that the checking of the RSA signature fails. Solution: To operate libcrypto using concurrent threads callbacks are implemented which provide the locking mechanism.
OSPL-1158 | DDSI2 could fail to provide historical transient local data in configurations without durability In OpenSplice delivering historical data to new non-volatile readers is normally handled by the OpenSplice kernel and durability service. However, the DDSI specification prescribes an implementation of transient-local data that DDSI2 adheres to, in allowing many minimum-profile application to run on OpenSplice without a durability service present. In this configuration, DDSI2 does not always provide the historical data, instead discarding a sample as if it were a notification of a lost sample. Solution: This issue has been fixed by correctly setting the relevant data.
OSPL-1310 | Configurator tool does not allow configuring the Report element The //OpenSplice/Domain/Report element is missing in the configurator tool. Solution: The configuration element plus its attributes have been added to the configurator tool.
OSPL-1312 | Default Lease ExpiryTime and updateFactor are incorrect in configurator tool The default Lease ExpiryTime is set to 10.0 in the splice daemon but to 20.0 in configurator tool. The updateFactor is set to 0.2 in the splice daemon but to 0.1 in the configurator tool. Solution: The configurator tool has been updated to match splice daemon implementation.
OSPL-1314 | Inconsistent linkage of OpenSSL to secure networking services on Windows x86-64 On the above platform the secure networking services were dynamically linking Open SSL requiring the user to install Open SSL in order to use them. This was at odds with the behaviour on all other platforms. Solution: The secure networking services statically link a version of Open SSL on Windows x86-64. The secure networking services will be changed to dynamically link to Open SSL in a future version of of the product.

## 6.1.1p4

Report ID. | Description
--- | ---
OSPL-1017/ 10755 | Added support for Windriver Linux 4.3 on Freescale MPC8308 Solution: Implementated platform support for windriver linux 4.3 on mpc8308

## 6.1.1p3

Report ID. | Description
--- | ---
OSPL-1017/ 10755 | Durability crashes when alignment data contains only unregister messages The 6.1.1p2 release failed on this issue. Solution: Correctly applied patch to resolve the issue.
OSPL-1092/ 10791 | Liveliness notifications to data readers created on multiple partitions may not happen If a data reader is created on two partitions, say "A" and "B", then it will only receive liveliness notifications for the partition that is last lexicographically, i.e. only for "B", despite a new data writer being created on partition A.. Solution: The algorithm that determined whether a data reader's partitions match that of a data writer has been fixed to ensure that it supports a data reader with multiple partitions. This means that a notification can now happen for more than just the final partition in the list

## 6.1.1p2

Report ID. | Description
--- | ---
OSPL-1017/ 10755 | Durability crashes when alignment data contains only unregister messages In the scenario where there are only unregister messages aligned by the durability service for a given partition-topic combination, the service would crash because an instance lookup would fail. Solution: Durability is made robust against this kind of scenario.
OSPL-1035/ 10764 | DDSI2 failure to deserialize bounded strings of maximum length DDSI2 validates all data coming in over the network, but the input validator erroneously considered strings in received network packets of which the length equalled the specified bound as being oversized. Solution: The error in the validator has been fixed

## 6.1.1p1

Report ID. | Description
--- | ---
OSPL-892/ 10091 | DDSI2 can respond with incorrect set fragments to retransmission requests The DDSI protocol allows reliable readers to request retransmission of individual fragments of large samples. DDSI2 could respond with fragments other than the ones requested, which could generally be masked by an eventual request for the full sample to be retransmitted, but would cause the communication to come to a complete standstill if a particular fragment always got lost. For example, when the rapid (re)transmission of a large amount of data systematically lead to a switch throwing away a whole range of packets. Solution: DDSI2 now always responds with the requested fragments.
OSPL-919 | C# Examples do not compile on Windows 64 bit platforms The C# Examples do not compile on Windows 64 bit platforms. This was caused by 2 problems: - missing entries in the solution file - bugs in the example source code Solution: The missing entries have been added to the solution file and the bugs fixed in the example source code.

## 6.1.1

Report ID. | Description
--- | ---
OSPL-301/ 10110 | handle.serial exceeds HANDLE_SERIAL_MASK Two different perceptions of the maximum serial number for a handle exist within the product. Once the serial becomes larger than the smallest maximum, the reported error occurs. Solution: The maximum serial number to be used is now to same in both locations in the product.
OSPL-508/ 9816 | Idlpp crashes on invalid recursion. Solution: idlpp will check if a type is defined before it is used - except for sequences where recursion is allowed.
OSPL-635 10466 | Unable to determine adapter name in windows It was possible that when using windows OpenSplice is unable to determine the network adapter name. Solution: The defect in the name resolving mechanism is fixed according to the MSDN page solution and a proper adapter name is resolved.
OSPL-637 10466 | Handling loopback data in native networking When using shared memory with native networking the configuration will never 'see' a co-located single-process instance on the same node. Secondly data that loops back (i.e. 'own sent data') is detected in a sub-optimal way. Solution: The defect in native networking is solved and a new configuration item 'EnableMulticastLoopback' for native networking is introduced to optimize loopback data. EnableMulticastLoopback specifies whether the networking service will allow IP multicast packets within the node to be visible to all networking participants in the node, including itself. It must be TRUE for intra-node multicast communications, but if a node runs only a single OpenSplice networking service and does not host any other networking-capable programs, it may be set to FALSE for improved performance
9963/ dds3426 / OSPL-646 | DDSI2 used incorrect encoding for fragment data message headers DDSI2 incorrectly used to generate and interpret fragmented data message headers as if they were slightly extended versions of the non-fragmented data message headers. This caused DDSI2 to be non-compliant with respect to the standard and to fail to interoperate with other vendors' implementations for large samples. Solution: the setting and interpretation has been corrected. This breaks backwards compatibility, but because DDSI2 is still in beta, this does not constitute a change of policy. For those exceptional cases where backwards compatibility is currently an issue, a setting Unsupported/LegacyFragmentation has been introduced, which may be set to true to continue using and interpreting the old message format.
OSPL-780 | Incorrect handling of ioctl return code The return result from a call to ioctl should be interpreted as successful if the result is not equal to ERROR. The existing code uses result equal to zero as the criteria for success but positive non-zero values are also valid. Solution: The defect in the abstraction layer is now fixed and positive non-zero values values are now also valid.
OSPL-783 | IPv6 DontRoute emulation incorrect Due to lack of support for SO_DONTROUTE on some IPv6 stacks, networking tried to emulate the behaviour by setting the hop-count to 1. This is not functionally equivalent to SO_DONTROUTE. Solution: The emulation of the option has been removed. When set on an IPv6 configured networking service the option will be ignored.
OSPL-784 | Erroneous messages logging when sending initial ACKs if multiple AC messages were bundled in a single packet Erroneous messages were logged when multiple ACK messages were bundled into a single packet in the case of multiple partitons with Partition 1 only has a first ACK to be sent (no pending ACKs) and partition 2 has a first ACK and/or pending ACKs. Solution: The defect in the ACK logging mechanism has been fixed and now logs the correct messages.
OSPL-813 | Consistent final value not always guaranteed with BY_SOURCE_TIMESTAMP In the unusual scenario where a single writer updates an instance with the same timestamp, a consistent final value for that instance was not guaranteed across all subscribers. According to the DDS v1.2 spec this should be guaranteed in this case. Solution: When updating the administration of the readers the consistent final value is guaranteed by incorporating a writer-generated sequence number.
OSPL-821/ 10098 | DDSI2 socket receive buffer sizes are be too small to handle large packet bursts Large incoming packet bursts could overwhelm the configured buffer capacity of the network sockets in DDSI2 networking service. This was dependent on many factors, in particular also on scheduling latencies at the OS level. Solution: The default receive buffer size is now the minimum of the new Unsupported/MinimumSocketReceiveBufferSize option and the operating system default UDP socket buffer size. The default value of 64kB should suffice for most systems but can be increased where needed.
OSPL-827 | liveliness count issue with multiple partitions When using data readers accros multiple partitions the liveliness count increments for all writers instead of only the writers connected to the selected partition. Solution: The defect in the liveliness count algorithm is now fixed and now only the liveliness count for the writers in the selected partition are updated.

## 6.1.0g2

Report ID. | Description
--- | ---
dds3554 | e500v2 based builds need to include the VX_SPE_TASK option when spawning RTPs. Updated e500v2 based builds to include the VX_SPE_TASK option when spawning RTPs.

## 6.1.0g1

Report ID. | Description
--- | ---
dds3554 | PowerPC P2020 and PPC32 vxworks 6.8, linux hosted builds now supported. Added PowerPC P2020 and PPC32 vxworks 6.8, linux hosted builds.

## 6.1.0p8

Report ID. | Description
--- | ---
dds3508/ 10342 | spliced not running on LynxOS 5. Problems with spliced not executing correctly on LynxOS 5. Solution: Multiple fixes required, invalid makesystem options and some extra LynxOS posix support required.

## 6.1.0p7

Report ID. | Description
--- | ---
8840 / 9350 / dds2973 / dds2590 | Memory leaks during shutdown of native networking. During the shutdown of native networking not all administration structures are freed. Solution: The defect in the network termination algorithm is now fixed and all administration is correctly freed.
10065 / dds3306 | DDSI2 may erroneously decide CDR serialized data is invalid The DDSI2 deserializer attempts to avoid allocating memory for sequences of obviously bogus lengths by checking whether the remaining number of bytes is sufficient to encode some sequence of the declared length. Unfortunately, it uses the wrong notion of the size of an element, which can cause it to incorrectly declare a length to be bogus. This is dependent on platform, type and the type and contents of any data preceding the sequence. Solution: Always deserialize all data until the input is really exhausted.
10064 / dds3339 | Reliable communication fails with multiple connected RT networking services on one node The statically configured portnumbers collide with multiple instances, causing unicast data not to be received by all RT networking instances. For reliability related packets (ACK's, resends, etc.) unicast is used on a static port (data-port + 1), even when broad- or multicast is configured. This implies that multiple instances try to use the same IP-addres-portnumber combination, which is never possible. This causes only the latest bound RT networking service to receive all ACK's and resends for any instance on the same IP-address-portnumber combination, breaking reliable communication and causing a lot of warnings to be reported regarding unexpected ACK's, etc. Solution: RT networking uses a dynamically assigned portnumber instead of a statically configured portnumber for the reliability related packets.
10125 / dds3391 | OpenSplice DDS configured with multiple native network services and IgnoredPartitions configuration option set. In the case that OpenSplice is used with multiple native networking services and IgnoredPartitions is configurated. Writing multiple instances with a single dataWriter fails. The first instance will be written all further instances will not be written. Solution: The defect in the network administation algorithm in combination with ignored partitions is now fixed.
9963 / dds3426 dds3478 | DDSI2 used incorrect encoding for fragment data message headers DDSI2 incorrectly used to generate and interpret fragmented data message headers as if they were slightly extended versions of the non-fragmented data message headers. This caused DDSI2 to be non-compliant with respect to the standard and to fail to interoperate with other vendors' implementations for large samples. Solution: The setting and interpretation has been corrected. This breaks backwards compatibility. For those exceptional cases where backwards compatibility is currently an issue, a setting Unsupported/LegacyFragmentation has been introduced, which may be set to true to continue using and interpreting the old message format.

## 6.1.0p6

Report ID. | Description
--- | ---
9963 / dds3426 dds3478 | DDSI2 fragment size is now configurable DDSI2 never creates data messages containing a payload larger than the FragmentSize, any sample larger than the FragmentSize gets split into multiple fragments of FragmentSize each. These fragments are then transported independently (but may yet be merged into larger UDP datagrams). Solution: This size is now configurable using Unsupported/FragmentSize, with a default of 1280 bytes. Values below 1025 bytes violate the DDSI2 specification, above approximately 65000 bytes it (probably) won't fit inside a single UDP datagram. Increasing the size will shift more fragmenting and reassembling to the IP stack, which is generally more efficient because it is done inside the network stack, but which is incapable of retransmitting individual lost fragments. Increasing it may also allow operating without any fragmenting at the DDSI level, which may help avoid interoperability issues.
dds3486 | Third party licenses updates OpenSplice Tester third party tool licenses were not documented in release notes. Solution: Updated docs/html/third_party_licenses.html.

## 6.1.0p5

Report ID. | Description
--- | ---
dds3467/ 10259 | Signal handling failing on DENX. Signals were not being correctly handled for the DENX target Solution: Use the generic POSIX implementation.
dds3217/9881 dds3430 | Spliced shared memory leak on remote durability shutdown A memory leak was found whenever a remote node was started and then stopped while durability was also running. Solution: When durability detected a remote node, it would write an update into the system (and thus the shared memory on the local node). The logic for this write wrongly performed a double string creation for the same string. The second string creation overwrote the pointer to the first created string, which resulted in the first created string to be never freed when the remote node disconnected. The solution was to remove the first string creation, as it was superfluous.
dds3248/ 9908 | Partition expressions not matched properly. In case an application publishes/subscribes to multiple partitions and the list of partitions has names that are sub-strings of one of the others in the list, some partitions may be ignored. Even though communication within a node and communication over the network using the native networking service still works correctly, this issue causes communication over the network to fail when using the ddsi networking service and it also causes listeners not to be triggered on matched subscriptions and publications. Solution: The error in the pattern matching algorithm in the kernel has been repaired.
dds3399/ 10139 | Incorrect network statistics. The networking service optionally keeps track of statistics that can be inspected by means of the Tuner tool. After inspection it turned out that the maxNumberOfPacketsResentToOneNode and maxNumberOfBytesResentToOneNode statistics are showing wrong values. Solution: The maxNumberOfPacketsResentToOneNode and maxNumberOfBytesResentToOneNode statistics are now showing the correct values.
dds3416/ 10152 | Manual liveliness not working correctly Specific circumstances, such as a manual liveliness, could trigger a bug in the lease manager that would eventually cause the lease manager thread to hang indefinitely. The result is that periodic leases, such as the sending and receiving of heartbeats, is stopped. Solution: The lease manager was fixed.
dds3432/ 10187 | Applications SEGFAULT when the domain is not started. In the case no DDS domain is running but there is still a dirty shared memory segement present from an old instance of Spliced. It can happen that when an application is started, the application can crash with a SEGFAULT. Solution: The defect is fixed and the application will no longer crash because of this.
dds3455 | The durability service should improve the memory used during alignment. The durability service temporarily caches received alignment data until the set for a specific partition-topic combination is complete. The algorithm implemented there could be improved to reduce the amount of memory used during this phase. Solution: The durability service now stores unregistrations is a much more memory-efficient way reducing the memory overhead for alignment to a minimum.
dds3457/10241 dds3458/10242 | Crash of networking and/or durability during due to memory exhaustion. The networking and durability services could crash when the shared memory was exhausted. Solution: The services now check the available memory threshold and does not claim more memory when the threshold has been reached. Furthermore they will terminate when no more memory becomes available within a few seconds.

## 6.1.0p4

Report ID. | Description
--- | ---
dds3443/ | Added support for vxWorks 6.8.2 on MIPSI32R2sf There was no port for vxWorks 6.8.2 on mips. Solution: A build for vxworks 6.8.2 on MIPSI32R2sf has been added

## 6.1.0p3

Report ID. | Description
--- | ---
dds3217/ 9881 | Spliced shared memory leak on remote node shutdown When a remote node comes (e.g., ospl start is executed on a remote node) and then leaves (e.g., ospl stop is executed on a remote node) the system, a structural increase in shared memory is observed. Solution: A memory leak was fixed dealing with heartbeat message of the splice daemon being leaked. And a memory leak was fixed where durability history_kind was wrongly mixed with regular history depth instead of the value of the durability history depth.
dds3391/ 10125 | OpenSplice DDS configured with multiple native network services and IgnoredPartitions configuration option set In the case that OpenSplice is used with multiple native networking services and IgnoredPartitions is configured. Writing multiple instances with a single dataWriter fails. The first instance will be written all further instances will not be written. Solution: The network administration algorithm is now taking ignored partitions into account as well.

## 6.1.0p2

Report ID. | Description
--- | ---
dds3240 | Usability improvement for OpenSplice RMI The rmipp compilation requires a step to also compile its output with idlpp. There is no need for a user to inititate this. Solution: rmipp compilation now directly calls the idlpp step to remove unnecessary user action.
dds3299 | Added Support for IPv6 on vxworks 6.7 and 6.8 Added Support for IPv6 on vxworks 6.7 and 6.8, including workarounds for issues with vxworks inet_pton, and inet_ntop ( Windriver TSR#1085626 )

## 6.1.0p1

Report ID. | Description
--- | ---
dds3348 | Robustness of secure-networking service against malformed incoming packets The secure networking service should be robust against malformed incoming packets, but certain cases were (although detected) not handled correctly and could lead to a crash of the secure-networking service. Solution: Handling of malformed incoming packets has been fixed, so that they are correctly ignored.
dds3354/ 10083 | DBMSConnect - Bounded strings would get mapped by DbmsConnect to a VARCHAR column with width 6000 DBMSConnect ignored the length of a bounded string and treated it as an unbounded string, which is mapped to a SQL'99 VARCHAR column with a width of 6000. Solution: DBMSConnect uses the specified maximum length of a bounded string to determine the appropriate width of a column.
dds3363/ 10094 | Installation of the OpenSplice daemon as a Windows service from the Visual Studio 2010 distribution fails with an abort. Installation of the OpenSplice daemon as a Windows service from the Visual Studio 2010 distribution failed with an abort as the installer used an obsolete API. Solution: Installation of the OpenSplice daemon as a Windows service from the Visual Studio 2010 distribution no longer fails with an abort as the installer no longer uses an obsolete API.
dds3365/ 10098 | DDSI - Unnecessary packet drops for large "best-effort" messages (>8Kb) when using DDSI2 on windows platform. When receiving "best-effort" messages larger than 8kB via the DDSI2 service on the windows platform, a packetdrop-rate was observed that was higher than expected. This was caused by the UDP receivebuffer size on this platform, that defaults to just 8kB. Solution: An enhancement has been implemented that will set the UDP receivebuffer size to 64kB if the default value of a platform is lower than that. This will ensure that the UDP receivebuffers are big enough for the largest supported packetsize.
dds3366 | Shared Memory leaks in OpenSplice RMI In OpenSplice RMI, each request and each reply uses a different instance. These instances were not disposed and unregistered after the request/reply. The reply readers were not taking the samples that were destinated to other clients. These two problems were leading to a shm leak : shm memory consumption growing for each request/reply until the process ended. Solution: After writing the request/reply, the corresponding writer disposes and unregisters the corresponding instance. After taking it's reply, the reply reader takes all samples destinated to other clients.

## 6.1.0

Report ID. | Description
--- | ---
dds2723 | DataReader does not support the TIME_BASED_FILTER QoS policy The time-based filter QoS policy allows for pacing of a DataReader, based on a minimum separation time when receiving samples. Solution: The feature is now implemented and described in the OpenSpliceDDS Reference Manuals.
dds2784 | The DomainParticipant find_topic() function blocks for the full timeout period Where the topic of interest in the DomainParticipant find_topic() call did not exist, the find_topic method was blocking for the full timeout period even if the topic became available earlier. Solution: If no matching topic is found on find_topic() call, the function now checks for a matching topic every 10ms until a matching topic is found or the timeout is reached.
dds2846 | Issues with multiple domains on Windows A number of problems exist in the Windows abstraction layer that become noticeable if multiple domains are active and the default SHM mapping address is used. File locks are not released causing problems at shutdown and kernel objects (condition events, semaphores) are mixed up between the active domains. Solution: A number of improvements were made to ensure a correct operation of OpenSplice on Windows.
dds3003 | Cleanup problem in C++ PSM When an application is terminated while particular entities are still in use by the C++ PSM, these entities are not properly cleaned-up and freed. Depending on the context this could cause a crash or hang during shutdown. Solution: The cleanup routines of the affected entities were changed to take into account additional constraints to ensure a proper cleanup under all circumstances.
dds3023 | Crash in writer history cache management Under some circumstances the set of samples belonging to an instance in the writer history cache could become corrupted and cause a crash. Solution: The area of code was reviewed and improved to remove this problem.
dds3062 | Synchronization error while shutting down spliced A thread tried to access the spliced user-space object after it was destroyed. Solution: Spliced now waits until the thread has finished before destroying the spliced user-space object.
dds3125/ 9463 | Idlpp does not handle -I correctly and does not include the directory of where the IDL is located idlpp does not handle -I correctly when the paths end with a backslash. This typically happens in Visual Studio, because macros always end with a backslash. Also the include the directory of where the IDL is located is missing from the include path. Solution: Each last backslash from the include path is now removed and the include the directory of where the IDL is located is now added to the include path.
dds3142 | Durability crashed if no configuration was provided Because durability did not load the default values when a configuration (URI) was omitted on the commandline, the configuration was corrupt, which crashed the service. Solution: The service now also loads default settings when a configuration is not available.
dds3147/dds3189/ 9725 | DCPS C++ TypeSupportFactory object leakage The C++ TypeSupportFactory leaks in case its associated TypeSupport is registered with a DomainParticipant due to a missing decrease of the reference count of that object in the API itself when the DomainParticipant is deleted. Solution: The reference count of the object is now correctly decreased when a DomainParticipant, that has the type registered, is deleted.
dds3148/ 9726 | Maximum UDP payload size could not be configured DDSI2 used a default maximum payload size for the payload of UDP packets which could cause issues on networks that don't support fragmentation of UDP frames. Solution: A configuration option has been added that allows the maximum payload size to be configured. The DDSI2Service/Unsupported/MaxMessageSize element specifies the maximum size of the UDP payload ([def] 4096) that will be used by DDSI2. DDSI2 will maintain this limit within the bounds of the DDSI specification. This currently means that even though MaxMessageSize is set below 1192, messages with a payload of up to 1192 may still be observed.
dds3154/ 9756 | Heap memory leakage due to Java based query conditions. The copy routines for a sequence of strings for the DCPS Java API contained a memory leak due to the fact a release flag wasn't set to true. Solution: The release flag has been set to true.
dds3156/ 9753 | Reliablility problem in networking when running multiple nodes. When running real time networking and nodes are communicating over a reliable channel, it is possible that when a node is shutdown other nodes in the network start to lose communication with each other due to a corruption in the network administration. Solution: The defect in the network administation algorithm is now fixed.
dds3168/ 9771 | Destruction of ErrorInfo in C++ could cause crash. Due to a bug in the C++ language binding for the (unsupported) ErrorInfo API a crash could occur. Solution: The bug has been resolved, allowing proper destruction of ErrorInfo objects in the C++ language binding.
dds3221 | Using hostname as address of a NetworkPartition fails When a valid or invalid hostname is used as the address of a NetworkPartition of the network service, the error 'ignoring invalid networking address ' is reported and no communication takes place. Solution: The defect was in the hostname resolving algorithm and is now fixed.
dds3245 | Durability MMF store leaks unregistrations on injection of persistent data To make sure that instances are not registered by DataWriters that no longer exist (they cannot because the system has been restarted), the durability service will inject a self created unregister message for each unique DataWriter for an instance and that is proper behavior. However, the unregister message needs to be freed after it has been injected and that part is missing. This causes every unregister message on instance injection to leak. Solution: Unregister messages are now freed after re-publishing them.
dds3266 | Crash in signal handler due to uninitialized value During code analysis, a possible scenario was detected that could results in a crash in the signal handler if it's thread received a signal before a value was initialized. Solution: The code has been updated to avoid this possible scenario.

## Fixed Bugs and Changes affecting API / behaviour

## 6.8.3

| Description
--- | ---
OSPL-10922 | Implicit IsoCpp2 Participant, Publisher and Subscriber. A Participant has to be available before able to create a Topic for example. For many usecases, this is just a default Participant. The API would become simpler when a default Participant is assumed when no one was provided while creating the Topic. The same is applicable for Publishers/DataWriters and Subscribers/DataReaders. Solution: A default (singleton) Participant is created implicitly when dds::core::null is used when creating a Topic. An implicit Publisher is created when dds::core::null was provided when constructing a DataWriter (using the Participant of the given Topic). An implicit Subscriber is created when dds::core::null was provided when constructing a DataReader (using the Participant of the given Topic).
OSPL-10936 | Simplify creation of transient reliable DataReaders and DataWriters in IsoCpp2. To create transient reliable DataReaders and DataWriters you have to create the right QoSses with the proper policies and a transient reliable Topic. Many usecases need a simple transient reliable communication. By simplifying the creation of transient reliable Entities, these usecases can be simplified as well. Solution: The org::opensplice::topic::qos::TransientReliable() convenience function is added to IsoCpp2. Topics created with the resulting QoS will be transient reliable. DataReaders and DataWriters created using such a Topic are transient reliable as well automatically.

## 6.8.0

Report ID. | Description
--- | ---
OSPL-9914 | Removal of obsolete ISOCPP (version 1) from examples and documentation ISOCPP version 1 is deprecated and replaced by ISOCPP version 2. Examples and documentation were still present in OpenSplice causing new users to possible make the mistake to start using the wrong ISOCPP version. Solution: The ISOCPP version 1 examples and documentation are now removed forcing new users to use ISOCPP version 2.
OSPL-9763 / 17591 | IsoCpp2 memory leak when deleting DomainParticipants. A small listener object was not deleted when the related IsoCpp2 DomainParticipant was deleted. Solution: The deletion of the DomainParticipant and the related listener object and thread has been re-factored.
OSPL-9187 / 16857 OSPL-9221 | Potential memory leak for unaccessed group coherent subscribers In order to correctly deliver coherent sets to group coherent subscribers with late joining readers, the middleware maintained the transactions that weren't yet accessed. When accessing the subscriber, the transactions were flushed. This was possible because between begin- and end-access no readers can be added to a subscriber. This however introduced a requirement to access the subscriber periodically in order to be able to reclaim the memory. Solution: A restriction has been put on when datareaders can be created for a group-coherent subscriber. A group-coherent subscriber is always created disabled, regardless of the EntityFactory QoS on the domainparticipant. Readers can only be added to the subscriber for as long as it is not enabled. After the subscriber has been enabled by calling enable on it, mutations to the subscriber like adding a reader to it or changing the QoS (even ones that are normally mutable) on the subscriber or its readers are not allowed anymore. Readers can still be removed from the subscriber. If the subscriber is enabled, all its contained readers will be enabled too, regardless of the EntityFactory QoS of the subscriber. This change thus requires the addition of an explicit invocation of enable on the group coherent subscriber.

## 6.7.2

Report ID. | Description
--- | ---
OSPL-9654 / 17532 | Missing function prototypes on C APIs. When using the missing-prototypes compiler warning flag, the generated code for SAC, C99 and FACE will trigger that compile warning. Solution: Add prototypes just before the related generated function definitions.

## 6.7.0

Report ID. | Description
--- | ---
OSPL-6636 | Invalid return code of offered- and requested-deadline-missed get status operations in classic C++ language binding The DataWriter::get_offered_deadline_missed_status and DataReader::get_requested_deadline_missed_status return an error code if the total count is 0. The status output-parameter is still filled correctly. Because there's no last_instance_handle when no deadline is missed yet, the language-binding would incorrectly determine the instance handle is invalid causing the error retcode. Solution: The check was fixed to allow for this special case.
OSPL-6647 | Wrong status reset for on_data_available and on_data_on_readers When an on_data_available event is handled in the DCPS API, it should reset the data_available state before calling the listener. This is done, but it is done on the entity associated with the listener instead of the entity where the event originates from. This means for instance, that when a DomainParticipant receives an on_data_available event, it tries to reset the data_available state of itself instead of the related reader. The Subscriber has the same problem. In the DataReader, the entity is the source itself, so it isn't a problem there. The same happens when a on_data_on_readers event is received. But this has an additional problem that it resets the data_available status, while it should reset the on_data_on_readers status of the related subscriber. This problem exists on all DCPS language bindings. Solution: Fixed behaviour of on_data_available and on_data_on_readers to reset the status of the entity where the event originated. Also fixed on_data_on_readers so that it resets the correct on_data_on_readers status and not the on_data_available status. This was done for all API's.
OSPL-7343 | Topics can be created with invalid names. Topics can be created with invalid characters in their names. However, the subsequent creation of DataWriters or DataReaders will fail when using such a Topic that has an invalid name. A topic name can consist out of the following characters: ‘a’-‘z’, ‘A’-‘Z’, ‘0’-‘9’ and ‘_’, but it may not start with a digit. Solution: The Topic creation fails when a name with invalid characters is used.
OSPL-7560 / 15776 | When the TimeBasedFilterQos policy is used and the writer stops publishing after having published a series of samples, readers do not receive the latest state that was published after the minimum_separation delay has passed. The TimeBasedFilterQosPolicy can be used to control the rate at which readers receive samples. In particular, if there is a high frequency writer and receiving applications cannot keep up, then the TimeBasedFilterQosPolicy can be used to reduce the rate at which application readers receive the samples. In the previous implementation readers would not receive the latest state that was published in case the writer stops publishing after the minimum_separation delay has passed. Solution: Readers now receive the latest state that was published after the minimum_separation delay has passed if the instance has changed in the meanwhile and the reader's ReliabilityQosPolicy is set to RELIABLE.

## 6.6.4

Report ID. | Description
--- | ---
TSTTOOL-396 | Query condition support in Python Scripting Engine The Python scripting engine now supports query conditions.
TSTTOOL-397 | Status condition support in Python Scripting Engine The Python scripting engine now supports status conditions.

## 6.6.2p1

Report ID. | Description
--- | ---
OSPL-7688 | Query interface supports non-ISO compliant '!=' operator again. In a previous release the non-ISO compliant operator '!=' was removed from the supported SQL syntax. This was done in an effort to provide one common and standards compliant SQL parser for all the various services/languages in the product (where previously different components could use different parsers that supported different syntaxes). However, although the operator in question was non-ISO compliant and never advertised in our documentation, many users already used in in their applications. Solution: The '!=' operator has been added to the supported SQL syntax of our SQL parser.

## 6.6.2

Report ID. | Description
--- | ---
OSPL-7688 | Waiting for historical data with condition was not available for IsoCpp2. The proprietary function wait_for_historical_data_w_condition() was not implemented on the AnyDataReaderDelegate. Solution: The function wait_for_historical_data_w_condition() has been introduced on the AnyDataReaderDelegate.
OSPL-7872 | Java5 DDS API lack support for conditional wait_for_historical_data operation on DataReader Java5 DDS API lack support for conditional wait_for_historical_data operation on DataReader. Solution: The proprietary conditional waiting for historical data has been implemented and can be used by casting the DataReader to the OpenSplice-specific org.opensplice.dds.sub.DataReader and invoking waitForHistoricalData() method with the desired parameters.

## 6.6.0p3

Report ID. | Description
--- | ---
OSPL-7676 / 15818 | Several issues with new ISOCPP2 backend for idlpp. The new backend for ISOCPP2 was not working correctly for anonymous and inner types, and generated code had include dependencies on classes that were part of the classic IDL-C++ language mapping. Solution: Anonymous and inner types are now fully supported and all depencencies on the classic C++ language mapping have been removed.

## 6.6.0p1

Report ID. | Description
--- | ---
OSPL-7572 / 15788 | ISOCPP2 not using C++11 compliant idlpp backend. The C++11 Backend used by idlpp was not fully compliant with the new IDL-C++11 mapping as mandated by the OMG. Solution: A new C++11 backend has been provided for the isocpp2/isoc++2 target of idlpp that is truly complying with the OMG mandated IDL to C++11 language mapping. This results to a number of relevant and incompatible changes with respect to the previous C++11 backend: boolean in IDL now truly maps to the C++ bool type, so only "true" and "false" are now allowed. enum in IDL now behaves like the "enum class", which means the enums labels will be scoped with the type of the enum. The default (empty) constructor for structs and unions now initializes all attributes to valid values. (e.g. 0 for the primitive types, strings are empty, vectors are zero-length) For backward compatibility with the previous isocpp2 backend, a new flag is available on idlpp ("-o deprecated-c++11-mapping") that forces it to use the previous backend.

## 6.6.0

Report ID. | Description
--- | ---
OSPL-6024 / 14394 | DCPS Java5 API provides incorrect default LatencyBudget QosPolicy and DataWriterQos.reliability QosPolicy The DCPS Java5 API uses infinite LatencyBudget as default instead of zero duration and BEST_EFFORT reliability for DataWriterQos reliability instead of RELIABLE. Solution: Default LatencyBudget is now zero and default DataWriterQos reliability is now RELIABLE.
OSPL-7528 | WaitSet::wait() and the WaitSet::dispatch() behave different on time-out Make sure that both the WaitSet::wait() and the WaitSet::dispatch() behave identical, so let the WaitSet::wait() also throw a TimeoutException when the timeout occurs. Solution: WaitSet::dispatch() and WaitSet::wait() would differ in how they responded to a timeout: the first would throw a TimeoutError, the second would not. That behavior has been made more consistent now: the WaitSet::wait() also throws a TimeoutError when the indicated timeout elapses.

## 6.5.1

Report ID. | Description
--- | ---
OSPL-6024 / 14394 | Ignore outstanding loans when deleting entities A datareader keeps history about open loans. Open loans are memory given to the user by a take or a read action on a datareader and are not (yet) returned with a call to return_loan. A datareader cannot be deleted if there are open loans. The delete_datareader operation will return a RETCODE_PRECONDITION_NOT_MET returncode. There is a need to support deletion of a DataReader when open loans still exist though. Solution: To be able to ignore any open loans in case of a deletion of a datareader a new property "ignoreLoansOnDeletion" has been introduced on the datareader, with a default value false. If this property is set to true using the set_property operation, the datareader will ignore its open loans in case of a delete action. The value is interpreted as a boolean (i.e., value must be either 'true' or 'false') "false" (default). In case the property is set to false, the datareader will check for open loans in case of a delete action and will return PRECONDITION_NOT_MET in case of open loans. In case the property is set to "true", the datareader will ignore open loans and can be deleted in such a situation. This new property is only available on classic Java and C++ API's, both standalone and in CORBA-cohabitation mode.
OSPL-6342 | Support for dynamic network partitions for RTNetworking The RTNetworking service needs to support for changing network partitions dynamically at run-time. Solution:This feature allows users to amend the configuration of the RTNetworking service at runtime by means of a Topic-API.
OSPL-7021 | The behavior of the dispose_all operation is different from the behavior of the dispose operation for reader on the same federation. The dispose_all operation is performed asynchronously. This may cause that readers on the same federation my still read alive samples after the execution of the dispose_all operation. With this respect the dispose_all operation behaves differently from that of the dispose operation. The dispose operation has immediate effect for readers on the same federation. Solution: For readers on the same federation the dispose_all operation is performed synchronously. The state of the readers connected ot the same federation is updated during the dispose_all operation.
OSPL-7027 / 14930 | 100% CPU Usage network service when resending locally rejected samples When a local datareader uses resource limits and runs into these resource limits, the networking service may go to 100% load when attempting to re-deliver a sample that is rejected due to the fact that the maximum resource limits have been reached. Solution: The networking service now reschedules the delivery of a sample to a datareader for the next resolution tick instead of attempting the re-deliver in a busy-wait loop until it is delivered.

## 6.5.0p5

Report ID. | Description
--- | ---
OSPL-6034 / 14399 | Adding support to timed out asyncronous calls in OpenSpliceRMI-Java OpenSpliceRMI waits for asynchronous calls replies infinitely by default. The setTimeout operation on the service proxy does not apply on asynchronous calls. So there is no way to control the time OpenSpliceRMI should wait for asynchronous replies. Solution:Henceforth, synchronous and asynchronous calls are waited for during the same default duration whose value is 10 min. A new method has been added to the base asynchronous reply handler defined as "public void handleException(org.opensplice.DDS_RMI.SystemException exp)" to notify the user of timeout expiration (TIMEOUT exception) or of any other error occurred during the asynchronous reply delivery. The user reply handler should override this method to handle the errors. Asynchronous replies timeout could be set either with the CRuntime object, or with the proxy class, or with the reply handler class using the "setRepliesTimeout" method. The existing setTimeout() operation on the proxy class has been deprecated and replaced by setRepliesTimeout(). A new command line option called "--RMIClientSchedulingModel =" has been added to allow the user to set a priority to all the threads created at the client side including the thread that waits for the asynchronous replies. Please, refer to the OpenSpliceRMI documentation for more details. In order to benefit from these new features, the user should regenerate the rmipp code. Note that this asynchronous requests timeout support is currently available in Java only. The C++ support will be implemented in a future release.

## 6.5.0

Report ID. | Description
--- | ---
OSPL-5899-1 | Listener and waitset trigger order In the previous releases before V6.5 listeners and waitsets where triggered in random order but the specification prescribes that listeners are triggered before waitsets. Solution: In V6.5 we have partly corrected the behavior, as it now behaves deterministic in the following order: trigger the waitsets containing affected read and query condition. invoke the listeners. trigger waitsets containing affected status conditions. In a future release we will correct the order of the first two items, as they should be in reverse order. Important remark for existing applications: Previously if a listener is set on a status condition of an entity and the same status condition is attached to a waitset then both the listener would be invoked and the waitset would return the status condition. In V6.5 the waitset will no longer return the status condition. The listener will reset the status condition before the waitset is triggered implying that the waitset will not return the status condition because it no longer evaluates true. Additionally, if an application has not set a listener but accidentally has set the listener mask, the waitset will no longer return the status condtion. It appears that only a waitset is used on a status condition but in reality a default listener is set which will reset the status condition before the waitset is triggered.
OSPL-5899-2 | Listener mask behaviour change According to the DDS specification setting a listener mask for specific events without implementing a listener for those events (i.e. specifying a 'NULL listener') will act as if a listener is set and as a result will consume the events and not propagate events to listeners of its parents or waitsets. Before V6.5 setting a mask had no effect when not implementing a listener meaning that events where not consumed so parent listeners and waitsets where still triggered. Solution: The issue is fixed, but applications must be aware that if the mask was set by accident, they might be missing events they have received before if listeners are set on parent entities or associated conditions are used in waitsets.

## 6.4.1

Report ID. | Description
--- | ---
OSPL-4630/ 12963 | get_all_data_disposed_topic_status() method is now implemented Solution: The get_all_data_disposed_topic_status() method has been implemented in C++ and Java language bindings.

## 6.3.1p2

Report ID. | Description
--- | ---
OSPL-2733 | Change in QoS settings of Streams API The QoS settings of the internal DataWriters of the Streams API allowed potentially unlimited memory usage, because the resource limits were not set. Solution: The internal resource-limit QoS settings of a StreamDataWriter have been set to max_samples = 10, to prevent potential unlimited memory usage.

## 6.3.0

Report ID. | Description
--- | ---
OSPL-505/OSPL-704 | OSPL_EXIT_CODEs are not useful in a shell. When using ospl two return values OSPL_EXIT_CODE_RECOVERABLE_ERROR (-1) and OSPL_EXIT_CODE_UNRECOVERABLE_ERROR (-2) are indistinguishable in a shell. Solution: The return codes are now postive +1 and +2
OSPL-1078/ 10788 | Support for parallel demarshalling should be available on Java an C++ Demarshalling data to a language-binding specific format may take considerable processing depending on the type of the data. Since demarshalling is done by the application thread performing the read/take, demarshalling occurs single-threadedly, limiting the throughput that can be achieved. Solution: The C++ and Java datareaders have been extended with support for demarshalling with multiple threads. The number of threads used can be controlled by using the new set_property(DDS::Property) operation on C++ and Java datareaders. The property "parallelReadThreadCount" accepts a string representing a positive integer (e.g., "4") as value. If the call was successful, successive read/take operations on that datareader will use the provided number of threads for the demarshalling step of the respective operations.
                      dr.set_property(new Property("parallelReadThreadCount", "4"));
OSPL-1194 | Record and Replay: Removal of mode attribute The 'mode' attribute of RnR XML storages has been removed because it was not clear how this setting should be used in different circumstances with new and/or existing storages. Solution: The default behaviour is now to always append to a storage, when its resources (i.e. XML files) exist. If the resources do not exist they will be silently created, if possible. The overwrite-behaviour that was achieved by setting the mode to 'w', has been replaced by a separate TRUNCATE command. This command will remove all data from a storage, but it can only be processed if the storage is not open for recording and/or replaying.
OSPL-1348 | Record and Replay: Removal of interest Solution: The RnR command API has been modified to allow removal of individual record/replay interest instead of forcibly removing all interest by stopping the scenario responsible for adding it. The API contains separate commands to either add or remove interest to record or replay data belonging to a specific partition/topic. For example, to stop recording data, a REMOVE_RECORD command must be issued, containing interest expressions that match exactly the expressions of the ADD_RECORD command that initiated the recording. Currently all interest will still be forcibly removed when a STOP_SCENARIO command is published but future releases will only allow interest to be removed by publishing remove commands.
OSPL-1640 | Default for ospl changed Inexperienced users finding ospl hard to use as the default isn't friendly. Solution: ospl used to stop by default. It now displays the usage.
OSPL-1790 | Added missing functions to DataReaderView in the Standalone C++ language binding Applications built on the Corba C++ language binding couldn't be built on the Standalone C++ language binding due to missing functions in the DataReaderView. `
                virtual ReadCondition_ptr create_readcondition (SampleStateMask sample_states,
    ViewStateMask view_states, InstanceStateMask instance_states) = 0;
    virtual QueryCondition_ptr create_querycondition (SampleStateMask sample_states,
    ViewStateMask view_states, InstanceStateMask instance_states,
    const DDS::Char* query_expression, const StringSeq& query_parameters) = 0;
    virtual ReturnCode_t delete_readcondition (ReadCondition_ptr a_condition) = 0;
    virtual ReturnCode_t delete_contained_entities () = 0;
` Solution: The DataReaderView in the Standalone C++ language binding is extended with the missing functions.
OSPL-2019 | Function calls on deleted entities in ccpp and sacpp now correctly return already_deleted Calling functions on deleted entities in ccpp and sacpp returned BAD_PARAMETER instead of ALREADY_DELETED. Solution: Code fixed to match OMG specification.

## 6.2.0

Report ID. | Description
--- | ---
OSPL-347/ 8919 | Changes in Corba Co-habitation Java PSM Solution: In previous releases only a subset of the OpenSplice API was generated using a Corba ORB. Starting from this release, the entire Corba-Java API is generated by the IDL compiler that comes with the ORB. This enables customers to use internal types like ReturnCode_t and InstanceHandle_t in a Corba environment, i.e. Helper and Holder classes are now available for those types as well. Because all classes are now properly implementing Corba interfaces and inheriting from Corba base classes, derived classes are required to provide an implementation for all abstract operations mentioned in the generated interface. In case of Listeners, OpenSplice supplies the ListenerBase class as a convenience. When Listeners extend from this base class they are no longer required to implement these operations themselves. See detailed notes in 6.2 features section above
OSPL-1160 | DDS_Service::register_interface C++ operation signature change The DDS_Service::register_interface C++ operation accepts a raw pointer to the service implementation as parameter, whereas its implementation assigns it to a smart pointer. This situation can lead to a double free problem. Solution: The register_interface current signature is deprecated : `template bool register_interface(T2 * svc_impl, const std::string & svc_name, int svc_instance_id)` and adding a new one : `template bool register_interface(shared_ptr svc_impl, const std::string & svc_name, int svc_instance_id)` that accepts a smart pointer to the service implementation as paramter in stead of a raw one.

## 6.1.0p7

Report ID. | Description
--- | ---
9963 / dds3426 dds3478 | DDSI2 used incorrect encoding for fragment data message headers DDSI2 incorrectly used to generate and interpret fragmented data message headers as if they were slightly extended versions of the non-fragmented data message headers. This caused DDSI2 to be non-compliant with respect to the standard and to fail to interoperate with other vendors' implementations for large samples. Solution: The setting and interpretation has been corrected. This breaks backwards compatibility. For those exceptional cases where backwards compatibility is currently an issue, a setting Unsupported/LegacyFragmentation has been introduced, which may be set to true to continue using and interpreting the old message format.

## 6.1.0

Report ID. | Description
--- | ---
dds751 | Change in ReaderLifecycle QoS (invalid sample setting) The QoS setting that determines if OpenSplice creates invalid samples to communicate state changes, called 'enable_invalid_samples', is now deprecated. Invalid samples, in the past, could either be enabled or disabled. There is a replacement QoS setting, called 'invalid_sample_visibility', which accepts three values: - MINIMUM_INVALID_SAMPLES: Acts like the old enable_invalid_samples = true, an invalid sample will be created if there's no regular sample on which the state change can be piggy-backed (this is the default behavior). - NO_INVALID_SAMPLES: Acts like the old enable_invalid_samples = false, no invalid samples are created. - ALL_INVALID_SAMPLES: Currently not implemented, but in the future will create an invalid samples for all state changes even if a regular sample is available. Using the QoS deprecated setting will cause a message to be logged to the info log. This QoS will be removed from the product in the future. If applicable it is recommended to switch application code to the new invalid_sample_visibility setting instead. Solution: The default DataWriter reliability QoS is now set to RELIABLE in OpenSplice's API.
dds2676 | Default DataWriter reliability QoS is set to BEST_EFFORT OpenSplice default DataWriter reliability QoS was set to BEST_EFFORT. This was conflicting with the spec which states that default DataWriter reliability QoS should be RELIABLE. Solution: The default DataWriter reliability QoS is now set to RELIABLE in OpenSplice's API.
dds2806 | Domain ID change from string to integer The DDS API prescribes a create_participant() method to create a DomainParticipant. A DomainParticipant is the entry-point for an application to a specific Domain. To be able to create a DomainParticipant for a specific Domain, the create_participant() call requires a DomainId_t as parameter. In the specification the type of this DomainId_t is 'native' meaning that every vendor is free to choose its own type. In OpenSpliceDDS the type of a DomainId_t was a string and represented either the name of the Domain or a URI that points to the location of the configuration for the Domain to connect too. This has now become an integer domain ID. With this change OpenSpliceDDS now complies with other vendors on the DomainId_t type and the DDS interoperability specification (DDS-I) can use it now to select the port-number for discovery for a specific Domain. Solution: The feature is now implemented and described in the OpenSpliceDDS Reference Manuals.
dds3061 | DDSI v1 removed from the codebase The deprecated DDSIv1 code is now officially removed from the source code base and product APIs. DDSI2 should be used. Solution: The feature is now implemented and described in the OpenSpliceDDS Reference Manuals.