This page lists all the fixed bugs and changes in the OpenSplice v6.6.x release
Regular releases of OpenSplice are made available which contain fixed bugs, changes to supported platforms and new features.
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.6.x
OpenSplice v6.6.4p2
Fixed bugs and changes not affecting the API in OpenSplice 6.6.4p2
Report ID. | Description |
---|---|
OSPL-8425 / 16551 | When a lot of fragmented, best effort data is received, the receiver will run out of buffer space Defragmentation buffers is shared with the receive buffer. In case a lot of data is received, the networkstack isn't able to free claimed buffer space as it doesn't get to time to defragmentate data in the buffers. As a result, incoming data can not be stored and networking can't recover from this situation as these buffers remain locked. Solution: In case no buffers can be freed, drop data in buffers to create free space to be able to receive new data and continue to function. Data in the dropped buffers are lost but as this is best-effort data, this is allowed. |
OSPL-8886 | Durability failure to merge data after a short disconnect When the disconnection period is shorter than twice the heartbeat a durability service may not have been able to determine a new master before the node is reconnected again. In that case no master conflict is generated. In case the durability service is "late" in confirming a master it might even occur that the master has updated its namespace, but the namespace update is discarded because no confirmed master has been selected yet. As a consequence no request will for data will be sent to the master, and the durability service will not be aligned. Solution: In case a durability service receives a namespace update for a namespace for which no confirmed master is selected yet, the update is rescheduled for evaluation at a later time instead of discarding the update. |
OSPL-8914 | Durability failure to merge data after a short disconnect When a node becomes disconnected it may loose its master. As a result the node will look for a new master. In doing so, the node would first unconfirm its current master and then wait for other fellows to propose a new master. The time to look for a new master is specified in the configuration file (DurabilityService.Network.Heartbeat.ExpiryTime). When the disconnection was shorter than the DurabilityService.Network.Heartbeat.ExpiryTime, no merge is triggered. Solution: whenever a node is discovered that is not simply starting and it has no confirmed master, a merge is triggered, just like when there are conflicting masters. NOTE: This change has been reverted in 6.6.3p4f7. |
OSPL-8920 | DDSI2 Crash Version 6.6.3p4 introduced a fix for OSPL-8872, taking the sequence number most recently transmitted by a writer when it matched reader into account to force heartbeats out until all historical data has been acknowledged by the reader. The change also allowed a flag forcing the transmission of heartbeats informing readers of the availability of data to be set earlier than before in the case where the writer had not published anything yet at the time the reader was discovered. While logically correct, this broke the determination of the unique reader that had not yet acknowledged all data in cases where there is such a unique reader. This in turn could lead to a crash. Solution: the aforementioned flag is once again never set before a sample has been acknowledged. |
OSPL-8928 | Improve FACE documentation FACE documentation is very rudimentary. Solution: Getting started, API documentation, configuration documentation and example have been added. |
OSPL-8948 / 16755 OSPL-8987 | Race condition between durability data injection and garbage collecting of empty instances The durability service cached instance handles when injecting a historical data set in a way that could result in the historical samples being thrown away if the instance was empty and no known writers had registered it. Solution: the instance handle is no longer cached. |
OSPL-8953 | Potential deadlock between reader creation and durability notification A thread that creates a new DataReader and a thread from the durability service that notifies a DataReader when it has completed its historical data alignment grab two of their locks in reverse order, causing a potential deadlock to occur. Solution: The locking algorithm has been modified so that these two threads do no longer grab both locks in reverse order. |
OSPL-8956 | Temporary blacklisting of remote participants in DDSI2 The DDSI2 service now provides an option to temporarily block rediscovery of proxy participants. Blocking rediscovery gives the remaining processes on the node extra time to clean up. It is strongly advised that applications are written in such a way that they can handle reconnects at any time, but when issues are found, this feature can reduce the symptoms. Solution: A new setting in the DDSI section of the configuration has been added: Internal/RediscoveryBlacklistDuration along with an attribute Internal/RediscoveryBlacklistDuration [@enforce]. The former sets the duration (by default 10s), the second whether to really wait out the full period (true), or to allow reconnections once DDSI2 has internally completed cleaning up (false, the default). It strongly discouraged to set the duration to less than 1s. |
OSPL-8971 | Catchup policy may incorrectly mark unregistered instances as disposed. When an instance is unregistered on the master node during a disconnect from another node that has specified a CATCHUP policy with that master, then upon a reconnect that unregister message will still be delivered to that formerly disconnected node. However, the reconnected node will dispose all instances for which it did not receive any valid data, so if the unregister message it the only message received for a particular instance, then its instance will be disposed. Solution:The Catchup policy is now instructed to dispose instances for which it did not receive any valid data OR for which it did not receive any unregister message. |
OSPL-8984 | DDSI handling of non-responsive readers needs improvement When a writer is blocked for ResponsiveTimeout seconds, DDSI will declare the matching proxy readers that have not yet acknowledged all data "non-responsive" and continue with those readers downgraded to best-effort. This prevents blocking outgoing traffic indefinitely, but at the cost of breaking reliability. For historical reasons it was set to 1s to limit the damage a non-responsive reader could cause, but past improvements to the handling of built-in data in combination with DDSI (such as fully relying on DDSI discovery for deriving built-in topics) mean there is no longer a need to have such an aggressive setting by default. Solution: The default behaviour has been changed to never declare a reader non-responsive and maintain reliability also when a remote reader is not able to make progress. The changes also eliminate some spurious warning and error messages in the log files that could occur with a longer timeout. |
OSPL-9027 | idlpp is not robust to paths with whitespace The idlpp tool is not able to handle paths that contain whitespaces when compiling for cpp and thus using cppgen. Solution: Add quotes to the arguments for cppgen, which are generated by idlpp. |
OSPL-9028 | Bug in serializing messages with sequences of 64 bit The SAC generic copy routines have an issue with alignment and empty sequences. Additionally, the legacy CDR serialiser (the only one up to but not including 6.4.1) has this issue because it always inserts padding for sequences of primitive and enumerated types even when the sequence is empty. Solution:The SAC copy routines have been modified to be able to deal with empty sequences. Even though the new CDR serialiser (since 6.4.1) does not have this issue and versions from 6.4.1 onward are not affected, the old code is still a compile-time option in the current versions for development purposes and so that one is fixed, too. |
OSPL-9055 | Potential Sample drop during delivery to a local Reader In some cases, a dispose followed by an unregister does not result in NOT_ALIVE_DISPOSED state on a Reader residing on the same node as the Publisher. In those cases, the Reader has an end state set to NOT_ALIVE_NO_WRITERS, and reports that a sample has been Lost. Solution: We have no clue what could cause this behaviour, but added some logging to capture the context of the erroneous sample drop. This is just a temporary measure, and will be reverted when the root cause has been found and fixed. |
OSPL-9056 | Potential deadlock during early abort of an application When an application aborts so quickly that the participant's leaseManager thread and its resendManager thread have not yet had the opportunity to get started, then the exit handler will block indefinitely waiting for these threads to exit the kernel. However, both threads are already blocked waiting to access a kernel that is already in lockdown. Solution: The constructor of the participant will not return before both the leaseManager and resendManager threads have entered the kernel successfully. |
OSPL-9058 / 16796 OSPL-9206 / 16852 | Incompatibility with versions before V6.5.0p5 An internal change to builtin heartbeat topic caused an incompatibility with older versions. When adding a node running a recent version of OpenSplice to a domain with nodes running a version before V6.5.0p5, the existing nodes would incorrectly dispose participants (and corresponding entities) belonging to the new nodes after a single heartbeat period, normally done only when a heartbeat expires. Solution: To resolve this, the change to the heartbeat topic was reverted. |
OSPL-9064 / 16808 | Changes caused by OSPL-8914 in 6.6.3p4f4 have been reverted OSPL-8914 in the 6.6.3p4f4 release has made several changes to the durability service in order to solve problems where a rapid disconnect/reconnect cycle would leave the durability service in an undefined state. In these situations, a disconnect had not yet been fully processed when the reconnect occurs. However, the solutions provided in 6.6.4 caused other, previously non-existing errors during normal operation. Solution: All changes made as part of OSPL-8914 in the 6.6.4 release have been reverted. As an alternative solution to rapid disconnect/reconnect cycle issues, ddsi has offered temporary blacklisting of recently disconnected participants (see OSPL-8956). |
OSPL-9067 | Large topics are sent published but not received Loss of the initial transmission of the final fragments of a large sample failed to cause retransmit requests for those fragments until new data was published by the same writer. Solution: ensure the receiving side will also request retransmission of those fragments based on heartbeats advertising the existence of the sample without giving specifics on the number of fragments. |
OSPL-9068 / 00016813 | Catchup policy may leak away some instances When a node that performs a catchup to the master contains an instance that the master has already purged, then the node catching up would need to purge this instance as well. It would need to do this by re-registering the instance, inserting a dispose message and then unregistering this instance again. However, the unregister step was missing, causing the instance to effectively leak away since an instance is only purged by the durability service when it is both disposed AND unregistered. Solution: The durability will now both dispose AND unregister the instance at the same time. |
OSPL-9071 | v_groupFlushAction passes a parameter that is not fully initialized. Valgrind reported that the v_groupFlushAction function passes a parameter that is not fully initialized. Although one of these parameters was evaluated in a subsequent function invocation, it never caused issues because the value was only used as an operand for a logical AND where the other operand was always FALSE. Solution: All attributes of the parameter in question are now explicitly initialized. |
OSPL-9077 / 00016820 | Potential crash in durability service during CATCHUP policy The durability service could crash while processing a CATCHUP event. This crash was caused by the garbage collector purging old instances while the CATCHUP policy was walking through the list of instances to do some bookkeeping. Solution: The CATCHUP policy now creates a private copy of the instance list while the garbage collector is unable to make a sweep. This private list is then used to do the bookkeeping. |
OSPL-9081 / 00016824 | Potential deadlock in the OpenSplice kernel The OpenSplice kernel has a potential deadlock where two different code paths may claim locks in the opposite order. The deadlock occurs when one thread is reading/taking the data out of a DataReader while the participant's listener thread is processing the creation of a new group (i.e. a unique partition/topic combination) to which this Reader's Subscriber is also attached. Solution: The locking algorithm has been modified in such a way that the participant's listener thread no longer requires to hold both locks at the same time. |
OSPL-9096 | Durability service DIED message even though the durability service is still running The d_status topic is published periodically by the durability service to inform its fellows of its status. By using a KEEP_ALL policy, the thread writing the status message and renewing the serivce lease could be blocked by a flow-control issue on the network, which could cause the durability service to be considered dead by the splice daemon when in fact there was no problem with the durability service. Solution: use a KEEP_LAST 1 history QoS policy for the writer. |
OSPL-9097 | DDSI transmit path can lock up on packet loss to one node while another node has crashed A successful retransmit to one remote reader while another remote reader that has not yet acknowledged all samples disappears (whether because of a loss of connectivity or a crash), and when all other remote readers have acknowledged all samples, and while the writer has reached the maximum amount of unacknowledged data would cause the transmit path in DDSI to lock up because the writer could then only be unblocked by the receipt of an acknowledgement message that covers a previously unacknowledged sample, which under these circumstances will not come because of the limit on the amount of unacknowledged data. Solution: deleting a reader now not only drops all unacknowledged data but also clears the retransmit indicator of the writer. |
OSPL-9388 / 17030 | Durability service might deadlock when the networking queue is flooded. When the network queue is overrun by the durability service, the normal mode of operation is to sleep a bit and retry again later. However, there is a slight chance that the sending thread of the network service that needs to make room again by consuming elements in the queue will indirectly block on the sleeping thread in the durability service itself. Solution: The network service can no longer indirectly run into a lock that is held by the durability service while the network queue is flooded. |
OpenSplice v6.6.4p1
Fixed bugs and changes not affecting the API in OpenSplice 6.6.4p1
Report ID. | Description |
---|---|
OSPL-9016 | Changes caused by OSPL-8914 in 6.6.4 have been reverted OSPL-8914 in the 6.6.4 release has made several changes to the durability service in order to solve problems where a rapid disconnect/reconnect cycle would leave the durability service in an undefined state. In these situations, a disconnect had not yet been fully processed when the reconnect occurs. However, the solutions provided in 6.6.4 caused other, previously non-existing errors during normal operation. Solution: All changes made as part of OSPL-8914 in the 6.6.4 release have been reverted. As an alternative solution to rapid disconnect/reconnect cycle issues, ddsi has offered temporary blacklisting of recently disconnected participants (see OSPL-8956). |
OpenSplice v6.6.4
Fixed bugs and changes not affecting the API in OpenSplice 6.6.4
Report ID. | Description |
---|---|
OSPL-8953 | Potential deadlock between reader creation and durability notification A thread that creates a new DataReader and a thread from the durability service that notifies a DataReader when it has completed its historical data alignment grab two of their locks in reverse order, causing a potential deadlock to occur. Solution: The locking algorithm has been modified so that these two threads do no longer grab both locks in reverse order. |
OSPL-8636 | Streams throughput example hang on windows When using the streams throughput example on windows the subscriber application could hang on termination. Solution: The defect is fixed and the subscriber will not hang anymore. |
OSPL-8886 | Durability failure to merge data after a short disconnect When the disconnection period is shorter than twice the heartbeat a durability service may not have been able to determine a new master before the node is reconnected again. In that case no master conflict is generated. In case the durability service is "late" in confirming a master it might even occur that the master has updated its namespace, but the namespace update is discarded because no confirmed master has been selected yet. As a consequence no request will for data will be sent to the master, and the durability service will not be aligned. Solution: In case a durability service receives a namespace update for a namespace for which no confirmed master is selected yet, the update is rescheduled for evaluation at a later time instead of discarding the update. |
OSPL-8914 | Durability failure to merge data after a short disconnect When a node becomes disconnected it may loose its master. As a result the node will look for a new master. In doing so, the node would first unconfirm its current master and then wait for other fellows to propose a new master. The time to look for a new master is specified in the configuration file (DurabilityService.Network.Heartbeat.ExpiryTime). When the disconnection was shorter than the DurabilityService.Network.Heartbeat.ExpiryTime, no merge is triggered. Solution: whenever a node is discovered that is not simply starting and it has no confirmed master, a merge is triggered, just like when there are conflicting masters. NOTE: This change has been reverted in 6.6.4p1 because it may break other durability functionality. |
OSPL-8920 | DDSI2 Crash Version 6.6.3p4 introduced a fix for OSPL-8872, taking the sequence number most recently transmitted by a writer when it matched reader into account to force heartbeats out until all historical data has been acknowledged by the reader. The change also allowed a flag forcing the transmission of heartbeats informing readers of the availability of data to be set earlier than before in the case where the writer had not published anything yet at the time the reader was discovered. While logically correct, this broke the determination of the unique reader that had not yet acknowledged all data in cases where there is such a unique reader. This in turn could lead to a crash. Solution: the aforementioned flag is once again never set before a sample has been acknowledged. |
OSPL-8948 / 16755 OSPL-8987 | Race condition between durability data injection and garbage collecting of empty instances The durability service cached instance handles when injecting a historical data set in a way that could result in the historical samples being thrown away if the instance was empty and no known writers had registered it. Solution: the instance handle is no longer cached. |
OSPL-8956 | Temporary blacklisting of remote participants in DDSI2 The DDSI2 service now provides an option to temporarily block rediscovery of proxy participants. Blocking rediscovery gives the remaining processes on the node extra time to clean up. It is strongly advised that applications are written in such a way that they can handle reconnects at any time, but when issues are found, this feature can reduce the symptoms. Solution: A new setting in the DDSI section of the configuration has been added: Internal/RediscoveryBlacklistDuration along with an attribute Internal/RediscoveryBlacklistDuration [@enforce]. The former sets the duration (by default 10s), the second whether to really wait out the full period (true), or to allow reconnections once DDSI2 has internally completed cleaning up (false, the default). It strongly discouraged to set the duration to less than 1s. |
OSPL-8957 | Unnecessary heartbeat/acknowledgement traffic in DDSI with late joiners for transient-local data In DDSI, reliable writers send heartbeats to inform their readers of the existence of unacknowledged data, and keep doing so until the readers have acknowledged everything. The heartbeats indicate the range of sequence numbers available. The highest sequence number advertised in the heartbeat was the highest sequence number available for retransmit, leaving out any subsequent sequence numbers that are no longer available for retransmit. If a transient-local writer unregistered an instance and then became quiescent, it would be advertising a sequence number less than the latest sequence number it published, and this would lead to a late-joining reader never acknowledging all data up to this latest sequence number. As a result, the writer would keep sending heartbeats and the readers would keep acknowledging it. Sending new samples from the writer would break the cycle. Solution: the writer now advertises the latest sequence number it published. If there is a gap between the latest available for retransmit and the latest published, the reader will be informed that these sequence numbers are no longer relevant using a standard message. |
OSPL-8958 | DDSI can regurgitate old T-L samples for instances that have already been unregistered DDSI maintains a writer history cache for providing historical data for transient-local writers and for providing reliability. An instance is removed from this cache when it is unregistered by the writer, but its samples are retained until they have been acknowledged by all (reliable) readers. Already acknolwedged samples that were retained because they were historical data could survive even when the instance was removed. When this happened, a late-joining reader would see some old samples reappear. Solution: deleting an instance now also removes the already acknowledged samples from the history. |
OSPL-8971 | Catchup policy may incorrectly mark unregistered instances as disposed. When an instance is unregistered on the master node during a disconnect from another node that has specified a CATCHUP policy with that master, then upon a reconnect that unregister message will still be delivered to that formerly disconnected node. However, the reconnected node will dispose all instances for which it did not receive any valid data, so if the unregister message it the only message received for a particular instance, then its instance will be disposed. Solution:The Catchup policy is now instructed to dispose instances for which it did not receive any valid data OR for which it did not receive any unregister message. |
OSPL-8972 | Durability fellow state may be incorrect A durability service keeps track of the state of each fellow it knows. In every message that fellow sends to a durability service the state of the fellow is included. The recipient has different threads to handle incoming messages. In rare cases, these messages are processed in the reverse order, thus ending up with a wrong conclusion about the fellow's state. Solution: The durability service now uses the source timestamp in incoming messages to determine the order in which they have been written to ensure it never updates the internal state using 'old' information. |
OSPL-8973 | Additional durability tracing when verbosity is set to FINEST Durability has been extended with additional tracing in the processing of namespace definitions received from fellows, in particular when checking for master conflicts. |
OSPL-8974 | Durability conflict scheduling fails when multiple namespaces have the same policy and differ only in topic names Durability checks for conflicts between fellows (master, native and foreign state) that may require merging data whenever it receives a "d_nameSpaces" instance. If a conflict is detected, it enqueues it for eventual resolution, but only if an equivalent conflict is not yet enqueued. Testing for equivalency is done by checking: conflict kind, roles and local and fellow namespaces. However, the name space compare function (d_nameSpaceCompare) did not take the name into account, nor the full partition+topic expressions. The consequence is that when namespaces A and B have identical policies and differ only in the topic parts of the partition/topic expressions, a conflict for namespace A would be considered the same as a conflict for namespace B. The result would be a failure to merge data in B. Solution: The comparison now takes the name of the namespace into account. The configuration is required to have no overlap between namespaces and to have compatible namespace definitions throughout the system. The name alone is therefore sufficient. |
OSPL-8979 | DDSI incapable of receiving multicasts after restart in single-process mode The tracking of joined multicast groups DDSI could not handle the case where DDSI would be restarted in single-process mode (e.g., by creating a participant, deleting it, and creating another one), potentially causing the new sockets not to join the multicast groups. Solution: DDSI now explicitly leaves all multicast groups on termination. |
OSPL-8980 | With DDSI remote participants expire independently on cable disconnect The DDSI protocol has lease expiry tied to participants and the DDSI service faithfully implemented this. This means that a cable disconnect occurs caused the leases of the various participants on the remote node to expire independently, and therefore also the automatic disposing and unregistering of data. A short disconnection where the lease of the durability service never expired, but where the lease of some application process did expire could lead to an inconsistent state of the data space, if that application published auto-disposed transient data. Solution: DDSI has been modified to implement only a single lease per remote federation for OpenSplice peers by internally tying the leases of the applications to the lease of the remote DDSI service. |
OSPL-8984 | DDSI handling of non-responsive readers needs improvement When a writer is blocked for ResponsiveTimeout seconds, DDSI will declare the matching proxy readers that have not yet acknowledged all data "non-responsive" and continue with those readers downgraded to best-effort. This prevents blocking outgoing traffic indefinitely, but at the cost of breaking reliability. For historical reasons it was set to 1s to limit the damage a non-responsive reader could cause, but past improvements to the handling of built-in data in combination with DDSI (such as fully relying on DDSI discovery for deriving built-in topics) mean there is no longer a need to have such an aggressive setting by default. Solution: The default behaviour has been changed to never declare a reader non-responsive and maintain reliability also when a remote reader is not able to make progress. The changes also eliminate some spurious warning and error messages in the log files that could occur with a longer timeout. |
OSPL-8989 | Non-atomic dispose+unregister operation on DCPSHeartbeat A race condition between auto-disposing/unregistering, taking data from a data reader and merging of historical data was resolved in OSPL-8684 by performing the an atomic dispose+unregister operation instead of two separate operations. This fix covered all cases except the DCPSHeartbeat built-in topic, which is handled specially by the splice daemon and still performed two independent operations. Solution: The atomic dispose+unregister is now also used for DCPSHeartbeat. There are no user-visible consequences of this change. |
TSTTOOL-395 | Python scripting examples need to be updated to reflect the ability to create and specify QoS settings on entities. the example now shows: reading and writing to non-default partition use a waitset to poll some data pass some user data through one of the QoS use a check to show that a reader and a writer don't match on QoS |
Fixed bugs and changes affecting the API in OpenSplice 6.6.4
Report ID. | Description |
---|---|
TSTTOOL-396 | Query condition support in Python Scripting Engine The Python scripting engine now supports query conditions |
TSTTOOL-397 | Status condition support in Python Scripting Engine The Python scripting engine now supports status conditions. |
OpenSplice v6.6.3p5
Fixed bugs and changes not affecting the API in OpenSplice 6.6.3p5
Report ID. | Description |
---|---|
OSPL-8920 | DDSI2 Crash Version 6.6.3p4 introduced a fix for OSPL-8872, taking the sequence number most recently transmitted by a writer when it matched reader into account to force heartbeats out until all historical data has been acknowledged by the reader. The change also allowed a flag forcing the transmission of heartbeats informing readers of the availability of data to be set earlier than before in the case where the writer had not published anything yet at the time the reader was discovered. While logically correct, this broke the determination of the unique reader that had not yet acknowledged all data in cases where there is such a unique reader. This in turn could lead to a crash. Solution: the aforementioned flag is once again never set before a sample has been acknowledged. |
OSPL-8914 | Durability failure to merge data after a short disconnect When a node becomes disconnected it may loose its master. As a result the node will look for a new master. In doing so, the node would first unconfirm its current master and then wait for other fellows to propose a new master. The time to look for a new master is specified in the configuration file (DurabilityService.Network.Heartbeat.ExpiryTime). When the disconnection was shorter than the DurabilityService.Network.Heartbeat.ExpiryTime, no merge is triggered. Solution: whenever a node is discovered that is not simply starting and it has no confirmed master, a merge is triggered, just like when there are conflicting masters. |
OSPL-8886 | Durability failure to merge data after a short disconnect When the disconnection period is shorter than twice the heartbeat a durability service may not have been able to determine a new master before the node is reconnected again. In that case no master conflict is generated. In case the durability service is "late" in confirming a master it might even occur that the master has updated its namespace, but the namespace update is discarded because no confirmed master has been selected yet. As a consequence no request will for data will be sent to the master, and the durability service will not be aligned. Solution: In case a durability service receives a namespace update for a namespace for which no confirmed master is selected yet, the update is rescheduled for evaluation at a later time instead of discarding the update. |
OpenSplice v6.6.3p4
Fixed bugs and changes not affecting the API in OpenSplice 6.6.3p4
Report ID. | Description |
---|---|
OSPL-8884 | Spliced assertion failure (_this->state & L_UNREGISTER) in v_registrationMessageCompare The record of a writer unregistering an instance is retained for a little before it is completely removed from the system. In the case of spliced and DCPSHeartbeat, if in this window the spliced needed to auto-dispose the DCPSHeartbeat, it could resurrect the registration but leave it in an inconsistent state, resulting in this assertion failure. Solution: DDSI now correctly tags the "unregister" events. |
OSPL-8825 / 00016727 OSPL-8722 / 00016668 | Invalid timing during replay with non-default speed by Record and Replay service A regression caused by a previous fix caused the Record and Replay service to not compensate for a non-default replay speed in certain circumstances during replay. Solution: The issue was resolved by making some adjustments in the replay timing algorithm so the replay-speed is always factored in. |
OSPL-8684 / 00016645 | Instances that were NOT_ALIVE due to a disconnect do not always become ALIVE after a reconnect When a disconnect occurs, all instances owned by the disconnected Writers should become NOT_ALIVE_DISPOSED (in case a disconnected Writer had its auto_dispose_unregistered_instances set to TRUE) or NOT_ALIVE_NO_WRITERS. However, when the disconnected node reconnects, and the topic is non-VOLATILE, you might expect the instances to go back to the ALIVE state. However, that did not happen in all scenarios. Solution: If the NOT_ALIVE instances are taken by the DataReader, they will now instantly be purged. When merge policies are configured to re-insert the missing messages back into the DataRerader after the connection is re-established, then these re-inserted samples will cause the instance to be re-created starting in the NEW, NOT_READ, ALIVE state. Note however, if the NOT_ALIVE samples are not taken out at the time of the disconnection, their instances will not be purged, and the re-inserted samples will be discarded as being duplicates of samples that are already there. In those cases the instance state will still not be changed back to ALIVE. |
OSPL-8857 / 00016738 | Unable to start OpenSplice Tuner on Windows An incomplete classpath in the manifest of ospltun.jar causes a ClassDefNotFound exception when starting the Tuner. Solution: The issue was resolved by fixing the classpath handling in manifest file generation. |
OSPL-8872 | DDSI transient local data retrieval may block indefinitely when packet loss occurs halfway through a fragmented sample if the writer is quiescent When the DDSI service is retrieving historical transient-local data from a remote writer (this includes DDSI discovery data), it depends on a constant back-and-forth between requests for retransmits (NACKs) and heartbeats from the writer that allow it to send NACKs. The writer adapts its heartbeat rate based on the state of the readers it surmises from the ACKs/NACKs it receives. On receipt of an ACK it concludes the reader must have received all data (otherwise it should have NACKed the missing samples), which may result in no more heartbeats going out. Requesting a retransmit of individual sample fragments is done using a message different from the standard NACK message. If a reader has received part of a fragmented sample, it will send such an alternative NACK for the missing fragments while sending an ACK for everything up to that point. This ACK caused the writer to incorrectly conclude the reader had received everything. Writing a single new sample would cause the back-and-forth to restart and continue until all data had been transferred. Discovery of a new reader would temporarily trigger heartbeats as well, restarting the sequence, but in a state that further packet loss could cause it to stop again. Solution: the writer requires that the ACK concerns a high enough sequence number before concluding it need not send any more heartbeats. |
OSPL-8847 | When coherent transactions containing topics with strings as key are being aligned, the receiving durability service could crash Durability services are used to align historical data. In case coherent transactions exist, special messages called End-Of_transactions (EOT) are aligned to indicate which parts of the transaction is completed. If topics are aligned that have a string as key and that belong to a transaction, then the receiving durability service could crash because it tries to access unallocated memory. Solution: The code that was responsible for the illegal memory access is fixed. |
OSPL-8803 | Durability tracing logs do not mention the OpenSplice version number The durability tracing log generated by the OpenSplice durability service (when tracing is enabled) does not mention the OpenSplice version number. Solution: The OpenSplice version number is now added to the durability tracing log. |
OSPL-8819 | Memory rise with transient local data using DDSI When using transient local data in combination with DDSI, DDSI starts to allocate memory and never frees it. Solution: When using transient local, DDSI did not request the receiver site to acknowledge the sent data, but still kept it in a list, allocation more and more memory for each message sent. DDSI has been changed to request acknowledgment when using transient-local data. |
OSPL-8771 / 00016706 | Memory leak after deleting a transient reader A reference counting error in determining whether a reader is entitled to transient data caused part of the data reader administration to be retained after deleting the data reader. Solution: The stray reference is now released. |
OSPL-7244 | Tuner does not support writing samples containing multi-dimensional collections The Tuner tool does not support editing multi-dimensional sequences (in IDL, sequence Solution: Support for editing certain multidimensional collections has been added, specifically editing of two dimensional unbounded sequences of primitives, such that the Google Protocol Buffer type "repeated bytes" is able to be edited. Other more complex types such as N-dimensional bounded/unbounded sequences or arrays of primitives or of structs are still not editable. |
OSPL-8804 / 00016720 | Late joining DataReader receives 1 sample per DataReaderInstance per unfinished transaction at maximum When a transaction on a transient topic contains more than 1 samples per instance, and the transaction is not yet finished at the time a late joining Volatile Reader requests historical data, then the reader will receive only the first sample for each ReaderInstance in that transaction, regardless of the Reader's history depth. Solution:The Volatile Reader will now receive all samples of the unfinished transaction. |
OpenSplice v6.6.3p3
Fixed bugs and changes not affecting the API in OpenSplice 6.6.3p3
Report ID. | Description |
---|---|
OSPL-6961 | Cause of an unregister not correctly tracked when a DDSI lease expires There are two reasons why an "unregister" of an instance can take place: the first, most common one, is that a writer explicitly calls unregister_instance, or that it automatically happens when the writer is deleted; the second one is when a remote writer suddenly disappears and the other nodes have to synthesize one. The two are indistinguishable to applications, but the way the must be treated for transient data following a reconnect is different. DDSI did not properly distinguish between the two cases. Solution: DDSI now correctly tags the "unregister" events. |
OSPL-8563 | OS_INFO payloads from Node Info samples contain invalid XML character on Windows 10 64bit, Java 8 When publishing OS_INFO information using NodeMonitor on Windows 10 in conjunction with Java 8, a form feed XML character is supplied by the underlying Sigar library, which cannot be processed by OpenSplice and throws the following exception:[error] o.o.a.c.t.xml - SAXException: Character reference "" is an invalid XML character. Solution:The NodeMonitor implementation now strips out the invalid XML form feed character for the OS_INFO description before publishing the data. |
OSPL-8585 | Display the Topic Type definition wherever a GPB evolution can be selected Tuner does not support selecting a protobuf type evolution yet when writing/reading. Solution: Tuner's support for Google protocol buffers has been updated with the ability to directly view the type definition of the selected type evolution when choosing a type evolution to read/write data as. |
OSPL-8666 / 16651 | Reading with QueryConditions could yield samples that shouldn't be read based on the masks provided. For instance, when an QueryCondition has the mask NOT_READ_SAMPLE_STATE, only samples with that state should be returned when reading or taking with that condition. However, the query implementation did not include testing the masks for trigger values. This means that when using a triggered QueryCondition with the NOT_READ_SAMPLE_STATE, you'd be able to read samples with the READ_SAMPLE_STATE. This was also applicable for the view state and instance state. Solution: Add masks checks for triggered QueryConditions. |
OSPL-8691 | DDSI not properly retransmitting end-of-transaction messages. When using coherent updates, an end-of-transaction message is used to notify the subscribers that the set is now complete and may be committed. These messages may get lost and hence may need to be retransmitted, just like ordinary samples. The retransmit path of DDSI however failed to handle these correctly. In consequence, the subscribing side would automatically reconstruct an end-of-transaction message at a later stage, one that is sufficient for guaranteeing topic-level coherence, but not for group-level coherence. Solution: DDSI has been updated to properly retransmit end-of-transaction messages when required. |
OSPL-8708 | Tuner cannot acquire key list for protobuf topics whose type contains a oneof. If the user creates a reader or writer frame for a topic whose type is a protobuf type containing a oneof declaration, the reader or writer frame will show a warning in the status bar that the key list could not be obtained. Consequently, the user data table would not have any highlighting for key or protobuf required fields. Solution: The underlying API that acquires protobuf specific properties for user data field (such as the required flag or default values) did not properly account for the switch field, which is an invented field for the mapping of oneof to union for representation in existing tooling data models. The tooling protobuf API was fixed to account for this switch field. |
OSPL-8710 / 16663 | Issue with java waitset during termination of domain. When a java application is blocking on a waitset _wait() call, while at the same time OpenSplice is stopping, the application may run into an ArrayIndexOutOfBoundsException. All conditions in the waitset are supposed to trigger because they are detached from the domain, but the java binding does not properly resize the ConditionSeqHolder array supplied by the application, to contain all conditions. Solution: To resolve the issue a check on the array size was added, resizing if required. |
OSPL-8724 | A crash could occur when the system terminates while there are pending events to process. Events are handled asynchronously. In the exceptional case where the system terminates while there are pending events, these events must be cleaned up. A bug could cause that an unmanaged piece of memory is accessed, which potentially causes a crash. Solution: When the system terminates while there are pending events, these events are now being cleaned up correctly. |
OSPL-8728 | Unknown object kind error log when using isocpp2 listener. When using the isocpp2 API with listeners an Unknown object kind error log shows up when listening for the DATA_AVAILABLE status event. Solution: The isocpp2 listener mechanism is fixed and the error will not show anymore when using DATA_AVAILABLE status. |
OSPL-8736 | Registering the same type twice in c sharp raises bad parameter. There was a code path in the C# API in which registering a type that was already known did not set the correct return value, causing a successful call to raise an exception. Solution: Added handling of the result code and return OK when all went well. |
OSPL-8737 | Lag during replay by Record and Replay service. TWhen a reasonable load is placed on the RnR service, i.e. by replaying a storage with many samples recorded at a high frequency from different topics and/or writers, the service may not be able to keep up with the exact original 'recorded' timing and a sample is replayed with a delay. The delays of individual samples add up, resulting in a noticeable delay sooner or later, as the replay carries on. Solution: The replay timing has been improved to compensate for delays on individual samples, catching up lost time so the replay in general doesn't lag behind. |
OSPL-8738 | Lease handling in the DDSI service is sensitive to time jumps. The DDSI service's handling of the leases of remote participants was still based on the wall clock time, and therefore a forward jump of the wall clock by more than a few seconds could cause lease expiry, and hence disconnections. Similarly, a backward jump of the wall clock time could delay lease expiry. Solution: The lease handling is now based on a monotonic clock that counts time elapsed since an arbitrary reference in the past. |
OpenSplice v6.6.3p2
Fixed bugs and changes not affecting the API in OpenSplice 6.6.3p2
Report ID. | Description |
---|---|
OSPL-7245 | Enable highlighting of required fields in GPB user data. Google Protocol Buffer samples in Tuner do not highlight so-called required attributes. This makes it difficult to see what needs to be edited before samples can be written. Solution: The OpenSplice Tuner UI has been updated to distinguish between key, required and optional fields for Google Protocol Buffer samples. Required user data fields in sample tables are highlighted with the cyan colour in the same fashion as in OpenSplice Tester. |
OSPL-7392 OSPL-8450 | The durability service does not properly align open coherent transactions. As soon as a durability service joins an existing system it will retrieve all non-volatile historical data that is available within the system by requesting this data from an available durability service (the master). The master durability service should provide the historical data to the newly joined durability service (this is called alignment). Unfortunately, the master durability service did not align the non-volatile historical data that belongs to a coherent transactions that is not committed (finished) yet. In particular, the following problems were identified: historical data that is not committed yet was not aligned, only committed data was aligned end-of-transactions markers that are used to decide about completeness of a transaction were not aligned. As a consequence alignment of open transactions fails, and the late joining durability service may end up in an inconsistent state. Solution: Data that is part of a non-finished coherent transaction is now being aligned, just as the end-of-transaction markers. This allows the late joining durability service to reconstruct the same state as the master, and consequently completeness of transactions is handled correctly in various disconnect scenarios. |
OSPL-8102 | Minimal configured database size required If a database size is configured below the minimal database size Opensplice will not start and stop with out of memory problems. Solution: If the configured database size is below the minimal required size, it will be increased to the minimal required size and a warning trace will be logged. Minimal database size for 32-bit builds is 2 MB and for 64-bit builds it is 5 MB. The default memory threshold size for free memory will be 10% of the configured database size if the configured database size is less than the default 10MB. |
OSPL-8490 / 16602 | Compatibility issues with dcpssacsAssembly.dll When working with the dcpssacsAssembly.dll provided with the C# API there can be compatibility issues with Visual Studio versions. This is because the dcpssacsAssembly.dll is created with the use of the .NET framework 2.0. Solution: The dcpssacsAssembly.dll is now generated with the corresponding Visual Studio .Net Framework compiler. |
OSPL-8528 | Closing a DDS entity containing closed entities intermittently results in an AlreadyClosedException When concurrently calling close methods on entities, the Java5 API may throw an AlreadyClosedException in case one of the children of the offending Entity already has been closed. Solution: The implementation of the various close methods has been modified to be able to deal with concurrent closing of multiple entities by the application. |
OSPL-8544 | Ordered_access for GROUP scope does not handle lifespan expiry correctly. When a sample's lifespan has been expired in a Reader that belongs to a Subscriber with GROUP Presentation scope, it is not removed from the Reader cache at the start of a coherent_access block. Because of the fact that during a coherent_access block reader caches will be locked for any type of modification, the get_datareaders() function of the Subscriber and the read/take functions on individual Readers can still access samples that should have been expired. Solution: The start of a coherent_accesss block on the Subscriber will first test the contents of its Reader caches for expired samples. All samples that have been expired will be purged prior to locking their Reader caches. |
OSPL-8566 / 16634 | Deployment Guide vs Configuration Guide In the set of documents delivered in the pdf directory of each OSPL version appears the Deployment Guide. This document refers about 56 times to "the separate OpenSplice Configuration Guide". The references should point to section 12 of the deployment guide itself instead Solution: The references in the document have been updated. |
OSPL-8576 | TypeEvolution chooser should be hidden when the Google Protocol Buffers feature is disabled for the platform. In OpenSplice Tuner, when choosing to read or write data from a GPB-defined topic, the user is prompted with a dialog window to choose which type evolution to view the data as. If the OpenSplice installation does not have the Google Protocol Buffer feature enabled, then Tuner should not prompt the user for type evolution choice, since it wouldn't affect anything. Solution: If the Google Protocol Buffer feature for OpenSplice is not included in the installation, then the type evolution choice in OpenSplice Tuner will not appear. |
OSPL-8583 | Possible memory leak when reader is removed with uncommitted transactions When a reader was removed that still had unread complete transactions it was possible that the transaction leaked. Solution: Updated the internal transaction administration so that when a reader is removed so are its transactions. |
OSPL-8596 | Wrong dispose in protobuf example In the protobuf example, the 'Person' protobuf type has 2 key fields : name and worksFor.name. The publisher code first writes a sample with name="Jane Doe" and worksFor.name="Acme Corporation". Then it is supposed to dispose this instance but in fact disposes another instance as it only sets the name field to "Jane Doe" but does not set the worksFor.name field. Solution: The worksFor.name is now also set for the dispose. |
OSPL-8609 | When coherent group access is used a resource claim regarding the resource limits of the group is performed twice. When coherent access is used then the resource counters maintained in the group regarding the resource limits set on the group are decremented twice. This may cause samples loss because of the incorrect resource counters in the group. Solution: The group resource claim on the resource limit is performed only once for each coherent transaction. |
OSPL-8618 | When the durability client receives an event to request historical data while the subscriber is being destroyed, the durability client could crash when it tries to handle the event. When the durability client receives an event to request historical data from a reader, the durability client will asynchronously determine the partitions for which data must be requested from the reader's subscriber. In case the subscriber has just been destroyed then the durability client tries to determine the partitions from a non-existent subscriber. This inevitably leads to crash. Solution: Before determining the partitions from the reader's subscriber a check is added to see if the subscriber exists. If the subscriber exists it is made sure using refcounting and locking that the partitions can be obtained, even if another thread is in the process of destroying the subscriber. |
OSPL-8640 | C++ RMI applications may crash on Windows when compiled with VS 2015 C++ RMI applications may crash on Windows platforms when compiled with the Visual Studio 2015 compiler. The problem is that constructors of classes call the default constructor of its virtual parent class explicitly. However, that default constructor is not implemented. Solution: These explicit calls to default constructors have been removed. |
OSPL-8643 | A durability service that cannot act as aligner for a namespace does not merge when its fellow aligner re-appears within the expiry time A durability service can be configured as non-aligner (alignee) for a namespace, in which case it is dependent on a fellow durability service (master) to provide historical data for this namespace. When the alignee looses its master (e.g., due to a disconnect) there is no durability service to provide historical data for this namespace, and the namespaces of the aligner and aligner may diverge. When a reconnect appears the master suddenly becomes available again, and the alignee should trigger a merge action to resolve the potentially diverged state. This was not happening in case a master appears with the expiry time. Consequently, the alignee may end up in a diverged state. Solution: When a master of an alignee disconnects from the system, the namespace state is cleared and its master is reset. As soon as an aligner appears a master conflict is detected and a merge will be triggered. |
TSTTOOL-372 / 16541 TSTTOOL-379 / 16578 | Python Scripting Engine should support reading or writing to non-default partitions The python scripting engine was connecting to on the default partition (the partition with an empty name) for all readers and writers. Solution: With this fix, the scripting engine connects by default using the partition name pattern '*', which is consistent with Tester's behaviour. In addition, it is now possible to explicitly create subscribers and publishers, and to explicitly provide the desired partition name/pattern. |
TSTTOOL-373 / 16541 TSTTOOL-378 / 16578 | Python Scripting Engine should support setting QoS settings on entities The Python scripting engine did not allow specification of Quality of Service (QoS) policies when creating entities Solution: all readers and writers were configured with default policies. With the fix, it is now possible to specify QoS policies on the following entities: readers, writers, publishers and subscribers. |
TSTTOOL-391 | Python Scripting Engine should support WaitSets The python scripting engine did not permit creation of wait sets. Solution: With this fix, a WaitSet class has been implemented, and it is possible to add Read Conditions to the wait set. Note that the WaitSet implementation does not yet support Status conditions or Query conditions. |
OpenSplice v6.6.3p1
Fixed bugs and changes not affecting the API in OpenSplice 6.6.3p1
Report ID. | Description |
---|---|
OSPL-8547 / 16628 | Topic definitions from KV-persistent store are not announced to other nodes Topic definitions from the kv-store are not announced to other nodes. If no application on that other node has already registered this type definition the situation can occur that the durability service will not reach the operational state. Solution: The kv store will announce the topic definitions found in the persistent store to all other nodes |
OpenSplice v6.6.3
Fixed bugs and changes not affecting the API in OpenSplice 6.6.3
Report ID. | Description |
---|---|
OSPL-7457 | Interoperable transient-local support. Transient-local was handled as transient data, but in combination with running DDSI as network protocol, data sometimes got delivered multiple times. Solution: In cases where DDSI is the network protocol, historical transient-local data is delivered by the DDSI2(E) service and no longer by the durability service. |
OSPL-7515 / 15645 | When the merge policy for a namespace that is responsible for builtin topics is different from IGNORE or MERGE, the system state can become inconsistent. In the configuration a user can specify merge policies for namespaces. These merge policies specify how to resolve state diverge due to disconnections. If the merge policy that is specified for the namespace that is responsible for the builtin topics is different from IGNORE or MERGE then the internal state of the system can become inconsistent. This is undesirable and should be considered as an invalid configuration. Solution: The durability service now terminates when the merge policy that is specified for the namespace that is responsible for the builtin topics is different from IGNORE or MERGE. Termination will only occur when the durability service is responsible for builtin topic alignment. |
OSPL-8044 | Undesired timeout on wait_for_historical_data without durability When durability is not enabled, a wait_for_historical_data call would still block during the timeout-period, even though no historical data will be delivered to a reader without a durability service. Solution: A check was added to determine if durability is used. If not, wait_for_historical_data will return precondition_not_met instead of blocking and returning timeout. |
OSPL-8306 / 16511 OSPL-8096 / 16183 OSPL-8313 / 16513 OSPL-8314 / 16514 OSPL-8315 / 16512 | The networking service may crash when a reconnect occurs under high load conditions. When the networking service determines that another has not reacted in time and is removed from the reliable protocol and shortly thereafter the just removed node is reconnected it may occur that some variables related to this node are not correctly initialized to their default values. Solution: The state variables that the networking service maintains for the participating nodes are set to their default values when the node is removed from the reliable protocol. This ensures that when a node is considered alive again that the node related information has the correct state. |
OSPL-8310 | Statistics not enabled when not explicitly setting enabled attribute to true. When not explicitly configuring the enabled attribute of the //OpenSplice/Domain/Statistics/Category element and setting it to true, the statistics for that category are not enabled. Solution: When not configuring the enabled attribute it is now interpreted as having the true value set. |
OSPL-8311 | ThrottleLimit configuration does not accept human-readable sizes as input. The //OpenSplice/NetworkService/Channels/Channel/Sending/ThrottleLimit provides the lower bound for throttling and is really a size in bytes. Until now this value would not accept human-readable sizes. Solution: Human-readable sizes can now be used as input for ThrottleLimit |
OSPL-8391 / 16538 OSPL-8462 / 16573 OSPL-8467 / 16579 | The reception of a dispose message may cause a crash when the corresponding instance has been removed. When a dispose message is received the corresponding datareader instance is lookup using the corresponding group instance. However in the mean time the datareader instance may have been removed. The dispose message will than trigger the creation of a new datareader instance but at that time the key information present in the dispose message is not available which may cause access to an invalid pointer value. Solution: When the datareader receives a dispose message for an instance that is removed the dispose message will be dropped because it will not result in any state change. |
OSPL-8439 / 16570 | Include dependency for constant declarations missing in idlpp. When declaring a constant in an IDL file whose type is taken from an included IDL file, idlpp forgets to take the include dependency into account. This means that the generated code will refer to a type from another generated file, but the first file will not include the second file, resulting in compilation errors. Solution: The missing dependency has now been added to idlpp. The type of a constant declaration will now be properly included if located in another file. |
OSPL-8477 / 16597 | Registering a protobuf-modelled type multiple times leaks memory When registering a type, its meta-data gets stored as well to allow tools to generically create datawriters and datareaders without the need for pre-compiling the type information into the tools. When registering a protobuf-modelled type with the same DomainParticipant multiple times, the definition leaks away though due to a missing deallocation. Solution: the missing deallocation of the duplicate type in the type registration algorithm has been added. |
OSPL-8480 / 16599 | Ordered_access does not always suppress invalid samples correctly. When using ordered_access when reading/taking data, some additional (invalid) samples could appear that you would normally not see when reading from a similar Reader that is not using ordered_access. This is caused by the fact that normal DataReaders suppress invalid samples when they can mask those invalid samples by valid samples for the same instance. However, in case of ordered_access, this suppression mechanism was not being applied. Solution: The suppression mechanism for invalid samples is now also applied to DataReaders that use ordered_access. |
OSPL-8488 / 16604 | Coherent access in combination with resource limits can results in not receiving sample updates. When using coherent access in combination with resource limits and max samples per instance is set to 1 it could be that samples are not being received by the datareader. Solution: The defect in the datareader mechanism is resolved and samples are being properly received. |
OSPL-8497 / 16613 | ArrayIndexOutOfBoundsException can occur during termination when using waitsets in the Java API. When using the Java API in combination with waitsets an ArrayIndexOutOfBoundsException can occur during termination of the middleware. Solution: The defect in the waitset mechanism is resolved and the exception will not occur anymore. |
OSPL-8508 | DCPSPublication samples maintained longer than necessary. In some cases, samples for the DCPSPublication topic were maintained longer than necessary by spliced. Even though eventually spliced would reclaim the memory, this appeared as if there was a memory leak. Solution: The processing of the samples by spliced has been changed, so that cleanup happens as soon as possible instead of deferre |
TSTTOOL-369 / 16350 | Tester in Jython does not support float.Nan values in check method In the provided Python Scripting Engine example, a Topic's float member with a NaN value could not be checked and the check function would return false. Solution: The _checkPyobj(pyobj, checkValues, logFailures = False) function in $OSPL_HOME/tools/scripting/examples/tester_compat.py has been modified to handle this case. |
TSTTOOL-376 / 16517 | Install Jython for ospltest scripts. When installing Jython on Windows platforms following the instructions in the Tester User Guide, users would be unable to install the library due to spaces in the OSPL_HOME environment variable. Solution: Updated the documentation to have quotes around the environment variables that could have spaces on Windows. |
OpenSplice v6.6.2p4
Fixed bugs and changes not affecting the API in OpenSplice 6.6.2p4
Report ID. | Description |
---|---|
OSPL-8139 | Durability creates defaultNamespace when configuration is invalid. The durability service can silently ignore an invalid configuration (i.e. no namespaces and/or policies are included, or are not consistent). In that case the service applies the default configuration, i.e. a defaultNamespace with initial alignment and alignee policy. Since namespaces are also exchanged with other durability services in a domain, the resulting behaviour of the mis-configured node, but also other nodes, may be far from what the user expects. Solution: Instead of silently applying default configuration parameters, the service now refuses to start in case the configuration is missing or invalid, reporting relevant errors to the OpenSplice error log. |
OSPL-8221 / 16391 | DataReader may crash when using ordered_access. The administration of a DataReader that has a PresentationQos with ordered_access set to TRUE may become corrupted when all available samples are taken out of the DataReader. This corruption might in turn result in a crash of the publishing (when on the same federation as the corrupted reader) or subscribing application. Solution: The ordering mechanism has been fixed so that taking the last sample out of a Reader with ordered_access set to TRUE can no longer corrupt the Reader's administration and therefore no longer crash your applications. |
OSPL-8234 | Samples written without begin_coherent_changes broke ordering Samples (including implicitly created samples like unregister on writer deletion) written with a coherent writer without calling begin_coherent_changes first could be delivered out of order and during a begin_access. Solution: For a coherent writer every sample is now part of a transaction. A write without a previously called begin_coherent_changes now does this implicitly. This ensures in order delivery and samples are no longer delivered after calling begin_access. |
OSPL-8288 / 16504 OSPL-8289 / 16503 | The use of the newly introduced detachAllDomain functionality occasionally resulted in processes blocking or crashing when detaching and terminating. The problem was caused by two reasons: some internal participant threads that remained active where they should have stopped during the detachAllDomain call. when an application listener callback blocks in application code OpenSplice failed to detect that it was safe to terminate. As a result the detachAllDomain failed and depending on the parameter values it could either hang or fail. In case of a failure the detachAllDomain returned with OK and the application process continued to terminate which then caused a crash because the remaining thread where still accessing shared memory while being unmapped from process space. Solution: The ordering mechanism has been fixed so that taking the last sample out of a Reader with ordered_access set to TRUE can no longer corrupt the Reader's administration and therefore no longer crash your applications. |
OSPL-8442 OSPL-8435 / 16568 OSPL-8427 / 16564 | The method detach_all_domains may fail when a listener callback is blocking. The listener callback is called from shared memory context which means that the thread that is executing the listener callback is registered as using shared memory resources. The detach_all_domain method will try to have all threads that are executing from shared memory context to either leave the shared memory context or to block which would allow the shared memory to be detached safely. Thus when the listener callback is blocking in the application context the detach_all_domain method will fail with a timeout because this thread is still listed as using shared memory resources. Solution: When an application listener callback has to executed the thread that has to call this callback first releases the shared memory resources it is using and leaves the shared memory context before calling the callback. |
OSPL-8443 | The function DDS_wait_for_historical_data_w_condition() does not handle the special value DDS_TIMESTAMP_INVALID correctly. The function DDS_wait_for_historical_data_w_condition() allows an application to provide conditions on the historical data to request. In particular, timestamps to indicate the interval when data was produced can be specified. The special DDS_TIMESTAMP_INVALID can be used for both the lowerbound and upperbound of the interval and should be interpreted as don't care. Due to an error these special values where not handled correctly, causing these values to be interpreted as invalid parameters and causing the DDS_wait_for_historical_data_w_condition() to return with BAD_PARAMETER return code. Solution: The error is fixed, so DDS_TIMESTAMP_INVALID is now considered a valid value. Note that this issue has currently only been fixed for the C language binding. Other language bindings will be fixed in a future release. |
OpenSplice v6.6.2p3
Fixed bugs and changes not affecting the API in OpenSplice 6.6.2p3
Report ID. | Description |
---|---|
OSPL-8205 / 16386 | Exception in thread ListenerEventThread causes NullPointerException. When using the Java API with listeners a NullPointerException can occur when deleting an entity which has a listener attached. Solution: The cause of the fault is still unclear but a workaround has been implemented to catch the exception so the listener will terminate correctly. When this happens a trace will also be added to the ospl-error.log |
OSPL-8388 | dbmsconnect example configuration fails to get open with configurator The dbmsconnect example XML configuration contains a '<>' as part of an SQL filter expression, but this needs to be escaped in XML for the XML to be valid. Even though dbmsconnect is able to cope with this file, the configurator tool is not accepting this invalid XML. Solution: The '<>' statement has been escaped in the XML file as '<>'. |
OpenSplice v6.6.2p2
Fixed bugs and changes not affecting the API in OpenSplice 6.6.2p2
Report ID. | Description |
---|---|
OSPL-6586 | Coherent updates are not always delivered to DataReaders for a ContentFilteredTopic. ContentFilteredTopic DataReaders filter out samples that do not match the filter. Samples that are filtered out purely on key-value do not even get offered to the DataReader as they are filtered out a bit earlier in the process. For coherent sets, the DataReader, even though filtering out the sample, still needs to receive the sample to determine completeness of a coherent set as it counts all samples and compares this count with the expected number provided by the publisher. Therefore not receiving all samples results in an incorrect count and the complete coherent set not being made available to the application. Solution: For ContentFilteredTopic DataReaders, all samples are now delivered for counting purposes but immediately dropped afterwards so that no resources are consumed but completeness can be verified. Although samples are dropped, some additional administration is required to keep track of the data completeness and as a consequence some extra memory is kept during the time the coherent set is not completed yet. |
OSPL-7601 | DDSI2 service lacks support for transient-local history settings of KEEP_LAST with depth > 1. The DDSI2 service maintains transient-local data in accordance with the DDSI specification, but only implemented support for KEEP_LAST with depth 1. For OpenSplice this is more-or-less a non-issue as the durability service handles the history correctly anyway, but when interoperating this could be a restriction. Solution: The history maintained by DDSI now fully supports all history QoS settings. |
OSPL-7893 | The durability service may select conflicting masters after a reconnect. When a reconnect occurs the durability service has to determine a new master. When a reconnect occurs the master selection procedure will determine a new master in a number of rounds where information is exchanged between the durability fellows to reach conformity about the selected master for each namespace. However when the durability service is in the complete state the master selection procedure selects a master to early which causes that the durability fellows may select different masters causing the potential merge of historical data to fail. Solution: When in the complete state and a reconnect occurs, the master selection now waits during each stage of the master selection until all information has been received from the other fellows about their master selection. |
OSPL-8114 | When publishing a coherent set during durable data alignment, transactions may never become complete. When publishing a transaction during alignment of durable data it is possible that a transaction never became complete as it could receive parts of the transaction in twofold, each received part of the transaction was counted and used to determine completeness. In this case the transaction never became complete as the expected count was lower then the actual count. Solution: The transaction mechanism has been updated to handle duplicate messages. The internal group must be complete before the readers receive the EOT markers. |
OSPL-8126 | When the durability service terminates while rejected samples still need to be delivered to the readers, then termination is stalled until the samples are delivered. When the durability service receives alignment data it tries to deliver the data in the readers. When delivery is rejected (e.g., because the reader has reached its resource limits) then the durability service will periodically retry to deliver the data. In case the durability service must terminate while periodically retrying to deliver rejected samples, then termination will only succeed after all samples have been delivered successfully. This negatively affects responsiveness of the durability service in case of a termination request. To improve responsiveness the durability service should not wait until all samples have been delivered when it is requested to terminate. Solution: The durability service does not deliver rejected samples anymore when termination occurs. |
OSPL-8136 | Possible missing of async RMI replies when server exits and starts again A C++ RMI client may miss replies from a server when a server replies to an asynchronous request and exits, then it is re-started again to process other requests whereas the client remains active. The reply instance is then disposed and as the client takes the replies, it receives an invalid sample that disturbs the replies management and makes RMI miss the following valid replies. Solution: Invalid samples for the RMI replies datareader have been disabled at the client side. |
OSPL-8152 / 16371 | Crash in the shared memory monitor thread due stacksize limitation. When using a datamodel with a lot of indirections and nesting and experiencing an application, the shared memory monitor crashes too, because it runs out of stack space during its attempt to clean up application resources. Solution: It is now possible to configure the stack size for all splice daemon threads found in the configuration section //OpenSplice/Domain/Daemon. Each thread now has an additional element "StackSize" which can be set to the desired size. An example to set the shmMonitor stack to 1 Mb: |
OSPL-8172 | PublicationInfo for group coherent writer notification unsafe. When the splice daemon receives a PublicationInfo message that describes a coherent writer, a notification is sent to the publisher in an unsafe way, which caused potential multithreaded manipulation of the internal cached writer administration in the coherency mechanism. Solution: Made the notification threadsafe. |
OSPL-8185 / 16385 | Potential crash during simultaneous creation and deletion of a shared DataReader/Subscriber There is a race condition in the implementation of shared DataReaders/Subscribers, where if you simultaneously delete the last occurence of a shared Reader/Subscriber while at the same time creating a new reference to it, the system might end up crashing. Solution: The race condition has been removed. It is now possible to safely remove the last occurence while at the same time creating a new reference to it. |
OSPL-8189 | Group coherent reader can access subscriber after deletion. After deletion of the subscriber a group coherent reader may still try to access the subscriber, which causes a crash. Solution: The data reader has a back-reference to the subscriber , which is now removed in a threadsafe manner and checked before trying to access the subscriber. |
OSPL-8191 | After calling begin_access, historical data could still be delivered to a group coherent reader. Reader creation retrieves historical data with the begin_access (read)lock instead of with the access (write)lock. This can cause data to change after a begin access in a multithreaded environment. Solution: Historical data is now retrieved within the access (write)lock. |
OSPL-8208 | C# API Waitset.wait causes NullReferenceException. When using the C# DDS API with waitsets a NullReferenceException may occur when using the Waitset.wait call. Solution: The fault in the waitset handling for C# is fixed. |
OSPL-8212 / 16390 | RTI/TwinOaks interoperability issue with "autodispose_unregistered_instances" QoS RTI and TwinOaks have a different interpretation of the "autodispose_unregister_instances" writer QoS, which could cause unexpected disposes of instances in OpenSplice when a RTI or TwinOaks writer disappears. Solution: The DDSI2 service has been modified to distinguish between OpenSplice and non-OpenSplice peers when defaulting the QoS setting, eliminating these unexpected disposes. |
OSPL-8222 | Multi-partition Publishers don't disconnect properly from all targeted partitions. Publishers that are connected to multiple partitions can cause problems when they need to disconnect from one or more of their partitions (for example because the PublisherQos is changing one or more partitions or because the writer is deleted.) These problems manifest themselves by not properly sending unregister messages to all targeted partitions, which may cause the InstanceState not to go to NO_WRITERS when it should and which may cause v_registration objects to leak away in the shared memory. Solution: Multi-partition Publishers now disconnect properly from all targeted partitions, which should result in the correct InstanceState for all partitions and which should remove the leaking of v_registration objects. |
OSPL-8224 | Spinning waitset when an empty coherent set is received. A data_available notification was sent to all readers part of a transaction even when it did not have data. A waitset with a following get_datareaders (which returned 0 readers) could then enter a spin loop when no read to reset the data_available flag was done. Solution: data_available notifications are now only sent to readers which have data. |
OSPL-8233 | Completing a pending group coherent transaction could cause a crash after reader deletion. When a group coherent transaction becomes complete it is added to a pending list. This pending list is flushed to the readers upon call to begin_access. When a reader was deleted the begin_access still tried to flush the deleted readers part of transaction which could cause a crash. Solution: Data for the removed reader is now removed from the pending list on deletion of that reader. |
OSPL-8267 / 16494 | DDS protobuf compiler fails when including more than one depth-of-directory. When proto files include others that are in different directories with more than one level difference, the DDS protobuf compiler plugin would fail to generate code as the output directory for the generated code was not created recursively, causing the directory creation to fail and therefore code generation would fail alltogether. Solution: The code generator has been modified to create directories recursively in all situations. |
OSPL-8268 | detach_all_domains operation doesn't return a failure when something went wrong. The detach_all_domains function always return result OK. Even though no DDS call can be made afterwards, it may still prove useful to know if all was well. Solution: The function now doesn't return OK anymore in case of a detectable failure. In case it took too long to wait for threads to leave shared memory, TIMEOUT will be returned. |
OSPL-8271 | isocpp2 target for idlpp crashes on enum in outer scope. When idlpp attempts to compile an IDL file that has an enum in the outer scope (i.e. not embedded in a module) to the isocpp2 target, it crashes with a segmentation violation. Solution: The crash has been fixed in idlpp. |
OSPL-8302 / 16505 | The detach_all_domain operation may cause a process to crash due to a race condition. When detach_all_domains returns successfully it has detached the shared memory segments from the process. Before that, it will deny all threads access to the shared memory segments. However, a race condition exists, which may cause a thread still to be in a critical section after the unmapping the shared memory from the process. The aforementioned thread may try to access an object in shared memory, which causes a crash of the process. Solution: The detach_all_domain operation now waits for all threads to have left this critical section before unmapping the shared memory segment(s) from the process. |
OpenSplice v6.6.2p1
Fixed bugs and changes not affecting the API in OpenSplice 6.6.2p1
Report ID. | Description |
---|---|
OSPL-7947-1 | Transaction sample received twice, as historical data and as normal write, causing the transaction to never become complete When reader was created it asynchronously connected and requested historical data making it possible to receive the same sample via historical data and the normal path, this sample was counted twice which caused the transaction to never become complete. Solution: A reader now connects and requests historical data synchronously so that the sample is not received twice and the transaction now becomes complete. |
OSPL-7947-2 | When discovering a transactionWriter implicitly is was possible that transactions with same writer never became complete The group transaction mechanism has two ways of discovering writers one via builtin topics and an implicit discovery when data from that writer is received. In the latter situation it was possible that transaction which were depended on the same writer never became complete. Solution: When a writer is implicitly discovered check all open transactions for dependency on the writer and mark the writer as discovered so that the transaction can become complete. |
OSPL-6395 / 14540 | Integration with Rhapsody 8.x The name of the abstraction-layer header file ("os.h") was too generic and caused a collision with a file by the same name belonging to IBM Rhapsody. To prevent this, and other potential name clashes in the future, the file was renamed to "vortex_os.h" Solution: In case the C language-binding is used, this header file is included in idlpp-generated code. This means code generated by a previous version of OpenSplice cannot be compiled using the new header file and should be regenerated first. Applications already compiled for a previous version are not affected. |
OSPL-7562 | Durability service does not handle default partition properly in name-space configurations The OpenSplice durability services exchange name-space information before starting alignment of historical data. If name-space contents do not match, services refuse to align each other. The algorithm that does the comparison of the expressions has a problem dealing with the so-called default partition (this is an empty string). This leads to an incorrect interpretation of ". Solution: The flawed algorithm has been corrected to deal with the default partition properly too. |
OSPL-7601 | DDSI2 lacks support for transient-local history settings of KEEP_LAST with depth > 1 The DDSI2 service maintains transient-local data in accordance with the DDSI specification, but only implemented support for KEEP_LAST with depth 1. For OpenSplice this is more-or-less a non-issue as the durability service handles the history correctly anyway, but when interoperating this could be a restriction. Solution: The history maintained by DDSI now fully supports all history QoS settings. |
OSPL-7687 | bundled throughput-example doesn't work correctly on windows The bundled throughput examples uses a flawed algorithm to determine how long an action takes. Solution: The flawed algorithm has been corrected. |
OSPL-8121 / 16218 | Incorrect publication_handle in received SampleInfo The publication_handle in the SampleInfo object of a recieved Sample was previously being set to the same value as the instance_handle, this was incorrect. Solution: The SampleInfo::publication_handle() now returns the correct publication_handle as expected. |
OSPL-8124 | Improve group transaction flush mechanism. The group transaction flush mechanism was inefficient as it used an unnecessary list Solution:The unnecessary list has been removed |
OSPL-8144 | Java5 listener may trigger before entity is fully initialised. Entities created throughout the Java5 API, which have a listener attached at creation time may cause problems as the listener may trigger before the entity is fully initialised. Solution: Listener callbacks are now blocked until the entity is fully initialised |
OSPL-8149 | Server-part of client-side durability protocol must be enabled for all default shared memory configurations. The durability service has a feature to react to requests from clients that have an interest in historical data but are not able (or willing) to run a durability service themselves. To have a durability service react to such requests a configuration option //Opensplice/DurabilityService/ClientDurability[@enabled] exists that must be explicitly set to TRUE. This is not very user-friendly and hampers a seemless out-of-the-box experience. For that reason the client durability feature will also be enabled now when the //Opensplice/DurabilityService/ClientDurability-element is present without the [@enabled]-attribute. Furthermore, for shared memory configurations that are part of the distribution this feature is enabled by default. Solution: Durability services now will react to client requests when the //Opensplice/DurabilityService/ClientDurability-element is present without the [@enabled]-attribute. Furthermore, default shared memory configurations have been updated so that the client durability feature is enabled. |
OSPL-8151 / 16355 OSPL-8159 / 16376 | JVM crash when creating a participant with an own set name for the thread creating the participant. When using the Java API and the thread creating the participant has an own set name the JVM crashes. Solution: The defect is solved and the JVM will not crash anymore on an own set thread name. |
OSPL-8157 | Coherent updates do not get delivered when using a wildcard partition. When a Publisher is publishing coherent updates in a wildcard partition (a partition that uses a wildcard like '*' or '?'), or a Subscriber is subscribing to a wildcard partition, then coherent updates are not correctly matched between Publisher and Subscriber and the contents of the coherent update will be lost. Solution: Wildcard partition matching between Publisher and Subscribers has been improved: either the Publisher or the Subscriber can now use a wildcard partition without impacting the coherent update. However, if both Publisher and Subscriber use an unequal yet matching wildcard partition a mismatch may still take place. Fixing this scenario is left for a future update. The issue was already captured in the known issues list under OSPL-973 |
OSPL-8161 / 16377 OSPL-8071 / 16171 | NullPointerException in the ListenerThread when using Java When using the Java API and a listener is used on an entity it can happen that the ListenerThread causes a NullPointerException when the entity is removed. The info logfile will then also show the following messages "timeout or spurious wake-up happened x times." Solution: The defect is the listener mechanism is solved and the deletion of an entity will cause no more exceptions/info messages |
OSPL-8169 | In case of group coherent updates where more than one transaction is involved and simultaneously both become complete by actions on different readers a deadlock occurred. A cross locking deadlock situation involving the reader lock and group lock caused the problem, when an action performed on a reader leads to a complete transaction it will lock the group to notify about the completeness, if the group itself then also become complete and notify all other readers, this last step takes the locks in reversed order and will lead to a deadlock when two transactions become complete by two simultaneous actions on different readers. Solution: The group now releases the lock before notifying all other readers. |
Fixed bugs and changes affecting the API in OpenSplice 6.6.2p1
Report ID. | Description |
---|---|
OSPL-7688 | Query interface supports non-ISO compliant '!=' operator again. In a previous release the non-ISO compliant operator '!=' was removed from the supported SQL syntax. This was done in an effort to provide one common and standards compliant SQL parser for all the various services/languages in the product (where previously different components could use different parsers that supported different syntaxes). However, although the operator in question was non-ISO compliant and never advertised in our documentation, many users already used in in their applications. Solution: The '!=' operator has been added to the supported SQL syntax of our SQL parser. |
OpenSplice v6.6.2
Fixed bugs and changes not affecting the API in OpenSplice 6.6.2
Report ID. | Description |
---|---|
OSPL-5028-1 | Launcher - Choosing a file for OSPL_URI that is not an OpenSplice configuration file results in errors. In the OpenSplice Launcher Settings, under the Environment tab, if one were to use the file chooser to set the URI or the Lice nse field, and selected a file type that is not meant to go there, errors would be reported in the log and Launcher would otherwise not guard against any attempts to process the invalid files. Solution: For the file chooser dialogs for the URI and the License fields, an extension filter has been added to only show only .xml and .lic files respectively. |
OSPL-5028-2 | Launcher - NullPointerExceptions get printed to console every time a configuration is selected. Whenever a OpenSplice config is selected from the configurations table, a NullPointerException and stacktrace would get printed to the console, due to a unchecked return from the examples table selection model. Solution: The accessed to the examples selection model are properly checked for null returns. |
OSPL-7087 / 15090 | Adding support to an unexpected stopping of the underlying DDS middleware to the java RMI library. When the DDS middleware stops (normally or not) while a RMI server is waiting for or processing rmi requests, the RETCODE_ALREADY_DELETED error code should be handled properly. Solution: The RMI implementation shutdowns the RMI server in case it receives a RETCODE_ALREADY_DELETED that signals a stopping of the DDS middleware. This will unblock the server application thread that was running the RMI runtime to wait for the requests. Note that the DDS middleware must not be stopped before the RMI application has stopped, whatever it is at the client or the server side. Even if the RMI library has been updated to handle an expected stopping of the DDS middleware, the user application cannot continue to work well. |
OSPL-7283 / 15405 | GettingStartedGuide is missing information about how to install OpenSplice on UNIX ARM platform. The procedure to install OpenSplice on a UNIX ARM platform is missing from the GettingStartedGuide. Solution: The GettingStartedGuide is extended with a description of the OpenSplice installation on a UNIX ARM platform. |
OSPL-7317 | Not possible to create reader for builtin topic DCPSType Not possible to create reader for builtin topic DCPSType, because Typesupport for DCPSType was not mapped on the kernel representation as is required for builtin types, the typesupport was not registered and the DCPSType reader was not created for the Builtin Subscriber. Solution: DCPSType typesupport is now generated correctly and registered and a DCPSType builtin reader is created. |
OSPL-7346 | Truncation of max file size configuration values on 32-bit platforms An issue in the configuration file processing caused truncation of the MaxFileSize RnR storage parameter on 32-bit platforms. Solution:To resolve the issue, configuration processing was improved. In addition to resolving the truncation, it now supports floating point values and the following list of units: b, B (bytes) , KiB, kB, K, k (=1024 bytes), MiB, MB, M, m (=1024KiB), GiB, GB, G, g (=1024MiB), TiB, TB, T, t (=1024GiB) |
OSPL-7618 / 15802 | Readcondition and ContentFilterTopic could lead to a memory leak in isocpp2 When using a Readcondition or a ContentFilterTopic in isocpp2 it is possible that they are not properly cleaned up after removing them cauing a memory leak. Solution: The leak has been fixed. |
OSPL-7627 / 15740 | Queries/Filters had problems with literals representing fields of type "unsigned long long" (uin64_t). Queries/Filters were not able to parse literals of type "unsigned long long" whose value were between MAX_INT64 and MAX_UINT64 correctly. Solution: The parser has been fixed. |
OSPL-7686 / 15837 | Deleting a domain (last participant from a domain) doesn't free all used resources correctly in single process mode. Deleting a domain (last participant from a domain) doesn't free all used resources correctly in single process mode. Solution: By setting the database size in single process mode the database will be allocated on heap and used by the memory manager in opensplice. Deleting the domain with this database results now in a correct cleanup off all used resources. Note: In previous versions the Size attribute for the Database element in the configuration had no meaning and was ignored. All available heap memory was available for the domain service. With the current implementation the database size is limited to the configured size and memory is managed by the ospl memory manager. Size 0 is default and will force the old unlimited behavior where the operating system memory manager is utilised. |
OSPL-7694 / 15847 | Problem with string writing in the Tuner. When using the Tuner and writing a string unbounded or bounded square brackets are always added to the input. Solution: The writing mechanism is changed and no more square brackets are added. |
OSPL-7723 / 15852 | Suppress default logs true provides null data to report plugin. When using a report plugin with the option SuppressDefaultLogs set to TRUE and the element TypedReport set in stead of Report results in null data inside the specified report log. Solution: The report plugin is adjusted so that in this scenario the reports are passed to the specific log file. |
OSPL-7743 / 15912 | Possible missing of some async replies when their server exits. The problem may occur when a server replies to an asynchronous request and exits, then it is re-started again to process other requests whereas the client remains active. The reply instance is then disposed and as the client takes the replies, it receives an invalid sample that disturbs the replies management and makes RMI miss the following valid replies. Solution: Disabling the invalid samples for the replies datareader at the client side. |
OSPL-7762 | DDSI declaring readers on slow machines "non-responsive". DDSI2's flow-control was extremely sensitive to the configuration of the maximum allowed amount of unacknowledged data in a writer, the relative speeds of the machines and the networks and the socket receive buffers on the subscribing nodes. Solution: DDSI2 now dynamically adapts the maximum amount of unacknowledged data, based on retransmit requests. The adaptation can be disabled for increased predictability if required. |
OSPL-7772 | Missing samples after CATCHUP or REPLACE merge has occurred. When nodes reconnect and a CATCHUP or REPLACE merge policy has been configured, then alignment takes place. It turns out that the alignment data contains the right amount of data, but after injection of the data in the system there are less samples than expected. This phenomenon was caused due to an incorrect administration of the last dispose time which prevented that data that has been produced before the last dispose time could be inserted. In case a foreign state conflict appears and there is no aligner, rediscovery of an aligner would not lead to a merge. Solution: The last dispose time is not set when alignment for CATCHUP or REPLACE takes place, and rediscovery of aligners in case of foreign state conflicts is fixed. |
OSPL-7777 | Launcher should display the reason why tools cannot be started. If Java is not installed on the host machine from which Launcher is started, the tools cannot be started even though the buttons are enabled. Solution: In order to help troubleshoot incompatibilities between our tools and other Java implementations, Added another environment variable JAVA_HOME that would get picked up by Launcher from the user's environment (just like the other variables) and allow the user to specify/override their own JAVA_HOME path within the tool. Launcher will detected if a JRE and JDK are installed. When modifying the JAVA_HOME environment variable in Launcher or starting Launcher with a JAVA_HOME set to a non-officially supported Java implementation (OpenJDK, IBM Java, etc), a notification will come up indicating what Java implementation was picked up and that it is not officially supported for running the tools and building/running the examples. The tools and examples will remain enabled in this case. The tool buttons are disabled and a message is displayed that Java is not detected in JAVA_HOME. The buttons will re-enable once a valid Java install directory is specified in JAVA_HOME. |
OSPL-7814 / 15970 | IllegalMonitorStateException when using the java API in combination with a listener When using the Java API in combination with a listener an IllegalMonitorStateException could occur. Solution: The cause of the exception is fixed in the listener handling. |
OSPL-7816 / 15972 | Durability service doesn't notice disconnection. When using durability in combination with RTNetworking it could happen that when the network connection is lost the durability service is not notified about this. Solution: The defect in the disconnect mechanism is fixed and durability now gets the disconnect notification. |
OSPL-7823 | As a user, I want to be able to preview all the environment variables. Allow the user to preview the environment variables that are available to the user through Launcher. Solution: A new Preview Environment Variables dialog is available to the user through the Preview button in the settings environment tab. The new dialog allows the user to preview the configured environment variables and copy to the clipboard. |
OSPL-7839 / 15981 | Generation error in C# backend of idlpp When compiling an IDL file that specifies an array of enumerations, the C# backend of idlpp would generate a statement that contained a superfluous bracket, which caused a compilation error in the C# compiler. Solution: The C# backend of idlpp has been fixed by removing the superfluous bracket. |
OSPL-7852 / 15991 | Warning during compilation in isocpp2 When compiling an application that uses isocpp2 a warning can occur in State.hpp. Solution: The warning has been fixed. |
OSPL-7854 / 15990 | Coherent Set transaction do not proper process dispose messages. When a coherent set with a dispose message in it is used it can happen that the dispose is not proper handled causing late joiners to allign the disposed message with the status NOT_ALIVE_DISPOSE_INSTANCE_STATE where the message would be expected to be completly gone from the system. Solution: The coherent set mechanism is updated to handle dispose messages correctly. |
OSPL-7857 / 15988 OSPL-7697 / 15841 | Memory could leak away when instances are recycled aggressively during an overflow of the networking queue. When an instance is unregistered but quickly brought back to life (by writing/disposing a sample with the same key), there is a small chance that in case of an overflow of the network queue some memory is leaking away. Solution: The memory leak has been fixed. |
OSPL-7865 | Enable java debug symbols To improve readability of exception stack-traces and help with debugging java applications, symbols need to be included in the jars. Solution: symbols are now included in all jar files. As a result, the average size of jar files has increased ~25%. It is possible to rebuild the Corba-Java language-binding jar using the custom-lib build process. To create a jar without symbols please change the custom-lib build script, replacing -g by -g:none. |
OSPL-7876 | RT networking crash when using scoped discovery RT networking configurations relying on roles and scopes to restrict discovery of nodes could crash on an invalid memory reference upon discovering a new node. Solution: The issue has been corrected. |
OSPL-7877 | Durability merge policies can cause data loss For some merge policies durability needs to dispose all (or a particular subset) of the instances in a group, but it must not use the internal disposeAll functionality, as that implements the "dispose-all" operation that has an effect into the future. Because of that effect, old data could be lost following a CATCHUP/REPLACE/DELETE merge operation, including the data being aligned. Solution: The algorithm has been modified to no longer rely on this internal disposeAll functionality. |
OSPL-7889 | idlpp may crash when generating for the isocpp2 target idlpp crashes for the isocpp2 target when specifying an IDL enum in the outer scope (i.e. not in a module). Solution: idlpp has been fixed to correctly handle enums in the outer scope. |
OSPL-7890 | Group coherence: Avoid the partial alignment of historical group transactions A late joining Subscriber for group transactions may receive a group transaction partly as historical data and partly as incoming messages, this currently leads to invalid delivery of partially complete group transactions. Solution: Partly aligned group transactions now trigger full group alignment and remove all related transaction administration. |
OSPL-7895 | Tooling entities are not cleaned up after disconnecting Entities created by tools are no longer deleted when disconnecting the tool due to an incorrect reference count of entities in the C&M API. As a result entities remained available in the federation the tools ever connected to until the federation stops. Solution: Corrected the reference count for entities in the C&M API. |
OSPL-7924 | Add java5 and isoc++v2 DCPS examples to Launcher The titular DCPS examples were added to OpenSplice, but the Launcher tool currently does not have the capability to detect them and add them to the list of available language options. Solution: The Launcher tool has been updated to recognize the java5 and isocpp2 DCPS examples in a OpenSplice installation, and is able to execute build and run tasks for them. |
OSPL-7931 | DDSI2 possible crash when lease expiry coincides with termination During termination, DDSI2 would delete all proxy entities explicitly, without accounting for the possibility that leases could still expire. This could lead to freeing a proxy participant prematurely, resulting in a use-after-free when deleting the one remaining endpoint. Solution: This issue has been solved. |
OSPL-7932 | Group coherence: detect missing EOT message and discard associated pending transaction. As soon as a Subscriber receives a EOT message of a (group) transaction it knows for which writers it will receive EOTs, whenever an EOT or any data for other writer-transaction are missing but newer data for those writers is received then the Subscriber can conclude that the missing EOT and/or data is lost forever and subsequently discard the whole group transaction. Solution: Received messages of group coherent updates that will not become complete are now discarded. |
OSPL-7933 | Group coherence: Subscriber-side re-evaluation of completed transactions to assure data meets latest user expectation. An initializing Subscriber can receive transactions that match the Subscribers readers before all readers are created, meaning that data belonging to the reader to be created is not considered and possibly not delivered. Solution: Completeness evaluation of ongoing group transactions now consider creation of additional DataReaders that may affect completeness |
OSPL-7938 | In situations where the builtin topics do not have to be aligned, they where still being aligned in case the AutoBuiltinTopics namespace is generated When no namespace for the builtin topics is configured, a namespace called 'AutoBuiltinTopics' is created automatically for the builtin topics. When no builtin topic aligned is needed (e.g., when DDSI takes care of the builtin topics) it could still happen that the builtin topics were being aligned, even though they shouldn't. Solution: Alignment of builtin topics is prevented for the AutoBuiltinTopics namespace in case no alignment is needed for them. |
OSPL-7941 | Resource leak in application after closing domain in shared memory mode. If a domain is closed (last participant in an application for that domain is deleted) not all used resources were freed correctly in shared memory mode. Solution: Used resources are freed now for the closed domain. |
OSPL-7946 | Group coherence: ddsi crash during connection changed A crash may occur in the DDSI2 service when a connection change happens during a coherent update by an application. Solution: Crash during connection change has been fixed. |
OSPL-7947 | Group coherence: complete transactions sometimes do not get delivered Depending on timing, transactions, although complete, would not get delivered to application readers. Solution: Several bugs concerning race-conditions have been solved. |
OSPL-7948 / 16142 | Limitation on supported network interfaces. When using DDSi with more than 32 network interfaces it is possible that the requested network interface is not found and DDSi will report an error. Solution: The number of supported network interfaces is increased to 128. |
OSPL-7973 / 16144 | Java 5 QosProvider error reporting improvement. When using the QosProvider in Java 5 all errors with it resulted in a null pointer exception with no proper error message. Solution: The error reporting in Java 5 for the QosProvider has been improved. Each error now results in the proper java exception with a use full error message. |
OSPL-7974 / 16145 | Waitset events potentially leak away when received after the Waitset's timeout value. If a WaitSet times out, and new events arrive before the unblocked Waitset thread gets the time to execute and report the timeout, the new events will be lost and their memory will leak away. The chances of this happening increase when a Waitset frequently times out while its thread has to compete for CPU time with one or more other threads that are generating events for that same Waitset. Solution: A thread that is unblocked by a Waitset because of a timeout, will first check for pending events prior to reporting the timeout. If pending events exist, each event is processed accordingly and the timeout is is not reported. If no pending events exist, the waitset will report the fact that it timed out. |
OSPL-7978 | DDSI connection fail-over when using Cloud routing service. When DDSI is relying on the Cloud services, it should switch from one routing service instance to another in case of network or routing service failure. The Cloud discovery service provides its clients with new addresses to use in such situations, but the DDSI2 service would not actually switch to the new addresses. Solution: The DDSI2 has been modified to always use the most recent addressing information provided by the discovery service. |
OSPL-8004 | Shared memory leak in set_qos operations. The OpenSplice kernel failed to release memory allocated in the process of changing the QoS of an entity, resulting in a memory leak each time a set_qos operation was used. Solution: The memory is now freed. |
OSPL-8015 | Tuner export data throws exception. When attempting to export data using the Tuner, an exception is raised. This is caused by a change in the UI, where the QoS-ses to use are presented in a different manner. Solution: Updated internal algorithm to cope with the change in the UI to obtain QoS settings. |
OSPL-8021-1 | DDSI2 crash in nn_address_to_loc when accepting TCP connection. The DDSI2 service could crash on accepting a TCP connection if requesting the peer address after accepting the connection failed, typically caused by the connection already having been closed. Solution: DDSI now handles this error condition correctly. |
OSPL-8021-2 | Networking Bridge not enabling forwarding for a topic until new entities created/destroyed. The networking bridge processes the built-in topics describing the existing entities to determine what to forward. There existed cases in which the networking bridge would have been able to enable forwarding of data but instead would pause its discovery process until the arrival of new built-in topics. Solution: The networking bridge now always fully processes the available built-in topic samples before waiting for new ones to arrive. |
OSPL-8021-3 | DDSI2 spamming the log with "malformed packet" warnings when interoperating with RTI Connext. RTI Connext sends many packets that are not well-formed RTPS packets, and these lead to "malformed packet" warnings from DDSI2. It appears that recent changes to RTI Connext have caused a significant increase in the number of warnings, leading to huge log files with little value to users. Solution: DDSI2 now no longer logs the "malformed packet" warnings for commonly encountered packets, except when run in "pedantic" mode. |
OSPL-8021-4 | Phantom entities in OpenSplice with DDSI2 and the Networking Bridge when interoperating with other vendors' products OpenSplice internally operates using globally unique identifiers that antedate the DDSI specification, and hence DDSI2 translates between the identifiers as used in the DDSI specification and those used in OpenSplice. In combination with the Networking Bridge, the interaction could lead to the creation of "phantom" readers and writers as a consequence of an incomplete filter on the translated identifiers. Solution: The filtering now accounts for interoperating with other products. |
OSPL-8021-5 | Networking Bridge discovery hang on topics used by other vendors' implementations The Networking Bridge requires complete topic definitions to be available, but the DDSI specification does not define interoperable type definitions. Therefore, the bridge can encounter readers and writers for topics that do not exist in OpenSplice. Solution: The networking bridge now skips endpoints that use undefined topics; if and when a topic becomes available, the endpoints are re-evaluated. |
OSPL-8029 | When a client requests historical data using client-durability that matches multiple partition/topic combinations, multiple responses are generated. One of the ways to obtain is historical data is using the client-durability feature. When a client requests data that matches multiple partition/topic combinations the server responded with multiple data sets (one for each partition/topic combination). The intended behavior is that a single response is generated that contains the aggregated data from all requested partition/topic combinations. Solution: The problem is fixed and now a single response is generated that contains all requested data. |
OSPL-8032 | Mmstat can report more memory available than configured Mmstat determines the amount of available memory through a fairly involved calculation, in which an mistake was introduced, causing it to potentially report more available memory than was configured. Solution: The calculation has been corrected. |
OSPL-8034 | DDSI memory leak caused by a race condition between discovery and termination DDSI discovery runs in a separate thread that takes its input from the network. During termination, the network input was stopped, but the discovery thread could still be processing a participant discovery message. In this case, deleting all proxy participants could occur too soon, leaking a proxy participant. Solution: Processing DDSI discovery data is now forced to complete in time. |
OSPL-8055 | Group coherence: transaction does not become complete In some scenarios transactions would not become complete and therefore not delivered due to an incorrect algorithm in the matching of writers and readers. Solution: Several scenarios that resulted in incorrect dropping group coherent updates are now solved. |
OSPL-8058 | Group coherence: memory leakage The introduction of the group coherency feature introduces memory leaks in some scenarios, also in some situations where group coherence is not even used by any application. Solution: Several memory leaks concerning group coherent updates have been fixed. |
OSPL-8072 | Maximum Domain ID value (230) is not enforced in the API or during startup of the domain. Maximum Domain ID value (230) is not enforced in the API or during startup of the domain Solution: The domain will refuse to start when the domain ID in the configuration file is out or range (larger then 230). Trying to pass an invalid domain ID in a function call will result in an error in the info log and the call to fail |
OSPL-8091 / 16180 | Coherent Set transaction leaks v_transactionPublisher object Each time when a coherent set publisher is created a v_transactionPublisher object will leak. Solution: The coherent set mechanism is updated and the object is now properly freed. |
OSPL-8095 / 16182 | Durability crash when inserting out of order disposed messages When durability is used to insert out of order disposed messages the service could crash. Solution: The defect is solved and durability will not crash anymore on out of order disposed messages. |
OSPL-8123 | The persistent store retaining the wrong samples When committing a transaction on a KEEP_LAST history where the transaction contained more samples for a single instance than the depth of the history, the (KV) persistent store would not always retain the N latest samples. Solution: The persistent store has been fixed to retain the latest samples also in this case. |
TSTTOOL-265 / 15462 | Implement built in script variables for current scenario/macro filename and path. The Tester scripting engine has facilities for calling on built in variables that can be referenced from any script execution. Two new variables that hold the value for the currently executing script file name and and the file path are needed. Solution:The new built in variables have been added to the Tester scripting engine as variable names "script_file" and "script_path". See Tester user guide section 6.1.2 for update |
TSTTOOL-343 | Tester's statistics browser can't display statistics information. Navigating to the statistics tab and attempting to view statistics information for DDS entities does not currently work. The Tester log file reports that the entities are not available. Solution: The CM objects that the statistics workers held to gather statistics from were being freed too early. The unintentional free has been fixed and the statistics view works again. |
Fixed bugs and changes affecting the API in OpenSplice 6.6.2
Report ID. | Description |
---|---|
OSPL-7688 | Waiting for historical data with condition was not available for IsoCpp2. The proprietary function wait_for_historical_data_w_condition() was not implemented on the AnyDataReaderDelegate. Solution: The function wait_for_historical_data_w_condition() has been introduced on the AnyDataReaderDelegate. |
OSPL-7872 | Java5 DDS API lack support for conditional wait_for_historical_data operation on DataReader Java5 DDS API lack support for conditional wait_for_historical_data operation on DataReader. Solution: The proprietary conditional waiting for historical data has been implemented and can be used by casting the DataReader to the OpenSplice-specific org.opensplice.dds.sub.DataReader and invoking waitForHistoricalData() method with the desired parameters. |
OpenSplice v6.6.1
Fixed bugs and changes not affecting the API in OpenSplice 6.6.1
Report ID. | Description |
---|---|
OSPL-6050 / 14407 | DDSI2 MaxMessageSize and FragmentSize are no longer considered Internal options DDSI2 MaxMessageSize and FragmentSize are no longer considered Internal options and should therefore be moved from the Internal to the General section. Solution: The DDSI2Service/Internal/MaxMessageSize and DDSI2Service/Internal/FragmentSize options have now been moved to DDSI2Service/General/MaxMessageSize and DDSI2Service/General/FragmentSize. The old setting is still supported as a deprecated setting and causes a warning when used. |
OSPL-6467 | When a client sends a historical data request to the client-durability server, the server did not respect the timeout that was specified in the reques When a client sends a historical data request to the client-durability server, the client can specify a timeout value to indicate the time that the server may take to answer the request. Up to now the server did not respect the timeout value and would always answer immediately. With this fix the server now respects the timeout value. Solution: The server now queues requests and answers them based on their timeout value. |
OSPL-6983 | When a client sends a request for historical data to the client-durability server, the server must ensure that the client's historical data reader is discovered. One way for a client to obtain historical data is by publishing a request for historical data, and waiting for the response from the client-durability server. In case the server uses ddsi as the networking service, ddsi first must match readers and writers before communication can take place. If the server sends a response to a request, but ddsi has not yet discovered the reader to deliver the response to, then ddsi will drop the request. To prevent this from happening the server must either ensure that the reader has been discovered before sending the response, or send back a error indicating that no reader was discovered in time. Solution: The server know contains functionality to detect whether the reader of a client has been discovered. |
OSPL-7348 | userClock is missing from the configurator. userClockService is not a service but an option for a domain in the configuration. The tag userClockService is confusing. Solution: The configuration tag userClockService is now changed to userClock. The old tag userClockService is still supported for backwards compatibility, but will result in a warning in the info log that a deprecated tag is used. |
OSPL-7716 / 15848 OSPL-7708 / 15846 | Sometimes a RETCODE_ERROR was reported during the processing of a dispose_all_data request. When the durability service contained a sample with a newer timestamp than the timestamp for the dispose_all_data request, it would decide to exclude the newer sample from the dispose request. Its return status would clearly communicate that decision, but this was wrongfully interpreted as an unspecified error. Solution: The interpretation of the return status of the durability service has been corrected, and will no longer consider the exclusion of samples newer than the dispose_all_data request as an unspecified error. |
OSPL-7733 | Premature deletion of a writer may cause that DDSI drops data when client-durability is used. When a client sends a historical data request to a server, the server is expected to deliver the response in the partition specified in the request. For that reason the server creates a writer, publishes the data, and destroys the writer again. If ddsi has not yet taken the data before the writer is destroyed then the data will not be delivered. To prevent this situation premature deletion of the writer must be prevented. Solution: The writer is cached for some time before it is being deleted. This gives ddsi sufficient time to take the data. |
OSPL-7775 | ISOCPPv2 union generation from idl can fail. The generation of an IsoCpp2 union from an idl will fail if a) the union has char as switch type b) it has a default case and c) it is build on a platform on which char is unsigned by default and signed-char compiler flag is not used. The result can be a wrongly initialized union class, an ncompilable generated header file or an idlpp crash. All these problems were caused by the fact that idlpp expected the minimum and maximum values of a char to be -128 and 127 respectively. This is untrue when the char is unsigned. Solution: Maximum and minimum values of a char are now dependent on its default sign-ness. |
OSPL-7782 | Memory leak using Java5 DDS API DataReader.Selector. Whenever a DataState or Content filter was applied to a Selector, an underlying ReadCondition got created. The ReadCondition had native resources associated with it and would only be freed when the DataReader associated with the Selector got deleted. This could lead to a serious increase of memory usage and eventually result in an OutOfMemoryError in case new Selectors were allocated frequently i.c.w. setting a DataState or Content filter. Solution: In case of just a DataState, no ReadCondition is allocated. This also improves performance of the Selector. Additionally, the finalizer of the Selector frees native resources associated with a ReadCondition now (only applicable if a Content filter is applied). Finally, the Selector implementation has been made thread-safe as well by returning a new Selector object every time a setter method is called. |
OSPL-7785 / 15959 | JVM crash during deletion of data reader or data writer. A mistake in the reference counting of basic types in the code constructing samples of the built-in topics for the user_data, group_data, topic_data and partition name settings could eventually cause the freeing of a basic type that is supposed to remain in existence during the operation of the domain. Use of this type in subsequent operations could then cause a crash. The issue could only occur when these QoS are set to a non-empty value. Solution: The reference counting for these cases has been corrected. Note that the issue is not limited to Java and that the crash can also occur in situations other than deleting a data reader or writer. |
OSPL-7794 | ISOCPP2 dds::core::Time::operator > and < are broken The > and < operators on dds::core::Time in the ISOCPP2 API are not working properly due to an incorrect algorithm for comparing the nanoseconds part. Solution: The internal algorithm has been fixed to make the operators work properly again. |
OSPL-7808 | ISOCPPv2 domain_id function returned default_id The isocpp2 'dds::domain::DomainParticipant::domain_id()' function returned 'org::opensplice::domain::default_id()' when a the DomainParticipant was created with default_id. The DomainParticipant delagate kept a copy of the domain_id which was used during creation iso requesting the actual domain_id from the underlying core. Solution: The 'dds::domain::DomainParticipant::domain_id()' function now gets the actual domain_id from the underlying core. |
OSPL-7822 | Possible crash due to double free in listener. The listener has a thread that waits for events and dispatches them. After dispatching, the events are freed. Events are also freed before dispatching when the source entity was destroyed in the meantime. It was possible that these events of the destroyed entity were still be handled and thus freed a second time. Solution: Fixed the wait for events loop. |
OpenSplice v6.6.0p4
Fixed bugs and changes not affecting the API in OpenSplice 6.6.0p4
Report ID. | Description |
---|---|
OSPL-7761 / 15836 | Illegal time is reported repeatedly when the native networking service is used. On some Windows platforms the native networking service does not serialize the source timestamp of the messages correctly, which causes the receiver to read an incorrect timestamp and will report the illegal time error. This is caused by a code construction i.c.w. an optimalisation made by a compiler in the order of parsing the second and nanosecond part of a messaged. This causes the seconds and nanoseconds to be sent on the wire in the wrong order. Solution: The code that serializes the source timestamp is changed to ensure that they are parsed in the correct order. |
OpenSplice v6.6.0p3
Fixed bugs and changes not affecting the API in OpenSplice 6.6.0p3
Report ID. | Description |
---|---|
OSPL-6481 | Launcher can not load User defined Files. When a user creates their own deployment xml file (e.g %OSPL_HOME%\etc\config\My_ospl.xml), Launcher can not load it and can therefore not apply it. Even if you stop the Launcher and you restart it, it does not see the new xml file. Solution: Updates to the user-specified configurations field in the directory setting panel, to the OSPL_URI field in the environment settings panel will trigger a refresh of the configurations list in teh Configurations page. Added a new Refresh button on the Configurations page. If the Refresh button is pressed, then the configurations list is rebuilt using OSPL_URI, user specified configurations directory, OSPL_HOME\etc\config directory. Duplicates are removed if they exist in more than one of these locations.Notifications added to warn users if a configuration no longer exists when trying to edit it or set it as default configuration. |
OSPL-7664 | Memory leakage when using group coherence with volatile topics. Every group coherent transaction leaked memory as the EOT message, as opposed to other transaction message, created a new group owned transactionGroup which never became complete and was therefor never removed. Solution: Prevent EOT messages from creating group owned transactionGroups for volatile topics. |
OSPL-7700 / OSPL-7714 / 15845 | Group coherence data possibly wrong during discovery. When group coherent data was written and not all writers had been discovered yet via builtinTopics it was possible data wrong data was flushed or data was never flushed as the mechanism for determining the completeness of a group was flawed. Solution: The mechanism for calculating completeness has been reworked so correct completeness can be determined. |
OSPL-7728 / 15854 | Memory leakage on Waitset time-out. When monitoring shared memory using mmstat, it could be seen that v_proxy objects were leaking away every time a WaitSet timed out. Solution: The leak has been solved. |
OSPL-7737 / 15858 | XML parser does not allow reference to DTD. The new XML parser introduced in V6.6.0p1 did not allow references or attributes that started with a '!' so that references to the DTD like would result in a validation error. Solution: Tag names and attribute names that start with '!' will no longer automatically result in validation errors. |
Fixed bugs and changes affecting the API in OpenSplice 6.6.0p3
Report ID. | Description |
---|---|
OSPL-7676 / 15818 | Several issues with new ISOCPP2 backend for idlpp. The new backend for ISOCPP2 was not working correctly for anonymous and inner types, and generated code had include dependencies on classes that were part of the classic IDL-C++ language mapping. Solution: Anonymous and inner types are now fully supported and all depencencies on the classic C++ language mapping have been removed. |
OpenSplice v6.6.0p2
Fixed bugs and changes not affecting the API in OpenSplice 6.6.0p2
Report ID. | Description |
---|---|
OSPL-5834 | Host side binaries included in target RTS installers Host side RLM binaries, rlm, rlmutil and prismtech were being included in target RTS installers unnecessarily. Solution: RLM binaries, rlm, rlmutil and prismtech are no longer included in target RTS installers. |
OSPL-7082 / 14835 | Tuner tool hangs when reading large sequences or arrays. The tuner tool can take a a few minutes when reading samples that contain large sequences or arrays. It is not responsive during that time. Solution: The performance of C&M (which the Tuner tool uses) is improved considerably by using StringBuilder instead of Strings where keys an values are concatenated and by adding happy paths to searches. |
OSPL-7641 | Group coherence not working when used during discovery. When a group coherent writer starts publishing data before/during creation of the group coherent reader it was possible that no group coherent data was received during the livecycle of the reader. The transaction mechanism had an invalid (too high) writer count, because the discovery based on PublicationInfo and EOT message both increased the count for the same writer, the count is used determine if a transaction is complete and can be delivered to the reader. Because the count was too high the transaction never became complete and thus the transaction was never delivered to the reader. Solution: Updated the internal administration so that when a writer is discovered via PublicationInfo it removes it from a list so that the EOT message cannot add the same writer. |
OSPL-7646 / 15812 | Issue with register_service in Java RMI with duplicate services. The register_service call of the Java binding of RMI did not properly check for duplicate services. When a particular service-name is already registered, the call would return true without considering the instance-id and class parameters. Solution: The behaviour was fixed by returning false when a service is registered with a name that already exists, but a different instance-id or class. |
OSPL-7661 / 15813 | Unregistering of report plugin not done sufficiently. Participant creation failed after 10 registered report plugins due to incomplete cleanup on unregistrations and a hard limit of 10 plugins. Solution: Limits on number of report plugins are removed and unregistering report plugin has been improved. |
OSPL-7673 / 15816 | Compiler warnings caused by idlpp-generated cpp code. C++ code generated by idlpp leads to warnings when compiling the code. Solution: Improvements to idlpp templates and code-generation (to remove unnecessary casts, among others) can result in compiler warnings regarding signedness of comparison operands. The signedness of length variables in generated code for sequence-of-sequences was changed to an unsigned type so the warning does not occur. |
OpenSplice v6.6.0p1
Fixed bugs and changes not affecting the API in OpenSplice 6.6.0p1
Report ID. | Description |
---|---|
OSPL-7610 | Durability crash when fellow running pre-V6.6 version is present The durability service contains a mechanism to determine compatibility with other durability services, which could be other versions with a different set of features. A flaw in this mechanism causes the durability service to crash when it receives a sample-request from a durability service with a pre-V6.6.0 version. Solution: The mechanism was improved to be more robust |
OSPL-7557 | SOAP service not allowing connections in SP-mode Connecting any tool to a SOAP service, that is running as part of a single-process DDS application, fails with the error report that a participant could be created. This is due to a change in the SOAP service where it passed on an empty domain URI internally to prevent an extra unnecessary parse of the configuration file. Solution: The SOAP service now always passes on the full URI and domain id in all cases. |
OSPL-7564 | Change default installdir/windows start menu for Vortex V2 For Vortex_v2 the directory/start menu structure must change. All Vortex products should now install into the same structure. The version number is the version of that product and has no leading "v". For OpenSplice the structure must be: PrismTech/Vortex_v2/Device/VortexOpenSplice/ Solution: The new structure has been applied. |
OSPL-7565 | Durability crash when more than 2 roles present For each name space, durability maintains information about the various roles it has merged with. The way this set is represented could cause a crash when more than 2 roles were used in the system. Solution: The representation has been fixed. |
OSPL-7616 | Interoperability problem with RTI Connext 5.2.0 DDSI2 is quite strict in its checking of the values it receives in the discovery messages, which can from time-to-time result in interoperability problems. With Connext 5.2.0, RTI appears to have appropriated part of OMG-reserved namespace for a new extension in the discovery data, DDSI2 flags it as invalid and discovery fails completely. Solution: DDSI2 now accepts unrecognised values unless the "pedantic" mode for StandardsCoformance has been selected. |
OSPL-7630 | Coherent transaction shared memory leakage For every coherent transaction a kernelModuleI::v_transactionPublisher and child objects leaked in shared memory. Solution: Memory is now freed. |
OSPL-7631 | Possible deadlock when using coherent transaction When an end-of-transaction (EOT) message was the only message in the resend list the 'end_coherent_changes' function could deadlock. The resending of an EOT message did cause 'end_coherent_changes' to re-evaluate its conditions. Solution: Resending EOT messages now causes 'end_coherent_changes' to reevaluate it's conditions. |
Fixed bug and changes affecting the API in OpenSplice 6.6.0p1
Report ID. | Description |
---|---|
OSPL-7572 / 15788 | ISOCPP2 not using C++11 compliant idlpp backend. The C++11 Backend used by idlpp was not fully compliant with the new IDL-C++11 mapping as mandated by the OMG. Solution: A new C++11 backend has been provided for the isocpp2/isoc++2 target of idlpp that is truly complying with the OMG mandated IDL to C++11 language mapping. This results to a number of relevant and incompatible changes with respect to the previous C++11 backend: boolean in IDL now truly maps to the C++ bool type, so only "true" and "false" are now allowed. enum in IDL now behaves like the "enum class", which means the enums labels will be scoped with the type of the enum. The default (empty) constructor for structs and unions now initializes all attributes to valid values. (e.g. 0 for the primitive types, strings are empty, vectors are zero-length) For backward compatibility with the previous isocpp2 backend, a new flag is available on idlpp ("-o deprecated-c++11-mapping") that forces it to use the previous backend. |
OpenSplice v6.6.0
Fixed bugs and changes not affecting the API in OpenSplice 6.6.0
Report ID. | Description |
---|---|
OSPL-139 | Retention-period for purging unregistered instances is too long and non-configurable Currently theres a fixed 5 seconds 'retention period' after which unregistered instances are actually deleted/memory-freed. The 'artefact' that this retention period prevents is the unwanted resurrection of unregistered-instances in case of out-of-order reception of network-traffic. The current value of 5 seconds is so long that its not hard at all to run out of the default 10 MB shared-memory segment if you create/delete instances in a rapid pace. Solution: A new option RetentionPeriod is added to the domain configuration (OpenSplice/Domain/RetentionPeriod). This option specifies how long the administration for unregistered instances is retained in both readers and the durability service before it is definitively removed. The default value is 500 ms |
OSPL-5395 / 13742 | The dispose_all_data() (resp. on_all_data_disposed()) method is not supported under ISOCPP The dispose_all_data() (resp. on_all_data_disposed()) method is not supported in the ISOCPP, but must be supported in its successor ISOCPP2. Solution: The ISOCPP2 API now supports this feature. |
OSPL-6338 | ISOCPP streams API may drops samples silently when flush of stream fails. The flush operation of the isocpp streams API will perform a write operation of the underlying datawriter. The write operation on this datawriter may return a timeout because of expiry of the reliability.max_blocking_time associated with this datawriter, which is default set to 100 ms. For example this may occur because of network congestion. In that case the sample are silently dropped. Solution: When the flush operation on the stream fails, because the underlying datawriter write operation returns a timeout then a timeout exception will be thrown. Also the append operation will throw a timeout exception when the append results in a flush operation that times out. The samples will not be dropped and will be sent when the application retries the flush operation. |
OSPL-6436 / 14446 | C++ code generated for IDL where the same module scope was repeatedly opened and closed would be ordered such that all of the code for each module would be grouped together. This could lead to the generated code being invalid due to datatypes being used before they are defined. IDL generated by the Modeller application could be sensitive to this issue. Solution: C++ code is generated with a module scope structure corresponding to the IDL source. |
OSPL-6808 | Java5 DDS API lacks support for proprietary DomainParticipant operations. The Java 5 API was missing support for the proprietary delete_historical_data() and create_persistent_snapshot() operations on a DomainParticipant for the Java 5 DDS API. Solution: The 2 missing operations have been added to the Java5 API. |
OSPL-6943 | 1st and 3rd implementation of dds::domain::discover function potentially clash.s When invoking the 1st implementation of dds::domain::discover with 2 parameters (so time-out becomes default parameter), the function clashes with its 3rd overloaded implementation, which also has 2 parameters and which is preferred by the compiler. Solution: 3rd implementation of dds::domain::discover has been renamed to dds::domain::discover_all. |
OSPL-6954 / 14900 | The concurrent handling of a terminate signal and cleanup performed by the application may cause a crash. When a termination signal is handled, which tries to detach the application entities from shared memory, and concurrently the application is performing a cleanup of the DDS entities a crash may occur when the signal handler tries to access memory that is already freed. Solution: A reference count is added to the objects that can be freed concurrently when the application is detaching from shared memory. |
OSPL-7035 / 15067 | NullPointerException when using Java RMI API during shutdown. When RMI is used and a request is done during shutdown of the application it is possible that a NullPointerException can occur in the handleRequest call. Solution: The handleRequest function is adjusted so the NullPointerException will not occur anymore. |
OSPL-7095 | Reader snapshot in Tuner returned incomplete history and provided unreliable sample info. The reader snapshot feature from the tuner did not present reliable sample info, in particular the sample, view and instance states could not be trusted. Moreover, the snapshot only showed a single sample per instance, rather than the full history in case of KEEP_ALL or KEEP_LAST n with n > 1. Solution: These issues have been addressed. |
OSPL-7101 | Handling of leading/trailing white-space in configuration file. In the OpenSplice XML configuration-file, leading and trailing whitespace in configuration directives was not handled consistently. The raw value was stored, leaving the possibility for different services to interpret it in different ways. Solution: Whitespace is now trimmed from all configuration elements (not attributes) to get a consistent behavior, even though it doesn't strictly adhere to the XML specification, it is what most users expect. |
OSPL-7109 | The default value of the durability StoreSleepTime is 2.0, it should be 0.0. In case data needs to be persisted, the StoreSleepTime and StoreSessionTime control the rate at which data is stored. In particular, the StoreSleepTime is intended to prevent that the thread that is responsible for persisting data eats up too much CPU time. The default used to be 2.0 seconds. This may potentially cause unnecessary delays. Since in many use cases persisting data will not cause a resourcing problem, it makes more sense to use a default of 0.0 seconds instead 2.0 seconds. Only if it turns out that the persistency thread takes up too much CPU time a non-zero value should be used. Solution: The default value for StoreSleepTime is set to 0.0 seconds. |
OSPL-7130 / 15176 | Problem with listener notification at startup in ISOCPP API When creating an entity with a listener and events that should be notified to the listener occur immediately, they may not when using the ISOCPP DDS API. Solution: The ISOCPP DDS API is now deprecated and has been replaced by the ISOCPPv2 DDS API that does not suffer from the problem. Users who suffer from the issue should migrate to the new ISOCPPv2 DDS API. Check out the ISOCPP migration guide to find out how. |
OSPL-7198 / 15368 | Enum c_collKind elements are named too generic. The elements of c_collKind are named quit generic (f.i. C_LIST). This can conflict with customers' variable naming or their 3rd party libraries. Solution: The elements have been renamed by prefixing them with the OSPL_ prefix. |
OSPL-7202 / 15365 | If a write with timestamp of a new sample is done after an unregister of the instance but with a timestamp before the unregister, this new sample is not received the reader Due to the unregister the communication path between the writer and reader(s) was destroyed, causing the write of the new sample being discarded. Solution: In case a write with timestamp is done after an unregister with a timestamp before the unregister, bypass the normal communication path and write directly to the reader(s). |
OSPL-7210 / 15373 | Defining multiple protobuf messages in a single proto file fails for isocpp2 For each protobuf message in a proto file that is annotated to be used in DDS, the proto compiler back-end generates the required underlying trait when using the isocpp2 API. In case of multiple 'DDS-enabled' message structures, the generated traits end up in the same file, which is ok, but the surrounding ifdef's are the same for each traits. This leads to exclusion of all generated traits except the first, which on its turn leads to an invalid argument error when trying to use the trait at run-time. Solution: In case of multiple traits the ifdefs are only done once and surrounds the complete set of traits. |
OSPL-7228 / 15377 | Creating Topics using ISOCPP2 with non-topic types results in cryptic error reports With the ISOCPP2 DDS API, templates and traits are used to deal with type-specific structures. This requires a pre-processing step that generates traits for data-structures that need to be published/subscribed in DDS. Whenever an attempt is made to create a Topic for a type without a trait, the code still compiles due to the fact a template exists. At run-time though, the creation fails due to the missing trait and this results in an exception being thrown (Note: the missing trait can also be caused by not including the correct header file in your application. The " Solution: The error message has been modified to "Topic type without traits detected. This can happen by using a non-topic type or including the wrong header file." |
OSPL-7234 / 15376 OSPL-7336 / 15432 | The durability service may crash when not all namespace from a fellow are received and another fellow disconnect. The role of a fellow is set when all namespaces of that fellow are received. When another fellow is disconnected the namespace administration of all fellows is checked to see if the disconnected fellow was not an aligner. A crash occurs when the administration contains a fellow for which the role is not set. Solution: When the first namespace of fellow is received the role of that fellow is also set. |
OSPL-7250 | Unable to terminate StreamDataReader applications. The get() method on a StreamDataReader can cause applications to block for a significant amount of time if a large timeout is supplied and no data is being delivered to the reader. Solution:A new method named interrupt() has been added to the StreamDataReader. Calling this method causes any threads blocking on get() to unblock immediately and return control to the application. For an example of using this method in a termination handler, please see the Streams Throughput example. |
OSPL-7256 | Waitsets on Java API (classic and Java 5) would sometimes not unblock when the middleware is shutdown. Due to an error in handling the list of conditions, the check done to detach from a single domain might come up empty, causing the waitset to remain blocked. This was particularly likely on 64-bit platforms. Solution: The list of conditions is now passed correctly, causing the unblock to properly work. |
OSPL-7263 | Isocpp2 can generate garbled information in exceptions. A few calls to isocpp2 would produce somewhat unclear reports and/or exceptions when they fail. Solution: The creation of exceptions and report stacks has been improved. |
OSPL-7284 / 15404 | Unexpected and incomplete native log report. Some logs are written in the OSPL native report system in spite of the configuration SuppressDefaultLogs=True. Also, the information in the native log and report plugin are incomplete. Solution: The tracing functionality is improved regarding checking of SuppressDefaultLogs and regarding traces copying when SuppressDefaultLogs=True. |
OSPL-7288 / 15399 | String When the reporting functionality fails, it can generate " Solution:Generate "NULL" instead of " |
OSPL-7293 | Crash in RnR service during remove-replay command containing transformations While processing a remove-replay command containing transformations, the RnR service could potentially crash due to memory corruption. This does not occur when replay is stopped by other means, i.e. by stopping a scenario or reaching end-of-storage. Solution: The issue was caused by a double free and fixed by improving the transformation cleanup. |
OSPL-7303 | The secure networking service cannot find the security element in the configuration file. The secure networking service reads the security settings from the Security element in the configuration file. The XPath expression used to find the Security settings is incorrect. It tries to find the Security element under the NetworkService element instead of the SNetworkService element. Solution: First try to find the Security element under the SNetworkService element. When the Security element cannot be found under the SNetworkService element then the Security element is searched under the NetworkService element in order to be backward compatilble, in that case a deprecated warning is logged. |
OSPL-7313 / 15414 | DDSI2 ExternalNetworkAddress error in a multicast configuration. The presence of the DDSI2 ExternalNetworkAddress option in a multicast configuration was deemed an error and DDSI2 would terminate during startup. Solution: Reduce the presence of DDSI2 ExternalNetworkAddress in a multicast configuration to a warning and ignore its value. |
OSPL-7318 / 15416 | The durability service configuration parameter maxWaitCount is parsed incorrectly. The durability service configuration parameter maxWaitCount is not correctly interpreted. This may cause that the check performed by the durability service for the attachment of the networking services to a particular group may timeout to early. When that occurs the group involved is ignored. When this particular durability service has been selected as master for that group it will not align this group to the other nodes. Solution: Calculate the correct timeout value from the configured maxWaitCount. |
OSPL-7337 / 15433 | DDSI configuration with SSM allowed and ASM disallowed causes attempts at sending to 0.0.0.0 A DDSI configuration that enables SSM but disabled ASM should (initially) send participant discovery (SPDP) packets to the explicitly configured peers only. Internally this is realised by setting the SPDP multicast address to the unspecified address (:: or 0.0.0.0), but enabling any form of multicasting caused the unspecified SPDP address to no longer be recognised as such, and hence to be considered a required destination for SPDP packets. This in turn caused the log to fill up with error messages, but was otherwise harmless. Solution: The error in the processing of the addresses has been fixed. |
OSPL-7338 | Report 'no append' feature improvements. When using the Solution: Delete stale log files as soon as OSPL_LOGAPPEND=false or |
OSPL-7341 | A durability configuration with aligner set to false may miss data on reconnect. A federation with a durability service which has the configuration aliger set to false (alignee) didn't receive data published during a disconnect after a reconnect when the master durability service does not detect a master conflict. The alignee detected a master conflict and assumed the master would raise its state while the master saw no conflict and has no reason to raise its state. Solution: The alignee now requests the latest state from the master when it recovers from a disconnect during which it had no maste |
OSPL-7368 / 15476 | For the ISO C++ mapping the idlpp compiler generates incorrect code for a typedef of an array. When the idl specification contains a typedef of an array then the code generated by the idlpp compiler for the ISO C++ mapping is incorrect. In that case it partly generates typedefs for the array alias which are usually generated for the C++98 mapping. Solution: A condition is added to the idlpp compiler when generating code for a typedef of an array which checks if the code has to be generated for the ISO C++ or the C++98 mapping. |
OSPL-7376 / 15469 | Idlpp generates sequence alloc functions twice when compiling different idl modules which contain a definition of a sequence of a type specified in another module. When different idl modules specify a typedef of sequence of a type which is defined in another module or the specify a typedef of a sequence of a basic idl type then the corresponding alloc and allocbuf functions are generated twice by the idlpp preprocessor. For example when two modules each specify "typedef sequence Solution: For sequence definitions the generate sequence alloc and allocbuf are prefixed with the scope name of the module in which they are defined. |
OSPL-7445 | Cannot build ISOCPP custom lib on Windows On Windows the custom_lib for isocpp would fail to build due to an import/export conflict with the classic C++ API on which it was built. Solution: That conflict has now been resolved. |
OSPL-7469 | Java5 DCPS API TopicQos.withPolicy() methods don't copy policies from original TopicQos The witPolicy() methods on the TopicQos are meant to return a copy of the original TopicQos with only the policies supplied as arguments to be overridden compared to the original TopicQos. The implementation returned the default TopicQos with the supplied policies overridden per supplied argument(s), but not using the original TopicQos as source meaning that non-overridden policies would be default instead of the value in the original TopicQos. Solution: The algorithm has been modified to use the original TopicQos as source instead of the default TopicQos. |
OSPL-7480 / 15640 | ISOCPP C++11 should use defaulted functions. Since C++11, defaulted functions are introduced. But older Visual Studio versions did not support it completely. Constructors and assignment operators are generated by idlpp for these compilers. However, the compiler detection regarding this issue was not correct, resulting in all non-VS C++11 compilers using the generated functions. Solution: Compiler detection is improved so that all C++11 compilers that support defaulted functions actually use them. |
OSPL-7527 | Invalid handle error in isocpp2 when getting an status from an entity When requesting an status from an entity which needs an instance handle and the status has not yet occurred results in an invalid handle error on isocpp2. Invocations of the offered/requested_deadline_missed() functions on Writer and Reader in the ISOCPP2 API would crash when no such event ever occurred before the invocation. Solution: That crash has now been fixed. |
OSPL-7528 / 15653 | TimeoutException in ISOCPP2 should not be recorded in ospl-error.log The TimeoutException in ISOCPP2 should bot be recorded in the ospl-error.log, since it might result in massive amounts of undesired log messages in normal scenario's. Solution: When a TimeoutError occured, it would show up in the ospl-error.log file causing potentially lots of undesired messages in there since a timeout scenario can be totally valid and is by no means an inherent error. For that reason any TimeoutError is no longer logged into the ospl-error.log file. |
OSPL-7533 | Alignment of durability service with aligner=false configuration by late joining master with persistent data intermittently fails When a late joining durability service with aligner=true configuration (master) joins a system with running durability services with aligner=false configuration (alignee) it could happen that the alignee nodes did not get alignment data from the master node. The alignee node detected a master conflict when the master node arrived and when it tried to resolve the conflict this intermittently failed because the master wasn't always ready to align. Solution: The alignee node now triggers a master conflict when the master is ready to align. |
TSTTOOL-164 | Builtin topic filters do not take into account all CM* topics. If the user preference Hide Builtin (DCPS*) is set to true, the following topics would still be unfiltered: CMPublisher, CMSubscriber, CMDataWriter, CMDataReader. Solution: The filter pattern has been adjusted to filter out all DCPS* topics and all CM* topics. The preference page label has also been updated to reflect that. |
TSTTOOL-207 | Partition combo boxes in Tester's AddReader Dialog does not always show all existing partitions If user starts Tester with the "ospltest" command (instructing Tester to automatically connect on startup to ospl target using JNI), it is possible for some existing partitions to be missing from the partition comboboxes in AddReader, AddReaders and AddTopic Dialogs. This behavior is more prominent, the more partitions there are. Solution: Tester's Partition Manager is now created before any of its dependent components to ensure partitions are properly managed and available right at connection time. |
TSTTOOL-332 | Mismatch in handling of unbounded character sequences between script send and script check. In a scenario script, given a topic that has an unbounded sequence of characters in its type "cseq", the following script code would fail the check: send test_SimpleCollectionTopic ( cseq[0] => a, cseq[1] => b, cseq[2] => c ); check test_SimpleCollectionTopic ( cseq[0] => a, cseq[1] => b, cseq[2] => c ); Passing in indexed parameters for unbounded character sequences is accepted for send, but not for check. Solution: The check instruction can now accept indexed parameters for unbounded character sequences |
TSTTOOL-336 | New example Tester scripts needed to show how to manipulate the Record and Replay service. Solution: Composed some new example scripts that define record and replay scenarios, configures a storage, then allows to start and stop the scenarios on demand. They are now a part of the suite of example scripts. |
Fixed bug and changes affecting the API in OpenSplice 6.6.0
Report ID. | Description |
---|---|
OSPL-6024 / 14394 | DCPS Java5 API provides incorrect default LatencyBudget QosPolicy and DataWriterQos.reliability QosPolicy The DCPS Java5 API uses infinite LatencyBudget as default instead of zero duration and BEST_EFFORT reliability for DataWriterQos reliability instead of RELIABLE. Solution: Default |
OSPL-7528 | WaitSet::wait() and the WaitSet::dispatch() behave different on time-out Make sure that both the WaitSet::wait() and the WaitSet::dispatch() behave identical, so let the WaitSet::wait() also throw a TimeoutException when the timeout occurs. Solution: WaitSet::dispatch() and WaitSet::wait() would differ in how they responded to a timeout: the first would throw a TimeoutError, the second would not. That behavior has been made more consistent now: the WaitSet::wait() also throws a TimeoutError when the indicated timeout elapses. |