This page lists all the fixed bugs and changes in the OpenSplice 6.10.x releases.
Regular releases of 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 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 OpenSplice releases. There is also a page which details the new features that are the different 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.
Fixed Bugs and Changes in OpenSplice v6.10.x
OpenSplice v6.10.4p2
| Report ID. | Description |
|---|---|
| OSPL-13694 / 00020679 | Incorrect behavior on the members of 'dds_sample_info' bus of Simulink Vortex DDS Reader block. The 'dds_sample_info_t' array on the Vortex DDS Reader block for Simulink was not initialized properly. Therefore, on the generated code from a Simulink model, the members of the ' dds_sample_info' bus were incorrectly assigned to a value when there was no data available. Solution: The bug is now fixed. The 'dds_sample_info_t' array of the Vortex DDS Reader block is now initialized correctly. |
| OSPL-13707 | The function wait_for_historical_data may fail for reliable transient-local topic. When ddsi has received all the history data from a transient_local writer it will set the associated dds readers complete which signals the wait_for_historical_data. In a particular situation when there are several readers for the same transient_local topic created and the transient_local writer sends a GAP message which makes the history of one of these readers complete it may occur that the corresponding dds reader is not notified that it has become complete causing the wait_for_historical_data function to time out. When handling the GAP message the sequence number contained in the GAP message is used to evaluate if all history data has been received. However it should use the next expected sequence number which is associated with the reader history. Solution: When a ddsi transient_local reader receives a GAP message and the history cache associated with that reader is updated the next expected sequence number is used to determine if all the history data has been received. |
OpenSplice v6.10.4p1
| Report ID. | Description |
|---|---|
| OSPL-13503 / 00020504 | Python API cleanup error on condition delete For Python API applications, error reports saying "Bad parameter Not a proper condition" in the context of "dds_condition_delete" were getting logged in the ospl-error.log file during the termination of the applications. Solution: The bug is fixed and the error will not occur anymore. |
| OSPL-13672 / 00020656 | RnR unable to record all historical data A regression issue caused a problem in the RnR service when recording historical transient or persistent data. The issue would result in no historical data at all or only an incomplete set getting recorded Solution: The bug was fixed and a regression test-case extended to catch the issue if it occurs again in the same or similar circumstances |
| OSPL-13259 / 00020193 | A race condition in the waitset implementation may cause an OpenSplice daemon to crash. In the implementation of the waitset there is a condition in which the waitset data structure is not properly protected. This may cause that the waitset trigger and the waitset wait may access the waitset data structure concurrently causing the crash. Solution: Access to the waitset data structure is protected in all code paths to allow waitset to be thread-safe. |
| OSPL-13333 / 00020275 | When running out-of-resources the networking service may crash when using compression. When compression is enabled in the networking service will compress several messages in one larger compressed message. The received compressed message is decompressed and placed in a buffer before deserializing the contained messages into shared memory. When during deserialization of a message an out-of-resources condition occurs because there is not enough shared memory available anymore this error condition is not properly handled causing an incorrect memory access to occur. If deserialization fails, the pointer used to scroll over the messages in the decompression buffer will not be correctly set to the next message in the buffer. Solution: When the deserialization of a received message fails the pointer used to scroll over the messages contained in the decompression buffer is correctly set to the next message. Further when the deserialization of the message fails because of an out-of-resources condition a fatal error is raised which terminates the networking service. |
| OSPL-13504 / 00020506 | Segfault on exit when using Python API When using OpenSplice Python API in the applications, in some cases it was possible that a Segmentation Fault could occur during the termination of the applications. It was happening when the Python API was trying to free the allocated memory for the condition. Solution: The problem is now fixed. |
| OSPL-13549 / 00020536 | Memory leak in queried take There exist several memory leaks at places where original terms in a query are replaced with their disjuncted counterparts. In those places, the original term then leaks away. Solution: Modifications have been made to properly clean up these original terms. |
| OSPL-13561 / 00020546 | When SyncMessageExchange is enabled in the RT networking service it may occur that reliable communication does not start correctly. The send part of a reliable networking channel detects a remote node it has to put the packets that the remote node is expecting on a pending resent list which is used to resent packets that are not acknowledged by the other node. However the remote node may have already received an packet with a earlier sequence number which is acknowledged. When the SyncMessageExchange option is enabled it may occur that the pending resent list is already populated with packets to resent but when the first acknowledgement indicates an earlier sequence number it could occur that the packets the remote node is expecting are not put on the resent list causing the other node to wait for the missing packets. Solution: When receiving an acknowledgement contains a sequence number that was before the first sequence number contains in the resent list for that node then populate the resent list with the missing packets which are still available. |
| OSPL-13574 / 00020557 | Simulink Vortex DDS Block Set did not support "Rapid Accelerator" mode simulation. In previous Vortex OpenSplice releases, the Simulink Vortex DDS Block Set did not support "Rapid Accelerator" mode simulation. Solution: The Simulink Vortex DDS Block Set now supports "Rapid Accelerator" mode simulation. |
| OSPL-13579 / 00020534 | Python bug fix for the serialization problem for some structs when using dynamically generated Python classes. Previously, in the Python DDS API, the packing format for some structs was generated incorrectly when using dynamically generated Python classes. This problem did not affect Python classes generated by IDLPP. Solution: The bug is now fixed. |
| OSPL-13598 | In the durability service change and add trace messages to level fine. To improve analysis of durability trace files when the log level was set to fine a number of trace message which are logged at a higher level have to be enabled at level fine. Solution: A number of trace message have be enabled at level fine. Further some extra trace message are added to improve the analysis of the durability trace file. |
| OSPL-13610 | Matlab read, take, query-based read and query-based take functions return identical values from the Reader's cache. While reading N samples ( N >1 ) from Reader's cache the Matlab functions read, take, query-based read and query-based take were processing the data vector incorrectly and returning only the first entry from Reader's cache. Therefore, the output samples were identical after reading samples from Reader's cache. Solution: The Matlab read, take, query-based read and query-based take functions have been updated to return all entries from Reader's cache. |
| OSPL-13614 | The durability service fails to detect a master conflict when this occurs during the initial phase. When the durability starts it first determines a master for each configured namespace and then it identifies the topic-partitions that are locally known before it starts the initial alignment. When during this phase a master conflict occurs, e.g. another node has selected another master, then it false to trigger a master conflict which will redo the master selection to have a single master in the system for each namespace. Solution: Enable the detection of a master conflict after having selected a master. |
| OSPL-13621 / 00020601 | A reconnect may cause that the durability service incorrectly aligns implicitly disposed samples. When a node detects that another node has become disconnected the corresponding instances written by writers on the disconnected node are implicitly unregistered. When the associated writer QoS has autodispose_unregister_instances enabled then the implicit unregister also causes an implicit dispose of these instances. Note that these implicit generate message are related to the local discovery view of the node and should not be aligned between systems. These implicit messages will be purged from the transient store after the service_cleanup_delay expires. However when the durability service is performing an alignment the purging of the transient store is suppressed until the durability service declares the transient store complete again. When a reconnect occurs the durability service may perform an alignment which incorrectly may contain these implicit dispose messages. Solution: When collection alignment data from the transient store implicit messages are filtered out. |
| OSPL-13622 / 00020602 | Tuner: In certain uses cases, adding a query to a reader has no effect on incoming samples. A reader can be created with an optional query. A user would expect that if a query is defined, the query would be used when reading data. However, in certain cases, the query is not applied to incoming samples. Solution: Workaround: The read or take using a query is supported, ONLY IF you access the reader query from the Participant view. In the Participant view, you can see the reader, and underneath, the query for the reader. The query must be used to read data instead of the parent reader, in order for the query to be applied. Note: This feature in the participant view was broken in 2016 with the implementation of type evolutions (OSPL-7242). It has been fixed as a part of this ticket. |
| OSPL-13632 | Isocpp2 backend of idlpp represents true/false literals for boolean in capitals When using a boolean literal in your IDL to represent the value for a constant variable, the ISOCPP2 language backend will illegally represent these literals in uppercase (like it is done for classic C/C++, where an IDL boolean is actually mapped to an unsigned char), but for ISOCPP2 it will be mapped to C++ type bool, that can only hold the C++ keywords "true" and "false". Solution: The boolean IDL literals are now represented in lowercase for the ISOCPP2 target. |
| OSPL-13635 | When the durability service uses legacy master selection then a master conflict may not be resolved when a fellow disconnects before resolving the conflict. In case the durability service uses legacy master selection and when a master conflict is detected then the current master of the namespace is directly marked pending to prevent a duplicate master conflict to be raised. However when the fellow that caused the master conflict is disconnected before resolving the master conflict the master conflict may be discarded. as not relevant anymore. However this may cause that the master conflict still exists with other fellows which were detected but ignored because the master was directly set to pending. Solution: When detecting a master conflict in a namespace the master of the namespace is not directly set to pending. The master is set to pending at the moment new master selection is performed. |
| OSPL-13641 / 00020630 | Potential mis-alignment in C# union may cause data corruption In some cases, the database representation of a union in C# might suffer from mis-alignment, caused by an incorrect Packing instruction that was generated by idlpp as part of this C# database representation. This mis-alignment might cause data corruption for OpenSplice services and other applications. Solution: The incorrect Packing instruction is removed. |
| OSPL-13668 / 00020651 | Python DCPS API: When explicitly assigning an empty list to a sequence in Python, the message read will fail. When explicitly assigning an empty list to a sequence in Python, the message read fails. As a result, to clear a sequence, the whole message needs to be cleared and refilled with data. Solution: Fixed. A check is now made in _deserialize_seq to ensure that there is no exception thrown when reading a message with an empty sequence. |
| OSPL-13669 | Low priority durability master selected when using master priority selection. When the durability service is configured to use priority master selection than the instance with the highest priority should become the master. However depending on the order in which the priority of the fellows is evaluated it could occur that an instance with a lower priority is selected as master which could cause that master selection is not consistent between the durability instances. Solution: When determining the fellow with the highest priority and walking over the known fellows keep a temporal reference to the possible fellow with the highest priority. |
| OSPL-13218 | Better support for multi-user Windows environments Some features of OpenSplice process-management are not supported on Windows when multiple user-accounts are involved in running OpenSplice services and applications in shared-memory mode. Solution: Instead of refusing applications to connect to shared-memory, the process-management features can now be disabled through configuration options. For more information see Deployment Guide, section 13.2.11.3 shmMonitor, regarding registerCallback and registerProcess settings. |
| OSPL-13631 / 00020608 | Unnecessary information was removed from service log. Service log file size was increasing quickly. Solution: Unnecessary topic type (MetaData) information has been removed from New-BuiltinTopic log record to filter unnecessary data and reduce log size. |
OpenSplice v6.10.4
| Report ID. | Description |
|---|---|
| OSPL-13488 / 00020481 | The IDL feature of using file hierarchy supported by 'idlpp -I' option was not implemented in Simulink. The IDL feature of using file hierarchy supported by 'idlpp -I' option was not implemented in the IDL import function of the Simulink Vortex DDS block plugin. Solution: The 'idlpp -I' feature is now implemented in Simulink. A new function 'idlImportSlWithIncludePath' has been added to the Simulink Vortex DDS block plugin to support the IDL feature of using file hierarchy. In this function, the positional argument 'INCLUDEDIRPATHS' can be used to pass a cell array with the values of the include paths for IDL files. |
| OSPL-13501 / 00020505 | Network bridge does not operate correctly when bridging native RT networking services only. The networking bridge subscribes to the builtin topics to learn the topology of the network. It waits for subscription match status for the corresponding readers. This is to assure that the ddsi service which contains writers for the builtin topics are available. However when only native RT networking services are present this does not work because the native RT networking services do not have writers for the builtin topics. Solution: When only native RT networking services are being bridged then the check on the subscription match status of the builtin topic readers is not performed. |
| OSPL-13377 / 00020342 | An exception is thrown when handling events such as requested_deadline_missed While handling events such as requested_deadline_missed if the handle of the entity than caused the event to be triggered becomes invalid an exception will be thrown Solution: Update the handling of events to return an error case in case that the handle of the entity that triggered the event becomes invalid instead of throwing an exception |
| OSPL-13400 / 00020352 | Incompatibility issue between Python API and C++ API when using KEEP_ALL history QoS policy Python API (C99 API) and C++ API use different values for depth when using KEEP_ALL QoS policy therefor an error occurs when comparing the QoS policies used in both API's Solution: Do not compare the depth values when using KEEP_ALL QoS policy in all API's |
| OSPL-13470 | Potential memory leak in deallocation of sequence buffer for C/C99 The C/C99 representation of your IDL model suffers from a memory leak in the following case: 1, You have an attribute that is a typedef to a sequence. 2. The element type of this sequence contains an indirection (i.e. directly or indirectly holds a string or another sequence). The problem is that the deallocator for the sequence buffer, as it is currently generated by idlpp, is missing a deallocator for the indirection(s) in the individual elements, which therefore leak away. Solution: A proper deallocator function for each individual sequence element is now correctly generated and invoked by the deallocator of the sequence. |
| OSPL-13484 / 00020479 | Durability master selection may fail when a potential namespace master is started and delayed alignment is used. When delayed alignment is enabled for a namespace and a node has selected a master for a that namespace and another node is started or restarted which is also a potential master for that namespace it could trigger a new master selection for that namespace even if the original master has already published data. Timing issues could cause that the newly triggered master selection fails to find a new master. This may occur when the newly started node has not reached the correct state when master selection is performed. Solution: The durability service should update the quality of a namespace when receiving the namespace information from the master node. This prevents that master selection is restarted when delayed alignment is used and there is already data published. Further delayed alignment should only trigger a new master selection when then the potential new master has reached to correct state. |
| OSPL-13493 / 00020486 | Potential data loss during alignment when using the REPLACE merge policiy. A bug was discovered in an algorithm responsible for the conversion of WallClock time to Elapsed Time in the durability service, that could result the disappearance of data in some nodes that are being aligned using the REPLACE merge policy. Basically the conversion error might represent a time that was x seconds in the past as being x seconds in the future. Given an arbitrary time t, if during the window [ t-x, t+x ] data is received through the live path, this live data might be purged as part of the old data set that is to be replaced by data set that is received as part of the merge. Solution: The conversion error has been corrected now. |
| OSPL-13500 / 00020502 | When then RT networking service is restarted communication may not be restored. When the RT networking service is configured with the restart failure action then when the networking service is restarted because the occurrence of an exception then it may occur that the communication is not restored. This can occur when the fellow networking services do not detect this because the restart is within the configured death detection time. Solution: When the networking service is restarted the restart is delayed for a short duration which is more than the configured death detection time to let the fellow networking service to detect the restart. |
| OSPL-13505 | Stalling alignment due to not answering a d_nameSpacesRequest When durability services discover each other they need to exchange capabilities and namespaces. The rule of the game is that a durability service can only send namespaces to another durability service when a capability of the remote durability service has been discovered, and when a request for namespaces has been received. Different threads are involved in processing the capability and the request for namespaces. There was a race condition between these these thread such that when a request for namespaces was received just prior to the capability, it could be the happen that no namespaces where send. This lead to stalled alignment. Solution: The race condition has been removed by properly locking the code section that was causing the race condition. |
| OSPL-13506 | AlwaysUsePeeraddrForUnicast DDSI option conflicts with Vortex Link Fault Tolerance When OpenSplice has set to true, it was ignoring the locators received in SEDP. This behavior was obstructing the Vortex Link to work properly in Fault Tolerance and Load Balancing configuration so that OpenSplice clients were not capturing the fallback Vortex Link service. Solution: AlwaysUsePeeraddrForUnicast implementation is now only controlling SPDP messages and the control for SEDP messages has been reverted. |
| OSPL-13512 | CopyIn/CopyOut function generated for IDL typedefs are not properly exported The copyIn/CopyOut functions for typedefs as generated by idlpp for the C/C++ targets are missing the import/export macro needed to invoke those operations from the context of another library/executable. This may lead to issues on Windows platforms if one IDL file is using a typedef from another IDL file, whereas the code generated for the latter IDL file is not contained in the same library/executable as the first IDL file. Solution: CopyIn/CopyOut functions for typedefs are now properly exported, |
| OSPL-13514 | shmdump cannot handle dump files bigger than 4.2GB When using shmdump to dump the contents of your shared memory to a file, you run into a number of issues: * You must manually specify the size of your shared memory as a mandatory command-line parameter to shmdump , which is cumbersome and not needed since the size can already be obtained from other sources. * The variable holding the size is only 32-bit, and therefore overflows when the shared memory size is > 4.2GB. Solution: Specifying the shared memory size is no longer mandatory, although still optional. Also the shared memory size is now stored in a variable type that corresponds to the platform width. |
| OSPL-13516 / 00020513 | Possible crash when creating shared subscribers or DataReaders simultaneously When two or more processes create a shared DataReader or subscriber, only the first succeeds and others slave to it. In specific circumstances the slaves could return a partially initialized entity resulting in undefined behaviour and/or a crash when the entity is used. Solution: The issue is resolved by adding a synchronization mechanism so a shared DataReader or subscriber is only returned when fully initialized. Note shared DataReaders and subscribers are a properietary DDS extension applicable in shared-memory deployment only and enabled by setting the Share QoS policy on a Subscriber and DataReaders. |
| OSPL-13530 / 00020525 | The RT Networking service could run out of fragmentation buffers when the backlog of several nodes grows. The RT Networking service is normally configured with a maximum number of fragmentation buffers. Fragmentation buffer are used to store the received network packets. When the maximum number of fragmentation buffers is exceeded a fatal error is raised and the Networking service terminates. A reliable channel maintains for each remote node a backlog of fragments which cannot be delivered because there are fragments missing. When the backlog of a certain node exceeds the configured threshold the backlog of that node is cleared and the node is temporally disconnected to inform the system that messages of that node have been missed. However it may occur that several nodes have a growing backlog and the maximum number of fragmentation buffers is exceeded before the backlog of one of these nodes is exceeded causing the Networking service to terminate. Solution: When the number of used fragmentation buffers reaches the configured maximum then select the remote node which has the largest backlog and clear that backlog to free fragmentation buffers. This node is marked temporally disconnected to notify that reliable communication with that node has been disrupted which will trigger the durability service to perform a possible realignment of the missing messages. |
| OSPL-13580 / 00020360 | Exception in Java FACE API caused by invalid unlock after incoming data callback When an exception occurs while handling incoming samples using the FACE callback mechanism, eg. a DataReader becoming invalid because the domain was terminated, a lock is always released even if the exception is raised before the lock is taken. Solution: Exception handling was modified to properly lock/unlock in all circumstances. |
| OSPL-13203 | Visual Studio 2019 requires MATLAB version R2019b as a minimum Visual Studio 2019 is not supported by MATLAB versions prior to R2019b so previous versions of OpenSplice with VS2019 have not included MATLAB. Solution: Builds of OpenSplice with Visual Studio 2019 now include MATLAB and require version R2019b as a minimum. |
OpenSplice v6.10.3p2
| Report ID. | Description |
|---|---|
| OSPL-11049 / 00018425 | Unicast messages not received by networking service when using multicast on windows When the networking service is used on windows and the networking is configured to use multicast then the sockets which are used of sending are incorrectly bound to the same port number as being used by the sockets used for receiving messages. This may cause that unicast message (ACKs and resends) are not received by the networking service on windows. Solution: The sockets used for sending are bound to port number 0. By using port number 0 the socket will be bound to a random port. |
| OSPL-13355 / 00020324 | For the secure networking service the SyncMessageExchange option does not work correctly. The sync messages exchanged when the SyncMessageExchange option is set are not encrypted. The receiver tries to decrypt these messages which causes that these messages are dropped. Because the sync message is never acknowledged the sender will not purge the resend list causing the networking service to run out of memory. Solution: When secure networking is used the sync messages are encrypted. |
| OSPL-13368 / 00020337 | Simulink Model Validation errors with GOTO blocks and Subsystems When a Vortex DDS block entity port (e.g. domain participant or topic) was connected to either a GOTO block or a port on a subsystem, the DDS block would report an error during validation. Solution: Validation of entity port connections has been relaxed to allow connections to blocks such as GOTO and Subsystems. No changes are required to existing blocks or models. |
| OSPL-13392 | When the SyncMessageExchange is enabled it could occur that after a reconnect the communication does not restarts. When the SyncMessageExchange is enabled in RT networking service a sync message is sent when a reconnect occurs. When the receiver receives the sync message it starts waiting on a message with sequence number communicated through the sync message send by the sender. However it could occur that an old acknowledge message is received at the sender which incorrectly causes the sender to drop the message that the receiver is waiting for. Solution: After a receiving a sync message which resets the communication with a sending node the receiver should not send acknowledge messages for received messages older than the sequence number indicated by the sync message. Further at the sending side the message acknowledges and the acknowledge of the sync message should go through the same queue to ensure in order delivery. |
| OSPL-13416 / 00020384 | Closing sockets after SSL failure TCP Socket was left open after SSL connection failure such as using an expired or revoked certificates. DDSI tries to connect the TCP peer as long as application/federation stays running and consumes all socket resources of the operating system. Solution: TCP socket is closed after receiving an error during the SSL connection attempt. |
| OSPL-13423 / 00020393 | Merge policy "REPLACE" might not revive an aligned instance correctly Upon a reconnect to a durability master, the merge policy "REPLACE" will first dispose the current data-set, and then re-insert the aligned data set, meaning that all instances contained in the latter set that have not been explicitly disposed or unregistered by their owner should end up in the ALIVE state again. However, a bug in the instance state machine caused the aligned sample to be dropped if the user would take the initial DISPOSE from the start of the "REPLACE" policy, prior to the insertion of the aligned sample. Since the initial DISPOSE and the insertion of the aligned sample did not occur atomically, there was a slight chance that the user would consume the DISPOSE prior to the insertion of the aligned sample. Solution: The "REPLACE" merge policy has not been modified in such a way that the insertion of the initial DISPOSE message and the insertion of the aligned sample happen atomically. Because of that, the user is not able to consume the DISPOSE prior to the insertion of the aligned message. |
| OSPL-13426 | Durability fails to get complete when master becomes disconnected when resolving initial conflict. When the durability service starts it first has to determine a master for each of the namespaces to determine which of the present durability services is allowed to inject the persistent data. After selecting a master all the present durability services are asked for their topic/partition information. However when the master disconnects and no topic/partition information has been received from the master the durability services fails to become complete. Solution: When during initial the selected master becomes disconnect the master selection is restarted. |
| OSPL-13427 / 00020396 | Python API memory Leak on Waitset's wait function. In the wait function of the Waitset class, memory was allocated for _c_conditions to get all the triggered conditions attached to the waitset. It was never freed causing a memory leak on waitset wait. Solution: The memory leak has been fixed. |
| OSPL-13474 / 00020421 | The handling of the DCPSPublication and DCPSSubscription builtin topics cause a memory leak. The spliced daemon maintains a list of the samples of the DCPSPublication and DCPSSubscription builtin topics to perform some cleanup action when corresponding instances become not-alive. However the reference count of these samples may incorrect become increased when updating these lists causing a memory leak. Solution: When trying to insert an outdated sample which is rejected the reference count of the rejected sample is not incremented. |
| OSPL-11116 | DDSI ability to ignore advertised addresses and/or use peer/source address A problem can occurs when the advertised addresses of Link/Fog causes DDSI2 to disconnect and then try to reconnect to the wrong address. Solution: A new option TCP/AlwaysUsePeeraddrForUnicast is added that can be used to ignore an advertised unicast address. |
OpenSplice v6.10.3p1
| Report ID. | Description |
|---|---|
| OSPL-13235 / 00020125 | Modified type generation for FACE C++ binding in idlpp The C++ FACE binding is built on top of our isocpp2 DCPS binding. Therefore types generated from IDL follow the IDL to C++11 specification. This doesn't match FACE specification which expects the classic IDL to C++ (03) specification. Solution: idlpp was modified to apply the classic C++ type mapping when generating code for FACE. Instead of accessing members using getters/setters as usual in isocpp2, members can now be accessed directly. Note the FACE binding itself is still built on top of isocpp2 therefore both include/dcps/C++/SACPP and isocpp2 directories must be added to the include path when compiling the generated code. |
| OSPL-12629 | In case alignment data is requested from multiple nodes, alignment may stall when a node leaves during alignment In order to determine whether an alignment action has completed, the number of expected samples is calculated from the number of samples that are aligned from each node, compensated for possible duplicates (because different nodes can send the "same" data, so this should result in a single expected sample). When a node leaves before the alignment has completed, the number of expected samples must be compensated too. There is a flaw in the algorithm to compensate the number of expected samples when a node leaves. This may lead to an incorrect number of expected samples, potentially causing alignment not finishing. Solution: The algorithm to calculate the number of expected samples has been corrected. |
| OSPL-13100 / 00019942 | The networking service may crash when receiving message for an unknown network partition. When the networking service receives a packet which does not relate to a networking partition known by the node is still tries to process the packet with an invalid partition reference which may cause that the networking service crashes. Solution: When a packet is received which does not relate to a known network partition the packet is ignored and an warning is logged. |
| OSPL-13183 / 00020091 | Unintended instance revival during re-alignment due to premature purging of readerInstances. Consider the following scenario: 1. Node A writes a sample S1 for Instance I1. 2. Node B takes the sample. 3. Node A and Node B disconnect. 4. Node A and Node B re-connect. 5. Node B sends a re-alignment request to node A. 6. Node A creates a snapshot of its state (including sample S1 for instance I1) 7. Node A now disposes + unregisters instance I1 prior to sending out the snapshot it just created. 8. Node B receives and takes the dispose + unregister, and consequently purges instance I1 from its reader cache. 9. Node B now receives the snapshot from node A, and subsequently creates a new instance I1 in its Reader cache for holding S1. 10. I1 is effectively revived, breaking the eventual consistency of the system. Solution: By not purging the reader instance immediately after it was disposed/unregistered and left empty by the take operation, but by delaying the purge time til after the injection of the snapshot, we can avoid instance I1 from being revived because the now conserved history record of the instance will indicate the S1 has already been consumed. The instance purge delay will be derived from the sum of the following two parameters: the configured RetentionPeriod (in ms) of the Domain section in your config file, and the configured service_cleanup_delay of its topic's DurabilityServiceQosPolicy. This gives you the possibility to define a global minimum offset and a topic specific addition. |
| OSPL-13197 / 00019796 | The networking synchronization option sometimes fails to synchronize to nodes after a asymmetrical reconnect. A synchronization option was added to the networking service configuration to provide better recovery after an asymmetrical reconnect. However it could occur that the synchronization failed because an old ack message could purge the resend queue incorrectly. Solution: When the synchronization option is enabled the networking service will not purge the resend queue for a particular node when not having received an acknowledge of the synchronization message. |
| OSPL-13211 / 00020101 | The autopurge_dispose_all setting my cause that the reader instance is incorrectly purged when applying a REPLACE merge. In the situation that a durability performs a REPLACE merge alignment and the reader has the autopurge_dispose_all QoS policy enabled then the reader instance will incorrectly be purged and the sample injected as result of the REPLACE alignment will be rejected. A REPLACE merge action will first dispose the reader instance before injected the alignment sample. The dispose is misinterpreted as resulting from a dispose_all operation causing the purge. Solution: The flags of the dispose indicate that it is caused by a REPLACE merge action. The autopurge_dispose_all implementation checks the flags to determine if the dispose resulted from a dispose_all operation or not. |
| OSPL-13255 / 00020103 | Java WaitSet timeout influenced by non-triggering QueryConditions. A QueryCondition can be attached to a WaitSet. Then it is possible to wait for a sample that is accepted by the QueryCondition. A timeout can be added to that WaitSet wait. When a sample is received that is not accepted by the QueryCondition, the internal WaitSet wait is called with the original timeout, causing the wait duration to increase. Solution: When a sample is received that is not accepted by the QueryCondition, the timeout is re-calculated before calling the internal WaitSet wait again. |
| OSPL-13283 / 00020201 | Potential memory leak in generic copy functions for SAC and C99 Copy routines are used to copy samples from your language representation into the shared memory database representation and vice-versa. They are normally generated by idlpp and dedicated to the data types specified in your IDL file. However, for SAC and C99 it is also possible to use generic copy functions, that are not dependent on compile-time availability of your datatypes but that perform the copying based on run-time availability of your sample's metadata. This is useful for applications that have no compile time knowledge about the datatypes they will work with, and that have to discover their topic's metadata at runtime. An example of the use of a generic copy function can be the Python language binding, which is built on top of the C99 API, and which allows you to introspect an arbitrary Python sample (without having to pre-model it in IDL and then compile a dedicated copy function) and write it into DDS or read it out of DDS. The problem with this generic copy function was that is was suffering from a pretty serious memory leak for samples that contained a sequence of type struct (either a struct with subsequent references or a struct without subsequent references). Solution: The memory leaks have been fixed. |
| OSPL-13300 | The CM* builtin topics are not logged when builtin topic logging is enabled. When processing the received CM* builtin topics the log function incorrectly discards these topics. Solution: The builtin topic logging function accepts all received builtin topics and logs them to the log file. |
| OSPL-13314 / 00020254 | Registering a typesupport using the generic type of the classic C API may cause a crash in a multi domain context. The classic C API provides functions to use generic types. When a generic TypeDescriptor is registered with a DomainParticipant it will generate information to copy-in/out the corresponding topic data. This information contains a reference to the type descriptor which is stored in the associated database. However when multi domains are used and the same TypeSupport is registered with different domains the second domain will use the copy-in/out information generated for the first domain. This will cause a crash when writing a topic. Solution: When registering a generic TypeDescriptor with a domain it is checked if it was already registered with a other domain and when that is the case generate the copy-in/out information again for the current domain. |
| OSPL-13325 / 00020264 | C# backend of idlpp may generate invalid demarshaling code for IDL unions with no contained references The C# backend for idlpp generates demarshaling instructions that cause C# compilation errors for an IDL union with no contained reference types (i.e. it contains no strings or sequences, neither directly nor indirectly) but with one or more branches that hold a struct or union. Solution: The C# backend has been modified to generate the correct demarshaling code |
| OSPL-13336 / 00020277 | Networking bridge service does not forward topics When using the networking bridge service user topics did not get forwarded to the other network service when DDSI is used as network service. Solution: The defect in the DDSI service is solved and user topics are forwarded again. |
| OSPL-13338 / 00020274 | The spliced daemon may crash when a reconnect of a remote system is detected. When the spliced daemon receives a heartbeat from a previously disconnected remote instance it updates the DCPSPublication instances associated with that remote system. However these DCPSPublication instances may contain invalid data causing the crash. Note that the update of the DCPSPublication instances is not necessary because they are already updated by the durability service in case of the use of RTNetworking and or by the ddsi service. Solution: When a remote system heartbeat is received by the spliced daemon it updates the information about the alive systems which is used to determine if data that is aligned through the durability service is alive or not. The update of the DCPSPublication is performed either by the alignment of the builtin topics through the durability service or by the ddsi service as result of the discovery process. |
| OSPL-13342 | Simulink Reader Block did not produce valid Sample Info during simulations During simulations, the Simulink Reader block's 'info' port did not produce meaningful output. Code generated with Simulink Coder does not suffer from this problem. This problem was introduced with OpenSplice 6.8.3. Solution: The Reader block has been corrected to provide correct sample information on the 'info' port. |
| OSPL-13351 | When UseSyncExchange is enabled it may cause synchronization between the sender and receiver fails The UseSyncExchange option should enable that the synchronization on the first packet by both the receiver and the sender is improved to minimize unnecessary packet loss. The sender selects the first packet either based on the first acknowledge from the receiver or from the first packet send after detecting the receiver. However the receiver may already have received an older packet for which the acknowledge has not yet been received by the sender. The synchronization message sent to the receiver includes a lower bound for the sequence numbers that the receive may accept and are available for resending by the sender. This lower bound is set to restrictive which causes that packet the receiver is waiting for are rejected. Solution: The lower bound of synchronization message is set to what is available for resending. |
| OSPL-13352 | An overload situation at the networking receive channel may cause that acknowledges are not sent in time. To prevent packet loss in the receive socket the networking service tries to read the receives sockets with priority. When the socket contains a high number of packets reading all these packet may stall the the sending of acknowledges This may cause that other nodes remove this node from the reliable protocol because acknowledges are not received in time. Solution: The maximum number of bytes read from a socket each iteration is limited to enable the networking receive channel to handle sending of acknowledges and delivering received messages to the applications in time. |
| OSPL-13354 / 00020323 | Linker may detect missing symbols for idlpp generated C/C99 code. When using an anonymous sequence or sequence in your IDL data model, the generated C/C99 output may cause linker issues because of missing symbols. The culprits are functions that provide the allocation semantics for these sequences, and they usually come with the following naming scheme: __sequence_. In principle, according to the official IDL-C language mapping you should not invoke these functions directly but instead rely on the DDS_sequence___alloc() and DDS_sequence__allocbuf() instead. Since those are already located in your DDS API, we skip them in the generated data model to avoid duplicate symbols during linking. That said, if you would for example create an anonymous sequence of a type not provided by the DDS API (for example a sequence), then the IDL compiler would generate the allocators in your generated data model. However, this could still result in duplicate symbols during linking if I would have two independent IDL files both using an anonymous sequence, and then linking the generated objects together into one library/executable. To avoid those kinds of problems, from OpenSplice version 6.10.2p3 onwards we reversed this process: the names of the actual allocator functions are now always context specific (e.g. __sequence_), and the official allocator function your applications are supposed to use (e.g. DDS_sequence_short__alloc()) is now a macro pointing to one of these implementation functions. If you now link the objects of two separate IDL files together, their actual allocation functions no longer have name clashes, and the DDS_sequence_short__alloc() macro will only be set if not set before, and point to the first occurence of such an allocation function. So although the actual sequence allocation implementation functions use the naming scheme __sequence_, these are only provided to avoid name clashes during linking, and your application should use DDS_sequence_ allocator functions instead. Nevertheless, it was a bug that for sequence and sequence the context dependent allocation function was announced in the header file but not implemented in the .c file. For people who prefer to use the context dependent allocation function over the official allocation macro, this would result in a linker error. Solution: We now also generate the context dependent allocation implementation, so that even people that like to use those in their applications (although this is not according to the IDL-C language mapping) will no longer run into linker errors. due to missing symbols. |
| OSPL-13360 | Potentially stalling alignment when many nodes are discovered simultaneously When durability services discover each other, the durability protocol starts by exchanging namespaces. This is done by sending a so-called nameSpacesRequest message from one durability service to another. The other durability service then responds with sending its namespaces. In situations where many nodes are discovered more or less at the same time and there are many namespaces to exchange, it is possible to end up in a state where one node is waiting for namespaces of the other node, but the other node is asymmetrically disconnected and never the receives the request for namespaces. Because exchanging namespaces is a precondition for alignment, failing to kickstart can cause alignment to fail. Solution: A mechanism has been implemented to resend a nameSpacesRequest when it is detected that a remote node has experienced an asymmetric disconnect. As an additional safety measures a nameSpacesRequest is resend if it takes too long to answer. The default value is set to 30.0 seconds, but this value can be overridden by setting the environment variable OSPL_DURABILITY_MAX_PERIOD_WAIT_FELLOW_NS. When set to 0.0 the retry mechanism is disabled. |
| OSPL-13361 / 00020179 | Tester created default readers unable to read historical data samples. The default volatile readers created by the Tester were unable to receive historical data samples written from the transient durability writers. Solution: A new boolean property ?scriptDefaultReaderWait? is added to the "tester.properties" file. The default value of this property is "false". Setting it to ?true? will make the Tester default reader created by the script to wait for the historical data samples. This solution is for scripts only and would not affect the UI reader creation. |
| OSPL-13366 / 00020336 | Memory leak in listener events not yet processed when application terminates Listener events can leak shared-memory in v_readerStatus event-data under specific circumstances where the application is terminated before queued events can be processed by the listener event thread. Solution: An internal change involving proper ref-counting of event-data ensures the relevant memory is free'd in all circumstances. |
| OSPL-13369 | Durability may find no aligner for a namespace when using legacy master selection. The initial master selection may find no aligner in case of legacy master selection when during the initial master selection the namespaces from possible aligners are not yet received. It will decide just after two iteration over the received namespaces that it could not find an aligner for the namespace and continues without selecting an aligner. Solution: The durability service will wait for an aligner to become available during the initial alignment phase. |
| OSPL-13388 | The spliced daemon may crash when receiving invalid heartbeat messages. When processing received heartbeat messages the spliced daemon accesses the corresponding instance to determine the instance state of the received heartbeat sample. When the corresponding reader only contains invalid messages the read operation may remove the instance. Solution: When reading heartbeat samples also the corresponding instance is kept alive during the processing of the heartbeat sample. |
OpenSplice v6.10.3
| Report ID. | Description |
|---|---|
| OSPL-7334 | When two nodes become disconnected and reconnect again, the DELETE merge policy deletes the data set even when nothing has changed. When nodes become disconnected and reconnect again the configured merge policy is applied. If the merge policy is DELETE then the data set will be deleted. This is undesired when there is no difference between the data sets of the nodes involved. Solution: The DELETE merge policy will only be applied when there is a change in data sets between the nodes. NOTE: this change in behavior is currently only implemented when the equalityCheck is configured. Without the equalityCheck there is no difference. |
| OSPL-12768 / 00019538 | Alignment may stall when a new local group is created while a merge request to acquire the data via a merge for the same group is ongoing. When a durability service learns about a partition/topic combination, it may have to acquire data for this group by sending a request for samples to its master. When at the same time a merge conflict with the fellow is being handled, this may also lead to the sending of a request for samples to the same fellow. Both paths are for performance reasons decoupled, and so there is a window of opportunity that may lead to two identical requests for the same data to the same fellow. Since the requests are identical only one of them is answered. The remaining one never gets answered, with may potentially stalls conflict resolution. Solution: The requests are distinguished so that they are never identical |
| OSPL-12862 / 00019625 | Alignment may stall when a new local group is created while a merge request to acquire the data via a merge for the same group is being scheduled When a durability service learns about a partition/topic combination, it may have to acquire data for this group by sending a request for samples to its master. When at the same time a merge conflict with the fellow is being handled, this may also lead to the sending of a request for samples to the same fellow. Both paths are for performance reasons decoupled, and so there is a window of opportunity that may lead to two identical requests for the same data to the same fellow. Since the requests are identical only one of them is answered. The remaining one never gets answered, with may potentially stalls conflict resolution. Solution: The requests are distinguished so that they are never identical |
| OSPL-13101 | Premature alignment that can potentially lead to incomplete alignment When nodes states have temporarily diverged and they get reconnected again, their states must be merged according to the configured merge policy. Typically, this leads to requests for data from one node (say A) to the other (say B), and the other nodes sends the data. Before these requests for data are send, node A node first retrieves which partition topic combinations (so called groups) exist on B, so that it can ask for data for these groups. To do that the requesting node A first sends a request for groups to B, and B replies by sending all its groups in newGroup messages, one by one. Each message contains an indicator that indicates how many groups there are, so A knows how many groups to expect before requests for data can be send out for each group. When node B creates a new group, this also leads to the publication of a newGroup message which is received by all durability services. This message has an indicator that the number of expected groups is 0. If a new group is created while groups are being exchanged, then it can happen that the number of expected groups is reset to 0, causing the durability service on A to prematurely think that all groups have been received, and so node A starts requesting data from B without having acquired all groups. Because A sends requests for data for all groups that it currently knows, node A will only acquire data for a subset of the group that B knows. Solution: When a new group is created the number of expected groups are not reset to 0 any more. |
| OSPL-13106 | Bug fix for segmentation fault when writing union data idlpp used to generate incorrect code for serializing structs containing unions. We have fixed this problem. Solution: We serialize structs (Python objects) by copying them into a buffer with a packing format. Previously, the packing format for structs containing unions was generated incorrectly. We have fixed this problem by adding a custom calculation for the packing format of unions inside structs. |
| OSPL-13133 / 00020000 | The tuner and tester incorrectly removes spaces from string values. The tuner and tester use the CM api. Topic data which contains string or character values may be handled incorrectly by the tuner or the tester because the CM api removes leading and trailing spaces incorrectly from string values. Solution: When processing string values the CM api leading and trailing spaces are not removed. |
| OSPL-13205 | Deficiency in deserialization of dds security message fixed Deserialization for string types was producing one character memory violation sometimes. This situation might cause unexpected behaviour when the character after the string buffer is not null. Solution: A fix applied to limit the memory access within limits. |
| OSPL-13228 / 00020129 | FACE Read_Callback interfaces are now compliant with CTS requirements The Read_Callback interfaces generated by the idlpp backend for the FACE were not compliant with the requirements as set out by the latest FACE CTS. Solution: The Read_Callback interfaces are now generated using the correct names. For example for a type named Type1, the interface was named Type1Read_Callback, but now according to the new CTS requirements it is called Read_Callback_FACE_DM_Type1. |
| OSPL-13239 | Application crash on query condition read or take. Read /Take on a query condition that implements a like expression on a string type key can result in a segmentation violation when an instance is unregistered or disposed. An internal memory optimization removes key fields from unregister and dispose messages so the query should therefore not address these fields, however due to another string key optimization this does occur and results in an segmentation violation. Solution: added an additional internal test to detect this use-case and take a different approach and avoid addressing these fields. |
| OSPL-13247 | OpenSplice installer causes Windows to reboot When Visual C++ Redistributable for Visual Studio 20XX is not installed and the OpenSplice installer triggers the installation a Windows reboot can occur causing the installation to fail. Solution: The Visual C++ Redistributable for Visual Studio 20XX will be installed without triggering a system reboot. |
| OSPL-13252 | When a node requests groups from another node, the answer is send to all nodes instead of the requestor only As part of aligning data sets between nodes, information about the available groups (i.e., partition/topic combinations) must be exchanged between the nodes. This is done by having one node sent a request for groups to another node, and the other node sends back the groups that is has. Instead of addressing the groups to the requesting node, the other nodes sends back the groups to everybody. This may cause unnecessary processing by nodes that have not requested the groups. Solution: When a node sends a request to another node, the answer is directed to the requesting node only |
OpenSplice v6.10.2p4
| Report ID | Description |
|---|---|
| OSPL-13212 | The networking bridge service does not work correctly in combination with the networking service. The problem is that the publication and subscription match statuses are not correctly updated. The cause is that the alive status of a system is used in when aligning the DCPSPublication topic. Because the alive status of a node at the other side of the bridge is not passed on the corresponding builtin topics will not be inserted as alive when they are aligned by the durability services. This causes that the publication and subscription match statuses are not updated. Solution: Builtin topics received through alignment make the corresponding instance alive which causes that publication and subscription match statuses are correctly updated. |
OpenSplice v6.10.2p3
| Report ID. | Description |
|---|---|
| OSPL-13188 / 00020092 | In the isocpp2 api the SampleInfo equal operator behaves incorrectly. When comparing two SampleInfo values for equality the value of the instance state attribute is not compared correctly. Solution: When comparing two SampleInfo values for equality the instance state attributes are included in the comparison. |
| OSPL-11802 / 00018828 | Anonymous sequences represented in C or C99 may result in duplicate symbols during linking When using the same anonymous sequence in multiple IDL files, linker errors might appear when linking the object files representing the C or C99 representation of these IDL files together due to duplicate symbols. The collisions are caused by the allocator functions generated for the anonymous sequences, which are bear the same name. Solution: The allocator functions generated for anonymous sequences are now always scoped by a unique context, i.e. the struct/union containing the the anonymous sequence or the typedef that references it. This way name collisions are avoided. The original function names are still available as conditional macro's pointing to these scoped allocator functions. If you pull in more than one implementation for an anonymous sequence, only one macro definition will be available, pointing to only one of the scoped functions (which should all be interchangeable). |
| OSPL-12800 | Implemented ^C handling for OpenSplice applications on Windows Until now OpenSplice did not implement a Windows console termination handler for applications and this required applications to install their own termination handler and safely disconnect from the DDS Domain. However the OpernSplice Service could become corrupted in case an application performed an exit in their termination handler leaving the shared memory in an unstable state. Solution: OpenSplice now implements a console termination handler which will safely disconnect from the Domain and then pass the event to any other termination handler. If applications had set their own termination handler it will be called after being disconnected so an exit will no longer leave the shared memory in an unstable state. Any OpenSplice calls performed by the application or application handler however can receive an 'already deleted' error code / exception because the domain was disconnected and should process it. |
| OSPL-12887 | The generic read/write functions provided by the SAC and C99 API do not support recursive types. The generic read and write functions provide by the SAC and C99 APIs use the type information to copy the topic data. When the topic type definition contains recursion then these generic read and write function may crash depending of the kind of recursion that is used. The problem is caused because the size of the recursive type is calculated incorrectly causing misalignment of the members of a struct or a union. Solution: The size of a type that is used recursive is calculate first to enable the correct calculation of the alignment. |
| OSPL-12899 / 00019745 | Missing files for Simulink Vortex DDS blockset library validate ports feature. A new feature for validating ports introduced a bug that threw exceptions when using the Simulink Vortex DDS blockset library. The exceptions were caused by missing files in the blockset library. Solution: Missing files added into Simulink Vortex DDS blockset library. |
| OSPL-13023 / 00019800 | OpenSplice - OpenDDS authentication handshake problem was fixed for DDS Security interoperability. OpenDDS was not accepting some of the OpenSplice authentication handshake messages. As handshake is the initial step for communication, it was impossible to interoperate with OpenDDS. Solution: A field in the handshake message was fixed, and permissions file parsing behaviour was updated to handle non-given partition to be evaluated as default partition. Current interoperability with OpenDDS is as follows: * Communication only works when Discovery protection kind is ENCRYPT. Protection can be still enabled/disabled for each topic (enable_discovery_protection) in the governance file. * SIGN protection kind is not working for any case * RTPS protection is not supported in OpenDDS * Metadata protection and data protection work with ENCRYPT protection kind. Only one protection can be used at a time. |
| OSPL-13048 / 00019919 | The error and warning messages that include topic names are removed from log files for discovery protected topics. The local permission errors are written as messages in the error log and the remote permission errors are written as messages in the info log. However, topic names can be seen on the logs which can be non-secure for discovery protected topics. Solution: Permission errors are not logged for the following situations: * creation of local topic, datareader and datawriter * match of remote topic, datareader and datawriter |
| OSPL-13074 / 00019944 | Durability may crash when handing an asymmetrical disconnect. When an asymmetrical disconnect is detected by durability it will clear the namespace administration associated with the fellow that is considered disconnected. However there may still be a merge action in progress that is associated with that fellow and which tries to access the deleted namespace object. Solution: When using the namespace object it's reference count is incremented to ensure it can be accessed safely. OSPL-13080 / 00019948 DDS Security decoding payload may fail when the payload contains only a key. |
| OSPL-13094 / 00019955 | Networking service may crash when using synchronous write. To support the synchronous write functionality a special builtin reader is used. This builtin reader is a specialized reader which has different attributes as the normal application data readers. When the networking service reports a sample lost event then a crash may occur when the sample lost event is reported on this special builtin reader. Solution: Sample lost events are only reported on normal data readers. |
| OSPL-13112 / 00019983 | The RT Networking may crash when a short disconnect occurs. When networking receives messages it will first put these messages in a queue before processing them further. For a reliable channel the message read from this queue are put in the out-of-order administration which is related to the sending node. When networking considers a sending node as not responding it will clear the administration related to that sending node. When reconnect is enabled and networking receives again messages from that node it will resume reliable communication and considers that node alive again. Reliable communication is resumed from the first message it receives again from that node. However when the disconnect is very short there may still be old message from that node present in the internal queue which causes problems when they are put into the out-of-order administration related to that sending node. Solution: The out-of-order administration rejects message that are considered old. |
| OSPL-13116 | Durability may leak some memory when configured with delayed alignment When delayed alignment is configured alignment requests may leak when there is a previous request which is still waiting to be processed and the new request is ignored as a duplicate. Solution: Free the memory of an alignment request when it is considered a duplicate. |
| OSPL-13118 / 00019991 | DDS Applications unresponsive for termination signals. Application signal handlers for SIGQUIT, SIGPIPE, SIGINT, SIGTERM and SIGHUP are no longer executed after implementing a fix for internal DDS service zombie processes caused by user sent kill signals. The problem was caused by a signal mask that prevented passing the signal to the application handlers. In addition the default OpenSplice termination handler was called when an application handler was set which is unintentionally and could prohibit applications to divert termination requests. And that for window applications any application defined nor the default CntrHandlers where not invoked after executing the OpenSplice CntrHandler. Solution: The Signal mask is lifted during the re-raise of the signal so that it is forwarded to application handlers. No OpenSplice termination handler is set when the application has set a termination handler. In Windows application OpenSplice no longer consumes the console event so that the event is passed to other CntrHandlers. |
| OSPL-13124 / 00019998 | termination handler. In Windows application OpenSplice no longer consumes the console event so that the event is passed to other CntrHandlers. OSPL-13124 / 00019998 Fixed some typo's and clarified information in deployment manual and configurator. Some typos have been caught in the Deployment manual and some clarifications were suggested, especially with respect to the notation of ranges. Solution: The typos have been fixed and a more mathematical notation has been used to indicate valid ranges for the parameters in both the Deployment manual and the Configurator. |
| OSPL-13125 | Transient_local instances which are disposed may not be removed when there are no writers. All durable topics (TRANSIENT, TRANSIENT_LOCAL and PERSISTENT) instances are maintained in a local storage. Instances which are disposed and have no writer will be purged from this storage taking into account the service_cleanup_delay. This storage can be in the complete or incomplete state. When the durability service is performing an alignment then the storage is set in the incomplete state and when in the incomplete state the storage is not purged to ensure proper alignment to take place. However when the configuration is using the durability service in combination with the ddsi service the alignment of transient_local is a task of the ddsi service and the durability service will not take responsibility for the storage containing the transient_local instances. This causes that this storage remains in the incomplete state and purge of the storage is suppressed. Note that when the RT networking service is configured the durability service will take responsibility to align the transient_local topics. Solution: When the durability service is not responsible for the alignment of the transient_local topics then the purge suppression of the transient_local storage is disabled. Further transient_local instances which have no writers will also be purged from the local storage to prevent late-joining readers to receive transient_local data when there is no writer of that data. - Since there is one combined storage for all Writers we cannot handle scenarios where Readers expect all samples from all Writers (e.g. Reader = KEEP_ALL or reader has history_depth > 1). - Neither can we handle scenarios where Readers selectively pick samples from a variety of sources (e.g. because of ContentFiltering on the Reader side, or because of differences in RxO QosPolicy settings.) - When Readers use BY_RECEPTION_TIME ordering, they might receive some samples again when a late joining Reader is created on the same federation. - The combination of a non-TRANSIENT_LOCAL topic with a TRANSIENT_LOCAL reader/writer will also not work as might be expected with respect to determining completeness of the data set. |
| OSPL-13174 | When detecting a disconnect of an node the corresponding instance may not be unregistered. When the spliced daemon detects that a node has become disconnected it should unregister all instances written by that node. For this purpose information present in the corresponding DCPSPublication builtin topics is used. Note that in this situation an alive and a disposed sample of the DCPSPublication are present. Instead of using the alive sample the disposed DCPSPublication sample is used which only contains the key. Solution: The alive DCPSPublication builtin topics associated with the disconnected node is used to unregister the corresponding instances. |
OpenSplice v6.10.2p2
| Report ID. | Description |
|---|---|
| OSPL-12843 / 00019612 | OpenSplice remains in a degraded state when a term signal is send to an internal service like e.g. durability. When a term signal is send to an internal service it will terminate as if it was instructed by the spliced as if a normal shutdown is requested. However, the rest of the system will not shutdown, the terminated service will remain as a zombie process and the rest of the system will remain in a degraded state. Solution: A term signal handler is installed for internal services that will notify the spliced to shutdown OpenSplice when a term signal is received. |
| OSPL-12959 | Tester unable to write struct fields for union type where the union does not have any case for a given enum. In the Tester, the Edit Sample dialog of the "Sample List" window was showing incorrect value for a union type where the union type does not have a case for a given enum. Any attempt to write or dispose any sample containing such union type would fail, throwing a CMException on write. Solution: The problem is fixed. Now tester can write and dispose samples with union type. |
| OSPL-12964 / 00019796 | Durability does not reach the operational state When a durability service starts it is checked if all namespaces have a confirmed master before reaching the operational state. This check contained an error which could cause that a durability service did not reach the operational state. Solution: The condition used in the check has been fixed. |
| OSPL-12965 / 00019797 | First message send after detecting remote node may not arrive at that node. The durability service is dependent on the reliable delivery of message provided by the networking service. When the durability services detects a new fellow (node) it send a capability message to the new detected fellow. However under very high load circumstances it may occur that this first message may not be delivered by the networking service. The networking service will provide reliable communication to a remote node on a particular networking partition when it has received the first acknowledge from the remote node on that partition. However when the first number of message send after detecting the remote node do not arrive at that node for at least a duration longer than recovery_factor times the resolution interval it may occur that this first message is not delivered. Solution: The configuration option SyncMessageExchange is added to enable sending of a synchronization message to a newly detected node. By default this option is disabled because older versions do not provide this option. When enable a synchronization message is sent repeatedly until a corresponding acknowledge is received or the configured timeout expires. When this option is enabled the receiving node will wait with the delivering of the first received message until a synchronization message is received or the configured timeout expires. |
| OSPL-12966 / 00019798 | Add the option to the networking service to include the send backlog in throttling calculation. The calculation of the amount of throttling is using the number of receive buffers that are in use the receiving nodes. A receiving node reports the number of used buffer to the sender in the acknowledge messages. However when there is a high load on the system message may be dropped in the network or in the socket receive buffers of the receiving node. At the sending node an increase of the number of unacked messages may indicate that there is some network congestion occurring. By including the number of unacked messages in the calculation of the throttling factor a sender may react better to network congestion. Solution: The ThrottleUnackedThreshold configuration option is added. When set to a value higher than zero it will enable the number of unacked message to be included in the calculation of the throttling factor. When this option is enabled then the number of unacked bytes that exceeds the ThrottleUnackedThreshold are used in the calculation of the throttling factor. |
| OSPL-12967 / 00019799 | Networking is not able to resolve asymmetrical disconnect correctly. The reliable channel of the networking service will consider a remote node as died when it did not receive an acknowledge in time which is controlled by the Resolution, RecoveryFactor and MaxRetry configuration parameters. When a reconnect occurs it is possible that the remote node did not notice the disconnect and may still be waiting on a particular message to arrive. However this message may not be present anymore at the sending node. This may cause that at the receiving node the reliable backlog exceeds the threshold or when this occurs for more than one node at the same time that the total number of de-fragmentation buffers exceeds the threshold resulting in a termination of the networking service. Solution: The configuration option SyncMessageExchange is added to enable sending of at reset message when a remote node reconnects. By default this option is disabled because older versions do not provide this option. When enable the reset message is sent repeatedly until a corresponding acknowledge is received or the configured timeout expires. The reset message contains the sequence number of the first message that is available and the next sequence number to be sent. This allows the receiving node to reset it's reliable administration. |
| OSPL-13019 / 00019770 | QoS change of time-based filter policy not effectuated Changing the time-based filter QoS policy in some circumstances did not result in the new value being applied to DataReaders with a reliable reliability QoS policy. Solution: The code responsible for QoS changes was fixed |
| OSPL-13030 / 00019840 | Idlpp generates incorrect copy routine for type containing typedef of sequences for isocpp2 When a type definition contains a typedef of a sequence type where the sequence type is another typedef of a sequence then the copy routine generated for the isocpp2 language binding by the idlpp pre-processor is incorrect and causes the application to crash. Solution: The generated copy routine is corrected. |
| OSPL-13053 | The include files generated by idlpp do no have an unique guard macro. The include files generated by the idlpp pre-processor contain a guard macro which is derived from the basename of the source idl file. This may cause problems when idl files have the same basename but are located in different directories. Solution: When the "maintain-include-namespace" option is provided to the idlpp command then the guard macro generated by idlpp will contain an unique prefix generate from the md5 hash of the contents of the idl file. |
| OSPL-13060 / 00019932 | Unrecognized define in isocpp2 for TRUE and FALSE When using isocpp2 with an idl that contains a boolean a compile error could occur that TRUE and FALSE are not defined. Solution: The defines are now properly initiated and the native true and false keywords are now used for booleans generated by idlpp for isocpp2 |
| OSPL-419 / 9168 | For RT networking it is possible to silence tracing, but this is not possible for durability. In situations where log files become too large tracing may have to be suppressed. In RT networking this could be done by setting the enabled attribute of the Tracing element to false. A similar approach was not possible for the durability service. Solution: The durability service now offers a possibility to suppress tracing by specifying the attribute //OpenSplice/DurabilityService/Tracing[@enabled]. This attribute is optional, and defaults to TRUE. Setting it to FALSE will silence tracing of the durability service. |
OpenSplice v6.10.2p1
| Report ID. | Description |
|---|---|
| OSPL-12962 / 00019787 | Python API memory Leak on calls to class serialize when serializing strings When serializing a Python object for writing containing string fields, there is a global variable in ddsutil package called _global_packed which holds the Python reference to the strings while things are organized to be input to struct.pack, then cleared after the serialize routine is finished. When using the serialize code generated by idlpp, however, the _global_packed is never cleared, leading to an ever growing list of python strings. Solution: Idlpp generated Python code now clears the _global_packed list after every call to _serialize. |
| OSPL-12955 / 00019790 | QoS Provider URIs not sufficiently validated When a QoS provider is created with an URI referring to a path instead of an XML file, a crash occurs. Solution: The URI validation of common QoS provider code (shared by all relevant PSMs) was improved to return an error when URI refers to a directory instead of a file (or symlink on supported platforms). |
| OSPL-13006 | GCC warning in idlpp-generated SACPP code (extra semicolon after namespace) When using gcc with strict options (i.e. -Wpedantic), a warning is triggered when compiling idlpp-generated classic standalone C++ code, due to an extra semicolon after the DDS namespace closing bracket. Solution: The warning is caused by a recent change, part of the new idlpp backend (OSPL-11549 / 00018613) and fixed by not outputting the semicolon during code generation. |
| OSPL-12842 / 00019595 | Durability may not notice a temporarily disconnect caused by the reliable backlog threshold being exceeded at networking level. When a receive channel is overloaded or does not get enough resources then it can cause that ack messages are not send in time. This may result in an asymmetric disconnect at the sender side. This may cause that at the receiver side an expected packet is never received causing the reliable backlog threshold to be exceeded. This may cause a short disconnect and reconnect to occur at the receiver side which may not be noticed by the spliced daemon and the durability service. This may cause that durability does not receive an expected message. Solution: When the networking receive channel detects that the reliable backlog is exceeded it declares the corresponding sending node dead for some time to prevent that message still available in the receive socket may reconnect the sending node immediately. Further the durability service reacts not only on the disposed state of the heartbeat but also on the no-writer state which indicates that a remote node has died and may become alive shortly thereafter. |
| OSPL-12846 / 00019611 | mproved inter-operability with Twin Oaks CoreDX Strict QoS validation causes OpenSplice to ignore CoreDX endpoints which use all zero values for the DurabilityServiceQos policy in RTPS-DDSI protocol messages, which is illegal according to the specification. Solution: It was decided in coordination with Twin Oaks to ignore the illegal DurabilityServiceQos in certain harmless cases (volatile or transient-local DurabilityQos) and allow communication between OpenSplice and CoreDX endpoints |
| OSPL-12852 / 00019601 | Improve max-samples threshold warning reports and configurability The max-samples (and samples per instance) threshold warnings, when triggered through one of the PSMs, would imply a more serious error or in other circumstances would not be reported at all. Also it was not possible to disable the threshold warnings by configuration file. Solution: The report mechanism was changed so the warnings are consistently reported at the appropriate verbosity. The relevant configuration parameters (//Domain/ResourceLimits) now accept a value of '0' to disable the reports. |
| OSPL-12864 / 00019622 | Tuner is not able to import data file in XML format. When the Tuner tries to import a data file in XML format and this data file contains whitespace in the text elements or contains windows line endings then it fails to correctly convert strings to numeric values. Solution: The XML parser used by the Tuner strips whitespace from the text elements. |
| OSPL-12866 / 00019627 | Face API hanging when sending NPE to send_event function When using the Java Face API and a NullPointerException is generated inside the send_event function the system wont respond anymore due to the connection being closed. Solution: The exception mechanism is adjusted to cope with this exception and the system will continue to respond as the connection will be kept alive. |
| OSPL-12868 | DDS Security may incorrectly report that secure remote readers or writers do not have participant permission handle. When DDS Security is enabled it may occur that the remote participant is not yet approved but already discovery information about the associated remote readers or writers is received. The permissions of the remote reader and writer are checked again when the remote participant becomes approved. However in this situation incorrect warning and error messages are logged. Solution: In the case that discovery information about remote reader and writers arrive before the associated participant is approved the warning and error logs are removed. |
| OSPL-12870 | Incorrect XSD references in DDS Security configuration files The XSD references in bundled DDS Security configuration templates and example DDS Security configuration files were incorrect Solution: XSD reference in Governance file was updated as https://www.omg.org/spec/DDS-SECURITY/20170901/omg_shared_ca_governance.xsd XSD reference in Performance file was updated as https://www.omg.org/spec/DDS-SECURITY/20170901/omg_shared_ca_permissions.xsd |
| OSPL-12875 / 00019629 | Incorrect handling of dispose-all topic operation The dispose-all operation is processed by remote nodes with help of the C&M Command builtin-topic. Processing of this topic by spliced, contained a flaw which could result in publication of a new C&M Command. This would lead to the same instances being disposed multiple times after using the dispose-all operation. Solution: The processing was fixed to publish a C&M command no more than once. |
| OSPL-12876 | Timestamps for DomainParticipant status logs in the Domain BuiltinTopic logfile are not according to the standard Time format. Timestamps for DomainParticipant status logs in the Domain BuiltinTopic logfile are not according to the standard Time format. Timestamps are logged as seconds.nanoseconds e.g. '1552577680.107568118' but should be logged in the standard time format e.g. '2019-03-14T16:34:40+0100 1552577680.107568118' Solution: The format of the logging is changed to the standard Time format. |
| OSPL-12878 / 00019633 | The use of the DDS Security plugins may cause a crash on some platforms. The DDS Security authentication and the access_control plugin both contain a function with the same name. On some platforms this may cause that the linker links the wrong function which cause an crash during initialization of DDS security when this function is called. Solution: The corresponding functions are made static to prevent visibility |
| OSPL-12888 | When using DDS Security and enable RTPS encryption memory is leaked. When using DDS Security and the configuration specifies that RTPS message encryption is enabled then a memory leak is present at the receiving (decode) side. Solution: The memory leak is resolved. |
| OSPL-12907 / 00019737 | A DataReaderQuery creation can fail when the data type contains a long long attribute which is also addressed in the query expression and compared to a positive integer constant. E.g, something like the following query expression : "myLongLongField = 5" The problem is caused by an internal database query validation function that verifies if the field type and constant type are compatible for comparison. This operation didn't grant comparison between unsigned long long (which is the default type for positive expression constants) and signed long long fields. Solution: The operation is corrected to also grant comparison between signed and unsigned long long fields and constants. |
| OSPL-12911 | Tester unable to read struct fields or write sample of recursive data type. Tester was able to read samples of IoTData type topic (containing recursive data type), but fields within a recursive IOT_NVP_SEQ were missing. Any attempt to write or dispose any sample containing recursive IOT_NVP_SEQ would fail, throwing a CMException on write. Solution: The problem is fixed. Now tester can correctly read, write and dispose samples of recursive data type. |
| OSPL-12919 | A deadlock situation exists between a group coherent transaction becoming complete as result of an alignment action performed by the durability service and an application deleting a coherent DataReader. The problem is caused by internal locking reversal between group coherent administration and kernel group data forwarding. Solution: Kernel groups can insert transactions into the group coherency administration in parallel and must be under control of locking whereas flushing completed group coherent updates is performed by only one thread and is allowed to be performed without locking the group coherency administration as soon as the completed transaction is removed from the admin. Moving the flush outside the locked section solved the deadlock issue. |
| OSPL-12935 | Potential deadlock when deleting a participant When a DomainParticipant is deleted by the user, it instructs the threads it spawned (leaseManager thread, signalHandler thread, resendManager thread, sharedMemoryServiceMonitor thread and watchdog thread) to terminate after which it tries to join those threads. However, the leaseManager thread has a little glitch that could cause it to miss its termination event, after which the participant is waiting indefinitely to join the leaseManager thread. Solution: The glitch in the leaseManager thread has been fixed, removing the chance that the participant will get into this deadlock. |
| OSPL-13004 | Detecting a remote topic that is not allowed locally by DDS Security permissions, shuts down the local DDSI service. DDS Security permissions can be used to allow or deny the creation of topics. Consider a setup where node A is allowed to create 'mytopic', while node B is not. Node B will still receive the topic discovery data from node A. At some point, remote topics were confused as local topics and checked against the local permissions. Because node B thought it was handling a denied local topic, it shut down DDSI as per design. Solution: Detect whether a topic is remote or local before checking against local permissions. |
| OSPL-13009 | When duplicate data is received (e.g., due to alignment) this data is forwarded to readers and may lead to resurrection When a node receives data then this data is injected in the internal administration. If the data has been received earlier (which can happen for instance after a reconnect) then there is no need to forward the data to the readers because the readers already received it. However, the data was still forwarded to the readers. This could lead to resurrection in case the reader previously took the data and the instance because empty and no_writers. Solution: Duplicate data is not forwarded to readers anymore |
| OSPL-12792 | Unable to use Java language bindings on Java 11 JRE Due to the removal of the CORBA package from the JRE in Java 11 (more info: http://openjdk.java.net/jeps/320), certain exception classes are no longer available without using a 3rd party ORB. Solution: Since the use of an ORB is undesirable in classic standalone Java and Java5 PSMs the missing classes are included in the PSMs. A slightly modified version of the Glassfish ORB (https://github.com/eclipse-ee4j/orb) exception classes (specifically SystemException, BAD_OPERATION, BAD_PARAM, MARSHAL and NO_MEMORY) is compiled and packaged in the jars. Note: The use of RMI is not supported on Java 11. |
| OSPL-12853 | Listeners may receive an event that no longer applies to the listener mask just after the listener mask has changed or in case of debug builds crash on an assertion in the OpenSplice library (v_listener code). The problem was caused by incorrect event list management in the OpenSplice core, leaving old events behind which are then passed to the application after the mask was changed and in debug builds triggering an assertion that expected an empty event list. Solution: The issue in the event list management is fixed, obsolete events are no longer left behind. |
| OSPL-1144 / Case 00010809 | Files generated by idlpp begin with a comment The IDL Pre-processor idlpp adds a header to each generated file. The contents of the template file 'fileHeaderContents', located in the directory 'Common' in OSPL_TMPL_PATH, will be added to the start of each generated file. This template can be modified to customize the header contents. This feature can be disabled by an idlpp command line option. |
| OSPL-12287 / 00019125 | Strange output for mmstat Some number were very large instead of being negative numbers Solution: The solution was to change the format of the printed number from unsigned to signed |
| OSPL-12861 / 00019621 | Allow hyphen in topic name The hyphen character ('-') is not allowed in topic-names according to the DDS V1.2 specification but due to an error is listed as a valid character instead of the underscore('_'). Solution: Since the specification is confusing and there's no real reason not to allow it, the hyphen was added as a valid character as long as it does not appear at the start or end of a topic-name. |
OpenSplice v6.10.2
| Report ID. | Description |
|---|---|
| OSPL-3350 | Query ‘like’ expressions on a topic with more that one key can crash with a segmentation violation. In case that the like expression addresses a key field on a topic with multiple keys and the key field is not the last defined in the topic key list then the internal query logic makes a mistake in resolving the key value leading to a segmentation violation. Solution: The bug in the query logic is fixed and tested and now works as expected. |
| OSPL-10460 | Solution: The bug in the query logic is fixed and tested and now works as expected. OSPL-10460 The idlpp pre-processor does not report invalid annotations. The idlpp pre-processor first removes all comments before handling the type definitions. Thus annotations that are specified in comments (//@) are not parsed and thus not checked for validity. Solution: The comments are not skipped and annotations present in these comments are processed and validated. Further the syntax of the annotations is updated to the IDL 1.4 specification. |
| OSPL-11154 / 00018509 | The durability alignment may fail when the networking service detects another node but the communication is not yet reliable in both directions. When the networking service detects the presence of another node it will report that node alive. When the durability service detect this event and receives a first message from the corresponding fellow it will issue a namespace request. However the corresponding reliable channel over which this durability message will be send was not yet reliable at the other node. This may occur when there is much data loss at the receiving side of the other node (for example when socket buffers overflow). In that case the namespace request may be lost. The networking service will resend message at the moment it receives a first acknowledgement from the other node. The networking service maintains some backlog to prevent the first messages to be lost when the first acknowledgement is received. However when there is low traffic on this channel it may cause that the first messages send after detecting the presence of the other node are still lost. The durability service expects a reply as response to the namespace request as long as the fellow at which the request was issued remains alive for the durability service. Solution: A the moment the networking service detects the presence of another node it will report it alive but it will also start resending messages to that node until it receives a acknowledgement from that node or a timeout occurs and the node is reported as not alive. |
| OSPL-11549 / 00018613 | New idlpp backend for classic StandAlone C++ Up til now, idlpp did not have its own backend for the classic C++ language binding: it was forwarding this job to an external IDL compiler (cppgen) instead. However, cppgen was suffering from several issues: * Not able to handle unions with a large number of branches * Not accepting all legal union discriminator types * Not being able to handle recursion through the use of bounded sequences * Skipping generation of a typedef to another typedef in an included IDL file. Solution: A new classic C++ backend is built directly on idlpp that solves all of these issues. The new backend deprecates the use of cppgen, but if the new backend causes issues you can still choose to use cppgen instead by passing the command line parameter "-o deprecated-c++-mapping |
| OSPL-12362 | Possible incorrect liveliness count on DataReader instances and application crashes when a DataWriter unregisters an instance. Three bugs are detected and solved: - When a DataWriter unregisters an instance and is deleted immediately afterwards the liveliness count on DataReader instances should be decreased once but due to an internal race condition it could be decreased twice and eventually become negative. - When a DataWriter unregisters an instance and more that one DataWriter exists for this instance the liveliness is not always decreased resulting in an instance that potentially never becomes not alive anymore. - When a DataWriter unregisters an instance, internally an invalid pointer is used that potentially can cause the application to crash. Solution: The race condition, liveliness counting issue and invalid pointer use are fixed. |
| OSPL-12431 | Solution: The race condition, liveliness counting issue and invalid pointer use are fixed. OSPL-12431 Entity enable only fails on the DataReader when its factory is not enabled. According to the specification the enable operation on an entity should fail in case its factory is disabled and return PRECONDITION_NOT_MET. Until now only the enable on the DataReader behaved according the specification, all other entities would enter the enabled state and return OK. Solution: Checking of the factory enable state is added to Subscriber, Publisher and DataWriter so from now on the enable operation behaves as specified for all entities except for Topics. |
| OSPL-12505 | Potential memory leakage and incorrect liveliness counts. Some internal issues can potentially cause incorrect liveliness awareness and lead to leakage of DataReader instances and incorrect DataReader liveliness counts in instances. Solution: Detected internal issues are fixed. |
| OSPL-12682 | When data without valid content (e.g., a dispose) is forwarded to a reader and the internal instance cache pipeline is bypassed, readers may drop the data. Data that is published should end up at interested readers. Internally, a mechanism called the 'instance pipeline' is used to achieve fast access to the required reader instance to deliver the data. In some occasions the instance pipeline is bypassed, in which case a lookup for the instance occur. In order to lookup an instance the keys for the instance must be provided. If the keys are not provided, then the reader cannot find the required instance. In the code there exists a path where alignment data without valid data (e.g., a dispose) but with keys is received, and this data is transformed to a message without any keys. If this message is forwarded to the reader and the cache is bypassed, then the data does not end up at interested readers. This could occur in situations where a dispose is aligned. Solution: If the pipeline is bypassed, the message is not transformed anymore to a message without keys, but the full-fledged message will be used. |
| OSPL-12755 / 00019529 | Memory leak in durability kv-store in sqlitemt mode The sqlitemt mode of the durability kv-store uses XML instead of CDR serialization to store a more human-readable representation of persistent data, useful for testing/debugging purposes. A missing free in this code caused memory to leak each time a sample is stored. Solution: The issue was fixed by adding a free in the relevant code branch. |
| OSPL-12759 | The idlpp preprocess should be able to maintain the full include directive in the generated files. When an idl file contains an include of another idl file then files generated by the idlpp preprocessor contain a corresponding include statement. However the include statement in the generated file will only contain the basename related to the included file. This may cause conflicts with source files which have the same basename. Solution: The optional option "-o maintain-include-namespace" is added to the idlpp preprocessor. When this option is specified the idlpp preprocessor which will maintain the corresponding include path as specified in the idl file. |
| OSPL-12786 / 00019536 | For c# unions containing only primitive types the idlpp generates incorrect code. To marshal a union between c# and the database representation the idlpp pre-processor generates an intermediate union representation to simulate the overlaying of the union cases. For this purpose a byte array is used. However a byte array in c# may not overlay an other type which causes a problem when the database representation has the union case at an offset smaller that the pointer size. For example when the union contains only primitive types. Solution: To marshal c# unions the idlpp pre-processor generates an intermediate type which either reflects the definition of the union when it only contains primitive types or a buffer to copy the c# union to or from which corresponds with the union size. |
| OSPL-12799 / 00019578 | Possible crash in durability service during termination After the work on OSPL-12648 was finished we discovered that there was another path in the durability termination mechanism that could lead to a crash. Solution: The order in which threads are terminated was rearranged to ensure this cash cannot occur anymore. |
| OSPL-12838 / 00019602 | Non-verbose error reports when key-file cannot be created When a shared-memory domain is started an key-file with metadata is created in a temporary directory (i.e. OSPL_TEMP or /tmp). If this directory doesn't exist or filesystem permissions don't allow creation of the file, an error report is created without including the path. Solution: The error report was extended to include path information |
| OSPL-12840 | Processing many alignment requests is time consuming When there are many nodes and many groups, an aligner may at some point in time be faced with many alignment requests that are stored in a queue. For logging purposes it is possible to log the contents of the queue every time a request is added to the queue. It turns out that this code to produce the logging information scales quadratically with the number of nodes and requests. Furthermore, this piece of code was excercised even when no log line was printed. This lead to unnecessary time consumption and slow performing alignment. Solution: The code is not being exercised by default anymore. |
| OSPL-11262 | Python Binding - Enabled reading of qos from Entity class, and reading of qos policies from Qos class The user of this API may want to read the qos policies that are set on an entity. Solution: The Entity class now has a 'qos' property, which is a Qos object. The Qos class now has getters and setters for each qos policy. |
| OSPL-12765 | Face message connection shall be a case-insensitive named entity The face connection name was not case-insensitive as a result of this a connection named Foo would differ from a connection named foo and give back different connection ids. Solution: The defect is fixed and a connection named Foo or foo will now communicate and also give back the same connection id. |
| OSPL-12638 | JavaScript API: Inconsistent QoS defaults for entities Depending on how entities are created, the QoS for the entities is set differently. For the reader and writer entities, if no argument is provided for QoS then topic's QoS is used. This is inconsistent with the creation of these entities with their default QoS values. Solution: Entities created without specifying an explicit QoS are now created as if a QoS.{entity}Default() value were passed. This is a change from previous releases and may result in the writer being 'reliable'. As a result, calls to write(), dispose() and unregister() must be changed to writeReliable(), disposeReliable() and unregisterReliable(). You must use the 'Reliable' variants of these functions because reliable data writers may block on the DDS system, and could thus block NodeJS JavaScript evaluation thread. The Reliable versions of these methods perform their processing on a separate thread, and indicate their success or failure via a returned promise. |
| OSPL-12645 | DDS Communication Status methods in Javascript API The Javascript 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. |
| OSPL-12597 | Added ACE V6.5.0/TAO V2.5.0 to ORB abstraction layer for Classic Corba-Cohabitation C++ API. The ORB abstraction layer that comes with the Classic Corba Cohabitation C++ API hasn't been kept up to date for a while, and only contained ORBS that were pretty outdated by today's standards, some of which might even refuse to build on the newer Linux distributions. Solution: The latest version of ACE-TAO (ACE V6.5.0/TAO V2.5.0) has now been added to the ORB abstraction layer. |
OpenSplice v6.10.1p2
| Report Id | Description |
|---|---|
| OSPL-12528 / 00019315 | Dispose on synchronous writer blocking and returning timeout When an instance is disposed by a synchronous writer, the writer blocks until the dispose is acknowledged by relevant readers. An issue results in readers receiving the dispose without acknowledging resulting in writers blocking for the maximum blocking time and then returning a timeout result code. Note only dispose is affected, not write_dispose or any of the other write operations Solution: The incorrect behavior was caused by the synchronous flag on the dispose-message getting removed by mistake and an invalid sequence-number comparison, both on the writer side. |
| OSPL-12637 / 00019334 | The dbms connect service does not work with the latest MySQL version. The SQL syntax used by the dbms connect service to create the event table in the MySQL DBMS is no longer supported. This causes the creation of the event table and the corresponding trigger to fail. Solution: The SQL syntax to create the event table is update to use only one primary key which is auto increment. |
| OSPL-12648 / 00019383 | Possible crash in durability service during termination A number of threads in the durability service access shared data. Depending on the context, during termination the cleanup of this data in one thread can cause another thread to crash. Solution: The order in which threads are terminated was changed to ensure the data is cleaned up after all relevant threads have finished. |
| OSPL-12666 | The idlpp pre-processor crashes on a recursive data type definition When the data definitions contain a typedef of a structured type that is being used recursively, e.g. the structured type references itself, then the idlpp pre-processor crashes when generating the corresponding type descriptors. Solution: When generating the type descriptor the idlpp pre-processor maintains an administration of the type definitions which are currently being handled which enables to detect a recursion in the type definition. |
| OSPL-12703 | For c++ the idlpp preprocessor may report that it cannot find the include file "dds_dcps.idl The location of the dds_dcps.idl file has be changed. This may cause that the idlpp pre-processor cannot find this include file when compiling for the c++ language. The default include path used by the idlpp preprocessor points to the wrong location. Solution: The default include path used by the idlpp pre-processor is updated. |
| OSPL-12706 | Using mmstat -t on Window 64bit may causes a crash. When using mmstat -t on Windows 64bit the tool crashes when accessing the kernel which causes the spliced daemon to stop. The cause is the use of the ctime function which depending on the context expects either a 32 or 64 bit time value. Solution: The use of the function ctime is replaced which always uses the time in 64bit format. |
OpenSplice v6.10.1p1
| Report ID. | Description |
|---|---|
| OSPL-12650 / 00019222 | The secure networking service reports that it received a message with invalid protocol-id. In case the secure networking service has to send more than one ACK message it may occur that the header of the ACK message becomes corrupted because it was overwritten by the previous encryption. This cause that the receiving node reports that is has received a message with an invalid protocol id and discards the message. This may cause a unnecessary retransmission. Solution: When more than one ACK message is send the buffer used to hold the ACK messages is reinitialized after sending the previous ACK message. |
| OSPL-12693 | The user-data field of the builtin DCPSParticipant topic may remotely be missing. When the ddsi service advertises a local participant it has to copy the QoS parameter of the corresponding participant QoS in the advertising message. This enables the receiving ddsi service to create an corresponding builtin DCPSParticipant topic. However in this case the user-data field is not copied at the sending side and thus will the created DCPSParticipant topic have an empty user-data field. Solution: The user-data field of the participant QoS is copied to the message which advertises the participant on the network. |
OpenSplice v6.10.1
| Report ID | Description |
|---|---|
| OSPL-12660 / 00019363 | Files created outside the configured OSPL_TEMP location The shared-memory monitor creates 'osplsock' files which do not adhere to the configured OSPL_TEMP env. variable. Instead the file is always created in /tmp. Solution: The code responsible for socket file creation is changed to prepend the value of OSPL_TEMP instead of '/tmp'. Note the fallback is still to use '/tmp' in case OSPL_TEMP is unset. On Posix systems a restriction of 108 bytes is applied to the length of the OSPL_TEMP due to the nature of unix sockets exceeding this result in an error message and OpenSplice will not start |
| OSPL-12253 / 00019074 | Networking service trace logs of different threads are interleaved The trace reports of the (secure) RTNetworking service on a busy system can be interleaved, i.e. two threads writing partial traces to the output file that end up on the same line. This decreases readability of the log and makes automated processing more difficult. Solution: The issue was resolved by no longer writing partial traces to the output file. There is a possibility of order reversal of reports by different threads though that should only be cosmetic, reports of the same thread will still be in order. |
| OSPL-12496 / 00019225 | Durability service fails to update status on termination The durability service needs to terminate when it detects an invalid namespace configuration. This normally occurs shortly after startup and follows a different termination path that fails to update the service-state. This in turn prevents spliced from taking appropriate actions. Solution: The durability code was fixed so the service-state is correctly updated before the service terminates. |
| OSPL-12561 | When two type definitions use an anonymous sequence of a type with the same name but in a different scope a crash may occur. When an anonymous sequence or array is created the a corresponding type definition is registered within the database which is used to allocate and free the anonymous sequence or array. This anonymous sequence or array type is registered using the name of the sub-type. However the name of the sub-type may not be unique because it may occur in different scopes. This may result that the wrong type is used to allocate the anonymous sequence or array. Solution: The full-name of the sub-type is used when registering the anonymous sequence or array type. Note that the full-name will be unique. |
| OSPL-12564 / 00019319 | will be unique. OSPL-12564 / 00019319 The use of the C API generic read/write operation may cause a crash on ARM. For some type definitions the use of the generic read/write operation provided by the C API may cause a crash on the ARM platform. For sequence types the data is stored differently in the database as on the API layer. On the API level a sequence has the additional field _length, _maximum and _release. The generic copy routines that are generated from the XML type definition correct for the different sizes of the sequence stored in the database and how it will be copied to/from the C API. However on the ARM platform a misalignment may occur when the sequence type is followed by a data type that has to be aligned on a 8 byte boundary. Solution: The data structures used by the generic copy routines are updated to include information to correct the alignment differences between the database representation and how the data is represented at the C API. |
| OSPL-12581 / 00019361 | Java OSGi support broken Since V6.9.2 when the building of the Java(5) APIs was changed to maven the dcpssaj-osgi-bundle.jar file was not OSGi compliant. Solution: The following jar files are now OSGi compliant: dcpscj.jar, dcpssaj.jar and dcpssaj5.jar. These OSGi jar files can still be used as 'normal' jar files. No extra separate OSGi jar files needed. |
| OSPL-12621 | Type error in isocpp/isocpp2 xtypes interface When trying to use the xtypes interface of isocpp or isocpp2 an compilation error occurs on enum type. This should be enum Type in the TypeKind_def. Solution: Fix the type error. |
| OSPL-12548 | The DDSI2 service may establish secure TCP connections using TLSv1.1 instead of the more secure TLSv1.2 When establishing a secure TCP connection the DDSI2 networking service uses less secure version 1.1 of the TLS protocol instead of the more secure 1.2. Solution: The initialization of the secure TCP connection is changed to allow only TLSv1.2. |
| OSPL-12572 | The serializer used to convert data to CDR format does not handle large array correctly. When the type definition of a data type contains a large array containing more that 2^23-1 of primitive types then the CDR serializer is not able to convert this data. Internally the serializer uses an upper limit of 2^23 when serializing an array containing primitive types Solution: To convert data that contains an array with more than 2^23-1 primitive types the CDR serializer creates a loop of iterations to serializer successive parts of the large array. |
OpenSplice v6.10.0p2
Changes and fixed bugs not affecting the API in OpenSplice 6.10.0p2
| 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-12135 / 00019020 | Python DCPS API - Incorrect struct align and padding logic for dynamic (de)serializer. There were certain cases observed with certain topic types where data corruption within the sample payload occurred on reading data with the Python API coming from remote writers. The cause of the corruption was deserializer was populating the Python class for the topic data type from the incoming byte buffer with incorrect struct padding information. Solution: The calculation for struct padding has been corrected. |
| OSPL-12271 / 00019111 | Database mapping-address overlap on 64-bit ARM The 64-bit ARM (aarch64) builds used a default mapping address normally only used on 32-bit systems (0x20000000). Solution: To decrease the chance of address overlap, the default was changed to match the address used on 64-bit Intel-based systems (0x140000000). |
| OSPL-12276 / 00019117 | Error in the generated python object For statically generated Python code (via idlpp -l python), if an IDL struct is defined with only a single field then the generated member of '_member_attributes' becomes a string instead of a tuple. This happens because ('name') is interpreted as a string, whereas ('name1', 'name2') is a tuple of two strings. Solution: The '_member_attributes' in the generated python code now has an additional comma at the end. Therefore, now the '_member_attributes' will be interpreted as a tuple even if the IDL struct contains a single field. |
| OSPL-12280 / 00019122 | OSPL Tuner shortcut for Create Reader-Writer | Existing Partition should not be CTRL-A The shortcut for for Create Reader-Writer | Existing Partition does not work when it is set to CTRL-A, as this shortcut already has the default behaviour of 'select all rows' associated with it. Solution: The shortcut has been changed to CTRL-B. |
| OSPL-12330 | Python API segfault crash when receiving a disposed instance When subscribing with an application using the Python API, if a topic contains a string field, and a reader on that topic receives a state update (as in valid_data == False), then while deserializing the sample a segfault crash occurs due to attempting to dereference the null pointer for the string field. Solution: Fixed the null pointer dereference when deserializing string fields. |
| OSPL-12441 / 00019190 | When a candidate master becomes non-responsive during master selection, durability may not reach the COMPLETENESS state When a durability service starts, one of the first things it does is look for other durability services (fellows). If there are any fellows, then the durability services will negotiate which one them will acts as the master aligner for a namespace. In case there is a fellow that becomes non-responsive while negotiating mastership, then other durability service still try to elect this fellow as master. Because the fellow is non-responsive this will fail. This causes the durability service to never reach the COMPLETENESS state Solution: When a fellow becomes non-responsive while negotiating mastership, the fellow is excluded as potential master. |
| 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. |
| OSPL-12525 | Idlpp python codegen fails to compile IDL containing const value of typedef type. When using idlpp for python code generation, if the IDL contains a const value whose type is a typedef, like the following: typedef int myint_t; const myint_t x = 0; Then idlpp exits immidiately with error code 1 and the printout "should not get here. idl_type == 1". Solution: The case for handling const definitions whose type is a typedef is now handled. |
| OSPL-12526 | [JavaScript] Potential errors reading from topics with sequences On reading a sequence, the DDS JavaScript API receives two integer values from the underlying DDS system: the length of the sequence read, and the maximum length of the buffer containing the sequence. The JavaScript API erroneously assumed that these two values were always the same, and erroneously made use of the returned maximum value. This could result in the JavaScript API including more sequence elements than a sample actually contains. Such behaviour can be seen if your code performs two or more read/take operations, with the first operation returning a sample with a larger number of sequence elements and the second operation returning a sample with a smaller number of sequence elements. The sample from the second operation would then erroneously include extra sequence elements from the first sample. Solution: The DDS JavaScript API has been corrected to distinguish between sequence length and the maximum sequence buffer size, and to correctly use the actual sequence length when reading. |
| OSPL-12541 / 00019322 | Missing dispose messages for late joining readers In the scenario where a late joining DataReader receives historical data from a deleted DataWriter with the auto dispose QoS policy set. The DateReader expects to receive the historical data in the state NOT_ALIVE_DISPOSED. However tests showed that since V6.10 the state has changed to NOT_ALIVE_NO_WRITERS. Solution: The problem is introduced by combining the Unregister and Disposed message as optimization but where the Unregister got preference above the Dispose. A fix is applied so that the Dispose is processed correctly. |
| OSPL-11674 | Simulink: Optional output directory argument to Vortex.idlImportSl Previous releases of the Simulink integration for OSPL did not allow specifying an output directory when the Vortex.idlImportSl() processed an IDL file. Solution: An optional argument has been added to Vortex.idlImportSl. If the outputDirectory parameter is provided, output from the IDL processor will be placed in the specified directory. Otherwise, current behaviour will be maintained, and the IDL process output will be placed in the current working directory. |
| OSPL-12074 | NodeJS DCPS API - New convenience function added to convert seconds to nanoseconds The DCPS api has functions that expect a number of nanoseconds as a parameter. This can be inconvenient to specify number of nanoseconds. Solution: A new convenience function was added so that users can easily convert seconds to nanoseconds. |
| OSPL-12152 | Python API missing factory method to create a topic The Python API for DDS did not include a {{DomainParticipant}} method to create/register a {{Topic}}. Instead, users had to directly invoke the {{Topic}} constructor. This was inconsistent with the way the API deals with the creation of child entities. Solution: A {{create_topic}} method has been added to the {{DomainParticipant}} class. Customers should prefer this method to calling the {{Topic}} class constructor directly. |
OpenSplice v6.10.0p1
Fixed bugs and changes not affecting the API in OpenSplice 6.10.0p1
| Report ID. | Description |
|---|---|
| OSPL-12135 / 00019020 | Python DCPS API - Incorrect struct align and padding logic for dynamic (de)serializer. There were certain cases observed with certain topic types where data corruption within the sample payload occurred on reading data with the Python API coming from remote writers. The cause of the corruption was deserializer was populating the Python class for the topic data type from the incoming byte buffer with incorrect struct padding information. Solution: The calculation for struct padding has been corrected. |
| OSPL-12196 / 00019046 | Memory leak when client durability client sends unanswered request When the client durability client sent out a request and it did not receive a response the request was kept indefinitely which caused memory leakage. Solution: Added a garbage collector to client durability client which removes unanswered requests after ~35 seconds |
| OSPL-12328 / 00019137 | Unions in C# may be misaligned on some platforms Depending on the exact contents of a an IDL union, its C# representation might be misaligned on certain platforms. For example, on some 32 bit platforms a union with a 64 bit branch would not align that branch on 64 bit (as required on certain 32 bit platforms), but rather on 32 bit. Solution: The algorithm to determine alignment has been corrected to now be based on the worst case alignment requirement of all its branches. |
| 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-12348 / 00019160 | SuspendedPublication compile error When creating a SuspendedPublication object using the ISOCPP2 API results in a compile error. Solution: The error is fixed and the SuspendedPublication object can now be used correctly. |
| OSPL-12349 / 00019164 | OSPL_LOGPATH environment variable not used Due to a comparison bug, the value of the OSPL_LOGPATH environment variable is rejected, while it contains a valid string referring to a directory with write permission. Solution: The comparison bug was fixed so only values referring to an invalid path and/or directory with insufficient permissions is rejected |
OpenSplice v6.10.0
Fixed bugs and changes not affecting the API in OpenSplice 6.10.0
| 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. Solution: Memory leaks are fixed. |
| OSPL-11760 / 00018777 | OpenSplice signalhandler deadlocks when crash in malloc. The OpenSplice signalhandler deadlocks when a SEGV occurs in the malloc system call as the signalhandler did allocations for reporting. Solution: Removed allocations from reporting when called by signalhandler and added a 60 second timeout on handling of synchronous signals after which the process is terminated. |
| OSPL-11976 / 00018930 | Durability service is reported DIED when resending for more the than heartbeat expiry time. When the durability service starts resending samples and isn't able to successfully write the sample before the heartbeat expiry time expires the service is reported DIED. When durability starts resending samples some of it's threads were holding a lock while continously trying to write the sample, this resulted in the renewal thread to block and not renew the lease. Solution: Release the locks before resending. |
| OSPL-12194/OSPL-12195 | Python/Javascript Binding IDL processing errors in OpenSplice Evaluation version. When processing idl files with the Python/Javascript binding with an evaluation version of OpenSplice an error occurs due to the EVALUATION VERSION idlpp printout Solution: The evaluation version of the Python/Javascript binding now correctly processes IDL files. |
| OSPL-12170 / 00019038 | Memory Leak concerning v_groupInstance. When writing and disposing instances it can happen that the v_groupInstance count grows where it should remain stable. Solution: The leaking v_groupInstance is fixed and the count will remain stable again. |
| OSPL-12712 | Simulink] Simulink Coder support for cross-compiling to another target When using Simulink Coder to cross-compile a model to a OpenSplice target, the Simulink model needs access to the host environment OpenSplice executables, includes and libraries as well as the target environment OpenSplice libraries. Solution: To support cross-compilation, the VortexDDS Block Set now supports the LINK_OSPL_HOME, which should be set to the home directory of the target OpenSplice installation. During Simulink Coder compilation, a warning will be printed on the console indicating that LINK_OSPL_HOME is being used. For Simulink Coder builds targeted at the host OpenSplice installation, LINK_OSPL_HOME should not be set. |
| OSPL-12219 | Simulink] Calculation of model-relative paths for QoS profiles occasionally incorrect To enable model portability the DDS block set for Simulink attempts to start references to QoS Profile XML documents as relative to the simulink model. However, in cases where the Simulink model included several subsystems, across subdirectories, or in cases where the QoS file was not in a subdirectory of the Simulink model, the calculation was incorrect. Solution: QoS Profile paths are now calculated relative to the 'root' Simulink model. In the case where the QoS Profile document is not contained directly or indirectly in the folder tree containing the root model, '../' elements are added to the QoS Profile path, in order to ensure a correct relative path. Note that, as with previous releases, when executing models (or programs generated from models via Simulink Coder), QoS Profile XML files are located relative to the current working directory when the execution starts. |
| OSPL-12218 | [Simulink] Global variable 'domain' being created by Participant block Using the DDS Participant block in a Simulink model caused a global variable 'domain' to be created. Solution: The variable is no longer created. |
| OSPL-12118 | Potential crash when reading data from persistent XML store When a durability service it may inject persistent data from its store (when available). In case the persistent data was stored in an XML store, then the pathname of the file that contains the store is dynamically allocated. The current implementation assumes that folder separation symbols occupy a single character. This is not true for some operating systems. In those cases too little memory is allocated. This may lead to a crash. Solution: The pathname now uses a operating system dependent file separator. |
| OSPL-12090 / 00018967 | Listener is not triggering on a built-in topic reader. When using the Java(5) API and when a listener is attached to a built-in topic reader the listener is never triggered. Solution: The defect in the built-in topic mechanism is solved and a listener attached to a built-in reader will now trigger as expected. |
| OSPL-12085 | Missing methods in C# Tutorial example. The C# Tutorial example contains a messageboard executable who uses a ExtDomainParticipant class. This class was missing 2 methods. Solution: The missing functions are added to the ExtDomainParticipant class |
| OSPL-12078 / 00018965 | When the namespace state has been reset and a native state conflict occur, the durability service can crash. Whenever a master for a namespace advertises a new state, slave nodes generate a native state conflict. To resolve such conflict, slave nodes will start an alignment from its master. In case the namespace state of the slave has been reset just before the native state conflict is resolved it is possible that the durability service service crashes due to an invalid deference. Solution: The invalid deference has been fixed. |
| OSPL-12042 | Build error when building from source on macOS When building from source building on macOS of ospl_uniqueID failed due to not yet existing directory Solution: Directory created as part of build process |
| OSPL-11974 | Idlpp ignores illegal enum idl construction. When using multiple enums in the same idl module and in those enums the same labels are used idlpp does not produce an error as this is not valid idl. Solution: The problem is fixed and idlpp now reports the invalid idl construction. |
| OSPL-11971 / 00018921 | Reading an invalid sample may cause infinite triggering loop. Invalid samples are meant to communicate an instance state change in case of the absence of user samples. Their only purpose is to communicate the instance state change, and when that has been done they serve no further purpose and therefore they are no longer be visible on subsequent read/take actions. However, if an invalid sample is read (not taken), it stays behind in the reader where it may cause a Read/QueryCondition on a SampleState of ANY to continue to trigger. However, since any subsequent read/take operation will ignore the invalid sample, there is no way to to get rid of it causing the Read/QueryCondition to spin indefinitely. Solution: The read operation now destructively takes invalid samples out of the reader cache, thus avoiding the Read/QueryCondition to spin on them. |
| OSPL-11957 | Shared memory consumption may increase after many restarts of nodes in case coherent transactions are involved, leading to potential shared memory exhaustion. The persistent store maintains End-Of-Transactions (EOT) messages that are published when a transaction is completed. An EOT should be removed from the persistent store if no samples belonging to the EOT are referenced anymore, but this was not happening in all cases. As a result the persistent store maintains too many EOTs. When these messages are injected after a restart, they will never be removed anymore. Over time, this may cause shared memory depletion. Note: this issue relates to OSPL-11941 Solution: EOT messages are now correctly removed from the persistent store. |
| Shared memory consumption may increase after many restarts of nodes in case coherent transactions are involved, leading to potential shared memory exhaustion. The persistent store maintains End-Of-Transactions (EOT) messages that are published when a transaction is completed. An EOT should be removed from the persistent store if no samples belonging to the EOT are referenced anymore, but this was not happening in all cases. As a result the persistent store maintains too many EOTs. When these messages are injected after a restart, they will never be removed anymore. Over time, this may cause shared memory depletion. Note: this issue relates to OSPL-11941 Solution: EOT messages are now correctly removed from the persistent store. | Tracing Verbosity uppercase values accepted but not recognized by RTNetworking. When using RTNetworking and setting a Tracing Verbosity value in uppercase the values are accepted by the configuration checker but not recognized by RTNetworking configuration parser. Solution: The defect is fixed and now upper and lowercase accepted values are recognized by the RTNetworking configuration parser. |
| OSPL-11786 / 00018791 | Generating dead code with IDLPP from an IDL containing a string definition. When using an idl containing a string definition and generating code for the C language dead code is being generated. Solution: The defect in the generating algorithm is fixed and correct code is now generated. |
| OSPL-11532 | Python API: get_key method implemented for DataReader and DataWriter Previous releases of the Python API for DCPS did not include implementations for the get_key method on DataReader and DataWriter classes because an underlying DCPS error would have caused these methods to fail. (The get_key method accepts an 'instance handle' and returns an object instance with the key fields initialized to the appropriate values for the instance handle. All other field values have default values.) Solution: The get_key method is now available. |
| OSPL-11506 | To save network bandwidth it is now possible to start alignment only when the topology has become stable. As soon as a durability service joins an existing system alignment may occur between the durability service and its master. When the topology changes while the alignment is going on (e.g, new subsystems joining) the alignment itself may not be necessary anymore (e.g., because somebody else has become master). Unfortunately, there is no way cancel ongoing alignments. To prevent such potential unnecessary alignments it is more efficient to start alignment when the topology is "stable", meaning that no topology changes have been detected for some time. This increases the chances that all nodes have selected the same master, which may lead to less alignments. The optional configuration option //Opensplice/DurabilityService/Network/Alignment/Topology/Stable can be used to specify the stability period (defaults to 0.0. seconds). To prevent that no alignment will ever occur in deployments where the topology is never stable, a maximum can be provided using the //Opensplice/DurabilityService/Network/Alignment/Topology/Stable[@max] attribute (which defaults to -1.0, meaning infinite). When the maximum time has expired and the topology is still not stable then alignment will occur anyway. Solution: It is now possible to wait for alignment if the topology has become stable. |