54.2.3 Format of Logged Messages

You can control the amount of information in each message with the set_print_format() or set_print_format_by_log_level() operation (see Table 54.4 NDDSConfigLogger Operations). The format options are listed in Table 54.10 Message Formats.

Table 54.10 Message Formats

Message Format

(NDDS_CONFIG_LOG_

PRINT_FORMAT_*)

Description

DEFAULT

(default) Message, method name, log level, activity context (what was happening when the event occurred), and logging category.

TIMESTAMPED

Message, method name, log level, activity context, logging category, and timestamp.

VERBOSE

Message with all available context information (includes thread identifier, message location).

VERBOSE_TIMESTAMPED

Message with all available context information and timestamp.

DEBUG

Information (including message number and backtrace information) for internal debugging by RTI personnel.

MINIMAL

Message number and message location.

MAXIMAL

All available fields.

See also 54.2.3.3 Activity Context and 54.5 Logging a Backtrace for Failures.

By default, NDDS_CONFIG_LOG_PRINT_FORMAT_DEFAULT is assigned to all log levels except FATAL_ERROR. By default, FATAL_ERROR is assigned to NDDS_CONFIG_LOG_PRINT_FORMAT_DEBUG, which prints the backtrace information. See Table 54.2 Message Logging Verbosity Levels.

You could use a less verbose print_format, such as NDDS_CONFIG_LOG_PRINT_FORMAT_MINIMAL, for warnings, as follows:

NDDS_Config_Logger *logger = NDDS_Config_Logger_get_instance();
NDDS_Config_Logger_set_print_format_by_log_level(
    logger,
    NDDS_CONFIG_LOG_PRINT_FORMAT_MINIMAL,
    NDDS_CONFIG_LOG_LEVEL_WARNING));

You could use a more verbose print_format, such as NDDS_CONFIG_LOG_PRINT_FORMAT_DEBUG (which contains the backtrace) when you are troubleshooting errors, as follows:

NDDS_Config_Logger *logger = NDDS_Config_Logger_get_instance();
NDDS_Config_Logger_set_print_format_by_log_level(
    logger,
    NDDS_CONFIG_LOG_PRINT_FORMAT_DEBUG,
    NDDS_CONFIG_LOG_LEVEL_ERROR));

This way, you will reduce the amount of logging on warnings, and errors will contain more information. This configuration is key to understanding and solving issues when needed.

Of course, you are not likely to recognize all of the method names; many of the operations that perform logging are deep within the implementation of Connext. However, in case of errors, logging will typically take place at several points within the call stack; the output thus implies the stack trace at the time the error occurred. You may only recognize the name of the operation that was the last to log its message (i.e., the function that called all the others); however, the entire stack trace is extremely useful to RTI support personnel in the event that you require assistance.

You may notice that many of the logged messages begin with an exclamation point character. This convention indicates an error and is intended to be reminiscent of the negation operator in many programming languages. For example, the message “!create socket” means “cannot create socket.”

54.2.3.1 Timestamps

Reported times are in seconds from a system-dependent starting time; these are equivalent to the output format from Connext. The timestamp is in the form YYYY-MM-DD HH:MM::SS.<microseconds>, where SS is the number of seconds and <microseconds> is a fraction of that second expressed in microseconds. Enabling timestamps will result in some additional overhead for clock access for every message that is logged.

Logging of timestamps is not enabled by default. To enable it, use NDDS_Config_Logger method set_print_format().

54.2.3.2 Thread identification

Thread identification strings uniquely identify active threads when a message is output to the console. A thread may be a user (application) thread or one of several types of internal threads. See Part 11: Connext Threading Model.

Logging of thread IDs is not enabled by default. To enable it, use NDDS_Config_Logger method set_print_format(). It adds the thread name to the log message, so you know which thread is responsible for the message. See Chapter 72 Identifying Threads Used by Connext.

54.2.3.3 Activity Context

Many middleware APIs now store information in thread-specific storage about the activity context operation.

Activity Context provides more context about a logging message. It is a group of resources and activities associated with an action, such as the creation of an entity:

  • A resource is an abstraction of an entity. It can contain attributes such as Topic or domain ID.
  • An activity is a general task that a resource is doing, such as "Getting QoS."

The activity context is one of the NDDS_Config_LogPrintFormat DDS logging infrastructure formats. If a format that prints activity context is selected (see Table 54.10 Message Formats), then every time Connext logs a message, it will contain the contextual information.

For example, in the creation of a DataWriter, the activity context will provide information about:

  • Resource: the Publisher creating the DataWriter. The attributes of the publisher will be GUID, Entity kind, name, and domain ID.
  • Activity: entity creation. It will have two parameters, the Entity kind and the Topic—in the example below, "Writer" and "TestTopic."

The string representation of the above activity context would be:

[0x101A76B,0x79E5D71,0x50EE914:0x80000088{Entity=Pu,Name=TestPublisher,Domain=1}|CREATE Writer WITH TOPIC TestTopic]

In this example, the activity context fields are as follows:

  • GUID is 0x101A76B,0x79E5D71,0x50EE914:0x80000003
    • [0x101A76B,0x79E5D71,0x50EE914:0x80000003{Entity=Pu,Name=TestPublisher,Domain=1}|CREATE Writer WITH TOPIC TestTopic]
  • Entity Name=TestPublisher
    • [0x101A76B,0x79E5D71,0x50EE914:0x80000003 {Entity=Pu,Name=TestPublisher,Domain=1}|CREATE Writer WITH TOPIC TestTopic]
  • Entity kind is Entity=Pu (for Publisher)
    • [0x101A76B,0x79E5D71,0x50EE914:0x80000003 {Entity=Pu,Name=TestPublisher,Domain=1}|CREATE Writer WITH TOPIC TestTopic]
  • Domain ID is Domain=1
    • [0x101A76B,0x79E5D71,0x50EE914:0x80000003 {Entity=Pu,Name=TestPublisher,Domain=1}|CREATE Writer WITH TOPIC TestTopic]
  • Activity is CREATE Writer WITH TOPIC TestTopic
    • [0x101A76B,0x79E5D71,0x50EE914:0x80000003 {Entity=Pu,Name=TestPublisher,Domain=1}|CREATE Writer WITH TOPIC TestTopic]

When a DataWriter writes a sample, the activity context will provide information about:

  • Resource: the DataWriter writing the sample. The attributes of the DataWriter will be GUID, name, Entity kind, Topic, data type, and domain ID.
  • Activity: the writing of a sample.

The string representation of this activity context would be:

[0x101A76B,0x79E5D71,0x50EE914:0x1C1:0x80000003{Name=TestDataWriter,Entity=DW,Topic=test,Type=Foo,Domain=1}|Write]

In this example, the additional activity context fields are as follows:

  • Topic=test 
    • [0x101A76B,0x79E5D71,0x50EE914:0x80000003{Name=testDataWriterName,Entity=DW,Topic=test,Y=Foo,Domain=1}|Write]
  • Data Type=Foo
    • [0x101A76B,0x79E5D71,0x50EE914:0x80000003{Name=testDataWriterName,Entity=DW,Topic=test,Type=Foo,Domain=1}|Write]

When executing an event within the Chapter 66 Event Thread, activity context includes information about the activity the original thread was executing when it posted the event (in addition to any activities the event thread enters). Consider the following example:

WARNING [0xEF4B1953,0x05A7DFA5,0xE557BBB5:0x00000000|ASSERT REMOTE DR|:0x000003C2
{Entity=DW,Topic=DISCPublication,Type=DISCPublicationParameter,Domain=67}|LINK 
0xC974B8F7,0x9597897A,0xE770A8EA:0x000003C7
{Type=DISCPublicationParameter}|LC:Discovery]COMMENDSrWriterService_assertRemoteReader:The remote reader with GUID 0xC974B8F7,0x9597897A,0xE770A8EA:0x000003C7 has no addressable multicast locators.

This message is logged from the Event thread while running into a WARNING during the “LINK” activity. It includes the activity “ASSERT REMOTE DR” from the original thread that posted the event.

54.2.3.3.1 Activity Context Strings and Attributes

The resources of the activity context can have multiple associated attributes. Those attributes provide extra information about the entity such as GUID prefix, Topic, data type (class), Entity kind, Entity name, and domain ID. The following tables describe how those attributes are represented.

Table 54.11 Activity Context Attributes

Attribute

Description

GUID

(given at the beginning of the context, such as: 0x101A76B,0x79E5D71,0x50EE914:0x1C1:0x80000003)

Name

Name of the entity, such as TestPublisher

Entity

Entity kind, such as Pu for Publisher

Domain

Domain ID

Topic

Topic name

Type

Data type

MessageKind

Kind of message: "DATA", "HEARTBEAT", "GAP", or other message kind

Table 54.12 Activity Context Resources and Entities

Entity Kind

Entity Type

DP

DDS_DomainParticipant

Pu

DDS_Publisher

Su

DDS_Subscriber

Topic

DDS_Topic

DW

DDS_<*>DataWriter

DR

DDS_<*>DataReader

Table 54.13 Examples of Activity Context Activities

String

Operation

Entity operations:

ENABLE

Entity::enable

GET QOS

Entity::get_qos

SET QOS

Entity::set_qos

GET LISTENER

Entity::get_listener

SET LISTENER

Entity::set_listener

CALL LISTENER

Entity::call_listener

ASSERT LIVELINESS

Entity::assert_liveliness

GET MATCHED <Pubs/Subs>

Entity::get_matched_<publications/subscriptions/subscription_locators>

Factory operations (DomainParticipantFactory, DomainParticipant, Publisher/Subscriber, DataReader):

CREATE <Entity>

Factory::create_<entity>

DELETE <Entity>

Factory::delete_<entity>

GET_DEFAULT_QOS <Entity>

Factory::get_default_<entity>_qos

SET_DEFAULT_QOS <Entity>

Factory::set_default_<entity>_qos

DELETE CONTAINED

Factory::deleted_contained_entities

Participant-specific operations:

GET PUBS

Participant::get_publishers

GET SUBS

Participant::get_subscribers

LOOKUP Topic(<name>)

Participant::lookup_topicdescription

LOOKUP FlowController(<name>)

Participant::lookup_flowcontroller

IGNORE <Entity>(<host ID>)

Participant::ignore_<entity>
54.2.3.3.2 Configuring Activity Context Attributes

The attributes that NDDS_Config_ActivityContextAttribute uses in the string representation of the activity context can be configured through a mask. This mask indicates what resource attributes are used when Connext logs a message or when the Heap Monitoring utility saves statistics for a memory allocation.

void NDDS_Config_ActivityContext_set_attribute_mask(
        NDDS_Config_ActivityContextAttributeKindMask attribute_mask);
 
enum NDDS_Config_ActivityContextAttributeKind {
  NDDS_CONFIG_ACTIVITY_CONTEXT_ATTRIBUTE_GUID_PREFIX,
  NDDS_CONFIG_ACTIVITY_CONTEXT_ATTRIBUTE_TOPIC,
  NDDS_CONFIG_ACTIVITY_CONTEXT_ATTRIBUTE_TYPE,
  NDDS_CONFIG_ACTIVITY_CONTEXT_ATTRIBUTE_ENTITY_KIND,
  NDDS_CONFIG_ACTIVITY_CONTEXT_ATTRIBUTE_DOMAIN_ID,
  NDDS_CONFIG_ACTIVITY_CONTEXT_ATTRIBUTE_ENTITY_NAME
}
#define NDDS_CONFIG_ACTIVITY_CONTEXT_ATTRIBUTE_MASK_DEFAULT
#define NDDS_CONFIG_ACTIVITY_CONTEXT_ATTRIBUTE_MASK_NONE 
#define NDDS_CONFIG_ACTIVITY_CONTEXT_ATTRIBUTE_MASK_ALL

54.2.3.4 Logging Category

The types of messages logged by Connext fall into the categories listed in Table 54.3 Message Logging Categories; each category can be set to a different verbosity level. A subset of the existing categories can show up as part of the logged message. Table 54.14 Loggable Categories covers the list of logging category strings that can show up as part of logged messages (preceded by "LC:").

Table 54.14 Loggable Categories

String

Category

Discovery

NDDS_CONFIG_LOG_CATEGORY_DISCOVERY

Security

NDDS_CONFIG_LOG_CATEGORY_SECURITY

User

NDDS_CONFIG_LOG_CATEGORY_USER