This page lists all the fixed bugs and changes in the OpenSplice 6.11.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.11.x
OpenSplice v6.11.2p6
| Report ID. | Description |
|---|---|
| OSPL-14675 / 00021716 | Memory leak in the kernel, when setting QoS on a Subscriber. A memory leak in the OpenSplice kernel occurs when using any of the APIs to setting QoS on subscribers. Solution: The memory leak has been fixed. |
| OSPL-14681 / 00021724 | Update the used SQLite version. The SQLite version used in OpenSplice contained CVE vulnerabilities. Solution: The version of SQLite has been updated to 3.41.0 for the following OpenSplice product codes: P839, P840, P792, P738, P704. |
| OSPL-14802 / 00021818 | A late-joining reader may read a transient-local sample from a deleted writer of another vendor. In OpenSplice transient-local samples are stored in the transient store. When the writer is deleted the corresponding instances should become unregistered. It appeared that this does not occur for instances written by a transient_local writer. This may cause a late-joining reader to receive an alive sample from an already deleted transient-local writer. Solution: When an OpenSplice instance detects that a writer is deleted it unregisters all the instances written by that writer. Note that when communicating with another vendor, a late-joining OpenSplice reader may still read a sample in the no-writer state from a deleted transient-local writer. |
| OSPL-14847 / 00021846 | When DDS security is used, the tuner may not be able to create a reader for topics allowed by security. For the tuner to create a reader or writer for a certain topic it needs the associated topic and type definition. Topic discovery would provide that information. However when DDS security is used the topic discovery information may not be distributed. It appears that topic information is only sent when the permission file specifies the all wildcard "*" for the partition part of an allowed rule. At the moment the topic is created the ddsi service will try to send topic discovery information and will ask the access control plugin if that is allowed. However the access control plugin will reject that request because the partition related to a reader or writer is not yet known. Solution: When DDS security is enabled, topic discovery information is sent when access control permits the creation of a reader or writer. In this case the associated topic information will be distributed. |
| OSPL-14890 / 00021878 | Memory leak when using the dispose_all_data function. When dispose_all_data is called an internal Topic (DCPSCandMCommand) message is written to communicate the dispose_all_data to the other nodes in the system. This caused a small memory leak at the node where dispose_all_data is called. Solution: After writing the DCPSCandMCommand message, the memory is freed. |
| OSPL-14899 | Samples may be incorrectly dropped when samples from the same writer arrive out-of-order. When a writer writes a sample a sequence number is added to the sample. The sequence number is incremented for each sample. The sample that is written is put into the network queue to be processed by the network service, which transmits the sample to the other nodes. However, the network service (either ddsi2 or RT networking) applies its own sequence number scheme to provide reliable communication and to provide in order delivery. Lately an input filter was implemented at the receiving side which checks if samples from the same writer arrive in order. Normally that will be the case. However, it may occur that the network queue at the sending side is full. In this case it may occur that samples from different writer instances are not placed in the network queue in order of writer sequence number. In this case the input filter may incorrectly drop these samples. The same may occur when using transient-local. Solution: The input filter has been removed. |
| OSPL-14901 / 00021806 | Fix for CVE-2020-18734. A stack buffer overflow in ddsi q_bitset_template.h causes a crash. More info on https://nvd.nist.gov/vuln/detail/CVE-2020-18734. Solution: The defect has been fixed by adding a check for the buffer. |
| OSPL-14930 / 00021910 | Reduce memory usage of the networking service when using the "Reliability Under Publisher Crash" feature. When the networking service is configured to use the "Reliability Under Publisher Crash" (RUPC) feature, it will maintain the packets stored in the defragmentation buffers during the configured "PacketRetentionPeriod" on a backup list. When this retention period expires, the buffers can be re-used again to store received packets. The problem is that the timestamp set on the defragmentation buffer to mark the start of the retention period is done lazy at the moment a new defragmentation buffer is needed. This may cause the defragmentation buffers to remain unavailable for a much longer time then specified by the retention period which may cause much more defragmentation buffers to be used than needed. Solution: Defragmentation buffers are timestamped at the moment they are added to the backup list. Further defragmentation buffers for which the retention period has expired are periodically moved from the backup list to the free list. |
| OSPL-14935 / 00021917 | Samples of a persistent topic may not be received when using by reception timestamp. When a reader receives a sample it has to be determined if this sample is a new or old sample. An old sample will be dropped when the history is full. When using by source timestamp, the source time is used to compare if a sample is newer or not. When using by reception timestamp the allocation time is used for that purpose. The allocation time of a sample is set when the sample is received. The clock used for the allocation time may be the monotonic or boottime (linux) clock. When injecting a sample from persistent storage, the allocation time of the sample should be set again. However, this does not occur, causing the problem that old samples from persistent storage are considered newer than live samples. Solution: When injecting a sample from persistent storage set the allocation time of the sample again. |
| OSPL-14939 / 00021922 | When using DDS Security, it may occur that the first samples of a volatile writer may not be received by a matching reader. A writer receives a publication match event when the spliced daemon receives a DCPSSubscription builtin topic related to a remote reader and finds a match with a local writer. When the DDSI service discovers a remote reader then it immediately creates a corresponding DCSPSubscription and writes that into the OpenSplice kernel. When not using DDS Security, the DDSI service will, on discovery of a remote reader, immediately match that reader with the locally present writers and reliability will be provided. However, when using DDS Security to have communication between a writer and a remote reader, this requires that first, the associated crypto tokens have been exchanged before reliable communication can be established. Because the DDSI service writes the DCPSSubscription builtin topic immediately after discovery of a remote reader, it may occur that samples written by a volatile writer are being dropped because the crypto token exchange was still in progress. Solution: When using DDS Security the DDSI service will on discovery of a remote reader delay the writing of the corresponding DCSPSubcription builtin topic until the crypto token exchange has been completed and the writer and reader are matched at DDSI level. |
| OSPL-14944 / 00021923 | Samples of DCPSPublication and DCPSSubscription are not freed when the corresponding writer or reader is deleted. The spliced daemon maintains the builtin topics. When the spliced daemon receives alive DCSPPublication or DSPSSubscription samples it adds these samples to the builtin administration, which is, for example, used to handle publication or subscription match events. When the spliced daemon receives a disposed DCPSPublication or DCPSSubscription sample it should remove the corresponding earlier stored alive sample from the administration. Solution: The reception of a disposed DCSPPublication or DCSPSubscription removes the corresponding alive sample from the builtin administration. |
| OSPL-14949 / 00021929 | The ddsi2 service leaks some heap memory when it receives SPDP messages containing a property list. The deserialization of the property list that may be present in a SPDP message received from an remote participant allocates a little memory related to the number of key value pairs present in the property list. Solution: When the property list is deleted then free also the memory allocated for storing the references to the key value pairs. |
OpenSplice v6.11.2p5
| Report ID. | Description |
|---|---|
| OSPL-14865 / 00021858 | In the isocpp api the generic InstanceHandle constructor should be explicit. The issue is that the implicit constructor of InstanceHandle template allows any type to be implicitly converted to an InstanceHandle. By specifying the constructor as explicit solves this issue. See isocpp specification issue. Solution: The constructor specified in dds::core::TInstanceHandle is defined as explicit. |
| OSPL-14847 / 00021846 | When DDS security is used the tuner may not be able to create a reader for topics allowed by security. For the tuner to create a reader or writer for a certain topic it needs the associated topic and type definition. Topic discovery would provide that information. However when DDS security is used the topic discovery information may not be distributed. It appears that topic information is only sent when the permission file specifies the all wildcard "*" for the partition part of an allow rule. At the moment the topic is created the ddsi service will try to send topic discovery information and will ask the access control plugin if that is allowed. However the access control plugin will reject that request because the partition related to a reader or writer is not yet known. Solution: When DDS security is enabled topic discovery information is sent when access control permits the creation of a reader or writer. In this case the associated topic information will be distributed. |
| OSPL-14825 / 00021833 | [NodeJS] IDL containing a union field of type sequence did not work. If an IDL type contained a Union object with a field of type Sequence, then the NodeJS API would either fail with an obscure error or write data that did not contain the sequence data. Solution: NodeJS now supports sequence fields within a union. |
| OSPL-14787 / 00021808 | Transient-local alignment may be slow in the case of large fragmented user samples. When retransmitting a fragmented message, ddsi will first send the first fragment of the sample to provide better flow control of large samples. When message loss occurs, this will prevent complete samples having to be retransmitted when fragment are lost. When using this mode, ddsi will handle one sample at a time and proceed with the next sample after the first sample has been completely acknowledged. This could cause the alignment of a large amount of transient-local data to become slow which is related to the roundtrip latency. To accelerate the alignment a number of samples could be partly retransmitted. Solution: When a number of fragmented samples are scheduled for retransmission then retransmit fragments of a number of these samples before waiting for a nackfrag message. |
| OSPL-14772 / 00021794 | The spliced daemon may deadlock on termination when a service did not terminate in time and the spliced daemon forcefully terminates the service. When a process terminates or crashes, the spliced daemon will try to cleanup the shared memory resources that the process may have left. When a process crashes when accessing shared memory, which should not occur, the spliced daemon will not try to cleanup the shared memory resources and will terminate because the state of the shared memory could be compromised. However in this case, the spliced daemon receives a termination signal and will start terminating and shutting down the services. It appears that the ddsi and the durability services do not terminate fast enough, which causes that the spliced daemon to send a kill -9 to these services. Although the spliced daemon is in the terminating phase it still detects that the durability process has terminated and it detects that the durability process was accessing shared memory when it received the kill -9 signal. Because the spliced daemon is already in the terminating state, it does not check if the shared memory is compromised and starts cleaning up the shared memory, which causes the deadlock because the durability service was still holding a lock. Solution: When the splice daemon during termination has to forcefully terminate a non-responding service, it directly terminates without performing a cleanup action. |
| OSPL-14770 / 00021791 | The durability service may deadlock when resolving a connect conflict with nodes having a role defined. When detecting a fellow, the durability creates a connect conflict. A connect conflict can be combined with an existing connect conflict from a different fellow which enables a connect conflict to be resolved for all fellows in one alignment action. However connect conflicts from fellows which have different roles cannot be combined. The role of a fellow becomes known when a namespace message is received. Initially, connect conflict of fellows are combined but when the role information becomes available the connect conflicts have to be split again. The split of the connect conflicts causes a deadlock because the lock of the conflict was not released when adding the split conflict to the conflict administration. Solution: When a connect conflict for a particular fellow is removed from a combined connect conflict because the role of this fellow does not match, then release the conflict administration lock before adding the new conflict. |
| OSPL-14763 | DLite slow processing of incoming alignment data. The main loop of DLite periodically waits in a waitset for incoming protocol messages. If alignment beads are received the waitset will unblock and DLite will process the incoming alignment data. However, every 100 messages DLite will pause processing of alignment and return to the main loop to verify if it needs to do some housekeeping. After that it should continue processing the remaining beads. However, it continues by calling the waitset wait again and this is incorrect in the case where no new data is received and remaining unprocessed data still exists. If no new data is received, the data available status is not set because it was reset in the previous cycle, so the wait will block until it receives new data or a timeout occurs (1 second), after which it will process the next 100 beads. This means that in a worst case scenario the processing of received alignment data will add a 1 second delay (timeout) for every 100 beads. Solution: The solution is to check if unprocessed data exists before entering the waitset wait. The waitset wait shall be skipped in the case where unprocessed data exists. |
| OSPL-14759 / 00021786 | Using ordered access with group scope could result in a segmentation fault. To provide ordered access with group scope a subscriber related resource is shared by the readers of this subscriber. Not all operations on this shared resource are properly locked which could cause that more readers could manipulate this shared resource at the same time causing it to become corrupt. Solution: All concurrent operations on the shared resource which is used to provided coherent access on group scope are properly locked. |
| OSPL-14749 / 00021776 | An sample from a reliable writer can get lost when the sample is written during startup of OpenSplice. When an application writer writes a sample the sample is put in a queue. The samples on this queue are then handled by the ddsi service and forwarded on the network. To handle a sample the ddsi service needs the information about the application writer. For that purpose the ddsi service listens to the internally generated builtin topics that are created when the application writer is created. When the ddsi service reads a sample from the internal queue it checks if it already knows about the application writer, which means that it has received the internal generated builtin topic associated with the application writer. The ddsi service will drop the sample when it has not yet received the corresponding builtin topic. Normally this could not happen because the builtin topic is created when the application writer is created and thus before a sample can be written. However during startup of OpenSplice, it could occur that the ddsi service is not yet ready to receive the internally generated builtin topics and then the resend manager will be responsible to provide the builtin topics to the ddsi service at a later time. In that case there is a small chance that the ddsi service retrieves an application sample from the queue before it has received the corresponding builtin topic and then will drop the sample. Solution: The spliced daemon will set the state to operational after the networking services have been initialized and are able to process the builtin topics. This will resolve the issue because the creation of a domain participant will wait until the state becomes operational. |
| OSPL-14684 / 00021591 | The functions ignore_participant, ignore_publication and ignore_subscription do not work correctly. The functions ignore_participant, ignore_publication and ignore_subscription do not work as intended. The idea is that you pass the instance handle of the entity you want to ignore (you can obtain this instance handle from the builtin topics, or from the function get_instance_handle on the Entity class), and then all data originating from that Entity will be discarded. However, something went wrong in the translation of the instance handle into the intended target, causing it not to be located and therefore not to be ignored. Solution: The translation from instance handle to intended target has now been corrected. which causes the intended target to be ignored correctly. |
| OSPL-14255 / 00021085 | In certain circumstances BY_RECEPTION_TIMESTAMP topics (including the builtin topics) may go back in time. BY_RECEPTION_TIMESTAMP topics (this includes all builtin topics that are BY_RECEPTION_TIMESTAMP according to the DDS specification) would always append newly arriving samples to the end of their corresponding instance queue. This would allow them to go back in time if samples would ever be receiver out-of-order. One particular scenario where this could wreak havoc is when builtin topics that are aligned using either Durability/DLite (this for example the case when using native networking, where the builtin topics do not get aligned as part of the networking protocol) get disposed before the transient snapshot (in which they are still included) arrives. So in a case like that, you first get a DISPOSE message from a DCPSPublication through the live networking path, followed by the sample preceding it from the transient snapshot, which would result in the DCPSPublication representing a particular Writer ending in the ALIVE state instead of in the DISPOSE state. This could cause Readers to assume there still is at least one ALIVE Writer while in fact there is not, causing their data to stay ALIVE even when this is incorrect. Also mechanisms like the synchronous reliability do not work correctly in scenarios like that: if a DCPSSubscription represents a synchronous Reader then the writing side can be fooled into believing there is still a Reader that needs to acknowledge its data, when in fact this Reader has already left the system. The writing side will then block waiting for an ack that will never be sent, effectively blocking the Writer application indefinitely. Solution: BY_RECEPTION_TIMESTAMP topics will no longer be allowed to go back in time for data originating from the same DataWriter. Each individual instance with samples originating from the same source becomes effectively "eventually consistent". |
| OSPL-14233 | For the RT networking service, allow the use of the loopback interface. Specifying the loopback interface in the configuration of the networking service does not work. When selecting the network interface to be used, the networking checks if the interface is multicast capable which is normally not the case for the loopback interface. Therefore the networking service will ignore the configured loopback interface and select the first multicast capable interface. Solution: When the networking configuration specifies to use the loopback interface, it will accept this interface without checking if it is multicast capable. When using the loopback interface to communicate between networking instances on the same node, it is necessary for the GobalPartition address to be a multicast address and that EnableMulticastLoopback is enabled (which is the default). |
OpenSplice v6.11.2p4
| Report ID. | Description |
|---|---|
| OSPL-14557 / 00021626 | A memory leak may occur when using a dataview. When performing a read or take on a dataview the read operation walks through the instance table associated with the view and temporarily increments the reference count of that instance. After processing this instance the reference count is not decremented which cause the memory leak. Solution: Release a dataview instance after it has been accessed by a read or take operation because the read or take increase the reference count of the instance. |
| OSPL-14621 / 00021673 | Reader instance of a reader which uses a content filter may leak. When a content filter is used samples that do not match with the filter will not be injected in the reader. However when a sample is received and before the filter expression is evaluated the reader instance that corresponds with this sample is searched for in the reader administration. When that instance is not found a new reader instance is created and inserted in the reader administration. Then when the sample does not pass the content filter the newly created empty instance will leak. Solution: When a content filter is used check before creating a reader instance if the received sample passes the content filter. |
| OSPL-14683 / 00021723 | A take/read_next_instance on a dataview may incorrectly fail. The take/read_next_instance on a view will loop through the view instances until it finds an instance and sample that passes the provided instance- and sample-mask. However before checking if a sample matches with the provided instance mask the state of the sample is already changed. For example, it has been set to read before the check on the instance mask is performed which indicates that the sample does not match. Solution: When performing a take/read_next_instance operation on a view first check if the instance passes the provided mask. |
| OSPL-14694 / 00021729 | Rank values and GenerationCount values of SampleInfo object in isocpp2 are always set to 0 The attributes in the rank() object and generation_count() object in the SampleInfo of the ISOCPP2 API were always set to 0, even in cases where they should have been > 0. This was caused by the Reader modifying a copy of the object instead of its original value. Solution: Instead of obtaining a copy of the rank() object or generation_count() object and modifying its attributes, we now instantiate a new rank() or generation_count() object and set that directly into the SampleInfo. |
OpenSplice v6.11.2p3
| Report ID. | Description |
|---|---|
| OSPL-14714 / 00021756 | Ddsi discovery of remote entities may fail after an asymmetrical disconnect. The ddsi discovery protocol of readers and writers is using transient-local semantics. When an asymmetrical disconnect occur caused by massive packet loss it may occur that a transient-local reader does not receive all the data of the corresponding transient-local writer because the writer did not noticed the disconnect and assumes that all readers have received all the data and does not sent a heartbeat. However the asymmetrical disconnected reader does not send an acknack to retrigger the transient-local realignment because a heartbeat from the writers was already received before the asymmetrical disconnect occurred. Solution: A reader keeps asking for data (send acknack) when it detects that is has not received all the data with a configurable interval which is 1s by default. |
| OSPL-14407 / 00021529 | A master conflict may cause two successive alignment to occur. When a master conflict occurs and an other node becomes master. At a node that is an alignee for the correspond namespace the resolution of the master conflict will result in alignment requests being sent to the new master. The new master will issue alignment request to other present aligners of the namespace because it may not have the complete state when it became the new master. After the new master has received all the relevant data from the other aligners it will raise the state of the namespace. This causes a native state conflict at all the alignees which will then again request alignment data from the new master. When the master would answer the first alignment request after it has received the alignment data from the other aligners it would not be necessary for the alignees to perform an additional alignment request when detecting the native state conflict. Solution: When a master conflict results in a new master the new master will delay answering alignment request until it has received the alignment data from the other aligners. When resolving a native state conflict a node will check if it already has received alignment data from the new master that was collected after the new master had raised the state of the corresponding namespace and when that is the case consider the native state conflict solved. |
| OSPL-14606 / 00021668 | Durability incorrectly discards a native state conflict when receiving a namespace's message out of order. A durability protocol message could be received out-of-order. In this case, an old namespace message gets processed after a namespace message from the master node, indicating a state change which would normally generate a native state conflict. However, the processing of the old namespace message causes the namespace state to be reset, which causes the native state conflict to be discarded. Solution: The durability service discards messages which are older than the last handled message. |
| OSPL-14610 / 00021670 | Disposed instance my be revived as result of a durability alignment. When an instance is disposed and unregistered the take operation may remove the instance from the reader cache. A retention period can be configured to keep the instance present for some time after the take operation. The reader instance maintains some information about the last sample that was taken. This to prevent that old samples may be received again. However when a dispose message is received followed by an unregistration message the unregistration message will purge the dispose message from the reader cache without recording the write time of the dispose. In this case approximately at the same time a durability alignment was being performed and the alignment data did not contain the dispose and unregister messages because the alignment snapshot was take just before that these message were written. This may cause that when the durability service injects the data using a replace policy, which purges the reader instance using the time of the snapshot, injects an old sample again in the reader instance making it alive again. Solution: When a dispose message is pushed out a reader instance because of the reception of an unregister message the write time of the dispose message must be recorded in the instance to prevent older samples to update the reader instance. |
| OSPL-14633 / 00021683 | OpenSplice Tuner does not correctly show query details In a long standing regression (nearly a decade), OpenSplice Tuner has not displayed the 'expression', expression 'parameters' or 'instance', 'sample' or 'view' states associated with the query object. This was last known to work in release 6.4.3p17. Solution: The display of these details has been corrected, with the exception of expression parameter values, which cannot be easily retrieved from the internal structures of OpenSplice. |
| OSPL-14637 / 00021655 | The durability service may remain in the incomplete state after handling the last conflict. When the conflict queue becomes empty, the durability service marks the transient store as complete. A race condition could cause a conflict which is processed very fast to incorrectly not set the complete state. Solution: The setting and resetting of the complete state is protected by a mutex lock. |
| OSPL-14641 / 00021692 | A problem in the networking service may prevent messages to be delivered to readers. When detecting a fellow node, the networking service sends a sync message communicating the expected sequence numbers. The receive side of the networking service does not forward received message until this sync message is received. The sending side schedules a timer to resend the sync message when no acknowledgement is received. In this case this timer could also be cancelled when receiving an acknowledgement for a normal data message (expected sequence number). This could cause that the receiving node to never receive the sync message. Solution: The sync message resend timer is only cancelled when receiving a sync acknowledgement message. |
| OSPL-14643 / 00021689 | Wait_for_historical_data on a transient-local reader fails when there exists a transient-local writer which has not sent data. When an application creates a second transient-local reader some time after the first reader was created and there exists a transient-local writer in the system, then the wait_for_historical_data call on the second reader may fail because it determines that the last sequence number received by the writer is still 0. However, when the administration shows that the writer had responded with a heartbeat indicating that no data was available previously, then the second reader should set it's state in sync with the writer. Solution: When a transient-local reader is created which matches with a transient-local writer that has not sent any data yet and a heartbeat of that writer was received before, then set the reader in sync with this writer. |
| OSPL-14666 / 00021711 | Java Exception in OpenSplice Tuner when viewing Query 'Data type' details In OpenSplice Tuner, if you select a Query object, and view its details, and then switch to the 'Data type' tag, a Java exception will occur. Solution: The exception has been corrected, and the 'Data type' tag now correctly displays the data type of the Topic associated with the Query. |
| OSPL-14667 / 00021710 | At startup of a node, the durability service may perform an unnecessary alignment with the master. The durability services communicate the state of the namespaces with each other. In this information, the master node indicates the current state of the namespace. When a client node detects that the state of the namespace has been changed (increased), it will raise a native state conflict which will result in an alignment action with the master. Initially, the client sets its own namespace state to 0. At the moment the durability service becomes complete, it sets the state of the namespace to the state of the master. At startup of the client, the namespace state of the master is probably already higher than one. This may cause the client to incorrectly determine that a native state conflict has occurred and starts an extra alignment with the master. Note that this alignment is unnecessary because the client node already had performed, or will perform an alignment action, which is performed when the durability service starts. Solution: When the durability service receives the first namespace information message from a fellow, it will maintain information about the fellow namespace state. When checking if a native state conflicts, it will compare the initial namespace state received from the master with the current state and only raise a native state conflict when the current master namespace state has been increased. |
| OSPL-14671 | Insertion of historical data which have the synchronize flag set result in unnecessary acknowledgements. When receiving a message which has the synchronize flag set, which indicates that this message is written by a synchronous writer, an acknowledgement is sent. This happens also when the durability service injects historical data. This may cause a storm of these acknowledgements to be sent. This may cause a network overload to occur when several nodes are aligned with this kind of data at the same time. Solution: Acknowledgements are not sent when injecting historical messages which have the synchronize flag set. |
| OSPL-14693 / 00021738 | Network initial synchronization with a newly detected node may fail. When the networking service detects a fellow node, it will send a sync message which indicates the next packet sequence number that will be sent. However older packets may already been received by the fellow node which will then acknowledges these packets. When receiving an acknowledgement, the sending node should populate the resend list associated with the fellow with the packets that are not yet acknowledged. This does not occur when the expected packet sequence number indicated in the sync message has not yet been sent. Solution: When a node receives the first acknowledgement from a fellow node and the acknowledged sequence number is acceptable (not too old), then the resend list is populated with the packets that are sent later but not yet acknowledged. |
| OSPL-14713 / 00021525 | Simulink integration functions idlImportSl and idlImportSLWithIncludePath fail if an output directory is specified. Both idlImportSl and idlImportSLWithIncludePath accept an optional final argument 'outputDirectory'. When a caller provides this parameter, the resulting call to the IDLPP processor will fail, resulting in the function failing. Solution: The order of arguments passed to IDLPP has been changed to prevent the failure. |
| OSPL-14725 | Multidomain support on windows broken when using the ospl tool. When using ospl start to start multiple domains on windows the ospl tool kills the already running domain. Solution: The ospl tool has been fixed so it can now start multiple domains again. |
| OSPL-14726 / 00021760 | Instances may not be disposed after durability master switch. When a conflict is created, the "kernel groups" (transient store) is set to the INCOMPETE state. When all conflicts are resolved and the conflict queue becomes empty, the conflict resolver sets the "kernel groups" back to the COMPLETE state. When the transient store is in the INCOMPLETE state then purging of the transient store will be disabled. When an instance is disposed and unregistered the instance will be purged from the transient store after the service_cleanup_delay has expired. In this case, the service_cleanup_delay is set to 0. Thus the instance may be purged immediately when it gets disposed and unregistered and the transient store is in the COMPLETE state. In this case, it seems that the durability service detects a master conflict which should set the transient store in the INCOMPLETE state. However, just before that event, the conflict resolver has determined that the conflict queue became empty and will then set the transient store to the COMPLETE state. Due to a race condition between the thread that raised the master conflict and the conflict resolver which sets the transient store in the COMPLETE state, it may occur that the transient store remains in the COMPLETE state while the durability service is performing an alignment as a result of the master conflict. When at the master node, an instance is being disposed and unregistered just after the alignment request from the client node and the dispose and unregister are received at the client node, before the durability service at the client node injects the alignment data which does not contain the dispose and unregister. In that case, the instance may be purged from the transient store before the alignment data is injected, which causes that the instance becomes alive again. An existing reader will not notice this but a late joining reader will see the instance incorrectly alive. Solution: The conflict administration is locked when the durability service sets the transient store in the complete state. |
OpenSplice v6.11.2p2
| Report ID. | Description |
|---|---|
| OSPL-14625 / 00021610 | Alignment issue causing corrupted builtin-topic data when accessed by the CSharp language binding Mis-alignment with native C structure of QoS policies causing corruption of, for example, the PublicationBuiltinTopicData, leading to invalid values in other members of the struct. Solution: An internal array was marshalled based on its size in bytes instead of its number of elements. This was resolved by fixing the relevant code in idlpp responsible for the CSharp code binding generation. |
| OSPL-14578 / 00021638 | Possible crash when deleting multiple DataReaders with ordered-access QoS. A DataReader with ordered-access QoS shares some administration with its subscriber. When multiple DataReaders exist for the same subscriber, deleting one DataReader would leave behind some administration causing a crash when subsequent DataReaders are deleted. Solution: The code to remove a DataReader was updated to handle this case correctly. |
| OSPL-14628 / 00021666 | Samples with topic-scope coherent presentation QoS not correctly processed by DDSI service. An issue with the identification of (remote) writers with a coherent topic-scope QoS, can cause samples to not get delivered to a matching reader. This occurs only for remote writers when the DDSI2 network-service is used. Solution: The issue was fixed in DDSI2 by setting the correct identification on the incoming data, so it is correctly processed when delivered to local readers by the OpenSplice kernel. |
| OSPL-14693 / 00021738 | Network initial synchronization with a newly detected node may fail. When the networking service detects a fellow node, it will send a sync message which indicates the next packet sequence number that will be sent. However older packets may already been received by the fellow node which will then acknowledges these packets. When receiving an acknowledgement, the sending node should populate the resend list associated with the fellow with the packets that are not yet acknowledged. This does not occur when the expected packet sequence number indicated in the sync message has not yet been sent. Solution: When a node receives the first acknowledgement from a fellow node and the acknowledged sequence number is acceptable (not too old), then the resend list is populated with the packets that are sent later but not yet acknowledged. |
| OSPL-14700 / 00021749 | Listener thread priority policy mix up in ISOCPP2 API When using ISOCPP2 and setting a thread priority policy to SCHEDULE_TIMESHARING, the actual result was that it was set to SCHEDULE_REALTIME, and when setting it to SCHEDULE_REALTIME it was set to SCHEDULE_TIMESHARING. Solution: The thread priority policy mechanism has been adjusted to set to the actual chosen priority. |
OpenSplice 6.11.2p1
| Report ID. | Description |
|---|---|
| OSPL-13974 / 00020849 | A node configured with master priority 0 may cause an unwanted master conflict to be raised. A node which is configured as aligner and with master priority 0 will become master of the corresponding namespace when at that moment no master with a higher priority is available. When a node with a higher master priority is selected as master, it will notify the other nodes after the master selection. However a namespace message sent by the node that has master priority 0 before it has received the information of the new master may raise an unnecessary master conflict which may cause an unnecessary alignment action to occur. Solution: Namespace message from a node that has master priority 0 will not cause a master conflict to be raised at other nodes. |
| OSPL-13958 / 00020837 | On termination of the durability service, a fatal error may occur when cleaning up resources. The durability service contains listener threads which listen to events and action threads which perform some action. The action threads are associated with a particular listener but may access resources of other listener threads. When the durability terminates, first all the listener threads are stopped and then the resources related to these listener threads are freed. However the action threads are stopped later and could still try to access the resources of a listener. In this case an action thread tries to take a mutex which is already freed, causing an abort. Solution: The action threads are stopped when the associated listener thread is stopped. This prevents that the action threads are still running when the resources are being freed. |
| OSPL-13963 / 00020842 | A delayed durability message may cause that a non-responsive fellow incorrectly is considered alive. When the networking service detects that a node has become non-responsive it will notify this and the durability service will mark the fellow durability service as non-responsive. However it may occur that there are still messages from that fellow durability services still queued either in the networking service or in the reader caches of the durability data readers. When such a message arrives after the fellow has been declared as non-responsive, the fellow is considered alive again, but obviously does not respond and this may cause that the durability service does not become complete. Solution: When a durability fellow is detected to be non-responsive it is placed on a black list for some time and when the durability service receives a message from that fellow durability service, it will check if this message was issued before the fellow was marked as non-responsive. If the message was issued before the time the fellow was marked as non-responsive the message is ignored. |
| OSPL-14012 / 00020823 | Tester: Old browser nodes not removed even when "Show disposed participants" is unchecked. Items representing disposed entities in the tree view of the Tester "Browser" tab are not removed even when the "Show disposed participants" option is cleared. Instead, these tree items are displayed with an orange background. Solution: Tester has been updated to remove these nodes from the tree view, when the "Show disposed participants" option is cleared. |
| OSPL-14172 / 00021015 | All nodes switch continuously from COMPLETE to INCOMPLETE with DMPA enabled. When receiving an update of a namespace from a fellow, the master priority field is not copied to the existing namespace information from that fellow. Solution: The master priority contained in a received namespaces' message is updated in the corresponding namespace information which a durability service maintains for each fellow. |
| OSPL-14221 / 00021067 | The Replace merge may incorrectly remove newer samples from the reader. The replace merge policy uses the timestamp of the request to determine which samples have to be replaced and which instances have to be disposed. However this may cause an incorrect result when newer samples are written after the time of the request but before the aligner has made the snapshot of the data to be aligned. This may also occur when the clocks of the aligner and the alignee are not sufficiently synchronized. To solve this problem the time of the snapshot should be used. Solution: The snapshot time is added to the final alignment message. At the aligner, this snapshot time is used to when applying the Replace policy. |
| OSPL-14255 / 00021085 | In certain circumstances BY_RECEPTION_TIMESTAMP topics (including the builtin topics) may go back in time. BY_RECEPTION_TIMESTAMP topics (this includes all builtin topics that are BY_RECEPTION_TIMESTAMP according to the DDS specification) would always append newly arriving samples to the end of their corresponding instance queue. This would allow them to go back in time if samples would ever be receiver out-of-order. One particular scenario where this could wreak havoc is when builtin topics that are aligned using either durability/dlite (this for example the case when using native networking, where the builtin topics do not get aligned as part of the networking protocol) get disposed before the transient snapshot (in which they are still included) arrives. So in a case like that, you first get a DISPOSE message from a DCPSPublication through the live networking path, followed by the sample preceding it from the transient snapshot, which would result in the DCPSPublication representing a particular Writer ending in the ALIVE state instead of in the DISPOSE state. This could cause Readers to assume there still is at least one ALIVE Writer while in fact there is not, causing their data to stay ALIVE even when this is incorrect. Also mechanisms like the synchronous reliability do not work correctly in scenarios like that: if a DCPSSubscription represents a synchronous Reader then the writing side can be fooled into believing there is still a Reader that needs to acknowledge its data, when in fact this Reader has already left the system. The writing side will then block waiting for an ack that will never be sent, effectively blocking the Writer application indefinitely. Solution: BY_RECEPTION_TIMESTAMP topics will no longer be allowed to go back in time for data originating from the same DataWriter. Each individual instance with samples originating from the same source becomes effectively "eventually consistent". |
| OSPL-14256 / 00021086 | The reception of an old durability message from an already deceased fellow could cause the durability service not to become complete. When a remote node terminates, the networking service will notify the durability service through the heartbeat mechanism. The durability service will then remove this fellow from its administration. However it could be that old durability messages are still queued either in the networking service or in the durability reader cache. This could cause that the durability service thinks the fellow is alive again, which may cause that the durability service waits indefinitely for a response from that fellow. Solution: When the durability service receives an indication that a fellow has died, it will maintain some information about that fellow for some time and mark the timestamp that the fellow has died. When receiving a message from that fellow, it compares the receive timestamp of that message with the recorded timestamp to determine if the message was old or came from a reconnected fellow. |
| OSPL-14331 / 00021192 | With RT networking, high packet loss may cause that all the configured bandwidth is consumed by resending packets. When there is high packet loss or a node is non responding, then the resending of packets will reduce the available bandwidth for normal traffic. As packets are resent point to point, it may be useful to have a configuration option that specifies the bandwidth available for resends, which is not accounted in the total available bandwidth, to allow resends to have less impact on normal traffic. Solution: The MaxResendBurstSize option is added to the configuration to allow, in combination with the ResendThrottleLimit, control of the bandwidth available for resending packets without effecting the available bandwidth for normal traffic. |
| OSPL-14357 / 00021504 | When the durability service detects a large number of fellows in a short time interval the total time to become complete again is longer than necessary. When a durability master detects a new fellow that is an aligner for the namespace, it will issue an alignment request to that fellow. During that time the transient store will be in the incomplete state and return to the complete state when the alignment data has been received. When a large number of aligners connect in a short time interval, each aligner will be handled one by one, which causes the total time to become complete again to be long. By combining the alignment actions to all these aligners, this would reduce the time the transient store will be in the incomplete state considerably. Solution: When a durability master detects more than one aligner connecting within a certain interval, the resulting alignment actions are combined into one. |
| OSPL-14361 / 00021506 | The FellowGarbageCollectionPeriod durability configuration parameter is incorrectly ignored. When parsing the configuration file, the xml path to the FellowGarbageCollectionPeriod parameter is wrong, causing the value to be ignored. Solution: The code correctly parses the FellowGarbageCollectionPeriod parameter. |
| OSPL-14373 / 00021511 | Add a check to terminate the durability service when not making progress. When the durability service detects a conflict, the state of the durability service is set to incomplete. As a security measure it should be possible to terminate the durability service when resolving the conflict does not make progress and the durability service remains in the incomplete state. For that purpose, it should be possible to set a timeout on the time to resolve a conflict. When that timeout expires the durability service should terminate with a fatal error. Solution: The configuration parameter ConflictResolutionTimeout has been added, which enables the user to set a maximum timeout on the resolution of a conflict. When this timeout expires, the durability service terminates with a fatal error. |
| OSPL-14442 / 00021561 | A crash may occur when using the DataReaderView. There appears to be a race condition between operations on the DataReader and an associated DataReaderView. When a sample is purged from the DataReader it will also be purged from the associated DataReaderView which may interfere with a read or take operation in the DataReaderView. Solution: Extra locking is added when performing purge operations from the DataReader on the associated DataReaderView. |
| OSPL-14448 / 00021564 | An instance may be incorrectly removed by durability when applying a REPLACE merge. When durability applies a REPLACE merge, it uses the snapshot time when the aligner had made the snapshot of the alignment data. The aligner included the time of the snapshot in the alignment data sent to the requester. When applying the REPLACE policy, the snapshot time is converted to a local which is used to purge the transient store of the relevant data. When an application at the aligner has written a sample just after the aligner had made the snapshot and this sample arrives before the alignment data, then this sample may incorrectly be purged from the transient store because of the inaccuracy in the conversion from the snapshot time, which was the wall clock time at the aligner at the moment the snapshot was made to the local time which is using a monotonic clock source. Solution: The REPLACE merge uses the snapshot time which was included in the alignment data directly to purge the transient store instead of converting it first to a local time. |
| OSPL-14477 | The dispose_all function may interfere with a REPLACE or CATCHUP action performed by durability. The dispose_all functionality and the REPLACE and CATCHUP actions performed by durability use a common resource stored in transient store which is used to dispose the relevant instances. When a dispose_all is performed during a REPLACE of CATCHUP action the dispose_all may overwrite this information which may cause the result of the REPLACE or CATCHUP to be incorrect. Solution: The dispose information used by the REPLACE or CATCHUP policy is maintained by the durability service and not temporarily stored in the transient store. |
| OSPL-14527 / 00021594 | Segmentation fault in WaitSet_wait The DDS_WaitSet_wait will crash when the condition sequence maximum is set but the buffer and the length are 0. Solution: The maximum size of the condition sequence is set to 0 when the sequence buffer is null. |
| OSPL-14538 | Sample may be permanently lost when rejected locally When a DataWriter tries to transmit a sample, it will try to deliver it in the following order: 1. The local Durability Service (when the data is TRANSIENT or PERSISTENT). 2. to the local DataReaders. 3. to the network services If the sample gets rejected in any of these steps, it will need to be retransmitted by the Writer to the rejecting entities until it is successfully received by all entities. However, a problem occurs if a sample gets rejected in steps 1 or 2, because in that case it will skip the third step as well. In such a scenario, the resendManager will attempt to retransmit the rejected sample to the rejecting entities in steps 1 and 2, but not to the networks in step 3, because technically they did not even get a chance to reject the sample, because they were skipped altogether. This causes the sample to not be transmitted to any other nodes, resulting in an inconsistent system state. Solution: A sample that is rejected by the local durability service will skip all other entities but gets retransmitted to all categories by the resendManager. This is to enforce eventual consistency between nodes where data that cannot be aligned can also not become available to other local entities. A sample that is rejected by the local DataReader(s) will be allowed to be delivered to the network services, but gets retransmitted only to the local DataReaders. |
| OSPL-14553 / 00021620 | The networking service option to send some durability messages point-to-point may cause message loss. When enabling the networking service option to improve durability message communication to send durability message which are sent to one particular fellow, may cause durability messages to be lost causing the durability service to fail. When using this option, durability messages may arrive at the durability reader out of order because now point-to-point and multicast message use different networking partitions. A change in the handling of messages by a reader which uses by reception timestamp causes that messages from the same writer are also checked on sequence number. Messages with sequence number out of order are rejected. Solution: When the networking service may use point-to-point communication for durability messages, the networking service will reorder the received durability messages by assigning increasing sequence number to the received messages. |
| OSPL-14554 / 00021621 | Durability doesn't resolve master conflict after the stop of several nodes. The durability service monitors the system heartbeat of other nodes to detect if a fellow node is alive. Both the spliced daemon and the networking service update the system heartbeat associated with remote nodes. It appears that there is a race condition between the update of this system heartbeat by the networking service and the spliced daemon. A reset of a reliable channel in the networking service may cause that the networking service unregisters the corresponding heartbeat and then writes it again. When the spliced daemon reacts on the unregister of the heartbeat by disposing the heartbeat the durability service may receive the dispose after the alive heartbeat written by the networking service. This causes that the durability service does not detect when the remote node at some later time terminates. When this happens during an ongoing alignment the durability service may stay waiting indefinitely. Solution: The garbage collection performed by the spliced daemon when a remote node terminates is directly triggered by the not alive state of the corresponding system heartbeat without first having to dispose this heartbeat. |
| OSPL-14564 / 00021633 | When several nodes restart the durability alignment takes too much time. During initial alignment the durability service will receive group information for the running nodes. To be able to align these groups the groups have to be locally created. For that purpose either a local application should have created the group or the corresponding DCPSTopic should be locally present to enable the durability service to create the group. In this case the running nodes are configured with master priority 0 which causes that the durability service does not initially ask the present nodes for the builtin topics available to them. This may delay the initial alignment of that node because it has to wait for the presence of the DCPSTopic. Solution: The master of the builtin namespace initially sends alignment requests to already running nodes including nodes configured with master priority 0. |
| OSPL-14570 | Syntax error in MATLAB class Vortex.Topic An extra parenthesis is present in the MATLAB class Vortex.Topic which causes a compilation error when the class is used from a MATLAB script or class. Solution: The error has been fixed. |
| OSPL-14580 / 00021621 | Durability incorrectly uses the sample insert time to check if a sample is outdated. When a fellow node stops, the durability service might still receives message from that fellow which could make the fellow incorrectly alive again. For that purpose, some information about a deceased fellow is retained for some time. To check if a message is outdated, the insert time of the sample is used - this is incorrect. It would be better to use the allocation time because the allocation time is set just after it has been de-serialized. Further messages which are inserted after the durability service detects that a fellow has gone are queued for some time, because they may belong to a new lifecycle of the fellow. The function to check if a sample is outdated incorrectly returns true when it cannot find the fellow. Solution: The allocation time of the a received durability message is used to determine if the message is outdated. |
| OSPL-14591 / 00021604 | DBMS Connector does not receive Exclusive Ownership messages If a topic has its Ownership QoS set to Exclusive then any message using this topic is not read by the DBMS Connector. Therefore no row is added to the database. Solution: The DBMS Connector code copies the QoS from the found topic to add to the DataReader used to read the messages. The ownership QoS was not being copied to the DataReader QoS and so only the default ownership value (Shared) was accepted. |
| OSPL-14602 | Deadlock in Durability during termination During termination of durability, the service can end up in a deadlock when an action is present in the actionQueue. During termination of durability, all the actions are removed from the actionQueue. When doing this, the action is executed one last time, but in the case where durability is already in terminating state, the execution of the action can cause durability to deadlock. Solution: A check is added to not execute any action when durability is in terminating mode, as the action has no use to run at this stage. |
| OSPL-14462 / 00021578 | Missed Heartbeat info log message missing on disconnect When a node is disconnected a Missed Heartbeat for node xxx message was written into the ospl info log. This message was removed for performance reasons resulting in users being able to detect disconnects by scanning the info log file. Solution: A new Disconnect detected for node xxx message is now written to the info log file once a disconnect is detected. |
OpenSplice 6.11.2
| Report ID. | Description |
|---|---|
| OSPL-14132 | Limit the number of builtin topics that a non-master will align to the durability master. The durability service that becomes the master of the builtin namespace has to acquire a total view of the builtin topics that exists in the system to enable the master to align each node. For that purpose when the master detects a new fellow it will request the builtin topic from that newly detected node. For the builtin topics that correspond to DDS entities except topic (DCPSPartition, DCPSSubscription, DCSPPublication, etc) it is only needed to align the master with those samples that correspond to entities on the node itself. Solution: When receiving an alignment request for a builtin topic group and the node is not the durability master for that namespace return only those samples that correspond to locally created DDS entities. This does not apply to DCSPTopic. |
| OSPL-11051 / 00018443 | ddsi2e may crash when more than 2 to the power 24 entities are created. ddsi uses 24-bit entity ids. These entity ids should wrap around, but fail to do so. This causes the function to allocate a fresh entity id to fail when it has reached 2^24 entity ids. Subsequent dereferences of this entity id can cause a crash. Solution: Entity ids can now roll over, allowing reuse of slots of previously freed entities. |
| OSPL-13932 / 00020817 | Resurrection of fellows by processing outdated namespaces Durability services exchange namespaces with each other. There is a time window where a durability service (say A) receives a namespace from another durability service (say B), but before this message is processed durability service B becomes non-responsive. Because B becomes non-responsive, A will remove B from its administration. If a little later the pending namespace message from durability service B is processed by A again, then A will resurrect B. This is undesired, because B is not around anymore. Solution: A mechanism has been implemented so that A remembers the time when B became non-responsive. A uses this time to determine whether the namespace that it processed is outdated or not. |
| OSPL-13996 / 00020855 | Provide an option to the durability service to allow alignment data to be injected atomically in the data reader . When the durability service applies the replace policy it will purge an instance on the first sample that is injected, followed by the remaining samples of the same instance. Thus the reader could be triggered by each individual sample that is injected by the durability service. For example, in case the instance is already disposed and the alignment data still contains both a valid sample and a disposed sample, then on the injection of the valid sample the instance will become alive again because the sample replaces the contents of the instance and somewhat later the disposed sample is injected by the durability service making the instance disposed again. Note that this behavior is a consequence of using the replace policy. In case this behaviour is not desired, an option has to be provided that allows the injection of the alignment data in the reader cache to be atomic. Solution: The option InjectMode with the value Blocked or Unblocked is added to the durability configuration to allow alignment data to be injected atomically in a reader or not. By default this option is set to Unblocked mode. |
| OSPL-14102 / 00020939 | Abrupt reboot on a node may cause high latencies when using RT networking. When the networking service does not receive the shutdown notifications of a remote node, for example when that node crashes, then a reliable channel will continue resending to that node until either the discovery heartbeat times out or the max retries is exceeded. This may cause that the other nodes experience long latencies because the resend will leave less bandwidth for normal traffic. Solution: When no acknowledgements are received from a node for some time, the number of resends is reduced to that node until acknowledgements are received again. The configuration parameter MaxAckDelay specifies the maximum expected acknowledgement latency. When this threshold is exceeded the number of resends is reduced. |
| OSPL-14124 | Allow the durability service configured with master priority 0 to detect a master conflict with a higher priority master at an earlier stage. When a durability service is configured with master priority 0 it will become locally master when there is no durability service with a higher master priority present. When a node with a higher master priority has selected itself as master than the durability service, a lower master priority should detect a master conflict which should then resolve to the new master. A condition for raising a master conflict is that the conflicting master has passed a certain state. However when the node with the highest master priority becomes master, it is still in a state that does not raise a master conflict, which causes that master switch at the node that loses mastership to be delayed, which may cause unnecessary alignments to occur. Solution: When using master priorities to select a master then a master conflict is raised when the node that caused the master conflict is either in the master selection state or in a higher state. |
| OSPL-14139 / 00020976 | Simulink: Usage of 'strnlen' in 'dds_participant_wrapper.c' file prevented code compilation. In the OpenSplice Simulink API, the usage of 'strnlen' in the 'dds_participant_wrapper.c' file prevented the compilation of the generated code of Simulink models. Solution: The problem is now fixed. |
| OSPL-14142 / 00020979 | The setting of InProcessExceptionHandling is ignored when handling an exception signal asynchronously sent. When handling a signal, the signal handler classifies the signal in three categories, which are exit signals, asynchronous exception signals and synchronous exception signals. The InProcessExceptionHandling parameter determines the behavior when handling an exception signal. The problem is that the setting of this parameter is ignored when handling an asynchronous exception signal sent from outside the process and handles it as if it was an exit signal. Solution: The signal handler handles both exception signal categories the same way. |
| OSPL-14143 / 00020978 | An asymmetrical disconnect may cause the durability service to crash. The durability service detects an asymmetrical disconnect when it receives an unexpected capability message from a fellow. In this case, the durability service will remove all namespace knowledge about that fellow. However, a race condition exists when another thread is currently processing a namespace message from that same fellow. Solution: The thread that handles namespaces messages is not allowed to access the stored namespace information without the mutex lock. |
| OSPL-14148 / 00020988 | Memory leakage caused by messages no longer being freed after alignment. After a reconnect between nodes and after alignment, the new catchup mechanism will visit instances and messages to evaluate if anything needs to be removed because is has been disposed and purged during disconnect. While visiting messages the refcount is increased but afterwards never decreased and that leads to leakage of messages. Solution: Increasing the refcount is actually not required and is removed. |
| OSPL-14149 | Configured catchup does not work for Dlite Due to invalid handling of the specified catchup directive the configuration had no effect. Solution: The bug is fixed and a regression test is implemented. |
| OSPL-14151 / 00020989 | In RT networking the synchronization of sequence number between sender and receiver may fail after a reconnect. When one node decides that another node has not responded in time, then it will force a disconnect followed by a reconnect when it receives a new message from that node. The reconnect will cause that a sync message is sent to the other node. Because the other node has not noticed the same disconnect, the reception of the sync message causes a reset of the reliable communication. A problem occurs when acknowledgement messages received after the reception of the sync (reset) are handled before the reset is handled. This may cause that packets are already removed from the reliable administration which will never be resent, causing the sync message sent in response to the reset message to contain the wrong information. The acknowledgement information and reset information is notified by the receive thread to the send thread by different message queues which may cause that these messages are not handled in the correct order. Solution: The reset sync message is always handled before handling the acknowledgement received after the reset message. |
| OSPL-14152 | Potential slowing or stalling historical data alignment for Dlite When a node that wants to align other is disconnected its state known by others is not cleared. Others can potentially wrongly wait for this node to start alignment. Solution: A fix has been applied that clears the state when a disconnect is detected. |
| OSPL-14154 | Catchup wrongly disposes instances after reconnect When a node has configured catchup, it may wrongly purge/dispose instances after a reconnect. Solution: Additional information is exchanged between dlite services that fixes making wrong decisions. |
| OSPL-14156 | The catchup initiated disposeAll memory leak. A disposeAll followed by a catchup alignment after a reconnect performed by the Durability service will become a memory leak because it is removed but not freed. Solution: Add code to free the disposeAll when removed. |
| OSPL-14170 / 00021011 | The progress of the durability service is dependent on the local knowledge of the topics to be aligned. When a durability service is responsible to act either as an aligner or alignee for a particular group (partition.topic combination), then either the durability service should be able to create the corresponding group or the group should have been created locally by an application. For that purpose the associated topic information should be known locally, which is provided through the DCPSTopic builtin topic. Thus durability progress can be delayed until the DCPSTopic has been aligned or made available through an application. Note that this problem does not occur when using the ddsi service because the ddsi service will align DCPSTopic. Solution: Using the option to have the networking service align the builtin topics will resolve this issue. |
| OSPL-14175 / 00021028 | When RT networking does not directly detect that a remote node has stopped it may cause an increase of the communication latency. When a node stops, the RT networking service will inform the other nodes by sending a number of discovery heartbeats indicating that the node is stopping. However, when the node crashes or these stop heartbeats are not received then a reliable channel may try for some time to resend packets to the stopped node, depending on the configuration settings. These resends will reduce the bandwidth available for normal communication, causing extra latencies. Solution: The number of resends is reduced when acknowledgements from a node are not received within a certain time. |
| OSPL-14177 | Order of elements in XML configuration is not preserved but matters in some cases. When parsing the configuration file, the elements contained in the configuration file are stored in an arbitrary order. For most configuration elements this is not important but for some elements the order can be important. For example, the PartitionMapping element which may contains wildcards for the topic-partition selection, so the order in which the wildcard expressions are evaluated may be relevant. Solution: The order of the configuration elements is maintained. |
| OSPL-14190 | Add option to RT networking to allow the dynamic network partition feature to be disabled. To support the dynamic network partition feature, the networking service uses a number of builtin transient topics. To limit the overhead of the use of these special builtin topics, especially in systems containing a large number of nodes, it would be nice to have an option to turn this feature off. Solution: The parameter DynamicPartitionSupport has been added to the networking configuration. |
| OSPL-14191 | Add option to the durability service not to send namespace and group information for namespaces that are not configured as aligner. Currently the durability service will transmit to other fellows all the configured namespaces and all the corresponding group information. However in particular system configurations, it is not always necessary to transmit the namespaces and groups for which this durability service is not configured as an aligner. Furthermore, the builtin groups are always present and are not needed to send the builtin group information and have the builtin group information created implicitly on the detection of a fellow. Solution: The general parameter AligneeReportNamespace is added to the durability service configuration to control whether namespace and group information for which the durability service is not an aligner is sent to fellow durability services. |
| OSPL-14194 | Transient instance lifecycle state change might be missed after reconnect When you get disconnected from a Transient Writer, you expect the lifecycle states of the instances originating from this Writer to become NOT_ALIVE. Likewise, after a reconnect these lifecycle states should revert back to the ALIVE state (if the Writer did not dispose/unregister them during the disconnect, that is). However, if the Reader has already read (not taken!) the sample from before the disconnect, upon reconnection it will discard the sample meant to revive the instance as a duplicate of the sample that was already in its cache (albeit in a READ state). This will correctly set the instance state to ALIVE, but probably your Reader may not notice this since in typical use-cases Readers use the NOT_READ Mask to read data that is in the ALIVE state. In this particular example when reading ALIVE, NOT_READ data, your revived instance will not show up because it is still in the READ state. Solution: In case of a reconnect, the sample used to revive the instance will always show up as NOT_READ, even if that same sample was already READ prior to the reconnect event. This is to make sure that you will actually be notified about the lifecycle state change that your instance went through, going back from NOT_ALIVE to ALIVE. |
| OSPL-14223 | Incorrect alignment of late joiners when simultaneously being aligned and receiving live data by Dlite Alignment is based on state differences and after alignment the completeness is verified by comparing the data sequence number ranges between nodes. However, in case of continuously publishing new data the state of nodes will always be in flux, making comparison unreliable. The problem is that state exchange and alignment data exchange are two separate topics that will never reflect the same state if published at different times. Solution: The state of the aligner is no longer published separately from alignment data but is incorporated into the alignment data as one consistent set. The alignee can now merge the correct state according to the data it received. |
| OSPL-14232 | Potential instance revival bug in case of multiple Writers per instance When a reader instance is registered by more than one Writer and all its Writers get disconnected, only the last disconnecting Writer will insert a NO_WRITERS message. However, if the first Writer to reconnect is not the Writer that inserted the NO_WRITERS message, it is not allowed to insert samples older than the NO_WRITERS sample (in case of BY_SOURCE_TIMESTAMP destination ordering that is) to revive the instance back into the ALIVE state. This is wrong: since a NO_WRITERS message is only inserted when ALL participating writers disconnected, any Writer should be allowed to revive the instance. Solution: Any Writer is now allowed to revive an instance, not only the Writer that inserted the NO_WRITERS message. |
| OSPL-14243 / 00021075 | Spliced may refuse to start after non graceful termination, When spliced is non-gracefully terminated (for example by suddenly rebooting the machine without bringing spliced down first) its key file (containing all relevant details about the Domain it is hosting) stays behind. If this key-file is not removed by the user, the ospl tool used to start a new instance of spliced might wrongly assume the keyfile is still relevant and therefore refuse to start spliced if it has reason to believe the previous incarnation of spliced is still alive. Consider for example the following scenario: the ospl tool starts a spliced process with processId , and lists this processId in its keyfile. Now the node is suddenly rebooted and the old keyfile is not removed as part of the reboot process. When a new incarnation of spliced is started using the ospl tool, ospl will look at the existing keyfile, check if the listed there is active, and it refuses to start spliced under the assumption it is already running. However, the of the previous incarnation of spliced might be in use by another process after the reboot, thus the ospl tool falsely assumes that spliced is already running. Solution: The ospl tool will now not just check whether the listed in the keyfile is currently active, but also whether the process represented by the pid is actually a spliced. |
| OSPL-14251 | The networking service may crash when it receives an acknowledgement after a long delay. The networking service maintains a list of fragments for joining fellows (the late joining list). Transmitted fragments are stored in this list for some time to provide reliable communication to a joining fellow which may initially have missed a number of fragments. This late joining list may become empty when the node is not sending data and all fragments on the list have timed out. When receiving a first acknowledgement from a fellow node which has endured a very high delay, the networking service may crash accessing the empty late joining list. Solution: When handling a first acknowledgement from another node, the late joining list is checked not to be empty. |
| OSPL-14252 / 00021068 | DDSI2 udp transmit thread potentially blocking indefinitely on Windows The DDSI2 service on Windows can block and eventually get terminated due to lack of transmit-thread progress. This is due to a Windows API call that should always return but in a specific deployment reported by a customer, was observed to block infinitely. Solution: The code was changed to use a configurable timeout (//OpenSplice/DDSI2Service/Internal/UDPWriteTimeout)) which defaults to 5s. This allowed the service to work correctly in the customer-reported scenario, while still detecting unexpected or irregular delays when the timeout is exceeded. |
| OSPL-14253 / 00021081 | MATLAB: "statement is incomplete" error when topic type reference is invalid When creating a DDS Topic with the MATLAB API, you must pass the Vortex.Topic class constructor a reference to MATLAB class generated by idlpp. Typically, such a reference is created by the MATLAB "?" (question mark) operator. Note, however, that this operator silently returns an empty class array should the referenced name not be found. This could occur because of a typographical error, or because the referenced class is not in the MATLAB path. The Vortex.Topic constructor does not detect such invalid class references, and ultimately causes an exception with the text: "Error: The statement is incomplete." Solution: Argument checking in Vortex.Topic has been improved to detect the result of an invalid class reference operation, and to issue a clearer error message in this case. |
| OSPL-14263 | When the name of a DLite service exceeds 128 characters a crash can occur DLite services have a name. These names are used in the log files that are generated by DLite services. A buffer of 128 characters was internally used to contain the name. This leads to a crash in case the name exceeds 128 characters. Solution: The buffer is now dynamically allocated based on the length of the name. |
| OSPL-14276 / 00021099 | The durability service may crash when a fellow node is disconnected and directly reconnected again. Initially the role field of a fellow namespace is unset. The role is set when the first namespace's message is received from that fellow. When processing a namespace's message from a fellow and when that same fellow is disconnected and shortly thereafter reconnected, the namespace administration of that fellow is initialized again and the role field becomes unset. However the processing of the old namespaces messages expects the role field still to be valid. Solution: When accessing the role field of a fellow namespace, it is checked if this field is valid. |
| OSPL-14311 | Missing Protobuf header files In the case of an OpenSplice release without java tooling support the protobuf header files are missing from the release. Solution: The protobuf header files are now included in releases without java tooling support. |
| OSPL-14326 / 00021133 | Reliable communication stalled after an asymmetrical disconnect/reconnect when using RT networking. When a disconnect/reconnect occurs a reset message is sent to the remote entity. This reset should reset the synchronization of the sequence numbers between sender and receiver. In the case where the expected packet indicated by the reset message was received before the reset message and is still on the out-of-order list, it could occur that the out-of-order administration is not updated correctly, causing the processing of the out-of-order list to stall. Solution: When a reset message is received, update the out-of-order list correctly and possibly restart processing of the out-of-order list from the expected sequence number. |
| OSPL-14329 / 00021058 | Possible crash in repeated DDS Security plugin loading mechanism In single-process mode, creating and deleting participants causes service and plugin libraries to be loaded and unloaded on the fly. In the DDS Security plugin mechanism of the DDSI2 service, initialization code is not robust against executing more than once and could crash when the location of libraries changes between the first and second time they are loaded into the process. Solution: The initialization code of the plugin-loading mechanism was fixed to allow multiple executions, supporting restarting the DDSI2 service within the same process. |
| OSPL-14334 / 00021196 | The networking service may crash when using the option to manage the builtin topics. When handling a topic request from a fellow node and that fellow node has already been removed from the administration because it became disconnected, a trace message tries to dereference an invalid pointer. Solution: The trace message is corrected. |
| OSPL-14360 | struct and union definitions that have the same name as modules in which they are defined can cause crashes. Internal processing (deserialization) of the XML type descriptor will try to process the module as if it was the struct definition and will lead to a crash. The problem is that an internal search operation during deserialization searches the wrong scope and returns the module with the same name. Solution: The search operation is replaced by one that searches the correct scope |
| OSPL-14411 / 00021533 | DLite in combination with native networking may leak range info belonging to builtin topics. DLite keeps an internal administration of the ranges of sequence numbers it received per individual writer. If DLite is used in combination with native networking (which by default doesn't take care of aligning the builtin topics like ddsi does), this range administration includes the writers for the builtin topics. However, due to a bug in the initialization of the transient store, the tombstone_cleanup_delay was set to infinite for the builtin topics, causing their range info to never be cleaned up, effectively causing a little memory leak for every participant that leaves the system. In scenarios where participants are coming and going all the time, this little memory leak might eventually accumulate and cause the system to run out of memory. Solution: The tombstone_cleanup_delay for builtin topics is now set to 5 seconds. This means that all range info describing the builtin topics from a particular participant will be cleaned up 5 seconds after that participant leaves the system. |
| OSPL-14413 | The delivery thread of RT networking is accessing the shared memory directly without setting the protection count. When the SMP option is enabled in RT networking, a separate thread is created which writes the received sample (messages) into the shared memory. However, this thread does not set the shared memory protection count. This causes the situation that when a crash occurs when writing a sample into the shared memory segment and an exception occurs, the exception (signal) is being handled as a normal user kill exception (signal). In this case the networking service detaches from the shared memory before re-raising the exception (signal). Solution: The main part of the asynWriter (delivery) thread is run with the shared memory protection count raised. |
| OSPL-14443 / 00021555 | C API has potential issues when dealing with UserDataQosPolicy, GroupDataQosPolicy or TopicDataQosPolicy, The C API has some bugs in its handling of a sequence of octet that is used in the UserDataQosPolicy, GroupDataQosPolicy or TopicDataQosPolicy. These bugs could either cause a double free (resulting in a crash) or a memory leak when invoking get_qos, set_qos, get_default__qos or set_default__qos operations and passing Qos objects that have any of these policies set to a non empty sequence of octet. Solution: The code that handles the sequence of octet has been corrected, thus removing the potential double free and the potential memory leak. |
| OSPL-13924 | Remove hard idlpp dependency for dynamic types in Python API Added a friendly warning in the Python package installer to remind customers when idlpp is not available. Added dynamic type construction with python dataclasses (available in Python version 3.6+) for those who cannot pregenerate python classes with idlpp Solution: For customers wanting to work with dynamic types in python but who have no idlpp at runtime: take a look at tools/python/examples/example5.py for a demonstration of this. |
| OSPL-14036 / 00020881 | Added human readable timestamps in Dlite tracing Dlite tracing reports are timestamped with the internal representation of the system time (wall clock). However, to improve readability and comparison with other log files it is desired to add a human readable and standardized format. Solution: Each line is prepended with an additional representation of the timestamp with a format similar to other logfiles. |
| OSPL-14123 | Allow the option to determine the master on the durability service that first started to be applied to transient namespaces. When using master selection based on priorities and when there are several nodes which have the highest priority, then the master is chosen first on the namespace quality and then the system-id. For namespaces configured as transient, the quality will always be 0 and thus the node with the highest system-id will become master. Thus when a new node is started, it may take over the mastership of these transient namespaces which will cause new alignments to occur. However it could be preferred that in this case, the first selected master will remain the master for the namespace. For persistent namespaces there is the option to select the master based on the node that was first started in case the priorities are the same. By applying this option also to transient namespaces, it will ensure that a newly started node which has the same master priority can not take over mastership. Solution: The option to select a master based on the node that was first started is also applicable to a transient namespace. |
| OSPL-14141 | durability_migrate logging and v6.6 KV store support The additon of some more descriptive logging output and support for durability KV stores produced by the Opensplice 6.6 release is desirable. Solution: Some more descriptive logging output and support for durability KV stores produced by the Opensplice 6.6 release have been added. |
| OSPL-14298 / 00021107 | Python API: improved performance of ddsutil.get_dds_classes_from_idl when retrieving multiple topics from one idl file. The Python API function ddsutil.get_dds_classes_from_idl would re-parse an idl file for every topic type you retrieved from it. Solution: ddsutil.get_dds_classes_from_idl now caches the parsing results of an idl file. Pass the `force_reload=True` optional keyword parameter to disable this new behavior. |
| OSPL-14403 | Improve the resend mechanism of RT networking. The current resend mechanism in RT networking walks each resolution tick over all the possible packets in both the node administration and in the late joining list. This is not very efficient. Further resends are performed when an acknowledgement is not received within the time specified by the recovery factor. However, in systems where the acknowledgement latency can be very unpredictable, for example systems that are using VMs, it could be better to only perform resends when the receiver indicates that it has packets missing. An option should be added to allow the resend mechanism to operate in either mode: one mode that will perform a resend when a packet is not acknowledged within the resolution time and one mode that only performs resends when the received ack messages indicate gaps of missing packets. Solution: A time ordered queue is used to schedule the packets that potentially have to be resent when an acknowledgement is not received in time. When an acknowledgement message indicates that some packets are missing, these packets are resent first by moving them to the head of the resent queue. |
OpenSplice 6.11.1
| Report ID. | Description |
|---|---|
| OSPL-14113 / 00020953 | Idlpp for Python API creates circular dependency in the generated file. In the OpenSplice Python API, when having an IDL which has a module B inside module A and using something from module B (e.g., an enum) inside module A, it results in a circular dependency during the import of module A. Solution: The problem is now fixed. |
| OSPL-14065 / 00020912 | Incorrect inconsistency detection in the DLite differential alignment protocol. The differential alignment protocol concluded wrongly that not all data was received from writers that didn't published any data yet. This could prevent the wait_for_historical_data from unblocking which can cause numerous application issues. Solution: The protocol logic is fixed by excluding publishers from differential alignment calculations until they have published data. |
| OSPL-14128 | Race condition in management of instance lifecycle states In the 6.11.0, a new mechanism was introduced that allowed the spliced to revive instances that lost liveliness due to a disconnect when their writer was re-discovered. However, this caused a race condition between the spliced trying to revert the instance back to its state prior to the disconnect, and durability/dlite, which are trying to update the instance to its latest state. Both mechanisms should have been commutative, but in certain scenarios they were not, and this could cause the instance to end up in the wrong life cycle state. Solution: Both mechanisms are now fully commutative, and the resulting instance lifecycle state is now eventually consistent with the rest of the system. |
| OSPL-13652 / 00020635 | Add missing python API methods and ensure the subscriber partition setting is functional. Added methods to set Qos, read_status and take_status. Ensured that setting the partition on creation of a subscriber does function and included a test for this. Solution: You can now change the Qos policies of entities (but only those allowed by DDS). You can read/take status of an entity and set the partition of a subscriber by Qos, for example via the XML QosProvider. |
| OSPL-13665 / 00020647 | Issue with invalid samples when using read condition causes readers to get stuck unable to read samples. In specific cases when a reader has both instances with invalid samples and others with valid samples, if samples are read using a condition on eg. view, sample or instance states, which an instance with invalid sample(s) doesn't meet, no other instances are considered and a 'no-data' result is returned to the application. Note this applies to operations such as take_w_condition but also to conditions in waitsets. Solution: Processing instances with invalid samples contained a bug in an return code causing the implementation to stop iterating instances and return 'no-data' result to applications prematurely. |
| OSPL-13743 / 00020702 | Possible alignment mismatch when an asymmetrical disconnect occurs during alignment When nodes get reconnected after being disconnected, a request for alignment data is sent. When there is an asymmetrical disconnect AFTER the aligner has received the request but BEFORE the aligner has actually sent the data, then the alignee drops the request but the aligner does not. When the asymmetrical disconnect is resolved, the alignee sends a new request for alignment data to the aligner. It now can happen that the aligner sends the alignment data of the FIRST request to the alignee, and the alignee considers this as the answer to the SECOND request. When the alignee receives the alignment data to the SECOND request, the data gets dropped because there is no outstanding request anymore. This can lead to an incorrect state whenever the alignment set has been updated between the first and the second request. Solution: The answer to the first sample request is not considered a valid answer to the second request any more. |
| OSPL-13787 / 00020504 | Python: "dds_condition_delete: Bad parameter Not a proper condition" entries in ospl-error.log In some circumstances, the ospl-error.log can contain errors with the text "dds_condition_delete: Bad parameter Not a proper condition", even though customer code appears correct. This is due to unexpected interactions between the Python garbage collector and the underlying C99 DCPS API used by the Python integration. An attempted fix (OSPL-13503, released in 6.10.4p1) was later reverted in 6.11.0 (OSPL-13771) because it caused a memory leak. Solution: The issue has been fixed. The fix tracks implicit releases of C99 'condition handles' by tracking garbage collection of the parent DataReader class, and prevents duplicate calls do dds_condition_delete in those cases. Note that customer code can still cause an entry in ospl-error.log, but only when code explicitly calls DataReader.close() prior to explicitly calling Condition.delete(). In such a code sequence, an error message is a reasonable expectation. |
| OSPL-13869 / 00020756 | Long delay to get read and write functions result for large sequence types when using Python API When using OpenSplice Python API in the applications, there was a delay to get the results of the read and write functions for sequence types. The problem was only apparent with large sequences: ~ 1MB or so. In the Python API code, it was looping through the list in data construction, serialization and deserialization. Thus, it was taking a long time to get results back from the read and write functions for large sequence types. Solution: For sequence types, the Python API code is now updated to generate array.array in data construction and deserialization if the sequence type is supported by the built-in array module. The serialization process for the sequence types is also updated to skip the looping through of the data if it is an instance of array.array. The updated code reduces the read and write functions time for the sequence types that are supported by the built-in array module. It is essential to regenerate the code from the IDL file using idlpp in order to achieve performance improvements. The unregenerated code will continue to execute correctly. Please note that the large sequences of types not supported by the built-in array module (enum, boolean, string, char and struct types) will not see any performance improvements. |
| OSPL-13914 / 00020791 | A delay in the scheduling of the durability service threads may cause the spliced daemon to consider the durability service as died. The durability service has to report it's liveliness regular with the spliced daemon. When the durability service does not report it's liveliness within the lease period the spliced daemon considers the durability service as died. The durability service contains a watchdog mechanism to monitor the liveliness of the threads when this watchdog finds a thread non-responding the durability service will delay the liveliness notification to the spliced daemon. When a durability thread goes to sleep it informs the thread watchdog accordingly. However a high CPU load may cause that a thread sleeps longer than expected. In this case at one location in the code the sleep time reported to the thread watchdog is to small which may cause that the thread watchdog considers a thread as non-responsive when the sleep time is much longer as expected. Solution: The sleep time reported to the thread watchdog is increased to take into account scheduling delays caused by a high CPU load. |
| OSPL-13926 / 00020810 | The ospl stop command may block. When an 'ospl stop' or 'ospl stop -a' command is issued then the ospl tool will search for an associated key file(s). When the key file indicates that spliced daemon is still initializing the ospl tool will wait until spliced reports that is has become operational. This is done to prevent problems when the ospl tool tries to terminate the still starting spliced daemon. However when a spliced daemon was killed during it's startup it may leave a key file which is still indicating that it is initializing. When the 'ospl stop' command finds such a key file it will wait indefinitely. Solution: The 'ospl stop' command finds a key file indicating the initializing state it will check if the corresponding spliced daemon is still running. When that is not the case it try to cleanup the resources left by the killed spliced daemon and remove the key file. |
| OSPL-13954 | MATLAB: IDLPP generates incorrect code for sequence of structs For the Matlab language, IDLPP generated in correct code to serialize (write) a sequence of structs, resulting in an exception during sample writes. Solution: IDLPP has been updated to generate the correct code. |
| OSPL-13964 / 00020844 | Instance liveliness sometimes incorrectly set to NO_WRITERS for late joiners When a late joiner joins an already running system, the TRANSIENT samples already published by the other nodes get aligned by either durability or dlite. The alignment consists of two phases: Discovering the remote Writers Acquiring the samples that they sent. Both phases are executed asynchronously, and so you might end up receiving samples from a Writer that you did not yet discover, In that case, the samples will be inserted in the NO_WRITERS state, and the delayed discovery of their Writer will not correct for this. Solution: A Writer whose discovery is delayed will now correctly update the liveliness of instances for which samples had already been received prior. |
| OSPL-13973 | When the call to DDS_DomainParticipant_find_topic() times out no error message should be reported One of the way to acquire a topic is to call DDS_DomainParticipant_find_topic(). When the topic cannot be found within the specified duration an error message was generated in ospl-error.log. The generation of such error message is incorrect, because not being able to find the topic is legitimate behaviour. Solution: The error message is not generated any more. |
| OSPL-14049 | Serializing big samples on Windows may consume a lot of CPU when using ddsi The ddsi serializer was serializing into 8Kb blocks, reallocating to an additional block if not big enough. For very big samples this potentially resulted in a large number of realloc operations, which on Windows often resulted in memcopying one memory area into another before proceeding, consuming a lot of CPU in the process, which as a consequence was impacting the network latencies quite dramatically. Solution: Windows now uses a more efficient algorithm to reallocate memory, and the ddsi derializer now converges to its eventual size in fewer iterations. |
| OSPL-14066 / 00020914 | Improve handling of unhandled application exceptions in Windows. When an exception occurs in application code and that exception is not handled it will terminate the application. When this occurs and there are still threads busy in the OpenSplice shared memory segment then it can not always be ensured that the shared memory is still in a consistent state and in that case the spliced daemon will stop OpenSplice. For Posix systems this is handled by the signal handler of OpenSplice to protect the shared memory. Solution: For Windos an unhandled exception handler is added which tries to stop or let threads leave the shared memory segment when an unhandled exception occurs in application code. |
| OSPL-14067 | When the durability config specifies master priority selection on several namespace then it may occur that master selection does not converge. When master selection is based on master priorities then the node with the highest priority will win. However when there is more than one node with the highest priority the quality of the namespace is used to select the master. When a master is selected the node will set it's own quality to that of the master. However this quality was by mistake also set on other namespaces that use master priority selection. This could cause that master selection on some namespace became unstable. Solution: When a master has been selected for a namespace the quality of the master is copied to the corresponding namespace and not to all. |
| OSPL-14079 | When a user clock is used, the DLite service uses the user clock instead of the wall clock in their log files When a user clock is configured, the services use the user clock instead of the wall clock in their log files. Sometimes customers want to use the wall clock instead of the user clock in their logs, because the wall clock better appeals to human intuition of time. To have service log files use the wall clock instead of the user clock in their log files, the attribute //OpenSplice/Domain/UserClockService[@reporting] can be set to false. Solution: The clock that is used to report time stamps in service log files is chosen based on the //OpenSplice/Domain/UserClockService[@reporting] settings. |
| OSPL-12820 | ddsi may have problems handling big data samples DDSI breaks up samples into fragments to be able to send them over the network effectively. In case (part of) the sample is 'lost' when sending over the network, DDSI is able to resend the fragments that have been lost or alternatively the complete sample (so all fragments). For large samples, the chances of at least one fragment being lost is relatively high and given the size of the complete sample, resending it completely is very costly, let alone the chances of 'loosing' part of the resent sample again. The ddsi protocol for handling fragments does not allow the receiver to Ack individual fragments (it can only NACK missing fragments), so it is hard to notify the sender when it is sending too fast. Solution: By creatively playing with the various freedoms that the ddsi protocol allows, we can prevent ddsi from retransmitting the whole message if it is not Acked in time. This should improve throughput and overall stability of the connection. |
| OSPL-13985 | Add option to durability to prevent injecting persistent data more than once when using master priorities. When using the durability service uses master selection based on priorities (masterPriority attribute set) then it may occur that the persistent data is injected more than once by different durability services. This happens when one durability service has taken mastership on a namespace because it has the highest properties for that namespace but later another durability service is started which has better properties for that namespace and will take over the mastership of that namespace and will inject it's persistent data again. When using master selection based on priorities the properties that determine which durability service will become master are the priority and next the quality of the namespace an finally the system-id of the node. When there are several potential aligners in the system and there is no hierarchy among them then the can be configured with equal master priorities. However it then still not guaranteed that only one durability service will inject it's persistent data because now the selection is made on the quality of the namespace. I case that is not desirable an option is needed to select the master not on the quality of the namespace but on the durability service that was started first. Solution: For this purpose the attribute 'masterSelectBy' is added to the 'Policy' configuration element associated with a particular namespace. The possible values of this attribute are 'Quality' or 'FirstStarted'. When set to 'Quality', which is the default, the master selection criterium will be based on the quality of the persistent data. When set to 'FirstStarted' the master selection criterium will be based on the startup time of the durability service. |
| OSPL-13989 | Add the option to have a durability service not to advertise it is an aligner when using masterPriority=0. When configuring a namespace with masterPriority=0 and aligner=true then the durability service will act as a master for this namespace until there is no globally selected master available but it will never become master for other nodes. However it will still advertise itself as an aligner for that namespace. As an aligner for other nodes it may contain durable data that the durability service that has become the master still needs to retrieve to be able to distribute this data over the system. However is is not always desired that the master retrieves this data from the nodes that have configured masterPriority=0. Especially in systems with a large number of nodes this may reduce the initial alignment load on the system. Solution: To provide this option the possible values or the aligner attribute of the Policy element associated with a particular namespace has been extended with the value 'Local'. Thus the valid values of the aligner attribute are now True, False or Local. Note that 'Local' may only be used in combination with masterPriority=0. |
| OSPL-14022 | Set the default rate for a DLite service to publish its metrics to every 10 seconds Any DLite service can periodically publish metrics that can be received by monitoring services to assess the health of the DLite service. The default frequency was to publish a metric every 1s. In practice this is not needed and could potentially lead to unnecessary load. A 10s period seems to be a more sensible default. The default value can be overriden by //OpenSplice/DLite/Settings/metrics_interval. Solution: A DLite service now publishes metrics every 10s unless the value is overriden by //OpenSplice/DLite/Settings/metrics_interval. |
| OSPL-13345 / 00020318 | Simulink - override partition from Publisher and Subscriber blocks. In previous Vortex OpenSplice releases, the partition name was only settable through the QoS Profile that is selected in the Simulink blocks. Solution: Partition overrides are now possible on Publisher and Subscriber blocks via block parameters. |
| OSPL-13407 / 00020374 | When a user clock is used, the services use the user clock instead of the wall clock in their log files When a user clock is configured, the services use the user clock instead of the wall clock in their log files. Sometimes customers want to use the wall clock instead of the user clock in their logs, because the wall clock better appeals to human intuition of time. To have service log files use the wall clock instead of the user clock in their log files, the attribute //OpenSplice/Domain/UserClock[@reporting] can be set to false. Solution: The clock that is used to report time stamps in service log files is chosen based on the //OpenSplice/Domain/UserClock[@reporting] settings. |
| OSPL-14104 | Memory leakage of resend data on writer deletion Data published by a writer that could not be delivered because of temporary unavailability of peers is maintained by the writer in its history cache until it can be delivered. Although unlikely that resend data exists at writer deletion it will leak because the writer destructor fails to delete the data. Solution: Implemented resend data deletion in the writer destructor. |
| OSPL-14105 | Support DDSI discovery caused by multicast discovery on one side only The DDSI service sends participant discovery messages to the SPDP multicast address (if enabled), any addresses configured as peers, and any unicast addresses it added at run-time based on discovery. That third group did not include addresses of peers that advertise themselves via multicast while the local node has SPDP multicast disabled (a very non-standard but sometimes quite useful configuration). The result is that discovery could occur in only one direction and that some temporary, asymmetrical disconnections could not be recovered from. Solution: It now adds the unicast addresses of discovered peers when SPDP multicast is disabled. This ensures bidirectional discovery and recovery from all temporary asymmetrical disconnections. |
| OSPL-13502 / 00020501 | Python: Access the version number of OpenSplice in the Python dds module. In the previous releases of OpenSplice, it was not possible to access the OpenSplice version number in the Python dds module. Solution: It is now possible to get the OpenSplice version number in the Python dds module using the "__version__" attribute. Please note that if the Python code is recompiled with a different OpenSplice version, the Python dds package will still show the OpenSplice version number it originally came with. |
| OSPL-14064 / 00020913 | Service crash during startup when configuration becomes unavailable When service configuration is removed from the configuration file after starting spliced but before spliced has started the service, the service may crash due to missing configuration elements. Solution: Some extra checks and error report were added to allow a graceful termination of the service instead of a crash |
OpenSplice 6.11.0
| Report ID. | Description |
|---|---|
| OSPL-13920 / 00020795 | Node.js DCPS : Errors when importing IDL for topics using typedef references In Node.js DCPS, an importIDL api is provided to import topic types defined in IDL. The importIDL api generates xml using idlpp, then processes the xml. If the IDL included typedef references to other typedef references, the end user would see errors. The processing of the idlpp generated xml did not handle typedef references to other typedefs. Solution: The OSPL Node.js DCPS code has been fixed to handle the cases where topics defined in IDL include typedef references to other typedefs. |
| OSPL-13943 / 20692 | Durability alignment is not consistent among several nodes when using a REPLACE policy. When the durability service performs a REPLACE alignment policy the corresponding instances based on the timestamp of the alignment are first wiped from the transient store before the aligned samples are injected. When in the meantime a dispose of a DCPSPublication corresponding to some of the aligned data is handled by the spliced daemon then it may occur that these instances are placed on a purge list before the aligned samples are injected. In this case the injection of the samples will incorrectly not remove these instances from the purge list. Solution: An instance is always removed from the empty purge list when a sample is injected and the instance becomes not empty. |
| OSPL-13909 | Durability should wait for the presents of remote durability protocol readers when using ddsi. When the ddsi service is being used and in case the durability service detects a fellow durability service the durability service should wait with sending messages to that fellow until it has detected the remote durability readers. Due to some configuration parameter changes this function has mistakenly been disabled. Solution: The check for the presents of remote durability readers is enabled when the ddsi service is used as networking service. |
| OSPL-13724 / 00020481 | The Vortex.idlImportSlWithIncludePath function call of Simulink Vortex DDS blockset was causing error on Windows platform. On the Windows platform, the Vortex.idlImportSlWithIncludePath function call of Simulink Vortex DDS blockset was causing error for passing the includedirpaths argument. It is because the function was passing the arguments in the wrong order to the IDLPP tool. Solution: The bug is now fixed. The Vortex.idlImportSlWithIncludePath function has been updated to pass the arguments in the correct order to the IDLPP tool. |
| OSPL-12485 | Possible incomplete transaction when aligned by durability It was possible that a transaction was incomplete when aligned by durability as all transactional samples were treated as EOT. All transactional samples were compared as if they were EOTs which could lead to transactional samples being discarded as duplicates and not aligned Solution: Made sure only EOT messages are compared |
| OSPL-12877 | 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-13307 / 00019125 | When running mmstat -M some of the numbers created are incorrect The variables which are created by mmstat that represent a difference are output as unsigned long int. This means that negative numbers are incorrectly output. Solution: Changed the data type of variables that represent a difference from unsigned long int to signed long int to avoid incorrect output in mmstat -M. |
| OSPL-13532 | Stalling alignment when an asymmetrical disconnect occurs during the durability handshake When durability services discover each the must complete a handshake before data alignment can start. The handshake consists of a several stages: # Whenever a durability service discover another durability service it pushes a so-called Capability message to the discovered durability service. A precondition for this to happen is that the Capability reader of the remote durability service must have been discovered, otherwise the Capability message may get lost. These Capability messages are essential to detect, and recover from, asymmetric disconnects. # Once a Capability message has been received from a remote durability service it is possible to request its namespaces by sending a so-called nameSpacesRequest message (ofcourse, after having discovered the reader for this message on the remote durability service). This should trigger the remote durability service to send its namespaces, after which the handshake is completed There are two problems with the handshake. First of all, when a durability service sends its request for namespaces to the remote durability service, there is no guarantee that the remote durability service has discovered its namespaces reader at the time the namespaces are being published, so they can get lost. Secondly, and more likely, when an asymmetric disconnect occurs while establishing the handshake, it is not possible anymore to detect that an asymmetric disconnect has occurred , and therefore it is not possible anymore to recover from this situation. This will effectively lead to a situation where the handshake is not completed, and therefore alignment is stalled. Solution: There are two soutions ingeredients # When a Capability is published to a remote durability service ALL its relevant readers must have discovered iso only the Capability reader. # To resolve the stalling handshake due to asymmetric disconnects occurring during the handshake, Capability message and nameSpacesRequest message are being republished when the handshake takes too long to complete. This can be controlled using two environment variables ## The environment variable OSPL_DURABILITY_CAPABILITY_RECEIVED_PERIOD specifies the time (in seconds) after which to republish a capability. The default is 3.0 seconds. ## The environment variable OSPL_DURABILITY_NAMESPACES_RECEIVED_PERIOD specifies the time after which to resend a nameSpacesRequest. The default is 30.0 seconds |
| OSPL-13692 / 00020677 | Networking throttling may slow down communication too long. When a receiver experiences high packet loss the backlog will increase which is communicated to the sender. In that case the sender will apply throttling to reduce the load on the receiver, However throttling is also applied to the resending of the lost packets. This may cause that the backlog at the receiver decreases at a low rate causing the throttling to applied longer than necessary. Solution: A parameter (ResendThrottleLimit) is added which sets the lower throttling limit for resending lost packets. Further when the sender detects that there are gaps in the received acknowledgements resends are performed earlier. |
| OSPL-13698 | When the node causing a master conflict is disconnected before resolving the master conflict may remain unresolved. When using legacy master selection and a master conflict is detected because another node has selected a different master then the current master is directly set to pending. When before resolving the master conflict the node that caused the master conflict has been disconnected the master conflict could be dropped although the master conflict still exists and because the master is set to pending no new master conflict is raised. Solution: A master conflict is always resolved independent of the node that has caused the master conflict has been disconnected and has been removed from the durability administration. |
| OSPL-13705 / 00020691 | Provide option to the RT networking service to optimize durability traffic by using point-to-point communication. For the RT networking service, the durability service is just another application. Protocol messages sent by the durability service will therefore be sent to all the nodes in the system. The protocol messages sent by the durability service are either addressed to all, a subset or to only one fellow durability service. To limit the networking load caused by the durability service it would be beneficial when the networking service has some knowledge of the durability protocol and sent durability messages that are addressed to one fellow to be sent point-to-point. This requires that the capability to send messages point-to-point is added to the RT networking service. Solution: Support for point-to-point communication for durability message addressed to one fellow added. |
| OSPL-13748 / 00020708 | The RT networking service can run out of buffers when receive socket is overloaded. To limit the chance of packet loss to occur in the receive socket the networking receive thread tries to read as much packets from the receive socket before processing these packets further. However when the receive socket remains full the number of received packets that are waiting to be processes is increasing which may cause that the networking service will run out of buffers. Solution: When reading packets from the receive socket the size it is checked if the number of packets waiting to be processed does not exceed a threshold. When the threshold is reached the networking receive thread will first process some waiting packets before attending the receive socket. |
| OSPL-13753 / 00020714 | When installing a Visual Studio 2005 version silently a popup window appears and stops the installation The installations now ensure Visual Studio redistributables will not force a reboot of Windows before the main installer has completed by using an optional parameter when running the redistributable . This has created a problem for Visual Studio 2005 versions as this parameter is illegal and an error message is produced. Solution: An additional page has been included in the installer to allow users to not install the Visual Studio redistributable. This option can also be used when installing silently and allows a customer to skip the redistributable which creates the error condition. |
| OSPL-13756 | Provide the option to have the RT networking service perform the distribution of the builtin topics. When using the RT networking service the durability service will be responsible for alignment of the builtin topic which is not the case when the DDSI service is used. In a large system the number of builtin topics can become very large. When the networking service is made responsible for aligning the builtin topics only the own builtin topics of a node have been aligned when two nodes detected each other. Especially when a disconnect/reconnect occurs it will reduce the number of builtin topics that have to be aligned. Solution: The ability to align the builtin topics by RT networking has be added and a configuration parameter ManageBuiltinTopics has been added by which this ability can be enabled. Note to maintain similarity with the DDSI service this applies to: DCPSParticipant, DCPSPublication, DCPSSubscription, DCSPTopic and the CM related builtin topics. |
| OSPL-13771 / 00020719 | Python API: 'Out Of Resources' exceptions when using conditions and shared memory. A memory leak was introduced in 6.10.4p1. In the python class Condition, dealloc was removed, resulting in improper cleanup. This change was introduced as a fix for OSPL-13503 Cleanup error: dds_condition_delete: Bad parameter Not a proper condition. Solution: The change to remove the Condition dealloc was for a minor logging issue. This OSPL-13503 change was rolled back in order to fix the more serious Out of Resources exceptions. With this rollback, extra error messages may be logged. The memory leak for Condition is fixed. |
| OSPL-13773 | The durability service may send an alignment request to a not confirmed master. When during the master selection a master is proposed but that master is not yet confirmed and in parallel the need to align the data of a topic/partition is triggered then it may occur that an alignment request is sent to this not yet confirmed master which may not become the actual selected master. Solution: Delay during initial alignment requesting alignment of data until master selection has finished and a the master is confirmed. |
| OSPL-13781 | Allow setting the master selection protocol on each durability namespace independently. Either legacy master selection of master selection based on master priorities can be configured for the durability namespaces. When master selection based on master priority it should be configured on all the namespaces. However it should be allowed to configure the master selection protocol on each namespace independently. Solution: The global setting of the master selection protocol is removed and the master selection protocol configured for each namespace is applied when selecting a master for that namespace. |
| OSPL-13784 / 00020725 | The RT networking service the synchronization on the first expected fragment from a newly detected fellow could fail. When the networking service receives a first packet from an other node it has to determine the first sequence number of the packet that is both used by the sending node and the receiving node as the starting sequence number of the reliable communication. This first sequence number is determined either from the offset present in the first received packet or on the expected packet number indicated by the sync message when SyncMessageExchange has been enabled. The sender will then resent the packets from that agreed sequence number until the sequence number of the packet already received. In this case packets with lower sequence numbers than the sequence number of the first receive packet should be accepted. However this may fail when the first sync message is lost which may cause that packets are rejected by the receive but are already acknowledged. In that case the received will not receive the expected packet . Solution: When waiting for the sync message which sets the expected sequence number packet received with a sequence number lower than the sequence number of the first received packet are accepted and placed on the out-of-order list. |
| OSPL-13791 / 00020706 | Potential memory leak in Java5 DataReader The Java5 DataReader offers two different modes of reading data: it either returns an Iterator holding all requested samples, or you preallocate an ArrayList and pass that as input parameter to your read/take call. The latter is more efficient if you want to benefit from recycling samples allocated in the previous invocation of your read/take calls. For this purpose, the DataReader keeps track of a MAP containing for each previous ArrayLists all the relevant recyclable intermediate objects. However, if you keep feeding new ArrayList objects to each subsequent read/take call, the MAP will grow indefinitely and leak away all your previous data. Although invking the preallocated read/take calls this way is against its intended usage and design, some examples are doing exactly that. Solution: Examples have been modified not to feed new ArrayList objects to every subsequent read/tale call. Also the MAP that keeps track of all previous ArrayLists and their corresponding intermediate objects has been replaced with a one-place buffer. That means you can still benefit from recycling intermediate data if you use the same ArrayList over and over, but it will garbage collect anything related to any prior ArrayList you passed to the read/take calls. |
| OSPL-13795 / 00020698 | Issues during termination of spliced when configuration specifies thread attributes for heartbeat-manager When the configuration file specifies attributes such as stack size or scheduling class for the heartbeat-manager in spliced (//OpenSplice/Domain/Daemon/Heartbeat), termination fails and triggers an error report "Failed to join thread (null):0x0 (os_resultSuccess)" Solution: The code was changed to cover a specific path where after stopping the thread an invalid return code was propagated leading to failed termination. |
| OSPL-13797 | Unnecessary alignment may occur when a node with a namespace with aligner=false (temporarily) chooses a different master for this namespace. This unnecessarily increases network load. When a node with aligner=false for a namespace enters a network, this node starts looking for an aligner. If there are potentially multiple aligners but not all of them have been discovered yet, then it could happen that this node chooses a different master for the namespace than somebody else. When the nodes that chose a different master for the namespace detect each other, then a master conflict is generated. Resolving this master conflict leads to alignment. Although functionally there is nothing wrong, the unfortunate situation in this scenario is that the alignment for nodes with alignment=false is not necessary, because by definition of aligner=false this node will not provide any alignment data to the master (whichever one is chosen). Still the master bumps its state, and causes all slaves to align from the master again. These alignments are superfluous. Solution: The situation where are node with aligner=false has (temporarily) chosen a different master is not considered a valid reason to start alignment. |
| OSPL-13812 | Trying to unregister a non-existent instance leads to an entry in ospl-error. This is incorrrect. Trying to unregister a non-existent instance is a legitimate application action that should return PRECONDITION_NOT_MET. However, as a side effect also an error message would appear in ospl-error.log. Solution: The error message is not generated anymore when a non-existent instance gets unregistered. |
| OSPL-13844 | Spliced will crash during shutdown if builtin topics have been disabled. There is a bug in the spliced that causes it to crash during shutdown when you configured OpenSplice not to communicate the builtin topics. This was caused by spliced forgetting to set the Writers for the builtin topics to NULL in that case, which during shutdown would result in the spliced attempting to release dangling random pointers. Solution: The writers for the builtin topics are now properly set to NULL when you disabled the builtin topics, and therefore spliced will not attempt to clean them up during shutdown. |
| OSPL-13868 | Configuration files for NetworkPartitions example were incorrect The example configuration files include a ddsi2 service and not ddsie2 so extra additional values are not visible in configuration tool and would not be used in OpenSplice. Additionally a number of the elements are incorrectly cased. Solution: Updated Example files have been included. |
| OSPL-13888 | The durability service leaks memory when handling a received namespace message. When a namespace message from a fellow is received and that namespace message is a duplicate of an earlier received namespace message allocated namespace leaks. Solution: The duplicate namespace is freed. |
| OSPL-13892 | Potential backlog in the processing of builtin topics by spliced The spliced is responsible for processing incoming builtin topic samples. This processing is needed to for example modify the local notion of the liveliness of remote entities and the instances they have written. Having the wrong notion of the liveliness of a remote entity could result in instances being marked ALIVE, while they should have been marked NOT_ALIVE or vice-versa. Also, the failure to notice the deletion of a remote entity could result in extended waiting times in case of for example the synchronous write, where a writer is still waiting for acknowledgments of a Reader that already left the system. Due to a bug in the spliced code, the spliced could under certain conditions postpone processing of builtin topics for potentially long time intervals, resulting in incorrect liveliness representations during this interval, which in turn might cause extended waiting times in case of a synchronous write call. Solution: The spliced now no longer postpones the processing of builtin topics, causing the representation of the liveliness of entities and instances to be up to date, and avoiding unnecessary waiting times in the synchronous write call for readers that have already been deleted. |
| OSPL-13923 | MATLAB Query and Reader failure with waitsetTimeout() The MATLB Vortex.Query class would throw on calls to take() or read() if a non-zero value had previously been provided to waitsetTimeout(). BAD_PARAMTER messages would be written to ospl-error.log. In a similar situation, a Vortex.Reader class instance would appear to succeed, but ospl-error.log would still contain BAD_PARAMETER messages, and a DDS entity would be leaked with each call to read() or take() Solution: The problems have been fixed. Uninstall the currently installed Vortex_DDS_MATLAB_API toolbox and install the new toolbox distributed with this release. (The toolbox is located under tools/matlab in the OpenSplice installation directory.) |
| OSPL-13929 / 00020814 | Alignment of DCPSPublication may cause that instances that were explicitly unregistered and disposed are not purged and leak from shared memory. When detecting a disconnect of a node the instances written by writers on that disconnected node are unregistered. When the same node reconnects then alignment of DCPSPublication will indicate which writer are still alive. These DCPSPublication will then be used to update of the liveliness of the corresponding instances. However explicitly unregistered instances are also updated which causes that they are removed from the purge list which results in a memory leak. Solution: When handling the re-alignment of a DCPSPublication the corresponding instances that were explicitly unregistered are ignored. |
| OSPL-13931 | Potential alignment issue for unions in generic copy routines for C The generic copy routines for the C API may potentially misalign union attributes, causing the fields following the union to contain bogus values. Solution: The algorithm to determine proper alignment for unions has been corrected. |
| OSPL-13937 | Enable or disable tracing for Dlite In some situtions users want to disable tracing in production environments, and enable tracing in testing environment. So far, there has not been an easy way other than commenting out the tracing section in the configuration. This is cumbersome. Solution: An attribute //OpenSplice/Dlite/Tracing[@enabled] is added that can be used to enable/disable tracing for Dlite. |
| OSPL-13803 | Possible crash at termination of NodeJS with DDS Security The DDS Security implementation relies on a certain termination path to cleanup all it's resources, part of it dependent on an exit handler. This exit handler does not run reliably at the same moment, eg. before or after certain threads are joined, depending on context, such as a single-process deployment running in NodeJS. Solution: The cleanup was changed to work regardless of the exact moment when the exit handler is executed. |
| OSPL-13799 / 00020745 | Generate a logging message for dispose_all_event The invocation of the dispose_all() function on a topic is an important event, that should appear in the ospl-info.log file. Solution: A message is written into the ospl-info.log by the node that invokes the dispose_all() function. Note: although all other nodes respond by also disposing their corresponding topic data, they don't mention this event in their ospl-info.log. |
| OSPL-13870 | Add a parameter to RT networking to allow the independent setting of the acknowledgement interval. A reliable channel uses acknowledgement messages to notify the sender that a packet has been successfully received. To limit the rate at which acknowledgements are sent the acknowledgements are accumulates during the acknowledgement interval. Currently the acknowledgement interval is set to the configured resolution interval of the channel. However it could be useful to have the ability have an independent parameter which specifies the acknowledgement interval. Solution: The AckResolution parameter has been added to the RT networking configuration. When set it will determine the interval at which acknowledgements are sent. When not set the acknowledgement interval is set to the resolution of the reliable channel. |
| OSPL-13871 | Add an configuration parameter to RT networking to disable the sync exchange at initial detection of a node. When the SyncMessageExchange is disabled reliable communication with another node is started when receiving the first acknowledge from that node. When the SyncMessageExchange is enabled reliable communication will also start when receiving a first message from a node. The sync message will communicate the sequence number from which reliable communication is provided. However this may cause a very high backlog of packets that have to be resend to the newly detected node especially when initial latencies are large. Therefore an option should be provided to enable the SyncMessageExchange only on receiving the first acknowledgement which will reduce this initial backlog or resends to occur. Solution: A mode attribute is added to the SyncMessageExchange parameter which indicates if the reliable synchronization should occur on the initial received packer or the first received acknowledgement. |
| OSPL-13875 | Add option to RT networking to disable the initial sequence number offset. To establish reliable communication between a sender and receiver both have to agree on the initial packet sequence number from which reliable communication is established. This sequence number is based on the first sequence number that is acknowledged minus a small offset which in included in each packet sent. The initial sequence number is than the first acknowledged sequence number minus the offset. This offset then determines the number of packets that have to be resend immediately. To reduce this initial backlog an configuration parameter has to be added to disable this offset. Solution: The configuration parameter OffsetEnabled is added to allow disabling the offset calculation. |
| OSPL-13939 / 00020822 | Looser type-checks for the Python API It is no longer required to use python built-ins as long as the cast is defined. For string types only support for encoding and length determination is needed. For sequences and arrays iteration and length determination are the only requirements. Solution: Loosened type requirements on integers, bools, strings and floats. |
Fixed Bugs and Changes affecting API/behaviour in OpenSplice 6.11.x
OpenSplice 6.11.2
| Report ID. | Description |
|---|---|
| OSPL-14293 | IsoCpp2 query parameters setter function fixed According to existing documentation, the function template void parameters(const FWIterator& begin, const FWIterator end) on the query and querycondition objects, is supposed to set the parameters. However its actual behavior was to concatenate the new parameters to the old set. Solution: The function now replaces the old set of parameters by the new set. |
| OSPL-14271 | Calling DDS_end_coherent_changes() without calling DDS_begin_coherent_changes() should NOT lead to an error. In normal cases a call to DDS_end_coherent_changes() is preceded by a call to DDS_begin_coherent_changes(). However, there is nothing to prevent an application to call DDS_end_coherent_changes() without having called DDS_begin_coherent_changes(). In that case PRECONDITION_NOT_MET is returned. As a side effect, an error was also generated that ends up in ospl-error.log. This side effect is undesirable, because the error suggested that the user did something illegal. However, it is legitimate to call DDS_end_coherent_changes() without having called DDS_begin_coherent_changes(), in which case PRECONDITION_NOT_MET is returned. Solution: No error is generated any more. Instead, a warning is generated in ospl-info.log to make the user aware that the call to DDS_end_coherent_changes() did not yield the desired effect. |
OpenSplice 6.11.1
| Report ID. | Description |
|---|---|
| OSPL-14000 | Internal operation to get the actual domain (shm) memory usage on the C API. The actual amount of shared memory used by a Domain federation is useful to monitor for test purposes as well for managing a system. The internal operation to get this information is made public for applications by adding it to the C API. This operation will accept a Domain object that can by retrieved by the DDS_DomainParticipant_lookup_domain operation and will return the current amount of used memory in bytes. Note that this is a non-standard product specific operation. Solution: Operation Signature: DDS_long_long DDS_Domain_get_memory_usage(DDS_Domain domain); |
| OSPL-14002 | Internal operation to get the actual domain (shm) memory usage on the ISOCPP2 API. The actual amount of shared memory used by a Domain federation is useful to monitor for test purposes as well for managing a system. The internal operation to get this information is made public for applications by adding it to the ISOCPP2 API's DomainParticipant interface. This will return the current amount of used memory in bytes. Note that this is a non-standard product specific operation. Solution: uint64_t DDS::DomainParticipant::get_memory_usage(); |
OpenSplice 6.11.0
| Report ID. | Description |
|---|---|
| OSPL-12968 / 00019801 | DCPS Python API Out of scope entities aren't closed, causing memory leak When a python object holding a DDSEntity loses all references, the underlying DDS entity is not deleted, leaking the resource. In a domain where many entities are created dynamically, but not closed explicitly with the close(), this will eventually result in an Out of Resources error. Solution: Python objects automatically garbage collected when all references to the object are gone. There was code in the DCPS python API that deletes the underlying DDS entity when this occurs, but this never triggered because the were strong references to all DDSEntity python objects held in a persistent dictionary in the dds module. To remedy this, this dictionary was changed to store only weak references, so now the entity is deleted when the python object is garbage collected. There is an important thing for developers using this API to note, now. Before this change, it was possible to create a DDSEntity (typically with a listener) and just let it go out of scope, relying on the listener to just do it's thing, and keeping only a parent entity (like the participant) as the main means to control the lifecycle. This is no longer possible. Python code must keep a reference to a DDSEntity object to keep it active. However, note that DDSEntity still maintains a strong reference to its parent entity, meaning that once a reader or writer reference made, one can let go of a participant, publisher, and/or subscriber reference without having it be garbage collected. Once the last reference to the reader/writer is gone, only then is the entire chain of entities deleted. |