libbmq
a5f8a06ba1d16cb5a65643e1fa7f1a1d6aadef40
|
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) |
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.