This page lists all the fixed bugs and changes in the Vortex OpenSplice 6.9.x releases.
Regular releases of Vortex OpenSplice contain fixed bugs, changes to supported platforms and new features are made available on a regular basis.
There are two types of release, major releases and minor releases. Upgrading Vortex OpenSplice contains more information about the differences between these releases and the impact of upgrading. We advise customers to move to the most recent release in order to take advantage of these changes. This page details all the fixed bugs and changes between different Vortex OpenSplice releases. There is also a page which details the new features that are the different Vortex OpenSplice releases.
There are two different types of changes. Bug fixes and changes that do not affect the API and bug fixes and changes that may affect the API. These are documented in separate tables.
Vortex OpenSplice 6.9.1
Fixed bugs and changes not affecting the API in Vortex OpenSplice 6.9.1
|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.
Vortex OpenSplice 6.9.0
Fixed Bugs and Changes not affecting API in Vortex OpenSplice 6.9.0
|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
|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.