Vortex OpenSplice - documentation index

##### Vortex OpenSplice

- Introduction
- User Guides
- Changes
- Supported Platforms
- Known Issues
- DDSI Release Notes
- Rebuilding the APIs
- Upgrading OpenSplice
- Examples
- Third party licenses
- License

## OpenSplice Issues

Report ID. | Description
--- | ---
dds184 | Query parser doesn't support escape characters The internal OpenSplice DDS query parser does not support escape characters. This implicates that specific tokens cannot be used in query expressions (like for instance SQL keywords 'select', 'where', etc). Impact at API level: Topics with a SQL keyword as name cannot be created QueryCondition expressions cannot refer to datafields with SQL keyword as name ContentFilteredTopic expressions cannot refer to datafields with SQL keyword as name
4508 dds206 | typeSupport with invalid type name causes crash during register_type When a type support object is created with an type name which is not known in the meta database, the following register_type function crashes.
dds492 | idlpp cannot handle same struct in a struct or forward declarations to structs The following (faulty) idl code generates a 'floating point exception', instead idlpp should not allow such constructs.
                struct TestStruct;

                struct TestStruct{
                    long x;
                    TestStruct someEnum;
                    string val;
                };
The following idl also fails (the forward declaration to the TestStruct is not correctly processed):
                struct TestStruct;

                struct TestStruct1{
                    TestStruct y;
                };

                struct TestStruct{
                    long x;
                };
with the error: `***DDS parse error TestStruct undefined at line: 4`. The following idl construct is not allowed, however the IDL preprocessor does not give a clear error:
                struct TestStruct;

                struct TestStruct1{
                    TestStruct y;
                };

                struct TestStruct{
                    TestStruct1 x;
                };
4821 dds494 | SQL RelOp like not supported Using the SQL relational operator like is not supported.
dds1117 | Implicit unregister messages can corrupt copy-out functions On all language bindings there are methods that only use the key fields of a sample, as for example the register, unregister and dispose methods. However, currently the complete sample (including the non-key fields) need to adhere to the IDL to language mapping rules, as all fields are validated. This means that when a sample contains garbage data in its non-key fields, the sample could be rejected and the application might even crash in case of dangling pointers (segmentation fault). The work-around is that no values should be initalised to NULL values, no values should contain dangling pointers, all unions should explicitly be initialized to a valid value and any enumeration value should remain within its bounds.
dds1696 | Limitations for output directories for ospl_projgen on Integrity ospl_projgen will generate projects which will build incorrectly if it is supplied an output directory ( -o option ) in which the final part of the path matches the name of one of the address spaces being generated. e.g. ospl_projgen ... -t mmstat -o path/mmstat These projects appear to build correctly however the final image will be incorrect. Other names to avoid currently are inetserver, ivfs_server, ResourceStore, spliced, networking, durability, pong, ping1, ping2, ping3, ping4, ping5, ping6, shmdump, Chatter, Chatter_Quit, MessageBoard, UserLoad
dds1711 | Warnings when compiling with the Studio12 compiler There are still numerous warnings when using the Studio12 compiler. These can be ignored and will be tidied in future releases.
dds2142 | Default buffer size used by networking may cause an error to be logged on Solaris9. On Solaris9 there may be an error in the ospl-error.log when the networking service is started: "setsockopt returned errno 132 (No buffer space available)" this is down to the udp_max_buf being to small. To find out what the system has it set to do `/usr/sbin/ndd -get /dev/udp udp_max_buf` and to set it larger do : `/usr/sbin/ndd -set /dev/udp udp_max_buf <xxxxxxx size in bytes>`
dds3276 | Tester - Reconnection to shared memory OpenSplice domain on Windows fails On Windows, when trying to reconnect to a running domain of OpenSplice DDS that utilises shared memory the reconnection will fail. Workaround: Restart OpenSplice Tester.
dds2260 / OSPL-259 / OSPL-6304 | idlpp cannot handle recursive sequences The idlpp tool is not able to cope with recursive sequences:
    module example {
        typedef sequence NameList;

        struct DataType {
            sequence nameLists;
        };
    };
OSPL-973 | Partitions with wild-cards don't work properly in all cases The PartitionQosPolicy for Publisher and Subscriber entities can contain two types of values. An absolute value that specifies a partition or a partition expression i.e. a name containing wildcard symbols '?'' and/or '*'. A partition expression is locally used by the Entity to discover matching absolute partitions to build up connections. Entities react on the creation of new partitions and those that match the partition expression are connected. Unfortunately information about newly created remote partitions is not distributed at this time. This means no matching can be performed to determine if the remote partition must be instantiated locally. As a result Subscribers and Publishers that use wild-cards in partition expression won't connect to partitions that are not explicitly created in the local application (when running in single process mode) or local node (when running in federated mode). As a workaround, all partitions that need to match must be explicitly mentioned in the PartitionQosPolicy.
OSPL-2542 | 64 bit stack space issues with the JVM Newer versions of JDK (at least 1.6u43 and 1.6u45) run out of stack space on 64 bit platforms. Using a larger default StackSize would impact all non-Java applications too, and is therefore undesirable. Try increasing StackSize to 128000 bytes if you're experiencing problems with using listeners from Java on 64 bit platforms.
OSPL-2696 | Merge policy behaviour Merging of different data-sets after a re-connect only works when the disconnect takes less than the service_cleanup_delay value of the Topic(s). Otherwise it is not possible for the middleware to determine whether instances that are available on one side and not on the other have been disposed or created during the disconnect. If a re-connect takes place after a period larger than the configured service_cleanup_delay, data-sets on both sides may be different after the merge-policy has been applied. One should carefully consider the merge-policy configuration for all federations in the system as a whole as not all combinations make sense. Consider the example of a two-node system. The following configurations semantically make no sense: Configuring REPLACE as policy on both sides. Combining REPLACE as policy on one side and MERGE on the other side. Combining REPLACE as policy on one side and DELETE on the other side. Combining DELETE as policy on one side and MERGE on the other side. The wait_for_historical_data() call does not block while performing a merge due to the configured merge-policy. This means it is currently not possible to block an application until the merge has completed.
OSPL-4891 | RMI Java/C++ incompatibility RMI Java and RMI C++ will not communication with each other due to internal topic names mismatch.
OSPL-5885 | DDSI message verification Verification of incoming messages is quite strict, but enum values embedded in the data are not checked against the set of valid values.
OSPL-6080 | Crash duration termination by a signal There is a small chance that a process crashes when it is terminated by a signal. In this situation the termination sequence will first disable the API so that the application will no longer be able to access entities and then free all resources. The problem is that the termination sequence should wait until all ongoing operations, which started accessing entities before the API was disabled, have finished before freeing resources otherwise they may access freed memory and cause a crash. This problem can only occur when the termination sequence starts during entity create and enable operations.
OSPL-6152 | Tuner doesn't accept the name of the domain anymore (for connecting) Other than in 6.4, the current 6.5 version doesn't allow the name of the domain to be specified anymore as a means to connect to that domain, i.e. using "ospl_shmem_ddsi_statistics_rnr" as the URI rather than the (working) integer value (0) or the xml-config-file URI.
OSPL-6233 | DCPS API unregister_instance with timestamp before most recent register fails A call to unregister_instance (on an existing instance) with a timestamp prior to the most recent registration for that writer is handled incorrectly: the group instance correctly detects the unregister_instance operation should be ignored, but the writer nonetheless incorrectly removes the instance from its own adminstration.
OSPL-6901 | Behavior of built-in topic part of ISOCPP2 DCPS API not working with GCC <= 4.3 Builds that have been generated with GCC version <= 4.3, will not be able to use the built-in topic part of the ISOCPP2 DCPS API due to issues with dynamic casting in the combination of the API and the compiler.
OSPL-6974 | Group coherency during durability alignment When in a running system an end of a group coherent update takes place at the same time a late joining Node is aligning historical data there is a chance that a group coherent update is partially lost by the late joining node. The problem is caused by the sending node that not yet treats a group coherent update as an atomic change, in this situation the sending node will partially aligns data as a coherent update and partially aligns data as completed, the receiving node will not be able to detect completeness of the whole and eventually discard the part of the data that was send as a coherent update.
OSPL-7244 | Tuner does not support writing samples containing multi-dimensional collections Currently, the Tuner tool does not support editing multi-dimensional sequences (in IDL, sequence<sequence<some_type>>, or some_type[x][y]). When editing such data fields in the Tuner writer table, the fields will be uneditable. This also affects editing Google Protocol Buffer samples that contain a field defined as repeated bytes, as that is represented as a sequence of a sequence of octets in the data model.
OSPL-7299 | DDSI2(E) and RTNetworking ssl/crypto versions are incompatibile/not-available on some linux platforms DDSI2(E) and RTNetworking services may report "error while loading shared libraries: libssl.so.10: cannot open shared object file: No such file or directory" on some platforms even when ssl is installed properly due to a difference in ssl setups between linux distributions. A workaround for this is creating symbolic links in /lib for libssl.so.10 and libcrypto.so.10 that point to your libssl and libcrypto libraries on your system.
OSPL-7382 | Incorrect instance state after group coherence update and deletion of writer If a group scope coherent writer publishes a coherent set and then is deleted while a group scope coherent reader has locked its state by having called the begin_access operation it is expected that the coherent set will become available as soon as the end_access operation is called by the reader and that the state of the reader's instances has become NO_WRITERS (assuming that the writer was the only writer). In the current implementation it is possible that the update to the NO_WRITERS state is not detected and that the instance state of the reader's instances remain alive. libcrypto libraries on your system.
OSPL-7387 | Coherent updates that hit the DataReader's max_instances or max_samples_per_instance resource limits are always aborted and can leak memory. When a coherent update hits a Reader's max_instances or max_sample_per_instance limit it will be aborted. Aborting a transaction when running into these resource limits is only required when the Reader cannot solve this resource by taking action i.e. when releasing resources solely depends on arrival of data, however analysis of the actual situation and determining what to do is, in the current implementation, too costly so for now we always abort. Aborting can also leak some resources within the transaction administration because some dependencies may still be unknown at abortion, which is considered acceptable for the time being and for as long hitting resource limits only occurs occasionally. Advised is to avoid hitting these resource limits either by not setting them or to assure normal operation never reaches these limits
OSPL-7707 | Coherent updates not working properly i.c.w. QoS changes. When modifying the QoS-ses of existing publishers, writers, subscribers or readers that are involved in an ongoing coherent update, readers may not receive this coherent update in all cases. Users are advised to refrain from changing the QoS-ses of existing entities. If different QoS-ses are required, the involved entity should be deleted and re-created instead.
OSPL-8008 | C++ global const struct copy failure on g++ 4.1.1 When using DDS C++ pre-defined const structures (like DDS::DURATION_INFINITE, DDS::TIMESTAMP_CURRENT, etc) with g++ 4.1.1, assignments can fail. It will fail only when assigning it to a global const variable, which is then assigned to a variable within a function.
    DDS::Duration_t globalStruct = DDS::DURATION_INFINITE;
    const DDS::Duration_t globalStructC = DDS::DURATION_INFINITE;
    void main(void)
    {
        const DDS::Duration_t localStructC = DDS::DURATION_INFINITE;
        DDS::Duration_t copy_localStructC  = localStructC;
        DDS::Duration_t copy_globalStructC = globalStructC;
        DDS::Duration_t copy_globalStruct  = globalStruct;
    }
The content of `copy_globalStructC` does not equal `DDS::DURATION_INFINITE` but is zero. The other structures don't have this problem. Easiest workaround is by initializing `globalStructC` differently:
    const DDS::Duration_t globalStructC = {DURATION_INFINITE_SEC, DURATION_INFINITE_NSEC};
OSPL-8507 | Transactions with explicit registration messages never become complete. When explicitly registering one or more instances during a coherent update by calling the register_instance() or register_instance_w_timestamp() operations on one or more datawriters, the coherent update will never become complete for datareaders that do not participate in the same federation. The workaround for this is to never explicitly register instances in a coherent update from within application code, but instead rely on implicit registration of instances by the middleware.
OSPL-8665 | DDS wait_for_historical_data_w_condition operations cannot deal with partial coherent sets The wait_for_historical_data_w_condition() operation cannot deal with alignment of partial coherent sets, which basically means that the operation cannot be used in environments where coherent updates are used. Solving this issue requires an alternative implementation of the condition because the current implementation creates a query by splitting the condition into a list of instance (key) queries and sample (non-key) queries but transactions have no knowledge of instances and samples, for these the query can only rely on the messages so a different kind of implementation is required. A workaround is to stick to wait_for_historical_data() and have the application filter out the desired data.
OSPL-8673 | Possible release claim and memory leak when receiving transaction twice When a federation starts and receives part of a transaction via the normal path and durability aligns the complete transaction afterwards, the part of the transaction that is received twice may leak memory (as long as the reader/group lives) and also 'leaks' the resource claims the samples have done, potentially causing delivery of new samples to be denied because of ResourceLimits that have been set (only if they are used). If a second transaction is completely received after first transaction then this is not a problem.
OSPL-8768 | RMI Java multithread service priority not working on PERC When using multi-thread server policy for RMI Java on PERC, then the requests are not handled in the expected order. For instance, when you have different priorities, then the higher priority requests should be handled before the lower priority ones. This doesn't happen. The problem is that, for request handling order, RMI Java uses the native java.util.concurrent.PriorityBlockingQueue. This does not work properly on PERC.
OSPL-9113 | Non-coherent reader may not be aligned with data from an unfinished transaction Under certain circumstances a non-coherent reader may not receive historical data from an unfinished transaction. When a non-coherent reader is created and there is a unfinished transaction present for which no writer exists anymore (thus the transaction will never become complete) then this non-coherent reader may not receive the historical data from this transaction.
TSTTOOL-266 | Tester cannot edit recursive message fields in protocol buffer samples. When editing a sample belonging to a topic type defined by protocol buffer, if the defining message type contains a field that is the same message type as its parent, the fields in question don't appear in the data model. This renders them non-editable in the Sample Edit window, as well as when specifying their field names in scripting commands.
TSTTOOL-181 | Scripting grammar does not allow multidimentional collections as FieldNames. When accessing user data fields in a sample read in via a script, the scripting language does not allow more than one collection index in the field name, as defined by this rule (taken from the scripting BNF found in the Tester user guide, appendix A): `FieldName ::= ( "[" "]" )? ( ( "." FieldName ) )?` The grammar specifies that the collection index can be present 0 or 1 time. So if one tries to create a parameter to a send or check instruction for a field called "array2D[0][0]", script compilation fails.
TSTTOOL-186 | Tester erroneously adds in an extra collection index to UserData, when populating the edit sample table with existing sample data containing sequences containing arrays. In the case where there is a parent sequence containing an array, or containing a struct that also contains an array further down the chain, the internal data model thinks there is valid data in the parent sequence index one greater that there actually is. For example, in a live sample in the system there contains the fields:
    sequence[0].array[0] = 0
    sequence[0].array[1] = 1
    sequence[1].array[0] = 10
    sequence[1].array[1] = 11
But, when selecting that sample to edit it, the sample userdata is populated with the following fields defined:
    sequence[0].array[0] = 0
    sequence[0].array[1] = 1
    sequence[1].array[0] = 10
    sequence[1].array[1] = 11
    sequence[2].array[0] = 0
    sequence[2].array[1] = 0
The parent sequence has the next sequence member already defined when it shouldn't have.
TSTTOOL-187 | Confusing/erroneous table readouts of multidimensional collection user data in the sample editor. When using the sample edit window for editing multidimensional collections (eg. an integer matrix), the sample edit model does not properly account for the proper ordering of the collection indices, when assigning the field values to the field names. For example, a 2x3 matrix defined like this in application code:
    int[][] array2D = new int [2][3];
    array2D[0][0] = 0;
    array2D[0][1] = 1;
    array2D[0][2] = 2;
    array2D[1][0] = 3;
    array2D[1][1] = 4;
    array2D[1][2] = 5;
would look like this in the Tester sample edit window table:
    array2D[0][0]: 0
    array2D[0][1]: 3
    array2D[0][2]:
    array2D[1][0]: 1
    array2D[1][1]: 4
    array2D[1][2]:
TSTTOOL-341 | Mismatch in handling of bounded character sequences between script send and script check. In a scenario script, given a topic that has an bounded sequence of characters in its type "b_seq", the following script code would fail the check:
    send test_SimpleCollectionTopic (
        b_seq => abc
    );

    check test_SimpleCollectionTopic (
        b_seq=> abc
    );
Passing in non-indexed parameters (ie. treating the character sequence as a regular string in scirpt) for bounded character sequences is accepted for send, but not for check.
TSTTOOL-343 | Tester's statistics browser can't display statistics information. Navigating to the statistics tab and attempting to view statistics information for DDS entities does not currently work. The Tester log file reports that the entities are not available.
TSTTOOL-355 | Tester scenario scripts continue running if Tester is disconnected from OpenSplice. If Tester is disconnected from a domain while a scenario script is running, the scenario is not interrupted and continues to its natural completion. If the script contains commands to read/write samples, the result is the script will report a fail, and will spam NullPointerExceptions reports to the OSPLTEST log for each attempt to communicate with OSPL until the script runs its course. Workaround: After domain disconnection, and the script execution ends (either by ending naturally or by explicit stoppage by user), the script can be run again after domain re-connection with success. Be aware though that previously written transient or persistent samples will be read in again on reconnect and be input into the sample table again. If it is needed, the sample table can be cleared before executing the scenario again.

## Operating System/Platform Related Issues

- LynxOS 5 - Does not support multiple networking services using the same interface, this causes an error within the logs.
- VxWorks 6.8 - When creating the target kernel an extra module is required
  - POSIX scheduling polices SCHED_FIFO/SCHED_RR/SCHED_OTHER support in RTPs (INCLUDE_PX_SCHED_DEF_POLICIES)
- VxWorks 6.7 - Usage of SIOCGIFCONF in the ioctl call from an RTP kernel causes kernel task tNet0 to crash.
  - Fix : Upgrade 6.7 with Service Pack 1 (6.7.1), includes fix to WIND00162016
- VxWorks 6.5 - When launching the Spliced using WindRiver Workbench 2.6 as described in the OpenSplice Getting Started guide, there is an intermittent problem where the Spliced or the other OpenSplice services may not spawn. This problem does not occur when Spliced is deployed using the console command prompt.
  - Workaround : rtp exec -a -p 100 -u 65536 -e "PATH=<path to OpenSplice services>" <path>/spliced.vxe file://<path>/ospl.xml &
- VxWorks 6.5 - There is an issue with the standard installation of VxWorks 6.5 in that the netmask passed from the VxWorks BootLoader may not take effect. This can cause problems with OpenSplice networking services apparantely not communicating as expected.
  - Fix: This can be rectified with a patch from WindRiver: VxWorks 6.5 Point Patch for Defect WIND00102686 revC.
  - Workaround: It is possible to hardcode the IP address and netmask into the kernel to workaround this. Enable INCLUDE_IFCONFIG and set IFCONFIG_ENTRY_1 to "gei0 192.168.1.1 netmask 255.255.0.0" (including the quotoes), for example.
- VxWorks 5.5 - When multicast is enabled a message of the format below will written to the error log file. This is under investigation and is caused by the IP_MULTICAST_TTL being set on a socket. The system default for IP_MULTICAST_TTL is always used and the value set in the OpenSplice configuration file is ignored.
  - Report : ERROR
    Date : THU JAN 01 00:00:00 1970
    Description : setsockopt returned errno 22 (errno = 0x16)
    Node : vxTarget
    Process : networking <534898608 521237760>
    Thread : networking (534917136 521237760)
    Internals : V5.4.2p1/networking: setting multicast timetolive option - Please see release notes, known issue/nw_socketMulticast.c/201/0/249999990