libbmq  a5f8a06ba1d16cb5a65643e1fa7f1a1d6aadef40
bmqt_sessionoptions.h File Reference

Provide a value-semantic type to configure session with the broker. More...

#include <bdlt_timeunitratio.h>
#include <bsl_iosfwd.h>
#include <bsl_memory.h>
#include <bsl_string.h>
#include <bslma_allocator.h>
#include <bslma_usesbslmaallocator.h>
#include <bslmf_nestedtraitdeclaration.h>
#include <bsls_annotation.h>
#include <bsls_assert.h>
#include <bsls_timeinterval.h>
#include <bsls_types.h>

Go to the source code of this file.

Classes

class  BloombergLP::bmqt::SessionOptions
 

Namespaces

 BloombergLP
 
 BloombergLP::bmqpi
 
 BloombergLP::bmqt
 

Functions

bool BloombergLP::bmqt::operator== (const SessionOptions &lhs, const SessionOptions &rhs)
 
bool BloombergLP::bmqt::operator!= (const SessionOptions &lhs, const SessionOptions &rhs)
 
bsl::ostream & BloombergLP::bmqt::operator<< (bsl::ostream &stream, const SessionOptions &rhs)
 

Detailed Description

bmqt::SessionOptions provides a value-semantic type, SessionOptions, which is used to specify session-level configuration parameters.

Most applications should not need to change the parameters for creating a bmqa::Session; the default parameters are fine.

The following parameters are supported:

  • brokerUri: Address of the broker to connect to. Default is to connect to the broker on the local host on the default port (30114). The format is tcp://<host>:port. Host can be:

    • an explicit hostname or localhost,
    • an IP, example 10.11.12.13, or
    • a DNS entry. In this case, the client will resolve the list of addresses from that entry, and try to connect to one of them. When the connection with the host goes down, it will automatically immediately failover and reconnects to another entry from the address list.

    If the environment variable BMQ_BROKER_URI is set, then instances of bmqa::Session will ignore the brokerUri field from the provided bmqt::SessionOptions and use the value from this environment variable instead.

  • processNameOverride: If not empty, use this value for the processName in the identity message (useful for scripted language bindings). This field is used in the broker's logs to more easily identify the client's process.
  • numProcessingThreads: Number of threads to use for processing events. Default is 1. Note that this setting has an effect only if providing a bmqa::SessionEventHandler to the session.
  • blobBufferSize: Size (in bytes) of the blob buffers to use. Default value is 4k.
  • channelHighWatermark: Size (in bytes) to use for write cache high watermark on the channel. Default value is 128MB. This value is set on the writeCacheHiWatermark of the btemt_ChannelPoolConfiguration object used by the session with the broker. Note that BlazingMQ reserves 4MB of this value for control message, so the actual watermark for data published is channelHighWatermark - 4MB.
  • statsDumpInterval: Interval (in seconds) at which to dump stats in the logs. Set to 0 to disable recurring dump of stats (final stats are always dumped at end of session). Default is 5min. The value must be a multiple of 30s, in the range [0s - 60min].
  • connectTimeout, disconnectTimeout, openQueueTimeout, configureQueueTimeout, closeQueueTimeout: Default timeout to use for various operations.
  • eventQueueLowWatermark, eventQueueHighWatermark: Parameters to configure the EventQueue notification watermarks thresholds. The EventQueue is the buffer of all incoming events from the broker (PUSH and ACK messages as well as session and queue operations result) pending being processed by the application code. A warning (bmqt::SessionEventType::e_SLOWCONSUMER_HIGHWATERMARK) is emitted when the buffer reaches the highWatermark value, and a notification (bmqt::SessionEventType::e_SLOWCONSUMER_NORMAL) is sent when the buffer is back to the lowWatermark. The highWatermark typically would be reached in case of either a very slow consumer, causing events to accumulate in the buffer, or a huge burst of data. Setting the highWatermark to a high value should be done cautiously because it will potentially hide slowness of the consumer because of the enqueuing of PUSH events for a consumer, ACK events for a producer as well as all system events to the buffer (meaning that the messages may have a huge latency). Note, it is also recommended to have a reasonable distance between highWatermark and lowWatermark values to avoid a constant back and forth toggling of state resulting from push pop of events.
  • hostHealthMonitor: Optional instance of a class derived from bmqpi::HostHealthMonitor, responsible for notifying the bmqa::Session when the health of the host machine has changed. A hostHealthMonitor must be specified, in order for queues opened through the session to suspend on unhealthy hosts.
  • traceOptions: Provides the bmqpi::DTContext and bmqpi::DTTracer objects required for integration with a Distributed Trace framework. If these objects are provided, then the session will use them to create "spans" to represent requests made to the BlazingMQ broker on behalf of operations initiated by the client. This includes session-level operations (e.g., Session-Start, Session-Stop) as well as queue-level operations (e.g., Queue-Open, Queue-Configure, Queue-Close).