Vortex OpenSplice Tester FAQ’s

What is Tester?

The Vortex OpenSplice Tester Tool is a major leap forward in automated testing and debugging of Data Distribution Service (DDS) based systems. The 100% Java based Vortex OpenSplice Tester Tool is designed with the systems integrator in mind and offers an intuitive set of features to aid this task, offering both ‘local’ operation (where the tool is running on a deployed DDS-system) as well as ‘remote’ operation (where the tool connects over SOAP to a remotely deployed DDS-system).

Key Features

  • Automated testing of DDS-based systems
    • Dynamic discovery of DDS entities
    • Domain-Specific scripting Language (DSL) for test scenario’s
    • Batch execution of regression tests
  • Debugging of distributed DDS system
    • One-click definition of a monitoring-time-line
    • Analysis/comparison of topics / instances and samples
    • Virtual topic-attributes to dramatically ease analysis
    • System-browser of DDS entities (app’s / readers / writers)
    • Connectivity and QoS-conflict monitoring / detection
    • Statistics-monitoring of applications and services
  • Integrated IDE
    • Syntax highlighting editor, script-executor and Sample Logger
    • One-click relations between script, logs and timeline
    • Optional integration of message-interfaces with DDS interactions

The Vortex OpenSplice Tester Tool has the following characteristics:

  • 100% Java based
  • Remote-connection to target system (option)
  • Integrated charting capability
  • DDS-specific DSL alongside javascript, python or ruby

The Vortex OpenSplice Tester Tool is complementary to the Vortex OpenSplice Tuner Tool, in that the Tuner facilitates ‘white-box’ application monitoring and tuning (you can look ‘inside’ an application and monitor its behaviour and / or even change its Qualities of Service (QoS) parameters ‘on-the-fly’). Whereas the Vortex OpenSplice Tester Tool provides ‘black-box’ system testing and debugging of DDS-based systems (it ‘stimulates’ a DDS-system by injection of information and can react-on / validate / display / chart the system’s responses).

Is it possible to change the rate at which OpenSplice Tester runs from the default 10 Hz?

OpenSplice Tester will parse a properties file on startup called “tester.properties” which can be found in install_dir/examples/tools/ospltest. This file can be edited to tune how fast the Tester’s main reader thread runs. The “testerUpdateRate” property defines how fast the reader processing loop rungs. Each loop will take at least the amount of time, processing time + sleep time. The default for this is 100ms. The “testerMinSleepTime” property defines the minimum of time the reader processing loop must sleep. The default is 10ms.

When starting the tester I get the error “System clock has been set back (-40)”

“License checkout failed! Caught com.reprisesoftware.rlm.RlmException: System clock has been set back (-40)”

OpenSplice tester uses RLM for its licensing.  RLM detects windback by looking for future-dated files (access and modified times) in system directories. In many cases just running the system for a little while with the correct date will access the future-dated files and the problem will clear itself. Often a reboot helps too. If it doesn’t clear itself you will have to go into those directories and look for the offending file and set them to the current time by accessing them. On windows, RLM looks in windows or winnt. On linux, RLM looks in /etc, /var/adm, and /var/log.

When no Durability Service is running Tester has a large delay on startup and creation of readers.

This is due to a hardcoded value of 30 seconds for waitForHistoricalData timeout. This affects user created readers and the 5 builtin readers. This means that on connect, Tester will spend approximately 2.5 minutes “connecting” and be unresponsive for that entire time.
This can be avoided by changing settings in the tester.properties file. It defines a wait timeout in seconds for the waitForHistoricalData call for Tester’s 5 built-in topic readers. When connecting to systems with no durability service, setting this property to equal zero eliminates the long wait times for connection, while still making the attempt to collect transient data for the built-in topics.
Network Channel / Transport Priority FAQ’s

DDSI-Extended (DDSI2E) is an extended version of the DDSI2 networking service, giving extra features for:

  • Network partitions: Network partitions provide the ability to use alternative multicast addresses for combinations of DCPS topics and partitions to separate out traffic flows, for example for routing or load reduction.
  • Security: Encryption can be configured per network partition. This enables configuring encrypted transmission for subsets of the data.
  • Bandwidth limiting and traffic scheduling: Any number of ‘network channels’ can be defined, each with an associated transport priority. Application data is routed via the network channel with the best matching priority. For each network channel, outgoing bandwidth limits can be set and the IP ‘differentiated services’ options can be controlled.

A much more comprehensive overview of the networking service can be found in the Vortex OpenSplice Deployment Guide and Configuration Guide.

Channel and Transport Priority

This attribute sets the transport priority of the channel. Messages sent to the network have a transport_priority quality of service value. Selection of a networking channel is based on the priority requested by the message and the priority offered by the channel. The priority settings of the different channels divide the priority range into intervals. Within a channel, messages are sorted in order of priority.

Can I specify the value for Priority of the channel with Lower limit & Higher Limit for the particular range?

The transport priorities have no explicit mapping onto the operating system’s scheduling priorities. When we say transport priority ranges and intervals, it means you can create multiple channels each with a “transport priority” value. As an example, you might create 4 channels, one with priority 25, one with 50, one with 75 and one with 100. Then messages with transport priority 20 will be sent over the first channel, messages with priority 30 will be sent over the second channel etc. The priority of these messages are programmatically set by the “transport_priority QoS”.

The default priority is 0. Does this mean that it is the lowest or normal priority?

0 is the lowest priority.

Is the priority handled by the DDS library or does it need to be handled by the application?

All transport priorities are handled by the networking services with OpenSplice DDS. The user does not need to have thread priorities within their applications to manage this, the threading priority of the application code is independent to the threading of the network channels.

Are the priority values the same with respect to OpenSplice DDS operating on different platforms?

Priority ranges are comparable across different operating systems, it is the job of OpenSpliceDDS to define the operating system’s scheduling classes and the priorities of each channel in order to satisfy the channel priorities requested in the XML configuration file. A channel with transport priority 100 will always take precedent over one with 50, in that sense the ranges are comparable, but the threading that is selected to achieve this can vary across operating systems.

Could you provide some more information on DiffServField with respect to channel configuration?

The DiffServField value is included in all message packets sent over a particular channel and contains routing information. It uses the “Differentiated Services Code Point” DSCP) standard. It is independent to the network channel priority discussed above.

How does the networking service handle data sent with no channel or transport priority defined?

The networking service will always use a channel with the reliability attribute that matches the Reliability QoS of the message, the only exception to this rule, is the case where there is no channel configured with the matching reliability attribute. In that case the networking service will fall back to the channel that is labeled as default. This will happen if an application writes a message with RELIABLE reliability, while the networking configuration only contains channels with the the reliability attribute set to FALSE.

When there are multiple channels defined with a matching reliability attribute, than the networking will select one of those channels based on the Transport Priority QoS of the message. This value is compared with the priority attribute of the matching channels, and the networking service will select the channel with the the closest priority, equal or higher than that of the Transport Priority QoS of the message. If there is no matching channel with a priority equal or higher than that of the Transport Priority QoS, the channel with the highest priority is chosen.

The traffic of each channel is handled by a specific set of threads, of which the scheduling_class and thread_priority can be configured. These values do not depend upon the value of the Transport Priority QoS, but only on the channel chosen by the method described above. In addition to the choice of channel, the Transport Priority QoS is also used in the channels, where it will be used (among other factors) to determine the sequence in which messages are handled.


Vortex OpenSplice Tuner FAQ’s

Several common Vortex OpenSplice Tuner problems can be resolved by looking through the User Guide, which can be found here:

When using the Vortex OpenSplice Tuner you may run into some of the following errors:

Could not load JNI library error.

Could not load JNI library ‘cmjni’. Reason:
/opt/PrismTech/OpenSpliceDDS/VX.X.X/HDE/x86.linux2.6/lib/libcmjni.so: /opt/PrismTech/OpenSpliceDDS/VX.X.X/HDE/x86.linux2.6/lib/libcmjni.so: wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch)

The reason that you are seeing this message is because you are starting the tuner with a 64 bit JVM and using OpenSplice 32 bit libraries. To resolve the problem you need to either to use the 32-bit JVM or install the 64-bit version of Vortex OpenSplice

OpenSplice Tuner freezes when running via a remote shell

This a issue common with running any java GUI through a ssh -X terminal. Running a GUI remotely via ssh can cause the application to freeze depending on the network connection, however this would go for any java application being run in this manner. To prevent this from occurring in the future you should run the Tuner GUI locally creating a new OpenSplice node.

Vortex OpenSplice Tuner  “check the Supplied URI/URL is available or the shared memory segment” error.

When configuring OpenSplice you can choose between a shared memory architecture or a single process memory architecture. If you configure OpenSplice to use shared memory, when it starts it allocates a block in memory to use as the shared database. This is used by the DDS related administration and all DDS applications deployed in the current system. The data is only physically present once on any machine and smart administration is used to provide a view of the data for each subscriber.

At startup OpenSplice will create a this shared memory region at a virtual address in memory that is common across OpenSplice daemon, any services used by that domain and also the application. In this case it appears that the tuner is having a problem mapping the shared memory into its process space. In the case of this error in Tuner, provided the Opensplice daemon is running without any errors (check for an ospl-error.xml output file) it is possible that the memory location Tuner requests clashes with some of the Java libraries that Tuner has mapped in.

With the standard “shmem” ospl.xml file the shared memory size is 10MB and the address where the memory is mapped is 0x40000000 (on windows). You will need to modify the memory address so that it is no longer clashing.  You can do this by using the Configurator tool to modify the OpenSplice/Domain/Database/Address within the XML file (it can also be edited manually). There is more information on this in the OpenSplice Configuration and Deployment Guides, this article also has more information on the configurator. This configuration element is used to specify the start address of the location of the shared memory database, where the nodal shared administration is mapped into virtual memory for each process that attaches to the current Domain. The default values are platform dependent.

On windows you can use the VMMap utility provided by SysInternals. This shows the process address space and the files mapped into the process, along with the free regions. This should enable you to see if the memory is indeed clashing and allow you to find another free region to map the shared memory to.

Error when deleting Domain Participant: The Domain Participant contains one or more Entity objects.

When trying to delete a Domain Participant using the tuner the above error appears along with the following in log file:

Report : WARNING
Data : Mon Dec 15 11:00:00 2014
Description : Delete Participant 0x684df8 failed: Some contained Subscribers still exists
Node : test
Process : a_process <5000>
Thread : 4792
Internals: VX.X.X/3070bd6/2a52f68/_DomainParticipantPrepareDelete/gapi_domainParticipant.c/725/0/1387546234.801343120
In this case the error is pointing to a Subscriber still existing somewhere within the system. To solve this problem inspect your code to ensure that all Subscriber entities are deleted before an attempt is made to delete the Subscriber itself (datareaders etc.). It should be noted that all memory loans used by data readers on the Subscriber Entity must be returned.

Vortex OpenSplice Record and Replay FAQ’s

RnR Frequently Asked Questions

For more information on what the Record and Replay services are see this article.

What storage types does OpenSplice Record and Replay support?

The service records the data to storage xml files. These xml files can get quite large, and can be difficult to query and read. RnR Manager provides a Storage Editor that makes it easier to query, view and update this storage data. On import, the xml storage files are converted to a database file. The database can then be queried and updated. Updated data can be exported back into the OpenSplice Record and Replay service storage xml format if required

Vortex OpenSplice Record and Replay v6.4 and above supports two types of storage:

  •  XML – recorded data will be stored in xml format.
  • CDR – recorded data will be stored in binary CDR format.

Previous to version 6.4 only XML format was supported.

When you first launch the RnR Manager it needs write access to the Eclipse subdirectory in order to set up the workspace. How can I configure the tool to set up a writeable area per user area?

RnR Manager is started by executing the startRnRManager script, located in the eclipse directory of the RnR Manager install directory. The script’s purpose is to ensure the proper setting of the Vortex OpenSplice environment variables prior to application launch.

The script allows for command line options to be passed to the application. Any command line options accepted by an Eclipse application are also accepted by RnR Manager. A particularly useful option is -data , which allows a user to specify a custom directory to use as the RnR Manager workspace in case the default directory is shared or write protected. Example of starting RnR Manager with a non default workspace location: /startRnRManager.sh -data /home/user/rnrworkspace \startRnRManager.bat -data C:\Users\user\rnrworkspace.

Is it possible to record two topics simultaneously using two different storages?

Yes, this is indeed possible. There are no constraints on the number of recordings or the mapping between Topics and Storages.

Vortex Cafe FAQ

This is a list of frequently asked questions about Vortex Cafe which should help you resolve any issues you may be having when using the product.

Vortex Cafe FAQ

Vortex Cafe compatabilities

Which Java versions are supported by Vortex Cafe?

Vortex Café supports Java 5 and any further version.

Vortex Cafe Tuning

How should I configure Vortex Café for small devices (i.e. with constrained resources) ?

On devices with low memory and limited CPU, Vortex Café will give better results if configured to lower its memory usage and to use less number of threads. Here is an example of such configuration:

ddsi.network.receiver.udp.buffer.size=< size-of-biggestsample + 128 >


  • <size-of-biggestsample + 128 > is the serialized size of the biggest data your application could publish, plus 128 bytes. The serialized size of your data is usually a few bigger than the size of your data in memory, because of padding.
  • <maximum acceptable duration> is the maximum period during which your application might not publish any data. If your application doesn’t send any message during this period, the remote Participant will consider your application as terminated.
  • <leaseDuration/3> is the same value than above (maximum acceptable duration) divided by 3. Thus, 3 messages will be send during this duration, avoiding remote Participant to consider your application as terminated.

You should also configure your JVM to lower its memory usage. For instance on a Raspberry Pi 2 (1GB RAM) with the Oracle’s Java, use the following options:


On a Raspberry Pi model B (512MB RAM) rather use:


Vortex Cafe Connectivity

How should I configure Vortex Café in a multihomed environment (several network interfaces) ?

Vortex Café can only use a single network interface at a time. It will, by default automatically select a network interface among available ones. But it is often useful to explicitely select the interface out of which you want Café to communicate. This can be done easily with the following option:


Below are some examples:



How to increase TCP/IP Connection Migration reactivity ?

Café automatically migrates connections across available interface when network connectivity changes. For instance, if a mobile applications is communicating via WiFi and then loses WiFi having as only option a 3G network, then Café will automatically switch to 3G. The reactivity of the switch depends on the following settings:


The duration is expressed in seconds, as shown below:


Why do I have UDP communication problems on an Android device ?

If you experience communication issues with Vortex Café configured with UDP on an Android device, such as DataReader not receiving data, or duration leases expiration despite no Participant has been stopped, those are probably caused by loss of UDP multicast packets. Loosing packets could lead to false lease expiration of the duration lease for a remote participant, and to the un-matching of Readers/Writers (and thus to loss of DDS communications). The cause of packets loss are usually a bad support of UDP multicast by the Android device or by the WiFi router. In such case, you should configure Vortex Café on Android to limit it’s UDP multicast usage with such option:


Why do I have UDP communication problems on WiFi ?

As described in https://tools.ietf.org/id/draft-mcbride-mboned-wifi-mcast-problem-statement-00.html there are known issues with IP multicast in a WiFi 802.11 environment, leading to UDP multicast packets loss. The same document advises to use 802.11n (minimum) to help providing a more reliable and higher level of signal-to-noise ratio in a wifi environment over which multicast packets can be sent. However, if you still experience communication issues (DataReader not receiving data, or duration leases expiration despite no Participant has been stopped), you should configure Vortex Café on Android to limit it’s UDP multicast usage with such option:


Vortex Cafe Android

Which Android API versions are supported by Vortex Café ?

Vortex Café is a pure Java library, independent of any Android API. Consequently, it can be used with any level of Android API.

How can I get verbose logs in LogCat of Android monitor ?

The default level of tags is INFO. You can change the default level by setting a system property: setprop log.tag. Where level is either VERBOSE, DEBUG, INFO, WARN, ERROR, ASSERT, or SUPPRESS. SUPPRESS will turn off all logging for your tag.

Example: adb shell setprop log.tag DEBUG