RTI Connext DDS Micro
Version 2.4.11
|
This release includes three new major features:
Setting the flag -DRTIME_UDP_EXCLUDE_BUILTIN=1 excludes the UDP transport from being built. This setting can be useful if communication is done using only shared memory, INTRA, or a custom UDP transport.
[RTI Issue ID MICRO-1805]
When the DDS_DataReaderListener's on_sample_lost event is triggered, the returned DDS_SampleLostStatus.sample_info now contains the publication_handle of the DataWriter that originally wrote the lost sample(s).
[RTI Issue ID MICRO-1800]
RTI Connext DDS Micro DataWriters now offer the DDS_TOPIC_PRESENTATION_QOS presentation (when coherent_access = FALSE). This presentation is compatible with any reader using DDS_TOPIC_PRESENTATION_QOS and DDS_INSTANCE_PRESENTATION_QOS, when ordered_access = TRUE and ordered_access = FALSE.
Micro readers will remain unchanged and will only support DDS_INSTANCE_PRESENTATION_QOS when ordered_access = FALSE.
[RTI Issue ID MICRO-1747]
A warning in logs has been added to notify you when a configured UDP transport does not have any interface. This condition normally indicates a wrong UDP configuration, which might result in discovery and/or communication failure.
[RTI Issue ID MICRO-1630]
The function OSAPI_Thread_self() when called by a VxWorks Real-Time Process (RTP) always returned the (process) ID of the RTP, even for tasks spawned by the RTP. This issue has been fixed.
[RTI Issue ID MICRO-1814]
A C++ DataReader was incorrectly not allowed to be created with a NULL DataReaderListener and a non-empty status mask (i.e., not DDS_STATUS_MASK_NONE).
[RTI Issue ID MICRO-1807]
When RTI Connext DDS Micro discovered a RTI Connext DDS Pro application with Shared Memory transport enabled, RTI Connext DDS Micro failed to correctly use the UDPv4 locators instead.
This issue has been fixed.
[RTI Issue ID MICRO-1798]
In RTI RTI Connext DDS Micro 2.4.10.x and earlier, calling FooSeq_set_maximum() repeatedly with the same maximum size on an IDL sequence type containing non-primitive types (such as enums or other structures) caused a segmentation fault.
This issue has been fixed.
[RTI Issue ID MICRO-1786]
RTI Connext DDS Micro buildable sources can not be compiled with CMake versions 2.8.10.1 or 2.8.10.2.
This issue has been fixed.
[RTI Issue ID MICRO-1748]
The OS error code (errno) was not correctly logged if sendto() returned an error.
This issue has been fixed.
[RTI Issue ID MICRO-1712]
Wrong example code is generated in case rtiddsgen is executed with option -create examplefiles and option -create typefiles is NOT used.
This issue has been fixed.
[RTI Issue ID MICRO-1696]
Examples generated using Codegen use always the last structure in the idl file, even if it is not top-level.
This issue has been fixed.
[RTI Issue ID MICRO-1694]
Unregistered or disposed samples were not processed when preceded by a GAP sub-message within the same RTPS message.
This issue has been fixed.
[RTI Issue ID MICRO-1692]
A reliable DataReader configured with only multicast (no unicast) locator(s) may have failed to discover or communicate with a reliable DataWriter. Both built-in discovery endpoints and user-data endpoints were affected.
This issue has been fixed.
[RTI Issue ID MICRO-1687]
Users of RTI Connext DDS Micro's C++ API can now access instance handles of any DDS entity using method DDSEntity::get_instance_handle.
[RTI Issue ID MICRO-1681]
When configuring the initial peers of a DomainParticipant (i.e. DDS_DomainParticipantQos.discovery.initial_peers), tne syntax for specifying a range of participant indices for a peer locator has changed: a hyphen is now the separator, replacing a comma. In general, a peer "[x-y]@<address>" means that participant discovery messages will be sent to the address for participant indices x through y.
[RTI Issue ID MICRO-1680]
The lookup_instance() was not thread safe in RTI Connext DDS Micro 2.4.10.x and earlier. If an application was calling lookup_instance() from both a listener and a WaitSet/polling thread at the same time, the instance handle could be corrupted.
This issue has been fixed.
[RTI Issue ID MICRO-1679]
Codegen generates project files CMakeLists.txt and README.txt are generated even when project files are not generated.
This issue has been fixed.
[RTI Issue ID MICRO-1673]
Given an application that creates DomainParticipants in different DDS domains, a DomainParticipant created with the same Participant GUID (i.e., the GUID Prefix portion of the GUID) as created for a DomainParticipant in a different domain will fail to discover or communicate with other endpoints within its own domain. A workaround would be for the application to assign unique GUIDs for all DomainParticipants across all domains. This issue has been fixed.
This issue has been fixed.
[RTI Issue ID MICRO-1671]
An incorrectly defined compiler macro causes a compilation error when lwIP stack is used and LWIP_DNS is defined.
This issue has been fixed.
[RTI Issue ID MICRO-1664]
Code generated with the following command failed if a struct with the same name was defined in two namespaces, and the first namespace did not have any key:
rtiddsgen -micro -example HelloWorld.idl -replace -language C++ -namespace
This issue has been fixed.
[RTI Issue ID MICRO-1663]
DDS_WaitSet_wait does not work if OSAPI_Semaphore_take() returns an error; RETCODE_PRECONDITION_NOT_MET is always returned.
This issue has been fixed.
[RTI Issue ID MICRO-1658]
The log buffer may have overflowed on 64-bit architectures and caused an application crash.
This issue has been fixed.
[RTI Issue ID MICRO-1657]
Windows implementation of function realloc did not allow a NULL input pointer, this is wrong and posix implementation and Windows API allow it. This has the effect that function DDS_String_replace() fails when the input string is a NULL pointer.
This issue has been fixed.
[RTI Issue ID MICRO-1655]
Due to an issue in the resource calculation for the DataReader, new samples for an instance may not have been received if the instance went back to ALIVE when using any of the read() APIs.
This issue has been fixed.
[RTI Issue ID MICRO-1651]
An issue in the matching between a reader and writer caused a reader to be matched with the same writer twice if auto enable was set to FALSE.
This issue has been fixed.
[RTI Issue ID MICRO-1650]
When using previous versions of RTI Connext DDS Micro, C++ applications might have experienced resource leakage upon finalization of middleware resources using the method DDSDomainParticipantFactory::finalize_instance. The leaks were caused by unfreed memory blocks still owned by the class RTRegistry, and they have now been resolved. No additional action is required of users.
This issue has been fixed.
[RTI Issue ID MICRO-1637]
Windows Debug DLLs are built without debug information what prevents debugging. This is happening when building with CMake or the rtime-make script.
This issue has been fixed.
[RTI Issue ID MICRO-1634]
When compiling using CMake or the script rtime-make, RTI Connext DDS Micro libraries have a build lD (buildid), which consist of the current time and date. A hardcoded constant ID is used as the build ID when compilation is not done using CMake or the script rtime-make.
This issue has been fixed.
[RTI Issue ID MICRO-1632]
Example makefiles used always option -m32. This has been changed to use -m32 or -m64 depending on the platform configuration.
Examples can be compiled now for 32 and 64 bits platforms.
This issue has been fixed.
[RTI Issue ID MICRO-1628]
Compilation error fixed in generated source code when option -namespace is used and IDL file has modules and compilation uses shared libraries.
This issue has been fixed.
[RTI Issue ID MICRO-1620]
The maximum number of components that can be registered is limited to 58.
Limitations in CMake prior to 3.6 required forcing the compiler to a specific path. However, this resulted in warnings from CMake 3.6 and higher that this feature has been deprecated and instead the CMAKE_TRY_COMPILE_TARGET_TYPE should be used to prevent linking.
Unless there are specific needs,there are no plans to support CMake prior to 3.6 when building for VxWorks.
When using static endpoint discovery (DPSE), RTI Connext Micro requires that the object_id for statically asserted remote endpoints must be unique across all remote endpoints, as opposed to just between remote endpoints within the same participant. Note, this restriction was incorrectly documented as removed in version 2.4.1.
When compiling for VxWorks 6.9 with the -Wconversion flag there are compiler warnings of the type:
warning: conversion to 'DDS_Boolean' from 'int' may alter its value
These compiler warnings seem to be an issue with GCC for VxWorks and can be ignored. The problem is that returning a value from a expression seems to always be treated as an unbounded int as opposed to an int with a value of 0 or 1 as the C standard dictates.
osapi_cc_stdc.h detects the CPU endianness by checking GCC predefined macros, such as BYTE_ORDER. However, some versions of GCC does not set these macros, for example GCC for VxWorks. If osapi_cc_stdc.h does not find any of the flags, it incorrectly sets the CPU to little endian.
In this case it is important that one of the following preprocessor macros are defined:
NOTE: The VxWorks cmake toolchain file from RTI set these based on CPU type in the target name (–name option).
In 2.4.10 and earlier the stream passed to on_before_sample_deserialize callback started at the encapsulation header followed by user data. However, with the added support for batched samples this is no longer possible. Instead the stream now starts at the user-data payload. Note that the only supported encapsulation format for user-data is CDR. This may change in future versions.
The examples have been updated to reflect the change. Please refer to the examples for details.
This release includes batching reception. Please refer to the new user manual for Batching for details.
A new C++ example using Waitsets (HelloWorld_dpde_waitset) is included.
To reclaim resources in version 2.4.10 and earlier the DataReader cache tries to remove the oldest sample only. If that is on loan it cannot be removed and in case a new sample is received it cannot be added to the DataReader cache.
This issue has been fixed.
[RTI Issue ID MICRO-1754]
When Network Address Translation (NAT) is configured in the transport UDP properties, a duplicated locator might be sent in discovery packets.
This issue has been fixed.
[RTI Issue ID MICRO-1756]
If the creation of a DataReader fails before all fields in the DataReader structure are initialized, a NULL pointer access may have occur while finalizing the already created objects.
This issue has been fixed.
[RTI Issue ID MICRO-1755]
RTI Connext DDS Micro buildable sources could not be compiled with CMake 2.8.10.1 or 2.8.10.2.
This issue has been fixed.
[RTI Issue ID MICRO-1748]
When using UDP transformations the locator kind was always set as 0, intead of the configured value in UDP_InterfaceFactoryProperty::transform_locator_kind
This issue has been fixed.
[RTI Issue ID MICRO-1685]
Before this release shipped examples makefiles could only compile 32 bits architectures. Makefiles have been modified to support also 64 bits architectures.
This issue has been fixed.
[RTI Issue ID MICRO-1628]
The Windows implementation of function OSAPI_Heap_realloc() had a precondition to check for a NULL pointer as input parameter. This is wrong as in this case the function shall allocate a new buffer (equivalent to malloc()).
This issue has been fixed.
[RTI Issue ID MICRO-1655]
Shipped C++ examples now use DDSDomainParticipant::delete_contained_entities() to delete all DSS entities in a DDS Participant. This is easier than using DDSDomainParticipant::delete_topic(), DDSDomainParticipant::unregister_type(), etc.
This issue has been fixed.
[RTI Issue ID MICRO-1656]
Shipped examples were not releasing correctly some of the allocated structures when application finalized.
This issue has been fixed.
[RTI Issue ID MICRO-1676]
C++ shipped examples might release an object twice in case of error.
This issue has been fixed.
[RTI Issue ID MICRO-1677]
The maximum number of components that can be registered is limited to 58.
Limitations in CMake prior to 3.6 required forcing the compiler to a specific path. However, this resulted in warnings from CMake 3.6 and higher that this feature has been deprecated and instead the CMAKE_TRY_COMPILE_TARGET_TYPE should be used to prevent linking.
Unless there are specific needs,there are no plans to support CMake prior to 3.6 when building for VxWorks.
When using static endpoint discovery (DPSE), RTI Connext Micro requires that the object_id for statically asserted remote endpoints must be unique across all remote endpoints, as opposed to just between remote endpoints within the same participant. Note, this restriction was incorrectly documented as removed in version 2.4.1.
When compiling for VxWorks 6.9 with the -Wconversion flag there are compiler warnings of the type:
warning: conversion to 'DDS_Boolean' from 'int' may alter its value
These compiler warnings seem to be an issue with GCC for VxWorks and can be ignored. The problem is that returning a value from a expression seems to always be treated as an unbounded int as opposed to an int with a value of 0 or 1 as the C standard dictates.
osapi_cc_stdc.h detects the CPU endianness by checking GCC predefined macros, such as BYTE_ORDER. However, some versions of GCC does not set these macros, for example GCC for VxWorks. If osapi_cc_stdc.h does not find any of the flags, it incorrectly sets the CPU to little endian.
In this case it is important that one of the following preprocessor macros are defined:
NOTE: The VxWorks cmake toolchain file from RTI set these based on CPU type in the target name (–name option).
This release includes UDP Transformations which enables regular UDP sockets to be used with custom payload transformations. Please refer to UDP Transformations for details. The UDP Transformation feature is enabled by default in this release. However, future releases may disable the feature by default. Thus, it is advised to always compile with the UDP Transformation feature enabled (-DRTIME_UDP_ENABLE_TRANSFORMS=1 to cmake).
NOTE: In the the EAR for 2.4.10.1 the default behavior was to allow both plain UDP and transformed UDP traffic when transformations was compiled in. This has changed. The default is to disable regular UDP. In order to support it the transform_udp_mode must be set to UDP_TRANSFORM_UDP_MODE_ENABLED. Since this may change in future release it is advised to always set the correct mode of operation.
A race condition existed when a custom log handler was installed and the log buffer was full. A temporary message was created to hold the minimum log data and when the custom log handler was called it was possible that a new log entry was added while the custom log handler parsed the temporary message.
This has been fixed in this version.
[RTI Issue ID MICRO-1641]
The maximum number of components that can be registered is limited to 58.
Limitations in CMake prior to 3.6 required forcing the compiler to a specific path. However, this resulted in warnings from CMake 3.6 and higher that this feature has been deprecated and instead the CMAKE_TRY_COMPILE_TARGET_TYPE should be used to prevent linking.
Unless there are specific needs,there are no plans to support CMake prior to 3.6 when building for VxWorks.
When using static endpoint discovery (DPSE), RTI Connext Micro requires that the object_id for statically asserted remote endpoints must be unique across all remote endpoints, as opposed to just between remote endpoints within the same participant. Note, this restriction was incorrectly documented as removed in version 2.4.1.
When compiling for VxWorks 6.9 with the -Wconversion flag there are compiler warnings of the type:
warning: conversion to 'DDS_Boolean' from 'int' may alter its value
These compiler warnings seem to be an issue with GCC for VxWorks and can be ignored. The problem is that returning a value from a expression seems to always be treated as an unbounded int as opposed to an int with a value of 0 or 1 as the C standard dictates.
osapi_cc_stdc.h detects the CPU endianness by checking GCC predefined macros, such as BYTE_ORDER. However, some versions of GCC does not set these macros, for example GCC for VxWorks. If osapi_cc_stdc.h does not find any of the flags, it incorrectly sets the CPU to little endian.
In this case it is important that one of the following preprocessor macros are defined:
NOTE: The VxWorks cmake toolchain file from RTI set these based on CPU type in the target name (–name option).
It is now possible to generate an example application for RTI Connext Micro using rtiddsgen. To generate an example:
rtiddsgen -language C | C++ -micro -example <IDL File>
A CMakeLists.txt file is generated that can be used with rtime-make:
rtime-make [options] --srcdir <path to CMakeLists.txt> Please refer to the generated README.txt file for details.
The DataReader and DataWriter Qos policy now includes the DDS_DestinationOrderQosPolicy.
Please refer to the DDS reference manual for details.
[RTI Issue ID MICRO-1597]
The i86Win32VS2010 libraries shipped with RTI Connext DDS Micro did not include PDB files. For this reason, when compiling an application a warning similar to the following may have been shown:
rti_mezd.lib(BuiltinTopicData.obj) : warning LNK4099: PDB 'dds_czd.pdb' was not found with 'rti_mezd.lib(BuiltinTopicData.obj)' or at '<path>\dds_czd.pdb'; linking object as if no debug info
The warning was harmless and only indicates that debug information was missing for the linked libraries.
[RTI Issue ID MICRO-1556]
All shipped RTI Connext DDS Micro libraries for Windows platforms (static release/debug, dynamic release/debug) now link with the dynamic Windows C Run-Time (CRT). Previously, the static RTI Connext DDS Micro libraries statically linked the CRT.
An existing Windows project that is linking with the RTI Connext DDS Micro static libraries must update the RunTime Library settings.
In Visual Studio, select C/C++, Code Generation, Runtime Library, select:
For command-line compilation, use:
In addition, it may be necessary to ignore the static run-time libraries in their static configurations. In Visual Studio, select Linker, Input in the project properties and add libcmtd;libcmt to the 'Ignore Specific Default Libraries' entry.
For command-line linking, add /NODEFAULTLIB:"libcmtd" /NODEFAULTLIB:"libcmt" to the linker options.
[RTI Issue ID MICRO-1572]
When an application reaches the local_writer_allocation resource limit, where subsequent calls to DDS_Publisher_create_datawriter() fail to create a new DataWriter, calling DDS_Publisher_delete_datawriter() should reclaim resources of the deleted DataWriter and allow the creation of a new DataWriter. However, in the previous release, in certain cases there was a problem with reclaiming DataWriter resources that prevented the creation of a new DataWriter.
Deleting a DataWriter or DataReader involves acknowledgements from matched applications. Thus, calling DDS_Publisher_delete_datawriter() is not an instantaneous operation so resources may not be available immediately. When this case occurs, calling DDS_Publisher_create_datawriter() after a short duration may be successful. The maximum time for a resource to be released is the maximum time a response is expected from a matched application based on the DPDE discovery plugin configuration for the built-in discovery endpoints.
[RTI Issue ID MICRO-1579]
Applications using read()/take() in on_data_available may not have received NOT_ALIVE_NO_WRITERS for instances that changed state to NOT_ALIVE_NO_WRITERS when a deleted data writer or data reader lost liveliness with a data writer caused the change. This has been fixed.
[RTI Issue ID MICRO-1580]
A reliable DataWriter can mark a matched DataReader as inactive if the DataReader fails to respond to heartbeats, as configured by max_heartbeat_retries. However, if a DataReader is marked as inactive and the Participant liveliness for the DataReader's Participant expires, a DataWriter afterwards may have failed to reclaim instances resources if unregister_instance() was called. This has been fixed.
[RTI Issue ID MICRO-1581]
A reliable DataWriter with max_samples_per_instance = 1 may have run out of instance resources if the same instance is unregistered multiple times before an acknowledgement is received from a matched DataReader. This has been fixed.
[RTI Issue ID MICRO-1583]
If an application developed with RTI Connext Core used set_qos() on an enabled endpoint or deleted and created new endpoints before RTI Connext DDS Micro had discovered the deleted endpoints, RTI Connext DDS Micro failed to discovery new endpoints. This has been fixed.
[RTI Issue ID MICRO-1588]
If there was insufficient space to store a complete log-message, the default display function would incorrectly try to print log-data beyond the log-buffer. This has been fixed.
[RTI Issue ID MICRO-1589]
Calling unregister_instance() on the same TRANSIENT_LOCAL instance may have caused a segmentation fault. The segmentation fault occured when a call to unregister_instance() is acknowledged and a later call on unregister_instance() for the same instance had not been acknowledged yet. For the segmentation fault to occur there must be more than 1 call to unregister_instance() within the history depth. This has been fixed.
[RTI Issue ID MICRO-1590]
The rtiddsgen included by this release will correctly generate C++ code for data types defined within IDL modules, when passed the "-namespace" argument. Consider the following IDL:
C++ code generated by previous releases of rtiddsgen for this IDL input would fail to build if the "-namespace" argument was used to map each IDL module to a C++ namespace.
Some of the automatically generated data types were incorrectly being exported with C linkage, effectively disabling the C++ namespaces. This would cause duplicate symbols to be detected if two types with the same name were defined in two different modules.
[RTI Issue ID MICRO-1600]
When a received RTPS message had its message and submessage headers processed, RTI Connext DDS Micro incorrectly did not validate for all cases that there was sufficient space in the message's receive buffer before accessing a field of a header. Consequently, reception of certain malformed messages could have resulted in memory access violations. The problem has been fixed by always validating for sufficient buffer. This has been fixed.
[RTI Issue ID MICRO-1614]
Some combinations of timeouts, clock resolution and resource-limits may have caused an incorrect timeout to be scheduled causing an infinite loop in the timer thread.
If multiple timers expires at the same time and the timeout is exactly:
(dp_qos.resource_limits.remote_participant_allocation + (3*dp_qos.resource_limits.local_writer_allocation) + (3*dp_qos.resource_limits.local_reader_allocation) + 1) / 2 * timer_resolution
the next timeout may be scheduled for immediate timeout, causing the timer thread to consume excessive CPU.
[RTI Issue ID MICRO-1617]
Limitations in CMake prior to 3.6 required forcing the compiler to a specific path. However, this resulted in warnings from CMake 3.6 and higher that this feature has been deprecated and instead the CMAKE_TRY_COMPILE_TARGET_TYPE should be used to prevent linking.
Unless there are specific needs,there are no plans to support CMake prior to 3.6 when building for VxWorks.
When using static endpoint discovery (DPSE), RTI Connext Micro requires that the object_id for statically asserted remote endpoints must be unique across all remote endpoints, as opposed to just between remote endpoints within the same participant. Note, this restriction was incorrectly documented as removed in version 2.4.1.
When compiling for VxWorks 6.9 with the -Wconversion flag there are compiler warnings of the type:
warning: conversion to 'DDS_Boolean' from 'int' may alter its value
These compiler warnings seem to be an issue with GCC for VxWorks and can be ignored. The problem is that returning a value from a expression seems to always be treated as an unbounded int as opposed to an int with a value of 0 or 1 as the C standard dictates.
osapi_cc_stdc.h detects the CPU endianness by checking GCC predefined macros, such as BYTE_ORDER. However, some versions of GCC does not set these macros, for example GCC for VxWorks. If osapi_cc_stdc.h does not find any of the flags, it incorrectly sets the CPU to little endian.
In this case it is important that one of the following preprocessor macros are defined:
NOTE: The VxWorks cmake toolchain file from RTI set these based on CPU type in the target name (–name option).
Some changes were made to how RTI Connext DDS Micro includes different ports. In versions before 2.4.9 new ports would typically update osapi_config.h and add a new directory with an implementation for the required OSAPI functions. As of 2.4.9 osapi_config.h was re-factored and OS and compiler specific functions were moved to two new files:
Please refer to Porting RTI Connext DDS Micro for details.
RTI Connext DDS Micro now includes better support for adding CMake tool-chain files and also includes a better infrastructure to manage multiple builds of RTI Connext DDS Micro. It is strongly encouraged to read Building the RTI Connext DDS Micro Source for details to get familiar with the new build environment.
RTI Connext DDS Micro ships with a more cmake tool-chain files for Linux, Darwin, Windows and VxWorks. Please refer to Building the RTI Connext DDS Micro Source for details.
[RTI Issue ID MICRO-706]
A new smaller host bundle that does not include Java Runtime Environments (JRE) is now available for download. A host bundle with JREs included is still available.
With Java being necessary for the rtiddsgen utility, rtiddsgen now picks Java based on the following order:
[RTI Issue ID MICRO-1520]
RTI Connext DDS Micro was written for 32 bit architectures and is for all practical purposes a 32 bit application. There is no advantage to compiling RTI Connext DDS Micro for a 64 bit architecture and the only reason to do so is if RTI Connext DDS Micro must execute in a 64 bit environment for other reasons, such as other applications being 64 bit or 64 bit libraries not being available.
RTI Connext DDS Micro is compiled and tested on various 64 bit architectures (iOS, MacOS, Windows, Linux, VxWorks). However, when doing so the following must be kept in mind:
RTI Connext DDS Micro supports various POSIX like operating systems. Due to small differences in the implementations not all POSIX like are equal and OS specific adaptations are necessary.
As of 2.4.9 RTI Connext DDS Micro's POSIX OSAPI implementation conforms to:
The RTI Connext DDS Micro UDP transport uses ioctl calls to enable certain socket features. The required flags are in non-standard header-files on some operating system. In addition, not all POSIX-like operating systems support all the features. RTI Connext DDS Micro checks which OS it is compiled for by testing the presence of preprocessor flags. As of 2.4.9 RTI Connext DDS Micro has been built and tested on the following operating systems that supports a POSIX API (osapi_os.h):
NOTE: An additional compile option to enable certain non-POSIX features can be enabled to unchecking the RTIME_OSAPI_ENABLE_STRICT_POSIX option in the cmake-gui or by defining the C preprocessor flag -DOSAPI_ENABLE_STRICT_POSIX=1
[RTI Issue ID MICRO-1548]
The operation DDS_DomainParticipant_find_topic() is now natively supported by the C++ API as DDSDomainParticipant::find_topic().
[RTI Issue ID MICRO-1551]
In previous releases, types must be unregistered manually from a DomainParticipant before the participant can be deleted. Now in this release, all registered types are automatically unregistered when calling DDS_DomainParticipant_delete_contained_entitites().
NOTE: It is legal to register the same type multiple times as long as it is registered with the same type-plugin. If manually unregistering a type, the type must be unregistered the same number of times as it was registered. DDS_DomainParticipant_delete_contained_entitites() ignores the number of times a type has been registered since all entities using a type are deleted first.
[RTI Issue ID MICRO-1569]
The RTI Connext DDS Micro documentation has been improved for the following topics:
[RTI Issue ID MICRO-711, MICRO-1521, MICRO-1538, MICRO-1555]
Previously, given a DomainParticipant "P1" whose endpoints are communicating with other endpoints belonging to other DomainParticipants, when P1 detected liveliness lost with one other DomainParticipant, communication incorrectly stopped with endpoints belonging to other DomainParticipants as well.
[RTI Issue ID MICRO-1543]
The function lookup_topicdescription() returned a DDSTopicDescription that caused DDSTopic::narrow() to segmentation fault when this DDSTopicDescription was passed to other functions.
DDSTopic::narrow() now correctly returns a DDSTopic when passed a DDSTopicDescription found with lookup_topicdescription().
[RTI Issue ID MICRO-1544]
delete_topic() incorrectly returned PRECONDITION_NOT_MET if there where multiple references to it (for example via find_topic()). This has been corrected and delete_topic() now returns DDS_RETCODE_OK if there are multiple references, but the reference count can be decremented.
[RTI Issue ID MICRO-1545]
When an instance is unregistered on the data writer that is best-effort with infinite deadline or using TRANSIENT_LOCAL durability, the data writer fails to free the resources being used. As a result, new instances cannot be written. This has been fixed and when an instance is unregistered all resources associated with the key is released.
[RTI Issue ID MICRO-1546]
Some memory profile tools reported an invalid read in Log.c. This was caused by an invalid pointer access when the log buffer was full and has been corrected.
[RTI Issue ID MICRO-1550]
Code generated by rtiddsgen to support user data types has been updated to properly support compilation with the flag RTI_CERT. All unsupported operations (e.g. FooTypeSupport_delete_data) are now excluded when RTI_CERT is specified.
[RTI Issue ID MICRO-1558]
The HelloWorld_cert called functions that were not supported by libraries built with RTI_CERT. This has been corrected.
[RTI Issue ID MICRO-1561]
Previously in RTI Connext DDS Micro 2.4.6, a function to validate IP hostnames as defined by RFC-952 was added and called before passing them to the OS. However, this function was too restrictive and excluded valid service names. Hostname validation is now only done directly by the OS.
[RTI Issue ID MICRO-1563]
This problem was only present when using dynamic discovery.
Consider two participants A and B. In the previous release, if A lost liveliness with B, but B did not lose liveliness with A, then A did not completely rediscover B when their connection was reestablished. The problem was that since B had not lost liveliness with A, when a connection was reestablished, B thought A was already up to date on endpoint discovery. Hence, A did not rediscover the endpoints in B. This release has fixed this issue.
[RTI Issue ID MICRO-1571]
When performing matching between A DataReader and DataWriter the entity kind was not checked. This means a keyed DataReader would match a non-keyed DataWriter and a non-keyed DataReader would match an keyed DataWriter.
This issue would can happen if two different IDLs files are used to create DataReaders and DataWriters of the same topic and type.
Note that RTI Connext DDS Micro does not support type validation. If two (or more) IDLs are used to describe the same keyed type there is no check that the key-fields are the same. Thus, even with this issue resolved there are still potential pitfalls with multiple IDLs for the same type.
[RTI Issue ID MICRO-1574]
When using static endpoint discovery (DPSE), RTI Connext Micro requires that the object_id for statically asserted remote endpoints must be unique across all remote endpoints, as opposed to just between remote endpoints within the same participant. Note, this restriction was incorrectly documented as removed in version 2.4.1.
[RTI Issue ID MICRO-211, MICRO-1553]
Between VS2010 and VS2015 some APIs used by the RTI Connext DDS Micro OSAPI and UDP transport on Windows have been deprecated. The applicable APIs are:
Note that although these warnings can be removed by defining _WINSOCK_DEPRECATED_NO_WARNINGS, RTI Connext DDS Micro does not do so to make it clear these APIs are being used.
[RTI Issue ID MICRO-1575]
When compiling for VxWorks 6.9 with the -Wconversion flag there are compiler warnings of the type:
warning: conversion to 'DDS_Boolean' from 'int' may alter its value
These compiler warnings seem to be an issue with GCC for VxWorks and can be ignored. The problem is that returning a value from a expression seems to always be treated as an unbounded int as opposed to an int with a value of 0 or 1 as the C standard dictates.
osapi_cc_stdc.h detects the CPU endianness by checking GCC predefined macros, such as BYTE_ORDER. However, some versions of GCC does not set these macros, for example GCC for VxWorks. If osapi_cc_stdc.h does not find any of the flags, it incorrectly sets the CPU to little endian.
In this case it is important that one of the following preprocessor macros are defined:
NOTE: The VxWorks cmake toolchain file from RTI set these based on CPU type in the target name (–name option).
2.4.8 is a maintenance release with no new features.
The assignment operator for the DDS Qos, Qos policy and Status structures were not consistently supported. This has been fixed in this release as follows:
In addition, all QoS structures support the == and != operators.
[RTI Issue ID MICRO-1541]
The DPSE C++ API had methods called assert. However, this conflicts with the C assert() macro. This has been fixed in this release by updating the DPSE C++ API to be inline with the C API. The new API is:
[RTI Issue ID MICRO-1539]