.. include:: ../../../recorder.4.0/srcDoc/vars.rst .. _section-record_configuration: Configuration ============= This section provides a reference for the XML elements that comprise a |RECS| configuration. For details on how to provide XML configurations to |RECS|. refer to :ref:`section-Common-Config`. This chapter describes how to compose an XML configuration. Builtin Configuration of Recording Service ------------------------------------------ |RECS| is pre-configured with a builtin configuration. See :numref:`section-builtin-config-recording-service` for more details. .. _section-record-config-XML-tags: XML Tags for Configuring Recording Service ------------------------------------------ This section describes the XML tags you can use in a |RECS| configuration file. The following diagram and table describe the top-level tags allowed within the root ```` tag. .. figure:: ../static/RecordingServiceTopLevelTags.png :alt: Top-Level tags in Recording Service's Configuration File :name: FigureTopLevelTag :align: center :figwidth: 50 % Top-level Tags in Recording Service's Configuration File .. list-table:: Top-level Tags in Recording Service's Configuration File :name: TableTopLevelTag :widths: 20 70 10 :header-rows: 1 :class: longtable * - Tags within - Description - Multiplicity * - - Specifies a QoS library and profiles. The contents of this tag are specified in the same manner as for the *Connext DDS* QoS profile file—see :link_configuring_qos_xml_up_5:`Configuring QoS with XML in the RTI Connext DDS Core Libraries User's Manual <>`. - 0..* * - - Defines types that can be used by |RECS|. This is needed if data types are not available through discovery, or when using a transformation. The type description is done using the *Connext DDS* XML format for type definitions. See :link_userman_types_in_xml_up_5:`Creating User Data Types with Extensible Markup Language (XML), in the RTI Connext DDS Core Libraries User's Manual <>`. - 0..* * - - Contains a list of libraries that can be used to: - Plug in custom storage, such as custom databases. For more information, see :numref:`section-record-custom-storage`. - Transform data after it is received from *Connext DDS* and before it is stored. For more on using transformations, see :link_router_manual_config_transformation_up_5:`Data Transformation, in the RTI Routing Service User’s Manual <>`. See :numref:`section-Record-Config-Plugins` - 0..* * - - **Required.** |br| Specifies a |RECS| configuration. See :numref:`section-config-recording-service-tag`. Attributes - ``name``: Uniquely identifies a service configuration. **Required**. Example .. code-block:: xml - 1..* .. _section-config-recording-service-tag: Recording Service Tag --------------------- A configuration file must have at least one ```` tag. This tag is used to configure an execution of |RECS|. A configuration file may contain multiple ```` tags. When you start |RECS|, you can use the ``-cfgName`` command-line parameter to specify which ```` tag to use to configure the service. This means one file can be used to configure multiple |RECS| executions. The following diagram and :numref:`TableRecordingServiceTag` describe the tags allowed within a ```` tag. .. figure:: ../static/RecordingServiceTags.png :alt: Tags used to configure a |RECS| instance :name: FigureRecordingServiceTag :align: center :figwidth: 50 % Tags used to configure a |RECS| instance .. list-table:: Recording Service Tags in Recording Service's Configuration File :name: TableRecordingServiceTag :widths: 20 70 10 :header-rows: 1 :class: longtable * - Tags within - Description - Multiplicity * - - Enables remote administration. When administration is enabled, monitoring is also enabled by default. If no domain ID is specified for monitoring, |RECS| will use the same domain as administration by default. See :numref:`section-config-administration-tag`. - 0..1 * - - Enables monitoring for the recording service, including statistics. See :numref:`section-config-monitoring-tag`. - 0..1 * - - Describes how the data will be stored. If this is not specified, data will be stored in a SQLite file using the default name "rti_recorder_default.db". See :numref:`section-record-config-storage-tag`. - 0..1 * - - **Required**. |br| Specifies a DomainParticipant to use to record data. Attributes - ``name``: Uniquely defines a DomainParticipant. **Required**. Example .. code-block:: xml 3 See :numref:`section-config-domainparticipant-tag`. - 1..* * - - **Required**. |br| Active component of |RECS| for recording data. Contains one or more threads that can be used for recording. Attributes - ``name``: Uniquely defines a recording session. **Required**. - ``default_participant_ref``: Specifies a default DomainParticipant to be used by children of this recording session. Children can override this by specifying their own participant. Example .. code-block:: xml See :numref:`section-config-session-tag`. - 1..* Example: Specify a Recording Service Configuration in XML ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ .. code-block:: xml Starting a |RECS| instance with the following command will use the ```` tag with the name "MyRecorderService": .. code-block:: bash $NDDSHOME/bin/rtirecordingservice -cfgFile file.xml -cfgName MyRecorderService .. _section-config-administration-tag: Administration -------------- The ```` tag allows you to enable and configure remote administration of |RECS|, including stopping, starting, and pausing recording. See :numref:`section-record_administration` for details on using remote administration. .. list-table:: Administration Tags in Recording Service's Configuration File :name: TableAdministrationTag :widths: 20 70 10 :header-rows: 1 :class: longtable * - Tags within - Description - Multiplicity * - - Domain ID used for remote administration. Also used for monitoring by default. - 0..1 * - - QoS used by the administration DomainParticipant. If the tag is not defined, *Connext DDS* defaults will be used. - 0..1 * - - QoS used by the administration Publisher. If the tag is not defined, *Connext DDS* defaults will be used. - 0..1 * - - QoS used by the administration Subscriber. If the tag is not defined, *Connext DDS* defaults will be used. - 0..1 * - - QoS used by administration DataWriter(s). If the tag is not defined, *Connext DDS* defaults will be used, with the following changes: - history.kind = DDS_KEEP_ALL_HISTORY_QOS - resource_limits.max_samples = 32 - 0..1 * - - Quality of Service (QoS) used by administration DataReader(s). If the tag is not defined, the *Connext DDS* defaults will be used, with the following changes: - reliability.kind = DDS_RELIABLE_RELIABILITY_QOS (this value cannot be changed) - history.kind = DDS_KEEP_ALL_HISTORY_QOS - resource_limits.max_samples = 32 - 0..1 * - - When you enable *Distributed Logger*, |RECS| will publish its Log messages to *Connext DDS*. See :numref:`section-config-enabling-distributed-logger`. - 0..1 The contents of the tags for configuring QoS are specified in the same manner as for the *Connext DDS* QoS profile file. See :link_configuring_qos_xml_up_5:`Configuring QoS with XML, in the RTI Connext DDS Core Libraries User's Manual <>`. .. _section-config-monitoring-tag: Monitoring ---------- The ```` tag allows you to enable and configure remote monitoring of |RECS|. See :numref:`section-Recorder-Monitoring`. .. list-table:: Monitoring Tags in Recording Service's Configuration File :name: TableMonitoringTag :widths: 20 70 10 :header-rows: 1 :class: longtable * - Tags within - Description - Multiplicity * - - Whether to enable monitoring of the service. Default: Disabled, unless administration is enabled. - 0..1 * - - Domain ID used for monitoring. Default: The domain ID specified for monitoring. - 0..1 * - - QoS used by monitoring DataWriter(s) - 0..1 * - - QoS used by monitoring Publisher(s) - 0..1 * - - QoS used by monitoring DomainParticipant - 0..1 * - - How frequently to sample the service's statistics, using the tags or . For example, 1 samples the service's statistics every second. Default: 1 second. - 0..1 * - - How frequently to publish the service status, using the tags or . For example, 1 publishes the service's status every second. Default: 5 seconds - 0..1 The contents of the tags for configuring QoS are specified in the same manner as for the *Connext DDS* QoS profile file. See :link_configuring_qos_xml_up_5:`Configuring QoS with XML, in the RTI Connext DDS Core Libraries User's Manual <>`. .. _section-record-config-storage-tag: Storage ------- The ```` tag allows you to configure the storage to which data will be written. You can choose between using the builtin SQLite storage or implementing your own storage plugin. You can also specify the *flush period* of the service, defined as the time interval between consecutive writings of samples to disk. Within , |RECS| can also be set in *buffering mode*. This mode disables all automatic storage to disk and just writes the data to disk upon reception of a remote `flush()` command. .. list-table:: Storage Tags in Recording Service's Configuration File :name: TableRecorderStorageTag :widths: 20 70 10 :header-rows: 1 * - Tags within - Description - Multiplicity * - - Enables storing data in a SQLite database file. See :numref:`section-record-config-sqlite-tag`. - 0..1 * - - Enables storing data in an external library that you specify. Attributes - ``plugin_name``: Name of the plug-in that creates a storage plugin object. This name shall refer to a registered storage plug-in. See :numref:`section-Common-PluginManagement` for details on how the options of how to register plugins). See :numref:`section-Record-Config-Storage-Plugin-Tag` for more about using this tag. See :numref:`section-record-custom-storage` for a tutorial on plugging in custom storage. - 0..1 * - - Defined as a duration (seconds and nanoseconds), represents the rate at which user-data samples will be written to disk. When this tag is present, *Recording Service* will work in a purely periodic fashion. If no remote *flush()* command is received, data will be written to disk only when this period elapses. This tag cannot be used at the same time as the tag. Default: no default. If not set, *Recording Service* will work in a purely reactive way. - 0..1 * - - When set to true, *Recording Service* will run in buffering mode. This mode is a listening-only mode and will not output data to disk automatically. Instead, *Recording Service* will wait continously for remote `flush()` commands to trigger the storage to disk (see :numref:`section_record_remote_storage` for more information about the remote `flush` command). *Recording Service* will buffer samples using the caches in the DataReaders it creates, so it is important that the size of the caches is controlled so memory doesn't grow indefinitely. The size can be controlled by controlling the size of the queue (see :numref:`section-recording-service-operation-mode`) or by ensuring that the rate at which `flush` remote commands are sent matches the sample rate. The general recommendation is to define a buffer size for all Topics and Topic Groups in the configuration. This tag cannot be used at the same time as the tag. This feature *requires* remote administration to be enabled. If remote administration isn't enabled in the configuration, *Recording Service* will enable it automatically. Default: false (service will start in normal operation mode). - 0..1 * - - When this setting is enabled, *Recording Service* will keep an internal index about instances and their values. It will also store this instance to disk once *Recording Service* shuts down. This can affect the recording performance. However, *Replay Service* startup time will be improved when the Instance History Replay setting is enabled (see :numref:`section-replay_config_playback_tag`). If this setting is not enabled, Replay will build the indexes while starting up, delaying the startup process. Indexing can also be done offline, see :numref:`section-indexer-instances`. See :numref:`section-record-config-instance-indexing-tag` for more details on instance indexing configuration. - 0..1 .. _section-record-config-sqlite-tag: SQLite ^^^^^^ The ```` tag allows you to specify the name and file extension of a SQLite file in which to write data. It also allows you to choose the storage format in which to store the data. The default format, XCDR_AUTO, records data without deserializing it from the network format, so it is the most efficient way to store data; however, it is a binary format that cannot be queried without using *Converter* to convert it to a readable JSON_SQLITE format. The JSON_SQLITE format is slower to record, because it requires deserializing the data, but it can be queried using SQLite tools. .. list-table:: SQLite Tags in Recording Service's Configuration File :name: TableSqliteTag :widths: 20 70 10 :header-rows: 1 :class: longtable * - Tags within - Description - Multiplicity * - - Set of files to write to, and parameters for creating files and directories in that set. See :numref:`section-config-fileset-tag`. - 0..1 * - - File to write to. |br| Default: rti_recorder_default - 0..1 * - - Allows you to add a suffix to the end of a filename. - 0..1 * - - Whether |RECS| is allowed to overwrite files. The options are OVERWRITE or DO_NOT_TOUCH. When DO_NOT_TOUCH is selected, |RECS| cannot overwrite an existing file, even if the rollover functionality is enabled. Default: OVERWRITE - 0..1 * - - Specifies what format the data is stored in. |br| The options are: - XCDR_AUTO: This is the binary format used by *Connext DDS* when sending data over the network. This has the highest performance for recording, but can only be viewed by using *Converter* to convert the data to a readable format, or by using *Replay* to replay the data. This will internally store data in XCDR or XCDR2 depending on the format received. - JSON_SQLITE: This format can be queried, but recording in this format has lower performance because data must be deserialized before it can be stored. - XCDR: The format to use when communicating with *Connext DDS* before 6.0.0. - XCDR2: More efficient than XCDR, used by *Connext DDS* 6.0.0 and later. Default: XCDR_AUTO - 0..1 * - - Specifies a SQLite SQL expression to use when establishing sqlite connections using this plugin. This can be used to change the pragmas used by SQLite, or to do other database operations. |br| **Note**: when using |RECS| and another application (either |REPS| or another SQLite application) at the same time to access the same database files, we recommend using SQLite's WAL (write-ahead logging) mode. This can be done by adding ``PRAGMA JOURNAL_MODE = WAL;`` to this configuration setting. More information about SQLite's WAL mode can be found `here `_. Default: PRAGMA SYNCHRONOUS = OFF; PRAGMA JOURNAL_MODE = MEMORY; - 0..1 .. _section-config-fileset-tag: Fileset ''''''' The ```` tag allows you to specify a set of files for *Recording Service* to write to. This lets you specify behaviors such as "create a new directory with each run of |RECS| based on the timestamp when the tool was started" or "create a new file every time |RECS| is started, incrementing an integer in the filename." The ```` tag is also where the rollover behavior is specified. .. list-table:: Fileset Tags in Recording Service's Configuration File :name: TableFilesetTag :widths: 20 70 10 :header-rows: 1 :class: longtable * - Tags within - Description - Multiplicity * - - Base directory where the database files for an instance of *Recording Service* (including discovery and user data files) will be stored. Depending on the value of the tag, this will either contain a set of files or a set of directories. Default: The current working directory. - 0..1 * - - When |RECS| starts, it will use this expression to create the directory where output files will be stored. Every time |RECS| starts, it will evaluate this expression to decide on its output directory. Stopping and restarting remotely will cause *Recording Service* to re-evaluate this expression and possibly change its output directory. This execution directory is a parameterisable expression. In it, it accepts text and any combination of the following: - Autonumeric. **Format: %auto:M-N%.** This parameter describes an integer that auto-increments every time |RECS| starts. The numeric sequence is restarted when |RECS| is manually shut down and restarted. M must be lower than N; together they define a numeric range, both inclusive. N can be omitted (%auto:M%), resulting in an unlimited sequence of numbers starting at M. Example: .. code-block:: xml test_run_%auto:0-3% This example will create directories named test_run_0, test_run_1, test_run_2, and test_run_3. - Timestamp. **Format: %ts%.** This parameter will take the current timestamp in the system (the time represented as number of seconds since Epoch). - Time. **Format: %T%.** Current time expressed in ISO 8601 time format (HH:MM:SS). Example: 14:55:02. This parameter uses the strftime() parameter %T. - Short date. **Format: %F%**. Short date in YYYY-MM-DD format. Example: 2001-08-23. This parameter uses the strftime() parameter %F. - Date and time. **Format: %c%**. Date and time representation, locale-dependent. This parameter uses the strftime() parameter %c. **Note**: Using parameters, |RECS| will check if the possible execution directories exist before overwriting any directory. If the execution directories exist, *Recording Service's* behavior will be affected by the value of the tag. If is set to OVERWRITE, |RECS| will overwrite the first directory. Otherwise, |RECS| will not delete any of the old directories and will just exit. Using no parameters will yield the same execution directory every time the service is started. In this case, if the directory already contains database files, they may be overwritten (see the tag). Default: %ts% (current timestamp number since Epoch). - 0..1 * - - Once |RECS| knows the exact directory in which to put the database files, it will use this parameter to determine the name(s) of the user data file(s) to be created. Right before the recording starts and every time |RECS| has to change its current file to a new one, it will use this parameterisable expression to generate the next file's name. This setting accepts text and any combination of the following parameters: - Autonumeric. **Format: %auto:M-N%.** This parameter describes an integer that auto-increments every time |RECS| is started. However, the numeric sequence is restarted with every execution of the |RECS| application. M must be lower than N; together M and N define a numeric range, both inclusive. N may be omitted (%auto:M%), resulting in an unlimited sequence of numbers starting at M. Example: .. code-block:: xml test_files_%auto:0-2%.db This will create files named test_files_0.db, test_files_1.db, and test_files_2.db. When a rollover event occurs, *Recording Service* will either create one of these files, or overwrite the next file in the sequence. When |RECS| is restarted, this will start over with overwriting test_files_0.db. - Timestamp. **Format: %ts%.** This parameter will take the current timestamp in the system (the time represented as number of seconds since Epoch). - Time. **Format: %T%.** Current time expressed in ISO 8601 time format (HH:MM:SS). Example: 14:55:02. This parameter uses the strftime() parameter %T. - Short date. **Format: %F%.** Short date in YYYY-MM-DD format. Example: 2001-08-23. This parameter uses the strftime() parameter %F. |br| **Note:** This parameter will not vary in 24 hours, so use with caution in combination with the rollover time limit feature (time limit should be greater than 1 day; otherwise, you may overwrite the same file continously). - Date and time. **Format: %c%.** Date and time representation, locale-dependent. This parameter uses the strftime() parameter %c. **Note:** Using no parameters will yield the same file name every time. Therefore, if a file rollover command is received or scheduled, |RECS| will be stopped (no more data can be stored without overwriting the current, and only, file). Default: rti_recorder_default_%auto:0%.db (auto-numeric starting at zero, unlimited). - 0..1 * - - Configuration for rolling over the file after a size or time limit is reached. See :numref:`section-config-rollover-tag`. - 0..1 .. _section-config-rollover-tag: Rollover '''''''' Rollover enables |RECS| to overwrite the oldest data file created by the current execution of the service when the last file in the set has reached a maximum size, or when a time limit is reached. **Note:** In this release, rollover is only supported when the tag specifies an auto-numeric filename. (See example below.) .. code-block:: xml JSON_SQLITE output_dir file_rollover_%auto:0-9%.db true 50 .. list-table:: Rollover Tags in Recording Service's Configuration File :name: TableRolloverTag :widths: 20 70 10 :header-rows: 1 * - Tags within - Description - Multiplicity * - - Whether |RECS| will roll over files when a limit is reached. |br| Default: False. - 0..1 * - - The maximum allowed size for a file in a set. Note that setting this to a very low value (e.g., 1 KB) may yield unexpected behavior, because SQLite will take up more than that for even the simplest file. |br| **Note:** The unit refers to the decimal prefix and not the binary prefix of the number, meaning 1 MEGABYTES = 1000 KB (and not 1024 KB). This is usually the standard way to refer to storage size. Attributes: - unit: (Optional) The unit in which the size is expressed. The following values are allowed (Default: ``KILOBYTES``): - ``BYTES`` - ``KILOBYTES`` - ``MEGABYTES`` - ``GIGABYTES`` - 0..1 * - - The maximum amount of time |RECS| can record to a file in a set. Specified with tags , , , . Attributes: - start_time: The time to do the first rollover. After that, rollover will be done when the time_limit or file_size_limit is reached. - 0..1 .. _section-Record-Config-Storage-Plugin-Tag: Plugin ^^^^^^ .. list-table:: Storage plugin Tag in the Configuration File :name: RecordTableStoragePluginTag :widths: 20 70 10 :header-rows: 1 * - Tags within - Description - Multiplicity * - - Name/value pairs of properties to pass to a storage plugin. Example: .. code-block:: xml Name Value - 0 or 1 .. _section-record-config-instance-indexing-tag: Instance Indexing ^^^^^^^^^^^^^^^^^ .. list-table:: Instance Indexing Tag in the Configuration File :name: RecordTableInstanceIndexingTag :widths: 20 70 10 :header-rows: 1 * - Tags within - Description - Multiplicity * - - Set this to true to enable instance indexing. It's recommended to enable instance indexing only when *Replay Service* is going to use Instance History Replay mode. You can also perform instance indexing offline, see :numref:`section-indexer-instances`. Default: false. - 0 or 1 * - - The type of timestamp (reception, source or both) to use when building the instance history index. The options are: - ``RECEPTION``: Create the index based on the time the DDS sample was received by the DataReader. - ``SOURCE``: Create the index based on the time the DDS sample was written by the DataWriter. - ``BOTH``: Create the index based on both the source timestamp and the reception timestamp. Default: RECEPTION. - 0 or 1 .. _section-config-domainparticipant-tag: DomainParticipant ----------------- .. list-table:: DomainParticipant Tags in Recording Service's Configuration File :name: TableDomainParticipantTag :widths: 20 70 10 :header-rows: 1 :class: longtable * - Tags within - Description - Multiplicity * - - **Required**. |br| DDS domain ID used for recording. - 1 * - - QoS used by this DomainParticipant. See :link_configuring_qos_xml_up_5:`Configuring QoS with XML, in the RTI Connext DDS Core Libraries User's Manual <>`. - 0..1 * - - Configures certain aspects of how *Connext DDS* allocates internal memory. The configuration is per DomainParticipant and therefore affects all the contained DDS entities. |br| Example: .. code-block:: xml 1024 true Tags within this tag: - : For all DataWriters and DataReaders, the way *Connext DDS* allocates memory for samples is as follows: *Connext DDS* pre-allocates space for samples up to size X in the DataWriter and DataReader queues. If a sample has an actual size greater than X, the memory is allocated dynamically for that sample. The default size is 64KB. This is the maximum amount of pre-allocated memory. Dynamic memory allocation may occur when necessary if samples require a bigger size. - : If set to true, after allocating dynamic memory for very large samples, that memory will be released when possible. If false, that memory will not be released but kept for future samples if needed. The default is false. This feature is useful when a data type has a very high maximum size (e.g., megabytes) but most of the samples sent are much smaller than the maximum possible size (e.g., kilobytes). In this case, the memory footprint is reduced dramatically, while still correctly handling the rare cases in which very large samples are published. - 0..1 * - - Registers a type name and associates it with a type representation. When you define a type in the configuration file, you have to register the type in order to use it in a ````. Attributes: - ``name``: Name that the data type is registered with if no is specified. The same data type may be registered with different names. **Required**. - ``type_ref``: Definition of this data type. It must refer to one of the defined types in the ```` section by specifying the fully qualified name. Tags within this tag: - : Name the data type is registered with. The same data type may be registered with different names. Not required. - 0..* .. _section-config-session-tag: Session ------- The ```` tag configures the threads that will be used to record data. You also specify the Topics and groups of Topics to record inside the ```` tag. .. list-table:: Session Tags in Recording Service's Configuration File :name: TableRecordingSessionTag :widths: 20 70 10 :header-rows: 1 :class: longtable * - Tags within - Description - Multiplicity * - - Specifies the QoS of DDS subscribers that will be used by the contained ```` and ````. See :link_configuring_qos_xml_up_5:`Configuring QoS with XML, in the RTI Connext DDS Core Libraries User's Manual <>`. - 0..1 * - - Defines the number of threads used by this session to process Topics and Topic Groups and allows you to set the mask, priority, and stack size of each thread. This setting can improve the reactiveness and scalability of the running |RECS| when there are multiple Topics and Topic Groups associated with the same session. Example: .. code-block:: xml MASK_DEFAULT THREAD_PRIORITY_DEFAULT THREAD_STACK_SIZE_DEFAULT Default values: - **size**: 1 - **mask**: MASK_DEFAULT - **priority**: THREAD_PRIORITY_DEFAULT - **stack_size**: THREAD_STACK_SIZE_DEFAULT - 0..1 * - - Specifies an individual Topic to record. Attributes: - name: The name of the Topic to record. This name is also used when monitoring and administering each Topic. - participant_ref: A DomainParticipant to use when recording this Topic. If the parent ```` specifies a default_participant_ref, this attribute is optional. See :numref:`section-config-topic-tag`. - 0..* * - - Specifies a group of Topics to record. Attributes: - name: The name of the Topic group. This name is also used when monitoring and administering each Topic group. - participant_ref: Specifies a DomainParticipant to use when recording this topic group. If the parent ```` specifies a default_participant_ref, this attribute is optional. See :numref:`section-config-topicgroup-tag`. - 0..* .. _section-config-topicgroup-tag: Topic Group ----------- You can record a group of Topics, using regular expressions to describe which Topics to record. .. list-table:: Topic Group Tags in Recording Service's Configuration File :name: TableTopicGroupTag :widths: 20 70 10 :header-rows: 1 :class: longtable * - Tags within - Description - Multiplicity * - - A regular expression (fnmatch) describing which Topics are allowed to be recorded. You may use a comma-separated list to specify more than one filter. |br| Example: .. code-block:: xml CONTROL_*,DATA_* - 0..1 * - - A regular expression (fnmatch) describing which Topics are not allowed to be recorded. This tag is applied after the ``allow_topic_name_filter`` tag. You may use a comma-separated list to specify more than one filter. - 0..1 * - - A regular expression (fnmatch) describing the names of data types that are allowed to be recorded. You may use a comma-separated list to specify more than one filter. - 0..1 * - - A regular expression (fnmatch) describing the names of data types that are not allowed to be recorded. This tag is applied after the ``allow_type_name_filter`` tag. You may use a comma-separated list to specify more than one filter. - 0..1 * - - The DataReader's QoS to use when recording data. - 0..1 * - - A ContentFilteredTopic to use when recording data. See :link_xml_cft_config_up_5:`ContentFilteredTopics, in the RTI Connext DDS Core Libraries User's Manual <>`. This allows you to record data samples only if their contents pass a filter that you specify in your configuration. The filter looks like a SQL WHERE clause. Note that XML reserved characters must be converted to their escape values; for example, > and < (greater than and less than signs) must be converted to < and > as shown in the example below. Example: .. code-block:: xml x > 100 - 0..1 .. _section-config-topic-tag: Topic ----- The ```` tag specifies an individual Topic to record. .. list-table:: Topic Tags in Recording Service's Configuration File :name: TableTopicTag :widths: 20 70 10 :header-rows: 1 :class: longtable * - Tags within - Description - Multiplicity * - - The name of the DDS topic to be recorded. If this tag is not present, the name attribute of the `` will be used. |br| *Note*: we recommend using this tag to define the topic name. There may be characters that cause the XML validation to fail if they are part of the topic name attribute. Also, the '/' character and '::' separator may cause Recorder to fail when found in the topic name attribute. - 0..1 * - - **Required**. |br| The name of the data type that will be recorded for this topic. - 1 * - - The transformation library to be applied to this Topic's data when recording. This is a user library that can modify the data after it is received by *Connext DDS* and before it is stored in the database. Transformations implement APIs identical to *Routing Service*'s transformations. For more on using transformations, see these sections in the *RTI Routing Service User's Manual*: - :link_router_manual_config_transformation_up_5:`Data Transformation <>` - :link_router_manual_tutorials_up_5:`Tutorials <>` Attributes: - plugin_name: The name of the plugin to load, qualified by the plugin library name. Example: .. code-block:: xml ModifyTestID_create modify_test_id_library - 0..1 * - - The DataReader QoS to use when recording this data. - 0..1 * - - A ContentFilteredTopic to use when recording data. See :link_xml_cft_config_up_5:`ContentFilteredTopics <>`, in the *RTI Connext DDS Core Libraries User's Manual*. |br| Example of how to set a content filter expression: .. code-block:: xml x > 100 - 0..1 .. _section-Config-EnablingLargedataFeatures: Support for RTI FlatData and Zero Copy Transfer Over Shared Memory ------------------------------------------------------------------ |RECS| supports communication with applications that use RTI FlatData™ and Zero Copy transfer over shared memory. You can configure |RECS| to enable these capabilities for data reception. To enable |RECS| to work with RTI FlatData and Zero-copy transfer over shared memory, you will need to manually define the type in the XML configuration with the proper annotations, and then register this type manually in each |DP|. You can use each of these capabilities separately or together. For further information about these capabilities, see the :link_userman_largedata_up_5:`Sending Large Data <>` section in the |RTI_CONNEXT| *User's Manual*. Example: Configuration to enable both FlatData and Zero Copy transfer over shared memory ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ .. code-block:: xml shmem:// SHMEM 0 Point .. _section-Record-Config-Plugins: Plugins ------- All the pluggable components specific to |RECS| are configured within the ```` tag. :numref:`TableRecordPluginLibraryTag` describes the available tags. Plug-ins are categorized and configured based on the source language. |RECS| supports C/C++ plug-ins. .. list-table:: Configuration tags for plug-in libraries :name: TableRecordPluginLibraryTag :widths: 30 60 10 :header-rows: 1 :class: longtable * - Tags within - Description - Multiplicity * - - Specifies a C/C++ *Storage* plug-in. |br| See :numref:`TableNativePluginTag` and :numref:`section-record-config-storage-tag`. - 0..* * - - Specifies a C/C++ |TRANSF| plug-in. |br| See :numref:`TableNativePluginTag` and :numref:`section-config-topic-tag`. - 0..* .. _section-config-enabling-distributed-logger: Enabling Distributed Logger --------------------------- *Distributed Logger* is included in *Connext DDS* but it is not supported on all platforms; see the *RTI Connext DDS Core Libraries Platform Notes* for the set of platforms that support *Distributed Logger*. When you enable *Distributed Logger*, the Service will publish its log messages to *Connext DDS*. Then you can use *RTI Admin Console* to visualize the log message data. Since the data is provided in a topic, you can also use *rtiddsspy* or even write your own visualization tool. To enable *Distributed Logger*, use the tag ```` within ````. For example: .. code-block:: xml ... true ... For more details, see :link_distlog_services_up_5:`Enabling Distributed Logger in RTI Services, in the RTI Connext DDS Core Libraries User's Manual <>`. .. _section-builtin-config-recording-service: Recording Service Builtin Configuration Details ----------------------------------------------- The |RECS| builtin configuration specifies: - Recording all non-RTI Topics - In domain 0 - Into a SQLite file named rti_recorder_default.db - In the efficient XCDR format .. code-block:: xml RELIABLE_RELIABILITY_QOS KEEP_ALL_HISTORY_QOS rti_recorder_default dat XCDR_AUTO 0 * rti/*