This page lists all the changes and fixed bugs in OpenSplice v6.2.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.2.x
OpenSplice v6.2.3p1
Fixed bugs and changes not affecting the API in OpenSplice 6.2.3p1
| Report ID. | Description |
|---|---|
| OSPL-2110/ 11592 | On Windows the disconnection or connection of a network interface cable causes large memory loss A status change of the network interface triggers an event. A memory leak occurs when handling this event. Because the status of the event is not automatically reset the function to handle event is called repeatedly. Solution: The memory leak is removed and the network interface status change event notification is re-enabled to allow new network interface status changes to be detected. |
Showing 1 to 1 of 1 entry
OpenSplice v6.2.3
| Report ID. | Description |
|---|---|
| OSPL-948/ 10679 | DDSI2 sends duplicate samples for writers that publish in multiple partitions simultaneously A write in multiple partitions simultaneously is received by DDSI2 as a number of messages from a single writer, one for each partition. All these message were forwarded by DDSI2 and filtered out by the subscribers running OpenSplice. However, this required extra bandwidth and besides caused other vendors' implementations of the DDSI protocol to report them as independent updates. Solution: This behaviour has now been changed, so that DDSI2 filters out such duplicates in the vast majority of cases. In particular, as long as the writer, its local subscribers and the networking services do not run into resource limits, it is guaranteed to filter out all duplicates. The filter can, under very unlikely circumstances, conclude a message is a duplicate when in reality it is not. This requires publishing more than 4 billion samples with a single writer while carefully controlling the behaviour of the writer history cache using resource limits on local readers; a situation no real system is likely to ever encounter. We advise that on systems that may run into this, the Unsupported/ForwardAllMessages setting be set to true. |
| OSPL-966/ 10707 | The RTSM tool is no longer working As a protection mechanism the RTSM tool does not continue processing when it thinks that a given address is not valid. One of the steps it takes to determine whether an address is valid, is to check whether the address lies in the virtual memory range that is expected based on the configured size of the shared memory segment. However, the tool determined the size of a shared memory segment in the wrong manner. Due to this issue the tool reports perfectly valid addresses as 'faulty' and no further processing is done. Solution: The algorithm that calculates the size of the shared memory and correct range for addresses has been repaired to ensure valid addresses are no longer reported as 'faulty' and all further processing can be done. |
| OSPL-991/ 10735 OSPL-1771/ 11395 | take() and take_w_condition() do not have the same behaviour/random crash on take next instance The dispose_all_data operation on the topic was not treated identically to sending a separate dispose message for every entity. This manifested itself especially in the way the disposed data was delivered to late joiners (which sometimes couldn't see that the data was actually disposed) and in the way disposed data ignored the cleanup delay specified on the durability service. Solution: The new implementation of dispose_all_data is much more inline with sending separate dispose messages for every instance, and thus late joiners will always see the correct instance state. Furthermore the dispose messages obey the same cleanup delays as normal dispose messages. However, the dispose_all_data function will still be me more efficient with respect to the utilization of network network bandwitdth, CPU cycles and memory than the manual transmission of separate dispose messages. |
| OSPL-1205/ 10845 | Terminating applications report pthread_join failed with error 35 When an application with a defined exithandler terminates and this exithandler contains an exit call the ospl-error file will report the message: pthread_join failed with error 35. Solution: The defect in the OpenSplice signalhandling is fixed and this error will not be reported anymore. |
| OSPL-1334/ 10898 OSPL-1335/ 10899 | PurgeList may illegally remove a groupInstance. The purgeLists are sometimes populated by the same instance multiple times (for different generations). Although the purgeList expiry algorithm should handle these situations correctly, it seems some scenario's are not properly handled yet, and a groupInstance from the emptyPurgeList may be freed while it is already reincarnated as a new generation. Solution: New code has been added that prevents outdated generations from being inserted into the emptyPurgeList, thus preventing this list from having duplicate entries and thus preventing it from deleting a groupInstance that is already reincarnated. |
| OSPL-1341 / 10914 OSPL-1930 / 11473 | The reliable network communication may not operate correctly when the first messages of a sending node arrive out of order. When reconnection is enabled and when the first messages of another starting node arrive out of order and also the discovery heartbeats arrive later then the first message the reliable network channel will not operate correctly. Solution: The notification that a node has become alive by the discovery protocol should not reinitialize the reliable channel administration associated with that node when the reliable channel had already detected that the node was alive. |
| OSPL-1445/ 10981 | Possible deadlock when using the API find_topic function When in a multithreaded application, one thread uses the API find_topic function while the topic is not defined and the timeout is set, and another thread executes a function that needs the domain participant, the last thread will get blocked because the API find_topic function locks the domain participant and does not release it until the topic is found. Solution: The defect in the find_topic API function is now fixed and no deadlock will occur. |
| OSPL-1495/ 11040 | In DBMSConnect the mapping from DDS unsigned types to database record fields is not correct When a topic contains unsigned integer fields the mapping to the corresponding database schema is not correct. This means that the data written from DDS to database is not equal to the data that is stored in the database. This mapping is dependent on the DBMS used. For example MySQL supports unsigned integer fields while Microsoft SQL does not. Solution: The mapping of the DDS Topic fields to the corresponding database schema should be made dependent on the type of DBMS that is used. This also applies to the reading and writing of the database records. |
| OSPL-1557/ 10734 | Crash of durability during initial alignment Unregistrations that are aligned by the durability service are stored without any data to reduce footprint. These unregistrations can only be re-published locally when an instance handle is provided by the durability service while doing so. In some scenario's, the durability service did not use an instance handle while doing so, which made the service crash while locally republishing an aligned unregistration. Solution: The durability service now ensures an instance handle is created in any case while also making sure a registration is created in the instance for the writer that originally wrote the aligned sample. |
| OSPL-1512/ 11066 | PRECONDITION_NOT_MET doc update The reference manuals did not correctly document all cases where PRECONDITION_NOT_MET could be returned. Solution: Manuals updated. |
Showing 1 to 10 of 27 entries
OpenSplice v6.2.2
Fixed bugs and changes not affecting the API in OpenSplice 6.2.2
| Report ID. | Description |
|---|---|
| OSPL-1682/ 11291 | crash of spliced In certain scenario's the reader purgeList was doing invalid memory reads by trying to access already deleted purgeItems, thereby causing potential memory corruption of totally unrelated objects. Solution: The purge algorithm has been modified to prevent this situation, thus preventing the memory from becoming corrupted and improving the overall stability of the system. |
| OSPL-1729 | Calling DomainParticipantFactory.set_qos(_) using the Java API segfaults. The underlying JNI layer of the Java DCPS API used the wrong jfieldID when getting a value from Java. Solution: The correct jfieldID is now used. |
| OSPL-1852 | Topic disappearance when topic created in parallel In a scenario where a specific topic was created for the first time in the system, but for which a duplicate was created by another application before the original could enable its topic, a refCount to the resulting topic got dropped and that topic could suddenly disappear while still being used by the system. Solution: A change in the refCounting algorithm has now solved this issue. |
| OSPL-774 | New rmipp option to export generated code Solution: A new command line option has been added to the RMI pre-processor to be able to create a Windows DLL from generated code. This option is: -P dll_macro_name[,] Only applicable to C and C++. Sets export macro that will be prefixed to all functions in the generated code. This allows creating DLL's from generated code. Optionally a header file can be given that will be included in each generated file. |
| OSPL-1076/ 10787 | Compression in networking is not configurable other than on/off. Data compression typically involves a trade-off between CPU usage and the amount of compression achievable. The utility of the compression feature would be increased by allowing more flexibility in terms of this trade-off. Solution: The compression "level" of the existing zlib compressor may now be configured. Other compression algorithms may also be used. See the Deployment Guide for details. |
| OSPL-631/ 10459 | Using read or take with max_samples limit set can cause some key-values to be never read. The read and take operations return instances starting with lower key-values. If not all available data is read at once (e.g., when having set the max_samples limit) and the lower key-values keep receiving updates, a subsequently performed read operation will return the updated instances, which may prevent the higher key-values to be read. Solution: The read and take operations are changed to provide data circularly from a cursor. This means that these operations will 'resume' a read as if read_next_instance was succesively called. This way all instances can be read even when lower key-values get updated between two read-operations with a max_samples limit. |
| OSPL-1023 | Service failure actions can be taken multiple times When multiple services are known to the service framework, a failure action can be taken multiple times. Solution: The defect in the service failure action algorithm is now fixed and the action will only be done once. |
| OSPL-1051 | OpenSplice RMI Services Activation/De-activation in one call Services activation was done in a per-service basis. A given service becomes active (waits for incoming requests) by calling 'DDS_Service::run(service_name, ...)' which could be either blocking or non-blocking according based on the provided arguments. To activate multiple services, the "run" operation must be called as many times as there are services. Solution: Two new operations has been added to the "CRuntime" class to activate and de-activate all the registered services in one call: - CRuntime::run() - CRuntime::shutdown(bool wait_for_completion = true) The "run" operation is a blocking operation that blocks the calling thread until the shutdown is called. DDS_Service::run operation is kept but it becomes non blocking. It is recommended to use the CRuntime object for services activation and de-activation. |
| OSPL-1166/ 10823 | Terminating the "ospl -f start" operation may not kill all services The algorithm in ospl that performs the shutdown of the splice daemon and its child services in the case of blocking mode did not correctly detect whether the splice daemon had been terminated. This meant that it was possible that the splice daemon and its services may not necessarily have been terminated when "ospl -f start" returns. Solution: The shutdown algorithm in ospl has been improved to correctly detect the termination status of the splice daemon in both normal and blocking modes. |
| OSPL-1172/ 10827 | Performance difference between the datareader listener and subscriber listener In certain scenarios the subscriber listener handling is faster than the datareader listener handling. Solution: The handling algorithm of the datareader listener is improved to match the subscriber handling. |
Showing 1 to 10 of 22 entries
OpenSplice v6.2.2p2
Fixed bugs and changes not affecting the API in OpenSplice 6.2.2p2
| Report ID. | Description |
|---|---|
| OSPL-626 | Allow configuration of the UDP port number ranges that networking may use for the reliable channels for receiving ACK and resend messages Each reliable network channel requires an extra UDP port which other nodes used to send their ACKs and resend messages to. When several single process instances are used each single process requires for each reliable channel an unique UDP port number for this purpose. This enables control over the used UDP port numbers which may be needed when firewall are used. Solution: A configuration element "AllowedPorts" is added to either the networking channels or channel configuration which specifies the range (list) of UDP port numbers available. When specified an available port from the configured port range is used. When not specified the configurated channel port+1 is used when it is avaliable, otherwise a dynamic allocated UDP port is used. (Note: Deployment manual will be updated at 6.2.2 release. Use the configurator tool for further information. |
| OSPL-1326 | Idlpp crashes when two types in different modules have the same name and one of them has a keylist When an idl is used with 2 or more types in different modules and they have the same name and one or more have a keylist idlpp will crash. Solution: The fault in idlpp has been fixed and it is now save to use multiple types with the same name and a keylist in idl. |
| OSPL-1474/ 11036 | Windows Event Log plug-in failure to initialise The Windows Event Log plug-in could fail with an access violation. This could prevent the OpenSplice daemon starting as a Windows service as this plug-in is configured to be used by default in this circumstance. Solution: The Event Log now initialises correctly. |
| OSPL-1488 | DDSI2 fails to handle keyed topics with 64 members (and some variations) DDSI2 potentially performs some key re-ordering to remove the dependencies between the ordering of keys in the original IDL topic definition, the order of in which the members of the topic are serialised and the order in which the key fields are serialised. An mistake was found in the arithmetic that caused it to refuse topics with more than 64 members, or one with a key inside a nested struct with 32 fields inside one with 33 fields, &c. In such a case, no DDSI DataReaders and DataWriters would be created and no communication would take place for that topic, and the error log showed a generic error message: "handlePublications: new_writer: error -1" or "handleSubscriptions: new_reader: error -1". Solution: It now performs as intended and handles large structs correctly. |
| OSPL-1521/ 11075 | Datareader deletion could cause memory leaks Under certain conditions datareaders would not clean up their resources when becomming deleted. These leaks could occur when readers refuse to connect to writers because of a partition mismatch. Solution: The defect in the cleanup algorithm of datareaders is now fixed and will not leak anymore. |
| OSPL-1522/ 11074 | A reader subscribing to transient data using the "*" (wildcard) partition when samples are written to multiple partitions may lead to duplicate samples at the reader When a reader subscribes to a newly created topic/partition combination, because a writer on that partition has just been created, it should also request the historical data associated with combination. The issue was that it was actually being delivered the historical data for all partitions, including those for which samples may have already been delivered and read/taken. Solution: The behaviour has been changed so that historical samples are only delivered for the specific topic/partition that the reader has just subscribed to. |
Showing 1 to 6 of 6 entries
OpenSplice v6.2.2p1
| Report ID. | Description |
|---|---|
| OSPL-1326 | idlpp crash when two types in different modules have the same name and one of them has a keylist When an idl is used with 2 or more types in different modules and they have the same name and one or more have a keylist idlpp will crash. For example; module A { struct Z { long m; }; }; struct Z { long m; }; #pragma keylist Z Solution: The fault in idlpp has been fixed. |
| OSPL-1422 | Lookup_instance leaks memory The DataReader_lookup_instance call leaked one string for topics with string-keys, when a non-existing instance was looked up in a non-empty set. Solution: The leak is fixed. |
| OSPL-1424 | DDSI2 can stop accepting data when receiving fragments of old samples TDDSI2 defragmentation buffers have limited capacity and when full decide what to accept and what to drop on a policy that favours lower sequence numbers of higher ones in case of reliable communication. This policy causes the buffers to fill up slowly when every now and then a subset of the fragments of a sample arrive, but not all of them. This can only happen for "old" samples, as they have will been delivered to the data readers and no retransmits will be requested. Under normal circumstances it is very rare to receive some retransmitted fragments after receiving the full sample, but on networks with long delays, reordering and packet loss, such as a WAN, this problem is quite likely to surface. Solution: The current solution actively drops already accepted data from the defragmentation buffers, preventing uncontrolled build-up of incomplete samples. |
| OSPL-1425 | DDSI2 can request a retransmit of a full sample in addition to a retransmit of some of its fragments TDDSI2 considers the full state of a proxy writer and its data readers when generating a retransmit requests in response to a writer heartbeat, with the aim of generating the least costly retransmit request for the missing data. However, it can generate a retransmit request of some fragments of a sample while simultaneously requesting a retransmit of the full sample. Solution: The retransmit request for the full sample is now suppressed in cases where a retransmit of some fragments is requested. |
| OSPL-1426/ 10961 | DDSI2 can crash on topic creation On platforms where malloc(0) returns a null pointer, DDSI2 could crash on topic creation. Solution: DDSI2 now explicitly allows for this. |
Showing 1 to 5 of 5 entries
OpenSplice v6.2.1
Fixed bugs and changes not affecting the API in OpenSplice 6.2.0
| Report ID. | Description |
|---|---|
| OSPL-511 | Default OSPL xml configuration files not available in RTS The xml configuration files suppolied by default with the HDE were not in the RTS installer. Solution: Configuration files standardised across HDE and RTS installers. |
| OSPL-532 | DDSI2 keyhash generation is wrong for some cases DDSI2 always generates the keyhashes included in the DDSI standard (they are spec'd as optional). For topics of which the (big-endian) CDR representation of the key is or may be longer than 16 bytes the keyhash is computed as the MD5 hash of the serialized key.DDSI2 produces an incorrect hash on little-endian platforms for keys containing bounded strings where the total serialized length of the key is >= 17 and <=32 bytes. In practice this affects interoperability when multiple nodes publish the same instance:- between little- and big-endian machines running DDSI2- between little-endian DDSI2 and any other DDSI implementation. Solution: Corrected the keyhash generation. |
| OSPL-511 | OpenSplice Threads should be named To assist users (especially in the single process architecture) to name the threads used by OSPL. Solution: Major OSPL threads have been named |
| OSPL-558 | Narrow operation in examples leaking The use of the c++ _narrow operation on the created readers and writer entities in some of the OpenSplice examples led to memory leaks. Solution: These leaks have been resolved by better use of the _var helper type when calling the _narrow operation. |
| OSPL-593 | OpenSplice domain service installation as a native windows service At OpenSplice v6.1 running the OpenSplice domain services under the Windows Service Control Manager required the Windows Common Language Runtime. It also required the nomination on installation of a single global log directory that would hold all OpenSplice service and application process logs. When selecting to install the domain as a Windows service an incompatible 'single process mode' OpenSplice XML configuration file was installed by default. Solution: Installing and running OpenSplice services as a Windows Service now uses only unmanaged APIs so the .NET CLR is no longer required. A global log directory is no-longer required or prompted for during product installation. The installer will specify a 'shared memory' service configuration and will include a domain configuration entry to direct the log output from service processes to the Windows Event Log,for instance: ... See the Deployment Guide for more information regarding log plug-in configuration. Note that by default OpenSplice log events from application processes will still now be written to ospl-error/info.log files in the local directory, just as when not running OpenSplice as a Windows Service, but that this can be changed as per the comment in the snippet above. Note also that this entry can still be added to your OpenSplice domain configuration when OpenSplice is not installed as a Windows Service to direct service (or service and application) log output to the Event Log. |
| OSPL-659 | The C++ using the standalone C DCPS API 'PingPong' example has been removed The C++ using the standalone C DCPS API 'PingPong' example duplicated the code already available in the standalone C DCPS API 'PingPong' example unnecessarily given that the use of a C API from C++ is trivial. Solution: The example has been removed. Users wishing to use the standalone C DCPS API from C++ should refer to the the standalone C examples. These can be compiled with a C++ compiler. |
| OSPL-711 / OSPL-788 | Scheduling parameters for the top level service threads does not work when using single process deployment When applying scheduling(OpenSplice/Domain/Service/Scheduling) properties when using single process deployment the scheduling properties are not applied on the service. Solution: The defect is now fixed and the service thread will get the configured scheduling settings. |
| OSPL-775 | Exceptions 'throw' statements in rmi C++ generated code For consistency and best practice, the C++ exceptions specification has been ignored and instead the IDL to C++ mapping rules followed. Solution: All 'throw' specifications were removed from the RMI C++ generated code. |
| OSPL-778 | DDSI2 does not always deliver data for wildcard-based subscriptions To deliver data from remote writers to subscriptions using partition wildcards, DDSI2 sometimes needs to locally register the actual partition used. However, the optimisation used to avoid doing so unnecessarily did not correctly handle case in which a wildcard reader was matched to writers in different partitions. Solution: Optimisation corrected. |
| OSPL-781 / 10369 | The reliable channel does not operate correctly when using IPv6 on the Windows platform For Windows a bind is performed on the sending socket using the same portnumber as used by the receiving socket. This may cause that ACK messages are not received and that the reliable communication fails. Solution: The bind is not necessary at the sending socket and is removed. |
Showing 1 to 10 of 45 entries
Fixed bugs and changes affecting the API in OpenSplice 6.2.0
| Report ID. | Description |
|---|---|
| OSPL-347/ 8919 | Changes in Corba Co-habitation Java PSM Solution: In previous releases only a subset of the OpenSplice API was generated using a Corba ORB. Starting from this release, the entire Corba-Java API is generated by the IDL compiler that comes with the ORB. This enables customers to use internal types like ReturnCode_t and InstanceHandle_t in a Corba environment, i.e. Helper and Holder classes are now available for those types as well. Because all classes are now properly implementing Corba interfaces and inheriting from Corba base classes, derived classes are required to provide an implementation for all abstract operations mentioned in the generated interface. In case of Listeners, OpenSplice supplies the ListenerBase class as a convenience. When Listeners extend from this base class they are no longer required to implement these operations themselves. See detailed notes in 6.2 features section above |
| OSPL-1160 | DDS_Service::register_interface C++ operation signature change The DDS_Service::register_interface C++ operation accepts a raw pointer to the service implementation as parameter, whereas its implementation assigns it to a smart pointer. This situation can lead to a double free problem. Solution: The register_interface current signature is deprecated : template bool register_interface(T2 * svc_impl, const std::string & svc_name, int svc_instance_id) and adding a new one : template bool register_interface(shared_ptr svc_impl, const std::string & svc_name, int svc_instance_id) that accepts a smart pointer to the service implementation as paramter in stead of a raw one. |
Showing 1 to 2 of 2 entries