This page lists all the changes and fixed bugs in OpenSplice v6.5.x
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.5.x
OpenSplice v6.5.2p1
Fixed bugs and changes not affecting the API in OpenSplice 6.5.2p1
Report ID. | Description |
---|---|
OSPL-7425 | Support for armv7-marvell-linux-gnueabi-hard Port for Ubuntu 14.04 64 bit host to Ubuntu 14.04 for custom ARM V7 board using Marvell Armada 385 processor and armv7-marvell-linux-gnueabi-hard_i686_64K_Dev_20131002 compiler |
OpenSplice v6.5.2
Fixed bugs and changes not affecting the API in OpenSplice 6.5.2
Report ID. | Description |
---|---|
OSPL-7134 / 15140 | Idlpp (cppgen) created ambiguous enum mutators. Idlpp (cppgen) generated both a value mutator and an r-value reference mutator for enum types. These mutators conflict when compiling. Solution: Idlpp (cppgen) will not generate the r-value reference mutator for enum type anymore |
OSPL-7155 | Failing group coherence on reconnects. During reconnect tests we discovered failures in the discovery of matching writers causing updates never to become complete. Solution: Improved discovery mechanism which solves several use cases of failing group coherent updates during discovery phase of communication end points. |
OSPL-7160 / 15268 | Conditions cannot handle const functors. The different kinds of isocpp2 Conditions only supported non-const functors. This particularly caused problems when using lambda functions. Solution: Added support for const functors. |
OSPL-7227 / 15378 | Multiple definitions of copy-routines in code generated by protoc gen-dds back-end The protoc-gen-dds back-end generates code to allow .proto messages to be transparently published/subscribed. When using multiple messages originating from different .proto files in a single application, some code gets duplicated causing symbols to be defined multiple times and linking of compiled code to fail. Solution: The offending code has been moved to a separate file, which is included by all files that use the construction instead of duplicating it in each file. |
OSPL-6802 | A new merge policy called CATCHUP is available. This merge policy is similar to the already existing REPLACE merge policy, but the resulting instance states may differ. When nodes get disconnected their historical data sets may diverge. To recover from divergent states once the nodes get reconnected again, the durability service has defined various merge policies. One of these merge policies is the REPLACE merge policy. The REPLACE merge policy dispose and replace all historical data by the data set that is available on the remote node. Because all data is disposed first, a side effect is that instances whose state did not change will still be marked as NEW after the merge. For some use cases it is undesirable that instances which have not diverged are still marked as NEW. For that reason a new merge policy called CATCHUP is available now. Solution: The CATCHUP merge policy updates the historical data to match the historical data on the remote node by disposing those instances that are not available any more, and adding and updating all other instances. The resulting data set is the same as that for the REPLACE merge policy, but without the side effects. In particular, the instance state of instances that are both present on the local node and remote node and for which no updates have been done will remain unchanged. |
OSPL-7106 | When durability terminates while persisting samples, a sample can be lost. When persistency is enabled, the durability service is responsible for writing samples to the persistent store. If durability terminates while writing samples to the persistent store, it may occur that a sample that has recently been extracted from the persistent queue but not stored yet, gets lost. Solution: The check to decide whether durability should terminate can now only occur before taking a sample from the persistent queue and after it has been written to the store, but not in between. This ensures that a sample that has been taken from the persistent queue will always be persisted. |
OSPL-7093 | When a merge policy is applied, private groups are accidentally aligned. When a merge policy is applied, merge data must be requested from the master. It turns out that also data for private groups is requested when a merge is about to take place. This is not needed, as private groups are by definition local groups, and data for these groups should never be merged. Solution: When a group is marked as a private group, no data for that group will be requested anymore. |
OSPL-7136 | Improved handling of nested GPB messages during proto files compilation. The compilation of nested GPB messages could cause compiler crashes when handling multiple proto files and/or proto files without the package keyword. Solution: The parsing part of the GPB compiler has been improved and made more robust. |
OSPL-7153 | When durability terminates while a merge conflict is pending to be resolved, memory may be leaked. When a merge conflict is detected, the durability service creates a conflict object and stores it in a queue. A conflict resolver asynchronously takes conflicts from the queue and tries to resolve them. In case a conflict object is pending in the queue and the durability service terminates, pending conflicts in the queue are NOT destroyed. This may lead to leakage of the conflict object. Solution: When durability terminates any pending conflicts in the queue are cleaned up. |
OSPL-7189 / 15316 | Networking receive thread can spin at 100% following a disconnect/reconnect The RT networking service keeps track of a list of ACKs waiting to be sent. The code to cleanup this list following a disconnect contained an error that could corrupt the list if packet loss had occurred just before the disconnect. Solution: the cleanup is now robust against packet loss. |
OSPL-3817 | The idlpp preprocessor crashed when when the idl specification contains a sequence of a typedef of sequences. The idl preprocessor handles a sequence of a typedef of sequences incorrect which results in a crash of the preprocessor when it tries to parse such a construction. This caused by a missing condition in the preprocessor when it tries to pass this construction. Solution: The missing condition is added to the idlpp preprocessor to handle the sequence of a typedef of sequences correctly. |
OSPL-4403 | Corrupt RnR storage when using a storage type that doesn't match contents of existing file Two RnR storage backends are available: XML and CDR. When configuring a storage, either by publishing RnR config commands or in the OpenSplice configuration file, it's possible the data files already exist on the filesystem and contain data recorded during a previous session. When the recorded data is in XML format, it's possible to configure a new storage to use CDR format, or vice-versa, and append new samples to the storage in a different format than those recorded earlier. This corrupts the storage and it will not be usable for replay. Solution: The issue was resolved by adding verification of attributes when existing files are found. Changing a storage in a way that conflicts with existing files is no longer allowed. |
OSPL-7060 / 15088 | When OpenSplice is stopped an application may remain blocked on the WaitSet.wait operation. When an application is waiting in the WaitSet.wait operation and at that moment OpenSplice is stopped with the 'ospl stop' command or the spliced daemon is killed, then the WaitSet.wait operation will never return. This may occur even when the wait is performed with a timeout value. Solution: When the application is attached to the shared memory segment a callback is registered. When the spliced daemon which controls the shared memory segment is terminated the callback will be triggered. The callback detaches the application from the shared memory segment and triggers the WaitSet.wait to return OK together with the list of conditions that were detached from shared memory. When performing an operation on one of the returned conditions, ALREADY_DELETED will be returned. |
OSPL-7090 | Publishing multiple RnR commands at once may result in some commands being rejected by the service An issue in the ordering of commands received at the same time, may cause commands to be rejected if they depend on each other. For example a config-command that defines a storage must be processed before an add-record command that uses this storage, or the add-record command would be rejected because the storage is undefined. Solution: The issue was resolved by processing the commands in the same order as they are delivered to the service. |
OSPL-7126 / 15106 | Crash of watchdog thread on VxWorks RTP shared memory deployments The VxWorks support for shared mutexes and condition variables does not match the POSIX pthreads behaviour required by OpenSplice core, with the OpenSplice abstraction layer translating between the two. Because of an issue in the abstraction layer, reuse of a shared memory address for a mutex could result in different processes using different VxWorks kernel mutexes. This in turn caused race conditions and, under some circumstances, crashes. Solution: the abstraction layer has been updated to not dissociate the mutex names from the kernel mutexes, thereby ensuring that all processes always agree on the kernel mutex to use. |
OSPL-7141 / 15185 | Crash when getting IsoCpp null listener. Calling the listener getter function in IsoCpp when no listener was set, will cause a crash because it tries to use a null pointer. This null pointer is of an internal object that is created when a listener is attached. Solution: A check is added to the getter functions that will return null when the internal data object is null, meaning that no listener was set. |
OSPL-7142 / 15187 | First few samples written after discovery of a remote node not delivered Data is forwarded from the local writers (i.e., those attached to the same shared memory as the networking service in a shared memory deployment) only when the RT networking service has detected remote nodes, with some additional safeguards for data written while the system is starting up. When the first remote node was discovered, services (and applications) on the local node were informed of this event before the forwarding was enabled, which could cause data to be lost. A typical symptom is that the durability service fails to make progress. Solution: forwarding is now enabled before the existence of the remote node is announced. |
OSPL-7151 | Error registering a non-scoped type in Java Attempting to register a type without a scope (so module-less) using the Java API no longer worked due to internal algorithm that simply assumed that each type was scoped. Solution: The internal algorithm has been modified to check whether the type that is registered has a scope. |
OSPL-7189 / 15316 | Networking receive thread can spin at 100% following a disconnect/reconnect The RT networking service keeps track of a list of ACKs waiting to be sent. The code to cleanup this list following a disconnect contained an error that could corrupt the list if packet loss had occurred just before the disconnect. Solution: the cleanup is now robust against packet loss. |
TSTTOOL-296 | Sample Display view and Check script instruction incorrect when char sequence field followed by field with same initial prefix. If a topic data type contains a string field (or a character sequence or array) followed by another string field whose field name starts with the field name of the previous field, then the internal data model would mistakenly concatenate both fields into one field. Solution: The string field concatenation involving similarly named fields has been fixed. |
TSTTOOL-314 / 15087 | Tester bounded sequence fields always send the max length of the sequence. When Tester writes out a sample containing a bounded sequence, it always populates the full sequence length with values. Solution: The tool has been modified to only allocate sequence elements for elements that are actually defined, instead of allocating the full length with defaults first. NOTE: sequence elements must be defined in index order in a script. eg. send aTopic(seq[0] => 1, seq[1] => 1); is valid, while send aTopic(seq[1] => 1, seq[0] => 1); is not. |
OpenSplice v6.5.1p1
Fixed bugs and changes not affecting the API in OpenSplice 6.5.1p1
Report ID. | Description |
---|---|
OSPL-6616 / 14697 | Lack of reliability for first few packets on a channel can lead to unexpected behaviour Loss of the first few packets on a channel was not always detected and corrected. In case these packets belonged to the durability protocol for example, this could lead to unexpected behaviour. Solution: The reliable protocol is extended to support (re)transmitting packets to nodes that have not yet responded. Information about these nodes is shared across channels, so that when a single channel discovers reliable communication with a node on a NetworkPartition, all channels will. Furthermore, receiving nodes wait until they received the oldest packet they should receive before starting delivery of data. |
OpenSplice v6.5.1
Fixed bugs and changes not affecting the API in OpenSplice 6.5.1
Report ID. | Description |
---|---|
OSPL-4153 | Durability to support compression for KV-persistence The durability service currently has a KV-persistency implementation that allows persisting data to disk in either SQLite or LevelDB. Testing performance indicates that the disk is the bottleneck when trying to achieve a high throughput in some use cases. Therefore it should be possible to compress data when persisting. Solution: Samples can now be compressed by durability before persisting them (and obviously uncompressed before re-publishing them in DDS). Durability supports compression as a configurable option for KV persistence. For more details on how to configure it, please check section 4.3.3.9.3 of the Deployment Guide |
OSPL-6519 | Durability service may not detect disconnecting federation The durability service could in some situation miss a dispose of DCPSHeartbeat, causing it to think that a remote federation is still running. That on its turn may prevent correct alignment of historical data. Solution: The algorithm that checks whether the DCPSHeartbeat is disposed has been corrected. |
OSPL-6950 | DDSI2 not utilizing latency budget shorter than 1s The interface between the OpenSplice kernel and the networking services implements the latency budget, but requires the networking service to make a trade-off between idle wake-ups and efficient handling of short latency budgets. The DDSI2 service opted to have few idle wake-ups, but at the cost of essentially treating a latency budget setting < 1s as if set to 0s, which differs significantly from the RT networking service that puts the cutoff at 10ms by default (The RT networking service has useful work to perform in the idle wake-ups, hence the different trade-off). It should be noted that a high-rate writer typically manages to have some data in the network queue at all times, in which case it is not the latency budget that drives packing, but the sheer amount of data. Solution: DDSI2E now allows configuring this using the Internal/Channels/Channel[@name]/Resolution setting (similar to the RT networking setting). The default is unchanged. |
OSPL-6984 | DDSI2 possible use-after-free following end_coherent_updates DDSI2 may find itself forced to grow a message buffer when sending an end-of-transaction commit message, which may result in the message header being relocated in memory. This could lead to the setting of a flag in the message header in freed memory. Solution: It now recomputes the address of the message header. |
OSPL-6985 | Crash due to refcounting issue in large group-transactions The publishing side in group transactions larger than 50 writers may crash because of a refcounting issue in enlarging the group transaction administration. Solution: The refcounting issue has been fixed. |
OSPL-7013 | DDSI2 limits max deployments on a node that are discoverable via unicast When DDSI2 tried to allocate a participant index when Discovery/ParticipantIndex = "auto", it limited itself to indices 0 .. 9. In practice, this meant that running more than 10 (single-process) deployments on a machine required multicast discovery and the ParticipantIndex option set to "none". The amount of unicast discovery pings sent out periodically is directly related to the maximum, which argues in favour of a small limit. However, it should provide a way of configuring a higher limit in cases where this is required. Solution: A setting has been added, Discovery/MaxAutoParticipantIndex, which configures the highest index to be tried automatically. |
OSPL-7032 | C&M API does not allow creation of Publisher with one ore more non-default immutable policies The C&M API is internally creating a publisher as enabled and tries to apply the QoS afterwards. If any of the immutable policies are immutable, this fails. This prevents tools from creating publishers with non-default values for immutable QoS settings. The implementation should create the entity disabled, set the qos and then enable the entity. Solution: The C&M API now creates the publisher in disabled mode, sets the QoS and enables the publisher. |
TSTTOOL-298 | Protobuf feature for Tester does not account key and filterable fields with name overrides. If a .proto data definition contains FieldOptions with "name" defined to override the name of the member in DDS, then Tester doesn't recognize it, and subsequently fails to read those fields. Solution: The feature now finds all the DDS specific FieldOptions defined in the protobuf metadata to find the real names of the key and filterable fields, and properly translates them between sample data view in tool, and sample reading/writing at middleware. |
OSPL-7027 / 14930 | 100% CPU Usage network service when resending locally rejected samples When a local datareader uses resource limits and runs into these resource limits, the networking service may go to 100% load when attempting to re-deliver a sample that is rejected due to the fact that the maximum resource limits have been reached. Solution: The networking service now reschedules the delivery of a sample to a datareader for the next resolution tick instead of attempting the re-deliver in a busy-wait loop until it is delivered. |
OSPL-7052 | Unmatching Qos messages in ospl log and remote group detection for client durability. The durability service uses various topic definitions for the implementation of the client-durability feature. The qos values for the max_blocking_time and lease_duration for these topics should be same as the defaults in the DDS specification, but due to a bug this was not the case. When a client generates a topic that does use the default qos values, a warning would appear in the ospl log file. Furthermore, the client durability server did not detect the creation of non-volatile writers on remote nodes. Consequently, the client durability server would not collect and align the data written by these writers. Solution: The durability service has changed the qos values for the topics related to the client-durability feature, so that the max_blocking_time and lease_duration qos values now conform to the DDS specification. Also, the durability service now detects the creation of non-volatile writers on remote nodes so that the server is able to collect and align the data written by these writers. |
OSPL-7089 / 15092 | DURATION_ZERO_SEC and DURATION_ZERO_NSEC notation not recognized by QoSProvider. The QoSProvider does not recognize the DURATION_ZERO_SEC and DURATION_ZERO_NSEC time values defined in the XML syntax. Solution: The missing time values are now correctly parsed. |
TSTTOOL-301 | Writing octal character codes in c_char fields in script scenarios fails validation. As of OpenSplice V6.5.0p7, a feature was introduced in Tester where values punched in to sample field parameters in a scenario script send or dispose command underwent a validation on execute to ensure that the typed in value fits in the known IDL type for that topic. The validation failed to consider the case for IDL char fields where octal character codes of the form was used as input. Solution: Script validation of topic fields of IDL type "char" now allows for values of the regex form \\[0-3][0-7][0-7] eg. a valid send instruction: "send aTopic(aCharField => '\000');" |
Fixed bugs and changes affecting the API in OpenSplice 6.5.1
Report ID. | Description |
---|---|
OSPL-6024 / 14394 | Ignore outstanding loans when deleting entities A datareader keeps history about open loans. Open loans are memory given to the user by a take or a read action on a datareader and are not (yet) returned with a call to return_loan. A datareader cannot be deleted if there are open loans. The delete_datareader operation will return a RETCODE_PRECONDITION_NOT_MET returncode. There is a need to support deletion of a DataReader when open loans still exist though. Solution: To be able to ignore any open loans in case of a deletion of a datareader a new property "ignoreLoansOnDeletion" has been introduced on the datareader, with a default value false. If this property is set to true using the set_property operation, the datareader will ignore its open loans in case of a delete action. The value is interpreted as a boolean (i.e., value must be either 'true' or 'false') "false" (default). In case the property is set to false, the datareader will check for open loans in case of a delete action and will return PRECONDITION_NOT_MET in case of open loans. In case the property is set to "true", the datareader will ignore open loans and can be deleted in such a situation. This new property is only available on classic Java and C++ API's, both standalone and in CORBA-cohabitation mode. |
OSPL-6342 | Support for dynamic network partitions for RTNetworking The RTNetworking service needs to support for changing network partitions dynamically at run-time. Solution:This feature allows users to amend the configuration of the RTNetworking service at runtime by means of a Topic-API. For more details, check the RTNetworking dynamic partitions guide |
OSPL-7021 | The behavior of the dispose_all operation is different from the behavior of the dispose operation for reader on the same federation. The dispose_all operation is performed asynchronously. This may cause that readers on the same federation my still read alive samples after the execution of the dispose_all operation. With this respect the dispose_all operation behaves differently from that of the dispose operation. The dispose operation has immediate effect for readers on the same federation. Solution: For readers on the same federation the dispose_all operation is performed synchronously. The state of the readers connected ot the same federation is updated during the dispose_all operation. |
OSPL-7027 / 14930 | 100% CPU Usage network service when resending locally rejected samples When a local datareader uses resource limits and runs into these resource limits, the networking service may go to 100% load when attempting to re-deliver a sample that is rejected due to the fact that the maximum resource limits have been reached. Solution: The networking service now reschedules the delivery of a sample to a datareader for the next resolution tick instead of attempting the re-deliver in a busy-wait loop until it is delivered. |
OpenSplice v6.5.0p13
Fixed bugs and changes not affecting the API in OpenSplice 6.5.0p13
Report ID. | Description |
---|---|
OSPL-5473 | Shared memory leak during alignment Implicit disposes weren't delivered for builtin topics, causing leakage in shared memory. There is a small chance other topics could potentially leak as well, but it was never observed. Solution: The implicit (internal) flag is now part of the equation to find duplicate messages. |
OSPL-6284 / 14504 | Durability service fails to update service lease An issue in the durability service could result in a spinning thread during alignment of data from other durability nodes. The spinning thread triggers internal safety mechanisms, eventually preventing the service from updating it's service-lease which causes the spliced process to consider the service crashed or deadlocked. Depending on the configured failure-action, spliced may decide to terminate or restart all OpenSplice services. Solution: The cause of the spinning thread has been resolved. |
OSPL-6519 / 14561 | Incorrect processing of DCPSHeartbeat by spliced and durability The durability service could in some situation miss a dispose of DCPSHeartbeat, causing it to think that a remote federation is still running. That on its turn may prevent correct alignment of historical data. The spliced thread responsible for processing the DCPSHeartbeat topic and thus monitoring the liveliness of other nodes in a domain, could get stuck reading old data. Depending on configuration (i.e. realtime thread priorities) this could result in unreasonably high CPU usage preventing other threads from running. This means the liveliness monitoring of other nodes is not reliable and removal of a node can possibly go unnoticed by the spliced processes on other nodes in the domain. Solution: The algorithm that checks whether the DCPSHeartbeat is disposed has been corrected in durability and spliced is now skipping data that has already been processed. |
OSPL-6683 / TSTTOOL-208 | Tooling version compatibility constraint. OpenSplice Tester and Tuner need to connect to and read the necessary information present in C&M API minimum version of 6.5.0. Solution: When using C&M API to connect to a remote OpenSplice DDS system, a minimum version compatibility of 6.5.0 is now enforced in order to connect between local and remote. |
OSPL-6992 | Some cross development installers are not built for the correct architecture. In some cases where the host machine is 64 bit in a cross-development environment, the installer would be generated for a 32 bit host. On a subset of machines without 32 bit compatibility libraries the installer would not run. Solution: The installer generation logic has been updated to build for the correct architecture. |
OSPL-7010 / 14926 | Deadlock while terminating during initial alignment of durability. Durability did not notice a fellow being removed during initialization causing the initial alignment loop to be infinite. Solution: The durability service now checks if a fellow is still alive before deciding to wait for the communication state to change |
OSPL-7015 / 14928 | C# API sample marshalling issues The C# API was having problems marshaling samples that had an attribute that was a sequence of a sequence and of demarshaling a sample that had an attribute that was a sequence of strings. Solution: Both issues have now been fixed. |
TSTTOOL-261 | As a user I would want to see reason for failure of QOS compatibility in Tester Tester does not how reasons for failure of QoS compatibility. Solution: Display reasons of incompatibility from the tooltip when highlighted as incompatible reader. |
TSTTOOL-272 / 14761 | Slow sending of large strings from Tester Tester executed non-linear code when sending strings, char sequences and char arrays. A 'send' instruction that contained a string of about 10K characters would take several minutes to complete. Larger strings took exponentially longer. Solution: Code was reworked so that send behaviour is now no worse than linear with the string size. Casual observations suggests that a send is close to constant time. Typical send times for strings up to 64K characters where observed to be in the 30-60 ms time frame. |
OpenSplice v6.5.0p12
Fixed bugs and changes not affecting the API in OpenSplice 6.5.0p12
Report ID. | Description |
---|---|
OSPL-5473 | Small memory leak in DCPS api listener dispatcher for C and C++. The list of observables monitored by the listener dispatcher leaked. Solution: Create the list object at creation instead of on the fly. |
OSPL-6867 | Historical data that was requested by a client using the client-durability feature could only be delivered to a single, fixed partition instead of the partition preferred by the client. When the durability service receives a request for a client for historical data using the client-durability feature, the historical data could only be delivered to a single, preconfigured partition. Some use cases require the data to be delivered to different partitions. For this reason it is now possible to deliver the historical data to the partition requested by the client. This feature only applies to client-durability, the behaviour between durability services is not affected. Solution: Clients for client-durability can now specify the partition to receive historical data on a per-request basis. |
OSPL-6947 | Tools and SOAP service may crash. A piece of memory may be freed to soon when deleting proxy entities, like our tools do (potentially through a SOAP connection). This leads to free memory leads that can cause the tools or SOAP service to crash. Solution: The memory corruption has been solved. |
OpenSplice v6.5.0p11
Fixed bugs and changes not affecting the API in OpenSplice 6.5.0p11
Report ID. | Description |
---|---|
OSPL-6900 / 14883 | Leak of global references in Classic Java PSMs. A global reference was created for some Java classes related to DDS entities such as DomainParticipantImpl, TopicImpl etc. These references were never deleted so a class instance would leak every time an entity is deleted though the corresponding DDS calls like factory.delete_participant or participant.delete_topic. Solution: The issue was resolved by deleting the global reference when an entity is deleted. |
OSPL-6896 / 14878 | Durability crash during alignment. When durability is used and during alignment of a fellow, the fellow disconnects durability could crash. Solution: The alignment functionality is adjusted so that this crash cannot happen anymore. |
OSPL-6797 | DDSI2 needs to support multicast on platforms that incorrectly declare multicast unsupported. DDSI2 relies on the network interface capabilities it reads from the operating system kernel to determine whether or not multicasting is supported on the selected interface, but some platforms do not mark the interface as supporting multicasts even though it does in reality. The workaround of setting the flag manually on the interface requires elevated privileges, which is not always acceptable. Solution: An option Internal/AssumeMulticastCapable is now available in DDSI2, which can be set to a comma-separated list of interface name patterns (i.e., including ? and * wildcards) that are assumed to be multicast capable. |
OSPL-6889 / 14875 | Crash of spliced during termination while application(s) still running. Normally when the spliced process is terminated, application participants have already detached from the shared database so the database can be removed and OS resources reclaimed during spliced termination. However it is also possible that applications are still running when spliced is terminated. In that case the database will be detached and OS resources can only be reclaimed after the last application participant has also detached from the database. An issue could lead to a crash during spliced termination in the latter case. Because the database is detached but not removed, another spliced thread would try to access it resulting in undefined behaviour. Solution: The issue was resolved by preventing the offending spliced thread from accessing administration data during termination stage. |
OSPL-6912 / 14885 | DDSI2 can mismatch sockets and participants in "many sockets" compatibility mode. DDSI2 can operate in a compatibility mode in which each participant gets its own socket, in which case there is no requirement to include an explicit destination address in messages intended for just one participant, but the mapping from socket to participant could be done incorrectly. That results in the wrong participant being addressed, which typically results in dropping a message, but could also lead to data being considered acknowledeged when it fact it hadn't been. The problem is only known to occur when interoperating with TwinOaks CoreDX product. Solution: The mapping has been corrected. |
OSPL-6909 / 14886 | Deadlock during durability exit. When durability is terminating it could end up in a deadlock when terminating its internal listeners. Solution: The listener termination mechanism within durability is adjusted and the deadlock cannot occur anymore. |
OSPL-6894 / 14876 | The u_domain object is not freed causing a memory leak The u_domain object was not freed even though no other object had a reference to it. Solution: When the last participant is freed and thus all the references to the u_domain object are release the u_domain object is freed. |
OSPL-6419 | Possible crash in C++ when calling find_topic and deleting participant in other thread When having a deplicated C++ participant and one thread blocks in a find_topic while the other deletes the participant a crash could occur because the domain was unaware of the deletion of the kernel participant object. Solution: The domain is now aware that the deletion of the kernel participant object. |
OpenSplice v6.5.0p10
Fixed bugs and changes not affecting the API in OpenSplice 6.5.0p10
Report ID. | Description |
---|---|
OSPL-6781 / 14838 | Possible deadlock during durability clean up. When delete_contained_entitites is called it is possible that durability could end up in a deadlock. Solution: The clean up mechanism of durability is adjusted so this deadlock cannot occur anymore. |
OSPL-6707 | Perc JVM error when using waitsets. When using the Perc JVM in combination with waitsets an error occurs: java.lang.NoSuchMethodError: get_trigger_value. Solution: The error is fixed and will not occur anymore. |
OSPL-6555 / 14568 | OpenSplice installer could fail when installing OpenSplice as service. When installing OpenSplice as service and the Microsoft Visual C++ Runtime redistributable is not installed on the system the installation could fail. Solution: The installer is adjusted to install the Microsoft Visual C++ Runtime redistributable before installing the service. |
OSPL-4466 / 12862 | C# examples give warnings. When opening the OpenSplice C# example project files warnings with the text 'Load of property 'ReferencePath' failed' occur. Solution: The project files are adjusted so this warning will not occur anymore. |
OSPL-6759 / 14832 | Typographical error in ospl traces. The durability service contained a typographical error in the traces. Solution: The typographical error is corrected. |
OSPL-6839 / 14865 | Warning during termination of cmsoap service. When the cmsoap service is exiting a warning message "Received termination request, will detach user-layer from domain." in the info log can occur. The cmsoap service wrongly registers 2 exit handlers. Both of them are executed when the service is requested to terminate and eventually both do the same thing under the hood. The exit handler registration is adjusted and now only one handler is registered for the cmsoap service which also removes this warning message. |
OSPL-6519 / 14561 | Incorrect processing of DCPSHeartbeat by spliced. The thread responsible for processing the DCPSHeartbeat topic and thus monitoring the liveliness of other nodes in a domain, could get stuck reading old data. Depending on configuration (i.e. realtime thread priorities) this could result in unreasonably high CPU usage preventing other threads from running. This means the liveliness monitoring of other nodes is not reliable and removal of a node can possibly go unnoticed by the spliced processes on other nodes in the domain. Solution: The issues were resolved by skipping data that has already been processed. |
OpenSplice v6.5.0p9
Fixed bugs and changes not affecting the API in OpenSplice 6.5.0p9
Report ID. | Description |
---|---|
OSPL-6541 | Tuner doesn't show entity-relations in the partition view The Tuner tool no longer shows entity-relations when selecting the 'partition' view. Solution: An internal algorithm to find dependant entities has been modified to support partitions again. |
OSPL-6591 / 14606 | OSPL waits 10 seconds before exiting with a wrong report plugin When OSPL is started and a configured reportplugin is missing OSPL always waits 10 seconds before exiting. Solution: OSPL now directly exits and does not wait 10 seconds anymore. |
OSPL-6628 / 14751 | SIGKILL on an application with listeners terminates OpenSplice in an unexpected way. When SIGKILL is used on an application which uses listeners OpenSplice terminates with a message that it could not properly clean up its resources. Solution: There was a problem in the listener cleanup mechanism. This is now fixed and all resources are now properly cleaned up. |
OSPL-6682 / 14763 | The ospl tool help for return code 16 is incorrect. The ospl tool help says "not available" instead of "non existent" for code 16. Solution: Non-existent is now also reported in the ospl help for code 16. |
OSPL-6743 | The calculation of a key hash for a key type that is 8-bytes could lead to a crash. The client-durability feature calculates a md5 key hash for topic keys that do not fit in 16 bytes. The hash calculation for an 8-bytes type key contained an error, leading an invalid key. Access to such key could lead to a crash. Solution: The hash calculation is changed so that the correct hash is calculated. |
OSPL-6748 / 14821 OSPL-6760 / 14833 | Old sample erratically rejected causing weird resending behaviour. Due to an issue with handling the case that an old sample is not stored in the reader because there is already newer data available (KEEP_LAST), a writer (or service) would begin to retry delivering that sample. As long as the state of the reader/instance doesn't change, this will continue to behave wrongfully. Solution: The proper return-code is now returned, causing the sample to be accepted instead of rejected. |
OSPL-6690 | ncorrect use of the '#' character in the RTNetworking protocol for topic-/group-coherency Due to a bug in the handling of transaction-markers in the RTNetworking protocol, partition-names starting with a '#' could cause problems. Solution: The processing of transaction markers in the RTNetworking protocol has been fixed. If coherency with access_scope V_PRESENTATION_TOPIC is used on a build since V6.5.0p5, this will not interoperate with this fix included and an upgrade must be performed to get the bug resolved. |
OpenSplice v6.5.0p8
Report ID. | Description |
---|---|
OSPL-6687 | When a sample request is received from an unknown fellow the durability service can crash When a sample request is received from an unknown fellow, the response that is generated contains flawed data which could cause the durability service to crash. Solution: The response now contains valid data so that the receiving durability service does not crash anymore |
OSPL-6685 | DDSI2 may "hang" reading from a socket When DDSI2 was configured to use only a single unicast port, it would attempt to read two packets from the socket corresponding to the unicast port when signalled that data was available. Usually, a packet would arrive in short order, but if it didn't happen DDSI2 would appear to hang (stop processing messages, fail to terminate properly). Solution: It now only reads when data is known to be available. |
OSPL-6588 / 14609 | ExitRequest handler interferes with Java shutdown hook The exit request handler that OpenSplice installs runs before the JVM runs the shutdown hooks. This causes a problem for an application that tries to do some clean up when the JVM shuts down due to failing DDS operations in Java with ALREADY_DELETED as result. Solution: For Java OpenSplice now does nothing for the posix signals SIGHUP, SIGINT and SIGTERM and windows signals CTRL_C_EVENT and CTRL_BREAK_EVENT before the JVM runs the shutdown hooks. This way an application can still do some clean up. After the application clean up the JVM will then trigger the OpenSplice clean up. |
OSPL-6622 / 14699 | Possible NULL pointer dereference could cause durability service to crash on segmentation fault Removal of a fellow assigned NULL to the request member of a chain object. This could cause the durability service to dereference a NULL pointer, causing it to crash with signal 11. Solution: Upon removal of a fellow the request member of a chain object is now copied. This fix ensures the request member is properly freed if the reference count of a chain object reaches zero. |
OSPL-6662 | API call create_persistent_snapshot execution time When API call create_persistent_snapshot is called it will take always at lease one StoreSessionTime to execute. This could lead to extra or less data in the snapshot than would be expected. Solution: The snapshot will now be executed as soon as possible and will not wait at least one StoreSessionTime. |
TSTTOOL-180 | Difficult to send amended topic instances in OpenSplice Tester Tester scenarios in which a topic instance is sent, and then repeatedly amended and resent were tedious, and error prone to write, as each send instruction had to repeat all sample fields, even if only a few had changed. Solution: A new 'update parameter' (composed of the topic name followed by _update) is now accepted by the send instruction. If the update parameter is present, the sample data sent will be preserved by the topic reader. At most one sample per topic instance is preserved. If the update parameter's value is 'true', then the sample to be sent is initialized from the previously preserved sample for that topic instance, provided the topic reader has retained it. In all other cases, the sample to be sent continues to initialized from topic defaults. If a send instruction without the update parameter sends a sample, then the topic reader clears the saved sample data for the topic instance sent. Disposing the reader clears all retained sample data for that topic. |
OpenSplice v6.5.0p7
Fixed bugs and changes not affecting the API in OpenSplice 6.5.0p7
Report ID | Description |
---|---|
OSPL-3824 | C&M API cannot handle array of arrays, array of sequences, sequence of arrays and sequence of sequences The serializer contained bugs that caused the proper elements not to be found. Solution: Serializer now uses proper name generation functions where applicable and simplified retrieval of user data elements. |
OSPL-5245 | Write of c_char field would fail on writing certain characters to ospl log files The log contained error messages when writing certain special characters, even though the write would actually succeed for some of them. Solution: Fixed a case in the serializer where memory would be released twice, stop write on validation errors, and fixed scanning for octal sequences |
OSPL-6141 / 14430 | Deadlock in signal handler on trapping synchronous signal in signal handler The signal handler would deadlock if a synchronous signal was caught by the signal handler thread itself. Solution: The signal handler will not try to gracefully handle a synchrounous signal trapped by the signal handler itself. |
OSPL-6156 | In order to retrieve historical data on a node a durability service must be configured. For nodes with limited resources running that still want to acquire historical data a full-fledged durability service may not be desirable. Until now, if a late joiner wants to receive historical data, the late joiner must run a fully-fledged durability service. If the late joining device runs on a platform with limited resources, running a fully-fledged durability service may not be desirable. Instead of running a full-fledged durability service, an alternative way to acquire historical data whilst being on a platform with limited resources has been implemented. This feature is called client-durability. Using client-durability, a client can send out a request for historical data to a durability service that implements the client durability protocol. The server will then provide the requested data to the client. To enable the client-durability protocol in a durability service the Opensplice/DurabilityService/ClientDurability[@enabled] must be set to true. More information is available in the deployment manual. The client-durability feature is currently an internal feature of OpenSplice and not available for applications. Solution: An alternative approach to acquire historical data has been implemented that does not require running a fully-fledged durability service on the client node. |
OSPL-6626 | Heap and SHM leakage when using the tester in combination with the Soap service When using the Tester in combination with the Soap service topic related heap and SHM leakage occurs. Solution: The topic leakage has been fixed. |
OSPL-6490 | Crash of RnR service when storage path doesn't exist The RnR service would not allow creation of a storage in a non-existing path. This caused the service to publish a storage-status update to indicate the storage is in an error state, but a bug caused the service to crash shortly after updating its state. Solution: The behaviour was changed and the service will now create the required path if it doesn't exist. If the creation fails, i.e. due to permissions or a corrupt path name, the service updates the storage-status topic accordingly without crashing. A config command can then be issued to correct the path name and make the storage accessible to record and/or replay commands. |
TSTTOOL-260 | No reliable way to recheck the last sample of topic instance in OpenSplice Tester Tester instructions such as check_last and check_any would not reliably find the most recent sample for a topic instance. Solution: A new instruction, 'recheck_last' was introduced. It's syntax is identical to check_last, but it's behaviour is different: recheck_last will always check the most recent sample received, where as check_last fails if that topic has already been checked by a previous instruction. |
TSTTOOL-180 | No way to invoke a JavaScript without invoking another instruction in OpenSplice Tester The scenario syntax did not allow for the direct invocation of a JavaScript (or other script language). Instead, users needed to include the script as part of another instruction, such as the log instruction. For scenarios making heavy use of scripts, this was both inconvenient, and resulted in unnecessarily large log files. Solution: Scripts are now allowed in scenarios at the same level of as other instructions. The script must be enclosed in back quotes (`). The script invocation block (script enclosed in its back quotes) must be terminated by a semi-colon. |
TSTTOOL-179 | OpenSplice Tester provides no feedback on data conversion errors Sending a sample which included invalid data (e.g. sending a floating point value to an integer field) were silently ignored. No entries were made in the Tester log. Solution: Tester now checks for invalid values, and creates appropriate log entries. |
TSTTOOL-194 | OpenSplice Tester fails reading scenario files in some cases Tester would fail to start if it did not have permissions on all the folders containing the specified script and/or macro paths. Tester could open the wrong script/macro file if a backup copy with a tilde (~) appended to the full name was present. Solution: Tester correctly opens starts and opens scenario and macro files for which it has at least read access. |
OpenSplice v6.5.0p5
Fixed bugs and changes not affecting the API in OpenSplice 6.5.0p5
Report ID. | Description |
---|---|
OSPL-5888 | Listener scheduling QoS settings were not being honoured Listener scheduling QoS (changes) where not applied to the listener dispatcher thread. Solution: The QoS operations involved in setting and updating listener scheduling changes have been reworked and the listener dispatcher code was altered to be event based. |
OSPL-6156 | For nodes with limited resources running that still want to acquire historical data a full-fledged durability service may not be desirable. Until now, if a late joiner wants to receive historical data, the late joiner must run a full-fledged durability service. If the late joining device runs on a platform with limited resources, running a full-fledged durability service may not be desirable. Instead of running a full-fledged durability service, an alternative way to acquire historical data whilst being on a platform with limited resources has been implemented. This feature is called client-durability. Using client-durability, a client can send out a request for historical data to a durability service that implements the client durability protocol. The server will then provide the requested data to the client. To enable the client-durability protocol in a durability service the Opensplice/DurabilityService/ClientDurability[@enabled] must be set to true. More information is available in the deployment manual. The client-durability feature is currently an internal feature of OpenSplice and not available for applications. Solution: An alternative approach to acquire historical data has been implemented that does not require running a full-fledged durability service on the client node. |
OSPL-6194 | When there are many pending sample requests the durability service becomes very slow. The durability service internally keeps a list of pending sample requests. Each time a new request is received the durability service will traverse the list to see if there exists a pending sample request for the same partition and topic. If so, these requests will be combined. The algorithm to find if a request is already pending used an inefficient implementation, causing high CPU load and unnecessary delays in situations where the list of pending sample requests is very long. Solution: The implementation to see if a request is already pending now uses an optimized algorithm. |
OSPL-6258 | Liveliness of a remote node not always consistent among services, built-in topics A number of independent heartbeat mechanisms were used in parallel, resulting in different parts of a single federation having short-term inconsistencies between their views of the set of live remote nodes as well as introducing dependencies between the configuration of services to ensure dependencies between the services (e.g., networking and durability) in removing a node were handled correctly. Solution: The mechanisms have now been consolidated. |
OSPL-6272 | Networking bridge log verbosity The configurator contains a non-existent value 'finer' for the networking bridge tracing level verbosity. Solution: The value finer is removed from the configurator. |
OSPL-6320 | Bind error when reconnecting after a network adapter does down and then up. When trying to reconnect after an ethernet adapter went from down to up a 'bind returned errno 22 (Invalid argument)' message could occur in the ospl-error log. Solution: The reconnect mechanism is adjusted and the error will not occur anymore. |
OSPL-6332/ 14527 | ISOCPP listeners might reference invalided entities ISOCPP listeners used a raw pointer to reference DDS entities on stack that might have been invalidated. Solution: ISOCPP listeners now use a dds::core::WeakReference to keep a reference to DDS entities. |
OSPL-6385 | Durability service internal algorithm to read protocol samples should be optimised The durability service creates datareaders to receive information from fellow durability services to align historical data. The internal algorithm to read this data, takes one sample at the time where taking all samples at once would be more efficient processing-wise. Solution: The durability service has been modified to take all available samples at once. |
OSPL-6408 | Invalid default max_blocking_time for DataWriter with BEST_EFFORT reliability in ISOC++ API The ISOC++ API set the default Reliability.max_blocking_time to zero instead of 100 ms for DataWriters with BEST_EFFORT reliability. Solution: DataWriters now always have 100ms as default max_blocking_time no matter their reliability. |
OSPL-6437 | Topic-access feature behaves unexpectedly When using the Topic-access feature unexpected errors can occur in OpenSplice because the builtin topics are also slaved to this setting. Solution: The builtin topics ignore the topic-access setting so OpenSplice will keep working. |
OSPL-6454 | Installer crashes in text mode A fault with the third party installer creation program causes OpenSplice to crash when text mode is used Solution: The install cration program for OpenSplice was fixed. |
OSPL-6477 | Default Secure Networking configuration files contain an error The default secure networking configuration files contained a fault which could lead to an error when loaded into the configurator. Solution: The fault is fixed and the configurator can load the file without errors. |
OSPL-6488/ 14510 | Tuner problem when writing a bounded character array There was a fault in the tuner when trying to write a bounded character array. When the array is written the data was ignored. Solution: The array is not ignored anymore and the data will be written. |
OSPL-6491 | Remove dependency on CORBA::string_dup in RMI Vortex Lite shares some of the RMI codebase, but does not support CORBA co-habitation. rmipp generates code that includes CORBA::string_dup that Vortex Lite does not support. Solution: rmipp changes to generated DDS::String_dup instead that is supported by both Lite and OpenSplice. |
OSPL-6496 | Adding RMI support to operate without a durability service RMI services registration and discovery relies on Transient DurabilityQosPolicy as provided by a durability service in OpenSplice. In some specific deployment conditions, that service is not available. RMI should be adapted to support that use case. Solution:A new command line option called "--RMIDurability = yes | no" was added to indicate the availability of the durability service. Please refer to the RMI documentation for more details. |
OSPL-6531/ 14566 | DDS-RMI OSGi bundle not exporting all required packages An issue in the manifest for the OSGi bundle of DDS-RMI, caused the bundle to be incompatible with application bundles that contain code generated by rmipp. Solution: The DDS_RMI.Impl packages were added to the Export-Package manifest attribute |
OSPL-6640/ 14547 | Problem with license files The information to get a license is not accurate for the Windows platform in the getting started guide. Solution: The getting started guide has been updated to reflect the proper command on Windows. |
OpenSplice v6.5.0p4
Fixed bugs and changes not affecting the API in OpenSplice 6.5.0p4
Report ID. | Description |
---|---|
OSPL-6464/ 14412 | 14412 Semaphore handle leak on Windows An issue in the OS abstraction layer of the product caused a leak of semaphore handles. When a condition variable, used in many areas of the product i.e. when notifying a WaitSet or acknowledging a synchronous write, is triggered while no other threads are blocking on the condition, a shortcut is possible. However this shortcut contains a bug and leaks a semaphore handle. Solution: The issue was resolved by making sure the handle is closed in all circumstances. |
OpenSplice v6.5.0p3
Fixed bugs and changes not affecting the API in OpenSplice 6.5.0p3
Report ID. | Description |
---|---|
OSPL-2967 | Deadlock in Java listeners Terminate from within a listener callback required a new Thread from within the callback and call System.exit() in that thread. Solution: The additional thread is no longer required. nt 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-5684 | Reference guide update for SchedulingQosPolicy The reference guides did not mark SchedulingQosPolicy as OpenSplice proprietary property. Solution: Minor updates to guides only. 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-3936 | DDSI2 memory leak when retransmitting part of a fragmented sample because of retransmit queue limiting When DDSI2 attempts to retransmit a fragmented sample, but reaches the retransmit queue limit at the first fragment, it can leak one HeartbeatFrag message. Solution: Memory leak fixed. 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-4471 | Configurator does not support fields other than string values to contain environment variables The configurator does not support fields other than string values to contain environment variables i.e. ${DOMAIN_ID} Solution: The configurator does now support environment values for every input type except enum types and booleans. However Enum types/boolean environment variables are supported by all services so by editing the configuration file manually it still can be used. 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-5557 | Starting Tester in an environment where the data types for OsplArrayTopic and OsplSequenceTopic were already registered, caused errors to be printed in the ospl error log. Tester tries to register its topic types on startup. However, due to a slight change in the way the meta type is defined internally, if the topic types were registered previously, then trying to register them again caused a meta type mismatch error. Solution: The XML meta type definitions for OsplArrayTopic and OsplSequenceTopic have been updated. The error no longer appears. . |
OSPL-5575 | Begin/End Coherent Changes API calls did not return the correct return code in case of a failure. When using the Begin/End Coherent Changes API calls it was possible that an incorrect return code was returned. Solution: The calls now return a correct return code as per spec. |
OSPL-5739 | When there are other users running OpenSplice then the command "ospl stop -a" may fail. The ospl stop -a command may fail when there are other users running OpenSplice. The ospl stop -a command tries to open all key files associated with the running OpenSplice instances. When it cannot open a key file because it belongs to another user the ospl stop -a command stops and reports an error. Solution: When the ospl stop -a command walks over the key files and finds a file it cannot open it should not stop and instead continue parsing the next key file. |
OSPL-6030 | Java OSGI Support Only the standalone Java language binding had an OSGi compliant jar file. It was a separate jar file called dcpssaj-osgi-bundle.jar. Solution: The following jar files are now OSGi compliant: dcpscj.jar, dcpscj5.jar, dcpssaj.jar, dcpssaj5.jar, ddsrmi.jar and rlm.jar. These OSGi jar files can still be used as 'normal' jar files. No extra separate OSGi jar files needed. Only dcpssaj-osgi-bundle.jar is maintained for backwards compatibility. |
OSPL-6192 | Incomplete error messages A review of error log output across the OSPL APIs has been completed and a number of reports have been improved. |
OSPL-6285/ 14506 | Non terminated AsyncReplyWaiter threads in case of concurrent asynchronous methods invocations When the application invokes multiple asynchronous requests concurrently, multiple threads called AsyncReplyWaiter are created and not terminated by the runtime stop operation. The AsyncReplyWaiter thread is the thread that waits for asynchronous replies and dispatches them to the user asynchronous reply handlers. There should be only one AsyncReplyWaiter thread per process that is terminated at runtime stop. Solution: The AsyncReplyWaiter thread creation has been properly synchronized to avoid creating multiple AsynchReplyWaiter threads. |
OSPL-6286/ 14507 | RMI asynchronous reply handler may be called back for an invalid reply This may happen when the rmi server stops running for some reason. If a client issues an asynchronous request after that, it may receive an invalid reply including random values. Solution: The RMI asynchronous reply has been updated to process only valid reply topics samples. |
OSPL-6323 | Durability can deadlock on discovering an unclean shutdown of a remote fellow There are various ways in which the durability service can discover that a remote fellow no longer exists, and under most circumstances will detect this by the absence of a heartbeat. There are however some other ways that are only rarely used, and one of these would result in a deadlock in durability, and in such a way that it would have significant consequences for the rest of the federation. Solution: This deadlock has been fixed. |
OSPL-6351/ 14533 | Shared memory monitor sometimes couldn't find specifyied domain name Shared memory monitor couldn't properly compare domain names because of trailing whitespace. Solution: Updated keyfile parser to trim lines before analyzing them. |
OSPL-6352/ 14532 | Warnings when compiling c++ header files with-Wignored-qualifiers using gcc 4.8.2 When compiling code with OSPL c++ include headers files with the -Wignored-qualifiers compiler flag warnings show up. Solution: The c++ include files now compile without warnings when -Wignored-qualifiers is set. |
OSPL-6371 | Unable to use Foo type name in classic C++ PSMs Compilation errors occur when building code generated by idlpp, if the application idl specifies a type named Foo. This type is also used internally, leading to name clashes with existing classes and methods. Solution: The issue was resolved by using fully scoped names in idlpp templates. This ensures the classes from the DDS::OpenSplice namespace are used instead of the application namespace. |
OSPL-6387/ 14539 | Attaching conditions to a waitset during a wait could cause a crash Due to an error in the administration of the waitset, a crash could occur if the internal administration of the waiset grew to contain over 32 conditions while waiting on the waitset. Solution: The error in the administration has been resolved. |
OSPL-6402/ 14542 | Wrong directory path in windows PATH variable When installing OpenSplice on Windows and choosing to let the installer set the environment variables the installer adds a non existing directory path (%OSPL_HOME%/host/lib) to the PATH variable. Solution: The installer does not add the non existing directory path anymore. |
TSTTOOL-203 | Tester unable to handle bounded and unbounded arrarys and sequences of characters. Solution: Tester now properly reads in and write to the DDS, field data of bounded and unbounded arrays and sequences of characters. This feature is fixed in both the sample editor dialog (in the UI) and the scripting engine. |
OSPL-6431 | An API_INFO report message is reported in the ospl-error.log but should be reported in the ospl-info.log. When an API_INFO report message is reported in the context of an API call then the API_INFO report is mistakenly reported in the ospl-error.log instead of the ospl-info.log. Solution: When an API_INFO message is reported the ospl-info.log file is selected instead of the default ospl-error.log. |
OpenSplice v6.5.0p2
Fixed bugs and changes not affecting the API in OpenSplice 6.5.0p2
Report ID. | Description |
---|---|
OSPL-5859 / 14325 | Durability alignment may require larger amount of shared memory than expected During the alignment process, the durability service may collect historical data from multiple sources and these sources may (partly) have overlapping sets of historical data. When these data-sets are received, durability needs to filter out the duplicates and once all data from all sources has been received, republish the set locally. Due to an issue in a durability algorithm, the duplicates where only filtered out at republishing time and not on reception time, causing an temporary, but unnecessary, need for a larger amount of shared memory. Solution: The flaw in the durability algorithm that filters out duplicate samples on reception has been repaired. |
OSPL-5930 / 14351 | Invalid configuration of networking service not detected at startup and causing a crash at termination. In case the networking service is started with a missing or invalid configuration, the service would still run but a connection with other nodes is never established. At termination the service could crash on freeing internal administration related to configuration parameters. Solution: The service will now refuse to start when mandatory elements of the configuration, such as channels, are missing or invalid. An appropriate report is logged to the error log. |
OSPL-6083 | iShapes example readers should be created with INFINITE latency-budget QoS To allow demonstrating (the effects of changing) LATENCY_BUDGET, the readers should be created with an infinite latency-budget as this is a RxO Qos. Solution: readers are now created with INFINITE latency-budget. |
OSPL-6176 | Durability may report error if no persistent data exists on disk The durability service may report the error 'Unable to resolve persistent data version.' during start up when there is a topic definition on disk already, but no data yet. Solution: The error is now no longer reported under these particular circumstances that are deemed valid. |
OSPL-6279 / 14503 | All XML documents received by registered report plugins start with an error element All XML documents received by registered report plugins started with an error element instead of using a string representation of the report type passed when generating the report Solution: The string representation of the report type is now properly used to start and end the XML document |
OSPL-6280 | A non-OpenSplice reliable writer does not to deliver data to an OpenSplice best-effort reader using DDSI when on the OpenSplice side RnR is enabled. As RnR was using a reader with private QoS setting named QoS matching relaxing to receive both best-effort and reliable data. DDSI implementations that didn't understood this setting saw the reader as a best-effort reader. When a sample was lost, the RnR reader would request a retransmit, as this is required for the reliable data. However, as the reader was seen as a best-effort reader by the writer, this retransmit request was ignored, causing the data to be never delivered. Solution: RnR will now create separate readers for each non-matching QoS setting (reliable/best effort and shared/exclusive ownership) |
OSPL-6282 | iShapes GUI badly formatted The publisher buttons of the iShapes demo application are badly formatted compared to the rest of the interface. Solution: Fixed the formatting. |
OSPL-6288 | User data QoS empty in participants discovered via DDSI2 An issue in the processing of the participant QoS caused the UserDataQoS to be empty for all remote participants discovery via DDSI discovery. This issue did not affect systems using RTnetworking. Solution: UserDataQos is now exchanged again during discovery. |
OSPL-6297 / 14516 | Find topic timing behaviour incorrect The find topic method on a DomainParticipant has a timeout parameter that specifies the maximum blocking time to wait for the topic to appear. In certain cases the method would block for 100 ms too long, which can have a noticeable impact on the application when called often on topics that don't yet exist. Solution: The implementation was changed to never exceed the maximum timeout. |
OSPL-6295 | Windows start menu entry needs to be moved The location in the start menu on Windows does not match other Vortex products and needs to move to 'PrismTech/Vortex OpenSplice' Solution: Moved start menu entry to requested location. |
TSTTOOL-167 | Tester hangs and won't close if soap connection fails Ospl tester hangs when the soap connection fails due to an issue in an internal algorithm. Solution: Tester does not hang anymore when soap connection fails. |
TSTTOOL-182 / 14349 | Ospl tester appears to lock up Ospl tester appears to lock up due to the fact in runs out of memory when consuming large amount of samples. Solution: Added new preference to limit number of samples kept per reader under File>Preferences>Settings>Max Samples Per Reader The preference only takes only integer values. Default value is "0" which means infinite number of samples kept. |
TSTTOOL-184 / 14348 | New instance not automatically displayed in tester In Tester, if an application data writer has a QoS of autodispose_unregistered_instances set to false and then unregister_instance is called on a data writer for some instance, a sample reaches matching data readers with the no_writers state and is ignored. Solution: A new boolean option has been added in the Preferences menu under the Settings tab, called "Ignore not_alive_no_writers samples" and is set to true by default. If the option is set to false, then these specific samples will be displayed in Tester. |
TSTTOOL-190 | Tester does not show Vortex Lite ishapes instances in its topology unless user disconnects and reconnects Tester's Reader/Writer Tables (in the Browser Section) does not show all partitions for readers/writers with more than 2 partitions. Solution: Updated Reader Info and Writer Info to retrieve all the available partition names from the user data and display them properly in the Browser tab. |
TSTTOOL-191 / 14350 | No convenient way to select an existing partition Ospltest tool does not provide a convenient way to select an existing partition when creating a reader. Solution: User can now select from a list of existing partitions when trying to create a new reader. |
TSTTOOL-192 / 14352 | Ospltest gives errors on startup The script directories are not included in the RTS installers. Solution: Updated scripts and install directories to fix these errors. |
TSTTOOL-194 / 14443 | Tester Script and Macro paths The Tester does not have permissions for every file/folder within and below the path specified for its script/macro area it will not start. Solution: Tester is now updated to read files with extensions .sd, .md and .bd. |
TSTTOOL-195 / 14447 | Ospl tester and marks being treated as failures If Tester is receiving a very large amount of samples, and a mark command is run, the execution of the command wants to iterate through the sample list to mark all the samples it needs to ignore. However, if this iteration does not complete before the next sample comes in from the data reader, then it can throw this exception. Solution: Fixed tester to add marks properly. |
OpenSplice v6.5.0p1
Fixed bugs and changes not affecting the API in OpenSplice 6.5.0p1
Report ID. | Description |
---|---|
OSPL-6250 | Java5 Protobuf example Build.bat script is not working The Build.bat file that is delivered to compile the Java5 Protobuf example contains a copy-paste error from the one derived from Linux. Solution: Bat file has been modified to allow compilation of the example on Windows |
OSPL-6250 / OSPL-6263 / OSPL-6270 | Java5, ISO C++ and C# applications may crash on termination Applications using the Java5 DDS API may crash at termination time due to an issue in the automatic clean up procedure. Solution: The issue in the automatic clean up procedure has been fixed. 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-6253 | ISOC++ listeners may be deleted to soon Applications using the ISO C++ DDS API may experience that entities have already been deleted during listener call backs. Solution: The entity deletion procedure now waits for potential listener callbacks to finish before deleting the entity. |
OpenSplice v6.5.0
Fixed bugs and changes not affecting the API in OpenSplice 6.5.0
Report ID. | Description |
---|---|
OSPL-1722 | Synchronous reliability not supported when using DDSI2 OpenSplice DDS' synchronous reliability feature was not supported using DDSI2 and resulted in timeouts on the writer side because one of the built-in endpoints needed for processing the acknowledgements could not be discovered by DDSI2. Solution: The built-in endpoint is now discovered by DDSI2 and synchronous reliability is now supported. |
OSPL-3837 | Tuner generates error when starting with the -uri argument When the Tuner is started with the -uri argument, an error is generated in the error log file. Solution: The error is not generated anymore. |
OSPL-4841 / 12996 | Crash in WaitSet_wait for Java application In some situations a java application could crash in a Waitset_wait. Solution: The java api language binding has been rewritten. With this new implementation the code causing this crash is not present anymore. |
OSPL-4383 | Serializer serializes wrong double/float values when LC_NUMERIC is not equal to the default "C" locale. The LC_NUMERIC of the "C" locale is '.'. OpenSplice assumes doubles and floats to always have a '.' as LC_NUMERIC. But a few locales use a different LC_NUMERIC (like fr_FR and nl_NL use ','). The (de)serializing of doubles and floats is locale dependent and thus this LC_NUMERIC difference will cause problems when a different one is set on the system. Solution: Make double/float to/from string conversions locale LC_NUMERIC independent. |
OSPL-5095/ 13095 | No convenient RMI API for non default DDS domain Most of the RMI features are available via the org.opensplice.DDS_RMI.DDS_Service class, but this class works on the default DDS domain only. Solution: The Java and C++ RMI API has been extended so that the RMI applications can use any DDS domain id in a convenient way. As the CRuntime object is tied to the used DDS domain, a new method has been added to that class with the following signature : DDS_ServiceInterface getDDS_ServiceInterface() The DDS_ServiceInterface provides all the convenient methods to register/unregister services, run/shutdown them, and getting service proxies on the runtime-specific domain id, as does the DDS_Service class for the default domain. You can find a detailed description of that interface in the RMI API reference documentation. So, to use a non default DDS domain for RMI invocations, the developer should, first, get a CRuntime object for the wanted domain id as follows (in java): CRuntime runtime = CRuntime.getRuntime(domain_id); DDS_ServiceInterface dds_Service = defaultRuntime.getDDS_ServiceInterface(); then, dds_Service can be used to make the usual actions for client and server RMI applications. |
OSPL-5265 | idlpp -j package prefix not applied to module-less types idlpp package prefixes specified using the -j option were not applied to module-less types. Solution: The behaviour of idlpp changed in version 6.5 and prefixes are now properly applied. |
OSPL-5329 | Windows installation path On 64bit windows version a 64bit version is installed in C:\Program Files (x86) Solution: The 64 bit installation directory is changed to C:\Program Files\ |
OSPL-5424 | Windows Registry Keys not cleared on uninstall Registry key entries in HKEY_CURRENT_USER under Software -> PrismTech -> OpenSpliceDDS -> Version were not cleared when uninstalling. This was due to a bug in the uninstaller that prevented it completing. This could result in a number of entries in the HKEY_CURRENT_USER if multiple versions of OpenSplice were installed. Solution: The bug in the uninstaller has been fixed and uninstall now completes correctly. The Registry key in HKEY_CURRENT_USER is now cleared for any new installations but it will not clear historical entries. |
OSPL-5605 / 14105 | Unable to attach shared memory in Java8 applications on 64-bit Windows The OpenSplice shared-memory database needs to be mapped to the same address in all applications. On 32-bit and 64-bit Windows, the same default address is used. This caused problems with recent Java8 on 64-bit platforms, where the default address is already occupied by the JVM. Solution: The default address was changed to 0x100000000, to make the product work out-of-the-box on 64-bit Windows platforms that use a recent Java8 JVM. Note the address can be changed through the Domain/Database/Address configuration parameter when the default is unsuitable. |
OSPL-5678 | Networking service crash when compiled with VS2012 The networking service encountered a VS2012 C Runtime bug that let it crash: https://connect.microsoft.com/VisualStudio/feedback/details/782889/ Solution: Don't call strftime() with "%Z" when compiled with VS2012. |
OSPL-5697 | Declaring multiple RMI operations having the same name in different interfaces lead to compilation errors of C++ generated code Declaring two or more RMI operations with the same name in different IDL interfaces makes the compilation of the generated C++ proxy classes fails because of a duplicate typedef declaration. Solution: The RMI C++ code generator has been updated to declare the typedef in the scope of the related RMI interface proxy class instead of the global scope. |
OSPL-5789 / 14287 | Wrong error code returned by ospl The error codes, returned by ospl, did not reflect the information within the usage help text of ospl. Also, extended error codes and a small behaviour change were required as well. Solution: The normal ospl error codes have been improved. Also, the extended error codes will be returned when using the -e option. |
OSPL-5793 / 14284 | Error missing field initializers in the OpenSpliceRMI header file dds_service_sdk.h gcc compilation could warn or fails (with -Werror=missing-field-initializers option) about missing filed initializers for member "DDS::ReliabilityQosPolicy::synchronous" in the RMI header file "include/rmi/dds_service_sdk.h" Solution: The missing field initialization has been added. |
OSPL-5832 / 14298 | Termination issues while listener callback in progress. The listener callback implementation contains in concurrency issues which were difficult to resolve due to the internal design limitations. Solution: The mechanism has been redesigned, moving control of the listener thread into the PSMs. |
OSPL-5844 | DCPS Java 5 PSM does not use correct default domain id The internal default domainId is 0x7fffffff. In this case this domain id is used, the OSPL_URI environment variable is inspected and the domain id in there is used. The Java 5 PSM always uses 0 as default domainId. As a result setting OSPL_URI i.c.w. a non-zero domainId did not allow applications to create a DomainParticipant. Solution: In case no domainId is provided on creation of the DomainParticipant, OpenSplice checks the domainId in the OSPL_URI and uses the domainId specified there. This is not always 0 as specified in the Java5 PSM as default id. As our default config files that we ship always use 0, this is deemed acceptable behaviour. |
OSPL-5848 / 14321 | The durability service can crash i.c.w. dispose_all functionality The durability service could crash due to a null-pointer dereference in an internal algorithm related to the dispose_all functionality. Solution: The internal algorithm has been modified to deal with dispose all properly as well. |
OSPL-5847 / 14320 | Unable to read sample that complies to readcondition Due to a locking problem in the product, a read call could return NO_DATA while actually there is data available Solution: The issue has been resolved by adding a lock while freeing internal data |
OSPL-5849 | The Java5 DCPS implementation does not handle infinite duration correctly in Waitset.waitForConditions calls. The Java5 DCPS implementation internally converts durations to a different representation. In the Waitset.waitForConditions() operations the conversion algorithm was incorrect. Solution: Fixed the conversion routine to deal with infinite durations correctly. |
OSPL-5880 / 14330 | Crash of RTSM tool The RTSM tool fails to attach to shared memory and crashes on a segmentation violation due to a mismatch in the layout of internal data-structures. Solution: The issue was resolved and the code has been updated to prevent similar issues from occurring in the future |
OSPL-5893 / 14333 | The durability service could crash when running out of shared memory The durability service did not check in all cases whether the allocation of a sample in shared memory succeeded. As a result it could dereference a null-pointer and crash. Solution: The durability service did not check in all cases whether the allocation of a sample in shared memory succeeded. As a result it could dereference a null-pointer and crash. |
OSPL-5905 | Selecting a network interface for DDSI2 using the network address fails on Linux The comparison of the specified address and the network interface address failed to take the network mask into account. Solution: Code fix applied. |
OSPL-5910 / 14339 | A valgrind memcheck analysis of certain functionality reports: Invalid read of size 4 The copy subscriber qos out function from the gapi subscriber is creating a normal string for the name in the qos. This should be a gapi object string, as it is also freed as an gapi object. Solution: The copy out function is now creating the correct gapi object for the string. |
OSPL-5913 | Transport priority in built-in topics for remote writers always 0 when using DDSI The DDSI2 service generates built-in topics for the remote entities it discovers, but failed to correctly set the transport priority QoS in the CMDataWriter topic, leaving it at the default value instead. Solution: DDSI2 now sets the transport priority. |
OSPL-5999 | Tuner corrupts OSPL_URI when used with argument -uri= When starting the Tuner with the argument -uri=$OSPL_URI the OSPL_URI would be overwritten by the tuner property file. Solution: The OSPL_URI is no longer overwritten. |
OSPL-6053/ 14398 | Errors reported about lack of multicast capability by networking service, when no multicast communication is configured The networking service checks multicast support when a partition is added to it's internal administration. Even when the network-partitions are configured to use broadcast or unicast, the service still performs this check, leading to error reports when it determines multicast is not supported. Solution: The check was moved so it is only performed after determining the address is in fact a multicast address. |
OSPL-6069 / 6079 14409 / 14412 | Missing RMI asynchronous replies in some cases and their memory cleanup In case of an OpenSpliceRMI Java application that invokes multiple asynchronous calls intensively, some of the asynchronous replies could be lost. Furthermore, every asynchronous request is uselessly kept in memory, which increases dramatically the memory footprint of the RMI server. Solution: A bug in the asynchronous replies management of Java OpenSplice RMI has been fixed. The Java RMI generated code has also been updated consequently. So, existing java RMI applications should re-generate their code using rmipp. |
OSPL-6119 | DDSI can spontaneously change best-effort max_blocking_time DDSI tries to minimise the discovery traffic by leaving out all QoS's that are set to the default (this can be overridden using Compatibility/ExplicityPublishQosSetToDefault), relying on the peers' filling in the defaults again. The decision whether the reliability QoS was at the default value or not was not correctly accounting for the max_blocking_time part of it. Solution: Reliability QoS value now set correctly. |
OSPL-6134 | Documentation links in RTS don't work Documentation links in the RTS installer don't work as the target files are not available. Solution: The RTS should not include the documentation, so it has been removed. |
OSPL-6145 | RnR replay crash Whenever RnR replay had to wait for the resources to become available or for the networking services to be ready to accept data for a partition/topic combination introduced by the replay, RnR could crash. Solution: The issue has been fixed. |
OSPL-6160 | RnR replay fails when topic definitions are provided by recording RnR does not store/inject topics automatically, instead requiring the user to record and replay the DCPSTopic topic. Replaying a topic definition means that the topic becomes available once spliced has processed the sample, but this may be too late for the writer creation in RnR. Solution: RnR now creates the topics synchronously. |
OSPL-6207 | Report plugin robust against null pointer exception The report plugin could crash if it experienced a null pointer exception. Solution: The plugin is now robust against the exception. |
OSPL-5524 | Java Throughput example exception when running a 2nd publisher Due to an issue in the internal administration of the java subscriber-part of the throughput example, the subscriber would terminate with an exception in case the publisher is stopped and started for the second time. Solution: The algorithm to update internal administration has been fixed. |
Fixed bugs and changes affecting the API in OpenSplice 6.5.0
Report ID. | Description |
---|---|
OSPL-5899-1 | Listener and waitset trigger order In the previous releases before V6.5 listeners and waitsets where triggered in random order but the specification prescribes that listeners are triggered before waitsets. Solution: In V6.5 we have partly corrected the behavior, as it now behaves deterministic in the following order: trigger the waitsets containing affected read and query condition. invoke the listeners. trigger waitsets containing affected status conditions. In a future release we will correct the order of the first two items, as they should be in reverse order. Important remark for existing applications: Previously if a listener is set on a status condition of an entity and the same status condition is attached to a waitset then both the listener would be invoked and the waitset would return the status condition. In V6.5 the waitset will no longer return the status condition. The listener will reset the status condition before the waitset is triggered implying that the waitset will not return the status condition because it no longer evaluates true. Additionally, if an application has not set a listener but accidentally has set the listener mask, the waitset will no longer return the status condtion. It appears that only a waitset is used on a status condition but in reality a default listener is set which will reset the status condition before the waitset is triggered. |
OSPL-5899-2 | Listener mask behaviour change According to the DDS specification setting a listener mask for specific events without implementing a listener for those events (i.e. specifying a 'NULL listener') will act as if a listener is set and as a result will consume the events and not propagate events to listeners of its parents or waitsets. Before V6.5 setting a mask had no effect when not implementing a listener meaning that events where not consumed so parent listeners and waitsets where still triggered. Solution: The issue is fixed, but applications must be aware that if the mask was set by accident, they might be missing events they have received before if listeners are set on parent entities or associated conditions are used in waitsets. |