RTI Connext Traditional C++ API Version 7.7.0
DDS_SystemResourceLimitsQosPolicy Struct Reference

<<extension>> Configures DDSDomainParticipant-independent resources used by RTI Connext. Mainly used to change the maximum number of DDSDomainParticipant entities that can be created within a single process (address space). More...

Public Attributes

DDS_Long max_objects_per_thread
 [DEPRECATED] <<extension>> The maximum number of objects that can be stored per thread for a DDSDomainParticipantFactory. More...
 
DDS_Long initial_objects_per_thread
 <<extension>> The number of objects per thread for a DDSDomainParticipantFactory for which infrastructure will initially be allocated. More...
 
DDS_Boolean cleanup_global_type_resources
 <<extension>> Controls whether global type resources stored in the DDS_TypeCodeFactory are cleaned up when they are no longer needed. More...
 

Detailed Description

<<extension>> Configures DDSDomainParticipant-independent resources used by RTI Connext. Mainly used to change the maximum number of DDSDomainParticipant entities that can be created within a single process (address space).

Entity:
DDSDomainParticipantFactory
Properties:
RxO = N/A
Changeable = NO

Usage

Within a single process (or address space for some supported real-time operating systems), applications may create and use multiple DDSDomainParticipant entities. This QoS policy sets a parameter that places an effective upper bound on the maximum number of DDSDomainParticipant entities that can be created in a single process/address space. These values cannot be changed after a DomainParticipant has been created and they cannot be set in a QoS XML file.

Member Data Documentation

◆ max_objects_per_thread

DDS_Long DDS_SystemResourceLimitsQosPolicy::max_objects_per_thread

[DEPRECATED] <<extension>> The maximum number of objects that can be stored per thread for a DDSDomainParticipantFactory.

This value is the upper bound on the number of objects that can be stored per thread. When a DDSDomainParticipantFactory is created, infrastructure will be created to manage the number of objects specified by initial_objects_per_thread. As more objects are required by the application, the infrastructure will be automatically grown to accommodate up to max_objects_per_thread objects. Leave this property set to the default value to allow the infrastructure to grow as needed. If you wish to strictly control memory allocation, set max_objects_per_thread to a smaller value, but note that this runs the risk of a runtime error and reduced application functionality if your limit is reached.

[default] 261120

[range] [1, 261120]

Categories
Immutable, Middleware Memory Management

◆ initial_objects_per_thread

DDS_Long DDS_SystemResourceLimitsQosPolicy::initial_objects_per_thread

<<extension>> The number of objects per thread for a DDSDomainParticipantFactory for which infrastructure will initially be allocated.

The infrastructure for managing thread-specific objects will initially be sized according to this value. The infrastructure will grow automatically, up to a maximum of max_objects_per_thread, as required by the application at runtime. If you are certain that more than the default value of initial_objects_per_thread will be required for your application and you wish to reduce the number of memory allocations performed while your application reaches steady state, you may set this value to a larger number. To improve the efficiency of memory allocation, RTI Connext may initially size the infrastructure to a larger value than the value of initial_objects_per_thread. The infrastructure will never be sized less than initial_objects_per_thread or greater than max_objects_per_thread. When the infrastructure for managing thread-specific objects is created or increased, a log message stating "Allowed number of thread specific objects is now " will be produced at the local log level.

[default] 1024

[range] [1, 261120]; must be less than or equal to max_objects_per_thread

Categories
Immutable, Middleware Memory Management

◆ cleanup_global_type_resources

DDS_Boolean DDS_SystemResourceLimitsQosPolicy::cleanup_global_type_resources

<<extension>> Controls whether global type resources stored in the DDS_TypeCodeFactory are cleaned up when they are no longer needed.

When set to DDS_BOOLEAN_FALSE (the default), resources stored in the DDS_TypeCodeFactory are kept cached for the lifetime of the factory regardless of usage. Keeping resources cached avoids the cost of re-creating them if they are needed again. Most RTI Connext systems have a finite number of types, so keeping the resources associated with these types does not lead to an unbounded memory growth and is preferable to continuously deleting and re-creating these resources.

When set to DDS_BOOLEAN_TRUE, resources are eligible for removal once all references to them are released, reducing memory usage. You may want to set this QoS to DDS_BOOLEAN_TRUE if your application creates a large number of types and you are more concerned about the resources that are used for types that are not currently active than the performance of re-creating these resources when a type is used again.

The following resources are affected:

  • Dynamic data TypeCodes: When a dynamic type is unregistered from all DDSDomainParticipant entities and all DDS_DynamicData samples of that type are deleted, its TypeCode is removed from the factory. Re-registering the type later requires re-adding the TypeCode to the factory, which will be less efficient than reusing the cached TypeCode. Note: The DDSDynamicDataTypeSupport must be deleted after being unregistered from all DomainParticipants in order for its associated TypeCode to be removed from the factory. See DDSDynamicDataTypeSupport::~DDSDynamicDataTypeSupport.
  • SQL-optimized TypeCodes: When a DDSContentFilteredTopic, DDSTopicQuery, or DDSQueryCondition is deleted or its filter expression is modified, the associated SQL TypeCode is removed from the DDS_TypeCodeFactory once all references are released. Re-creating a filter on the same type requires regenerating the SQL TypeCode and adding it to the factory, which will be less efficient than reusing the cached TypeCode.

[default] FALSE

Categories
Immutable, Middleware Memory Management