This QosPolicy defines various settings that configure how DataWriters allocate and use physical memory for internal resources.
It includes the members in DDS_DataWriterResourceLimitsQosPolicy. For defaults and valid ranges, please refer to the API Reference HTML documentation.
|
Type |
Field Name |
Description |
|
DDS_Long |
Initial number of threads that are allowed to concurrently block on the write()call on the same DataWriter. |
|
|
DDS_Long |
Maximum number of threads that are allowed to concurrently block on write() call on the same DataWriter. |
|
|
DDS_Long |
Maximum number of remote DataReaders for which this DataWriter will perform content-based filtering. |
|
|
DDS_Long |
Initial number of batches that a DataWriter will manage if batching is enabled. |
|
|
DDS_Long |
Maximum number of batches that a DataWriter will manage if batching is enabled. When batching is enabled, the maximum number of DDS samples that a DataWriter can store is limited by this value and max_samples in RESOURCE_LIMITS QosPolicy. |
|
|
DDS_DataWriter |
Sets the kinds of instances allowed to be replaced when a DataWriter reaches instance resource limits. (See Configuring DataWriter Instance Replacement |
|
|
DDS_Boolean |
Whether to replace empty instances during instance replacement. (See Configuring DataWriter Instance Replacement |
|
|
DDS_Boolean |
Whether to register automatically instances written with non-NIL handle that are not yet registered, which will otherwise return an error. This can be especially useful if the instance has been replaced. |
|
|
DDS_Long |
Initial number of virtual writers supported by a DataWriter. |
|
|
DDS_Long |
Maximum number of virtual writers supported by a DataWriter. Sets the maximum number of unique virtual writers supported by a DataWriter, where virtual writers are added when DDS samples are written with the virtual writer GUID. This field is especially relevant in the configuration oPersistence Service1Persistence Service is included with the Connext DDS Professional, Evaluation, and Basic package types. It saves DDS data samples so they can be delivered to subscribing applications that join the system at a later time (see Introduction to RTI Persistence Service (Chapter 1 on page 1)). DataWriters, since they publish information on behalf of multiple virtual writers. |
|
|
DDS_Long |
max_remote_readers |
The maximum number of remote readers supported by a DataWriter. |
|
DDS_Long |
max_app_ack_remote_readers |
The maximum number of application-level acknowledging remote readers supported by a DataWriter. |
|
DDS_Long |
initial_active_topic_queries |
Initial number of active topic queries a DataWriter will manage. |
|
DDS_Long |
max_active_topic_queries |
Maximum number of active topic queries a DataWriter will manage. When topic queries are enabled, the maximum number of topic queries that a DataWriter can process at the same time is limited by this value. |
DataWriters must allocate internal structures to handle the simultaneous blocking of threads trying to call write() on the same DataWriter, for the storage used to batch small DDS samples, and for content-based filters specified by DataReaders.
Most of these internal structures start at an initial size and by default, will grow as needed by dynamically allocating additional memory. You may set fixed, maximum sizes for these internal structures if you want to bound the amount of memory that a DataWriter can use. By setting the initial size to the maximum size, you will prevent Connext DDS from dynamically allocating any memory after the creation of the DataWriter.
When setting the fields in this policy, the following rule applies. If this is false, Connext DDS returns DDS_RETCODE_INCONSISTENT_POLICY:
The initial_concurrent_blocking_threads is used to allocate necessary initial system resources. If necessary, it will be increased automatically up to the max_concurrent_blocking_threads limit.
Every user thread calling write() on a DataWriter may use a semaphore that will block the thread when the DataWriter’s send queue is full. Because user code may set a timeout, each thread must use a different semaphore. See the max_blocking_time parameter of the RELIABILITY QosPolicy. This QoS is offered so that the user application can control the dynamic allocation of system resources by Connext DDS.
If you do not mind if Connext DDS dynamically allocates semaphores when needed, then you can set the max_concurrent_blocking_threads parameter to some large value like MAX_INT. However, if you know exactly how many threads will be calling write() on the same DataWriter, and you do not want Connext DDS to allocate any system resources or memory after initialization, then you should set:
max_concurrent_blocking_threads = initial_concurrent_blocking_threads = NUM
(where NUM is the number of threads that could possibly block concurrently).
Each DataWriter can perform content-based data filtering for up to max_remote_reader_filters number of DataReaders.
Values for max_remote_reader_filters may be.
For more information, see ContentFilteredTopics.
If there are multiple threads that can write on the same DataWriter, and the write() operation may block (based on reliability_qos.max_blocking_time and HISTORY settings), you may want to set initial_concurrent_blocking_threads to the most likely number of threads that will block on the same DataWriter at the same time, and set max_concurrent_blocking_threads to the maximum number of threads that could potentially block in the worst case.
This QosPolicy cannot be modified after the DataWriter is created.
Since it is only for DataWriters, there are no compatibility restrictions for how it is set on the publishing and subscribing sides.
Increasing the values in this QosPolicy will cause more memory usage and more system resource usage.
© 2018 RTI