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.