One Admin Console To Debug Them All! 1


Better DDS Debugging with Admin Console

How can you debug a program when data is not flowing? It’s difficult to even diagnose a data flow issues since Quality of Service (QoS) can vary from one application to another. The problem can be compounded by the sheer scale of a system, as well as the integration of subsystems in a heterogeneous environment.

To ease debugging, the RTI Admin Console in Connext DDS 5.1 has added real-time match analyses. Each time a new DataWriter or DataReader is discovered, Admin Console evaluates its QoS as it relates to the other DataWriters and DataReaders associated with that topic. This evaluation is updated as the system changes.


Let’s say a specific DataReader deadline is compatible with a specific DataWriter. Then assume an application changes the deadline of that DataReader to make it incompatible with the DataWriter. Admin Console is notified of the updated QoS (through Discovery) and updates the match status.

So, what does it look like? Well, let’s walk through the user interface elements. First, the Physical View shows that the System, Host (balancerock in this case), and processes are in an error state.

The DDS Logical View also gets in on the act by showing the Topic which has the error. The DDS Logical View provides a DDS-centric view of the system by putting Topics under their respective Domains.


We click on the ‘Square’ Topic to bring up the Topic Editor. While there are two DataWriters, only one of them is mismatched. The DataReader is shown as ‘Partially matched’ because it matches one DataWriter but not the other.


We select the mismatched DataWriter and turn our attention to the ‘Match Analyses’ tab to discover the reasons for the problem.


It seems there are two problems; the Ownership and the Deadline QoSes are mismatched.

Did you notice that the QoS policies in the first column are formatted like hyperlinks? That’s because they are hyperlinks. If you click on the Ownership hyperlink, Admin Console shows you the compatibility documentation for the Ownership QoS policy. The other hyperlink points to the Deadline QoS policy.

Code Generator 2: Generate Code Faster 1

Are you tired of waiting for all your code to be generated? Would you like to customize the generated output? Code Generator 2 is your solution. This new code generator is already available in your RTI Connext DDS 5.1.0 installation as an Early Access Release (EAR).

Code Generator 2 is written completely in Java and uses Apache Velocity (VLT) templates to define the generated output. This allows you to customize the generated code for different languages by modifying those templates. Check the predefined set of variables available in RTI_rtiddsgen_template_variables.xlsx, located in the Code Generator 2 documentation.

This new design also improves performance compared to the current code generator. The VLT templates are parsed faster than the XSLT ones (used by the current code generator). When generating code for a large IDL, Code Generator 2 is up to 10 times faster than the current code generator.

If you want to invoke the code generator multiples times with different parameters or IDL files, Code Generator 2 provides a server mode that further improves its performance. When used in server mode, Code Generator 2 runs as a native executable that connects through TCP with a server instance of the code generator. The server instance is initiated automatically the first time that the code generator is invoked and it is automatically stopped after an inactivity period. As a result, the JVM is only loaded once when the server is started, the VLT templates are compiled once and the following invocations to Code Generator 2 are resolved faster.


Do you want to try Code Generator 2? Just run the rtiddsgen2 or the rtiddsgen2_server (for running in server mode) scripts with the usual parameters. If you need more information about supported and new features available in Code Generator 2, check out its Getting Started Guide.

Recording Service 5.1: Faster, More Scalable and More Concurrent than Ever! Reply

You’re facing a problem in your DDS system: you want to use Recording Service 5.0 to record high throughput data coming in from sensor networks. The database has to be accessed by other applications while Recorder is continuously recording. Your topics are updated frequently and Recorder has to write at such speeds that it locks some of your other applications out of the database. When you open the database, you realize that although your types are small, the tables are big and full of columns you don’t really need. What can you do??

Good news!

RTI Recording Service 5.1 was released a month ago with one of the biggest feature releases across the entire suite, including Recorder, Replay, Recording Console and Converter.

There were three motivations behind the updates to Recording Service 5.1 (RS):

  1. The OMG XTypes Specification, which required integration with XTypes, including Mutability and types with optional members.

  2. Enhanced scalability and performance, which resulted in additional configurability of the SampleInfo and metadata fields being recorded, and a reduction in new default column sets.

  3. Improvements in data concurrency, especially in systems where the database is accessed by other applications while Recorder is recording.

Your types evolve? No problem. Recorder records them, Replay replays them

Systems evolve and as they evolve, so do their data and data types. Recorder and Replay support the XTypes specification, with mutable types and types with optional members. Recorder and Replay allow you to choose what version of a type to record or replay, by providing the types via XML. A new feature that easily allows mapping of topic names and type versions in the configurations.


Recorder and Replay administration types and topics are now also using X-Types. From this point forward (starting with 5.1), if the types evolve in the future, legacy applications will be able to administer the tools.

Configurability for enhanced scalability and performance

One of the coolest new features in Recorder is the ability for the user to select the SampleInfo and metadata fields to be included in user topic tables, as well as which fields to store in the discovery tables. Also now, by default, only a few extra fields are recorded apart from those of the user data types – just the necessary fields for Replay and Converter to work with the database file. See section 4.5.1 of Recording Service User’s Manual for details and examples.

These new settings and feature enable a boost in the performance and scalability of Recorder. It can now record more user data fields and fewer irrelevant fields. Compared with version 5.0, the size of the database can be significantly reduced in cases where the user types are small- to medium-sized.

Boosting concurrent access to the database while Recorder is recording

There are new features that enable improved concurrent access to the database while it’s being recorded. Highlights include:

  • Ability to specify SQLite pragmas upon creation of the database file (and subsequent segments).
    Among other things, this gives the ability to change SQLite from journal mode to WAL mode. Write-Ahead Logging offers improved concurrency because readers of the database don’t block writers and a writer doesn’t block readers.

  • Online indexing.
    Recorder can create and maintain indexes on the database while recording. Indexes can be established for any SampleInfo fields or for user data fields (when recording in deserialized format). When other applications need efficient access to certain tables, and the access is based on the content in certain fields in those tables, online indexing can really improve the overall performance of the system. However, remember there is a tradeoff: Recorder’s performance will decrease as the number of indexes to maintain increases. Check out section 4.8.2 of our RTI Recording Service User’s Manual 5.1 for tips and tricks for indexing in SQLite databases.

And more…

There are lots of new features, improvements and cool changes I haven’t covered here, including automatic path separator detection in Replay, a new and faster deserialization algorithm for Converter and topic filters in QoS settings.

Check out the RTI Recording Service 5.1 Release Notes to get a sense of all this new stuff!