|
libbmq b6028b29b733bc7541593d2905a5f79a9f0192fc
|
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 <bsla_annotations.h>#include <bslma_allocator.h>#include <bslma_usesbslmaallocator.h>#include <bslmf_nestedtraitdeclaration.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 | |
| namespace | BloombergLP |
| namespace | BloombergLP::bmqpi |
| namespace | 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) |
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:
localhost,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.
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.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 must be specified, in order for queues opened through the session to suspend on unhealthy hosts.