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. |
Showing 1 to 10 of 24 entries
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). |
Showing 1 to 1 of 1 entry
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. |
Showing 1 to 10 of 18 entries
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. |
Showing 1 to 2 of 2 entries
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. |
Showing 1 to 3 of 3 entries
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. |
Showing 1 to 10 of 11 entries
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. |
Showing 1 to 10 of 12 entries
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. |
Showing 1 to 10 of 17 entries
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 |
Showing 1 to 1 of 1 entry
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. |
Showing 1 to 10 of 15 entries
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. |
Showing 1 to 6 of 6 entries
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 '<>'. |
Showing 1 to 2 of 2 entries
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. |
Showing 1 to 10 of 20 entries
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. |
Showing 1 to 10 of 14 entries
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. |
Showing 1 to 1 of 1 entry
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. |
Showing 1 to 10 of 58 entries
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. |
Showing 1 to 2 of 2 entries
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. |
Showing 1 to 10 of 12 entries
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. |
Showing 1 to 1 of 1 entry
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. |
Showing 1 to 5 of 5 entries
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. |
Showing 1 to 1 of 1 entry
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. |
Showing 1 to 6 of 6 entries
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. |
Showing 1 to 7 of 7 entries
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. |
Showing 1 to 1 of 1 entry
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. |
Showing 1 to 10 of 41 entries
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. |
Showing 1 to 2 of 2 entries