diff --git a/.github/workflows/build.yaml b/.github/workflows/build.yaml
index 044c8702b..4b5a4ca5e 100644
--- a/.github/workflows/build.yaml
+++ b/.github/workflows/build.yaml
@@ -352,6 +352,9 @@ jobs:
run: |
sudo apt-get update
sudo apt-get install -qy doxygen
+ - name: Set up output directory
+ run: |
+ mkdir -p docs/docs/apidocs
- name: Build docs
run: |
doxygen Doxyfile
diff --git a/docs/.idea/bmq-docs.iml b/docs/.idea/bmq-docs.iml
deleted file mode 100644
index ff88395d5..000000000
--- a/docs/.idea/bmq-docs.iml
+++ /dev/null
@@ -1,12 +0,0 @@
-
-
-
-
-
-
-
-
-
-
-
-
\ No newline at end of file
diff --git a/docs/.idea/modules.xml b/docs/.idea/modules.xml
deleted file mode 100644
index a2e275122..000000000
--- a/docs/.idea/modules.xml
+++ /dev/null
@@ -1,8 +0,0 @@
-
-
-
-
-
-
-
-
\ No newline at end of file
diff --git a/docs/.idea/vcs.xml b/docs/.idea/vcs.xml
deleted file mode 100644
index 9661ac713..000000000
--- a/docs/.idea/vcs.xml
+++ /dev/null
@@ -1,6 +0,0 @@
-
-
-
-
-
-
\ No newline at end of file
diff --git a/docs/404.html b/docs/404.html
deleted file mode 100644
index a2d250a53..000000000
--- a/docs/404.html
+++ /dev/null
@@ -1,11 +0,0 @@
----
-layout: default
-title: 404
-permalink: /404
-nav_exclude: true
-search_exclude: true
----
-
-
Page not found
-
-
The page you requested could not be found. Try using the navigation {% if site.search_enabled != false %}or search {% endif %}to find what you're looking for or go to this site's home page.
- BlazingMQ is a distributed message queueing platform with focus on
- efficiency, reliability and a rich feature set for modern day
- workflows.
-
-
- Carefully architected and written in C++ from the ground up with no
- runtime dependency on any external framework (e.g., Apache ZooKeeper),
- BlazingMQ provides consistently low median and p99 latency.
-
-
- With its unique multi-hop network topology, BlazingMQ can lead to
- significant savings in network bandwidth and latency for high fan-out
- workflows.
-
`.
-
-Apart from avoiding HTML validation errors, the fix allows the use of
-the [Jekyll layout for compressing HTML](http://jch.penibelst.de),
-which relies on `pre` tags not being nested, according to
-https://github.com/penibelst/jekyll-compress-html/issues/71#issuecomment-172069842
-
-USAGE
-
-(Any names can be used for `some_var` and `some_language`.)
-
-{% capture some_var %}
-{% highlight some_language linenos %}
-Some code
-{% endhighlight %}
-{% endcapture %}
-{% include fix_linenos.html code=some_var %}
-
-For code fences:
-
-{% capture some_var %}
-```some_language
-Some code
-```
-{% endcapture %}
-{% assign some_var = some_var | markdownify %}
-{% include fix_linenos.html code=some_var %}
-
-CAVEATS
-
-The above does not work when `Some code` happens to contain the matched string
-`
`.
-
-The use of this file overwrites the variable `fix_linenos_code` with `nil`.
-
-{%- endcomment -%}
-
-{% assign fix_linenos_code = include.code %}
-{% if fix_linenos_code contains '
-{%- endif -%}
diff --git a/docs/_includes/head.html b/docs/_includes/head.html
deleted file mode 100644
index 9f38d0f4b..000000000
--- a/docs/_includes/head.html
+++ /dev/null
@@ -1,50 +0,0 @@
-
-
-
-
-
-
- {% if site.ga_tracking != nil %}
- {% assign ga_tracking_ids = site.ga_tracking | split: "," %}
-
-
- {% endif %}
-
- {% if site.search_enabled != false %}
-
- {% endif %}
-
- {% if site.mermaid %}
- {% if site.mermaid.path %}
-
- {% else %}
-
- {% endif %}
- {% endif %}
-
-
-
-
-
- {% for file in site.static_files %}
- {% if file.path == site.favicon_ico or file.path == '/favicon.ico' %}
- {% assign favicon = true %}
- {% endif %}
- {% endfor %}
- {% if favicon %}
-
- {% endif %}
-
- {% seo %}
-
- {% include head_custom.html %}
-
-
diff --git a/docs/_includes/head_custom.html b/docs/_includes/head_custom.html
deleted file mode 100644
index e69de29bb..000000000
diff --git a/docs/_includes/header_custom.html b/docs/_includes/header_custom.html
deleted file mode 100644
index e69de29bb..000000000
diff --git a/docs/_includes/icons/code_copy.html b/docs/_includes/icons/code_copy.html
deleted file mode 100644
index fb6421ff4..000000000
--- a/docs/_includes/icons/code_copy.html
+++ /dev/null
@@ -1,15 +0,0 @@
-
-
- Copy
-
-
-
- Copied
-
-
diff --git a/docs/_includes/icons/document.html b/docs/_includes/icons/document.html
deleted file mode 100644
index c09e8a5c8..000000000
--- a/docs/_includes/icons/document.html
+++ /dev/null
@@ -1,6 +0,0 @@
-
- Document
-
-
diff --git a/docs/_includes/icons/expand.html b/docs/_includes/icons/expand.html
deleted file mode 100644
index 79921a560..000000000
--- a/docs/_includes/icons/expand.html
+++ /dev/null
@@ -1,6 +0,0 @@
-
- Expand
-
-
diff --git a/docs/_includes/icons/external_link.html b/docs/_includes/icons/external_link.html
deleted file mode 100644
index 1592be661..000000000
--- a/docs/_includes/icons/external_link.html
+++ /dev/null
@@ -1,5 +0,0 @@
-
-
- (external link)
-
-
diff --git a/docs/_includes/icons/icons.html b/docs/_includes/icons/icons.html
deleted file mode 100644
index 007a495b0..000000000
--- a/docs/_includes/icons/icons.html
+++ /dev/null
@@ -1,13 +0,0 @@
-
diff --git a/docs/_includes/icons/link.html b/docs/_includes/icons/link.html
deleted file mode 100644
index de24be707..000000000
--- a/docs/_includes/icons/link.html
+++ /dev/null
@@ -1,6 +0,0 @@
-
- Link
-
-
diff --git a/docs/_includes/icons/menu.html b/docs/_includes/icons/menu.html
deleted file mode 100644
index d2565758f..000000000
--- a/docs/_includes/icons/menu.html
+++ /dev/null
@@ -1,6 +0,0 @@
-
- Menu
-
-
diff --git a/docs/_includes/icons/search.html b/docs/_includes/icons/search.html
deleted file mode 100644
index 8f72c6a2a..000000000
--- a/docs/_includes/icons/search.html
+++ /dev/null
@@ -1,6 +0,0 @@
-
- Search
-
-
diff --git a/docs/_includes/js/custom.js b/docs/_includes/js/custom.js
deleted file mode 100644
index e69de29bb..000000000
diff --git a/docs/_includes/lunr/custom-data.json b/docs/_includes/lunr/custom-data.json
deleted file mode 100644
index e69de29bb..000000000
diff --git a/docs/_includes/lunr/custom-index.js b/docs/_includes/lunr/custom-index.js
deleted file mode 100644
index e69de29bb..000000000
diff --git a/docs/_includes/mermaid_config.js b/docs/_includes/mermaid_config.js
deleted file mode 100644
index 0967ef424..000000000
--- a/docs/_includes/mermaid_config.js
+++ /dev/null
@@ -1 +0,0 @@
-{}
diff --git a/docs/_includes/nav.html b/docs/_includes/nav.html
deleted file mode 100644
index 0ba8406b1..000000000
--- a/docs/_includes/nav.html
+++ /dev/null
@@ -1,251 +0,0 @@
-{%- comment -%}
- The `nav_order` values of pages affect the order in which they are shown in
- the navigation panel and in the automatically generated tables of contents.
- Sibling pages with the same `nav_order` value may be shown in any order.
- Sibling pages with no `nav_order` value are shown after all pages that have
- explicit `nav_order` values, ordered by their `title` values.
-
- The `nav_order` and `title` values can be numbers or strings. To avoid build
- failures, we sort numbers and strings separately. We sort numbers by their
- values, and strings lexicographically. The case-sensitivity of string sorting
- is determined by the configuration setting of `nav_sort`. Pages with no `title`
- value are excluded from the navigation.
-
- Note: Numbers used as `title` or `nav_order` values should not be in quotes,
- unless you intend them to be lexicographically ordered. Numbers are written
- without spaces or thousands-separators. Negative numbers are preceded by `-`.
- Floats are written with the integral and fractional parts separated by `.`.
- (Bounds on the magnitude and precision are presumably the same as in Liquid.)
-{%- endcomment -%}
-
-{%- assign title_pages = include.pages
- | where_exp: "item", "item.title != nil" -%}
-
-{%- comment -%}
- A page with `nav_exclude: true` does not appear in the main navigation.
- If it has a `parent`, it may appear in the parent's table of contents.
- If it specifies `has_children: true`, it should appear in the breadcrumbs
- of the child pages, but its order in relation to other pages is irrelevant.
- Pages that never appear can be removed from the pages that need to be sorted.
- This optimisation can be significant on a site with many pages.
-
- In Jekyll 4, the pages to be sorted can be filtered by:
-
- {%- assign title_pages = title_pages
- | where_exp: "item", "item.nav_exclude != true or item.parent != nil" -%}
-
- That filter is not allowed in Jekyll 3. The following iterative code gives the
- same effect, but it is activated only when it will filter more than 50% of the
- pages.
-{%- endcomment -%}
-
-{%- unless title_pages == empty -%}
- {%- assign unsorted_pages = title_pages
- | where_exp: "item", "item.parent == nil"
- | where_exp: "item", "item.nav_exclude == true" -%}
- {%- assign title_pages_size = title_pages.size -%}
- {%- assign unsorted_pages_percent = unsorted_pages.size
- | times: 100 | divided_by: title_pages_size -%}
- {%- if unsorted_pages_percent > 50 -%}
- {%- assign sorted_pages = "" | split: "" -%}
- {%- for item in title_pages -%}
- {%- if item.nav_exclude != true or item.parent -%}
- {%- assign sorted_pages = sorted_pages | push: item -%}
- {%- endif -%}
- {%- endfor -%}
- {%- assign title_pages = sorted_pages -%}
- {%- endif -%}
-{%- endunless -%}
-
-{%- assign nav_order_pages = title_pages
- | where_exp: "item", "item.nav_order != nil" -%}
-{%- assign title_order_pages = title_pages
- | where_exp: "item", "item.nav_order == nil" -%}
-
-{%- comment -%}
- Divide the arrays of `nav_order_pages` and `title_order_pages` according to
- the type of value.
-
- The first character of the result of `jsonify` is `"` only for strings.
- Grouping by a single character also ensures the number of groups is small.
-{%- endcomment -%}
-
-{%- assign nav_number_pages = "" | split: "" -%}
-{%- assign nav_string_pages = "" | split: "" -%}
-{%- assign nav_order_groups = nav_order_pages
- | group_by_exp: "item", "item.nav_order | jsonify | slice: 0" -%}
-{%- for group in nav_order_groups -%}
- {%- if group.name == '"' -%}
- {%- assign nav_string_pages = group.items -%}
- {%- else -%}
- {%- assign nav_number_pages = nav_number_pages | concat: group.items -%}
- {%- endif -%}
-{%- endfor -%}
-
-{%- unless nav_number_pages == empty -%}
- {%- assign nav_number_pages = nav_number_pages | sort: "nav_order" -%}
-{%- endunless -%}
-
-{%- unless nav_string_pages == empty -%}
- {%- if site.nav_sort == 'case_insensitive' -%}
- {%- assign nav_string_pages = nav_string_pages | sort_natural: "nav_order" -%}
- {%- else -%}
- {%- assign nav_string_pages = nav_string_pages | sort: "nav_order" -%}
- {%- endif -%}
-{%- endunless -%}
-
-{%- assign title_number_pages = "" | split: "" -%}
-{%- assign title_string_pages = "" | split: "" -%}
-{%- assign title_order_groups = title_order_pages
- | group_by_exp: "item", "item.title | jsonify | slice: 0" -%}
-{%- for group in title_order_groups -%}
- {%- if group.name == '"' -%}
- {%- assign title_string_pages = group.items -%}
- {%- else -%}
- {%- assign title_number_pages = title_number_pages | concat: group.items -%}
- {%- endif -%}
-{%- endfor -%}
-
-{%- unless title_number_pages == empty -%}
- {%- assign title_number_pages = title_number_pages | sort: "title" -%}
-{%- endunless -%}
-
-{%- unless title_string_pages == empty -%}
- {%- if site.nav_sort == 'case_insensitive' -%}
- {%- assign title_string_pages = title_string_pages | sort_natural: "title" -%}
- {%- else -%}
- {%- assign title_string_pages = title_string_pages | sort: "title" -%}
- {%- endif -%}
-{%- endunless -%}
-
-{%- assign pages_list = nav_number_pages | concat: nav_string_pages
- | concat: title_number_pages | concat: title_string_pages -%}
-
-{%- assign first_level_pages = pages_list
- | where_exp: "item", "item.parent == nil" -%}
-{%- assign second_level_pages = pages_list
- | where_exp: "item", "item.parent != nil"
- | where_exp: "item", "item.grand_parent == nil" -%}
-{%- assign third_level_pages = pages_list
- | where_exp: "item", "item.grand_parent != nil" -%}
-
-{%- comment -%}
- The order of sibling pages in `pages_list` determines the order of display of
- links to them in lists of navigation links and in auto-generated TOCs.
-
- Note that Liquid evaluates conditions from right to left (and it does not allow
- the use of parentheses). Some conditions are not so easy to express clearly...
-
- For example, consider the following condition:
-
- C: page.collection = = include.key and
- page.url = = node.url or
- page.grand_parent = = node.title or
- page.parent = = node.title and
- page.grand_parent = = nil
-
- Here, `node` is a first-level page. The last part of the condition
- -- namely: `page.parent = = node.title and page.grand_parent = = nil` --
- is evaluated first; it holds if and only if `page` is a child of `node`.
-
- The condition `page.grand_parent = = node.title or ...` holds when
- `page` is a grandchild of node, OR `...` holds.
-
- The condition `page.url = = node.url or ...` holds when
- `page` is `node`, OR `...` holds.
-
- The condition C: `page.collection = = include.key and ...` holds when we are
- generating the nav links for a collection that includes `page`, AND `...` holds.
-{%- endcomment -%}
-
-
-{%- for node in first_level_pages -%}
- {%- unless node.nav_exclude -%}
-
-Generated on Thu Jun 15 2023 11:58:50 by
-
- 1.7.1
-
-
diff --git a/docs/docs/apidocs/cpp_apidocs/bmq_8h_source.html b/docs/docs/apidocs/cpp_apidocs/bmq_8h_source.html
deleted file mode 100644
index 83ede2414..000000000
--- a/docs/docs/apidocs/cpp_apidocs/bmq_8h_source.html
+++ /dev/null
@@ -1,71 +0,0 @@
-
-
-Bloomberg Development Environment
-
-
- bmq.txt
-
-@PURPOSE: Public SDK API for the BlazingMQ framework.
-
-@MNEMONIC: BlazingMQ (bmq)
-
-@DESCRIPTION: BlazingmQ (package group 'bmq') is a message-queue
- framework allowing application developers to use reliable distributed queues.
-
- The 'bmqa' and 'bmqt' packages contain all components that constitute the
- public API for BlazingmQ users to use. A client should only use the
- components in these packages, and should not use any other package under the
- 'bmq' package group since they are implementation components that may change
- at any time.
-
-/Hierarchical Synopsis
-/---------------------
-The 'bmq' group library currently has 5 packages forming 5 levels of physical
-dependency.
-..
- 5. bmqa
-
- 4. bmqimp
-
- 3. bmqp
-
- 2. bmqt
-
- 1. bmqscm
-..
-
-/Package Synopsis
-/------------------
-: 'bmqa':
-: Provide applications public API for the BlazingmQ SDK.
-:
-: 'bmqimp':
-: [INTERNAL] Provide implementation for the API of the BlazingMQ SDK.
-:
-: 'bmqp':
-: [INTERNAL] Provide BlazingMQ protocol definition, builders and parsers.
-:
-: 'bmqscm':
-: Provide versioning information for library components in 'bmq'.
-:
-: 'bmqt':
-: Provide value-semantic vocabulary types.
-
-/Package Overview
-/----------------
- The following provides a brief overview of several of the packages within the
- 'bmq' package group, arranged in alphabetical order. The descriptions here
- are still very brief; see the respective Package Level documents for more
- details and usage examples.
-
-/'bmqa'
-/- - -
- 'bmqa' provides the top-level public APIs application can use to interact with
- BlazingMQ framework in their applications.
-
-/'bmqt'
-/- - -
- 'bmqt' provides value-semantic vocabulary types used in the {'bmqa'} APIs.
-
-Generated on Thu Jun 15 2023 11:58:50 by
-
- 1.7.1
-
-
diff --git a/docs/docs/apidocs/cpp_apidocs/bmqa_8h_source.html b/docs/docs/apidocs/cpp_apidocs/bmqa_8h_source.html
deleted file mode 100644
index 70dea8112..000000000
--- a/docs/docs/apidocs/cpp_apidocs/bmqa_8h_source.html
+++ /dev/null
@@ -1,74 +0,0 @@
-
-
-Bloomberg Development Environment
-
-
- bmqa.txt
-
-@PURPOSE: Provide applications public API for the BlazingMQ SDK.
-
-@MNEMONIC: BlazingMQ API (bmqa)
-
-@DESCRIPTION: The 'bmqa' package provides the public API of the BlazingMQ SDK
- for applications to use.
-
-/Hierarchical Synopsis
-/---------------------
-The 'bmqa' package currently has 8 components having 6 levels of physical
-dependency. The list below shows the hierarchical ordering of the components.
-..
- 6. bmqa_session
-
- 5. bmqa_event
- bmqa_messageeventbuilder
-
- 4. bmqa_messageevent
-
- 3. bmqa_messageiterator
-
- 2. bmqa_message
- bmqa_openqueuestatus
- bmqa_closequeuestatus
- bmqa_configurequeuestatus
- bmqa_sessionevent
-
- 1. bmqa_queueid
-..
-
-/Component Synopsis
-/------------------
-: 'bmqa_event':
-: Provide a generic variant encompassing all types of events.
-:
-: 'bmqa_message':
-: Provide the application with a message data object.
-:
-: 'bmqa_messageevent':
-: Provide the application with data event notifications.
-:
-: 'bmqa_messageeventbuilder':
-: Provide a builder for 'MessageEvent' objects.
-:
-: 'bmqa_messageiterator':
-: Provide a mechanism to iterate over the messages of a MessageEvent.
-:
-: 'bmqa_openqueuestatus':
-: Provide value-semantic type for an open queue operation
-:
-: 'bmqa_closequeuestatus':
-: Provide value-semantic type for a close queue operation
-:
-: 'bmqa_configurequeuestatus':
-: Provide value-semantic type for a configure queue operation
-:
-: 'bmqa_queueid':
-: Provide a value-semantic efficient identifier for a queue.
-:
-: 'bmqa_session':
-: Provide access to the BlazingMQ broker.
-:
-: 'bmqa_sessionevent':
-: Provide value-semantic type for system event session notifications.
-
-Generated on Thu Jun 15 2023 11:58:50 by
-
- 1.7.1
-
-
diff --git a/docs/docs/apidocs/cpp_apidocs/bmqa__abstractsession_8h_source.html b/docs/docs/apidocs/cpp_apidocs/bmqa__abstractsession_8h_source.html
deleted file mode 100644
index 08c4ea996..000000000
--- a/docs/docs/apidocs/cpp_apidocs/bmqa__abstractsession_8h_source.html
+++ /dev/null
@@ -1,475 +0,0 @@
-
-
-Bloomberg Development Environment
-
-
-// Copyright 2016-2023 Bloomberg Finance L.P.
-// SPDX-License-Identifier: Apache-2.0
-//
-// Licensed under the Apache License, Version 2.0 (the "License");
-// you may not use this file except in compliance with the License.
-// You may obtain a copy of the License at
-//
-// http://www.apache.org/licenses/LICENSE-2.0
-//
-// Unless required by applicable law or agreed to in writing, software
-// distributed under the License is distributed on an "AS IS" BASIS,
-// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-// See the License for the specific language governing permissions and
-// limitations under the License.
-
-// bmqa_abstractsession.h -*-C++-*-
-#ifndef INCLUDED_BMQA_ABSTRACTSESSION
-#define INCLUDED_BMQA_ABSTRACTSESSION
-
-//@PURPOSE: Provide a pure protocol for a BlazingMQ session.
-//
-//@CLASSES:
-// bmqa::AbstractSession: Interface for a BlazingMQ session.
-//
-//@DESCRIPTION:
-// 'bmqa::AbstractSession' is a pure protocol for a BlazingMQ session.
-
-
-// BMQ
-#include <bmqscm_version.h>
-#include <bmqa_closequeuestatus.h>
-#include <bmqa_configurequeuestatus.h>
-#include <bmqa_confirmeventbuilder.h>
-#include <bmqa_event.h>
-#include <bmqa_messageeventbuilder.h>
-#include <bmqa_messageproperties.h>
-#include <bmqa_openqueuestatus.h>
-#include <bmqa_queueid.h>
-#include <bmqt_queueoptions.h>
-#include <bmqt_uri.h>
-
-// BDE
-#include <bsl_functional.h>
-#include <bsls_timeinterval.h>
-#include <bsls_types.h>
-
-namespace BloombergLP {
-namespace bmqa {
-
- // =====================
- // class AbstractSession
- // =====================
-
-class AbstractSession {
- // A pure protocol for a session.
-
- public:
- // TYPES
- typedef bsl::function<void(const bmqa::OpenQueueStatus& result)>
- OpenQueueCallback;
- // Invoked as a response to an asynchronous open queue operation,
- // 'OpenQueueCallback' is an alias for a callback function object
- // (functor) that takes as an argument the specified 'result',
- // providing the result and context of the requested operation.
-
- typedef bsl::function<void(const bmqa::ConfigureQueueStatus& result)>
- ConfigureQueueCallback;
- // Invoked as a response to an asynchronous configure queue operation,
- // 'ConfigureQueueCallback' is an alias for a callback function object
- // (functor) that takes as an argument the specified 'result',
- // providing the result and context of the requested operation.
-
- typedef bsl::function<void(const bmqa::CloseQueueStatus& result)>
- CloseQueueCallback;
- // Invoked as a response to an asynchronous close queue operation,
- // 'CloseQueueCallback' is an alias for a callback function object
- // (functor) that takes as an argument the specified 'result',
- // providing the result and context of the requested operation.
-
- public:
- // CREATORS
- virtual
- ~AbstractSession();
- // Destructor
-
- // MANIPULATORS
-
- ///Session management
- ///------------------
- virtual
- int start(const bsls::TimeInterval& timeout = bsls::TimeInterval());
- // Connect to the BlazingMQ broker and start the message processing for
- // this 'Session'. This method blocks until either the 'Session' is
- // connected to the broker, fails to connect, or the operation times
- // out. If the optionally specified 'timeout' is not populated, use
- // the one defined in the session options. Return 0 on success, or a
- // non-zero value corresponding to the 'bmqt::GenericResult::Enum' enum
- // values otherwise. The behavior is undefined if this method is
- // called on an already started 'Session'.
-
- virtual
- int startAsync(const bsls::TimeInterval& timeout = bsls::TimeInterval());
- // Connect to the BlazingMQ broker and start the message processing for
- // this 'Session'. This method returns without blocking. The result
- // of the operation is communicated with a session event. If the
- // optionally specified 'timeout' is not populated, use the one defined
- // in the session options. Return 0 on success (this doesn't imply the
- // session is connected !), or a non-zero value corresponding to the
- // 'bmqt::GenericResult::Enum' enum values otherwise. The behavior is
- // undefined if this method is called on an already started 'Session'.
-
- virtual
- void stop();
- // Gracefully disconnect from the BlazingMQ broker and stop the
- // operation of this 'Session'. This method blocks waiting for all
- // already invoked event handlers to exit and all session-related
- // operations to be finished. No other method but 'start()' may be
- // used after this method returns. This method must *NOT* be called if
- // the session is in synchronous mode (i.e., not using the
- // EventHandler), 'stopAsync()' should be called in this case.
-
- virtual
- void stopAsync();
- // Disconnect from the BlazingMQ broker and stop the operation of this
- // 'Session'. This method returns without blocking and neither enforce
- // nor waits for any already started session-related operation to be
- // finished. No method may be used after this method returns.
-
- virtual
- void finalizeStop();
- // **DEPRECATED**
- //
- // This method is only to be used if the session is in synchronous mode
- // (i.e., not using the EventHandler): it must be called once all
- // threads getting events with 'nextEvent()' have been joined.
-
- virtual
- void loadMessageEventBuilder(MessageEventBuilder *builder);
- // Load into the specified 'builder' an instance of
- // 'bmqa::MessageEventBuilder' that can be used to build message event
- // for posting on this session. The behavior is undefined unless the
- // session has been successfully started and 'builder' is non-null.
- // Note that lifetime of the loaded object is bound by the lifetime of
- // this session instance (i.e., loaded instance cannot outlive this
- // session instance). Also note that the 'MessageEventBuilder' objects
- // are pooled, so this operation is cheap, and 'MessageEventBuilder'
- // can be obtained on demand and kept on the stack.
-
- virtual
- void loadConfirmEventBuilder(ConfirmEventBuilder *builder);
- // Load into the specified 'builder' an instance of
- // 'bmqa::ConfirmEventBuilder' that can be used to build a batch of
- // CONFIRM messages for sending to the broker. The behavior is
- // undefined unless the session has been successfully started and
- // 'builder' is non-null. Note that the lifetime of the loaded object
- // is bound by the lifetime of this session instance (i.e., loaded
- // instance cannot outlive this session instance).
-
- virtual
- void loadMessageProperties(MessageProperties *buffer);
- // Load into the specified 'buffer' an instance of 'MessageProperties'
- // that can be used to specify and associate properties while building
- // a 'bmqa::Message'. The behavior is undefined unless the session has
- // been successfully started and 'buffer' is non-null. Note that
- // lifetime of the loaded object is bound by the lifetime of this
- // session instance (i.e., loaded instance cannot outlive this session
- // instance).
-
- ///Queue management
- ///----------------
- virtual
- int getQueueId(QueueId *queueId,
- const bmqt::Uri& uri) const;
- // Load in the specified 'queueId' the queue corresponding to the
- // specified 'uri' and return 0 if such a queue was found, or leave
- // 'queueId' untouched and return a non-zero value if no queue
- // corresponding to 'uri' is currently open.
-
- virtual
- int getQueueId(QueueId *queueId,
- const bmqt::CorrelationId& correlationId) const;
- // Load in the specified 'queueId' the queue corresponding to the
- // specified 'correlationId' and return 0 if such a queue was found, or
- // leave 'queueId' untouched and return a non-zero value if no queue
- // corresponding to 'correlationId' is currently open.
-
- virtual
- int
- openQueue(QueueId *queueId,
- const bmqt::Uri& uri,
- bsls::Types::Uint64 flags,
- const bmqt::QueueOptions& options = bmqt::QueueOptions(),
- const bsls::TimeInterval& timeout = bsls::TimeInterval());
- // DEPRECATED: Use the 'openQueueSync(QueueId *queueId...)' instead.
- // This method will be marked as
- // 'BSLS_ANNOTATION_DEPRECATED' in future release of
- // libbmq.
-
- virtual
- OpenQueueStatus
- openQueueSync(QueueId *queueId,
- const bmqt::Uri& uri,
- bsls::Types::Uint64 flags,
- const bmqt::QueueOptions& options = bmqt::QueueOptions(),
- const bsls::TimeInterval& timeout = bsls::TimeInterval());
- // Open the queue having the specified 'uri' with the specified 'flags'
- // (a combination of the values defined in 'bmqt::QueueFlags::Enum'),
- // using the specified 'queueId' to correlate events related to that
- // queue. The object 'queueId' referring to is modified, so the
- // 'queueId' represents the actual queue uri, flags and options.
- // Return a result providing the status and context of the operation.
- // Use the optionally specified 'options' to configure some advanced
- // settings. Note that this operation fails if 'queueId' is
- // non-unique. If the optionally specified 'timeout' is not populated,
- // use the one defined in the session options. This operation will
- // block until either success, failure, or timing out happens.
- //
- // THREAD: Note that calling this method from the event processing
- // thread(s) (i.e., from the EventHandler callback, if
- // provided) *WILL* lead to a *DEADLOCK*.
-
- virtual
- int
- openQueueAsync(QueueId *queueId,
- const bmqt::Uri& uri,
- bsls::Types::Uint64 flags,
- const bmqt::QueueOptions& options = bmqt::QueueOptions(),
- const bsls::TimeInterval& timeout = bsls::TimeInterval());
- // DEPRECATED: Use the 'openQueueAsync(...)' with callback flavor
- // instead. This method will be marked as
- // 'BSLS_ANNOTATION_DEPRECATED' in future release of
- // libbmq.
-
- virtual
- void
- openQueueAsync(bmqa::QueueId *queueId,
- const bmqt::Uri& uri,
- bsls::Types::Uint64 flags,
- const OpenQueueCallback& callback,
- const bmqt::QueueOptions& options = bmqt::QueueOptions(),
- const bsls::TimeInterval& timeout = bsls::TimeInterval());
- // Asynchronously open the queue having the specified 'uri' with the
- // specified 'flags' (a combination of the values defined in
- // 'bmqt::QueueFlags::Enum'), using the specified 'queueId' to
- // correlate events related to that queue and the optionally specified
- // 'options' to configure some advanced settings. The object 'queueId'
- // referring to is modified, so the 'queueId' represents the actual
- // queue uri, flags and options. The result of the operation is
- // communicated to the specified 'callback' via a
- // 'bmqa::OpenQueueStatus', providing the status and context of the
- // requested operation. Note that this operation fails if 'queueId' is
- // non-unique. If the optionally specified 'timeout' is not populated,
- // use the one defined in the session options.
- //
- // THREAD: The 'callback' will *ALWAYS* be invoked from the
- // EventHandler thread(s) (or if a SessionEventHandler was not
- // specified, from the thread invoking 'nextEvent').
-
- virtual
- int
- configureQueue(QueueId *queueId,
- const bmqt::QueueOptions& options,
- const bsls::TimeInterval& timeout = bsls::TimeInterval());
- // DEPRECATED: Use the 'configureQueueSync(QueueId *queueId...)
- // instead. This method will be marked as
- // 'BSLS_ANNOTATION_DEPRECATED' in future release of
- // libbmq.
-
- virtual
- ConfigureQueueStatus
- configureQueueSync(
- const QueueId *queueId,
- const bmqt::QueueOptions& options,
- const bsls::TimeInterval& timeout = bsls::TimeInterval());
- // Configure the queue identified by the specified 'queueId' using the
- // specified 'options' and return a result providing the status and
- // context of the operation. Fields from 'options' that have not been
- // explicitly set will not be modified. If the optionally specified
- // 'timeout' is not populated, use the one defined in the session
- // options. This operation returns error if there is a pending
- // configure for the same queue. This operation will block until
- // either success, failure, or timing out happens.
- //
- // THREAD: Note that calling this method from the event processing
- // thread(s) (i.e., from the EventHandler callback, if
- // provided) *WILL* lead to a *DEADLOCK*.
-
- virtual
- int
- configureQueueAsync(
- QueueId *queueId,
- const bmqt::QueueOptions& options,
- const bsls::TimeInterval& timeout = bsls::TimeInterval());
- // DEPRECATED: Use the 'configureQueueAsync(...)' with callback flavor
- // instead. This method will be marked as
- // 'BSLS_ANNOTATION_DEPRECATED' in future release of
- // libbmq.
-
- virtual
- void configureQueueAsync(
- const QueueId *queueId,
- const bmqt::QueueOptions& options,
- const ConfigureQueueCallback& callback,
- const bsls::TimeInterval& timeout = bsls::TimeInterval());
-
- // Asynchronously configure the queue identified by the specified
- // 'queueId' using the specified 'options' to configure some advanced
- // settings. The result of the operation is communicated to the
- // specified 'callback' via a 'bmqa::ConfigureQueueStatus', providing
- // the status and context of the requested operation. If the
- // optionally specified 'timeout' is not populated, use the one defined
- // in the session options.
- //
- // THREAD: The 'callback' will *ALWAYS* be invoked from the
- // EventHandler thread(s) (or if a SessionEventHandler was not
- // specified, from the thread invoking 'nextEvent').
-
- virtual
- int
- closeQueue(QueueId *queueId,
- const bsls::TimeInterval& timeout = bsls::TimeInterval());
- // DEPRECATED: Use the 'closeQueueSync(QueueId *queueId...) instead.
- // This method will be marked as
- // 'BSLS_ANNOTATION_DEPRECATED' in future release of
- // libbmq.
-
- virtual
- CloseQueueStatus
- closeQueueSync(const QueueId *queueId,
- const bsls::TimeInterval& timeout = bsls::TimeInterval());
- // Close the queue identified by the specified 'queueId' and return a
- // result providing the status and context of the operation. If the
- // optionally specified 'timeout' is not populated, use the one defined
- // in the session options. Any outstanding configureQueue request for
- // this 'queueId' will be canceled. This operation will block until
- // either success, failure, or timing out happens. Once this method
- // returns, there is guarantee that no more messages and events for
- // this 'queueId' will be received. Note that successful processing of
- // this request in the broker closes this session's view of the queue;
- // the underlying queue may not be deleted in the broker. When this
- // method returns, the correlationId associated to the queue is
- // cleared.
- //
- // THREAD: Note that calling this method from the event processing
- // thread(s) (i.e., from the EventHandler callback, if
- // provided) *WILL* lead to a *DEADLOCK*.
-
- virtual
- int
- closeQueueAsync(QueueId *queueId,
- const bsls::TimeInterval& timeout = bsls::TimeInterval());
- // DEPRECATED: Use the 'closeQueueAsync(...)' with callback flavor
- // instead. This method will be marked as
- // 'BSLS_ANNOTATION_DEPRECATED' in future release of
- // libbmq.
-
- virtual
- void closeQueueAsync(
- const QueueId *queueId,
- const CloseQueueCallback& callback,
- const bsls::TimeInterval& timeout = bsls::TimeInterval());
- // Asynchronously close the queue identified by the specified
- // 'queueId'. Any outstanding configureQueue requests will be
- // canceled. The result of the operation is communicated to the
- // specified 'callback' via a 'bmqa::CloseQueueStatus', providing the
- // status and context of the operation. If the optionally specified
- // 'timeout' is not populated, use the one defined in the session
- // options. Note that successful processing of this request in the
- // broker closes this session's view of the queue; the underlying queue
- // may not be deleted in the broker. The correlationId associated to
- // the queue remains valid until the 'bmqa::CloseQueueStatus' result
- // has been received and processed by the 'callback', after which it
- // will be cleared and no more messages and events for this 'queueId'
- // will be received.
- //
- // THREAD: The 'callback' will *ALWAYS* be invoked from the
- // EventHandler thread(s) (or if a SessionEventHandler was not
- // specified, from the thread invoking 'nextEvent').
-
- ///Queue manipulation
- ///------------------
- virtual
- Event nextEvent(const bsls::TimeInterval& timeout = bsls::TimeInterval());
- // Return the next available event received for this session. If there
- // is no event available, this method blocks for up to the optionally
- // specified 'timeout' time interval for an event to arrive. An empty
- // time interval for 'timeout' (the default) indicates that the method
- // should not timeout (the method will not return until the next event
- // is available). Return a 'bmqa::SessionEvent' of type
- // 'bmqt::SessionEventType::e_TIMEOUT' if a timeout was specified and
- // that timeout expired before any event was received. Note that this
- // method can only be used if the session is in synchronous mode (ie
- // not using the EventHandler). The behavior is undefined unless the
- // session was started.
-
- virtual
- int post(const MessageEvent& event);
- // Asynchronously post the specified 'event' that must contain one or
- // more 'Messages'. The return value is one of the values defined in
- // the 'bmqt::PostResult::Enum' enum. Return zero on success and a
- // non-zero value otherwise. Note that success implies that SDK has
- // accepted the 'event' and will eventually deliver it to the broker.
- // The behavior is undefined unless the session was started.
-
- virtual
- int confirmMessage(const Message& message);
- // Asynchronously confirm the receipt of the specified 'message'. This
- // indicates that the application is done processing the message and
- // that the broker can safely discard it from the queue according to
- // the retention policy set up for that queue. Return 0 on success,
- // and a non-zero value otherwise. Note that success implies that SDK
- // has accepted the 'message' and will eventually send confirmation
- // notification to the broker.
-
- virtual
- int confirmMessage(const MessageConfirmationCookie& cookie);
- // Asynchronously confirm the receipt of the message with which the
- // specified 'cookie' is associated. This indicates that the
- // application is done processing the message and that the broker can
- // safely discard it from the queue according to the retention policy
- // set up for that queue. Return 0 on success, and a non-zero value
- // otherwise. Note that success implies that SDK has accepted the
- // 'message' and will eventually send confirmation notification to the
- // broker.
-
- virtual
- int confirmMessages(ConfirmEventBuilder *builder);
- // Asynchronously confirm the receipt of the batch of CONFIRM messages
- // contained in the specified 'builder'. This indicates that the
- // application is done processing all of the messages and that the
- // broker can safely discard them from the queue according to the
- // retention policy set up for that queue. Return 0 on success, and a
- // non-zero value otherwise. Note that in case of success, the
- // instance pointed by the 'builder' will be reset. Also note that
- // success implies that SDK has accepted all of the messages in
- // 'builder' and will eventually send confirmation notification to the
- // broker. Behavior is undefined unless 'builder' is non-null.
-
- ///Debugging related
- ///-----------------
- virtual
- int configureMessageDumping(const bslstl::StringRef& command);
- // Configure this session instance to dump messages to the installed
- // logger at 'ball::Severity::INFO' level according to the specified
- // 'command' that should adhere to the following pattern:
- //..
- // IN|OUT ON|OFF|100|10s
- //..
- // where each token has a specific meaning:
- //: o !IN! : incoming ('PUSH' and 'ACK') events
- //: o !OUT! : outgoing ('PUT' and 'CONFIRM') events
- //: o !ON! : turn on message dumping until explicitly turned off
- //: o !OFF! : turn off message dumping
- //: o !100! : turn on message dumping for the next 100 messages
- //: o !10s! : turn on message dumping for the next 10 seconds
- // Note that above, '100' and '10' numerical values are for just for
- // illustration purposes, and application can choose an appropriate
- // value for them. Also note that pattern is case-insensitive. Return
- // zero if 'command' is valid and message dumping has been configured,
- // non-zero value otherwise. The behavior is undefined unless the
- // session has been started.
-};
-
-} // close package namespace
-} // close enterprise namespace
-
-#endif
-
-Generated on Thu Jun 15 2023 11:58:50 by
-
- 1.7.1
-
-
diff --git a/docs/docs/apidocs/cpp_apidocs/bmqa__closequeuestatus_8h_source.html b/docs/docs/apidocs/cpp_apidocs/bmqa__closequeuestatus_8h_source.html
deleted file mode 100644
index 9448f8b94..000000000
--- a/docs/docs/apidocs/cpp_apidocs/bmqa__closequeuestatus_8h_source.html
+++ /dev/null
@@ -1,267 +0,0 @@
-
-
-Bloomberg Development Environment
-
-
-// Copyright 2019-2023 Bloomberg Finance L.P.
-// SPDX-License-Identifier: Apache-2.0
-//
-// Licensed under the Apache License, Version 2.0 (the "License");
-// you may not use this file except in compliance with the License.
-// You may obtain a copy of the License at
-//
-// http://www.apache.org/licenses/LICENSE-2.0
-//
-// Unless required by applicable law or agreed to in writing, software
-// distributed under the License is distributed on an "AS IS" BASIS,
-// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-// See the License for the specific language governing permissions and
-// limitations under the License.
-
-// bmqa_closequeuestatus.h -*-C++-*-
-#ifndef INCLUDED_BMQA_CLOSEQUEUESTATUS
-#define INCLUDED_BMQA_CLOSEQUEUESTATUS
-
-//@PURPOSE: Provide Value-Semantic Type for a close queue operation status
-//
-//@CLASSES:
-// bmqa::CloseQueueStatus: value-semantic type for a closeQueue result
-//
-//@DESCRIPTION: This component provides a specific value-semantic type for the
-// result of a close queue operation with the BlazingMQ broker, providing
-// applications with the result and context of the requested operation.
-//
-// A 'bmqa::CloseQueueStatus' type is composed of 3 attributes:
-//: o !result!: indicates the status of the operation (success,
-//: failure, etc.) as specified in the corresponding
-//: result code enum, 'bmqt::CloseQueueResult::Enum'
-//: o !queueId!: queueId associated with the close queue operation
-//: o !errorDescription!: optional string with a human readable description of
-//: the error, if any
-
-
-// BMQ
-#include <bmqscm_version.h>
-#include <bmqa_queueid.h>
-#include <bmqt_resultcode.h>
-
-// BDE
-#include <bsl_iostream.h>
-#include <bsl_string.h>
-#include <bslma_allocator.h>
-#include <bslma_default.h>
-#include <bslma_usesbslmaallocator.h>
-#include <bslmf_nestedtraitdeclaration.h>
-
-
-namespace BloombergLP {
-namespace bmqa {
-
- // ======================
- // class CloseQueueStatus
- // ======================
-
-class CloseQueueStatus {
- // A value-semantic type for a close queue operation with the message queue
- // broker.
-
- private:
- // DATA
- QueueId d_queueId;
- // queueId associated with the open
- // queue operation
-
- bmqt::CloseQueueResult::Enum d_result;
- // Result code of the operation
- // (success, failure)
-
- bsl::string d_errorDescription;
- // Optional string with a human
- // readable description of the error,
- // if any
-
- public:
- // TRAITS
- BSLMF_NESTED_TRAIT_DECLARATION(CloseQueueStatus, bslma::UsesBslmaAllocator)
-
- // CREATORS
- explicit CloseQueueStatus(bslma::Allocator *allocator = 0);
- // Default constructor, use the optionally specified 'allocator'.
-
- CloseQueueStatus(const bmqa::CloseQueueStatus& other,
- bslma::Allocator *allocator = 0);
- // Create a new 'bmqa::CloseQueueStatus' using the optionally specified
- // 'allocator'.
-
- CloseQueueStatus(const QueueId& queueId,
- bmqt::CloseQueueResult::Enum result,
- const bsl::string& errorDescription,
- bslma::Allocator *allocator = 0);
- // Create a new 'bmqa::CloseQueueStatus' object having the specified
- // 'queueId', 'result', and 'errorDescription', using the
- // optionally specified 'allocator' to supply memory.
-
- // MANIPULATORS
- CloseQueueStatus& operator=(const CloseQueueStatus& rhs);
- // Assign to this 'CloseQueueStatus' the same values as the one from the
- // specified 'rhs'.
-
- // ACCESSORS
- operator bool() const;
- // Return true if this result indicates success, and false otherwise.
-
- const QueueId& queueId() const;
- // Return the queueId associated to this operation result, if any.
-
- bmqt::CloseQueueResult::Enum result() const;
- // Return the status code that indicates success or the cause of a
- // failure.
-
- const bsl::string& errorDescription() const;
- // Return a printable description of the error, if 'result'
- // indicates failure. Return an empty string otherwise.
-
- bsl::ostream& print(bsl::ostream& stream,
- int level = 0,
- int spacesPerLevel = 4) const;
- // Format this object to the specified output 'stream' at the (absolute
- // value of) the optionally specified indentation 'level' and return a
- // reference to 'stream'. If 'level' is specified, optionally specify
- // 'spacesPerLevel', the number of spaces per indentation level for
- // this and all of its nested objects. If 'level' is negative,
- // suppress indentation of the first line. If 'spacesPerLevel' is
- // negative format the entire output on one line, suppressing all but
- // the initial indentation (as governed by 'level'). If 'stream' is
- // not valid on entry, this operation has no effect.
-};
-
-// FREE OPERATORS
-bool operator==(const CloseQueueStatus& lhs, const CloseQueueStatus& rhs);
- // Return 'true' if the specified 'rhs' object contains the value of the
- // same type as contained in the specified 'lhs' object and the value
- // itself is the same in both objects, return false otherwise.
-
-bool operator!=(const CloseQueueStatus& lhs, const CloseQueueStatus& rhs);
- // Return 'false' if the specified 'rhs' object contains the value of the
- // same type as contained in the specified 'lhs' object and the value
- // itself is the same in both objects, return 'true' otherwise.
-
-bsl::ostream& operator<<(bsl::ostream& stream, const CloseQueueStatus& rhs);
- // Format the specified 'rhs' to the specified output 'stream' and return a
- // reference to the modifiable 'stream'.
-
-// ============================================================================
-// INLINE DEFINITIONS
-// ============================================================================
-
- // ----------------------
- // class CloseQueueStatus
- // ----------------------
-
-// CREATORS
-inline
-CloseQueueStatus::CloseQueueStatus(bslma::Allocator *allocator)
-: d_queueId(allocator)
-, d_result(bmqt::CloseQueueResult::e_SUCCESS)
-, d_errorDescription(allocator)
-{
- // NOTHING
-}
-
-inline
-CloseQueueStatus::CloseQueueStatus(const CloseQueueStatus& other,
- bslma::Allocator *allocator)
-: d_queueId(other.d_queueId, allocator)
-, d_result(other.d_result)
-, d_errorDescription(other.d_errorDescription)
-{
- // NOTHING
-}
-
-inline
-CloseQueueStatus::CloseQueueStatus(
- const QueueId& queueId,
- bmqt::CloseQueueResult::Enum result,
- const bsl::string& errorDescription,
- bslma::Allocator *allocator)
-: d_queueId(queueId, allocator)
-, d_result(result)
-, d_errorDescription(errorDescription)
-{
- // NOTHING
-}
-
-// MANIPULATORS
-inline
-CloseQueueStatus&
-CloseQueueStatus::operator=(const CloseQueueStatus& other)
-{
- d_queueId = other.queueId();
- d_result = other.result();
- d_errorDescription = other.errorDescription();
- return *this;
-}
-
-// ACCESSORS
-inline
-CloseQueueStatus::operator bool() const
-{
- return d_result == bmqt::CloseQueueResult::e_SUCCESS;
-}
-
-inline
-const QueueId&
-CloseQueueStatus::queueId() const
-{
- return d_queueId;
-}
-
-inline
-bmqt::CloseQueueResult::Enum
-CloseQueueStatus::result() const
-{
- return d_result;
-}
-
-inline
-const bsl::string&
-CloseQueueStatus::errorDescription() const
-{
- return d_errorDescription;
-}
-
-} // close package namespace
-
-// FREE OPERATORS
-inline
-bsl::ostream&
-bmqa::operator<<(bsl::ostream& stream,
- const bmqa::CloseQueueStatus& rhs)
-{
- return rhs.print(stream, 0, -1);
-}
-
-inline
-bool
-bmqa::operator==(const bmqa::CloseQueueStatus& lhs,
- const bmqa::CloseQueueStatus& rhs)
-{
- return lhs.queueId() == rhs.queueId()
- && lhs.result() == rhs.result()
- && lhs.errorDescription() == rhs.errorDescription();
-}
-
-inline
-bool
-bmqa::operator!=(const bmqa::CloseQueueStatus& lhs,
- const bmqa::CloseQueueStatus& rhs)
-{
- return !(lhs == rhs);
-}
-
-} // close enterprise namespace
-
-#endif
-
-Generated on Thu Jun 15 2023 11:58:50 by
-
- 1.7.1
-
-
diff --git a/docs/docs/apidocs/cpp_apidocs/bmqa__configurequeuestatus_8h_source.html b/docs/docs/apidocs/cpp_apidocs/bmqa__configurequeuestatus_8h_source.html
deleted file mode 100644
index 65ca55d5a..000000000
--- a/docs/docs/apidocs/cpp_apidocs/bmqa__configurequeuestatus_8h_source.html
+++ /dev/null
@@ -1,273 +0,0 @@
-
-
-Bloomberg Development Environment
-
-
-// Copyright 2019-2023 Bloomberg Finance L.P.
-// SPDX-License-Identifier: Apache-2.0
-//
-// Licensed under the Apache License, Version 2.0 (the "License");
-// you may not use this file except in compliance with the License.
-// You may obtain a copy of the License at
-//
-// http://www.apache.org/licenses/LICENSE-2.0
-//
-// Unless required by applicable law or agreed to in writing, software
-// distributed under the License is distributed on an "AS IS" BASIS,
-// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-// See the License for the specific language governing permissions and
-// limitations under the License.
-
-// bmqa_configurequeuestatus.h -*-C++-*-
-#ifndef INCLUDED_BMQA_CONFIGUREQUEUESTATUS
-#define INCLUDED_BMQA_CONFIGUREQUEUESTATUS
-
-//@PURPOSE: Provide Value-Semantic Type for a configure queue operation status
-//
-//@CLASSES:
-// bmqa::ConfigureQueueStatus: value-semantic type for a configureQueue result
-//
-//@DESCRIPTION: This component provides a specific value-semantic type for the
-// result of a configure queue operation with the BlazingMQ broker, providing
-// applications with the result and context of the requested operation.
-//
-// A 'bmqa::ConfigureQueueStatus' type is composed of 3 attributes:
-//: o !result!: indicates the status of the operation (success,
-//: failure, etc.) as specified in the corresponding
-//: result code enum, 'bmqt::ConfigureQueueResult::Enum'
-//: o !queueId!: queueId associated with the configure queue operation
-//: o !errorDescription!: optional string with a human readable description of
-//: the error, if any
-
-
-// BMQ
-#include <bmqscm_version.h>
-#include <bmqa_queueid.h>
-#include <bmqt_resultcode.h>
-
-// BDE
-#include <bsl_iostream.h>
-#include <bsl_string.h>
-#include <bslma_allocator.h>
-#include <bslma_default.h>
-#include <bslma_usesbslmaallocator.h>
-#include <bslmf_nestedtraitdeclaration.h>
-
-
-namespace BloombergLP {
-namespace bmqa {
-
- // ==========================
- // class ConfigureQueueStatus
- // ==========================
-
-class ConfigureQueueStatus {
- // A value-semantic type for a configure queue operation with the message
- // queue broker.
-
- private:
- // DATA
- QueueId d_queueId;
- // queueId associated with the open
- // queue operation
-
- bmqt::ConfigureQueueResult::Enum d_result;
- // Status code of the operation
- // (success, failure)
-
- bsl::string d_errorDescription;
- // Optional string with a human
- // readable description of the error,
- // if any
-
- public:
- // TRAITS
- BSLMF_NESTED_TRAIT_DECLARATION(ConfigureQueueStatus,
- bslma::UsesBslmaAllocator)
-
- // CREATORS
- explicit ConfigureQueueStatus(bslma::Allocator *allocator = 0);
- // Default constructor, use the optionally specified 'allocator'.
-
- ConfigureQueueStatus(const bmqa::ConfigureQueueStatus& other,
- bslma::Allocator *allocator = 0);
- // Create a new 'bmqa::ConfigureQueueStatus' using the optionally
- // specified 'allocator'.
-
- ConfigureQueueStatus(
- const QueueId& queueId,
- bmqt::ConfigureQueueResult::Enum result,
- const bsl::string& errorDescription,
- bslma::Allocator *allocator = 0);
- // Create a new 'bmqa::ConfigureQueueStatus' object having the
- // specified 'queueId', 'result', and 'errorDescription', using the
- // optionally specified 'allocator' to supply memory.
-
- // MANIPULATORS
- ConfigureQueueStatus& operator=(const ConfigureQueueStatus& rhs);
- // Assign to this 'ConfigureQueueStatus' the same values as the one
- // from the specified 'rhs'.
-
- // ACCESSORS
- operator bool() const;
- // Return true if this result indicates success, and false otherwise.
-
- const QueueId& queueId() const;
- // Return the queueId associated to this operation result, if any.
-
- bmqt::ConfigureQueueResult::Enum result() const;
- // Return the result code that indicates success or the cause of a
- // failure.
-
- const bsl::string& errorDescription() const;
- // Return a printable description of the error, if 'result' indicates
- // failure. Return an empty string otherwise.
-
- bsl::ostream& print(bsl::ostream& stream,
- int level = 0,
- int spacesPerLevel = 4) const;
- // Format this object to the specified output 'stream' at the (absolute
- // value of) the optionally specified indentation 'level' and return a
- // reference to 'stream'. If 'level' is specified, optionally specify
- // 'spacesPerLevel', the number of spaces per indentation level for
- // this and all of its nested objects. If 'level' is negative,
- // suppress indentation of the first line. If 'spacesPerLevel' is
- // negative format the entire output on one line, suppressing all but
- // the initial indentation (as governed by 'level'). If 'stream' is
- // not valid on entry, this operation has no effect.
-};
-
-// FREE OPERATORS
-bool
-operator==(const ConfigureQueueStatus& lhs, const ConfigureQueueStatus& rhs);
- // Return 'true' if the specified 'rhs' object contains the value of the
- // same type as contained in the specified 'lhs' object and the value
- // itself is the same in both objects, return false otherwise.
-
-bool
-operator!=(const ConfigureQueueStatus& lhs, const ConfigureQueueStatus& rhs);
- // Return 'false' if the specified 'rhs' object contains the value of the
- // same type as contained in the specified 'lhs' object and the value
- // itself is the same in both objects, return 'true' otherwise.
-
-bsl::ostream&
-operator<<(bsl::ostream& stream, const ConfigureQueueStatus& rhs);
- // Format the specified 'rhs' to the specified output 'stream' and return a
- // reference to the modifiable 'stream'.
-
-// ============================================================================
-// INLINE DEFINITIONS
-// ============================================================================
-
- // --------------------------
- // class ConfigureQueueStatus
- // --------------------------
-
-// CREATORS
-inline
-ConfigureQueueStatus::ConfigureQueueStatus(bslma::Allocator *allocator)
-: d_queueId(allocator)
-, d_result(bmqt::ConfigureQueueResult::e_SUCCESS)
-, d_errorDescription(allocator)
-{
- // NOTHING
-}
-
-inline
-ConfigureQueueStatus::ConfigureQueueStatus(
- const ConfigureQueueStatus& other,
- bslma::Allocator *allocator)
-: d_queueId(other.d_queueId, allocator)
-, d_result(other.d_result)
-, d_errorDescription(other.d_errorDescription)
-{
- // NOTHING
-}
-
-inline
-ConfigureQueueStatus::ConfigureQueueStatus(
- const QueueId& queueId,
- bmqt::ConfigureQueueResult::Enum result,
- const bsl::string& errorDescription,
- bslma::Allocator *allocator)
-: d_queueId(queueId, allocator)
-, d_result(result)
-, d_errorDescription(errorDescription)
-{
- // NOTHING
-}
-
-// MANIPULATORS
-inline
-ConfigureQueueStatus&
-ConfigureQueueStatus::operator=(const ConfigureQueueStatus& other)
-{
- d_queueId = other.queueId();
- d_result = other.result();
- d_errorDescription = other.errorDescription();
- return *this;
-}
-
-// ACCESSORS
-inline
-ConfigureQueueStatus::operator bool() const
-{
- return result() == bmqt::ConfigureQueueResult::e_SUCCESS;
-}
-
-inline
-const QueueId&
-ConfigureQueueStatus::queueId() const
-{
- return d_queueId;
-}
-
-inline
-bmqt::ConfigureQueueResult::Enum
-ConfigureQueueStatus::result() const
-{
- return d_result;
-}
-
-inline
-const bsl::string&
-ConfigureQueueStatus::errorDescription() const
-{
- return d_errorDescription;
-}
-
-} // close package namespace
-
-// FREE OPERATORS
-inline
-bsl::ostream&
-bmqa::operator<<(bsl::ostream& stream,
- const bmqa::ConfigureQueueStatus& rhs)
-{
- return rhs.print(stream, 0, -1);
-}
-
-inline
-bool
-bmqa::operator==(const bmqa::ConfigureQueueStatus& lhs,
- const bmqa::ConfigureQueueStatus& rhs)
-{
- return lhs.queueId() == rhs.queueId()
- && lhs.result() == rhs.result()
- && lhs.errorDescription() == rhs.errorDescription();
-}
-
-inline
-bool
-bmqa::operator!=(const bmqa::ConfigureQueueStatus& lhs,
- const bmqa::ConfigureQueueStatus& rhs)
-{
- return !(lhs == rhs);
-}
-
-} // close enterprise namespace
-
-#endif
-
-Generated on Thu Jun 15 2023 11:58:50 by
-
- 1.7.1
-
-
diff --git a/docs/docs/apidocs/cpp_apidocs/bmqa__confirmeventbuilder_8h_source.html b/docs/docs/apidocs/cpp_apidocs/bmqa__confirmeventbuilder_8h_source.html
deleted file mode 100644
index c6b3da716..000000000
--- a/docs/docs/apidocs/cpp_apidocs/bmqa__confirmeventbuilder_8h_source.html
+++ /dev/null
@@ -1,259 +0,0 @@
-
-
-Bloomberg Development Environment
-
-
-// Copyright 2016-2023 Bloomberg Finance L.P.
-// SPDX-License-Identifier: Apache-2.0
-//
-// Licensed under the Apache License, Version 2.0 (the "License");
-// you may not use this file except in compliance with the License.
-// You may obtain a copy of the License at
-//
-// http://www.apache.org/licenses/LICENSE-2.0
-//
-// Unless required by applicable law or agreed to in writing, software
-// distributed under the License is distributed on an "AS IS" BASIS,
-// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-// See the License for the specific language governing permissions and
-// limitations under the License.
-
-// bmqa_confirmeventbuilder.h -*-C++-*-
-#ifndef INCLUDED_BMQA_CONFIRMEVENTBUILDER
-#define INCLUDED_BMQA_CONFIRMEVENTBUILDER
-
-//@PURPOSE: Provide a builder for batching confirmation messages.
-//
-//@CLASSES:
-// bmqa::ConfirmEventBuilder: builder for batching confirmation messages.
-//
-//@DESCRIPTION: This component implements a mechanism,
-// 'bmqa::ConfirmEventBuilder', that can be used for batching CONFIRM messages.
-// The resulting batch can be sent to the BlazingMQ broker using the
-// 'bmqa::Session' (refer to 'bmqa_session' for details). Wherever possible, a
-// BlazingMQ consumer should try to send a batch of CONFIRM messages, which is
-// more efficient than confirming messages individually.
-//
-// The builder holds a batch of CONFIRM messages under construction, and
-// provides two flavors of 'addMessageConfirmation' method to add a CONFIRM
-// message to the batch. It also provides a routine to retrieve number of
-// CONFIRM messages added to the batch. Once application is done creating the
-// batch, it can retrieve the blob (wire-representation) of the batch and send
-// it via 'bmqa::Session'. See 'Usage' section for more details.
-//
-///Usage
-///-----
-//: o An instance of bmqa::ConfirmEventBuilder (the builder) can be used to
-//: create multiple batches of CONFIRM messages. The recommended approach is
-//: to create one instance of the builder and use it throughout the lifetime
-//: of the task (if the task is multi-threaded, an instance per thread must
-//: be created and maintained). See usage example #1 for an illustration.
-//:
-//: o The lifetime of an instance of the builder is bound by the bmqa::Session
-//: from which it was created. In other words, bmqa::Session instance must
-//: outlive the builder instance.
-//
-///Example 1 - Basic Usage
-///-----------------------
-//..
-// // In this snippet, we will send a batch of CONFIRMs for all the
-// // 'bmqa::Message' messages received in a 'bmqa::MessageEvent'.
-//
-// // Note that error handling is omitted from the snippet for the sake of
-// // brevity.
-//
-// bmqa::Session session;
-// // Session start up logic elided.
-//
-// // Create and load an instance of the ConfirmEventBuilder. Note that in
-// // this example, we are creating the builder on the stack everytime a
-// // message event is received. Another approach can be to maintain the
-// // builder as a data member and use it everytime.
-//
-// bmqa::ConfirmEventBuilder builder;
-// session.loadConfirmEventBuilder(&builder);
-//
-// // Assuming that a 'bmqa::MessageEvent' is received.
-//
-// bmqa::MessageIterator iter = messageEvent.messageIterator();
-// while (iter.nextMessage()) {
-// const bmqa::Message& msg = iter.message();
-//
-// // Business logic for processing 'msg' elided.
-//
-// int rc = builder.addMessageConfirmation(msg);
-// // Error handling elided.
-// }
-//
-// // All messages in the event have been processed and their corresponding
-// // CONFIRM messages have been batched. Now its time to send the batch to
-// // the BlazingMQ broker.
-//
-// int rc = session.confirmMessages(&builder);
-// // Error handling elided. Note that in case of success, above method
-// // will also reset the 'builder'.
-//..
-//
-///Thread Safety
-///-------------
-// This component is *NOT* thread safe. If it is desired to create a batch of
-// CONFIRM messages from multiple threads, an instance of the builder must be
-// created and maintained *per* *thread*.
-
-
-// BMQ
-#include <bmqscm_version.h>
-#include <bmqa_message.h>
-#include <bmqt_resultcode.h>
-
-// BDE
-#include <bdlbb_blob.h>
-#include <bsls_alignedbuffer.h>
-
-namespace BloombergLP {
-
-// FORWARD DECLARATION
-namespace bmqp { class ConfirmEventBuilder; }
-
-namespace bmqa {
-
- // ==============================
- // struct ConfirmEventBuilderImpl
- // ==============================
-
-struct ConfirmEventBuilderImpl {
- // Component-private class. Do not use.
-
- // CONSTANTS
- static const int k_MAX_SIZEOF_BMQP_CONFIRMEVENTBUILDER = 64;
- // Constant representing the maximum size of a
- // 'bmqp::ConfirmEventBuilder' object, so that the below AlignedBuffer
- // is big enough. Note that since this buffer will hold a
- // 'bmqp::ConfirmEventBuilder' which holds a 'bdlbb::Blob' data member,
- // the size is different on 32 vs 64 bits.
-
- // PUBLIC DATA
- // (for convenience)
- bsls::AlignedBuffer<k_MAX_SIZEOF_BMQP_CONFIRMEVENTBUILDER> d_buffer;
-
- bmqp::ConfirmEventBuilder *d_builder_p;
-
- // CREATORS
- ConfirmEventBuilderImpl();
-
- private:
- // NOT IMPLEMENTED
- ConfirmEventBuilderImpl(const ConfirmEventBuilderImpl&); // = delete
- ConfirmEventBuilderImpl&
- operator=(const ConfirmEventBuilderImpl&); // = delete
-};
-
-
- // =========================
- // class ConfirmEventBuilder
- // =========================
-
-class ConfirmEventBuilder {
- // Mechanism to build a batch of CONFIRM messages.
-
- private:
- // DATA
- ConfirmEventBuilderImpl d_impl;
-
- private:
- // NOT IMPLEMENTED
- ConfirmEventBuilder(const ConfirmEventBuilder& other); // = delete
- ConfirmEventBuilder&
- operator=(const ConfirmEventBuilder& rhs); // = delete
- // Copy constructor and assignment operator not implemented
-
- public:
- // CREATORS
- ConfirmEventBuilder();
- // Create an invalid instance. Application should not create
- // 'ConfirmEventBuilder' themselves, but ask the 'bmqa::Session' to
- // give them one, by using 'bmqa::Session::loadConfirmEventBuilder'.
-
- ~ConfirmEventBuilder();
- // Destroy this instance.
-
- // MANIPULATORS
- bmqt::EventBuilderResult::Enum
- addMessageConfirmation(const Message& message);
- // Append a confirmation message for the specified 'message'. Return
- // zero on success, and a non-zero value otherwise. Behavior is
- // undefined unless this instance was obtained using
- // 'bmqa::Session::loadConfirmEventBuilder'.
-
- bmqt::EventBuilderResult::Enum
- addMessageConfirmation(const MessageConfirmationCookie& cookie);
- // Append a confirmation message for the specified
- // MessageConfirmationCookie 'cookie'. Return zero on success, and a
- // non-zero value otherwise. Behavior is undefined unless this
- // instance was obtained using
- // 'bmqa::Session::loadConfirmEventBuilder'.
-
- void reset();
- // Reset the builder, effectively discarding the batch of confirmation
- // messages under construction.
-
- // ACCESSORS
- int messageCount() const;
- // Return the number of messages currently in the ConfirmEvent being
- // built. Behavior is undefined unless this instance was obtained
- // using 'bmqa::Session::loadConfirmEventBuilder'.
-
- const bdlbb::Blob& blob() const;
- // Return a reference not offering modifiable access to the blob of
- // confirmation messages batch built by this builder. If no messages
- // were added, this will return an empty blob, i.e., a blob with
- // 'length == 0'. Behavior is undefined unless this instance was
- // obtained using 'bmqa::Session::loadConfirmEventBuilder'.
-};
-
-
-// ============================================================================
-// INLINE DEFINITIONS
-// ============================================================================
-
- // ------------------------------
- // struct ConfirmEventBuilderImpl
- // ------------------------------
-
-// CREATORS
-inline
-ConfirmEventBuilderImpl::ConfirmEventBuilderImpl()
-: d_buffer()
-, d_builder_p(0)
-{
- // NOTHING
-}
-
-
- // -------------------------
- // class ConfirmEventBuilder
- // -------------------------
-
-// CREATORS
-inline
-ConfirmEventBuilder::ConfirmEventBuilder()
-: d_impl()
-{
- // NOTHING
-}
-
-// MANIPULATORS
-inline
-bmqt::EventBuilderResult::Enum
-ConfirmEventBuilder::addMessageConfirmation(const Message& message)
-{
- return addMessageConfirmation(message.confirmationCookie());
-}
-
-} // close package namespace
-} // close enterprise namespace
-
-#endif
-
-Generated on Thu Jun 15 2023 11:58:50 by
-
- 1.7.1
-
-
diff --git a/docs/docs/apidocs/cpp_apidocs/bmqa__event_8h_source.html b/docs/docs/apidocs/cpp_apidocs/bmqa__event_8h_source.html
deleted file mode 100644
index 2eef08dc7..000000000
--- a/docs/docs/apidocs/cpp_apidocs/bmqa__event_8h_source.html
+++ /dev/null
@@ -1,148 +0,0 @@
-
-
-Bloomberg Development Environment
-
-
-// Copyright 2014-2023 Bloomberg Finance L.P.
-// SPDX-License-Identifier: Apache-2.0
-//
-// Licensed under the Apache License, Version 2.0 (the "License");
-// you may not use this file except in compliance with the License.
-// You may obtain a copy of the License at
-//
-// http://www.apache.org/licenses/LICENSE-2.0
-//
-// Unless required by applicable law or agreed to in writing, software
-// distributed under the License is distributed on an "AS IS" BASIS,
-// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-// See the License for the specific language governing permissions and
-// limitations under the License.
-
-// bmqa_event.h -*-C++-*-
-#ifndef INCLUDED_BMQA_EVENT
-#define INCLUDED_BMQA_EVENT
-
-//@PURPOSE: Provide a generic variant encompassing all types of events.
-//
-//@CLASSES:
-// bmqa::Event: variant encompassing all types of events.
-//
-//@SEE_ALSO:
-// bmqa::MessageEvent : Data event notification.
-// bmqa::SessionEvent : Session and queue status event notification.
-//
-//@DESCRIPTION: This component provides a generic 'bmqa::Event' notification
-// object used by the 'bmqa::Session' to provide BlazingMQ applications with
-// information regarding the status of the session or data coming from queues.
-// This 'bmqa::Event' object is only used when user wants to process messages
-// from the EventQueue using its own thread, by calling the
-// bmqa::Session::nextEvent method.
-//
-// A 'bmqa::Event' can either be a 'bmqa::SessionEvent' or a
-// 'bmqa::MessageEvent'. The former describes notifications such as the result
-// of a session start or the opening of a queue. The latter carries
-// application messages retrieved from a queue.
-//
-// Note that event is implemented using the pimpl idiom, so copying an event is
-// very cheap (a pointer copy). All copies of this 'bmqa::Event', as well as
-// any 'SessionEvent' or 'MessageEvent' extracted from it will share the same
-// underlying implementation.
-
-
-// BMQ
-#include <bmqscm_version.h>
-#include <bmqa_messageevent.h>
-#include <bmqa_sessionevent.h>
-
-// BDE
-#include <bsl_iosfwd.h>
-#include <bsl_memory.h>
-
-namespace BloombergLP {
-
-// FORWARD DECLARATION
-namespace bmqimp { class Event; }
-
-namespace bmqa {
-
- // ===========
- // class Event
- // ===========
-
-class Event {
- // A variant type encompassing all types of events
-
- private:
- // DATA
- bsl::shared_ptr<bmqimp::Event> d_impl_sp; // pimpl
-
- public:
- // CREATORS
- explicit Event();
- // Default constructor
-
- //! Event(const Event& other) = default;
-
- // MANIPULATORS
- //! Event& operator=(const Event& rhs) = default;
-
- // ACCESSORS
- SessionEvent sessionEvent() const;
- // Return the 'SessionEvent' variant. The behavior is undefined unless
- // 'isSessionEvent' returns true.
-
- MessageEvent messageEvent() const;
- // Return the 'MessageEvent' variant. The behavior is undefined unless
- // 'isMessageEvent' returns true.
-
- bool isSessionEvent() const;
- // Return true if the event is a session event.
-
- bool isMessageEvent() const;
- // Return true if the event is a message event.
-
- bsl::ostream& print(bsl::ostream& stream,
- int level = 0,
- int spacesPerLevel = 4) const;
- // Format this object to the specified output 'stream' at the (absolute
- // value of) the optionally specified indentation 'level' and return a
- // reference to 'stream'. If 'level' is specified, optionally specify
- // 'spacesPerLevel', the number of spaces per indentation level for
- // this and all of its nested objects. If 'level' is negative,
- // suppress indentation of the first line. If 'spacesPerLevel' is
- // negative format the entire output on one line, suppressing all but
- // the initial indentation (as governed by 'level'). If 'stream' is
- // not valid on entry, this operation has no effect.
-};
-
-// FREE OPERATORS
-bsl::ostream& operator<<(bsl::ostream& stream, const Event& rhs);
- // Format the specified 'rhs' to the specified output 'stream' and return a
- // reference to the modifiable 'stream'.
-
-} // close package namespace
-
-
-// ============================================================================
-// INLINE DEFINITIONS
-// ============================================================================
-
-
- // -----------
- // class Event
- // -----------
-
-inline
-bsl::ostream&
-bmqa::operator<<(bsl::ostream& stream,
- const bmqa::Event& rhs)
-{
- return rhs.print(stream, 0, -1);
-}
-
-} // close enterprise namespace
-
-#endif
-
-Generated on Thu Jun 15 2023 11:58:50 by
-
- 1.7.1
-
-
diff --git a/docs/docs/apidocs/cpp_apidocs/bmqa__manualhosthealthmonitor_8h_source.html b/docs/docs/apidocs/cpp_apidocs/bmqa__manualhosthealthmonitor_8h_source.html
deleted file mode 100644
index 3675ebcad..000000000
--- a/docs/docs/apidocs/cpp_apidocs/bmqa__manualhosthealthmonitor_8h_source.html
+++ /dev/null
@@ -1,87 +0,0 @@
-
-
-Bloomberg Development Environment
-
-
-// Copyright 2021-2023 Bloomberg Finance L.P.
-// SPDX-License-Identifier: Apache-2.0
-//
-// Licensed under the Apache License, Version 2.0 (the "License");
-// you may not use this file except in compliance with the License.
-// You may obtain a copy of the License at
-//
-// http://www.apache.org/licenses/LICENSE-2.0
-//
-// Unless required by applicable law or agreed to in writing, software
-// distributed under the License is distributed on an "AS IS" BASIS,
-// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-// See the License for the specific language governing permissions and
-// limitations under the License.
-
-// bmqa_manualhosthealthmonitor.h -*-C++-*-
-#ifndef INCLUDED_BMQA_MANUALHOSTHEALTHMONITOR
-#define INCLUDED_BMQA_MANUALHOSTHEALTHMONITOR
-
-//@PURPOSE: Provide a minimal implementation of 'bmqpi::HostHealthMonitor'.
-//
-//@CLASSES:
-// bmqa::ManualHostHealthMonitor: A 'HostHealthMonitor' that derives its host
-// health state from a value explicitly set through a setter method.
-//
-//@DESCRIPTION:
-// 'bmqa::ManualHostHealthMonitor' is a minimal implementation of
-// 'bmqpi::HostHealthMonitor', which is primarily useful for unit-testing, and
-// for integrating with other systems for determining host health.
-
-
-// BMQ
-#include <bmqscm_version.h>
-#include <bmqpi_hosthealthmonitor.h>
-#include <bmqt_hosthealthstate.h>
-
-// BDE
-#include <bdlmt_signaler.h>
-#include <bsl_memory.h>
-#include <bsls_keyword.h>
-
-namespace BloombergLP {
-
-namespace bmqa {
-
- // =============================
- // class ManualHostHealthMonitor
- // =============================
-
-class ManualHostHealthMonitor: public bmqpi::HostHealthMonitor {
- private:
- // PRIVATE DATA
- bsl::shared_ptr<bmqpi::HostHealthMonitor> d_impl_sp;
-
- public:
- // CREATORS
- ManualHostHealthMonitor(bmqt::HostHealthState::Enum initialState,
- bslma::Allocator *allocator = 0);
- // Constructs a 'ManualHostHealthMonitor' with the given initial state.
- // Optionally specify an 'allocator' to supply memory. If 'allocator'
- // is 0, the currently installed default allocator is used.
-
- ~ManualHostHealthMonitor() BSLS_KEYWORD_OVERRIDE;
- // Destructor.
-
- // MANIPULATORS
- bdlmt::SignalerConnection
- observeHostHealth(const HostHealthChangeFn& cb) BSLS_KEYWORD_OVERRIDE;
-
- void setState(bmqt::HostHealthState::Enum newState);
-
- // ACCESSORS
- bmqt::HostHealthState::Enum hostState() const BSLS_KEYWORD_OVERRIDE;
-};
-
-} // close package namespace
-} // close enterprise namespace
-
-#endif
-
-Generated on Thu Jun 15 2023 11:58:50 by
-
- 1.7.1
-
-
diff --git a/docs/docs/apidocs/cpp_apidocs/bmqa__message_8h_source.html b/docs/docs/apidocs/cpp_apidocs/bmqa__message_8h_source.html
deleted file mode 100644
index 54af4e2b3..000000000
--- a/docs/docs/apidocs/cpp_apidocs/bmqa__message_8h_source.html
+++ /dev/null
@@ -1,503 +0,0 @@
-
-
-Bloomberg Development Environment
-
-
-// Copyright 2014-2023 Bloomberg Finance L.P.
-// SPDX-License-Identifier: Apache-2.0
-//
-// Licensed under the Apache License, Version 2.0 (the "License");
-// you may not use this file except in compliance with the License.
-// You may obtain a copy of the License at
-//
-// http://www.apache.org/licenses/LICENSE-2.0
-//
-// Unless required by applicable law or agreed to in writing, software
-// distributed under the License is distributed on an "AS IS" BASIS,
-// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-// See the License for the specific language governing permissions and
-// limitations under the License.
-
-// bmqa_message.h -*-C++-*-
-#ifndef INCLUDED_BMQA_MESSAGE
-#define INCLUDED_BMQA_MESSAGE
-
-//@PURPOSE: Provide the application with a message data object.
-//
-//@CLASSES:
-// bmqa::Message: message received from/sent to a queue
-// bmqa::MessageConfirmationCookie: cookie for async message confirmation
-//
-//@SEE_ALSO:
-// bmqa::MessageEvent : Mechanism for data event notification.
-// bmqa::MessageEventBuilder: Builder for 'bmqa::MessageEvent'
-//
-//@DESCRIPTION: A 'bmqa::Message' represents the data message to put on a
-// queue, or retrieved from a queue. It is composed of the following fields:
-//
-//: o A message GUID, which is a printable string generated by the broker to
-//: uniquely identify this message.
-//:
-//: o A correlation Id, which is a user-provided identifier for the message.
-//:
-//: o A queue Id, to map with the queue this message is associated with.
-//:
-//: o The payload, which is opaque to the framework. At some point, framework
-//: may provide utilities to encode and decode schema messages using various
-//: CODECs. For example, a JavaScript publisher may publish a message into
-//: a queue using a JSON object as payload, and the consumer may be receiving
-//: that payload as a BER-encoded schema object.
-//:
-//: o At some point, system properties such as version, encoding, timestamp,
-//: priority, message group and "reply-to" will be supported. System
-//: properties will be used by the broker; for example to deliver
-//: high-priority messages first or to filter based on a minimum version.
-//:
-//: o At some point, application-defined message properties will also be
-//: supported, where properties are a list of name-value pairs.
-//
-// A 'bmqa::MessageConfirmationCookie' is a small object which allows to
-// confirm a 'bmqa::Message' asynchronously without having to hold on to the
-// entire message. This can be useful when, for example, the message is
-// decoded in the event handler, and the resulting object is enqueued for
-// asynchronous processing, along with that small cookie object for confirming
-// the message once successfully processed.
-
-// BMQ
-#include <bmqscm_version.h>
-#include <bmqa_queueid.h>
-#include <bmqt_compressionalgorithmtype.h>
-#include <bmqt_correlationid.h>
-#include <bmqt_messageguid.h>
-
-// BDE
-#include <bdlbb_blob.h>
-#include <bsl_cstddef.h> // for 'size_t'
-#include <bsl_iosfwd.h>
-#include <bsl_memory.h>
-#include <bsl_string.h>
-#include <bslma_allocator.h>
-#include <bsls_annotation.h>
-
-
-namespace BloombergLP {
-
-// FORWARD DECLARATION
-namespace bmqimp { class Event; }
-
-namespace bmqa {
-
-// FORWARD DECLARATION
-class MessageProperties;
-
-
- // ==================
- // struct MessageImpl
- // ==================
-
-struct MessageImpl {
- // Struct containing the internal (private) members of Message (That is so
- // that we can access private members of Message to initialize it, without
- // having to expose them publicly).
- //
- // IMPLEMENTATION NOTE: If adding new data members to this struct that are
- // lazily populated (such as 'queueId' or
- // 'correlationId'), then they should be reset in
- // 'bmqa::MessageIterator.nextMessage()'.
-
- // PUBLIC DATA
- bmqimp::Event *d_event_p;
- // Pointer to the Event this message is
- // associated with
-
- bsl::shared_ptr<bmqimp::Event> d_clonedEvent_sp;
- // May point to a bmqimp::Event (in case
- // this Message is a clone)
-
- bmqa::QueueId d_queueId;
- // QueueId this message is associated
- // with
-
- bmqt::CorrelationId d_correlationId;
- // CorrelationId this message is
- // associated with
-
-#ifdef BMQ_ENABLE_MSG_GROUPID
- bsl::string d_groupId;
- // Optional Group Id this message is
- // associated with
-#endif
-};
-
-
- // ===============================
- // class MessageConfirmationCookie
- // ===============================
-
-class MessageConfirmationCookie {
- // Cookie for async message confirmation.
-
- private:
- // DATA
- bmqa::QueueId d_queueId;
- // QueueID associated to this cookie
-
- bmqt::MessageGUID d_guid;
- // GUID associated to this cookie
-
- public:
- // CREATORS
- MessageConfirmationCookie();
- // Create an unset instance of this class.
-
- MessageConfirmationCookie(const QueueId& queueId,
- const bmqt::MessageGUID& messageGUID);
- // Create an instance with the specified 'queueId' and 'messageGUID'.
- // Users should not use that constructor directly, but rather load the
- // message cookie from an existing 'bmqa::Message' with the
- // 'bmqa::Message::confirmationCookie' accessor.
-
- // ACCESSORS
- const QueueId& queueId() const;
- // Return the queue ID of the message with which this confirmation
- // cookie is associated.
-
- const bmqt::MessageGUID& messageGUID() const;
- // Return message GUID of the message with which this confirmation
- // cookie is associated.
-};
-
- // =============
- // class Message
- // =============
-
-class Message {
- // A message sent/received to/from the BlazingMQ broker.
-
-#ifdef BMQ_ENABLE_MSG_GROUPID
- public:
- // CONSTANTS
- static const int k_GROUP_ID_MAX_LENGTH = 31;
- // Constant representing the maximum length of a Group Id string.
-#endif
-
- private:
- // DATA
- mutable MessageImpl d_impl; // pimpl
-
- private:
- // PRIVATE ACCESSORS
- bool isInitialized() const;
- // Return true if the message has been initialized with an underlying
- // event (and thus is valid), and false otherwise. Any operation
- // except assignment or destruction on an uninitialized message is an
- // error.
-
- public:
- // CREATORS
- explicit Message();
- // Create an invalid message having no content. Only valid operations
- // on an invalid message instance are assignment and destruction.
-
- //! Message(const Message& other) = default;
- // Create a message from the specified 'other' instance.
-
- //! ~Message() = default;
- // Destructor
-
- // MANIPULATORS
- //! Message& operator=(const Message& other) = default;
- // Assign to this object the value of the specified 'other' instance
- // and return a reference to this object.
-
- Message& setData(const bdlbb::Blob *data) BSLS_ANNOTATION_DEPRECATED;
- // Set the payload of this message to the blob pointed to by the
- // specified 'data'. Behavior is undefined unless 'data' is non-null
- // and payload's length is greater than zero. Note that payload
- // pointed to by 'data' is *not* copied right away, and should not be
- // destroyed or modified until this message has been packed (see
- // 'bmqa::MessageEventBuilder' component level documentation for
- // correct usage).
- //
- // This method is deprecated, please use 'setDataRef()' instead.
-
- Message& setData(const char *data,size_t length)
- BSLS_ANNOTATION_DEPRECATED;
- // Set the payload of this message to the specified 'length' bytes
- // starting at the specified 'data' address. The behavior is undefined
- // unless 'data' is non-null and 'length' is greater than zero. Note
- // that payload pointed to by 'data' is *not* copied right away, and
- // should not be destroyed or modified until this message has been
- // packed (see 'bmqa::MessageEventBuilder' component level
- // documentation for correct usage).
- //
- // This method is deprecated, please use 'setDataRef()' instead.
-
- Message& setDataRef(const bdlbb::Blob *data);
- // Set the payload of this message to the blob pointed to by the
- // specified 'data'. Behavior is undefined unless 'data' is non-null
- // and payload's length is greater than zero. Note that payload
- // pointed to by 'data' is *not* copied right away, and should not be
- // destroyed or modified until this message has been packed (see
- // 'bmqa::MessageEventBuilder' component level documentation for
- // correct usage).
-
- Message& setDataRef(const char *data,
- size_t length);
- // Set the payload of this message to the specified 'length' bytes
- // starting at the specified 'data' address. The behavior is undefined
- // unless 'data' is non-null and 'length' is greater than zero. Note
- // that payload pointed to by 'data' is *not* copied right away, and
- // should not be destroyed or modified until this message has been
- // packed (see 'bmqa::MessageEventBuilder' component level
- // documentation for correct usage).
-
- Message& setPropertiesRef(const MessageProperties *properties);
- // Set the properties of this message to the 'MessageProperties'
- // instance pointed by the specified 'properties'. Behavior is
- // undefined unless 'properties' is non-null. Note that properties are
- // *not* copied right away, and should not be destroyed or modified
- // until this message has been packed (see 'bmqa::MessageEventBuilder'
- // component level documentation for correct usage).
-
- Message& clearPropertiesRef();
- // Clear out and properties associated with this message. Note that if
- // there are no properties associated with this message, this method
- // has no effect. Also note that the associated 'MessageProperties'
- // instance, if any, is not modified; it's simply dissociated from this
- // message.
-
- Message& setCorrelationId(const bmqt::CorrelationId& correlationId);
- // Set correlation ID of this message to the specified 'correlationId'.
-
- Message&
- setCompressionAlgorithmType(bmqt::CompressionAlgorithmType::Enum value);
- // Set the Compression algorithm type of the current message to the
- // specified 'value' and return a reference offering modifiable access
- // to this object.
-
-#ifdef BMQ_ENABLE_MSG_GROUPID
- Message& setGroupId(const bsl::string& groupId);
- // Set Group Id of this message to the specified 'groupId'. The
- // 'groupId' must be a null-terminated string with up to
- // 'Message::k_GROUP_ID_MAX_LENGTH' characters (excluding the
- // terminating '\0'). The behavior is undefined if the message is not
- // a started, 'PUT' message or if 'groupId' is empty.
-
- Message& clearGroupId();
- // Clear the Group Id of this message. The behavior is undefined if
- // the message is not a started, 'PUT' message.
-#endif
-
- // ACCESSORS
- bool isValid() const; // TBD:BSLS_ANNOTATION_DEPRECATED
- // Return true if the message is valid, and false otherwise. Any
- // operation except assignment or destruction on an invalid message is
- // an error.
- //
- // This method is deprecated.
-
- operator bool() const; // TBD:BSLS_ANNOTATION_DEPRECATED
- // Same as 'isValid'.
- //
- // This method is deprecated.
-
- Message clone(bslma::Allocator *basicAllocator = 0) const;
- // Return a copy of this message, using the optionally specified
- // 'basicAllocator' with the copy holding all the data of this instance
- // and not backed by any 'MessageEvent'. Note that this operation
- // does *not* copy underlying data.
-
- const bmqa::QueueId& queueId() const;
- // Return the queue ID indicating the queue for which this message has
- // been received from. The behavior is undefined unless this instance
- // represents a 'PUT', 'PUSH' or 'ACK' message.
-
- const bmqt::CorrelationId& correlationId() const;
- // Return the correlation Id associated with this message. The
- // behavior is undefined unless this instance represents a 'PUT' or an
- // 'ACK', or a 'PUSH' message. Note that in case of failure to accept
- // a 'PUT' message, BlazingMQ sends an 'ACK' message with failed
- // status, even if an 'ACK' message was not requested by the
- // application (i.e., no correlationId was specified when posting the
- // message). In such cases, correlationId associated with the 'ACK'
- // message will be unset, and as such, application *must* check for
- // that by invoking 'isUnset' on the returned correlationId object. In
- // the case of a 'PUSH' message, the return value is the one specified
- // as the correlation id of the corresponding Subscription. Invoking
- // 'thePointer', 'theNumeric' or 'theSharedPtr' on an unset
- // correlationId instance will lead to undefined behavior.
-
- bmqt::CompressionAlgorithmType::Enum compressionAlgorithmType() const;
- // Return Compression algorithm type of the current message. Behavior
- // is undefined unless this instance represents a 'PUT' or 'PUSH'
- // message.
-
-#ifdef BMQ_ENABLE_MSG_GROUPID
- const bsl::string& groupId() const;
- // Return the Group Id associated with this message. The behavior is
- // undefined unless this instance represents a 'PUT' or a 'PUSH'
- // message and 'hasGroupId()' returns 'true".
-#endif
-
- const bmqt::MessageGUID& messageGUID() const;
- // Return the unique message Id generated by the SDK for this message.
- // The behavior is undefined unless this instance represents a 'PUT',
- // a 'PUSH' or an 'ACK' message.
-
- MessageConfirmationCookie confirmationCookie() const;
- // Return a cookie which can be used to confirm this message. The
- // behavior is undefined unless this instance represents a 'PUSH'
- // message.
-
- int ackStatus() const;
- // Return the status of the 'ACK' message. The behavior is undefined
- // unless this instance represents an 'ACK' message. This value
- // correspond to the 'bmqt::AckResult::Enum' enum.
-
- int getData(bdlbb::Blob *blob) const;
- // Load into the specified 'blob' the payload of the message, if any.
- // Return zero if the message has a payload and non-zero value
- // otherwise. The behaviour is undefined unless this instance
- // represents a 'PUT' or 'PUSH' message. Note that for efficiency,
- // application should fetch payload once and cache the value, instead
- // of invoking this method multiple times on a message.
-
- int dataSize() const;
- // Return the number of bytes in the payload. The behaviour is
- // undefined unless this instance represents a 'PUT' or a 'PUSH'
- // message. Note that for efficiency, application should fetch payload
- // size once and cache the value, instead of invoking this method
- // multiple times on a message.
-
- bool hasProperties() const;
- // Return 'true' if this instance has at least one message property
- // associated with it, 'false' otherwise. Behavior is undefined unless
- // this instance represents a 'PUT' or a 'PUSH' message.
-
-#ifdef BMQ_ENABLE_MSG_GROUPID
- bool hasGroupId() const;
- // Return whether this message has an associated GroupId set. The
- // behavior is undefined unless this instance represents a 'PUT' or a
- // 'PUSH' message.
-#endif
-
- int loadProperties(MessageProperties *buffer) const;
- // Load into the specified 'buffer' the properties associated with this
- // message. Return zero on success, and a non-zero value otherwise.
- // Behavior is undefined unless this instance represents a 'PUT' or a
- // 'PUSH' message, and unless 'buffer' is non-null. Note that if there
- // are no properties associated with this message, zero will be
- // returned and the 'MessageProperties' instance pointed by 'buffer'
- // will be cleared. Also note that for efficiency, application should
- // fetch properties once and cache the value, instead of invoking this
- // method multiple times on a message.
-
- bsl::ostream& print(bsl::ostream& stream,
- int level = 0,
- int spacesPerLevel = 4) const;
- // Format this object to the specified output 'stream' at the (absolute
- // value of) the optionally specified indentation 'level' and return a
- // reference to 'stream'. If 'level' is specified, optionally specify
- // 'spacesPerLevel', the number of spaces per indentation level for
- // this and all of its nested objects. If 'level' is negative,
- // suppress indentation of the first line. If 'spacesPerLevel' is
- // negative format the entire output on one line, suppressing all but
- // the initial indentation (as governed by 'level'). If 'stream' is
- // not valid on entry, this operation has no effect.
-};
-
-// FREE OPERATORS
-bsl::ostream& operator<<(bsl::ostream& stream, const Message& rhs);
- // Format the specified 'rhs' to the specified output 'stream' and return a
- // reference to the modifiable 'stream'.
-
-
-// ============================================================================
-// INLINE DEFINITIONS
-// ============================================================================
-
-
- // -------------
- // class Message
- // -------------
-
-inline
-Message&
-Message::setData(const bdlbb::Blob *data)
-{
- return setDataRef(data);
-}
-
-inline
-Message&
-Message::setData(const char *data,
- size_t length)
-{
- return setDataRef(data, length);
-}
-
-inline
-Message::operator bool() const
-{
- return isInitialized();
-}
-
- // -------------------------------
- // class MessageConfirmationCookie
- // -------------------------------
-
-inline
-MessageConfirmationCookie::MessageConfirmationCookie()
-: d_queueId()
-, d_guid()
-{
- // NOTHING
-}
-
-inline
-MessageConfirmationCookie::MessageConfirmationCookie(
- const bmqa::QueueId& queueId,
- const bmqt::MessageGUID& messageGUID)
-: d_queueId(queueId)
-, d_guid(messageGUID)
-{
- // NOTHING
-}
-
-// ACCESSORS
-inline
-const QueueId&
-MessageConfirmationCookie::queueId() const
-{
- return d_queueId;
-}
-
-inline
-const bmqt::MessageGUID&
-MessageConfirmationCookie::messageGUID() const
-{
- return d_guid;
-}
-} // close package namespace
-
-
- // -------------
- // class Message
- // -------------
-
-// FREE OPERATORS
-inline
-bsl::ostream&
-bmqa::operator<<(bsl::ostream& stream,
- const bmqa::Message& rhs)
-{
- return rhs.print(stream, 0, -1);
-}
-
-} // close enterprise namespace
-
-#endif
-
-Generated on Thu Jun 15 2023 11:58:50 by
-
- 1.7.1
-
-
diff --git a/docs/docs/apidocs/cpp_apidocs/bmqa__messageevent_8h_source.html b/docs/docs/apidocs/cpp_apidocs/bmqa__messageevent_8h_source.html
deleted file mode 100644
index 545e3bb3f..000000000
--- a/docs/docs/apidocs/cpp_apidocs/bmqa__messageevent_8h_source.html
+++ /dev/null
@@ -1,139 +0,0 @@
-
-
-Bloomberg Development Environment
-
-
-// Copyright 2014-2023 Bloomberg Finance L.P.
-// SPDX-License-Identifier: Apache-2.0
-//
-// Licensed under the Apache License, Version 2.0 (the "License");
-// you may not use this file except in compliance with the License.
-// You may obtain a copy of the License at
-//
-// http://www.apache.org/licenses/LICENSE-2.0
-//
-// Unless required by applicable law or agreed to in writing, software
-// distributed under the License is distributed on an "AS IS" BASIS,
-// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-// See the License for the specific language governing permissions and
-// limitations under the License.
-
-// bmqa_messageevent.h -*-C++-*-
-#ifndef INCLUDED_BMQA_MESSAGEEVENT
-#define INCLUDED_BMQA_MESSAGEEVENT
-
-//@PURPOSE: Provide the application with data event notifications.
-//
-//@CLASSES:
-// bmqa::MessageEvent: Mechanism for data event notification.
-//
-//@SEE_ALSO:
-// bmqa::MessageIterator: iterator over the messages in this event
-// bmqa::Message: type of the Message
-//
-//@DESCRIPTION: This component provides a 'bmqa::MessageEvent' notification
-// object used by the 'bmqa::Session' to provide BlazingMQ applications with
-// data messages received from the broker. The application can consume the
-// messages by asking this 'MessageEvent' for a 'MessageIterator'.
-//
-// Note that 'MessageEvent' is implemented using the pimpl idiom, so copying a
-// 'MessageEvent' is very cheap (a pointer copy). All copies of this
-// 'MessageEvent' will share the same underlying implementation.
-
-
-// BMQ
-#include <bmqscm_version.h>
-#include <bmqa_messageiterator.h>
-#include <bmqt_messageeventtype.h>
-
-// BDE
-#include <bsl_memory.h>
-#include <bsl_iosfwd.h>
-
-namespace BloombergLP {
-
-// FORWARD DECLARATION
-namespace bmqimp { class Event; }
-
-namespace bmqa {
-
-
- // ==================
- // class MessageEvent
- // ==================
-
-class MessageEvent {
- // An event containing messages received from a queue. The application can
- // consume messages using the message iterator.
-
- private:
- // DATA
- bsl::shared_ptr<bmqimp::Event> d_impl_sp; // pimpl
-
- public:
- // CREATORS
- explicit MessageEvent();
- // Create an unset instance. Note that 'type()' will return
- // 'bmqt::MessageEventType::UNDEFINED'.
-
- //! MessageEvent(const MessageEvent& other) = default;
-
- // MANIPULATORS
- //! MessageEvent& operator=(const MessageEvent& rhs) = default;
-
- // ACCESSORS
- MessageIterator messageIterator() const;
- // Return a 'MessageIterator' object usable for iterating over the
- // 'Message' objects contained in this 'MessageEvent'. Note that
- // obtaining an iterator invalidates (resets) any previously obtained
- // iterator. The behavior is undefined if 'type()' returns
- // 'bmqt::MessageEventType::UNDEFINED'.
-
- bmqt::MessageEventType::Enum type() const;
- // Return the type of messages contained in this MessageEvent.
-
- bsl::ostream& print(bsl::ostream& stream,
- int level = 0,
- int spacesPerLevel = 4) const;
- // Format this object to the specified output 'stream' at the (absolute
- // value of) the optionally specified indentation 'level' and return a
- // reference to 'stream'. If 'level' is specified, optionally specify
- // 'spacesPerLevel', the number of spaces per indentation level for
- // this and all of its nested objects. If 'level' is negative,
- // suppress indentation of the first line. If 'spacesPerLevel' is
- // negative format the entire output on one line, suppressing all but
- // the initial indentation (as governed by 'level'). If 'stream' is
- // not valid on entry, this operation has no effect.
-};
-
-// FREE OPERATORS
-bsl::ostream& operator<<(bsl::ostream& stream, const MessageEvent& rhs);
- // Format the specified 'rhs' to the specified output 'stream' and return a
- // reference to the modifiable 'stream'.
-
-
-// ============================================================================
-// INLINE DEFINITIONS
-// ============================================================================
-
-} // close package namespace
-
-
- // ------------------
- // class MessageEvent
- // ------------------
-
-inline
-bsl::ostream&
-bmqa::operator<<(bsl::ostream& stream,
- const bmqa::MessageEvent& rhs)
-{
- return rhs.print(stream, 0, -1);
-}
-
-} // close enterprise namespace
-
-#endif
-
-Generated on Thu Jun 15 2023 11:58:50 by
-
- 1.7.1
-
-
diff --git a/docs/docs/apidocs/cpp_apidocs/bmqa__messageeventbuilder_8h_source.html b/docs/docs/apidocs/cpp_apidocs/bmqa__messageeventbuilder_8h_source.html
deleted file mode 100644
index c8e65688d..000000000
--- a/docs/docs/apidocs/cpp_apidocs/bmqa__messageeventbuilder_8h_source.html
+++ /dev/null
@@ -1,367 +0,0 @@
-
-
-Bloomberg Development Environment
-
-
-// Copyright 2014-2023 Bloomberg Finance L.P.
-// SPDX-License-Identifier: Apache-2.0
-//
-// Licensed under the Apache License, Version 2.0 (the "License");
-// you may not use this file except in compliance with the License.
-// You may obtain a copy of the License at
-//
-// http://www.apache.org/licenses/LICENSE-2.0
-//
-// Unless required by applicable law or agreed to in writing, software
-// distributed under the License is distributed on an "AS IS" BASIS,
-// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-// See the License for the specific language governing permissions and
-// limitations under the License.
-
-// bmqa_messageeventbuilder.h -*-C++-*-
-#ifndef INCLUDED_BMQA_MESSAGEEVENTBUILDER
-#define INCLUDED_BMQA_MESSAGEEVENTBUILDER
-
-//@PURPOSE: Provide a builder for 'MessageEvent' objects.
-//
-//@CLASSES:
-// bmqa::MessageEventBuilder: a builder for 'MessageEvent'.
-//
-//@DESCRIPTION: This component implements a mechanism,
-// 'bmqa::MessageEventBuilder', that can be used for creating message events
-// containing one or multiple messages. The resulting MessageEvent can be sent
-// to the BlazingMQ broker using the 'bmqa::Session' (refer to 'bmqa_session'
-// for details).
-//
-// The builder holds a 'MessageEvent' under construction, and provides methods
-// to return a reference to the current message (in order to set its various
-// members), as well as to append a new message. Once the application is done,
-// the builder provides a method to get the message event that has been
-// constructed. See 'Usage' section for more details.
-//
-// Note that publishing events containing multiple messages may be more
-// efficient than events limited to a single message for applications that send
-// large volume of small messages.
-//
-///Usage
-///-----
-//: o An instance of bmqa::MessageEventBuilder (the builder) can be used to
-//: create multiple bmqa::MessageEvent's, as long as the instance is reset in
-//: between. This reset is preferably to do right after sending the event to
-//: guarantee that all user resources bound to the bmqa::MessageEvent (e.g.
-//: CorrelationIds with user's shared_ptr) are kept no longer than expected
-//: (e.g. until related ACK event is received). The recommended approach is
-//: to create one instance of the builder and use that throughout the
-//: lifetime of the task (if the task is multi-threaded, an instance per
-//: thread must be created and maintained).
-//: See usage example #1 for an illustration.
-//:
-//: o The lifetime of an instance of the builder is bound by the bmqa::Session
-//: from which it was created. In other words, bmqa::Session instance must
-//: outlive the builder instance.
-//:
-//: o If it is desired to post the same bmqa::Message to different queues,
-//: 'packMessage' can be called multiple times in a row with different queue
-//: IDs. The builder will append the previously packed message with the new
-//: queue ID to the underlying message event. Note that after calling
-//: 'packMessage', the message keeps all the attributes (payload, properties,
-//: etc) that were previously set (except for the 'correlationId' which must
-//: be set explicitly for each individual message). If desired, any
-//: attribute can be tweaked before being packing the message again. Refer
-//: to usage example #2 for an illustration.
-//
-///Example 1 - Basic Usage
-///-----------------------
-//..
-// // Note that error handling is omitted below for the sake of brevity
-//
-// bmqa::Session session;
-// // Session start up logic omitted for brevity.
-//
-// // Obtain a valid instance of message properties.
-// bmqt::MessageProperties properties;
-// session.loadMessageProperties(&properties);
-//
-// // Set common properties that will be applicable to all messages sent by
-// // this application.
-// int rc = properties.setPropertyAsChar(
-// "encoding",
-// static_cast<char>(MyEncodingEnum::e_BER));
-//
-// rc = properties.setPropertyAsString("producerId", "MyUniqueId");
-//
-// // Obtain a valid instance of message event builder.
-// bmqa::MessageEventBuilder builder;
-// session.loadMessageEventBuilder(&builder);
-//
-// // Create and post a message event containing 1 message. Associate
-// // properties with this message.
-// bmqa::Message& msg = builder.startMessage();
-//
-// msg.setCorrelationId(myCorrelationId);
-//
-// // Set payload (where 'myPayload' is of type 'bdlbb::Blob')
-// msg.setDataRef(&myPayload);
-//
-// // Set current timestamp as one of the properties.
-// rc = properties.setPropertyAsInt64(
-// "timestamp",
-// bdlt::EpochUtil::convertToTimeT64(bdlt::CurrentTime::now()));
-//
-// // Set properties.
-// msg.setPropertiesRef(&properties);
-//
-// // Pack the message.
-// rc = builder.packMessage(myQueueId);
-//
-// // Post message event
-// rc = session.post(builder.messageEvent());
-//
-//
-// // Create and post another message event containing 1 message.
-//
-// // bmqa::MessageEventBuilder must be reset before reuse.
-// builder.reset();
-//
-// // Start a new message.
-// bmqa::Message& msg = builder.startMessage();
-//
-// msg.setCorrelationId(myAnotherCorrelationId);
-// msg.setDataRef(&myAnotherPayload);
-//
-// // It's okay (and recommended) to use same properties instance.
-// rc = properties.setPropertyAsInt64(
-// "timestamp",
-// bdlt::EpochUtil::convertToTimeT64(bdlt::CurrentTime::now()));
-//
-// msg.setPropertiesRef(&properties);
-// rc = builder.packMessage(myAnotherQueueId);
-//
-// // Post second message event
-// rc = session.post(builder.messageEvent());
-//
-// // Reset the builder to free resources earlier.
-// builder.reset();
-//..
-//
-///Example 2 - Packing multiple messages in a message event
-///--------------------------------------------------------
-//..
-// // Note that error handling is omitted below for the sake of brevity
-//
-// bmqa::Session session;
-// // Session start up logic omitted for brevity.
-//
-// // Obtain a valid instance of message properties.
-// bmqt::MessageProperties properties;
-// session.loadMessageProperties(&properties);
-//
-// // Set common properties that will be applicable to all messages sent by
-// // this application.
-// int rc = properties.setPropertyAsChar(
-// "encoding",
-// static_cast<char>(MyEncodingEnum::e_BER));
-//
-// rc = properties.setPropertyAsString("producerId", "MyUniqueId");
-//
-// // Obtain a valid instance of message event builder.
-// bmqa::MessageEventBuilder builder;
-// session.loadMessageEventBuilder(&builder);
-//
-// // Create and post a message event containing 4 messages.
-// bmqa::Message& msg = builder.startMessage();
-//
-// // Pack message #1
-// msg.setCorrelationId(correlationId1);
-// msg.setDataRef(&payload1); // where 'payload1' is of type 'bdlbb::Blob'
-//
-// // Set current timestamp as one of the properties.
-// int rc = properties.setPropertyAsInt64(
-// "timestamp",
-// bdlt::EpochUtil::convertToTimeT64(bdlt::CurrentTime::now()));
-//
-// // Pack the message.
-// rc = builder.packMessage(queueId1);
-//
-// // Pack message #2
-// // We want to send message #1 to another queue. In order to do so, we
-// // just update the correlation ID of message #1. There is no need to set
-// // the payload or properties again. Because 'payload1' and 'properties'
-// // objects are being reused for the second message, they should not be
-// // destroyed before packing the second message.
-//
-// msg.setCorrelationId(correlationId2);
-//
-// // Also note that the "timestamp" property for the second message will be
-// // updated for this message. There is no need to invoke
-// // 'setPropertiesRef' on the message though.
-// rc = properties.setPropertyAsInt64(
-// "timestamp",
-// bdlt::EpochUtil::convertToTimeT64(bdlt::CurrentTime::now()));
-//
-// rc = builder.packMessage(queueId2);
-//
-// // 'payload1' can be safely destroyed at this point if it will not be
-// // reused again for another message.
-//
-// // Pack message #3
-// // Message #3 has a different payload, no properties and destined to
-// // 'queueId1'.
-// msg.setCorrelationId(correlationId3);
-// msg.setDataRef(&payload2); // where 'payload2' is of type 'bdlbb::Blob'
-//
-// // We need to explicitly clear out the associated properties.
-// msg.clearProperties();
-//
-// rc = builder.packMessage(queueId1);
-//
-// // Pack message #4
-// // Message #4 has different payload and destined to 'queueId3'.
-// msg.setCorrelationId(correlationId4);
-// msg.setDataRef(&payload3); // where 'payload3' is of type 'bdlbb::Blob'
-//
-// // Update "timestamp" property.
-// rc = properties.setPropertyAsInt64(
-// "timestamp",
-// bdlt::EpochUtil::convertToTimeT64(bdlt::CurrentTime::now()));
-//
-// // Need to associate properties with the message, since they were cleared
-// // out while packing message #3 above.
-// msg.setPropertiesRef(&properties);
-//
-// rc = builder.packMessage(queueId3);
-//
-// // Post second message event
-// rc = session.post(builder.messageEvent());
-//
-// // Reset the builder to free resources earlier.
-// builder.reset();
-//..
-//
-///Thread Safety
-///-------------
-// This component is *NOT* thread safe.
-
-
-// BMQ
-#include <bmqscm_version.h>
-#include <bmqa_message.h>
-#include <bmqa_messageevent.h>
-#include <bmqt_resultcode.h>
-
-// BDE
-#include <bsl_memory.h>
-
-namespace BloombergLP {
-
-// FORWARD DECLARATION
-namespace bmqa { class QueueId; }
-namespace bmqp { class MessageGUIDGenerator; }
-
-namespace bmqa {
-
- // ==============================
- // struct MessageEventBuilderImpl
- // ==============================
-
-struct MessageEventBuilderImpl {
- // Struct containing the internal (private) members of MessageEventBuilder
- // (That is so that bmqa::Session::loadMessageEventBuilder can access
- // private members of MessageEventBuilder to initialize it, without having
- // to expose them publicly).
-
- // PUBLIC DATA
- MessageEvent d_msgEvent; // This is needed so that 'getMessageEvent()' can
- // return a const ref.
-
- Message d_msg; // This is needed so that 'startMessage()' can
- // return a ref.
-
- bsl::shared_ptr<bmqp::MessageGUIDGenerator>
- d_guidGenerator_sp;
- // GUID generator object.
-};
-
-
- // =========================
- // class MessageEventBuilder
- // =========================
-
-class MessageEventBuilder {
- // A builder for 'MessageEvent' objects.
-
- private:
- // DATA
- MessageEventBuilderImpl d_impl; // Impl
-
- public:
- // CREATORS
- explicit MessageEventBuilder();
- // Create an invalid instance. Application should not create
- // 'MessageEventBuilder' themselves, but ask the 'bmqa::Session' to
- // give them one, by using 'bmqa::Session::loadMessageEventBuilder'.
-
- //! ~MessageEventBuilder() = default;
- // Destructor
-
- //! MessageEventBuilder(const MessageEventBuilder&) = default;
- //! MessageEventBuilder& operator=(const MessageEventBuilder&) = default;
- // Copy constructor and assignment operator
-
- // MANIPULATORS
- Message& startMessage();
- // Reset the current message being built, and return a reference to the
- // current message. Note that returned 'Message' is valid until this
- // builder is reset or destroyed. Behavior is undefined if this
- // builder was earlier used to build an event *and* has not been reset
- // since then.
-
- bmqt::EventBuilderResult::Enum packMessage(const bmqa::QueueId& queueId);
- // Add the current message into the message event under construction,
- // setting the destination queue of the current message to match the
- // specified 'queueId'. Return zero on success, non-zero value
- // otherwise. In case of failure, this method has no effect on the
- // underlying message event being built. The behavior is undefined
- // unless all mandatory attributes of the current Message have been
- // set, *and* 'queueId' is valid *and* has been opened in WRITE mode.
- // The result is one of the values from the
- // 'bmqt::EventBuilderResult::Enum' enum. Note that this method can be
- // called multiple times in a row with different 'queueId' if the
- // application desires to post the same 'bmqa::Message' to multiple
- // queues: all attributes on the message are unchanged, exception for
- // the 'correlationId' which is cleared.
-
- void reset();
- // Reset the builder, effectively discarding the 'MessageEvent' under
- // construction.
-
- const MessageEvent& messageEvent();
- // Return the 'MessageEvent' that was built. Note that returned
- // 'MessageEvent' is valid until this builder is reset or destroyed,
- // calling this method multiple times in a row will return the same
- // bmqa::MessageEvent instance. Also note that this builder must be
- // reset before calling 'startMessage' again.
-
- Message& currentMessage();
- // Return a reference to the current message.
-
- // ACCESSORS
- int messageCount() const;
- // Return the number of messages currently in the MessageEvent being
- // built.
-
- int messageEventSize() const;
- // Return the size in bytes of the event built after last successful
- // call to 'packMessage()', otherwise return zero. Note that returned
- // value represents the length of entire message event, *including*
- // BlazingMQ wire protocol overhead.
-};
-
-
-} // close package namespace
-} // close enterprise namespace
-
-#endif
-
-Generated on Thu Jun 15 2023 11:58:50 by
-
- 1.7.1
-
-
diff --git a/docs/docs/apidocs/cpp_apidocs/bmqa__messageiterator_8h_source.html b/docs/docs/apidocs/cpp_apidocs/bmqa__messageiterator_8h_source.html
deleted file mode 100644
index ad1eb3f12..000000000
--- a/docs/docs/apidocs/cpp_apidocs/bmqa__messageiterator_8h_source.html
+++ /dev/null
@@ -1,137 +0,0 @@
-
-
-Bloomberg Development Environment
-
-
-// Copyright 2014-2023 Bloomberg Finance L.P.
-// SPDX-License-Identifier: Apache-2.0
-//
-// Licensed under the Apache License, Version 2.0 (the "License");
-// you may not use this file except in compliance with the License.
-// You may obtain a copy of the License at
-//
-// http://www.apache.org/licenses/LICENSE-2.0
-//
-// Unless required by applicable law or agreed to in writing, software
-// distributed under the License is distributed on an "AS IS" BASIS,
-// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-// See the License for the specific language governing permissions and
-// limitations under the License.
-
-// bmqa_messageiterator.h -*-C++-*-
-#ifndef INCLUDED_BMQA_MESSAGEITERATOR
-#define INCLUDED_BMQA_MESSAGEITERATOR
-
-//@PURPOSE: Provide a mechanism to iterate over the messages of a MessageEvent.
-//
-//@CLASSES:
-// bmqa::MessageIterator: read-only sequential iterator on 'Message' objects
-//
-//@DESCRIPTION: 'bmqa::MessageIterator' is an iterator-like mechanism providing
-// read-only sequential access to messages contained into a MessageEvent.
-//
-///Usage
-///-----
-// Typical usage of this iterator should follow the following pattern:
-//..
-// while (messageIterator.nextMessage()) {
-// const Message& message = messageIterator.message();
-// // Do something with message
-// }
-//..
-
-
-// BMQ
-#include <bmqscm_version.h>
-#include <bmqa_message.h>
-
-// BDE
-#include <ball_log.h>
-
-namespace BloombergLP {
-
-// FORWARD DECLARATION
-namespace bmqimp { class Event; }
-
-namespace bmqa {
-
-
- // ==========================
- // struct MessageIteratorImpl
- // ==========================
-
-struct MessageIteratorImpl {
- // Struct to hold the impl of the 'MessageIterator'; that is so that we can
- // keep the real impl private and use some special cast to manipulate it,
- // without publicly exposing private members.
-
- // PUBLIC DATA
- bmqimp::Event *d_event_p; // Raw pointer to the event
-
- bmqa::Message d_message; // A 'Message', representing a view to the
- // current message pointing at by this iterator.
- // This is so that 'message' can return a 'const
- // Message&' to clearly indicate the lifetime of
- // the Message, and so that we only create one
- // such object per MessageIterator.
-
- int d_messageIndex;
- // Position of 'd_message' in the underlying
- // message event.
-};
-
-
- // =====================
- // class MessageIterator
- // =====================
-
-class MessageIterator {
- // An iterator providing read-only sequential access to messages contained
- // into a 'MesssageEvent'.
-
- private:
- // CLASS-SCOPE CATEGORY
- BALL_LOG_SET_CLASS_CATEGORY("BMQA.MESSAGEITERATOR");
-
- private:
- // DATA
- MessageIteratorImpl d_impl; // Implementation. Abstracted in its own struct
- // and private so that we can do some magic to
- // manipulate it without exposing any
- // accessors/manipulators (this is wanted since
- // this class is a public class).
-
- public:
- // CREATORS
- explicit MessageIterator();
- // Default constructor
-
- //! MessageIterator(const MessageIterator&) = default;
-
- //! ~MessageIterator() = default;
-
- // MANIPULATORS
- //! MessageIterator& operator=(const MessageIterator&) = default;
-
- bool nextMessage();
- // Advance the position of the iterator to the next message in the
- // event. Return true if there is a next message and false otherwise.
- // Note that advancing to the next message will invalidate any
- // previously returned bmqa::Message retrieved from the 'message()'
- // call.
-
- // ACCESSORS
- const Message& message() const;
- // Return the message to which the iterator is pointing, if any;
- // otherwise return an invalid message. Note that 'nextMessage' must
- // be called before 'message' in order to advance the iterators
- // position to the first message in the event.
-};
-
-} // close package namespace
-} // close enterprise namespace
-
-#endif
-
-Generated on Thu Jun 15 2023 11:58:50 by
-
- 1.7.1
-
-
diff --git a/docs/docs/apidocs/cpp_apidocs/bmqa__messageproperties_8h_source.html b/docs/docs/apidocs/cpp_apidocs/bmqa__messageproperties_8h_source.html
deleted file mode 100644
index 2335799f4..000000000
--- a/docs/docs/apidocs/cpp_apidocs/bmqa__messageproperties_8h_source.html
+++ /dev/null
@@ -1,398 +0,0 @@
-
-
-Bloomberg Development Environment
-
-
-// Copyright 2016-2023 Bloomberg Finance L.P.
-// SPDX-License-Identifier: Apache-2.0
-//
-// Licensed under the Apache License, Version 2.0 (the "License");
-// you may not use this file except in compliance with the License.
-// You may obtain a copy of the License at
-//
-// http://www.apache.org/licenses/LICENSE-2.0
-//
-// Unless required by applicable law or agreed to in writing, software
-// distributed under the License is distributed on an "AS IS" BASIS,
-// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-// See the License for the specific language governing permissions and
-// limitations under the License.
-
-// bmqa_messageproperties.h -*-C++-*-
-#ifndef INCLUDED_BMQA_MESSAGEPROPERTIES
-#define INCLUDED_BMQA_MESSAGEPROPERTIES
-
-//@PURPOSE: Provide a VST representing message properties.
-//
-//@CLASSES:
-// bmqa::MessageProperties: VST representing message properties.
-// bmqa::MessagePropertiesIterator: Mechanism to iterate over properties.
-//
-//@SEE ALSO: bmqt::PropertyType
-//
-//@DESCRIPTION: 'bmqa::MessageProperties' provides a VST representing message
-// properties. Message properties are a collection of name-value pairs that
-// producer can associate with a message, and consumer can retrieve from the
-// corresponding message. In order to keep their usage flexible, no schema is
-// enforced for the message properties, and their format (names and data types)
-// should be negotiated by producers and consumers. Message properties can be
-// used for routing, pipelining or filtering messages within the application.
-// It can be efficient to specify such message attributes in the properties
-// instead of the message payload, because application does not have to decode
-// entire payload to retrieve these attributes.
-// 'bmqa::MessagePropertiesIterator' provides a mechanism to iterate over all
-// the properties of a 'bmqa::MessageProperties' object.
-//
-///Restrictions on Property Names
-///------------------------------
-//
-//: o Length of a property name must be greater than zero and must *not* exceed
-//: 'bmqa::MessageProperties::k_MAX_PROPERTY_NAME_LENGTH'
-//
-//: o First character of the property name must be alpha-numeric.
-//
-///Restrictions on Property Values
-///-------------------------------
-//
-//: o Length of a property value must be non-negative (ie, can be zero) and
-//: must *not* exceed 'bmqa::MessageProperties::k_MAX_PROPERTY_VALUE_LENGTH'.
-//: Note that this restriction is obviously applicable to property values
-//: with types 'bmqt::PropertyType::e_STRING' and
-//: 'bmqt::PropertyType::e_BINARY', because for all other property value
-//: types, size is implicitly applicable based on the type (see 'Data Types
-//: and Size' section in 'bmqt::PropertyType' component).
-//
-
-
-// BMQ
-#include <bmqscm_version.h>
-#include <bmqt_resultcode.h>
-#include <bmqt_propertytype.h>
-
-// BDE
-#include <bdlbb_blob.h>
-#include <bsl_string.h>
-#include <bslma_allocator.h>
-#include <bslma_usesbslmaallocator.h>
-#include <bslmf_nestedtraitdeclaration.h>
-#include <bsls_alignedbuffer.h>
-#include <bsls_types.h>
-#include <bsl_cstdint.h>
-
-
-namespace BloombergLP {
-
-// FORWARD DECLARATION
-namespace bmqp { class MessageProperties; }
-namespace bmqp { class MessagePropertiesIterator; }
-
-namespace bmqa {
-
- // =======================
- // class MessageProperties
- // =======================
-
-class MessageProperties {
- // Provide a VST representing message properties.
-
- // FRIENDS
- friend class MessagePropertiesIterator;
-
- private:
- // PRIVATE CONSTANTS
- static const int k_MAX_SIZEOF_BMQP_MESSAGEPROPERTIES = 176;
- // Constant representing the maximum size of a
- // 'bmqp::MessageProperties' object, so that the below AlignedBuffer
- // is big enough.
-
- // PRIVATE TYPES
- typedef
- bsls::AlignedBuffer<k_MAX_SIZEOF_BMQP_MESSAGEPROPERTIES> ImplBuffer;
-
- private:
- // DATA
- mutable bmqp::MessageProperties *d_impl_p;
- // Pointer to the implementation object
- // in 'd_buffer', providing a shortcut
- // type safe cast to that object. This
- // variable *must* *be* the first
- // member of this class, as other
- // components in bmqa package may
- // reinterpret_cast to that variable.
-
- ImplBuffer d_buffer;
- // Buffer containing the implementation
- // object, maximally aligned.
-
- bslma::Allocator *d_allocator_p;
-
- public:
- // PUBLIC CONSTANTS
- static const int k_MAX_NUM_PROPERTIES = 255;
- // Maximum number of properties that can appear in a 'bmqa::Message'.
-
- static const int k_MAX_PROPERTIES_AREA_LENGTH = (64 * 1024 * 1024) - 8;
- // Maximum length of all the properties (including their names, values
- // and the wire protocol overhead). Note that this value is just under
- // 64 MB.
-
- static const int k_MAX_PROPERTY_NAME_LENGTH = 4095;
- // Maximum length of a property name.
-
- static const int k_MAX_PROPERTY_VALUE_LENGTH = 67104745; // ~64 MB
- // Maximum length of a property value. Note that this value is just
- // under 64 MB. Also note that this value is calculated assuming that
- // there is only one property and property's name has maximum allowable
- // length, and also takes into consideration the protocol overhead.
-
- public:
- // TRAITS
- BSLMF_NESTED_TRAIT_DECLARATION(MessageProperties,
- bslma::UsesBslmaAllocator)
-
- // CREATORS
- explicit
- MessageProperties(bslma::Allocator *basicAllocator = 0);
- // Create an empty instance of 'MessageProperties'. Optionally
- // specify a 'basicAllocator' used to supply memory. Note that it is
- // more efficient to use a 'MessageProperties' object retrieved via
- // 'Session::loadMessageProperties', instead of creating it via this
- // constructor.
-
- MessageProperties(const MessageProperties& other,
- bslma::Allocator *basicAllocator = 0);
- // Create an instance of 'MessageProperties' having the same value as
- // the specified 'other', that will use the optionally specified
- // 'basicAllocator' to supply memory.
-
- ~MessageProperties();
- // Destroy this object.
-
- // MANIPULATORS
- MessageProperties& operator=(const MessageProperties& rhs);
- // Assign to this object the value of the specified 'rhs' object.
-
- bool remove(const bsl::string& name,
- bmqt::PropertyType::Enum *buffer = 0);
- // Remove the property with the specified 'name' if one exists and
- // return true and load into the optionally specified 'buffer' the data
- // type of the property. Return false if the 'name' property does not
- // exist, and leave the 'buffer' unchanged.
-
- void clear();
- // Remove all properties from this instance. Note that 'numProperties'
- // will return zero after invoking this method.
-
- int setPropertyAsBool(const bsl::string& name, bool value);
- int setPropertyAsChar(const bsl::string& name, char value);
- int setPropertyAsShort(const bsl::string& name, short value);
- int setPropertyAsInt32(const bsl::string& name, bsl::int32_t value);
- int setPropertyAsInt64(const bsl::string& name, bsls::Types::Int64 value);
- int setPropertyAsString(const bsl::string& name, const bsl::string& value);
- int setPropertyAsBinary(const bsl::string& name,
- const bsl::vector<char>& value);
- // Set a property with the specified 'name' having the specified
- // 'value' with the corresponding data type. Return zero on success,
- // and a non-zero value in case of failure. Note that if a property
- // with 'name' and the same type exists, it will be updated with the
- // provided 'value', however if the data type of the existing property
- // differs, an error will be returned.
-
- int streamIn(const bdlbb::Blob& blob);
- // Populate this instance with its BlazingMQ wire protocol
- // representation from the specified 'blob'. Return zero on success,
- // and a non-zero value otherwise.
-
- // ACCESSORS
- int numProperties() const;
- // Return the total number of properties set in this instance.
-
- int totalSize() const;
- // Return the total size (in bytes) of the wire representation of this
- // instance. Note that returned value includes the BlazingMQ wire
- // protocol overhead as well.
-
- bool hasProperty(const bsl::string& name,
- bmqt::PropertyType::Enum *type = 0) const;
- // Return true if a property with the specified 'name' exists and load
- // into the optionally specified 'type' the type of the property.
- // Return false otherwise.
-
- bmqt::PropertyType::Enum propertyType(const bsl::string& name) const;
- // Return the type of property having the specified 'name'. Behavior
- // is undefined unless 'hasProperty' returns true for the property
- // 'name'.
-
- bool getPropertyAsBool(const bsl::string& name) const;
- char getPropertyAsChar(const bsl::string& name) const;
- short getPropertyAsShort(const bsl::string& name) const;
- bsl::int32_t getPropertyAsInt32(const bsl::string& name) const;
- bsls::Types::Int64 getPropertyAsInt64(const bsl::string& name) const;
- const bsl::string& getPropertyAsString(const bsl::string& name) const;
- const bsl::vector<char>& getPropertyAsBinary(
- const bsl::string& name) const;
- // Return the property having the corresponding type and the specified
- // 'name'. Behavior is undefined unless property with 'name' exists.
-
- bool getPropertyAsBoolOr(const bsl::string& name, bool value) const;
- char getPropertyAsCharOr(const bsl::string& name, char value) const;
- short getPropertyAsShortOr(const bsl::string& name, short value) const;
- bsl::int32_t getPropertyAsInt32Or(const bsl::string& name,
- bsl::int32_t value) const;
- bsls::Types::Int64 getPropertyAsInt64Or(const bsl::string& name,
- bsls::Types::Int64 value) const;
- const bsl::string& getPropertyAsStringOr(const bsl::string& name,
- const bsl::string& value) const;
- const bsl::vector<char>& getPropertyAsBinaryOr(
- const bsl::string& name,
- const bsl::vector<char>& value) const;
- // Return the property having the corresponding type and the specified
- // 'name' if property with such a name exists. Return the specified
- // 'value' if property with 'name' does not exist.
-
- const bdlbb::Blob&
- streamOut(bdlbb::BlobBufferFactory *bufferFactory) const;
- // Return a blob having the BlazingMQ wire protocol representation of
- // this instance, using the specified 'bufferFactory' to build the
- // blob. Behavior is undefined unless 'bufferFactory' is non-null.
- // Note that if this instance is empty (i.e., 'numProperties()' == 0),
- // returned blob will be empty. In other words, an empty instance has
- // no wire representation.
-
- bsl::ostream& print(bsl::ostream& stream,
- int level = 0,
- int spacesPerLevel = 4) const;
- // Format this object to the specified output 'stream' at the (absolute
- // value of) the optionally specified indentation 'level' and return a
- // reference to 'stream'. If 'level' is specified, optionally specify
- // 'spacesPerLevel', the number of spaces per indentation level for
- // this and all of its nested objects. If 'level' is negative,
- // suppress indentation of the first line. If 'spacesPerLevel' is
- // negative format the entire output on one line, suppressing all but
- // the initial indentation (as governed by 'level'). If 'stream' is
- // not valid on entry, this operation has no effect.
-};
-
-// FREE OPERATORS
-bsl::ostream& operator<<(bsl::ostream& stream, const MessageProperties& rhs);
- // Format the specified 'rhs' to the specified output 'stream' and return a
- // reference to the modifiable 'stream'.
-
-
- // ===============================
- // class MessagePropertiesIterator
- // ===============================
-
-class MessagePropertiesIterator {
- // Provide a mechanism to iterator over all the properties in an instance
- // of 'bmqa::MessageProperties'. The order of the iteration is
- // implementation defined. An iterator is *valid* if it is associated with
- // a property , otherwise it is *invalid*. Behavior is undefined if the
- // underlying instance of 'bmqa::MessageProperties' is modified during the
- // lifetime of this iterator.
-
- private:
- // PRIVATE CONSTANTS
- static const int k_MAX_SIZEOF_BMQP_MESSAGEPROPERTIESITER = 64;
- // Constant representing the maximum size of a
- // 'bmqp::MessagePropertiesIterator' object, so that the below
- // AlignedBuffer is big enough.
-
- // PRIVATE TYPES
- typedef
- bsls::AlignedBuffer<k_MAX_SIZEOF_BMQP_MESSAGEPROPERTIESITER> ImplBuffer;
-
- private:
- // DATA
- mutable bmqp::MessagePropertiesIterator *d_impl_p;
- // Pointer to the implementation object
- // in 'd_buffer'. This variable *must*
- // *be* the first member of this class.
- // If the value is null, the object
- // has not been constructed in the
- // 'd_buffer'.
-
- ImplBuffer d_buffer;
- // Buffer containing the implementation
- // object
-
- public:
- // CREATORS
- MessagePropertiesIterator();
- // Create an empty iterator instance. The only valid operations that
- // can be invoked on an empty instance are copying, assignment and
- // destruction.
-
- explicit
- MessagePropertiesIterator(const MessageProperties *properties);
- // Create an iterator for the specified 'properties'. Behavior is
- // undefined unless 'properties' is not null.
-
- MessagePropertiesIterator(const MessagePropertiesIterator& other);
- // Copy constructor from the specified 'other'.
-
- ~MessagePropertiesIterator();
- // Destroy this iterator.
-
- // MANIPULATORS
- MessagePropertiesIterator&
- operator=(const MessagePropertiesIterator& rhs);
- // Assignment operator from the specified 'rhs'.
-
- bool hasNext();
- // Advance this iterator to refer to the next property of the
- // associated 'MessageProperties' instance, if there is one and return
- // true, return false otherwise. Behavior is undefined unless this
- // method is being invoked for the first time on this object or
- // previous call to 'hasNext' returned true. Note that the order of
- // the iteration is not specified.
-
- // ACCESSORS
- const bsl::string& name() const;
- // Return a reference offering non-modifiable access to the name of the
- // property being pointed by the iterator. Behavior is undefined
- // unless last call to 'hasNext' returned true.
-
- bmqt::PropertyType::Enum type() const;
- // Return the data type of property being pointed by the iterator.
- // Behavior is undefined unless last call to 'hasNext' returned true;
-
- bool getAsBool() const;
- char getAsChar() const;
- short getAsShort() const;
- bsl::int32_t getAsInt32() const;
- bsls::Types::Int64 getAsInt64() const;
- const bsl::string& getAsString() const;
- const bsl::vector<char>& getAsBinary() const;
- // Return property value having the corresponding type being currently
- // being pointed by this iterator instance. Behavior is undefined
- // unless last call to 'hasNext' returned true. Behavior is also
- // undefined unless property's data type matches the requested type.
-};
-
-} // close package namespace
-
-
-// ============================================================================
-// INLINE DEFINITIONS
-// ============================================================================
-
-
- // -----------------------
- // class MessageProperties
- // -----------------------
-
-inline
-bsl::ostream&
-bmqa::operator<<(bsl::ostream& stream,
- const bmqa::MessageProperties& rhs)
-{
- return rhs.print(stream, 0, -1);
-}
-
-} // close enterprise namespace
-
-#endif
-
-Generated on Thu Jun 15 2023 11:58:50 by
-
- 1.7.1
-
-
diff --git a/docs/docs/apidocs/cpp_apidocs/bmqa__mocksession_8h_source.html b/docs/docs/apidocs/cpp_apidocs/bmqa__mocksession_8h_source.html
deleted file mode 100644
index c03a47d6f..000000000
--- a/docs/docs/apidocs/cpp_apidocs/bmqa__mocksession_8h_source.html
+++ /dev/null
@@ -1,1541 +0,0 @@
-
-
-Bloomberg Development Environment
-
-
-// Copyright 2016-2023 Bloomberg Finance L.P.
-// SPDX-License-Identifier: Apache-2.0
-//
-// Licensed under the Apache License, Version 2.0 (the "License");
-// you may not use this file except in compliance with the License.
-// You may obtain a copy of the License at
-//
-// http://www.apache.org/licenses/LICENSE-2.0
-//
-// Unless required by applicable law or agreed to in writing, software
-// distributed under the License is distributed on an "AS IS" BASIS,
-// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-// See the License for the specific language governing permissions and
-// limitations under the License.
-
-// bmqa_mocksession.h -*-C++-*-
-#ifndef INCLUDED_BMQA_MOCKSESSION
-#define INCLUDED_BMQA_MOCKSESSION
-
-//@PURPOSE: Provide a mock session, implementing 'bmqa::AbstractSession'.
-//
-//@CLASSES:
-// bmqa::MockSession: mechanism to mock a 'bmqa::Session'
-// bmqa::MockSessionUtil: utility methods to create 'bmqa' events
-//
-//@DESCRIPTION: This component provides a mechanism implementing the
-// 'bmqa::AbstractSession' protocol, for mocking a 'bmqa::Session' and can be
-// used to write a test for an application that uses BMQ. The
-// 'bmqa::MockSession' provides all the methods that 'Session' provides, with
-// added methods to specify return codes and emitted events and expected calls.
-// This can be used to test BlazingMQ application code without a connection to
-// the broker. 'bmqa::MockSessionUtil' is a utility namespace providing useful
-// methods to build 'bmqa::Event' objects that are typically only emitted from
-// the broker.
-//
-// The following documentation elucidates the API that this component provides
-// and some simple use cases to get you started.
-//
-//
-///Disclaimer
-///----------
-// THIS COMPONENT SHOULD ONLY BE USED IN TEST DRIVERS. IT WILL NOT WORK WITH
-// PRODUCTION CODE.
-//
-//
-///Usable Components
-///-----------------
-//: o !BMQA_EXPECT_CALL!: Macro to specify an expected call to a
-//: 'bmqa::MockSession' object. This macro is used to
-//: specify which is the next expected call on the
-//: 'bmqa::MockSession'. If an incorrect call is invoked
-//: or incorrect parameters are used, an assert will be
-//: invoked.
-//
-//: o !returning! : Specify a return value for the expected call. This
-//: is the value that will be returned when the method on
-//: 'bmqa::MockSession' is invoked.
-//
-//: o !emitting! : Specify an event to be 'emitted' when the expected
-//: call is invoked. The events specified are enqueued
-//: to the internal event queue and are delivered to the
-//: application when 'emitEvent' is invoked.
-//
-///Static Helper Methods
-///---------------------
-//: o !createAckEvent! : Create an acknowledgment message event for
-//: messages posted to BMQ.
-//
-//: o !createPushEvent! : Create a push message event for messages to
-//: be consumed from BMQ.
-//
-//: o !createOpenQueueStatus! : Create an openQueue result (relating to an
-//: async open queue operation)
-//
-//: o !createConfigureQueueStatus!: Create a configureQueue result (relating to
-//: an async configure queue operation)
-//
-//: o !createCloseQueueStatus! : Create a closeQueue result (relating to an
-//: async close queue operation)
-//
-//: o !createSessionEvent! : Create a specified type of session event
-//: except for events related to open, close
-//: and configure queue.
-//
-// The static event builder specified above are typically built inside the
-// broker but are now available to be built in the SDK. The expected use of
-// such events is to build them and specify them to either the
-// 'BMQA_EXPECT_CALL' macro in the 'emitting' parameter, or enqueued to the
-// 'bmqa::MockSession' directly through the 'enqueueEvent' method. They can
-// then be emitted by invoking the 'emitEvent' method, which in turn would be
-// processed through the application-provided 'bmqa::SessionEventHandler'.
-//
-///Additional Note
-///---------------
-// 'MockSession' does not check if methods have been invoked in the correct
-// order. The user is responsible for ensuring that the methods are invoked
-// and events enqueued in the correct order.
-//
-// The following methods do not emit events:
-//: o 'getQueueId'
-//: o 'loadMessageEventBuilder'
-//: o 'loadConfirmEventBuilder'
-//: o 'loadMessageProperties'
-//: o 'confirmMessage'
-//: o 'confirmMessages'
-//
-// Calls to the following methods do not require an expect:
-//: o 'getQueueId'
-//: o 'loadMessageEventBuilder'
-//: o 'loadConfirmEventBuilder'
-//: o 'loadMessageProperties'
-//
-//
-///Creating a mock session in asynchronous mode
-///--------------------------------------------
-// The 'MockSession' is created in asynchronous mode when a
-// 'SessionEventHandler' is provided to it. If it is not provided a handler,
-// the 'MockSession' is started in synchronous mode, requiring the application
-// to call 'nextEvent' to access enqueued events. A sample handler could look
-// like this:
-//
-//..
-// class MyEventHandler : public bmqa::SessionEventHandler {
-//
-// private:
-// // DATA
-// bsl::deque<bmqa::SessionEvent> d_sessionEventsQueue;
-// bsl::deque<bmqa::MessageEvents> d_messageEventsQueue;
-// bsl::deque<bmqa::OpenQueueStatus> d_openQueueResultsQueue;
-// ...
-//
-// public:
-// // MANIPULATORS
-// virtual void onSessionEvent(const bmqa::SessionEvent& event)
-// {
-// bsl::cout << "Received session event " << event << "\n";
-// // some business logic, typically a switch case on
-// // 'bmqt::SessionEventType'
-// d_sessionEventsQueue.push_back(event);
-// }
-//
-// virtual void onMessageEvent(const bmqa::MessageEvent& event)
-// {
-// bsl::cout << "Received message event " << event << "\n";
-// // some business logic, typically a switch case on
-// // 'bmqt::MessageEventType'
-// d_messageEventsQueue.push_back(event);
-// }
-//
-// void onOpenQueueStatus(const bmqa::OpenQueueStatus& result)
-// {
-// bsl::cout << "Received open queue result: " << result << "\n";
-// // Some business logic
-// d_openQueueResultsQueue.push_back(result);
-// }
-// ...
-//
-// bmqa::SessionEvent popSessionEvent()
-// {
-// BSLS_ASSERT(d_sessionEventsQueue.size() > 0);
-// bmqa::SessionEvent ret(d_receivedSessionEvents.front());
-// d_receivedSessionEvents.pop_front();
-// return ret;
-// }
-//
-// bmqa::MessageEvent popMessageEvent()
-// {
-// BSLS_ASSERT(d_messageEventsSize.size() > 0);
-// bmqa::MessageEvent ret(d_receivedMessageEvents.front());
-// d_receivedMessageEvents.erase(d_receivedMessageEvents.begin());
-// return ret;
-// }
-//
-// bmqa::OpenQueueStatus popOpenQueueStatus()
-// {
-// BSLS_ASSERT(d_openQueueResultsQueue.size() > 0);
-// bmqa::OpenQueueStatus ret(d_openQueueResultsQueue.front());
-// d_openQueueResultsQueue.erase(d_openQueueResultsQueue.begin());
-// return ret;
-// }
-// ...
-// };
-//..
-//
-///Usage
-///-----
-// This section illustrates intended use of this component.
-//
-///Example 1
-///- - - - -
-// The folowing example shows a simple producer in asynchronous mode, which
-// will start the session, open a queue, post a message to the queue, generate
-// an ack for that message and finally stop the session (skipping over close
-// queue because it is analogous to opening a queue). In theory, you can use
-// 'emitting' on the 'BMQA_EXPECT_CALL' macro and 'enqueueEvent'
-// interchangeably, but in practice it is important to note that events from
-// the broker are generated asynchronously, which means that they are not
-// emitted as you call the method. You can control emission of events,
-// however, by delaying the call to 'emitEvent'.
-//
-// NOTE: As with 'bmqa::Session', calling 'nextEvent' is meaningless in
-// asynchronous mode.
-//
-//..
-// void unitTest()
-// {
-// // Create an event handler
-// EventHandler eventHandler(d_allocator_p);
-//
-// // The following static initializer method calls all the appropriate
-// // static initializers of the underlying components needed for the
-// // 'MockSession'. The constructor of 'MockSession' will call it in
-// // any case but if events need to be built outside the scope of the
-// // creation of 'MockSession' you will need to explicitly invoke this
-// // static initializer method.
-// // bmqa::MockSession::initialize(s_allocator_p);
-//
-// bslma::ManagedPtr<bmqa::SessionEventHandler> handlerMp;
-// handlerMp.load(&eventHandler, 0, bslma::ManagedPtrUtil::noOpDeleter);
-//
-// bmqa::MockSession mockSession(handlerMp,
-// bmqt::SessionOptions(d_allocator_p),
-// d_allocator_p);
-//
-// bmqa::QueueId queueId(bmqt::CorrelationId(1), d_allocator_p);
-// bmqt::CorrelationId corrId(1);
-//
-// // Expect a call to start and the call emits an 'e_CONNECTED' event.
-// BMQA_EXPECT_CALL(mockSession, startAsync())
-// .returning(0)
-// .emitting(bmqa::MockSessionUtil::createSessionEvent(
-// bmqt::SessionEventType::e_CONNECTED,
-// 0, // statusCode
-// "", // errorDescription
-// d_allocator_p));
-//
-// // Make a call to startAsync and emit the event that is enqueued from
-// // that call.
-// ASSERT_EQ(mockSession.startAsync(), 0);
-//
-// // Emit our enqueued event. This fully sets up the session which is
-// // now ready to use. Typically you would have some business logic on
-// // 'e_CONNECTED' that makes your application ready to use.
-// ASSERT_EQ(mockSession.emitEvent(), true);
-//
-// // Our event handler internally just stores the event emitted, so pop
-// // it out and examine.
-// bmqa::SessionEvent startEvent(eventHandler.popSessionEvent());
-//
-// ASSERT_EQ(startEvent.type(), bmqt::SessionEventType::e_CONNECTED);
-// ASSERT_EQ(startEvent.statusCode(), 0);
-//
-// // Create the uri to your queue as you would in your application.
-// const bmqt::Uri uri("bmq://my.domain/queue");
-//
-// // Initialize the queue flags for a producer with acks enabled
-// bsls::Types::Uint64 flags = 0;
-// bmqt::QueueFlagsUtil::setWriter(&flags);
-// bmqt::QueueFlagsUtil::setAck(&flags);
-//
-// // We use the macro to expect a call to 'openQueueAsync', binding the
-// // 'uri' and 'queueId' objects as well as the 'flags' that we created.
-// bmqa::MockSession::OpenQueueCallback openQueueCallback =
-// bdlf::BindUtil::bind(&EventHandler::onOpenQueueStatus,
-// &eventHandler,
-// bdlf::PlaceHolders::_1); // result
-//
-// BMQA_EXPECT_CALL(mockSession,
-// openQueueAsync(uri1,
-// flags,
-// openQueueCallback));
-// BMQA_EXPECT_CALL(mockSession,
-// openQueueAsync(uri, flags, openQueueCallback));
-//
-// // Now that we have set our expectations we can try to open the queue.
-// mockSession.openQueueAsync(uri1, flags, openQueueCallback);
-//
-// // Since the application may not have direct access to the queue, we
-// // need to get the 'queueId' from the session. We can then bind this
-// // retrieved 'queueId' to the 'e_QUEUE_OPEN_RESULT' session event and
-// // enqueue it to the 'MockSession'.
-// // Note: You can only get the 'queueId' after 'openQueue' or
-// // 'openQueueAsync' has been invoked on the session.
-// bmqa::QueueId queueId1(corrId1);
-// bmqa::OpenQueueStatus openQueueResult =
-// bmqa::MockSessionUtil::createOpenQueueStatus(
-// queueId1,
-// bmqt::OpenQueueResult::e_TIMEOUT, // statusCode
-// "Local Timeout", // errorDescription
-// d_allocator_p);
-// mockSession.enqueueEvent(openQueueResult);
-//
-// // We just enqueued a 'bmqa::OpenQueueStatus' to be emitted. We can
-// // emit it using 'emitEvent'.
-// ASSERT_EQ(mockSession.emitEvent(), true);
-//
-// // Pop out this event from the handler and examine it.
-// bmqa::OpenQueueStatus result = eventHandler.popOpenQueueStatus();
-// ASSERT_EQ(result, openQueueResult);
-//
-// // On emission of 'bmqa::OpenQueueStatus', the queue is fully open and
-// // we can now post to it.
-// bmqa::MessageEventBuilder builder;
-// mockSession.loadMessageEventBuilder(&builder);
-//
-// BMQA_EXPECT_CALL(mockSession, post(builder.messageEvent()))
-// .returning(0);
-//
-// // Use the builder to build a mesage event and pack it for the queue
-// // that has been opened. If you try to pack the message for an
-// // invalid or closed queue, packing the message will fail. This has
-// // been elided for brevity.
-//
-// // Now that the event has been built we can 'post' it to BMQ.
-// ASSERT_EQ(mockSession.post(builder.messageEvent()), 0);
-//
-// // Simply creating a blob buffer factory on the stack to be used by
-// // 'createAckEvent'. Typically you would have one for the component.
-// bdlbb::PooledBlobBufferFactory bufferFactory(4 * 1024, d_allocator_p);
-//
-// // The method 'createAckEvent' takes a vector of 'AckParams' to
-// // specify multiple acks per event, but here we are only acknowledging
-// // 1 message. Specify a positive ack with 'e_SUCCESS' here but you
-// // can specify any from 'bmqt::AckResult::Enum'.
-// bsl::vector<bmqa::MockSessionUtil::AckParams> acks(d_allocator_p);
-// acks.emplace_back(bmqt::AckResult::e_SUCCESS,
-// bmqt::CorrelationId(1),
-// bmqt::MessageGUID(), // Real GUID needed if you want
-// // to record ack messages.
-// bmqa::QueueId(1));
-//
-// // Enqueuing ack event to be emitted. We use the helper function
-// // 'createAckEvent' to generate this event.
-// mockSession.enqueueEvent(bmqa::MockSessionUtil::createAckEvent(
-// acks,
-// &bufferFactory,
-// d_allocator_p));
-//
-// // Emit the enqueued ack event.
-// ASSERT_EQ(mockSession.emitEvent(), true);
-//
-// // As we did earlier, pop it out and examine.
-// bmqa::MessageEvent ackEvent(eventHandler.popMessageEvent());
-// ASSERT_EQ(ackEvent.type(), bmqt::MessageEventType::e_ACK);
-// bmqa::MessageIterator mIter = ackEvent.messageIterator();
-// mIter.nextMessage();
-// ASSERT_EQ(mIter.message().ackStatus(), bmqt::AckResult::e_SUCCESS);
-//
-// // This is a simple test. After posting our message and receiving the
-// // ack, we are now shutting down our application. Therefore we expect
-// // a 'stopAsync' call.
-// BMQA_EXPECT_CALL(mockSession, stopAsync());
-//
-// // Now make a call to 'stopAsync' to stop our session.
-// mockSession.stopAsync();
-//
-// // Here we are enqueuing an 'e_DISCONNECTED' event as you would
-// // receive from the broker on a successful shutdown.
-// mockSession.enqueueEvent(bmqa::MockSessionUtil::createSessionEvent(
-// bmqt::SessionEventType::e_DISCONNECTED,
-// 0, // statusCode
-// "", // errorDescription
-// d_allocator_p));
-// ASSERT_EQ(mockSession.emitEvent(), true);
-//
-// // Our event handler internally just stores the event emitted, so pop
-// // it out and examine.
-// bmqa::SessionEvent stopEvent(eventHandler.popSessionEvent());
-// ASSERT_EQ(stopEvent.type(), bmqt::SessionEventType::e_DISCONNECTED);
-// ASSERT_EQ(stopEvent.statusCode(), 0);
-//
-// // The corresponding pendant operation of the 'initialize' which would
-// // need to be called only if 'initialize' was explicitly called.
-// // bmqa::MockSession::shutdown();
-// }
-//..
-//
-///Example 2
-///- - - - -
-// The folowing example shows a consumer in synchronous mode, which will start
-// the session, generate a push message (simulating the broker), confirm the
-// message and then stop the session. Additionally, this test case also sets
-// all expectations up front before running the code, as this is the alternate
-// way of writing your test driver.
-//
-// NOTE: Using 'enqueue' or 'emitEvent' on 'bmqa::MockSession' or 'emitting' on
-// the 'BMQA_EXPECT_CALL' macro in synchronous mode is meaningless.
-//
-//..
-// void unitTest()
-// {
-// // MockSession created without an eventHandler.
-// bmqa::MockSession mockSession(bmqt::SessionOptions(d_allocator_p),
-// d_allocator_p);
-//
-// // The following static initializer method calls all the appropriate
-// // static initializers of the underlying components needed for the
-// // 'MockSession'. The constructor of 'MockSession' will call it in
-// // any case but if events need to be built outside the scope of the
-// // creation of 'MockSession' you will need to explicitly invoke this
-// // static initializer method.
-// // bmqa::MockSession::initialize(s_allocator_p);
-//
-// // Create simple queueIds and corrIds
-// bmqa::QueueId queueId(1);
-// bmqt::CorrelationId corrId(1);
-//
-// // Create the uri to your queue as you would in your application.
-// bmqt::Uri uri("bmq://my.domain/queue");
-//
-// // Expecting that 'startAsync' will be called on the MockSession.
-// BMQA_EXPECT_CALL(mockSession, startAsync())
-// .returning(0);
-//
-// // Simply creating a blob buffer factory on the stack to be used by
-// // 'createAckEvent'. Typically you would have one for the component.
-// bdlbb::PooledBlobBufferFactory bufferFactory(4 * 1024, d_allocator_p);
-//
-// // We then expect that 'nextEvent' will be called to return the
-// // 'e_CONNECTED' event from the broker
-// BMQA_EXPECT_CALL(mockSession, nextEvent(bsls::TimeInterval()))
-// .returning(bmqa::MockSessionUtil::createSessionEvent(
-// bmqt::SessionEventType::e_CONNECTED,
-// bmqt::CorrelationId::autoValue(),
-// 0, // errorCode
-// "", // errorDescription
-// d_allocator_p));
-// // Note that we use an 'autoValue' for correlationId because it's
-// // irrelevant for a 'CONNECTED' event.
-//
-// // Initialize the queue flags for a consumer
-// bsls::Types::Uint64 flags = 0;
-// bmqt::QueueFlagsUtil::setReader(&flags);
-//
-// // We use the macro to expect a call to 'openQueueSync', binding the
-// // 'uri' and 'queueId' objects as well as the flags that we created.
-// // Note that the 'queueId' object will be modified as 'openQueueSync'
-// // takes it as an output parameter.
-// bmqa::OpenQueueStatus expectedResult =
-// bmqa::MockSessionUtil::createOpenQueueStatus(
-// queueId,
-// bmqt::OpenQueueResult::e_SUCCESS, // statusCode
-// "", // errorDescription
-// d_allocator_p);
-// BMQA_EXPECT_CALL(mockSession, openQueueSync(&queueId, uri, flags))
-// .returning(expectedResult);
-//
-// // Build our incoming message event.
-// bsl::vector<bmqa::MockSessionUtil::PushMessageParams> pushMsgs(
-// d_allocator_p);
-// bdlbb::Blob payload(&bufferFactory, d_allocator_p);
-// bdlbb::BlobUtil::append(&payload, "hello", 6);
-//
-// const char guidHex[] = "00000000000000000000000000000001";
-// bmqt::MessageGUID guid;
-// guid.fromHex(guidHex);
-//
-// bmqa::MessageProperties properties;
-// mockSession.loadMessageProperties(&properties);
-//
-// // For each message that we are supposed to receive from the broker,
-// // we need to specify the payload, the queueId, a guid (the hex is
-// // random but unique within your test driver) and properties which
-// // could be empty.
-// pushMsgs.emplace_back(payload, queueId, guid, properties);
-// bmqa::Event pushMsgEvent = bmqa::MockSessionUtil::createPushEvent(
-// pushMsgs,
-// &bufferFactory,
-// d_allocator_p);
-// BMQA_EXPECT_CALL(mockSession, nextEvent(bsls::TimeInterval()))
-// .returning(pushMsgEvent);
-//
-// // Next we expect a call to 'confirmMessages', to confirm the 1 message
-// // that we received from the broker.
-// bmqa::ConfirmEventBuilder confirmBuilder;
-// mockSession.loadConfirmEventBuilder(&confirmBuilder);
-// BMQA_EXPECT_CALL(mockSession, confirmMessages(&confirmBuilder))
-// .returning(0);
-//
-// // Expectations have been set up. Now we run the code.
-// // 'startAsync' is the first call. We expect it to return 0 and we
-// // expect 'nextEvent' to return the 'e_CONNECTED' session event.
-// int rc = mockSession.startAsync();
-// ASSERT_EQ(rc, 0);
-// bmqa::SessionEvent startEvent = mockSession.nextEvent(
-// bsls::TimeInterval())
-// .sessionEvent();
-// ASSERT_EQ(startEvent.type(), bmqt::SessionEventType::e_CONNECTED);
-// ASSERT_EQ(startEvent.statusCode(), 0);
-// ASSERT_EQ(startEvent.errorDescription(), "");
-//
-// // Next we expect a call to 'openQueue' to open the queue.
-// bmqa::OpenQueueStatus result = mockSession.openQueueSync(&queueId,
-// uri,
-// 10);
-// ASSERT_EQ(result, expectedResult);
-//
-// // Now our call to 'nextEvent' will generate a push message from the
-// // broker, which we will then go on to confirm.
-// bmqa::MessageEvent pushMsgEvt(mockSession.nextEvent(
-// bsls::TimeInterval())
-// .messageEvent());
-// ASSERT_EQ(pushMsgEvt.type(), bmqt::MessageEventType::e_PUSH);
-//
-// // Now that we have received a push message which has yet to be
-// // confirmed, we can confirm that 1 unconfirmed message exists.
-// ASSERT_EQ(mockSession.unconfirmedMessages(), 1U);
-//
-// // Since there is only 1 message in our message event, we dont have to
-// // iterate over the event but in reality you will want to iterate over
-// // each message and add it to the confirm builder.
-// bmqa::MessageIterator mIter = pushMsgEvt.messageIterator();
-// mIter.nextMessage();
-// confirmBuilder.addMessageConfirmation(mIter.message());
-// ASSERT_EQ(confirmBuilder.messageCount(), 1);
-//
-// // Confirm the messages using the builder that has been populated.
-// rc = mockSession.confirmMessages(&confirmBuilder);
-// ASSERT_EQ(rc, 0);
-//
-// // Voila! We now have no unconfirmed messages.
-// ASSERT_EQ(mockSession.unconfirmedMessages(), 0u);
-// // 'stop' has been elided for brevity and is analogous to 'start'
-//
-// // The corresponding pendant operation of the 'initialize' which would
-// // need to be called only if 'initialize' was explicitly called.
-// // bmqa::MockSession::shutdown();
-// }
-//..
-//
-///Thread Safety
-///-------------
-// THREAD SAFE.
-
-// BMQ
-#include <bmqa_abstractsession.h>
-#include <bmqa_closequeuestatus.h>
-#include <bmqa_configurequeuestatus.h>
-#include <bmqa_messageeventbuilder.h>
-#include <bmqa_openqueuestatus.h>
-#include <bmqa_queueid.h>
-#include <bmqa_session.h> // for 'bmqa::SessionEventHandler'
-#include <bmqscm_version.h>
-#include <bmqt_queueoptions.h>
-#include <bmqt_sessionoptions.h>
-
-// MWC
-#include <mwcst_statcontext.h>
-
-// BDE
-#include <ball_log.h>
-#include <bdlb_variant.h>
-#include <bdlbb_blob.h>
-#include <bdlbb_pooledblobbufferfactory.h>
-#include <bsl_cstddef.h>
-#include <bsl_deque.h>
-#include <bsl_functional.h>
-#include <bsl_memory.h>
-#include <bsl_string.h>
-#include <bsl_unordered_map.h>
-#include <bsl_unordered_set.h>
-#include <bslma_allocator.h>
-#include <bslma_managedptr.h>
-#include <bslma_usesbslmaallocator.h>
-#include <bslmf_nestedtraitdeclaration.h>
-#include <bslmt_mutex.h>
-#include <bsls_alignedbuffer.h>
-#include <bsls_assert.h>
-#include <bsls_timeinterval.h>
-#include <bsls_types.h>
-
-namespace BloombergLP {
-
-// FORWARD DECLARATION
-namespace bmqimp { class Event; }
-namespace bmqimp { class MessageCorrelationIdContainer; }
-namespace bmqimp { struct Stat; }
-
-
-namespace bmqa {
-
-// FORWARD DECLARATION
-class ConfirmEventBuilder;
-
-// Record an expected method 'CALL' into the specified mock session 'OBJ'.
-#define BMQA_EXPECT_CALL(OBJ, CALL) \
- (((OBJ).expect_ ## CALL).fromLocation(__FILE__, __LINE__))
-
-
- // ======================
- // struct MockSessionUtil
- // ======================
-
-struct MockSessionUtil {
- // Utility methods to create 'bmqa' events
-
- private:
- // PRIVATE TYPES
- typedef bsl::shared_ptr<bmqimp::Event> EventImplSp;
- // Event impl shared pointer to access
- // the pimpl of 'bmqa::Event'.
-
- typedef bsl::shared_ptr<bmqimp::Queue> QueueImplSp;
- // Queue impl shared pointer to access
- // the pimpl of 'bmqa::QueueId'.
-
- public:
- // PUBLIC TYPES
- struct AckParams {
- // Struct representing parameters for an ack message.
-
- // PUBLIC DATA
- bmqt::AckResult::Enum d_status; // Status code
-
- bmqt::CorrelationId d_correlationId;
- // Correlation id
-
- bmqt::MessageGUID d_guid; // Message GUID of confirmed message
-
- QueueId d_queueId;
- // Queue id for message being referred
- // to
-
- // CREATORS
- AckParams(const bmqt::AckResult::Enum status,
- const bmqt::CorrelationId& correlationId,
- const bmqt::MessageGUID& guid,
- const bmqa::QueueId& queueId);
- // Create a new AckParams object with the specified 'status',
- // 'correlationId', 'guid' and 'queueId'.
- };
-
- // PUBLIC TYPES
- struct PushMessageParams {
- // Struct representing parameters for a push message.
-
- // PUBLIC DATA
- bdlbb::Blob d_payload; // Payload of message
-
- QueueId d_queueId; // Queue Id for this message
-
- bmqt::MessageGUID d_guid; // GUID for message
-
- MessageProperties d_properties; // Optionally specified properties for
- // message
-
- // CREATORS
- PushMessageParams(const bdlbb::Blob& payload,
- const bmqa::QueueId& queueId,
- const bmqt::MessageGUID& guid,
- const MessageProperties& properties);
- // Create a new PushMessageParams object with the specified
- // 'payload', 'queueId', 'guid' and 'properties'.
- };
-
- // CLASS METHODS
- static
- Event createAckEvent(const bsl::vector<AckParams>& acks,
- bdlbb::BlobBufferFactory *bufferFactory,
- bslma::Allocator *allocator);
- // Create and return an 'Event' configured as a message event of type
- // 'e_ACK' with the specified 'acks' params using the specified
- // 'bufferFactory' and the specified 'allocator' to supply memory.
-
- static
- Event
- createPushEvent(const bsl::vector<PushMessageParams>& pushEventParams,
- bdlbb::BlobBufferFactory *bufferFactory,
- bslma::Allocator *allocator);
- // Create and return an 'Event' configured as a message event of type
- // 'e_PUSH' and with the specified 'pushEventParams', using the
- // specified 'bufferFactory' and the specified 'allocator' to supply
- // memory.
-
- static
- Event
- createQueueSessionEvent(bmqt::SessionEventType::Enum sessionEventType,
- QueueId *queueId,
- const bmqt::CorrelationId& correlationId,
- int errorCode,
- const bslstl::StringRef& errorDescription,
- bslma::Allocator *allocator);
- // DEPRECATED: Use the 'createOpenQueueStatus(...)',
- // 'createConfigureQueueStatus(...)', or
- // 'createCloseQueueStatus(...)' methods instead. This
- // method will be marked as 'BSLS_ANNOTATION_DEPRECATED' in
- // future release of libbmq.
-
- static
- Event createSessionEvent(bmqt::SessionEventType::Enum sessionEventType,
- const bmqt::CorrelationId& correlationId,
- const int errorCode,
- const bslstl::StringRef& errorDescription,
- bslma::Allocator *allocator);
- // Create and return an 'Event' configured as a session event with the
- // specified 'sessionEventType', 'errorCode' and 'errorDescription' and
- // using the specified 'allocator' to supply memory. Note that this
- // method will not create queue related session events.
-
- static
- OpenQueueStatus
- createOpenQueueStatus(const QueueId& queueId,
- bmqt::OpenQueueResult::Enum statusCode,
- const bsl::string& errorDescription,
- bslma::Allocator *allocator = 0);
- // Create and return a 'bmqa::OpenQueueStatus' object with the
- // specified 'queueId', 'statusCode', and 'errorDescription', using the
- // optionally specified 'allocator' to supply memory in the result.
-
- static
- ConfigureQueueStatus
- createConfigureQueueStatus(
- const QueueId& queueId,
- bmqt::ConfigureQueueResult::Enum statusCode,
- const bsl::string& errorDescription,
- bslma::Allocator *allocator = 0);
- // Create and return a 'bmqa::ConfigureQueueStatus' object with the
- // specified 'queueId', 'statusCode', and 'errorDescription', using the
- // optionally specified 'allocator' to supply memory in the result.
-
- static
- CloseQueueStatus
- createCloseQueueStatus(const QueueId& queueId,
- bmqt::CloseQueueResult::Enum statusCode,
- const bsl::string& errorDescription,
- bslma::Allocator *allocator = 0);
- // Create and return a 'bmqa::CloseQueueStatus' object with the
- // specified 'queueId', 'statusCode', and 'errorDescription', using the
- // optionally specified 'allocator' to supply memory in the result.
-};
-
-
- // =================
- // class MockSession
- // =================
-
-class MockSession : public AbstractSession {
- // Mechanism to mock a 'bmqa::Session'
-
- public:
- // CLASS METHODS
- static void initialize(bslma::Allocator *allocator = 0);
- // Perform a one time initialization needed by components used in
- // 'MockSession' and 'MockSessionUtil'. This method only needs to be
- // called once before any other method, but can be called multiple
- // times provided that for each call to 'initialize' there is a
- // corresponding call to 'shutdown'. Use the optionally specified
- // 'allocator' for any memory allocation, or the 'global' allocator if
- // none is provided. Note that specifying the allocator is provided
- // for test drivers only, and therefore users should let it default to
- // the global allocator.
- // NOTE: This method will need to be invoked only if the application
- // needs to use 'MockSessionUtil' outside the scope of
- // 'MockSession'.
-
- static void shutdown();
- // Pendant operation of the 'initialize' one. The number of calls to
- // 'shutdown' must equal the number of calls to 'initialize', without
- // corresponding 'shutdown' calls, to fully destroy the objects. It is
- // safe to call 'initialize' after calling 'shutdown'. The behaviour
- // is undefined if 'shutdown' is called without 'initialize' first
- // being called.
-
- // PUBLIC TYPES
- typedef bsl::function<void (const char *description,
- const char *file,
- int line)> FailureCb;
- // Callback used to inform the test driver of an assertion failure.
- // The application test driver using the 'MockSession' may provide an
- // implementation that makes the test driver fail (for instance,
- // calling BDE's test driver ASSERT macro).
-
- private:
- // CLASS-SCOPE CATEGORY
- BALL_LOG_SET_CLASS_CATEGORY("BMQA.MOCKSESSION");
-
- private:
- // CONSTANTS
- static const int k_MAX_SIZEOF_MWCC_TWOKEYHASHMAP = 256;
- // Constant representing the maximum size of a 'mwcc::TwoKeyHashMap'
- // object, so that the below AlignedBuffer is big enough. No 'mwc'
- // headers can be included in 'bmq' public headers, to prevent build
- // time dependency.
-
- // PRIVATE TYPES
- typedef bsls::AlignedBuffer<k_MAX_SIZEOF_MWCC_TWOKEYHASHMAP>
- TwoKeyHashMapBuffer;
- // Aligned buffer holding the two key hash map
-
- typedef bsl::shared_ptr<bmqimp::Queue> QueueImplSp;
- // Cast for bmqimp::Queue to access internal data
-
- typedef bsl::shared_ptr<bmqimp::Event> EventImplSp;
- // Cast for bmqimp::Event to access internal data
-
- typedef bsl::shared_ptr<bmqimp::Stat> StatImplSp;
- // Convenience for bmqimp::Stat
-
- typedef bsl::shared_ptr<bmqimp::MessageCorrelationIdContainer>
- CorrelationIdContainerSp;
- // Convenience for bmqimp::MessageCorrelationIdContainer
-
- typedef bsl::function<void()> CallbackFn;
-
- struct Job {
- // Struct holding attributes associated with an asynchronous queue
- // operation executed with a user-specified callback
-
- // PUBLIC DATA
- CallbackFn d_callback;
- // Signature of a 'void' callback method
-
- QueueImplSp d_queue;
- // Queue associated with this job
-
- bmqt::SessionEventType::Enum d_type;
- // Type of queue event associated with
- // this job (OPEN,CONFIGURE, or CLOSE)
-
- int d_status;
- // Status of the queue operation
- };
-
- typedef bdlb::Variant<Event, Job> EventOrJob;
-
- enum Method {
- // Enumeration for the methods in the 'MockSession' protocol. Each
- // enum value corresponds to a method.
- e_START
- , e_START_ASYNC
- , e_STOP
- , e_STOP_ASYNC
- , e_FINALIZE_STOP
- , e_OPEN_QUEUE
- , e_OPEN_QUEUE_SYNC
- , e_OPEN_QUEUE_ASYNC
- , e_OPEN_QUEUE_ASYNC_CALLBACK
- , e_CLOSE_QUEUE
- , e_CLOSE_QUEUE_SYNC
- , e_CLOSE_QUEUE_ASYNC
- , e_CLOSE_QUEUE_ASYNC_CALLBACK
- , e_CONFIGURE_QUEUE
- , e_CONFIGURE_QUEUE_SYNC
- , e_CONFIGURE_QUEUE_ASYNC
- , e_CONFIGURE_QUEUE_ASYNC_CALLBACK
- , e_NEXT_EVENT
- , e_POST
- , e_CONFIRM_MESSAGE
- , e_CONFIRM_MESSAGES
- };
-
- struct Call {
- // PUBLIC TYPES
- typedef bsl::vector<EventOrJob> EventsAndJobs; // Vector of events
-
- // PUBLIC DATA
- int d_rc;
- // Value to be returned on call
-
- Method d_method;
- // The type of method
-
- int d_line;
- // Line number
-
- bsl::string d_file;
- // File
-
- bmqt::Uri d_uri;
- // Uri associated with this call
-
- bsls::Types::Uint64 d_flags;
- // Flags associated with this call
-
- bmqt::QueueOptions d_queueOptions;
- // QueueOptions associated with this
- // call
-
- bsls::TimeInterval d_timeout;
- // Timeout interval associated with
- // this call
-
- OpenQueueCallback d_openQueueCallback;
- // Callback to be invoked upon emission
- // of an async openQueue (if callback
- // was provided)
-
- ConfigureQueueCallback d_configureQueueCallback;
- // Callback to be invoked upon emission
- // of an async configureQueue (if
- // callback was provided)
-
- CloseQueueCallback d_closeQueueCallback;
- // Callback to be invoked upon emission
- // of an async closeQueue (if callback
- // was provided)
-
- bmqa::OpenQueueStatus d_openQueueResult;
- // The result of an open queue
- // operation
-
- bmqa::ConfigureQueueStatus d_configureQueueResult;
- // The result of a configure queue
- // operation
-
- bmqa::CloseQueueStatus d_closeQueueResult;
- // The result of a close queue
- // operation
-
- EventsAndJobs d_emittedEvents;
- // Events to be emitted on this call
-
- Event d_returnEvent;
- // Event to be returned on this call
-
- MessageEvent d_messageEvent;
- // MessageEvent associated with this
- // call
-
- MessageConfirmationCookie d_cookie;
- // MessageConfirmationCookie associated
- // with this call
-
- bslma::Allocator *d_allocator_p;
- // Allocator
-
- // TRAITS
- BSLMF_NESTED_TRAIT_DECLARATION(Call, bslma::UsesBslmaAllocator)
-
- // CREATORS
- Call(Method method, bslma::Allocator *allocator);
- // Create a Call object having the specified 'method' and the
- // specified 'allocator' to supply memory.
-
- Call(const Call& other, bslma::Allocator *allocator);
-
- // MANIPULATORS
- Call& fromLocation(const char* file, int line);
- // Record the specified 'file' and 'line' that this call was
- // created from.
- //
- // NOTE: This function is invoked through the macro only.
-
- Call& returning(int rc);
- // Specify the return value for this function call to be the
- // specified 'rc'.
-
- Call& returning(const bmqa::OpenQueueStatus& result);
- // Specify the return value for this function call to be the
- // specified 'result'. The behavior is undefined unless this call
- // corresponds to a synchronous open queue.
-
- Call& returning(const bmqa::ConfigureQueueStatus& result);
- // Specify the return value for this function call to be the
- // specified 'result'. The behavior is undefined unless this call
- // corresponds to a synchronous configure queue.
-
- Call& returning(const bmqa::CloseQueueStatus& result);
- // Specify the return value for this function call to be the
- // specified 'result'. The behavior is undefined unless this call
- // corresponds to a synchronous close queue.
-
- Call& returning(const Event& event);
- // Specify the return value for this function call to be the
- // specified 'event'.
-
- Call& emitting(const Event& event);
- // Specify the specified 'event' to be emitted on this function
- // call.
-
- Call& emitting(const OpenQueueStatus& openQueueResult);
- // Specify the specified 'openQueueResult' to be emitted on this
- // function call. The behavior is undefined unless the call is an
- // 'openQueueAsync' provided a callback.
-
- Call& emitting(const ConfigureQueueStatus& configureQueueResutl);
- // Specify the specified 'configureQueueResult' to be emitted on
- // this function call. The behavior is undefined unless the call
- // is a 'configureQueueResult' provided a callback.
-
- Call& emitting(const CloseQueueStatus& closeQueueResult);
- // Specify the specified 'closeQueueResult' to be emitted on this
- // function call. The behavior is undefined unless the call is a
- // 'closeQueueResult' provided a callback.
-
- // ACCESSORS
- const char* methodName() const;
- // Get the method name of this call.
- };
-
- typedef bsl::deque<Call> CallQueue;
- // Queue of expected calls
-
- typedef bsl::deque<bmqa::MessageEvent> PostedEvents;
- // Queue of posted events
-
- // DATA
- bdlbb::PooledBlobBufferFactory d_blobBufferFactory;
- // Buffer factory
-
- bslma::ManagedPtr<SessionEventHandler> d_eventHandler_mp;
- // Event handler (set only in
- // asynchronous mode)
-
- mutable CallQueue d_calls;
- // sequence of method calls that are
- // expected
-
- mutable bsl::deque<EventOrJob> d_eventsAndJobs;
- // events waiting to be emitted
-
- bsl::unordered_set<bmqt::MessageGUID> d_unconfirmedGUIDs;
- // GUIDS of unconfirmed messages
-
- TwoKeyHashMapBuffer d_twoKeyHashMapBuffer;
- // Aligned buffer of two key hash map
- // uri, corrid to queues
-
- FailureCb d_failureCb;
- // Currently installed failure callback
- // that is invoked if methods are
- // called incorrectly or out of order.
-
- int d_lastQueueId;
- // QueueId
-
- CorrelationIdContainerSp d_corrIdContainer_sp;
- // Mock correlationId container
-
- PostedEvents d_postedEvents;
- // Queue of posted events
-
- mutable bslmt::Mutex d_mutex;
- // protects all public methods
-
- mwcst::StatContext d_rootStatContext;
- // Top level stat context for this
- // mocked Session.
-
- StatImplSp d_queuesStats_sp;
- // Stats for all queues
-
- bmqt::SessionOptions d_sessionOptions;
- // Session Options for current session
-
- bslma::Allocator *d_allocator_p;
- // Allocator
-
- private:
- // PRIVATE CLASS METHODS
- static const char *toAscii(const Method method);
- // Get the string representation of the specified 'method'.
-
- // PRIVATE MANIPULATORS
- void initializeStats();
- // Configure this component to keep track of statistics.
-
- void
- openQueueImp(QueueId *queueId,
- const bmqt::QueueOptions& options,
- const bmqt::Uri& uri,
- bsls::Types::Uint64 flags,
- bool async);
- // Open the specified 'queueId' with the specified 'uri' and 'flags'.
- // If the specified 'async' param is true, set the state of the
- // specified 'queueId' to 'e_OPENING', else set it to 'e_OPENED. This
- // is to account for the fact that in 'openQueue' blocks until the
- // queue is opened whereas 'openQueueAsync' returns immediately and the
- // state changes to opened on emission of a successfull open queue
- // response.
-
- void processIfQueueEvent(Event *event);
- // Modify the queues specified by the 'event' if this event is a
- // session event of type 'e_QUEUE_OPEN_RESULT' or
- // 'e_QUEUE_CLOSE_RESULT'.
-
- void processIfQueueJob(Job *job);
- // Modify the queue(s) associated with the specified 'job' if this job
- // is associated with an operation of type 'e_QUEUE_OPEN_RESULT' or
- // 'e_QUEUE_CLOSE_RESULT'.
-
- void processIfPushEvent(const Event& event);
- // Record the messages in the specified 'event' as unconfirmed if it is
- // a push message event.
-
- // PRIVATE ACCESSORS
- void assertWrongCall(const Method method) const;
- // Invoke the failure callback because of a wrong call to the specified
- // 'method'.
-
- void assertWrongCall(const Method method, const Call& expectedCall) const;
- // Invoke the failure callback because of a wrong call to the specified
- // 'method', while the specified 'expectedCall' was expected instead.
-
- template<class T, class U>
- void assertWrongArg(const T& expected,
- const U& actual,
- const Method method,
- const char *arg,
- const Call& call) const;
- // Verify that the specified 'actual' value is equal to the specified
- // 'expected' value for argument 'argName' (a string) in the call to
- // 'method' (a Method enum) in 'call' (a Call). Invoke the failure
- // callback if not.
-
- public:
- // TRAITS
- BSLMF_NESTED_TRAIT_DECLARATION(MockSession, bslma::UsesBslmaAllocator)
-
- // CREATORS
- explicit
- MockSession(const bmqt::SessionOptions& options = bmqt::SessionOptions(),
- bslma::Allocator *allocator = 0);
- // Create a new 'MockSession' in *synchronous* mode using the
- // optionally specified 'options'. In such mode, events have to be
- // fetched by the application using the 'nextEvent()' method.
- // Optionally specify an 'allocator' used to supply memory. If
- // 'allocator' is 0, the currently installed default allocator is used.
-
- explicit
- MockSession(
- bslma::ManagedPtr<SessionEventHandler> eventHandler,
- const bmqt::SessionOptions& options = bmqt::SessionOptions(),
- bslma::Allocator *allocator = 0);
- // Create a 'MockSession' in *asynchronous* mode using the specified
- // 'eventHandler' as callback for event processing and the optionally
- // specified 'options'. Optionally specify an 'allocator' used to
- // supply memory. If the optionally specified 'allocator' is 0, the
- // currently installed default allocator is used.
-
- ~MockSession() BSLS_KEYWORD_OVERRIDE;
- // Stop the 'MockSession' and destroy this object.
-
- // MANIPULATORS
- // (specific to 'bmqa::MockSession')
- void enqueueEvent(const bmqa::Event& event);
- // Enqueue the specified 'event' in the queue of events to be emitted.
- // NOTE: This method is unique to 'MockSession' and is valid only in
- // unit tests.
-
- bool emitEvent(int numEvents = 1);
- // Emit the specified number of 'numEvents' from the queue of events to
- // be emitted. Return true if at least one event was emitted, and
- // false otherwise.
- // NOTE: This method is unique to 'MockSession' and is valid only in
- // unit tests.
-
- Call&
- expect_start(const bsls::TimeInterval& timeout = bsls::TimeInterval());
- Call&
- expect_startAsync(
- const bsls::TimeInterval& timeout = bsls::TimeInterval());
- Call& expect_stop();
- Call& expect_stopAsync();
- Call& expect_finalizeStop();
- Call&
- expect_openQueue(
- QueueId *queueId,
- const bmqt::Uri& uri,
- bsls::Types::Uint64 flags,
- const bmqt::QueueOptions& options = bmqt::QueueOptions(),
- const bsls::TimeInterval& timeout = bsls::TimeInterval());
- Call&
- expect_openQueueSync(
- QueueId *queueId,
- const bmqt::Uri& uri,
- bsls::Types::Uint64 flags,
- const bmqt::QueueOptions& options = bmqt::QueueOptions(),
- const bsls::TimeInterval& timeout = bsls::TimeInterval());
-
- Call&
- expect_openQueueAsync(
- QueueId *queueId,
- const bmqt::Uri& uri,
- bsls::Types::Uint64 flags,
- const bmqt::QueueOptions& options = bmqt::QueueOptions(),
- const bsls::TimeInterval& timeout = bsls::TimeInterval());
- Call&
- expect_openQueueAsync(
- QueueId *queueId,
- const bmqt::Uri& uri,
- bsls::Types::Uint64 flags,
- const OpenQueueCallback& callback,
- const bmqt::QueueOptions& options = bmqt::QueueOptions(),
- const bsls::TimeInterval& timeout = bsls::TimeInterval());
-
- Call&
- expect_closeQueue(
- QueueId *queueId,
- const bsls::TimeInterval& timeout = bsls::TimeInterval());
- Call&
- expect_closeQueueSync(
- QueueId *queueId,
- const bsls::TimeInterval& timeout = bsls::TimeInterval());
-
- Call&
- expect_closeQueueAsync(
- QueueId *queueId,
- const bsls::TimeInterval& timeout = bsls::TimeInterval());
- Call&
- expect_closeQueueAsync(
- QueueId *queueId,
- const CloseQueueCallback& callback,
- const bsls::TimeInterval& timeout = bsls::TimeInterval());
- Call&
- expect_configureQueue(
- QueueId *queueId,
- const bmqt::QueueOptions& options = bmqt::QueueOptions(),
- const bsls::TimeInterval& timeout = bsls::TimeInterval());
- Call&
- expect_configureQueueSync(
- QueueId *queueId,
- const bmqt::QueueOptions& options = bmqt::QueueOptions(),
- const bsls::TimeInterval& timeout = bsls::TimeInterval());
- Call&
- expect_configureQueueAsync(
- QueueId *queueId,
- const bmqt::QueueOptions& options = bmqt::QueueOptions(),
- const bsls::TimeInterval& timeout = bsls::TimeInterval());
-
- Call&
- expect_configureQueueAsync(
- QueueId *queueId,
- const bmqt::QueueOptions& options,
- const ConfigureQueueCallback& callback,
- const bsls::TimeInterval& timeout = bsls::TimeInterval());
-
- Call&
- expect_nextEvent(const bsls::TimeInterval& timeout = bsls::TimeInterval());
- Call& expect_post(const MessageEvent& messageEvent);
- Call& expect_confirmMessage(const Message& message);
- Call& expect_confirmMessage(const MessageConfirmationCookie& cookie);
- Call& expect_confirmMessages(ConfirmEventBuilder *builder);
- // Expect a call to the function and return a reference offering
- // modifiable access to the corresponding 'Call' object.
- //
- // NOTE: Do not use these method directly, use the macro
- // 'BMQA_EXPECT_CALL' instead.
-
- // MANIPULATORS
- // (virtual bmqa::AbstractSession)
- int start(const bsls::TimeInterval& timeout = bsls::TimeInterval())
- BSLS_KEYWORD_OVERRIDE;
- int startAsync(const bsls::TimeInterval& timeout = bsls::TimeInterval())
- BSLS_KEYWORD_OVERRIDE;
- // Start the 'MockSession' with an optionally specified 'timeout'. The
- // return values are elucidated in 'bmqt::GenericResult'. In general a
- // call to 'start' or 'startAsync' emits a 'SessionEvent' of type
- // 'e_CONNECTED' or 'e_CONNECTION_TIMEOUT'.
-
- void stop() BSLS_KEYWORD_OVERRIDE;
- void stopAsync() BSLS_KEYWORD_OVERRIDE;
- // Stop the 'MockSession'. In general a call to 'start' or
- // 'startAsync' emits a 'SessionEvent' of type 'e_DISCONNECTED' or
- // 'e_CONNECTION_TIMEOUT'.
-
- void finalizeStop() BSLS_KEYWORD_OVERRIDE;
- // This method is only to be used if the session is in synchronous mode
- // (i.e., not using the EventHandler): it must be called once all
- // threads getting events with 'nextEvent()' have been joined.
-
- void loadMessageEventBuilder(MessageEventBuilder *builder)
- BSLS_KEYWORD_OVERRIDE;
- // Load the 'MessageEventBuilder' into the specified 'builder' output
- // parameter.
-
- void loadConfirmEventBuilder(ConfirmEventBuilder *builder)
- BSLS_KEYWORD_OVERRIDE;
- // Load the 'ConfirmEventBuilder' into the specified 'builder' output
- // parameter.
-
- void loadMessageProperties(MessageProperties *buffer)
- BSLS_KEYWORD_OVERRIDE;
- // Load the 'MessageProperties' into the specified 'buffer' output
- // parameter.
-
- ///Queue management
- ///----------------
- int getQueueId(QueueId *queueId, const bmqt::Uri& uri) const
- BSLS_KEYWORD_OVERRIDE;
- // Load 'QueueId' object associated with the specified 'uri' into the
- // specified 'queueId' output parameter.
-
- int getQueueId(QueueId *queueId,
- const bmqt::CorrelationId& correlationId) const
- BSLS_KEYWORD_OVERRIDE;
- // Load 'QueueId' object associated with the specified 'correlationId'
- // into the specified 'queueId' output parameter.
-
- int
- openQueue(QueueId *queueId,
- const bmqt::Uri& uri,
- bsls::Types::Uint64 flags,
- const bmqt::QueueOptions& options = bmqt::QueueOptions(),
- const bsls::TimeInterval& timeout = bsls::TimeInterval())
- BSLS_KEYWORD_OVERRIDE;
- // DEPRECATED: Use the 'openQueueSync(QueueId *queueId...)' instead.
- // This method will be marked as
- // 'BSLS_ANNOTATION_DEPRECATED' in future release of
- // libbmq.
-
- OpenQueueStatus
- openQueueSync(QueueId *queueId,
- const bmqt::Uri& uri,
- bsls::Types::Uint64 flags,
- const bmqt::QueueOptions& options = bmqt::QueueOptions(),
- const bsls::TimeInterval& timeout = bsls::TimeInterval())
- BSLS_KEYWORD_OVERRIDE;
- // Open the queue having the specified 'uri' with the specified 'flags'
- // (a combination of the values defined in 'bmqt::QueueFlags::Enum'),
- // using the specified 'queueId' to correlate events related to that
- // queue. The object 'queueId' referring to is modified, so the
- // 'queueId' represents the actual queue uri, flags and options.
- // Return a result providing the status and context of the operation.
- // Use the optionally specified 'options' to configure some advanced
- // settings. In general, a call to 'openQueueSync' emits nothing.
-
- int
- openQueueAsync(QueueId *queueId,
- const bmqt::Uri& uri,
- bsls::Types::Uint64 flags,
- const bmqt::QueueOptions& options = bmqt::QueueOptions(),
- const bsls::TimeInterval& timeout = bsls::TimeInterval())
- BSLS_KEYWORD_OVERRIDE;
- // DEPRECATED: Use the 'openQueueAsync(...)' with callback flavor
- // instead. This method will be marked as
- // 'BSLS_ANNOTATION_DEPRECATED' in future release of
- // libbmq.
-
- void
- openQueueAsync(QueueId *queueId,
- const bmqt::Uri& uri,
- bsls::Types::Uint64 flags,
- const OpenQueueCallback& callback,
- const bmqt::QueueOptions& options = bmqt::QueueOptions(),
- const bsls::TimeInterval& timeout = bsls::TimeInterval())
- BSLS_KEYWORD_OVERRIDE;
- // Asynchronously open the queue having the specified 'uri' with the
- // specified 'flags' (a combination of the values defined in
- // 'bmqt::QueueFlags::Enum'). The object 'queueId' referring to is
- // modified, so the 'queueId' represents the actual queue uri, flags
- // and options. The result of the operation is communicated to the
- // specified 'callback' via a 'bmqa::OpenQueueStatus', providing an
- // automatically generated correlation 'queueId' and the status and
- // context of the requested operation. Use the optionally specified
- // 'options' to configure some advanced settings. In general, a call
- // to 'openQueueAsync' does not emit a 'SessionEvent', but rather
- // invokes the 'callback' (if provided) instead when the corresponding
- // 'emitEvent' is called.
- //
- // NOTE: 'openQueueAsync' updates the queue state to 'e_OPENING' which
- // is further updated upon invocation of the 'callback' (if
- // provided) with a successful 'bmqa::OpenQueueStatus'.
-
- int
- configureQueue(QueueId *queueId,
- const bmqt::QueueOptions& options = bmqt::QueueOptions(),
- const bsls::TimeInterval& timeout = bsls::TimeInterval())
- BSLS_KEYWORD_OVERRIDE;
- // DEPRECATED: Use the 'configureQueueSync(QueueId *queueId...)
- // instead. This method will be marked as
- // 'BSLS_ANNOTATION_DEPRECATED' in future release of
- // libbmq.
-
- ConfigureQueueStatus
- configureQueueSync(const QueueId *queueId,
- const bmqt::QueueOptions& options,
- const bsls::TimeInterval& timeout)
- BSLS_KEYWORD_OVERRIDE;
- // Configure the queue identified by the specified 'queueId' using the
- // specified 'options' to configure some advanced settings and return a
- // result providing the status and context of the operation. In
- // general, a call to 'configureQueueSync' emits nothing.
-
- int
- configureQueueAsync(
- QueueId *queueId,
- const bmqt::QueueOptions& options = bmqt::QueueOptions(),
- const bsls::TimeInterval& timeout = bsls::TimeInterval())
- BSLS_KEYWORD_OVERRIDE;
- // DEPRECATED: Use the 'configureQueueAsync(...)' with callback flavor
- // instead. This method will be marked as
- // 'BSLS_ANNOTATION_DEPRECATED' in future release of
- // libbmq.
-
- void
- configureQueueAsync(
- const QueueId *queueId,
- const bmqt::QueueOptions& options,
- const ConfigureQueueCallback& callback,
- const bsls::TimeInterval& timeout = bsls::TimeInterval())
- BSLS_KEYWORD_OVERRIDE;
- // Asynchronously configure the queue identified by the specified
- // 'queueId' using the specified 'options' to configure some advanced
- // settings. The result of the operation is communicated to the
- // specified 'callback' via a 'bmqa::ConfigureQueueStatus', providing
- // the status and context of the requested operation. In general, a
- // call to 'configureQueueAsync' does not emit a 'SessionEvent', but
- // rather invokes the 'callback' (if provided) instead when the
- // corresponding 'emitEvent' is called.
-
- int
- closeQueue(QueueId *queueId,
- const bsls::TimeInterval& timeout = bsls::TimeInterval())
- BSLS_KEYWORD_OVERRIDE;
- // DEPRECATED: Use the 'closeQueueSync(QueueId *queueId...)' instead.
- // This method will be marked as
- // 'BSLS_ANNOTATION_DEPRECATED' in future release of
- // libbmq.
-
- CloseQueueStatus
- closeQueueSync(const QueueId *queueId,
- const bsls::TimeInterval& timeout = bsls::TimeInterval())
- BSLS_KEYWORD_OVERRIDE;
- // Close the queue identified by the specified 'queueId' using the
- // specified 'timeout'. Populate the optionally specified 'result'
- // with the status and context of the operation and return a value
- // providing the status of the operation. In general, a call to
- // 'closeQueueSync' emits nothing.
-
- int
- closeQueueAsync(QueueId *queueId,
- const bsls::TimeInterval& timeout = bsls::TimeInterval())
- BSLS_KEYWORD_OVERRIDE;
- // DEPRECATED: Use the 'closeQueueAsync(...)' with callback flavor
- // instead. This method will be marked as
- // 'BSLS_ANNOTATION_DEPRECATED' in future release of
- // libbmq.
-
- void
- closeQueueAsync(
- const QueueId *queueId,
- const CloseQueueCallback& callback,
- const bsls::TimeInterval& timeout = bsls::TimeInterval())
- BSLS_KEYWORD_OVERRIDE;
- // Asynchronously close the queue identified by the specified 'queueId'
- // using the specified 'timeout'. The result of the operation is
- // communicated to the specified 'callback' via a
- // 'bmqa::CloseQueueStatus', providing the status and context of the
- // requested operation. In general, a call to 'closeQueueAsync' does
- // not emit a 'SessionEvent', but rather invokes the 'callback' (if
- // provided) instead when the corresponding 'emitEvent' is called.
-
- Event nextEvent(const bsls::TimeInterval& timeout = bsls::TimeInterval())
- BSLS_KEYWORD_OVERRIDE;
- // Returns the nextEvent emitted.
- //
- // NOTE: This method should only be used when the 'MockSession' has
- // been created in synchronous mode. It is invalid if used in
- // asynchronous mode and your test case is likely to be faulty
- // if used with such a set up.
-
- int post(const MessageEvent& messageEvent) BSLS_KEYWORD_OVERRIDE;
- // Post the specified 'messageEvent'. Return values are defined as per
- // 'bmqt::PostResult'. In general a call to 'post' emits a
- // 'MessageEvent' of type 'e_ACK' or no response if acks are not
- // requested.
-
- int confirmMessage(const Message& message) BSLS_KEYWORD_OVERRIDE;
- int confirmMessage(const MessageConfirmationCookie& cookie)
- BSLS_KEYWORD_OVERRIDE;
- int confirmMessages(ConfirmEventBuilder *builder) BSLS_KEYWORD_OVERRIDE;
- // Confirm messages specified by the 'message', 'cookie' or 'builder'.
- // Return values are defined as per 'bmqt::GenericResult'. No event is
- // emitted for calls to 'confirmMessage'.
-
- int configureMessageDumping(const bslstl::StringRef& command)
- BSLS_KEYWORD_OVERRIDE;
- // NOT IMPLEMENTED
-
- void setFailureCallback(const FailureCb& failureCb);
- // Set the failure callback of to be the specified 'failureCb'. This
- // callback is invoked whenever an expectation set by the test driver
- // is not met.
-
- bool popPostedEvent(bmqa::MessageEvent *event);
- // Load into the specified 'event' the next posted event on this
- // session, if any, and return true; leave 'event' unchanged and return
- // false otherwise.
-
- // ACCESSORS
- size_t unconfirmedMessages() const;
- // Get the number of unconfirmed messages. This corresponds to the
- // number of push messages enqueued to the session object but not yet
- // confirmed by the application.
-};
-
-
-// ============================================================================
-// INLINE DEFINITIONS
-// ============================================================================
-
- // -----------------
- // class MockSession
- // -----------------
-
-inline
-void
-MockSession::setFailureCallback(const FailureCb& failureCb)
-{
- d_failureCb = failureCb;
-}
-
-inline
-size_t
-MockSession::unconfirmedMessages() const
-{
- return d_unconfirmedGUIDs.size();
-}
-
-inline
-bool
-MockSession::popPostedEvent(bmqa::MessageEvent *event)
-{
- // PRECONDITIONS
- BSLS_ASSERT(event);
-
- bslmt::LockGuard<bslmt::Mutex> guard(&d_mutex); // LOCKED
-
- if (d_postedEvents.empty()) {
- return false; // RETURN
- }
-
- *event = d_postedEvents.front();
- d_postedEvents.pop_front();
-
- return true;
-}
-
-} // close package namespace
-} // close enterprise namespace
-
-#endif
-
-Generated on Thu Jun 15 2023 11:58:50 by
-
- 1.7.1
-
-
diff --git a/docs/docs/apidocs/cpp_apidocs/bmqa__openqueuestatus_8h_source.html b/docs/docs/apidocs/cpp_apidocs/bmqa__openqueuestatus_8h_source.html
deleted file mode 100644
index ac1d80495..000000000
--- a/docs/docs/apidocs/cpp_apidocs/bmqa__openqueuestatus_8h_source.html
+++ /dev/null
@@ -1,265 +0,0 @@
-
-
-Bloomberg Development Environment
-
-
-// Copyright 2019-2023 Bloomberg Finance L.P.
-// SPDX-License-Identifier: Apache-2.0
-//
-// Licensed under the Apache License, Version 2.0 (the "License");
-// you may not use this file except in compliance with the License.
-// You may obtain a copy of the License at
-//
-// http://www.apache.org/licenses/LICENSE-2.0
-//
-// Unless required by applicable law or agreed to in writing, software
-// distributed under the License is distributed on an "AS IS" BASIS,
-// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-// See the License for the specific language governing permissions and
-// limitations under the License.
-
-// bmqa_openqueuestatus.h -*-C++-*-
-#ifndef INCLUDED_BMQA_OPENQUEUESTATUS
-#define INCLUDED_BMQA_OPENQUEUESTATUS
-
-//@PURPOSE: Provide Value-Semantic Type for an open queue operation status
-//
-//@CLASSES:
-// bmqa::OpenQueueStatus: value-semantic type for an openQueue result
-//
-//@DESCRIPTION: This component provides a specific value-semantic type for the
-// result of an open queue operation with the BlazingMQ broker, providing
-// applications with the result and context of the requested operation.
-//
-// A 'bmqa::OpenQueueStatus' type is composed of 3 attributes:
-//: o !result!: indicates the status of the operation (success,
-//: failure, etc.) as specified in the corresponding
-//: result code enum, 'bmqt::OpenQueueResult::Enum'
-//: o !queueId!: queueId associated with the open queue operation
-//: o !errorDescription!: optional string with a human readable description of
-//: the error, if any
-
-
-// BMQ
-#include <bmqscm_version.h>
-#include <bmqa_queueid.h>
-#include <bmqt_resultcode.h>
-
-// BDE
-#include <bsl_iostream.h>
-#include <bsl_string.h>
-#include <bslma_allocator.h>
-#include <bslma_default.h>
-#include <bslma_usesbslmaallocator.h>
-#include <bslmf_nestedtraitdeclaration.h>
-
-
-namespace BloombergLP {
-namespace bmqa {
-
- // =====================
- // class OpenQueueStatus
- // =====================
-
-class OpenQueueStatus {
- // A value-semantic type for an open queue operation with the message queue
- // broker.
-
- private:
- // DATA
- QueueId d_queueId;
- // queueId associated with the open
- // queue operation
-
- bmqt::OpenQueueResult::Enum d_result;
- // Result code of the operation
- // (success, failure)
-
- bsl::string d_errorDescription;
- // Optional string with a human
- // readable description of the error,
- // if any
-
- public:
- // TRAITS
- BSLMF_NESTED_TRAIT_DECLARATION(OpenQueueStatus, bslma::UsesBslmaAllocator)
-
- // CREATORS
- explicit OpenQueueStatus(bslma::Allocator *allocator = 0);
- // Default constructor, use the optionally specified 'allocator'.
-
- OpenQueueStatus(const bmqa::OpenQueueStatus& other,
- bslma::Allocator *allocator = 0);
- // Create a new 'bmqa::OpenQueueStatus' using the optionally specified
- // 'allocator'.
-
- OpenQueueStatus(const QueueId& queueId,
- bmqt::OpenQueueResult::Enum result,
- const bsl::string& errorDescription,
- bslma::Allocator *allocator = 0);
- // Create a new 'bmqa::OpenQueueStatus' object having the specified
- // 'queueId', 'result', and 'errorDescription', using the
- // optionally specified 'allocator' to supply memory.
-
- // MANIPULATORS
- OpenQueueStatus& operator=(const OpenQueueStatus& rhs);
- // Assignment operator from the specified 'rhs'.
-
- // ACCESSORS
- operator bool() const;
- // Return true if this result indicates success, and false otherwise.
-
- const QueueId& queueId() const;
- // Return the queueId associated to this operation result, if any.
-
- bmqt::OpenQueueResult::Enum result() const;
- // Return the result code that indicates success or the cause of a
- // failure.
-
- const bsl::string& errorDescription() const;
- // Return a printable description of the error, if 'result' indicates
- // failure. Return an empty string otherwise.
-
- bsl::ostream& print(bsl::ostream& stream,
- int level = 0,
- int spacesPerLevel = 4) const;
- // Format this object to the specified output 'stream' at the (absolute
- // value of) the optionally specified indentation 'level' and return a
- // reference to 'stream'. If 'level' is specified, optionally specify
- // 'spacesPerLevel', the number of spaces per indentation level for
- // this and all of its nested objects. If 'level' is negative,
- // suppress indentation of the first line. If 'spacesPerLevel' is
- // negative format the entire output on one line, suppressing all but
- // the initial indentation (as governed by 'level'). If 'stream' is
- // not valid on entry, this operation has no effect.
-};
-
-// FREE OPERATORS
-bool operator==(const OpenQueueStatus& lhs, const OpenQueueStatus& rhs);
- // Return 'true' if the specified 'rhs' object contains the value of the
- // same type as contained in the specified 'lhs' object and the value
- // itself is the same in both objects, return false otherwise.
-
-bool operator!=(const OpenQueueStatus& lhs, const OpenQueueStatus& rhs);
- // Return 'false' if the specified 'rhs' object contains the value of the
- // same type as contained in the specified 'lhs' object and the value
- // itself is the same in both objects, return 'true' otherwise.
-
-bsl::ostream& operator<<(bsl::ostream& stream, const OpenQueueStatus& rhs);
- // Format the specified 'rhs' to the specified output 'stream' and return a
- // reference to the modifiable 'stream'.
-
-// ============================================================================
-// INLINE DEFINITIONS
-// ============================================================================
-
- // ---------------------
- // class OpenQueueStatus
- // ---------------------
-
-// CREATORS
-inline
-OpenQueueStatus::OpenQueueStatus(bslma::Allocator *allocator)
-: d_queueId(allocator)
-, d_result(bmqt::OpenQueueResult::e_SUCCESS)
-, d_errorDescription(allocator)
-{
- // NOTHING
-}
-
-inline
-OpenQueueStatus::OpenQueueStatus(const OpenQueueStatus& other,
- bslma::Allocator *allocator)
-: d_queueId(other.d_queueId, allocator)
-, d_result(other.d_result)
-, d_errorDescription(other.d_errorDescription, allocator)
-{
- // NOTHING
-}
-
-inline
-OpenQueueStatus::OpenQueueStatus(const QueueId& queueId,
- bmqt::OpenQueueResult::Enum result,
- const bsl::string& errorDescription,
- bslma::Allocator *allocator)
-: d_queueId(queueId, allocator)
-, d_result(result)
-, d_errorDescription(errorDescription)
-{
- // NOTHING
-}
-
-// MANIPULATORS
-inline
-OpenQueueStatus&
-OpenQueueStatus::operator=(const OpenQueueStatus& other)
-{
- d_queueId = other.queueId();
- d_result = other.result();
- d_errorDescription = other.errorDescription();
- return *this;
-}
-
-// ACCESSORS
-inline
-OpenQueueStatus::operator bool() const
-{
- return d_result == bmqt::OpenQueueResult::e_SUCCESS;
-}
-
-inline
-const QueueId&
-OpenQueueStatus::queueId() const
-{
- return d_queueId;
-}
-
-inline
-bmqt::OpenQueueResult::Enum
-OpenQueueStatus::result() const
-{
- return d_result;
-}
-
-inline
-const bsl::string&
-OpenQueueStatus::errorDescription() const
-{
- return d_errorDescription;
-}
-
-} // close package namespace
-
-// FREE OPERATORS
-inline
-bsl::ostream&
-bmqa::operator<<(bsl::ostream& stream,
- const bmqa::OpenQueueStatus& rhs)
-{
- return rhs.print(stream, 0, -1);
-}
-
-inline
-bool
-bmqa::operator==(const bmqa::OpenQueueStatus& lhs,
- const bmqa::OpenQueueStatus& rhs)
-{
- return lhs.queueId() == rhs.queueId()
- && lhs.result() == rhs.result()
- && lhs.errorDescription() == rhs.errorDescription();
-}
-
-inline
-bool
-bmqa::operator!=(const bmqa::OpenQueueStatus& lhs,
- const bmqa::OpenQueueStatus& rhs)
-{
- return !(lhs == rhs);
-}
-
-} // close enterprise namespace
-
-#endif
-
-Generated on Thu Jun 15 2023 11:58:50 by
-
- 1.7.1
-
-
diff --git a/docs/docs/apidocs/cpp_apidocs/bmqa__queueid_8h_source.html b/docs/docs/apidocs/cpp_apidocs/bmqa__queueid_8h_source.html
deleted file mode 100644
index 93b44d63e..000000000
--- a/docs/docs/apidocs/cpp_apidocs/bmqa__queueid_8h_source.html
+++ /dev/null
@@ -1,220 +0,0 @@
-
-
-Bloomberg Development Environment
-
-
-// Copyright 2014-2023 Bloomberg Finance L.P.
-// SPDX-License-Identifier: Apache-2.0
-//
-// Licensed under the Apache License, Version 2.0 (the "License");
-// you may not use this file except in compliance with the License.
-// You may obtain a copy of the License at
-//
-// http://www.apache.org/licenses/LICENSE-2.0
-//
-// Unless required by applicable law or agreed to in writing, software
-// distributed under the License is distributed on an "AS IS" BASIS,
-// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-// See the License for the specific language governing permissions and
-// limitations under the License.
-
-// bmqa_queueid.h -*-C++-*-
-#ifndef INCLUDED_BMQA_QUEUEID
-#define INCLUDED_BMQA_QUEUEID
-
-//@PURPOSE: Provide a value-semantic efficient identifier for a queue.
-//
-//@CLASSES:
-// bmqa::QueueId: Value-semantic efficient identifier for a queue.
-//
-//@DESCRIPTION: This component implements a value-semantic class,
-// 'bmqa::QueueId', which can be used to efficiently identify the queue
-// associated with a message event. A 'bmqa::QueueId' instance can be created
-// with a 64-bit integer, raw pointer, shared pointer, or
-// 'bmqt::CorrelationId'.
-
-// BMQ
-#include <bmqscm_version.h>
-#include <bmqt_correlationid.h>
-#include <bmqt_queueoptions.h>
-#include <bmqt_uri.h>
-
-// BDE
-#include <bsl_string.h>
-#include <bsl_iosfwd.h>
-#include <bsl_memory.h>
-#include <bsls_types.h>
-#include <bslma_allocator.h>
-#include <bslma_usesbslmaallocator.h>
-#include <bslmf_nestedtraitdeclaration.h>
-
-namespace BloombergLP {
-
-// FORWARD DECLARATION
-namespace bmqimp { class Queue; }
-
-namespace bmqa {
-
-
- // =============
- // class QueueId
- // =============
-
-class QueueId {
- // Value-semantic efficient identifier for a queue
-
- // FRIENDS
- friend bool operator==(const QueueId& lhs, const QueueId& rhs);
- friend bool operator!=(const QueueId& lhs, const QueueId& rhs);
- friend bool operator<(const QueueId& lhs, const QueueId& rhs);
-
- private:
- // DATA
- bsl::shared_ptr<bmqimp::Queue> d_impl_sp; // pimpl
-
- public:
- // TRAITS
- BSLMF_NESTED_TRAIT_DECLARATION(QueueId, bslma::UsesBslmaAllocator)
-
- // CREATORS
- explicit QueueId(bslma::Allocator *allocator = 0);
- // Default constructor. Create a new QueueId associated with an
- // automatically generated correlation Id, using the optionally
- // specified 'allocator'.
-
- QueueId(const QueueId& other,
- bslma::Allocator *allocator = 0);
- // Copy constructor, create a new queueId having the same values as the
- // specified 'other', and using the optionally specified 'allocator'.
-
- explicit QueueId(const bmqt::CorrelationId& correlationId,
- bslma::Allocator *allocator = 0);
- // Create a new QueueId associated to the correlation Id having the
- // specified 'correlationId' value, using the optionally specified
- // 'allocator'.
-
- explicit QueueId(bsls::Types::Int64 numeric,
- bslma::Allocator *allocator = 0);
- // Create a new QueueId associated to the correlation Id having the
- // specified 'numeric' correlationId value, using the optionally
- // specified 'allocator'.
-
- explicit QueueId(void *pointer,
- bslma::Allocator *allocator = 0);
- // Create a new QueueId associated to the correlation Id having the
- // specified 'pointer' correlationId value, using the optionally
- // specified 'allocator'.
-
- explicit QueueId(const bsl::shared_ptr<void>& sharedPtr,
- bslma::Allocator *allocator = 0);
- // Create a new QueueId associated to the correlation Id having the
- // specified 'sharedPtr' correlationId value, using the optionally
- // specified 'allocator'. The lifetime of 'sharedPtr' is tied to this
- // object, and it is the responsibility of the user to manage it
- // accordingly.
-
- // MANIPULATORS
- QueueId& operator=(const QueueId& rhs);
- // Assignment operator, from the specified 'rhs' using the specified
- // 'allocator'.
-
- // ACCESSORS
- const bmqt::CorrelationId& correlationId() const;
- // Return the correlationId associated to this QueueId. The behavior is
- // undefined unless this QueueId is valid.
-
- bsls::Types::Uint64 flags() const;
- // Return the flags used when opening this queue.
-
- const bmqt::Uri& uri() const;
- // Return the URI associated to this QueueId. The behavior is
- // undefined unless this QueueId is valid.
-
- const bmqt::QueueOptions& options() const;
- // Return the options used when opening this queue.
-
- bool isValid() const;
- // Return whether this QueueId is valid, i.e., is associated to an
- // opened queue.
-
- bsl::ostream& print(bsl::ostream& stream,
- int level = 0,
- int spacesPerLevel = 4) const;
- // Format this object to the specified output 'stream' at the (absolute
- // value of) the optionally specified indentation 'level' and return a
- // reference to 'stream'. If 'level' is specified, optionally specify
- // 'spacesPerLevel', the number of spaces per indentation level for
- // this and all of its nested objects. If 'level' is negative,
- // suppress indentation of the first line. If 'spacesPerLevel' is
- // negative format the entire output on one line, suppressing all but
- // the initial indentation (as governed by 'level'). If 'stream' is
- // not valid on entry, this operation has no effect.
-};
-
-// FREE OPERATORS
-bsl::ostream& operator<<(bsl::ostream& stream, const QueueId& rhs);
- // Format the specified 'rhs' to the specified output 'stream' and return a
- // reference to the modifiable 'stream'.
-
-bool operator==(const QueueId& lhs, const QueueId& rhs);
- // Return 'true' if 'rhs' object contains the value of the same type as
- // contained in 'lhs' object and the value itself is the same in both
- // objects, return false otherwise.
-
-bool operator!=(const QueueId& lhs, const QueueId& rhs);
- // Return 'false' if 'rhs' object contains the value of the same type as
- // contained in 'lhs' object and the value itself is the same in both
- // objects, return 'true' otherwise.
-
-bool operator<(const QueueId& lhs, const QueueId& rhs);
- // Operator used to allow comparison between the specified 'lhs' and 'rhs'
- // CorrelationId objects so that CorrelationId can be used as key in a map.
-
-} // close package namespace
-
-// ============================================================================
-// INLINE DEFINITIONS
-// ============================================================================
-
- // -------------
- // class QueueId
- // -------------
-
-inline
-bsl::ostream&
-bmqa::operator<<(bsl::ostream& stream,
- const bmqa::QueueId& rhs)
-{
- return rhs.print(stream, 0, -1);
-}
-
-inline
-bool
-bmqa::operator==(const bmqa::QueueId& lhs,
- const bmqa::QueueId& rhs)
-{
- return rhs.d_impl_sp.get() == lhs.d_impl_sp.get();
-}
-
-inline
-bool
-bmqa::operator!=(const bmqa::QueueId& lhs,
- const bmqa::QueueId& rhs)
-{
- return rhs.d_impl_sp.get() != lhs.d_impl_sp.get();
-}
-
-inline
-bool
-bmqa::operator<(const bmqa::QueueId& lhs,
- const bmqa::QueueId& rhs)
-{
- return rhs.d_impl_sp.get() < lhs.d_impl_sp.get();
-}
-
-} // close enterprise namespace
-
-#endif
-
-Generated on Thu Jun 15 2023 11:58:50 by
-
- 1.7.1
-
-
diff --git a/docs/docs/apidocs/cpp_apidocs/bmqa__session_8h_source.html b/docs/docs/apidocs/cpp_apidocs/bmqa__session_8h_source.html
deleted file mode 100644
index abef723c3..000000000
--- a/docs/docs/apidocs/cpp_apidocs/bmqa__session_8h_source.html
+++ /dev/null
@@ -1,1159 +0,0 @@
-
-
-Bloomberg Development Environment
-
-
-// Copyright 2014-2023 Bloomberg Finance L.P.
-// SPDX-License-Identifier: Apache-2.0
-//
-// Licensed under the Apache License, Version 2.0 (the "License");
-// you may not use this file except in compliance with the License.
-// You may obtain a copy of the License at
-//
-// http://www.apache.org/licenses/LICENSE-2.0
-//
-// Unless required by applicable law or agreed to in writing, software
-// distributed under the License is distributed on an "AS IS" BASIS,
-// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-// See the License for the specific language governing permissions and
-// limitations under the License.
-
-// bmqa_session.h -*-C++-*-
-#ifndef INCLUDED_BMQA_SESSION
-#define INCLUDED_BMQA_SESSION
-
-//@PURPOSE: Provide access to the BlazingMQ broker.
-//
-//@CLASSES:
-// bmqa::SessionEventHandler: interface for receiving events asynchronously.
-// bmqa::Session : mechanism for access to the BlazingMQ broker.
-//
-//@DESCRIPTION: This component provides a mechanism, 'bmqa::Session', that
-// provides access to a message queue broker and an interface,
-// 'bmqa::SessionEventHandler' for asynchronous notification of events. The
-// broker manages named, persistent queues of messages. This broker allows a
-// client to open queues, post messages to them, or retrieve messages from
-// them. All of these operations take place within the context of the session
-// opened by the client application.
-//
-// Messages received from a broker are communicated to the application by the
-// session associated with that broker in the form of events (see
-// 'bmqa_event'). Events can be of two different types: (1) Messages and
-// message status events ('bmqa::MessageEvent'), or (2) Session or queue
-// status events ('bmqa::SessionEvent').
-//
-// A 'Session' can dispatch events to the application in either a synchronous
-// or asynchronous mode. In synchronous mode, the application must call the
-// 'nextEvent' method in order to obtain events from the 'Session'. In
-// asynchronous mode, the application must supply a concrete
-// 'SessionEventHandler' object at construction time. The concrete
-// 'SessionEventHandler' provided by the application must implement the
-// 'onSessionEvent' and 'onMessageEvent' methods, which will be called by the
-// 'Session' every time a session event or a message event is received. Note
-// that by default, a session created in asynchronous mode creates only one
-// internal thread to dispatch events, but a different value for number of
-// threads can be specified in 'bmqt::SessionOptions'.
-//
-// A 'Session' is created either in synchronous or in asynchronous mode, and it
-// will remain in that mode until destruction. Allowing a mix between
-// synchronous or asynchronous would make the SDK complicated. The only
-// exceptions are the "start" and "open" operations that must be available in
-// synchronous or asynchronous version for the convenience of the programmer.
-//
-// By default a 'Session' connects to the local broker, which in turn may
-// connect to a remote cluster based on configuration.
-//
-// After a 'bmqa::Session' is started, the application has to open one or
-// several queues in read and/or write mode.
-//
-///Disclaimer
-///----------
-// A 'Session' object is a heavy object representing the negotiated TCP session
-// with the broker, and the entire associated state (opened queues, statistics,
-// ...). Therefore, sessions should be always reused if possible, preferably
-// with only *one* session per lifetime of a component/library/task.
-// Note that at the time of this writing multiplexing of different logical
-// sessions over the same physical connection is not supported, so in certain
-// circumstances reuse of the same session across the whole of a single
-// application will not be possible. For example, if an application uses two
-// unrelated libraries both of which use BlazingMQ under the hood, they won't
-// be able to share a session as it stands.
-// An example of an extreme inefficiency and an abuse of resources is to
-// create a session ad-hoc every time a message needs to be posted by the same
-// component.
-//
-///Thread-safety
-///-------------
-// This session object is *thread* *enabled*, meaning that two threads can
-// safely call any methods on the *same* *instance* without external
-// synchronization.
-//
-///Connecting to the Broker
-///------------------------
-// A 'Session' establishes a communication with a broker service using TCP/IP.
-// Each 'Session' object must be constructed with a 'bmqa::SessionOptions'
-// object, which provides the necessary information to connect to the broker.
-// In particular, the 'SessionOptions' object must specify the IP address and
-// port needed to connect to the broker. The 'SessionOptions' object may also
-// provide extra parameters for tuning the TCP connection behavior (see
-// 'bmqa_sessionoptions' for details).
-//
-// Note that in most cases the user does not need to explicitly construct a
-// 'SessionOptions' object: the default constructor for 'SessionOptions'
-// creates an instance that will connect to the broker service on the local
-// machine using the standard port.
-//
-// Some options can also be provided using environment variables.
-//: o !BMQ_BROKER_URI!: Corresponds to 'SessionOptions::brokerUri'.
-//: If this environment variable is set, its value will override the one
-//: specified in the 'SessionOptions'.
-//
-// A 'Session' object is created in an unconnected state. The 'start' or
-// 'startAsync' method must be called to connect to the broker. Note that
-// 'start' method is blocking, and returns either after connection to broker
-// has been established (success), or after specified timeout (failure).
-// 'startAsync' method, as the name suggests, connects to the broker
-// asynchronously (i.e., it returns immediately), and the result of the
-// operation is notified via 'bmqt::SessionEventType::CONNECTED' session event.
-//
-// When the 'Session' is no longer needed, the application should call the
-// 'stop' (blocking) or 'stopAsync' (non-blocking) method to shut down the
-// 'Session' and disconnect from the broker. Note that destroying a Session
-// automatically stops it. The session can be restarted with a call to 'start'
-// or 'startAsync' once it has been fully stopped.
-//
-///Connection loss and reconnection
-///--------------------------------
-// If the connection between the application and the broker is lost, the
-// 'Session' will automatically try to reconnect periodically. The 'Session'
-// will also notify the application of the event of losing the connection via
-// 'bmqt::SessionEventType::CONNECTION_LOST' session event.
-//
-// Once the connection has been re-established with the broker (as a result of
-// one of the periodic reconnection attempts), the 'Session' will notify the
-// application via 'bmqt::SessionEventType::RECONNECTED' session event. After
-// the connection re-establishment, the 'Session' will attempt to reopen the
-// queues that were in 'OPEN' state prior to connection loss. The 'Session'
-// will notify the application of the result of reopen operation via
-// 'bmqt::SessionEventType::QUEUE_REOPEN_RESULT' for each queue. Note that a
-// reopen operation on a queue may fail (due to broker issue, machine issue,
-// etc), so the application must keep track on these session events, and stop
-// posting on a queue that failed to reopen.
-//
-// After all reopen operations are complete and application has been notified
-// with all 'bmqt::SessionEventType::QUEUE_REOPEN_RESULT' events, the 'Session'
-// delivers a 'bmqt::SessionEventType::STATE_RESTORED' session event to the
-// application.
-//
-///Example 1
-///- - - - -
-// The following example illustrates how to create a 'Session' in synchronous
-// mode, start it, and stop it.
-//..
-// void runSession()
-// {
-// bmqt::SessionOptions options;
-// options.setBrokerUri("tcp://localhost:30114");
-//
-// bmqa::Session session(options);
-// int res = session.start();
-// if (0 != res) {
-// bsl::cout << "Failed to start session (" << res << ")"
-// << bsl::endl;
-// return;
-// }
-// bsl::cout << "Session started." << bsl::endl;
-//
-// // Open queue in READ or WRITE or READ/WRITE mode, and receive or
-// // post messages, etc.
-// // ...
-//
-// session.stop();
-// }
-//..
-// This example can be simplified because the constructor for 'Session' uses a
-// default 'SessionOptions' object that will connect to the local broker
-// service. The example may be rewritten as follow:
-//..
-// void runSession()
-// {
-// bmqa::Session session; // using default 'SessionOptions'
-// int res = session.start();
-// if (0 != res) {
-// bsl::cout << "Failed to start session (" << res << ")"
-// << bsl::endl;
-// return;
-// }
-// bsl::cout << "Session started." << bsl::endl;
-//
-// // Open queue in READ or WRITE or READ/WRITE mode, and receive or
-// // post messages, etc.
-// // ...
-//
-// session.stop();
-// }
-//..
-//
-///Processing session events - synchronous mode
-///--------------------------------------------
-// If the 'Session' is created in synchronous mode, the application needs to
-// call the 'nextEvent' method on a regular basis in order to receive events.
-// This method takes an optional wait timeout as a parameter, and it will
-// return the next available 'Event' from the session's internal event queue or
-// it will block the calling thread execution until new 'Event' arrives or
-// until the specified timeout expires. It is safe to call the 'nextEvent'
-// method from different threads simultaneously: the 'Session' class provides
-// proper synchronization logic to protect the internal event queue from
-// corruption in this scenario.
-//
-///Example 2
-///- - - - -
-// The following example demonstrates how to write a function that queries and
-// processes events synchronously. In this example the switch form checks the
-// type of the 'Event' and performs the necessary actions.
-//
-// We first define two functions to process 'SessionEvent' and 'MessageEvent'.
-// These functions return 'true' if we should keep processing events and
-// 'false' otherwise (i.e., no more events are expected from the 'Session').
-//..
-// bool processSessionEvent(const bmqa::SessionEvent& event)
-// {
-// bool result = true;
-// switch (event.type()) {
-//
-// case bmqt::SessionEventType::e_CONNECTED:
-// // The connection to the broker is established (as a result
-// // of a call to the 'start' method).
-// openQueues();
-// startPostingToQueues();
-// break;
-//
-// case bmqt::SessionEventType::e_DISCONNECTED:
-// // The connection to the broker is terminated (as a result
-// // of a call to the 'stop' method).
-// result = false;
-// break;
-//
-// case bmqt::SessionEventType::e_CONNECTION_LOST:
-// // The connection to the broker dropped. Stop posting to the queue.
-// stopPostingToQueues();
-// break;
-//
-// case bmqt::SessionEventType::e_STATE_RESTORED:
-// // The connection to the broker has been restored (i.e., all queues
-// // have been re-opened. Resume posting to the queue.
-// resumePostingToQueues();
-// break;
-//
-// case bmqt::SessionEventType::e_CONNECTION_TIMEOUT:
-// // The connection to the broker has timed out.
-// result = false;
-// break;
-//
-// case bmqt::SessionEventType::e_ERROR:
-// // Internal error
-// bsl::cout << "Unexpected session error: "
-// << event.errorDescription() << bsl::endl;
-// break;
-//
-// } // end switch
-//
-// return result;
-// }
-//
-// bool processMessageEvent(const bmqa::MessageEvent& event)
-// {
-// bool result = true;
-// switch (event.type()) {
-//
-// case bmqt::MessageEventType::e_PUSH: {
-// // Received a 'PUSH' event from the broker.
-// bmqa::MessageIterator msgIter = event.messageIterator();
-// while (msgIter.nextMessage()) {
-// const bmqa::Message& msg = msgIter.message();
-// // Process 'PUSH' msg here (omitted for brevity)
-// // ...
-// }
-// } break;
-//
-// case bmqt::MessageEventType::e_ACK: {
-// // Received an 'ACK' event from the broker.
-// bmqa::MessageIterator msgIter = event.messageIterator();
-// while (msgIter.nextMessage()) {
-// const bmqa::Message& msg = msgIter.message();
-// // Process 'ACK' msg here (omitted for brevity)
-// // ...
-// }
-// } break;
-//
-// } // end switch
-//
-// return result;
-// }
-//..
-//
-// Next, we define a function that handles events synchronously using the
-// 'processSessionEvent' and 'processMessageEvent' functions.
-//..
-// void handleEventsSynchronously(bmqa::Session *startedSession)
-// {
-// bool more = true;
-// while (more) {
-// bmqa::Event event =
-// startedSession->nextEvent(bsls::TimeInterval(2.0));
-// if (event.isSessionEvent()) {
-// more = processSessionEvent(event.sessionEvent());
-// }
-// else {
-// more = processMessageEvent(event.messageEvent());
-// }
-// }
-// }
-//..
-//
-///Processing session events - asynchronous mode
-///---------------------------------------------
-// If application wishes to use 'Session' in asynchronous mode, it must pass a
-// managed pointer to an event handler implementing the 'SessionEventHandler'.
-// In this case, when 'Session' is started, a thread pool owned by the
-// 'Session' is also started for processing events asynchronously. The
-// 'Session' will call event handler's 'onSessionEvent' or 'onMessageEvent'
-// method every time a session event or a message event is available.
-//
-// Note that after the 'Session' is associated with some event handler, this
-// association cannot be changed or canceled. The event handler will be used
-// for processing events until the 'Session' object is destroyed.
-//
-///Example 3
-///- - - - -
-// The following example demonstrates how to implement an event handler and how
-// to make the 'Session' use an instance of this event handler for processing
-// events.
-//
-// First, we define a concrete implementation of 'SessionEventHandler'.
-//
-//..
-// class MyHandler: public bmqa::SessionEventHandler {
-// public:
-// MyHandler() { }
-// virtual ~MyHandler() { }
-// virtual void onSessionEvent(const bmqa::SessionEvent& event);
-// virtual void onMessageEvent(const bmqa::MessageEvent& event);
-// };
-//
-// void MyHandler::onSessionEvent(const bmqa::SessionEvent& event)
-// {
-// // The implementation is similar to our 'processSessionEvent' function
-// // defined in the previous example.
-// processSessionEvent(event);
-// }
-//
-// void MyHandler::onMessageEvent(const bmqa::MessageEvent& event)
-// {
-// // The implementation is similar to our 'processMessageEvent' function
-// // defined in the previous example.
-// processMessageEvent(event);
-// }
-//..
-// Next, we define a function that creates a 'Session' using our implementation
-// of 'SessionEventHandler'.
-//..
-// void runAsyncSession()
-// {
-// bslma::ManagedPtr<SessionEventHandler> handlerMp(new MyHandler());
-//
-// bmqa::Session session(handlerMp); // using default 'SessionOptions'
-// int res = session.start();
-// if (0 != res) {
-// bsl::cout << "Failed to start session (" << res << ")"
-// << bsl::endl;
-// return;
-// }
-//
-// // ...
-//
-// session.stop();
-// }
-//..
-//
-///Opening queues
-///--------------
-// Once the 'Session' has been created and started, the application can use it
-// to open queues for producing and/or consuming messages. A queue is
-// associated with a domain. Domain metadata must be deployed in the BlazingMQ
-// infrastructure prior to opening queues under that domain, because opening a
-// queue actually loads the metadata deployed for the associated domain.
-//
-// The metadata associated with a domain defines various parameters like
-// maximum queue size and capacity, persistent policy, routing policy, etc.
-//
-// Queue are identified by URIs (Unified Resource Identifiers) that must
-// follow the BlazingMQsyntax, manipulated as 'bmqt::Uri' objects. A queue URI
-// is typically formatted as follows:
-//..
-// bmq://my.domain/my.queue
-//..
-// Note that domain names are unique in BlazingMQ infrastructure, which makes a
-// fully qualified queue URI unique too.
-//
-// Queues in BlazingMQ infrastructure are created by applications on demand.
-// Broke creates a queue when it receives an open-queue request from an
-// application for a queue that does not exist currently.
-//
-// Application can open a queue by calling 'openQueue' or 'openQueueAsync'
-// method on a started session. Application must pass appropriate flags to
-// indicate if it wants to post messages to queue, consume messages from the
-// queue, or both.
-//
-// Note that 'openQueue' is a blocking method, and returns after specified
-// queue has been successfully opened (success) or after specified timeout has
-// expired (failure). 'openQueueAsync' method, as the name suggests, is non
-// blocking, and the result of the operation is notified via
-// 'bmqt::SessionEventType::QUEUE_OPEN_RESULT' session event.
-//
-///Example 4
-///- - - - -
-// The following example demonstrates how to open a queue for posting messages.
-// The code first opens the queue with appropriate flags, and then uses
-// 'bmqa::MessageEventBuilder' to build a message event and post to the queue.
-//..
-// // Session creation and startup logic elided for brevity
-// const char *queueUri = "bmq://my.domain/my.queue";
-// bmqa::QueueId myQueueId(1); // ID for the queue
-// int rc = session.openQueue(
-// &myQueueId,
-// queueUri,
-// bmqt::QueueFlags::e_WRITE | bmqt::QueueFlags::e_ACK,
-// bsls::TimeInterval(30, 0));
-//
-// if (rc != 0) {
-// bsl::cerr << "Failed to open queue, rc: "
-// << bmqt::OpenQueueResult::Enum(rc)
-// << bsl::endl;
-// return;
-// }
-//..
-// Note that apart from 'WRITE' flag, 'ACK' flag has been passed to
-// 'openQueue' method above. This indicates that application is interested in
-// receiving 'ACK' notification for each message it posts to the queue,
-// irrespective of whether or not the message was successfully received by the
-// broker and posted to the queue.
-//
-// Once the queue has been successfully opened for writing, messages can be
-// posted to the queue for consumption by interested applications. We will use
-// 'bmqa::MessageEventBuilder' to build a message event.
-//..
-// // Create a message event builder
-// bmqa::MessageEventBuilder builder;
-// session.loadMessageEventBuilder(&builder);
-//
-// // Create and post a message event containing 1 message
-// bmqa::Message& msg = builder.startMessage();
-//
-// msg.setCorrelationId(myCorrelationId);
-// msg.setDataRef(&myPayload); // where 'myPayload' is of type 'bdlbb::Blob'
-// rc = builder.packMessage(myQueueId);
-// if (rc != 0) {
-// bsl::cerr << "Failed to pack message, rc: "
-// << bmqt::EventBuilderResult::Enum(rc)
-// << bsl::endl;
-// return;
-// }
-//
-// // Post message event
-// rc = session.post(builder.messageEvent());
-// if (rc != 0) {
-// bsl::cerr << "Failed to post message event to the queue, rc: "
-// << bmqt::PostResult::Enum(rc)
-// << bsl::endl;
-// return;
-// }
-//
-// // ... post more messages
-//..
-//
-///Closing queues
-///--------------
-// After an application no longer needs to produce or consume messages from a
-// queue, it can be closed by 'closeQueue' or 'closeQueueAsync' method. Note
-// that closing a queue closes an application's "view" on the queue, and may
-// not lead to queue deletion in the broker. A 'Session' does not expose any
-// method to explicitly delete a queue.
-//
-// Note that 'closeQueue' is a blocking method and returns after the specified
-// queue has been successfully closed (success) or after specified timeout has
-// expired (failure). 'closeQueueAsync', as the name suggests, is a
-// non-blocking method, and result of the operation is notified via
-// 'bmqt::SessionEventType::e_QUEUE_CLOSE_RESULT' session event.
-//
-// There are 3 flavors which behave differently with regard to thread blocking
-// and callback execution:
-///----------------------------------------------------------------------------
-// | openQueue | openQueueSync | openQueueAsync
-// | configureQueue | configureQueueSync | configureQueueAsync
-// | closeQueue | closeQueueSync | closeQueueAsync
-// | (deprecated Sync) | (Synchronous) | (Asynchronous)
-//-----------|-------------------|----------------------|----------------------
-// event | unblocks in | unblocks in event | executes callback in
-// handler | internal thread | handler thread (*) | event handler thread
-// | | |
-// nextEvent | unblocks in | unblocks in | executes callback
-// | internal thread | internal thread | in nextEvent thread
-//-----------------------------------------------------------------------------
-//
-// (*) - guarantees unblocking after all previously enqueued events have been
-// emitted to the eventHandler, allowing the user to have proper serialization
-// of events for the given queue (for example no more PUSH messages will be
-// delivered through the eventHandler for the queue after
-// configureQueueSync(maxUnconfirmed = 0) returns).
-
-// BMQ
-#include <bmqscm_version.h>
-#include <bmqa_abstractsession.h>
-#include <bmqa_closequeuestatus.h>
-#include <bmqa_configurequeuestatus.h>
-#include <bmqa_confirmeventbuilder.h>
-#include <bmqa_messageeventbuilder.h>
-#include <bmqa_openqueuestatus.h>
-#include <bmqt_queueoptions.h>
-#include <bmqt_sessionoptions.h>
-#include <bmqt_uri.h>
-
-// BDE
-#include <ball_log.h>
-#include <bsl_memory.h>
-#include <bsl_string.h>
-#include <bslma_allocator.h>
-#include <bslma_managedptr.h>
-#include <bslma_usesbslmaallocator.h>
-#include <bslmf_nestedtraitdeclaration.h>
-#include <bsls_keyword.h>
-#include <bsls_timeinterval.h>
-#include <bsls_types.h>
-
-
-namespace BloombergLP {
-
-// FORWARD DECLARATION
-namespace bmqimp { class Application; }
-namespace bmqimp { class Event; }
-namespace bmqp { class MessageGUIDGenerator; }
-namespace bslmt { class Semaphore; }
-
-namespace bmqa {
-
-// FORWARD DECLARATION
-class Event;
-class Message;
-class MessageEvent;
-class MessageProperties;
-class QueueId;
-class SessionEvent;
-
-
- // =========================
- // class SessionEventHandler
- // =========================
-
-class SessionEventHandler {
- // Pure protocol for an asynchronous event handler. The implementation
- // must be thread safe if the 'Session' is configured to use multiple
- // threads.
-
- public:
- // CREATORS
- virtual
- ~SessionEventHandler();
- // Destroy this object.
-
- // MANIPULATORS
- virtual
- void onSessionEvent(const SessionEvent& event) = 0;
- // Process the specified session 'event' (connected, disconnected,
- // queue opened, queue closed, etc.).
-
- virtual
- void onMessageEvent(const MessageEvent& event) = 0;
- // Process the specified message 'event' containing one or more
- // messages.
-};
-
-
- // ==================
- // struct SessionImpl
- // ==================
-
-struct SessionImpl {
- // Impl structure for the session data members, so that special task such
- // as 'bmqadm' can access them by reinterpret casting a 'Session' object.
- // Care should be taken though since 'Session' is a polymorphic class.
-
- // PUBLIC DATA
- bslma::Allocator *d_allocator_p;
- // The allocator to use
-
- bmqt::SessionOptions d_sessionOptions;
- // Session options as provided by
- // the application.
-
- bslma::ManagedPtr<SessionEventHandler> d_eventHandler_mp;
- // Event handler, if any, to use
- // for notifying application of
- // events.
-
- bsl::shared_ptr<bmqp::MessageGUIDGenerator>
- d_guidGenerator_sp;
- // GUID generator object.
-
- bslma::ManagedPtr<bmqimp::Application> d_application_mp;
- // The application object.
-
- private:
- // NOT IMPLEMENTED
- SessionImpl(const SessionImpl&) BSLS_KEYWORD_DELETED;
- SessionImpl& operator=(const SessionImpl&) BSLS_KEYWORD_DELETED;
-
- public:
- // TRAITS
- BSLMF_NESTED_TRAIT_DECLARATION(SessionImpl, bslma::UsesBslmaAllocator)
-
- // CREATORS
- SessionImpl(const bmqt::SessionOptions& options,
- bslma::ManagedPtr<SessionEventHandler> eventHandler,
- bslma::Allocator *allocator = 0);
- // Create a new object having the specified 'options' and
- // 'eventHandler' and using the optionally specified 'allocator'.
-};
-
-
- // =============
- // class Session
- // =============
-
-class Session: public AbstractSession {
- // A session with a BlazingMQ broker.
-
- public:
- // TYPES
- typedef AbstractSession::OpenQueueCallback OpenQueueCallback;
- // Invoked as a response to an asynchronous open queue operation,
- // 'OpenQueueCallback' is an alias for a callback function object
- // (functor) that takes as an argument the specified 'result',
- // providing the result and context of the requested operation.
-
- typedef AbstractSession::ConfigureQueueCallback ConfigureQueueCallback;
- // Invoked as a response to an asynchronous configure queue operation,
- // 'ConfigureQueueCallback' is an alias for a callback function object
- // (functor) that takes as an argument the specified 'result',
- // providing the result and context of the requested operation.
-
- typedef AbstractSession::CloseQueueCallback CloseQueueCallback;
- // Invoked as a response to an asynchronous close queue operation,
- // 'CloseQueueCallback' is an alias for a callback function object
- // (functor) that takes as an argument the specified 'result',
- // providing the result and context of the requested operation.
-
- private:
- // CLASS-SCOPE CATEGORY
- BALL_LOG_SET_CLASS_CATEGORY("BMQA.SESSION");
-
- private:
- // DATA
- SessionImpl d_impl; // Sole data member of this object.
-
- private:
- // NOT IMPLEMENTED
- Session(const Session&) BSLS_KEYWORD_DELETED;
- Session& operator=(const Session&) BSLS_KEYWORD_DELETED;
- // Copy constructor and assignment operator are not implemented
-
- public:
- // TRAITS
- BSLMF_NESTED_TRAIT_DECLARATION(Session, bslma::UsesBslmaAllocator)
-
- // CREATORS
- explicit
- Session(const bmqt::SessionOptions& options = bmqt::SessionOptions(),
- bslma::Allocator *allocator = 0);
- // Create a new 'Session' in *synchronous* mode using the optionally
- // specified 'options'. In such mode, events have to be fetched by the
- // application using the 'nextEvent()' method. Optionally specify an
- // 'allocator' used to supply memory. If 'allocator' is 0, the
- // currently installed default allocator is used.
-
- explicit
- Session(bslma::ManagedPtr<SessionEventHandler> eventHandler,
- const bmqt::SessionOptions& options =
- bmqt::SessionOptions(),
- bslma::Allocator *allocator = 0);
- // Create a 'Session' in *asynchronous* mode using the specified
- // 'eventHandler' as callback for event processing and the optionally
- // specified 'options'. Optionally specify an 'allocator' used to
- // supply memory. If the optionally specified 'allocator' is 0, the
- // currently installed default allocator is used.
-
- ~Session() BSLS_KEYWORD_OVERRIDE;
- // Stop the 'Session' and destroy this object.
-
- // MANIPULATORS
- // (virtual bmqa::AbstractSession)
-
- ///Session management
- ///------------------
- int start(const bsls::TimeInterval& timeout = bsls::TimeInterval())
- BSLS_KEYWORD_OVERRIDE;
- // Connect to the BlazingMQ broker and start the message processing for
- // this 'Session'. This method blocks until either the 'Session' is
- // connected to the broker, fails to connect, or the operation times
- // out. If the optionally specified 'timeout' is not populated, use
- // the one defined in the session options. Return 0 on success, or a
- // non-zero value corresponding to the 'bmqt::GenericResult::Enum' enum
- // values otherwise. The behavior is undefined if this method is
- // called on an already started 'Session'.
-
- int startAsync(const bsls::TimeInterval& timeout = bsls::TimeInterval())
- BSLS_KEYWORD_OVERRIDE;
- // Connect to the BlazingMQ broker and start the message processing for
- // this 'Session'. This method returns without blocking. The result
- // of the operation is communicated with a session event. If the
- // optionally specified 'timeout' is not populated, use the one defined
- // in the session options. Return 0 on success (this doesn't imply the
- // session is connected !), or a non-zero value corresponding to the
- // 'bmqt::GenericResult::Enum' enum values otherwise. The behavior is
- // undefined if this method is called on an already started 'Session'.
-
- void stop() BSLS_KEYWORD_OVERRIDE;
- // Gracefully disconnect from the BlazingMQ broker and stop the
- // operation of this 'Session'. This method blocks waiting for all
- // already invoked event handlers to exit and all session-related
- // operations to be finished. No other method but 'start()' may be
- // used after this method returns. This method must *NOT* be called if
- // the session is in synchronous mode (i.e., not using the
- // EventHandler), 'stopAsync()' should be called in this case.
-
- void stopAsync() BSLS_KEYWORD_OVERRIDE;
- // Disconnect from the BlazingMQ broker and stop the operation of this
- // 'Session'. This method returns without blocking and neither enforce
- // nor waits for any already started session-related operation to be
- // finished. No method may be used after this method returns.
-
- void finalizeStop() BSLS_KEYWORD_OVERRIDE;
- // **DEPRECATED**
- //
- // This method is only to be used if the session is in synchronous mode
- // (i.e., not using the EventHandler): it must be called once all
- // threads getting events with 'nextEvent()' have been joined.
-
- virtual
- MessageEventBuilder createMessageEventBuilder();
- // Return a MessageEventBuilder that can be used to build message event
- // for posting on this session. The behavior is undefined unless the
- // session has been successfully started. Note that lifetime of the
- // returned object is bound by the lifetime of this session instance
- // (i.e., returned instance cannot outlive this session instance).
- // Also note that the 'MessageEventBuilder' objects are pooled, so this
- // operation is cheap, and 'MessageEventBuilder' can be obtained on
- // demand and kept on the stack.
- //
- // DEPRECATED: Use the 'loadMessageEventBuilder instead. This
- // method will be marked as 'BSLS_ANNOTATION_DEPRECATED' in
- // future release of libbmq.
-
- void loadMessageEventBuilder(MessageEventBuilder *builder)
- BSLS_KEYWORD_OVERRIDE;
- // Load into the specified 'builder' an instance of
- // 'bmqa::MessageEventBuilder' that can be used to build message event
- // for posting on this session. The behavior is undefined unless the
- // session has been successfully started and 'builder' is non-null.
- // Note that lifetime of the loaded object is bound by the lifetime of
- // this session instance (i.e., loaded instance cannot outlive this
- // session instance). Also note that the 'MessageEventBuilder' objects
- // are pooled, so this operation is cheap, and 'MessageEventBuilder'
- // can be obtained on demand and kept on the stack.
-
- void loadConfirmEventBuilder(ConfirmEventBuilder *builder)
- BSLS_KEYWORD_OVERRIDE;
- // Load into the specified 'builder' an instance of
- // 'bmqa::ConfirmEventBuilder' that can be used to build a batch of
- // CONFIRM messages for sending to the broker. The behavior is
- // undefined unless the session has been successfully started and
- // 'builder' is non-null. Note that the lifetime of the loaded object
- // is bound by the lifetime of this session instance (i.e., loaded
- // instance cannot outlive this session instance).
-
- void loadMessageProperties(MessageProperties *buffer)
- BSLS_KEYWORD_OVERRIDE;
- // Load into the specified 'buffer' an instance of 'MessageProperties'
- // that can be used to specify and associate properties while building
- // a 'bmqa::Message'. The behavior is undefined unless the session has
- // been successfully started and 'buffer' is non-null. Note that
- // lifetime of the loaded object is bound by the lifetime of this
- // session instance (i.e., loaded instance cannot outlive this session
- // instance).
-
- ///Queue management
- ///----------------
- int getQueueId(QueueId *queueId,
- const bmqt::Uri& uri) const BSLS_KEYWORD_OVERRIDE;
- // Load in the specified 'queueId' the queue corresponding to the
- // specified 'uri' and return 0 if such a queue was found, or leave
- // 'queueId' untouched and return a non-zero value if no queue
- // corresponding to 'uri' is currently open.
-
- int getQueueId(QueueId *queueId,
- const bmqt::CorrelationId& correlationId) const
- BSLS_KEYWORD_OVERRIDE;
- // Load in the specified 'queueId' the queue corresponding to the
- // specified 'correlationId' and return 0 if such a queue was found, or
- // leave 'queueId' untouched and return a non-zero value if no queue
- // corresponding to 'correlationId' is currently open.
-
- int openQueue(QueueId *queueId,
- const bmqt::Uri& uri,
- bsls::Types::Uint64 flags,
- const bmqt::QueueOptions& options = bmqt::QueueOptions(),
- const bsls::TimeInterval& timeout = bsls::TimeInterval())
- BSLS_KEYWORD_OVERRIDE;
- // DEPRECATED: Use the 'openQueueSync(QueueId *queueId...)' instead.
- // This method will be marked as
- // 'BSLS_ANNOTATION_DEPRECATED' in future release of
- // libbmq.
-
- OpenQueueStatus
- openQueueSync(QueueId *queueId,
- const bmqt::Uri& uri,
- bsls::Types::Uint64 flags,
- const bmqt::QueueOptions& options = bmqt::QueueOptions(),
- const bsls::TimeInterval& timeout = bsls::TimeInterval())
- BSLS_KEYWORD_OVERRIDE;
- // Open the queue having the specified 'uri' with the specified 'flags'
- // (a combination of the values defined in 'bmqt::QueueFlags::Enum'),
- // using the specified 'queueId' to correlate events related to that
- // queue. The object 'queueId' referring to is modified, so the
- // 'queueId' represents the actual queue uri, flags and options.
- // Return a result providing the status and context of the operation.
- // Use the optionally specified 'options' to configure some advanced
- // settings. Note that this operation fails if 'queueId' is
- // non-unique. If the optionally specified 'timeout' is not populated,
- // use the one defined in the session options. This operation will
- // block until either success, failure, or timing out happens.
- //
- // THREAD: Note that calling this method from the event processing
- // thread(s) (i.e., from the EventHandler callback, if
- // provided) *WILL* lead to a *DEADLOCK*.
-
- virtual
- int openQueue(const QueueId& queueId,
- const bmqt::Uri& uri,
- bsls::Types::Uint64 flags,
- const bmqt::QueueOptions& options = bmqt::QueueOptions(),
- const bsls::TimeInterval& timeout = bsls::TimeInterval());
- // DEPRECATED: Use the 'openQueue(QueueId *queueId...)' instead. This
- // method will be marked as 'BSLS_ANNOTATION_DEPRECATED' in
- // future release of libbmq.
-
- int
- openQueueAsync(QueueId *queueId,
- const bmqt::Uri& uri,
- bsls::Types::Uint64 flags,
- const bmqt::QueueOptions& options = bmqt::QueueOptions(),
- const bsls::TimeInterval& timeout = bsls::TimeInterval())
- BSLS_KEYWORD_OVERRIDE;
- // DEPRECATED: Use the 'openQueueAsync(...)' with callback flavor
- // instead. This method will be marked as
- // 'BSLS_ANNOTATION_DEPRECATED' in future release of
- // libbmq.
-
- void
- openQueueAsync(QueueId *queueId,
- const bmqt::Uri& uri,
- bsls::Types::Uint64 flags,
- const OpenQueueCallback& callback,
- const bmqt::QueueOptions& options = bmqt::QueueOptions(),
- const bsls::TimeInterval& timeout = bsls::TimeInterval())
- BSLS_KEYWORD_OVERRIDE;
- // Asynchronously open the queue having the specified 'uri' with the
- // specified 'flags' (a combination of the values defined in
- // 'bmqt::QueueFlags::Enum'), using the specified 'queueId' to
- // correlate events related to that queue and the optionally specified
- // 'options' to configure some advanced settings. The object 'queueId'
- // referring to is modified, so the 'queueId' represents the actual
- // queue uri, flags and options. The result of the operation is
- // communicated to the specified 'callback' via a
- // 'bmqa::OpenQueueStatus', providing the status and context of the
- // requested operation. Note that this operation fails if 'queueId' is
- // non-unique. If the optionally specified 'timeout' is not populated,
- // use the one defined in the session options.
- //
- // THREAD: The 'callback' will *ALWAYS* be invoked from the
- // EventHandler thread(s) (or if a SessionEventHandler was not
- // specified, from the thread invoking 'nextEvent').
-
- int
- configureQueue(QueueId *queueId,
- const bmqt::QueueOptions& options,
- const bsls::TimeInterval& timeout = bsls::TimeInterval())
- BSLS_KEYWORD_OVERRIDE;
- // DEPRECATED: Use the 'configureQueueSync(QueueId *queueId...)
- // instead. This method will be marked as
- // 'BSLS_ANNOTATION_DEPRECATED' in future release of
- // libbmq.
-
- ConfigureQueueStatus
- configureQueueSync(
- const QueueId *queueId,
- const bmqt::QueueOptions& options,
- const bsls::TimeInterval& timeout = bsls::TimeInterval())
- BSLS_KEYWORD_OVERRIDE;
- // Configure the queue identified by the specified 'queueId' using the
- // specified 'options' and return a result providing the status and
- // context of the operation. If the optionally specified 'timeout' is
- // not populated, use the one defined in the session options. This
- // operation returns error if there is a pending configure for the same
- // queue. This operation will block until either success, failure, or
- // timing out happens.
- //
- // Note that the following 'bmqt::QueueOptions' fields cannot be
- // reconfigured after the queue has been opened:
- // - suspendsOnBadHostHealth
- // Attempts to reconfigure these fields will yield an 'e_NOT_SUPPORTED'
- // error code.
- //
- // THREAD: Note that calling this method from the event processing
- // thread(s) (i.e., from the EventHandler callback, if
- // provided) *WILL* lead to a *DEADLOCK*.
-
- int configureQueueAsync(
- QueueId *queueId,
- const bmqt::QueueOptions& options,
- const bsls::TimeInterval& timeout = bsls::TimeInterval())
- BSLS_KEYWORD_OVERRIDE;
- // DEPRECATED: Use the 'configureQueueAsync(...)' with callback flavor
- // instead. This method will be marked as
- // 'BSLS_ANNOTATION_DEPRECATED' in future release of
- // libbmq.
-
- void configureQueueAsync(
- const QueueId *queueId,
- const bmqt::QueueOptions& options,
- const ConfigureQueueCallback& callback,
- const bsls::TimeInterval& timeout = bsls::TimeInterval())
- BSLS_KEYWORD_OVERRIDE;
- // Asynchronously configure the queue identified by the specified
- // 'queueId' using the specified 'options' to configure some advanced
- // settings. The result of the operation is communicated to the
- // specified 'callback' via a 'bmqa::ConfigureQueueStatus', providing
- // the status and context of the requested operation. If the
- // optionally specified 'timeout' is not populated, use the one defined
- // in the session options.
- //
- // Note that the following 'bmqt::QueueOptions' fields cannot be
- // reconfigured after the queue has been opened:
- // - suspendsOnBadHostHealth
- // Attempts to reconfigure these fields will yield an 'e_NOT_SUPPORTED'
- // error code.
- //
- // THREAD: The 'callback' will *ALWAYS* be invoked from the
- // EventHandler thread(s) (or if a SessionEventHandler was not
- // specified, from the thread invoking 'nextEvent').
-
- int closeQueue(QueueId *queueId,
- const bsls::TimeInterval& timeout = bsls::TimeInterval())
- BSLS_KEYWORD_OVERRIDE;
- // DEPRECATED: Use the 'closeQueueSync(QueueId *queueId...) instead.
- // This method will be marked as
- // 'BSLS_ANNOTATION_DEPRECATED' in future release of
- // libbmq.
-
- CloseQueueStatus
- closeQueueSync(const QueueId *queueId,
- const bsls::TimeInterval& timeout = bsls::TimeInterval())
- BSLS_KEYWORD_OVERRIDE;
- // Close the queue identified by the specified 'queueId' and return a
- // result providing the status and context of the operation. If the
- // optionally specified 'timeout' is not populated, use the one defined
- // in the session options. Any outstanding configureQueue request for
- // this 'queueId' will be canceled. This operation will block until
- // either success, failure, or timing out happens. Once this method
- // returns, there is guarantee that no more messages and events for
- // this 'queueId' will be received. Note that successful processing of
- // this request in the broker closes this session's view of the queue;
- // the underlying queue may not be deleted in the broker. When this
- // method returns, the correlationId associated to the queue is
- // cleared.
- //
- // THREAD: Note that calling this method from the event processing
- // thread(s) (i.e., from the EventHandler callback, if
- // provided) *WILL* lead to a *DEADLOCK*.
-
- virtual
- int closeQueue(const QueueId& queueId,
- const bsls::TimeInterval& timeout = bsls::TimeInterval());
- // DEPRECATED: Use the 'closeQueue(QueueId *queueId...) instead. This
- // method will be marked as 'BSLS_ANNOTATION_DEPRECATED' in
- // future release of libbmq.
-
- int
- closeQueueAsync(QueueId *queueId,
- const bsls::TimeInterval& timeout = bsls::TimeInterval())
- BSLS_KEYWORD_OVERRIDE;
- // DEPRECATED: Use the 'closeQueueAsync(...)' with callback flavor
- // instead. This method will be marked as
- // 'BSLS_ANNOTATION_DEPRECATED' in future release of
- // libbmq.
-
- void closeQueueAsync(
- const QueueId *queueId,
- const CloseQueueCallback& callback,
- const bsls::TimeInterval& timeout = bsls::TimeInterval())
- BSLS_KEYWORD_OVERRIDE;
- // Asynchronously close the queue identified by the specified
- // 'queueId'. Any outstanding configureQueue requests will be
- // canceled. The result of the operation is communicated to the
- // specified 'callback' via a 'bmqa::CloseQueueStatus', providing the
- // status and context of the operation. If the optionally specified
- // 'timeout' is not populated, use the one defined in the session
- // options. Note that successful processing of this request in the
- // broker closes this session's view of the queue; the underlying queue
- // may not be deleted in the broker. The correlationId associated to
- // the queue remains valid until the 'bmqa::CloseQueueStatus' result
- // has been received and processed by the 'callback', after which it
- // will be cleared and no more messages and events for this 'queueId'
- // will be received.
- //
- // THREAD: The 'callback' will *ALWAYS* be invoked from the
- // EventHandler thread(s) (or if a SessionEventHandler was not
- // specified, from the thread invoking 'nextEvent').
-
- virtual
- int
- closeQueueAsync(const QueueId& queueId,
- const bsls::TimeInterval& timeout = bsls::TimeInterval());
- // DEPRECATED: Use the 'closeQueueAsync(...)' with callback flavor
- // instead. This method will be marked as
- // 'BSLS_ANNOTATION_DEPRECATED' in future release of
- // libbmq.
-
- ///Queue manipulation
- ///------------------
- Event nextEvent(const bsls::TimeInterval& timeout = bsls::TimeInterval())
- BSLS_KEYWORD_OVERRIDE;
- // Return the next available event received for this session. If there
- // is no event available, this method blocks for up to the optionally
- // specified 'timeout' time interval for an event to arrive. An empty
- // time interval for 'timeout' (the default) indicates that the method
- // should not timeout (the method will not return until the next event
- // is available). Return a 'bmqa::SessionEvent' of type
- // 'bmqt::SessionEventType::e_TIMEOUT' if a timeout was specified and
- // that timeout expired before any event was received. Note that this
- // method can only be used if the session is in synchronous mode (ie
- // not using the EventHandler). The behavior is undefined unless the
- // session was started.
-
- int post(const MessageEvent& event) BSLS_KEYWORD_OVERRIDE;
- // Asynchronously post the specified 'event' that must contain one or
- // more 'Messages'. The return value is one of the values defined in
- // the 'bmqt::PostResult::Enum' enum. Return zero on success and a
- // non-zero value otherwise. Note that success implies that SDK has
- // accepted the 'event' and will eventually deliver it to the broker.
- // The behavior is undefined unless the session was started.
-
- int confirmMessage(const Message& message) BSLS_KEYWORD_OVERRIDE;
- // Asynchronously confirm the receipt of the specified 'message'. This
- // indicates that the application is done processing the message and
- // that the broker can safely discard it from the queue according to
- // the retention policy set up for that queue. Return 0 on success,
- // and a non-zero value otherwise. Note that success implies that SDK
- // has accepted the 'message' and will eventually send confirmation
- // notification to the broker.
-
- int confirmMessage(const MessageConfirmationCookie& cookie)
- BSLS_KEYWORD_OVERRIDE;
- // Asynchronously confirm the receipt of the message with which the
- // specified 'cookie' is associated. This indicates that the
- // application is done processing the message and that the broker can
- // safely discard it from the queue according to the retention policy
- // set up for that queue. Return 0 on success, and a non-zero value
- // otherwise. Note that success implies that SDK has accepted the
- // 'message' and will eventually send confirmation notification to the
- // broker.
-
- int confirmMessages(ConfirmEventBuilder *builder) BSLS_KEYWORD_OVERRIDE;
- // Asynchronously confirm the receipt of the batch of CONFIRM messages
- // contained in the specified 'builder'. This indicates that the
- // application is done processing all of the messages and that the
- // broker can safely discard them from the queue according to the
- // retention policy set up for that queue. The return value is one of
- // the values defined in the 'bmqt::GenericResult::Enum' enum. Note
- // that in case of success, the instance pointed by the 'builder' will
- // be reset. Also note that success implies that SDK has accepted all
- // of the messages in 'builder' and will eventually send confirmation
- // notification to the broker, whereas failure implies that none of the
- // messages in 'builder' were accepted. Behavior is undefined unless
- // 'builder' is non-null.
-
- ///Debugging related
- ///-----------------
- int configureMessageDumping(const bslstl::StringRef& command)
- BSLS_KEYWORD_OVERRIDE;
- // Configure this session instance to dump messages to the installed
- // logger at 'ball::Severity::INFO' level according to the specified
- // 'command' that should adhere to the following pattern:
- //..
- // IN|OUT|PUSH|ACK|PUT|CONFIRM ON|OFF|100|10s
- //..
- // where each token has a specific meaning:
- //: o !IN! : incoming ('PUSH' and 'ACK') events
- //: o !OUT! : outgoing ('PUT' and 'CONFIRM') events
- //: o !PUSH! : incoming 'PUSH' events
- //: o !ACK! : incoming 'ACK' events
- //: o !PUT! : outgoing 'PUT' events
- //: o !CONFIRM! : outgoing 'CONFIRM' events
- //: o !ON! : turn on message dumping until explicitly turned off
- //: o !OFF! : turn off message dumping
- //: o !100! : turn on message dumping for the next 100 messages
- //: o !10s! : turn on message dumping for the next 10 seconds
- // Above, the numerical values '100' and '10' are just for illustration
- // purposes, and application can choose an appropriate positive numeric
- // value for them. Also, pattern is case-insensitive. Return zero if
- // 'command' is valid and message dumping has been configured, non-zero
- // value otherwise. The behavior is undefined unless the session has
- // been started.
-
- ///Internal
- ///--------
- void *impl();
- // Do *NOT* use. Internal function, reserved for BlazingMQ internal
- // usage.
-};
-
-// ============================================================================
-// INLINE DEFINITIONS
-// ============================================================================
-
- // -------------
- // class Session
- // -------------
-
-inline
-int
-Session::confirmMessage(const Message& message)
-{
- return confirmMessage(message.confirmationCookie());
-}
-
-inline
-void*
-Session::impl()
-{
- return &d_impl;
-}
-
-
-} // close package namespace
-} // close enterprise namespace
-
-#endif
-
-Generated on Thu Jun 15 2023 11:58:50 by
-
- 1.7.1
-
-
diff --git a/docs/docs/apidocs/cpp_apidocs/bmqa__sessionevent_8h_source.html b/docs/docs/apidocs/cpp_apidocs/bmqa__sessionevent_8h_source.html
deleted file mode 100644
index 06e52c930..000000000
--- a/docs/docs/apidocs/cpp_apidocs/bmqa__sessionevent_8h_source.html
+++ /dev/null
@@ -1,176 +0,0 @@
-
-
-Bloomberg Development Environment
-
-
-// Copyright 2014-2023 Bloomberg Finance L.P.
-// SPDX-License-Identifier: Apache-2.0
-//
-// Licensed under the Apache License, Version 2.0 (the "License");
-// you may not use this file except in compliance with the License.
-// You may obtain a copy of the License at
-//
-// http://www.apache.org/licenses/LICENSE-2.0
-//
-// Unless required by applicable law or agreed to in writing, software
-// distributed under the License is distributed on an "AS IS" BASIS,
-// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-// See the License for the specific language governing permissions and
-// limitations under the License.
-
-// bmqa_sessionevent.h -*-C++-*-
-#ifndef INCLUDED_BMQA_SESSIONEVENT
-#define INCLUDED_BMQA_SESSIONEVENT
-
-//@PURPOSE: Provide value-semantic type for system event session notifications.
-//
-//@CLASSES:
-// bmqa::SessionEvent: type for notification events related to the 'Session'.
-//
-//@SEE_ALSO:
-// bmqt::SessionEventType: Enum of the various type of notifications
-//
-//@DESCRIPTION: This component provides a generic 'bmqa::SessionEvent'
-// notification object used by the 'bmqa::Session' to provide BlazingMQ
-// applications with information regarding changes in the session status or the
-// result of operations with the message queue broker.
-//
-// A 'SessionEvent' is composed of 4 attributes:
-//: o !type!: indicate the type of the notification
-//: o !statusCode!: indicate the status of the operation (success,
-//: failure)
-//: o !correlationId!: optional correlationId used during async response
-//: o !queueId!: optional queueId associated with the event, of type
-//: 'OPEN', 'CONFIGURE', 'CLOSE', 'REOPEN'
-//: o !errorDescription!: optional string with a human readable description of
-//: the error, if any
-//
-// Note that 'SessionEvent' is implemented using the pimpl idiom, so copying a
-// 'SessionEvent' is very cheap (a pointer copy). All copies of this
-// 'SessionEvent' will share the same underlying implementation.
-
-
-// BMQ
-#include <bmqscm_version.h>
-#include <bmqa_queueid.h>
-#include <bmqt_correlationid.h>
-#include <bmqt_sessioneventtype.h>
-
-// BDE
-#include <bsl_memory.h>
-#include <bsl_string.h>
-
-namespace BloombergLP {
-
-// FORWARD DECLARATION
-namespace bmqimp { class Event; }
-
-namespace bmqa {
-
- // ==================
- // class SessionEvent
- // ==================
-
-class SessionEvent {
- // An event related to the operation of a 'Session'.
-
- private:
- // FRIENDS
- friend bool operator==(const SessionEvent& lhs, const SessionEvent& rhs);
- friend bool operator!=(const SessionEvent& lhs, const SessionEvent& rhs);
-
- private:
- // DATA
- bsl::shared_ptr<bmqimp::Event> d_impl_sp; // pimpl
-
- public:
- // CREATORS
- explicit SessionEvent();
- // Default constructor
-
- SessionEvent(const SessionEvent& other);
- // Create a new 'SessionEvent' having the same values (pointing to the
- // same pimpl) as the specified 'other'.
-
- // MANIPULATORS
- SessionEvent& operator=(const SessionEvent& rhs);
- // Assign to this 'SessionEvent' the same values as the one from the
- // specified 'rhs' (i.e., reference the same pimpl).
-
- // ACCESSORS
- bmqt::SessionEventType::Enum type() const;
- // Return the session event type.
-
- const bmqt::CorrelationId& correlationId() const;
- // Return the correlationId associated to this event, if any.
-
- QueueId queueId() const;
- // Return the queueId associated to this event, if any. The behavior
- // is undefined unless this event corresponds to a queue related event
- // (i.e. 'OPEN', 'CONFIGURE', 'CLOSE', 'REOPEN').
-
- int statusCode() const;
- // Return the status code that indicates success or the cause of a
- // failure.
-
- const bsl::string& errorDescription() const;
- // Return a printable description of the error, if 'statusCode' returns
- // non-zero. Return an empty string otherwise.
-
- bsl::ostream& print(bsl::ostream& stream,
- int level = 0,
- int spacesPerLevel = 4) const;
- // Format this object to the specified output 'stream' at the (absolute
- // value of) the optionally specified indentation 'level' and return a
- // reference to 'stream'. If 'level' is specified, optionally specify
- // 'spacesPerLevel', the number of spaces per indentation level for
- // this and all of its nested objects. If 'level' is negative,
- // suppress indentation of the first line. If 'spacesPerLevel' is
- // negative format the entire output on one line, suppressing all but
- // the initial indentation (as governed by 'level'). If 'stream' is
- // not valid on entry, this operation has no effect.
-};
-
-// FREE OPERATORS
-bool operator==(const SessionEvent& lhs,
- const SessionEvent& rhs);
- // Return 'true' if the specified 'rhs' object contains the value of the
- // same type as contained in the specified 'lhs' object and the value
- // itself is the same in both objects, return false otherwise.
-
-bool operator!=(const SessionEvent& lhs,
- const SessionEvent& rhs);
- // Return 'false' if the specified 'rhs' object contains the value of the
- // same type as contained in the specified 'lhs' object and the value
- // itself is the same in both objects, return 'true' otherwise.
-
-bsl::ostream& operator<<(bsl::ostream& stream,
- const SessionEvent& rhs);
- // Format the specified 'rhs' to the specified output 'stream' and return a
- // reference to the modifiable 'stream'.
-
-} // close package namespace
-
-
-// ============================================================================
-// INLINE DEFINITIONS
-// ============================================================================
-
- // ------------------
- // class SessionEvent
- // ------------------
-
-inline
-bsl::ostream&
-bmqa::operator<<(bsl::ostream& stream,
- const bmqa::SessionEvent& rhs)
-{
- return rhs.print(stream, 0, -1);
-}
-
-} // close enterprise namespace
-
-#endif
-
-Generated on Thu Jun 15 2023 11:58:50 by
-
- 1.7.1
-
-
diff --git a/docs/docs/apidocs/cpp_apidocs/bmqpi_8h_source.html b/docs/docs/apidocs/cpp_apidocs/bmqpi_8h_source.html
deleted file mode 100644
index 4e2e5593a..000000000
--- a/docs/docs/apidocs/cpp_apidocs/bmqpi_8h_source.html
+++ /dev/null
@@ -1,32 +0,0 @@
-
-
-Bloomberg Development Environment
-
-
- bmqpi.txt
-
-@PURPOSE: Provide an interface for monitoring the health of the host.
-
-@MNEMONIC: BlazingMQ Public Interfaces (bmqpi)
-
-@DESCRIPTION: The 'bmqpi' package provides pure abstract interfaces, which are
- intended for clients to extend in their own applications and libraries. These
- extension points facilitate integration with other aspects of a runtime
- environment (e.g. authentication, host health-checking), which may vary
- significantly from organization to organization.
-
-/Hierarchical Synopsis
-/---------------------
- The 'bmqpi' package currently has 1 component having 1 level of physical
- dependency. The list below shows the hierarchical ordering of the components.
-..
- 1. bmqpi_hosthealthmonitor
-..
-
-/Component Synopsis
-/------------------
-: 'bmqpi_hosthealthmonitor':
-: Provide an interface for monitoring the health of the host.
-
-Generated on Thu Jun 15 2023 11:58:50 by
-
- 1.7.1
-
-
diff --git a/docs/docs/apidocs/cpp_apidocs/bmqpi__dtcontext_8h_source.html b/docs/docs/apidocs/cpp_apidocs/bmqpi__dtcontext_8h_source.html
deleted file mode 100644
index 073e7d284..000000000
--- a/docs/docs/apidocs/cpp_apidocs/bmqpi__dtcontext_8h_source.html
+++ /dev/null
@@ -1,99 +0,0 @@
-
-
-Bloomberg Development Environment
-
-
-// Copyright 2021-2023 Bloomberg Finance L.P.
-// SPDX-License-Identifier: Apache-2.0
-//
-// Licensed under the Apache License, Version 2.0 (the "License");
-// you may not use this file except in compliance with the License.
-// You may obtain a copy of the License at
-//
-// http://www.apache.org/licenses/LICENSE-2.0
-//
-// Unless required by applicable law or agreed to in writing, software
-// distributed under the License is distributed on an "AS IS" BASIS,
-// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-// See the License for the specific language governing permissions and
-// limitations under the License.
-
-// bmqpi_dtcontext.h -*-C++-*-
-#ifndef INCLUDED_BMQPI_DTCONTEXT
-#define INCLUDED_BMQPI_DTCONTEXT
-
-//@PURPOSE: Provide an interface for a context with a notion of a current span.
-//
-//@CLASSES:
-// bmqpi::DTContext: Interface for a context with a notion of a current span.
-//
-//@DESCRIPTION:
-// 'bmqpi::DTContext' is a pure interface representing a context which defines
-// a "current" 'bmqpi::DTSpan' for the calling thread. Implementations *may*
-// return different spans for each thread, or return a single span shared by
-// all calling threads.
-//
-// Many distributed trace libraries provide a well-defined thread-local storage
-// slot for the span currently under execution, which allows a function to
-// obtain a reference to its caller across library boundaries, without changes
-// to its API to facilitate dependency injection. This storage slot is set by
-// instantiating an RAII "Span Guard" that writes a span to the TLS at
-// construction, and reverts its state on destruction (emulating the semantics
-// of a call-stack). The API of 'bmqpi::DTContext' aims to make it easy to wrap
-// these common patterns in a library-agnostic manner, while also facilitating
-// test double implementations.
-//
-
-// BMQ
-#include <bmqscm_version.h>
-#include <bmqpi_dtspan.h>
-
-// BDE
-#include <bsl_memory.h>
-#include <bslma_managedptr.h>
-
-namespace BloombergLP {
-namespace bmqpi {
-
- // ===============
- // class DTContext
- // ===============
-
-class DTContext {
- // A pure interface for a context with a notion of a current span.
-
- public:
- // PUBLIC CREATORS
- virtual ~DTContext();
- // Destructor
-
- // PUBLIC ACCESSORS
- virtual bsl::shared_ptr<bmqpi::DTSpan> span() const = 0;
- // Returns the current 'DTSpan' for the calling thread according to
- // this 'DTContext', or an empty 'shared_ptr' if no span is currently
- // set.
-
- // PUBLIC MANIPULATORS
- virtual
- bslma::ManagedPtr<void>
- scope(const bsl::shared_ptr<DTSpan>& newSpan) = 0;
- // Letting 'previous = span()' on some thread 'T', returns an object
- // 'token' which promises:
- //: o 'span()' will return 'newSpan' when called on thread 'T',
- //: following the construction of 'token'.
- //: o 'span()' will return 'previous' when called on thread 'T',
- //: following the destruction of 'token'.
- //
- // Note that if 'token2 = scope(otherSpan)' is called on thread 'T'
- // during the lifetime of 'token', then 'span()' will return
- // 'otherSpan'. After 'token2' is destroyed, it will again return
- // 'newSpan'.
-};
-
-} // close package namespace
-} // close enterprise namespace
-
-#endif
-
-Generated on Thu Jun 15 2023 11:58:50 by
-
- 1.7.1
-
-
diff --git a/docs/docs/apidocs/cpp_apidocs/bmqpi__dtspan_8h_source.html b/docs/docs/apidocs/cpp_apidocs/bmqpi__dtspan_8h_source.html
deleted file mode 100644
index d51927843..000000000
--- a/docs/docs/apidocs/cpp_apidocs/bmqpi__dtspan_8h_source.html
+++ /dev/null
@@ -1,128 +0,0 @@
-
-
-Bloomberg Development Environment
-
-
-// Copyright 2021-2023 Bloomberg Finance L.P.
-// SPDX-License-Identifier: Apache-2.0
-//
-// Licensed under the Apache License, Version 2.0 (the "License");
-// you may not use this file except in compliance with the License.
-// You may obtain a copy of the License at
-//
-// http://www.apache.org/licenses/LICENSE-2.0
-//
-// Unless required by applicable law or agreed to in writing, software
-// distributed under the License is distributed on an "AS IS" BASIS,
-// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-// See the License for the specific language governing permissions and
-// limitations under the License.
-
-// bmqpi_dtspan.h -*-C++-*-
-#ifndef INCLUDED_BMQPI_DTSPAN
-#define INCLUDED_BMQPI_DTSPAN
-
-//@PURPOSE: Provide an interface representing a span of a distributed trace.
-//
-//@CLASSES:
-// bmqpi::DTSpan: Interface for a span of a distributed trace.
-// bmqpi::DTSpan::Baggage: A set of key-values used to describe a 'DTSpan'.
-//
-//@DESCRIPTION:
-// 'bmqpi::DTSpan' is a pure interface representing a node within a distributed
-// trace graph (which forms a DAG with edges as invocations).
-//
-// 'bmqpi::DTSpan::Baggage' represents a set of key-values used to describe
-// metadata belonging to a 'DTSpan'. The phrase "baggage" is borrowed from the
-// OpenTelemetry standard's terminology.
-
-// BMQ
-#include <bmqscm_version.h>
-
-// BDE
-#include <bsl_unordered_map.h>
-#include <bsl_string.h>
-#include <bsl_string_view.h>
-#include <bslma_allocator.h>
-
-namespace BloombergLP {
-namespace bmqpi {
-
- // ============
- // class DTSpan
- // ============
-
-class DTSpan {
- // A pure interface for representing a span of a distributed trace.
-
- public:
- // PUBLIC CREATORS
- virtual ~DTSpan();
- // Destructor
-
- // PUBLIC ACCESSORS
- virtual bsl::string_view operation() const = 0;
- // Returns the name of the operation that this 'DTSpan' represents.
-
- // =============
- // class Baggage
- // =============
-
-
- // PUBLIC INNER CLASSES
- class Baggage BSLS_KEYWORD_FINAL {
- // A set of key-values used to describe a 'DTSpan'.
-
- private:
- // PRIVATE TYPEDEFS
- typedef bsl::unordered_map<bsl::string, bsl::string> MapType;
-
- // PRIVATE DATA
- MapType d_data;
-
- public:
- // PUBLIC TYPES
- typedef MapType::const_iterator const_iterator;
-
- // PUBLIC CREATORS
- Baggage(bslma::Allocator *allocator = 0);
-
- // PUBLIC ACCESSORS
- const_iterator begin() const;
- // Returns a const-iterator used to iterate over key-values.
-
- const_iterator end() const;
- // Returns a const-iterator representing the end of key-values.
-
- bool has(const bsl::string& key) const;
- // Returns whether this object holds a value associated with the
- // specified 'key'.
-
- bsl::string_view get(const bsl::string& key,
- const bsl::string_view& dflt = "") const;
- // Returns the value currently associated with 'key', or 'dflt' if
- // no associated value is currently held.
- //
- // Beware that if 'key' is not found and the returned 'string_view'
- // outlives 'dflt', then the 'string_view' will reference a
- // deallocated address.
-
- // PUBLIC MANIPULATORS
- void put(const bsl::string_view& key, const bsl::string_view& value);
- // Stores the specified 'value' associated with the specified
- // 'key'. Note that if such a 'key' was already stored, then its
- // associated value will be replaced by the supplied one.
-
- bool erase(const bsl::string& key);
- // Erases any value currently associated with 'key', and returns
- // whether any such value was previously held.
- };
-};
-
-} // close package namespace
-} // close enterprise namespace
-
-#endif
-
-Generated on Thu Jun 15 2023 11:58:50 by
-
- 1.7.1
-
-
diff --git a/docs/docs/apidocs/cpp_apidocs/bmqpi__dttracer_8h_source.html b/docs/docs/apidocs/cpp_apidocs/bmqpi__dttracer_8h_source.html
deleted file mode 100644
index 0918a25ab..000000000
--- a/docs/docs/apidocs/cpp_apidocs/bmqpi__dttracer_8h_source.html
+++ /dev/null
@@ -1,73 +0,0 @@
-
-
-Bloomberg Development Environment
-
-
-// Copyright 2021-2023 Bloomberg Finance L.P.
-// SPDX-License-Identifier: Apache-2.0
-//
-// Licensed under the Apache License, Version 2.0 (the "License");
-// you may not use this file except in compliance with the License.
-// You may obtain a copy of the License at
-//
-// http://www.apache.org/licenses/LICENSE-2.0
-//
-// Unless required by applicable law or agreed to in writing, software
-// distributed under the License is distributed on an "AS IS" BASIS,
-// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-// See the License for the specific language governing permissions and
-// limitations under the License.
-
-// bmqpi_dttracer.h -*-C++-*-
-#ifndef INCLUDED_BMQPI_DTTRACER
-#define INCLUDED_BMQPI_DTTRACER
-
-//@PURPOSE: Provide an interface that can create new 'DTSpan' objects.
-//
-//@CLASSES:
-// bmqpi::DTTracer: Interface for creators of 'DTSpan' objects.
-//
-//@DESCRIPTION:
-// 'bmqpi::DTTracer' is a pure interface for creators of new 'DTSpan' objects.
-
-// BMQ
-#include <bmqscm_version.h>
-#include <bmqpi_dtspan.h>
-
-// BDE
-#include <bsl_memory.h>
-#include <bsl_string_view.h>
-
-namespace BloombergLP {
-namespace bmqpi {
-
- // ==============
- // class DTTracer
- // ==============
-
-class DTTracer {
- // A pure interface for creators of 'DTSpan' objects.
-
- public:
- // PUBLIC CREATORS
- virtual ~DTTracer();
- // Destructor
-
- // PUBLIC METHODS
- virtual
- bsl::shared_ptr<DTSpan>
- createChildSpan(const bsl::shared_ptr<DTSpan>& parent,
- const bsl::string_view& operation,
- const DTSpan::Baggage& baggage
- = DTSpan::Baggage()) const = 0;
- // Creates and returns a new 'DTSpan' representing 'operation' as a
- // child of 'parent', having the key-value tags defined by 'baggage'.
-};
-
-} // close package namespace
-} // close enterprise namespace
-
-#endif
-
-Generated on Thu Jun 15 2023 11:58:50 by
-
- 1.7.1
-
-
diff --git a/docs/docs/apidocs/cpp_apidocs/bmqpi__hosthealthmonitor_8h_source.html b/docs/docs/apidocs/cpp_apidocs/bmqpi__hosthealthmonitor_8h_source.html
deleted file mode 100644
index 3c65fb54d..000000000
--- a/docs/docs/apidocs/cpp_apidocs/bmqpi__hosthealthmonitor_8h_source.html
+++ /dev/null
@@ -1,86 +0,0 @@
-
-
-Bloomberg Development Environment
-
-
-// Copyright 2021-2023 Bloomberg Finance L.P.
-// SPDX-License-Identifier: Apache-2.0
-//
-// Licensed under the Apache License, Version 2.0 (the "License");
-// you may not use this file except in compliance with the License.
-// You may obtain a copy of the License at
-//
-// http://www.apache.org/licenses/LICENSE-2.0
-//
-// Unless required by applicable law or agreed to in writing, software
-// distributed under the License is distributed on an "AS IS" BASIS,
-// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-// See the License for the specific language governing permissions and
-// limitations under the License.
-
-// bmqpi_hosthealthmonitor.h -*-C++-*-
-#ifndef INCLUDED_BMQPI_HOSTHEALTHMONITOR
-#define INCLUDED_BMQPI_HOSTHEALTHMONITOR
-
-//@PURPOSE: Provide an interface for monitoring the health of the host.
-//
-//@CLASSES:
-// bmqpi::HostHealthMonitor: Interface for a monitor of host health.
-//
-//@DESCRIPTION:
-// 'bmqpi::HostHealthMonitor' is a pure interface for a monitor of the health
-// of the host. BlazingMQ sessions can use such objects to conditionally
-// suspend queue activity while the host is marked unhealthy.
-
-
-// BMQ
-#include <bmqscm_version.h>
-#include <bmqt_hosthealthstate.h>
-
-// BDE
-#include <bsl_functional.h>
-#include <bdlmt_signaler.h>
-
-namespace BloombergLP {
-namespace bmqpi {
-
- // =======================
- // class HostHealthMonitor
- // =======================
-
-class HostHealthMonitor {
- // A pure interface for monitoring the health of the host.
-
- public:
- // TYPES
- typedef bsl::function<void(bmqt::HostHealthState::Enum)>
- HostHealthChangeFn;
- // Invoked as a response to the HostHealthMonitor detecting a change
- // in the state of the host health.
-
- public:
- // CREATORS
- virtual
- ~HostHealthMonitor();
- // Destructor
-
- // MANIPULATORS
- virtual
- bdlmt::SignalerConnection
- observeHostHealth(const HostHealthChangeFn& cb) = 0;
- // Registers the specified `cb` to be invoked each time the health of
- // the host changes.
-
- // ACCESSORS
- virtual
- bmqt::HostHealthState::Enum hostState() const = 0;
- // Queries the current health of the host.
-};
-
-} // close package namespace
-} // close enterprise namespace
-
-#endif
-
-Generated on Thu Jun 15 2023 11:58:50 by
-
- 1.7.1
-
-
diff --git a/docs/docs/apidocs/cpp_apidocs/bmqt_8h_source.html b/docs/docs/apidocs/cpp_apidocs/bmqt_8h_source.html
deleted file mode 100644
index 5159d3260..000000000
--- a/docs/docs/apidocs/cpp_apidocs/bmqt_8h_source.html
+++ /dev/null
@@ -1,76 +0,0 @@
-
-
-Bloomberg Development Environment
-
-
- bmqt.txt
-
-@PURPOSE: Provide value-semantic vocabulary types.
-
-@MNEMONIC: BlazingMQ (vocabulary) Types (bmqt)
-
-@DESCRIPTION: The 'bmqt' package provides low level value-semantic vocabulary
- types for use by the BlazingMQ SDK.
-
-/Hierarchical Synopsis
-/---------------------
- The 'bmqt' package currently has 11 components having 1 level of physical
- dependency. The list below shows the hierarchical ordering of the components.
-..
- 1. bmqt_correlationid
- bmqt_encodingtype
- bmqt_hosthealthstate
- bmqt_messageeventtype
- bmqt_messageguid
- bmqt_queueflags
- bmqt_queueoptions
- bmqt_resultcode
- bmqt_sessioneventtype
- bmqt_sessionoptions
- bmqt_uri
- bmqt_version
-..
-
-/Component Synopsis
-/------------------
-: 'bmqt_compressionalgorithmtype':
-: Provide an enumeration for different compression algorithm types.
-
-: 'bmqt_correlationid':
-: Provide a value-semantic type usable as an efficient identifier.
-:
-: 'bmqt_encodingtype':
-: Provide an enumeration for different message encoding types.
-:
-: 'bmqt_hosthealthstate':
-: Provide an enumeration for different host health states.
-:
-: 'bmqt_messageeventtype':
-: Provide an enumeration for the different types of message events.
-:
-: 'bmqt_messageguid':
-: Provide a value-semantic global unique identifier for BlazingMQ messages
-:
-: 'bmqt_queueflags':
-: Provide enums for flags to use at Queue open.
-:
-: 'bmqt_queueoptions':
-: Provide a value-semantic type for options related to a queue.
-:
-: 'bmqt_resultcode':
-: Provide enums for various publicly exposed result code.
-:
-: 'bmqt_sessioneventtype':
-: Provide an enumeration for the different types of session events.
-:
-: 'bmqt_sessionoptions':
-: Provide a value-semantic type to configure session with the broker.
-:
-: 'bmqt_uri':
-: Provide value-semantic type and utilities for a BlazingMQ queue URI.
-:
-: 'bmqt_version':
-: Provide a value-semantic type representing a version (major minor).
-
-Generated on Thu Jun 15 2023 11:58:50 by
-
- 1.7.1
-
-
diff --git a/docs/docs/apidocs/cpp_apidocs/bmqt__compressionalgorithmtype_8h_source.html b/docs/docs/apidocs/cpp_apidocs/bmqt__compressionalgorithmtype_8h_source.html
deleted file mode 100644
index 975a96127..000000000
--- a/docs/docs/apidocs/cpp_apidocs/bmqt__compressionalgorithmtype_8h_source.html
+++ /dev/null
@@ -1,163 +0,0 @@
-
-
-Bloomberg Development Environment
-
-
-// Copyright 2019-2023 Bloomberg Finance L.P.
-// SPDX-License-Identifier: Apache-2.0
-//
-// Licensed under the Apache License, Version 2.0 (the "License");
-// you may not use this file except in compliance with the License.
-// You may obtain a copy of the License at
-//
-// http://www.apache.org/licenses/LICENSE-2.0
-//
-// Unless required by applicable law or agreed to in writing, software
-// distributed under the License is distributed on an "AS IS" BASIS,
-// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-// See the License for the specific language governing permissions and
-// limitations under the License.
-
-// bmqt_compressionalgorithmtype.h -*-C++-*-
-#ifndef INCLUDED_BMQT_COMPRESSIONALGORITHMTYPE
-#define INCLUDED_BMQT_COMPRESSIONALGORITHMTYPE
-
-//@PURPOSE: Provide an enumeration for different compression algorithm types.
-//
-//@CLASSES:
-// bmqt::CompressionAlgorithmType: Type of compression algorithm
-//
-//@DESCRIPTION: Provide an enumeration, 'bmqt::CompressionAlgorithmType' for
-// different types of compression algorithm.
-//
-//: o !NONE!: No compression algorithm was specified
-//: o !ZLIB!: The compression algorithm is ZLIB
-
-// BMQ
-#include <bmqscm_version.h>
-
-// BDE
-#include <bsl_ostream.h>
-#include <bsl_string.h>
-
-namespace BloombergLP {
-namespace bmqt {
-
- // ===============================
- // struct CompressionAlgorithmType
- // ===============================
-
-struct CompressionAlgorithmType {
- // This struct defines various types of compression algorithms.
-
- // TYPES
- enum Enum {
- e_UNKNOWN = -1
- , e_NONE = 0
- , e_ZLIB = 1
- };
-
- // CONSTANTS
- static const int k_LOWEST_SUPPORTED_TYPE = e_NONE;
- // NOTE: This value must always be equal to the lowest type in the
- // enum because it is being used as a lower bound to verify that a
- // header's 'CompressionAlgorithmType' field is a supported type.
-
- static const int k_HIGHEST_SUPPORTED_TYPE = e_ZLIB;
- // NOTE: This value must always be equal to the highest type in the
- // enum because it is being used as an upper bound to verify that a
- // header's 'CompressionAlgorithmType' field is a supported type.
-
- // CLASS METHODS
- static
- bsl::ostream& print(bsl::ostream& stream,
- CompressionAlgorithmType::Enum value,
- int level = 0,
- int spacesPerLevel = 4);
- // Write the string representation of the specified enumeration 'value'
- // to the specified output 'stream', and return a reference to
- // 'stream'. Optionally specify an initial indentation 'level', whose
- // absolute value is incremented recursively for nested objects. If
- // 'level' is specified, optionally specify 'spacesPerLevel', whose
- // absolute value indicates the number of spaces per indentation level
- // for this and all of its nested objects. If 'level' is negative,
- // suppress indentation of the first line. If 'spacesPerLevel' is
- // negative, format the entire output on one line, suppressing all but
- // the initial indentation (as governed by 'level'). See 'toAscii' for
- // what constitutes the string representation of a
- // 'CompressionAlgorithmType::Enum' value.
-
- static const char *toAscii(CompressionAlgorithmType::Enum value);
- // Return the non-modifiable string representation corresponding to the
- // specified enumeration 'value', if it exists, and a unique (error)
- // string otherwise. The string representation of 'value' matches its
- // corresponding enumerator name with the "e_" prefix eluded. For
- // example:
- //..
- // bsl::cout << CompressionAlgorithmType::toAscii(
- // CompressionAlgorithmType::e_NONE);
- //..
- // will print the following on standard output:
- //..
- // NONE
- //..
- // Note that specifying a 'value' that does not match any of the
- // enumerators will result in a string representation that is distinct
- // from any of those corresponding to the enumerators, but is otherwise
- // unspecified.
-
- static bool fromAscii(CompressionAlgorithmType::Enum *out,
- const bsl::string& str);
- // Update the specified 'out' with correct enum corresponding to the
- // specified string 'str', if it exists, and return true. Otherwise in
- // case of an error or unidentified string, return false. The expected
- // 'str' is the enumerator name with the "e_" prefix excluded.
- // For example:
- //..
- // CompressionAlgorithmType::fromAscii(out, NONE);
- //..
- // will return true and the value of 'out' will be:
- //..
- // bmqt::CompresssionAlgorithmType::e_NONE
- //..
- // Note that specifying a 'str' that does not match any of the
- // enumerators excluding "e_" prefix will result in the function
- // returning false and the specified 'out' will not be touched.
-
- static bool isValid(const bsl::string *str, bsl::ostream& stream);
- // Return true incase of valid specified 'str' i.e. a enumerator name
- // with the "e_" prefix excluded. Otherwise in case of invalid 'str'
- // return false and populate the specified 'stream' with error message.
-};
-
-// FREE OPERATORS
-bsl::ostream& operator<<(bsl::ostream& stream,
- CompressionAlgorithmType::Enum value);
- // Format the specified 'value' to the specified output 'stream' and return
- // a reference to the modifiable 'stream'.
-
-} // close package namespace
-
-// ============================================================================
-// INLINE DEFINITIONS
-// ============================================================================
-
- // ===============================
- // struct CompressionAlgorithmType
- // ===============================
-
-// FREE OPERATORS
-inline
-bsl::ostream&
-bmqt::operator<<(bsl::ostream& stream,
- bmqt::CompressionAlgorithmType::Enum value)
-{
- return bmqt::CompressionAlgorithmType::print(stream, value, 0, -1);
-}
-
-} // close enterprise namespace
-
-#endif
-
-Generated on Thu Jun 15 2023 11:58:50 by
-
- 1.7.1
-
-
diff --git a/docs/docs/apidocs/cpp_apidocs/bmqt__correlationid_8h_source.html b/docs/docs/apidocs/cpp_apidocs/bmqt__correlationid_8h_source.html
deleted file mode 100644
index afc6b12d9..000000000
--- a/docs/docs/apidocs/cpp_apidocs/bmqt__correlationid_8h_source.html
+++ /dev/null
@@ -1,642 +0,0 @@
-
-
-Bloomberg Development Environment
-
-
-// Copyright 2014-2023 Bloomberg Finance L.P.
-// SPDX-License-Identifier: Apache-2.0
-//
-// Licensed under the Apache License, Version 2.0 (the "License");
-// you may not use this file except in compliance with the License.
-// You may obtain a copy of the License at
-//
-// http://www.apache.org/licenses/LICENSE-2.0
-//
-// Unless required by applicable law or agreed to in writing, software
-// distributed under the License is distributed on an "AS IS" BASIS,
-// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-// See the License for the specific language governing permissions and
-// limitations under the License.
-
-// bmqt_correlationid.h -*-C++-*-
-#ifndef INCLUDED_BMQT_CORRELATIONID
-#define INCLUDED_BMQT_CORRELATIONID
-
-//@PURPOSE: Provide a value-semantic type usable as an efficient identifier.
-//
-//@CLASSES:
-// bmqt::CorrelationId: correlation ID class.
-// bmqt::CorrelationIdLess: comparison functor for 'CorrelationId' as map key
-// bsl::hash: hash functor specialization
-//
-//@DESCRIPTION: This component implements a value-semantic class,
-// 'bmqt::CorrelationId', which can be used to identify any async operations.
-// The correlationId contains a value (64-bit integer, raw pointer or
-// sharedPtr) supplied by the application or uses an auto-assigned value. The
-// type and the value of the correlationId can be set at construction time and
-// changed later via the 'setNumeric()', 'setPointer()' and 'setSharedPointer'
-// methods. Alternatively, a 'CorrelationId::AutoValue' can be used to
-// generate a unique correlationId from within the process. The
-// 'bmqt::CorrelationIdLess' comparison functor can be used for storing
-// 'CorrelationId' in a map as the key element; and a hash functor
-// specialization is provided in the 'bsl::hash' namespace.
-//
-///AutoValue
-///---------
-// If the application doesn't care about the actual value of the correlation,
-// AutoValue type can be used to create a unique correlationId. An AutoValue
-// correlationId behaves exactly the same as any other type of correlation,
-// with the exception that it's value can not be retrieved (but two
-// correlationId can be still compared equal).
-//..
-// bmqt::CorrelationId corrId = bmqt::CorrelationId::autoValue();
-//..
-//
-///Usage
-///-----
-// This section illustrates intended use of this component.
-//
-///Example 1: Correlating Responses
-/// - - - - - - - - - - - - - - - -
-// Suppose that we have the following asynchronous messaging interface that we
-// want to use to implement a basic request/response class.
-//..
-// class Messenger {
-//
-// public:
-// // TYPES
-// typedef bsl::function<
-// void(void *buffer,
-// int bufferLength,
-// const bmqt::CorrelationId& correlationId)> MessageHandler;
-// // 'MessageHandler' is an alias for a functor that handles received
-// // messages consisting of the specified 'buffer', having the
-// // specified 'bufferLength', as well as the specified associated
-// // 'correlationId' if the message is in response to a previously
-// // transmitted message.
-//
-// // MANIPULATORS
-// void sendMessage(void *buffer,
-// int bufferLength,
-// const bmqt::CorrelationId& correlationId);
-// // Send a message containing the specified 'buffer' of the
-// // specified 'bufferLength', associating the specified
-// // 'correlationId' with any messages later received in response.
-//
-// void setMessageHandler(const MessageHandler& handler);
-// // Set the functor to handle messages received by this object to
-// // the specified 'handler'.
-// };
-//..
-// First we declare a requester class.
-//..
-// class Requester {
-//
-// // DATA
-// Messenger *d_messenger_p; // used to send messages (held)
-// bslma::Allocator *d_allocator_p; // memory supply (held)
-//
-// // PRIVATE CLASS METHODS
-// static void handleMessage(void *buffer,
-// int bufferLength,
-// const bmqt::CorrelationId& correlationId);
-// // Handle the response message consisting fo the specified 'buffer'
-// // having the specified 'bufferLength', and associated
-// // 'correlationId'.
-//
-// public:
-// // TYPES
-// typedef bsl::function<void(void *buffer, int bufferLength)>
-// ResponseCallback;
-// // 'ResponseCallback' is an alias for a functor that is used to
-// // process received responses consisting of the specified 'buffer'
-// // having the specified 'bufferLength'.
-//
-// // CREATORS
-// explicit Requester(Messenger *messenger,
-// bslma::Allocator *basicAllocator);
-// // Create a 'Requester' that uses the specified 'messenger' to send
-// // requests and receive responses, and the specified
-// // 'basicAllocator' to supply memory.
-//
-// // MANIPULATORS
-// void sendRequest(void *buffer,
-// int bufferLength,
-// const ResponseCallback& callback);
-// // Send a request consisting of the specified 'buffer' having the
-// // specified 'bufferLength', and invoke the specified 'callback'
-// // with any asynchronous response.
-// };
-//..
-// Then, we implement the constructor, setting the message handler on the
-// provided 'Messenger' to our class method.
-//..
-// Requester::Requester(Messenger *messenger,
-// bslma::Allocator *basicAllocator)
-// : d_messenger_p(messenger)
-// , d_allocator_p(basicAllocator)
-// {
-// d_messenger_p->setMessageHandler(&Requester::handleMessage);
-// }
-//..
-// Now, we implement 'sendRequest', copying the given 'callback' into a
-// correlationId that is provided to the messenger.
-//..
-// void Requester::sendRequest(void *buffer,
-// int bufferLength,
-// const ResponseCallback& callback)
-// {
-// bsl::shared_ptr<ResponseCallback> callbackCopy;
-// callbackCopy.createInplace(d_allocator_p, callback, d_allocator_p);
-// bmqt::CorrelationId correlationId(bsl::shared_ptr<void>(callbackCopy));
-// d_messenger_p->sendMessage(buffer, bufferLength, correlationId);
-// }
-//..
-// Finally, we implement our message handler, extracting the response callback
-// from the correlationId, and invoking it with the received response message.
-//..
-// void Requester::handleMessage(void *buffer,
-// int bufferLength,
-// const bmqt::CorrelationId& correlationId)
-// {
-// assert(correlationId.isSharedPtr());
-// ResponseCallback *callback = static_cast<ResponseCallback *>(
-// correlationId.theSharedPtr().get());
-// (*callback)(buffer, bufferLength);
-// }
-//..
-//
-
-
-// BMQ
-#include <bmqscm_version.h>
-
-// BDE
-#include <bdlb_variant.h>
-
-#include <bsl_cstdint.h>
-#include <bsl_iosfwd.h>
-#include <bsl_memory.h>
-#include <bsls_assert.h>
-#include <bsls_types.h>
-#include <bslh_hash.h>
-
-namespace BloombergLP {
-namespace bmqt {
-
-
- // ===================
- // class CorrelationId
- // ===================
-
-class CorrelationId {
- // This class implements an in-core value-semantic type for correlating an
- // asynchronous result with the original operation.
-
- // FRIENDS
- // Needed to access getAsAutoValue
- friend bool operator==(const CorrelationId& lhs, const CorrelationId& rhs);
- friend bool operator!=(const CorrelationId& lhs, const CorrelationId& rhs);
- friend struct CorrelationIdLess;
- friend bsl::ostream& operator<<(bsl::ostream& stream,
- const CorrelationId& rhs);
-
- template <class HASH_ALGORITHM>
- friend
- void hashAppend(HASH_ALGORITHM& hashAlgo, const CorrelationId& value);
-
- private:
- // PRIVATE TYPES
- typedef bsls::Types::Uint64 AutoValue;
- // 'AutoValue' is an alias for a 64-bit unsigned integer value that is
- // used to generate automatic, opaque, correlationId values.
-
- // DATA
- bdlb::Variant4<bsls::Types::Int64,
- void*,
- bsl::shared_ptr<void>,
- AutoValue> d_variant;
- // The variant used to hold the value of a
- // 'CorrelationId', that may either be unset,
- // hold a 64-bit integer, a raw pointer, a
- // shared pointer, or an 'AutoValue'.
-
- // PRIVATE ACCESSORS
- AutoValue theAutoValue() const;
- // Return the value of this correlationId as an 'AutoValue'. The
- // behavior is undefined unless 'isAutoValue'. Note that this method
- // is only available in order to implement the comparison and hash
- // operations.
-
- public:
- // TYPES
- enum Type {
- e_NUMERIC // the 'CorrelationId' holds a 64-bit integer
- , e_POINTER // the 'CorrelationId' holds a raw pointer
- , e_SHARED_PTR // the 'CorrelationId' holds a shared pointer
- , e_AUTO_VALUE // the 'CorrelationId' holds an auto value
- , e_UNSET // the 'CorrelationId' is not set
- };
-
- // CLASS METHOD
- static CorrelationId autoValue();
- // Return a 'CorrelationId' having a unique, automatically assigned
- // opaque value.
-
- // CREATORS
- explicit CorrelationId();
- // Create a 'CorrelationId' having the default, unset, value.
-
- explicit CorrelationId(bsls::Types::Int64 numeric);
- // Create a 'CorrelationId' object initialized with the specified
- // 'numeric' integer value.
-
- explicit CorrelationId(void *pointer);
- // Create a 'CorrelationId' object initialized with the specified
- // 'pointer' value.
-
- explicit CorrelationId(const bsl::shared_ptr<void>& sharedPtr);
- // Create a 'CorrelationId' object initialized with the specified
- // 'sharedPtr' shared pointer value.
-
- // MANIPULATORS
- CorrelationId& makeUnset();
- // Unset the value of this object.
-
- CorrelationId& setNumeric(bsls::Types::Int64 numeric);
- // Set the value of this object value to the specified 'numeric'.
- // Return a reference to this object.
-
- CorrelationId& setPointer(void* pointer);
- // Set the value of this object value to the specified 'pointer'.
- // Return a reference to this object.
-
- CorrelationId& setSharedPointer(const bsl::shared_ptr<void>& sharedPtr);
- // Set the value of this object value to the specified 'sharedPtr'.
- // Return a reference to this object.
-
- // void setAutoValue
- // There is explicitly no setAuto, autoCorrelation should only be used
- // at creation
-
- // ACCESSORS
- bool isUnset() const;
- // Return 'true' if the value of this object is unset;
-
- bool isNumeric() const;
- // Return 'true' if the value of this object is an integer value, and
- // otherwise return 'false'.
-
- bool isPointer() const;
- // Return 'true' if the value of this object is a pointer value, and
- // otherwise return 'false'.
-
- bool isSharedPtr() const;
- // Return 'true' if the value of this object is a shared pointer value,
- // and otherwise return 'false'.
-
- bool isAutoValue() const;
- // Return 'true' if the value of this object is an auto correlation
- // value, and otherwise return 'false'.
-
- bsls::Types::Int64 theNumeric() const;
- // Return the 64-bit integer value of this object. The behavior is
- // undefined unless method 'isNumeric' returns 'true'.
-
- void* thePointer() const;
- // Return the pointer value of this object. The behavior is undefined
- // unless method 'isPointer' returns 'true'.
-
- const bsl::shared_ptr<void>& theSharedPtr() const;
- // Return the pointer value of this object. The behavior is undefined
- // unless method 'isSharedPtr' returns 'true'.
-
- Type type() const;
- // Return the type of the value of this object.
-
- bsl::ostream& print(bsl::ostream& stream,
- int level = 0,
- int spacesPerLevel = 4) const;
- // Format this object to the specified output 'stream' at the (absolute
- // value of) the optionally specified indentation 'level' and return a
- // reference to 'stream'. If 'level' is specified, optionally specify
- // 'spacesPerLevel', the number of spaces per indentation level for
- // this and all of its nested objects. If 'level' is negative,
- // suppress indentation of the first line. If 'spacesPerLevel' is
- // negative format the entire output on one line, suppressing all but
- // the initial indentation (as governed by 'level'). If 'stream' is
- // not valid on entry, this operation has no effect.
-};
-
-// FREE OPERATORS
-
- // -------------------
- // class CorrelationId
- // -------------------
-
-bsl::ostream& operator<<(bsl::ostream& stream, const CorrelationId& rhs);
- // Format the specified 'rhs' to the specified output 'stream' and return
- // a reference to the modifiable 'stream'.
-
-bool operator==(const CorrelationId& lhs, const CorrelationId& rhs);
- // Return 'true' if 'rhs' object contains the value of the same type as
- // contained in 'lhs' object and the value itself is the same in both
- // objects, return false otherwise.
-
-bool operator!=(const CorrelationId& lhs, const CorrelationId& rhs);
- // Return 'false' if 'rhs' object contains the value of the same type as
- // contained in 'lhs' object and the value itself is the same in both
- // objects, return 'true' otherwise.
-
-bool operator<(const CorrelationId& lhs, const CorrelationId& rhs);
- // Operator used to allow comparison between the specified 'lhs' and 'rhs'
- // CorrelationId objects so that CorrelationId can be used as key in a map.
-
-
- // =======================
- // class CorrelationIdLess
- // =======================
-
-struct CorrelationIdLess
-{
- // ACCESSORS
- bool operator()(const CorrelationId& lhs, const CorrelationId& rhs) const;
- // Return 'true' if the specified 'lhs' should be considered as having
- // a value less than the specified 'rhs'.
-};
-
-
-// ============================================================================
-// INLINE DEFINITIONS
-// ============================================================================
-
-
- // -------------------
- // class CorrelationId
- // -------------------
-
-inline
-CorrelationId::AutoValue
-CorrelationId::theAutoValue() const
-{
- // PRECONDITIONS
- BSLS_ASSERT(isAutoValue());
-
- return d_variant.the<AutoValue>();
-}
-
-// CREATORS
-inline
-CorrelationId::CorrelationId()
-: d_variant()
-{
- // NOTHING
-}
-
-inline
-CorrelationId::CorrelationId(bsls::Types::Int64 numeric)
-: d_variant(numeric)
-{
- // NOTHING
-}
-
-inline
-CorrelationId::CorrelationId(void *pointer)
-: d_variant(pointer)
-{
- // NOTHING
-}
-
-inline
-CorrelationId::CorrelationId(const bsl::shared_ptr<void>& sharedPtr)
-: d_variant(sharedPtr)
-{
- // NOTHING
-}
-
-// MANIPULATORS
-inline
-CorrelationId&
-CorrelationId::makeUnset()
-{
- d_variant.reset();
- return *this;
-}
-
-inline
-CorrelationId&
-CorrelationId::setNumeric(bsls::Types::Int64 numeric)
-{
- d_variant.assign(numeric);
- return *this;
-}
-
-inline
-CorrelationId&
-CorrelationId::setPointer(void* pointer)
-{
- d_variant.assign(pointer);
- return *this;
-}
-
-inline
-CorrelationId&
-CorrelationId::setSharedPointer(const bsl::shared_ptr<void>& sharedPtr)
-{
- d_variant.assign(sharedPtr);
- return *this;
-}
-
-// ACCESSORS
-inline
-bool
-CorrelationId::isUnset() const
-{
- return d_variant.isUnset();
-}
-
-inline
-bool
-CorrelationId::isNumeric() const
-{
- return d_variant.is<bsls::Types::Int64>();
-}
-
-inline
-bool
-CorrelationId::isPointer() const
-{
- return d_variant.is<void*>();
-}
-
-inline
-bool
-CorrelationId::isSharedPtr() const
-{
- return d_variant.is<bsl::shared_ptr<void> >();
-}
-
-inline
-bool
-CorrelationId::isAutoValue() const
-{
- return d_variant.is<AutoValue>();
-}
-
-inline
-bsls::Types::Int64
-CorrelationId::theNumeric() const
-{
- // PRECONDITIONS
- BSLS_ASSERT(isNumeric());
-
- return d_variant.the<bsls::Types::Int64>();
-}
-
-inline
-void*
-CorrelationId::thePointer() const
-{
- // PRECONDITIONS
- BSLS_ASSERT(isPointer());
-
- return d_variant.the<void*>();
-}
-
-inline
-const bsl::shared_ptr<void>&
-CorrelationId::theSharedPtr() const
-{
- // PRECONDITIONS
- BSLS_ASSERT(isSharedPtr());
-
- return d_variant.the<bsl::shared_ptr<void> >();
-}
-
-inline
-CorrelationId::Type
-CorrelationId::type() const
-{
- int result = isUnset() ? e_UNSET
- : isNumeric() ? e_NUMERIC
- : isPointer() ? e_POINTER
- : isSharedPtr() ? e_SHARED_PTR
- : isAutoValue() ? e_AUTO_VALUE
- : -1;
- BSLS_ASSERT_OPT(-1 != result && "Unknown correlation type");
-
- return static_cast<Type>(result);
-}
-
-// FREE FUNCTIONS
-template <class HASH_ALGORITHM>
-void
-hashAppend(HASH_ALGORITHM& hashAlgo,
- const CorrelationId& value)
-{
- using bslh::hashAppend; // for ADL
-
- CorrelationId::Type type = value.type();
- hashAppend(hashAlgo, static_cast<int>(type));
-
- switch (type) {
- case CorrelationId::e_NUMERIC: {
- hashAppend(hashAlgo, value.theNumeric());
- } break;
- case CorrelationId::e_POINTER: {
- hashAppend(hashAlgo, value.thePointer());
- } break;
- case CorrelationId::e_SHARED_PTR: {
- hashAppend(hashAlgo, value.theSharedPtr());
- } break;
- case CorrelationId::e_AUTO_VALUE: {
- hashAppend(hashAlgo, value.theAutoValue());
- } break;
- case CorrelationId::e_UNSET: {
- hashAppend(hashAlgo, 0);
- } break;
- default: {
- BSLS_ASSERT_OPT(false && "Unknown correlationId type");
- hashAppend(hashAlgo, 0);
- }
- }
-}
-
- // ------------------------
- // struct CorrelationIdLess
- // ------------------------
-
-inline
-bool
-CorrelationIdLess::operator()(const CorrelationId& lhs,
- const CorrelationId& rhs) const
-{
- // If 'lhs' and 'rhs' have different types, they are compared by their
- // corresponding type indices. Otherwise, they are compared by value.
-
- bool result;
- if (lhs.d_variant.typeIndex() != rhs.d_variant.typeIndex()) {
- result = lhs.d_variant.typeIndex() < rhs.d_variant.typeIndex();
- } else if (lhs.isNumeric()) {
- result = lhs.theNumeric() < rhs.theNumeric();
- } else if (lhs.isPointer()) {
- result = reinterpret_cast<bsl::uintptr_t>(lhs.thePointer()) <
- reinterpret_cast<bsl::uintptr_t>(rhs.thePointer());
- } else if (lhs.isSharedPtr()) {
- result = lhs.theSharedPtr() < rhs.theSharedPtr();
- } else if (lhs.isAutoValue()) {
- result = lhs.theAutoValue() < rhs.theAutoValue();
- } else {
- BSLS_ASSERT_OPT(false && "Unknown correlator type");
- result = false;
- }
-
- return result;
-}
-
-} // close package namespace
-
- // -------------------
- // class CorrelationId
- // -------------------
-
-// FREE OPERATORS
-inline
-bool
-bmqt::operator==(const bmqt::CorrelationId& lhs,
- const bmqt::CorrelationId& rhs)
-{
- return lhs.d_variant == rhs.d_variant;
-}
-
-inline
-bool
-bmqt::operator!=(const bmqt::CorrelationId& lhs,
- const bmqt::CorrelationId& rhs)
-{
- return lhs.d_variant != rhs.d_variant;
-}
-
-inline
-bool
-bmqt::operator<(const bmqt::CorrelationId& lhs,
- const bmqt::CorrelationId& rhs)
-{
- CorrelationIdLess less;
- return less(lhs, rhs);
-}
-
-inline
-bsl::ostream&
-bmqt::operator<<(bsl::ostream& stream,
- const bmqt::CorrelationId& rhs)
-{
- return rhs.print(stream, 0, -1);
-}
-
-} // close enterprise namespace
-
-#endif
-
-Generated on Thu Jun 15 2023 11:58:50 by
-
- 1.7.1
-
-
diff --git a/docs/docs/apidocs/cpp_apidocs/bmqt__encodingtype_8h_source.html b/docs/docs/apidocs/cpp_apidocs/bmqt__encodingtype_8h_source.html
deleted file mode 100644
index 9e019100a..000000000
--- a/docs/docs/apidocs/cpp_apidocs/bmqt__encodingtype_8h_source.html
+++ /dev/null
@@ -1,157 +0,0 @@
-
-
-Bloomberg Development Environment
-
-
-// Copyright 2014-2023 Bloomberg Finance L.P.
-// SPDX-License-Identifier: Apache-2.0
-//
-// Licensed under the Apache License, Version 2.0 (the "License");
-// you may not use this file except in compliance with the License.
-// You may obtain a copy of the License at
-//
-// http://www.apache.org/licenses/LICENSE-2.0
-//
-// Unless required by applicable law or agreed to in writing, software
-// distributed under the License is distributed on an "AS IS" BASIS,
-// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-// See the License for the specific language governing permissions and
-// limitations under the License.
-
-// bmqt_encodingtype.h -*-C++-*-
-#ifndef INCLUDED_BMQT_ENCODINGTYPE
-#define INCLUDED_BMQT_ENCODINGTYPE
-
-//@PURPOSE: Provide an enumeration for different message encoding types.
-//
-//@CLASSES:
-// bmqt::EncodingType: Enumeration for different message encoding types.
-//
-//@DESCRIPTION: Provide an enumeration, 'bmqt::EncodingType' for different
-// message encoding types.
-//
-//: o !UNDEFINED!: No encoding was specified
-//: o !RAW!: The encoding is RAW, i.e., binary
-//: o !BER!: Binary encoding using the BER codec
-//: o !BDEX!: Binary encoding using the BDEX codec
-//: o !XML!: Text encoding, using the XML format
-//: o !JSON!: Text encoding, using the JSON format
-//: o !TEXT!: Plain text encoding, using a custom user-specific format
-//: o !MULTIPARTS!: Message is part of a multipart message
-
-
-// BMQ
-#include <bmqscm_version.h>
-
-// BDE
-#include <bsl_iosfwd.h>
-#include <bsl_string.h>
-
-
-namespace BloombergLP {
-namespace bmqt {
-
- // ===================
- // struct EncodingType
- // ===================
-
-struct EncodingType {
- // Enumeration for message encoding types.
-
- // TYPES
- enum Enum {
- e_UNDEFINED = 0
- , e_RAW = 1
- , e_BER = 2
- , e_BDEX = 3
- , e_XML = 4
- , e_JSON = 5
- , e_TEXT = 6
- , e_MULTIPARTS = 7
- };
-
- // PUBLIC CONSTANTS
- static const int k_LOWEST_SUPPORTED_ENCODING_TYPE = e_RAW;
- // NOTE: This value must always be equal to the lowest type in the
- // enum because it is being used as a lower bound to verify that an
- // EncodingType field is a supported type.
-
- static const int k_HIGHEST_SUPPORTED_ENCODING_TYPE = e_MULTIPARTS;
- // NOTE: This value must always be equal to the highest type in the
- // enum because it is being used as an upper bound to verify an
- // EncodingType field is a supported type.
-
- // CLASS METHODS
- static bsl::ostream& print(bsl::ostream& stream,
- EncodingType::Enum value,
- int level = 0,
- int spacesPerLevel = 4);
- // Write the string representation of the specified enumeration 'value'
- // to the specified output 'stream', and return a reference to
- // 'stream'. Optionally specify an initial indentation 'level', whose
- // absolute value is incremented recursively for nested objects. If
- // 'level' is specified, optionally specify 'spacesPerLevel', whose
- // absolute value indicates the number of spaces per indentation level
- // for this and all of its nested objects. If 'level' is negative,
- // suppress indentation of the first line. If 'spacesPerLevel' is
- // negative, format the entire output on one line, suppressing all but
- // the initial indentation (as governed by 'level'). See 'toAscii' for
- // what constitutes the string representation of a
- // 'EncodingType::Value' value.
-
- static const char *toAscii(EncodingType::Enum value);
- // Return the non-modifiable string representation corresponding to the
- // specified enumeration 'value', if it exists, and a unique (error)
- // string otherwise. The string representation of 'value' matches its
- // corresponding enumerator name with the 'BMQT_' prefix elided. Note
- // that specifying a 'value' that does not match any of the enumerators
- // will result in a string representation that is distinct from any of
- // those corresponding to the enumerators, but is otherwise
- // unspecified.
-
- static bool fromAscii(EncodingType::Enum *out,
- const bslstl::StringRef& str);
- // Return true and fills the specified 'out' with the enum value
- // corresponding to the specified 'str', if valid, or return false and
- // leave 'out' untouched if 'str' doesn't correspond to any value of
- // the enum.
-
- static bool isValid(const bsl::string *string, bsl::ostream& stream);
- // Return true if the specified 'string' is a valid representation of
- // the 'EncodingType', otherwise return false and print a description
- // of the error to the specified 'stream'.
-};
-
-// FREE OPERATORS
-bsl::ostream& operator<<(bsl::ostream& stream,
- EncodingType::Enum value);
- // Format the specified 'value' to the specified output 'stream' and return
- // a reference to the modifiable 'stream'.
-
-} // close package namespace
-
-
-// ============================================================================
-// INLINE DEFINITIONS
-// ============================================================================
-
-
- // -------------------
- // struct EncodingType
- // -------------------
-
-// FREE OPERATORS
-inline
-bsl::ostream&
-bmqt::operator<<(bsl::ostream& stream,
- bmqt::EncodingType::Enum value)
-{
- return EncodingType::print(stream, value, 0 , -1);
-}
-
-} // close enterprise namespace
-
-#endif
-
-Generated on Thu Jun 15 2023 11:58:51 by
-
- 1.7.1
-
-
diff --git a/docs/docs/apidocs/cpp_apidocs/bmqt__hosthealthstate_8h_source.html b/docs/docs/apidocs/cpp_apidocs/bmqt__hosthealthstate_8h_source.html
deleted file mode 100644
index 409807cbe..000000000
--- a/docs/docs/apidocs/cpp_apidocs/bmqt__hosthealthstate_8h_source.html
+++ /dev/null
@@ -1,130 +0,0 @@
-
-
-Bloomberg Development Environment
-
-
-// Copyright 2021-2023 Bloomberg Finance L.P.
-// SPDX-License-Identifier: Apache-2.0
-//
-// Licensed under the Apache License, Version 2.0 (the "License");
-// you may not use this file except in compliance with the License.
-// You may obtain a copy of the License at
-//
-// http://www.apache.org/licenses/LICENSE-2.0
-//
-// Unless required by applicable law or agreed to in writing, software
-// distributed under the License is distributed on an "AS IS" BASIS,
-// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-// See the License for the specific language governing permissions and
-// limitations under the License.
-
-// bmqt_hosthealthstate.h -*-C++-*-
-#ifndef INCLUDED_BMQT_HOSTHEALTHSTATE
-#define INCLUDED_BMQT_HOSTHEALTHSTATE
-
-//@PURPOSE: Provide an enumeration for different host health states.
-//
-//@CLASSES:
-// bmqt::HostHealthState: Enumeration for different host health states.
-//
-//@DESCRIPTION: Provide an enumeration, 'bmqt::HostHealthState' for different
-// representations of the health of a host.
-//
-//: o !UNKNOWN!: Host health could not be ascertained
-//: o !HEALTHY!: Host is considered to be healthy
-//: o !UNHEALTHY!: Host is not considered to be healthy
-
-// BMQ
-#include <bmqscm_version.h>
-
-// BDE
-#include <bsl_iosfwd.h>
-#include <bsl_string.h>
-
-
-namespace BloombergLP {
-namespace bmqt {
-
- // ======================
- // struct HostHealthState
- // ======================
-
-struct HostHealthState {
- // Enumeration for host health states.
-
- // TYPES
- enum Enum {
- e_UNKNOWN = 0
- , e_HEALTHY = 1
- , e_UNHEALTHY = 2
- };
-
- // CLASS METHODS
- static bsl::ostream& print(bsl::ostream& stream,
- HostHealthState::Enum value,
- int level = 0,
- int spacesPerLevel = 4);
- // Write the string representation of the specified enumeration 'value'
- // to the specified output 'stream', and return a reference to
- // 'stream'. Optionally specify an initial indentation 'level', whose
- // absolute value is incremented recursively for nested objects. If
- // 'level' is specified, optionally specify 'spacesPerLevel', whose
- // absolute value indicates the number of spaces per indentation level
- // for this and all of its nested objects. If 'level' is negative,
- // suppress indentation of the first line. If 'spacesPerLevel' is
- // negative, format the entire output on one line, suppressing all but
- // the initial indentation (as governed by 'level'). See 'toAscii' for
- // what constitutes the string representation of a
- // 'HostHealthState::Value' value.
-
- static const char *toAscii(HostHealthState::Enum value);
- // Return the non-modifiable string representation corresponding to the
- // specified enumeration 'value', if it exists, and a unique (error)
- // string otherwise. The string representation of 'value' matches its
- // corresponding enumerator name with the 'BMQT_' prefix elided. Note
- // that specifying a 'value' that does not match any of the enumerators
- // will result in a string representation that is distinct from any of
- // those corresponding to the enumerators, but is otherwise
- // unspecified.
-
- static bool fromAscii(HostHealthState::Enum *out,
- const bslstl::StringRef& str);
- // Return true and fills the specified 'out' with the enum value
- // corresponding to the specified 'str', if valid, or return false and
- // leave 'out' untouched if 'str' doesn't correspond to any value of
- // the enum.
-};
-
-// FREE OPERATORS
-bsl::ostream& operator<<(bsl::ostream& stream,
- HostHealthState::Enum value);
- // Format the specified 'value' to the specified output 'stream' and return
- // a reference to the modifiable 'stream'.
-
-} // close package namespace
-
-
-// ============================================================================
-// INLINE DEFINITIONS
-// ============================================================================
-
-
- // ----------------------
- // struct HostHealthState
- // ----------------------
-
-// FREE OPERATORS
-inline
-bsl::ostream&
-bmqt::operator<<(bsl::ostream& stream,
- bmqt::HostHealthState::Enum value)
-{
- return HostHealthState::print(stream, value, 0 , -1);
-}
-
-} // close enterprise namespace
-
-#endif
-
-Generated on Thu Jun 15 2023 11:58:51 by
-
- 1.7.1
-
-
diff --git a/docs/docs/apidocs/cpp_apidocs/bmqt__messageeventtype_8h_source.html b/docs/docs/apidocs/cpp_apidocs/bmqt__messageeventtype_8h_source.html
deleted file mode 100644
index 1f4b1374b..000000000
--- a/docs/docs/apidocs/cpp_apidocs/bmqt__messageeventtype_8h_source.html
+++ /dev/null
@@ -1,146 +0,0 @@
-
-
-Bloomberg Development Environment
-
-
-// Copyright 2014-2023 Bloomberg Finance L.P.
-// SPDX-License-Identifier: Apache-2.0
-//
-// Licensed under the Apache License, Version 2.0 (the "License");
-// you may not use this file except in compliance with the License.
-// You may obtain a copy of the License at
-//
-// http://www.apache.org/licenses/LICENSE-2.0
-//
-// Unless required by applicable law or agreed to in writing, software
-// distributed under the License is distributed on an "AS IS" BASIS,
-// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-// See the License for the specific language governing permissions and
-// limitations under the License.
-
-// bmqt_messageeventtype.h -*-C++-*-
-#ifndef INCLUDED_BMQT_MESSAGEEVENTTYPE
-#define INCLUDED_BMQT_MESSAGEEVENTTYPE
-
-//@PURPOSE: Provide an enumeration for the different types of message events.
-//
-//@CLASSES:
-// bmqt::MessageEventType: Enumeration for the types of message events.
-//
-//@DESCRIPTION: Provide an enumeration, 'bmqt::MessageEventType', for the
-// different types of message events.
-//
-//: o !UNDEFINED!: Unknown message type
-//: o !ACK!: Message is an ack
-//: o !PUSH!: Message is a push
-//: o !PUT!: Message is a put
-//
-
-
-// BMQ
-#include <bmqscm_version.h>
-
-// BDE
-#include <bsl_iosfwd.h>
-#include <bsl_string.h>
-
-
-namespace BloombergLP {
-namespace bmqt {
-
- // =======================
- // struct MessageEventType
- // =======================
-
-struct MessageEventType {
- // Enumeration for the types of message events
-
- // TYPES
- enum Enum {
- e_UNDEFINED = 0
- , e_PUT = 1
- , e_PUSH = 2
- , e_ACK = 3
- };
-
- // PUBLIC CONSTANTS
- static const int k_LOWEST_SUPPORTED_EVENT_TYPE = e_PUT;
- // NOTE: This value must always be equal to the lowest type in the
- // enum because it is being used as a lower bound to verify that an
- // MessageEventType field is a supported type.
-
- static const int k_HIGHEST_SUPPORTED_EVENT_TYPE = e_ACK;
- // NOTE: This value must always be equal to the highest type in the
- // enum because it is being used as an upper bound to verify an
- // MessageEventType field is a supported type.
-
- // CLASS METHODS
- static bsl::ostream& print(bsl::ostream& stream,
- MessageEventType::Enum value,
- int level = 0,
- int spacesPerLevel = 4);
- // Write the string representation of the specified enumeration 'value'
- // to the specified output 'stream', and return a reference to
- // 'stream'. Optionally specify an initial indentation 'level', whose
- // absolute value is incremented recursively for nested objects. If
- // 'level' is specified, optionally specify 'spacesPerLevel', whose
- // absolute value indicates the number of spaces per indentation level
- // for this and all of its nested objects. If 'level' is negative,
- // suppress indentation of the first line. If 'spacesPerLevel' is
- // negative, format the entire output on one line, suppressing all but
- // the initial indentation (as governed by 'level'). See 'toAscii' for
- // what constitutes the string representation of a
- // 'MessageEventType::Value' value.
-
- static const char *toAscii(MessageEventType::Enum value);
- // Return the non-modifiable string representation corresponding to the
- // specified enumeration 'value', if it exists, and a unique (error)
- // string otherwise. The string representation of 'value' matches its
- // corresponding enumerator name with the 'BMQT_' prefix elided. Note
- // that specifying a 'value' that does not match any of the enumerators
- // will result in a string representation that is distinct from any of
- // those corresponding to the enumerators, but is otherwise
- // unspecified.
-
- static bool fromAscii(MessageEventType::Enum *out,
- const bslstl::StringRef& str);
- // Return true and fills the specified 'out' with the enum value
- // corresponding to the specified 'str', if valid, or return false and
- // leave 'out' untouched if 'str' doesn't correspond to any value of
- // the enum.
-
-};
-
-// FREE OPERATORS
-bsl::ostream& operator<<(bsl::ostream& stream,
- MessageEventType::Enum value);
- // Format the specified 'value' to the specified output 'stream' and return
- // a reference to the modifiable 'stream'.
-
-} // close package namespace
-
-
-// ============================================================================
-// INLINE DEFINITIONS
-// ============================================================================
-
-
- // -----------------------
- // struct MessageEventType
- // -----------------------
-
-// FREE OPERATORS
-inline
-bsl::ostream&
-bmqt::operator<<(bsl::ostream& stream,
- bmqt::MessageEventType::Enum value)
-{
- return MessageEventType::print(stream, value, 0 , -1);
-}
-
-} // close enterprise namespace
-
-#endif
-
-Generated on Thu Jun 15 2023 11:58:51 by
-
- 1.7.1
-
-
diff --git a/docs/docs/apidocs/cpp_apidocs/bmqt__messageguid_8h_source.html b/docs/docs/apidocs/cpp_apidocs/bmqt__messageguid_8h_source.html
deleted file mode 100644
index a6f0edaf8..000000000
--- a/docs/docs/apidocs/cpp_apidocs/bmqt__messageguid_8h_source.html
+++ /dev/null
@@ -1,463 +0,0 @@
-
-
-Bloomberg Development Environment
-
-
-// Copyright 2014-2023 Bloomberg Finance L.P.
-// SPDX-License-Identifier: Apache-2.0
-//
-// Licensed under the Apache License, Version 2.0 (the "License");
-// you may not use this file except in compliance with the License.
-// You may obtain a copy of the License at
-//
-// http://www.apache.org/licenses/LICENSE-2.0
-//
-// Unless required by applicable law or agreed to in writing, software
-// distributed under the License is distributed on an "AS IS" BASIS,
-// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-// See the License for the specific language governing permissions and
-// limitations under the License.
-
-// bmqt_messageguid.h -*-C++-*-
-#ifndef INCLUDED_BMQT_MESSAGEGUID
-#define INCLUDED_BMQT_MESSAGEGUID
-
-//@PURPOSE: Provide a value-semantic global unique identifier for BlazingMQ
-//messages.
-//
-//@CLASSES:
-// bmqt::MessageGUID : Value-semantic global unique ID for BlazingMQ
-// message
-// bmqt::MessageGUIDLess : Binary function for comparing GUIDs.
-// bmqt::MessageGUIDHashAlgo : Provide a hashing algorithm for Message GUID.
-//
-//@DESCRIPTION: 'bmqt::MessageGUID' provides a value-semantic global unique
-// identifier for BlazingMQ messages. Each bmqa::Message delivered to
-// BlazingMQ client from BlazingMQ broker contains a unique MessageGUID. The
-// binary function 'bmqt::MessageGUIDLess' can be used for comparing GUIDs, and
-// an optimized custom hash function is provided with
-// 'bmqt::MessageGUIDHashAlgo'.
-//
-//
-///Externalization
-///---------------
-// For convenience, this class provides 'toHex' method that can be used to
-// externalize a 'bmqt::MessageGUID' instance. Applications can persist the
-// resultant buffer (on filesystem, in database) to keep track of last
-// processed message ID across task instantiations. 'fromHex' method can be
-// used to convert a valid externalized buffer back to a message ID.
-//
-///Efficient comparison and hash function
-///--------------------------------------
-// This component also provides efficient comparison and hash functions for
-// convenience, and thus, applications can use this component as a key in
-// associative containers.
-//
-//
-///Example 1: Externalizing
-/// - - - - - - - - - - - -
-//..
-// // Below, 'msg' is a valid instance of 'bmqa::Message' obtained from an
-// // instance of 'bmqa::Session':
-//
-// bmqt::MessageGUID g1 = msg.messageId();
-//
-// char buffer[bmqt::MessageGUID::e_SIZE_HEX];
-// g1.toHex(buffer);
-//
-// BSLS_ASSERT(true == bmqt::MessageGUID::isValidHexRepresentation(buffer));
-//
-// bmqt::MessageGUID g2;
-// g2.fromHex(buffer);
-//
-// BSLS_ASSERT(g1 == g2);
-//..
-//
-
-
-// BMQ
-#include <bmqscm_version.h>
-
-// BDE
-#include <bsl_cstring.h> // for bsl::memset, bsl::memcmp
-
-#include <bsl_cstddef.h>
-
-#include <bsl_iosfwd.h>
-#include <bslh_hash.h>
-#include <bslmf_isbitwiseequalitycomparable.h>
-#include <bslmf_istriviallycopyable.h>
-#include <bslmf_nestedtraitdeclaration.h>
-#include <bsls_annotation.h>
-#include <bsls_types.h>
-
-namespace BloombergLP {
-namespace bmqt {
-
-
- // =================
- // class MessageGUID
- // =================
-
-class MessageGUID {
- // This class provides a value-semantic type to represent a global unique
- // ID for BlazingMQ messages.
-
- // FRIENDS
- friend bool operator==(const MessageGUID& lhs, const MessageGUID& rhs);
- friend bool operator!=(const MessageGUID& lhs, const MessageGUID& rhs);
- friend struct MessageGUIDLess;
- template <class HASH_ALGORITHM>
- friend void hashAppend(HASH_ALGORITHM& hashAlgo, const MessageGUID& guid);
-
- public:
- // TYPES
- enum Enum {
- // Enum representing the size of a buffer needed to represent a GUID
- e_SIZE_BINARY = 16 // Binary format of the GUID
-
- , e_SIZE_HEX = 2 * e_SIZE_BINARY
- // Hexadecimal string representation of the GUID
- };
-
- // TRAITS
- BSLMF_NESTED_TRAIT_DECLARATION(MessageGUID,
- bslmf::IsBitwiseEqualityComparable)
- BSLMF_NESTED_TRAIT_DECLARATION(MessageGUID, bsl::is_trivially_copyable)
-
- private:
- // PRIVATE CONSTANTS
- static const char k_UNSET_GUID[e_SIZE_BINARY];
- // Constant representing an unset GUID
-
- private:
- // IMPLEMENTATION NOTE: Some structs in bmqp::Protocol.h blindly
- // reinterpret_cast a char[e_SIZE_BINARY] to a
- // MessageGUID (instead of using 'fromBinary()') so
- // that they can return a const MessageGUID&.
- // IMPLEMENTATION NOTE: See mqbu_messageguidutil.cpp for internal layout of
- // MessageGUID
-
- // DATA
- char d_buffer[e_SIZE_BINARY];
-
- public:
- // CLASS METHODS
- static bool isValidHexRepresentation(const char *buffer);
- // Return true if the specified 'buffer' is a valid hex representation
- // of a MessageGUID. The behavior is undefined unless 'buffer' is
- // non-null and length of the 'buffer' is equal to 'e_SIZE_HEX'.
-
- // CREATORS
- MessageGUID();
- // Create an un-initialized MessageGUID. Note that 'isUnset()' would
- // return true.
-
- ~MessageGUID();
- // Destructor.
-
- // MANIPULATORS
- MessageGUID& fromBinary(const unsigned char *buffer);
- // Initialize this MessageGUID with the binary representation from the
- // specified 'buffer', in binary format. Behavior is undefined unless
- // 'buffer' is non-null and of length 'e_SIZE_BINARY'. Return a
- // reference offering modifiable access to this object.
-
- MessageGUID& fromHex(const char* buffer);
- // Initialize this MessageGUID with the hexadecimal representation from
- // the specified 'buffer'. Behavior is undefined unless
- // 'isValidHexRepresentation()' returns true for the provided
- // 'buffer'. Return a reference offering modifiable access to this
- // object.
-
- // ACCESSORS
- bool isUnset() const;
- // Return 'true' if the value of this object is not set.
-
- void toBinary(unsigned char *destination) const;
- // Write the binary representation of this object to the specified
- // 'destination'. Behavior is undefined unless 'destination' is of
- // length 'e_SIZE_BINARY'. Note that 'destination' can later be used
- // to populate a MessageGUID object using 'fromBinary' method.
-
- void toHex(char *destination) const;
- // Write the hex representation of this object to the specified
- // 'destination'. Behavior is undefined unless 'destination' is of
- // length 'e_SIZE_HEX'. Note that 'destination' can later be used to
- // populate a MessageGUID object using 'fromHex' method.
-
- bsl::ostream& print(bsl::ostream& stream,
- int level = 0,
- int spacesPerLevel = 4) const;
- // Write the value of this object to the specified output 'stream' in a
- // human-readable format, and return a reference to 'stream'.
- // Optionally specify an initial indentation 'level'. If 'level' is
- // specified, optionally specify 'spacesPerLevel', whose absolute value
- // indicates the number of spaces per indentation level for this
- // object. If 'level' is negative, suppress indentation of the first
- // line. If 'spacesPerLevel' is negative, format the entire output on
- // one line, suppressing all but the initial indentation (as governed
- // by 'level'). If 'stream' is not valid on entry, this operation has
- // no effect. Note that this human-readable format is not fully
- // specified, and can change without notice. Applications relying on a
- // fixed length format must use 'toHex' method.
-};
-
-// FREE OPERATORS
-
- // -----------------
- // class MessageGUID
- // -----------------
-
-bsl::ostream& operator<<(bsl::ostream& stream, const MessageGUID& rhs);
- // Write the value of the specified 'rhs' object to the specified output
- // 'stream' in a human-readable format, and return a reference to 'stream'.
- // Note that this human-readable format is not fully specified, and can
- // change without notice. Applications relying on a fixed length format
- // must use 'toHex' method.
-
-bool operator==(const MessageGUID& lhs, const MessageGUID& rhs);
- // Return 'true' if 'rhs' object contains the value of the same type as
- // contained in 'lhs' object and the value itself is the same in both
- // objects, return false otherwise.
-
-bool operator!=(const MessageGUID& lhs, const MessageGUID& rhs);
- // Return 'false' if 'rhs' object contains the value of the same type as
- // contained in 'lhs' object and the value itself is the same in both
- // objects, return 'true' otherwise.
-
-bool operator<(const MessageGUID& lhs, const MessageGUID& rhs);
- // Return true if the specified 'lhs' instance is smaller than the
- // specified 'rhs' instance, false otherwise. Note that criteria for
- // comparison is implementation defined, and result of this routine *does*
- // *not* in any way signify the order of creation/arrival/delivery of
- // messages to which 'lhs' and 'rhs' instances belong. Note that this
- // operator is provided so that MessageGUID can be used as a key in
- // associative containers (map, set, etc).
-
-
- // =====================
- // class MessageGUIDLess
- // =====================
-
-struct MessageGUIDLess
-{
- // This struct provides a binary function for comparing 2 GUIDs.
-
- // ACCESSORS
- bool operator()(const MessageGUID& lhs, const MessageGUID& rhs) const;
- // Return 'true' if the specified 'lhs' should be considered as having
- // a value less than the specified 'rhs'.
-};
-
-
- // =========================
- // class MessageGUIDHashAlgo
- // =========================
-
-class MessageGUIDHashAlgo {
- // This class provides a hashing algorithm for 'bmqt::MessageGUID'. At the
- // time of writing, this algorithm was found to be approximately 4x faster
- // than the default hashing algorithm that comes with 'bslh' package.
- // Performance-critical applications may want to use this hashing algorithm
- // instead of the default one.
-
- private:
- // DATA
- bsls::Types::Uint64 d_result;
-
- public:
- // TYPES
- typedef bsls::Types::Uint64 result_type;
-
- // CREATORS
- MessageGUIDHashAlgo();
- // Constructor
-
- // MANIPULATORS
- void operator()(const void *data, size_t numBytes);
-
- result_type computeHash();
- // Compute and return the hash for the GUID.
-};
-
-
-// ============================================================================
-// INLINE DEFINITIONS
-// ============================================================================
-
-
- // -----------------
- // class MessageGUID
- // -----------------
-
-// CREATORS
-inline
-MessageGUID::MessageGUID()
-{
- bsl::memcpy(d_buffer, k_UNSET_GUID, e_SIZE_BINARY);
-}
-
-inline
-MessageGUID::~MessageGUID() {
-#ifdef BSLS_ASSERT_SAFE_IS_ACTIVE
- bsl::memcpy(d_buffer, k_UNSET_GUID, e_SIZE_BINARY);
-#endif
-}
-
-// ACCESSORS
-inline
-bool
-MessageGUID::isUnset() const
-{
- return 0 == bsl::memcmp(d_buffer, k_UNSET_GUID, e_SIZE_BINARY);
-}
-
-// FREE FUNCTIONS
-template <class HASH_ALGORITHM>
-void
-hashAppend(HASH_ALGORITHM& hashAlgo,
- const MessageGUID& guid)
-{
- using bslh::hashAppend; // for ADL
- hashAppend(hashAlgo, guid.d_buffer); // hashes entire buffer array
-}
-
-
- // ----------------------
- // struct MessageGUIDLess
- // ----------------------
-
-inline
-bool
-MessageGUIDLess::operator()(const MessageGUID& lhs,
- const MessageGUID& rhs) const
-{
- return 0 > bsl::memcmp(lhs.d_buffer,
- rhs.d_buffer,
- MessageGUID::e_SIZE_BINARY);
-}
-
-
- // -------------------------
- // class MessageGUIDHashAlgo
- // -------------------------
-
-// CREATORS
-inline
-MessageGUIDHashAlgo::MessageGUIDHashAlgo()
-: d_result(0)
-{
-}
-
-// MANIPULATORS
-inline
-void
-MessageGUIDHashAlgo::operator()(const void *data,
- BSLS_ANNOTATION_UNUSED size_t numBytes)
-{
- // Implementation note: we implement the 'djb2' hash algorithm (more
- // details at http://www.cse.yorku.ca/~oz/hash.html).
-
- // At the time of writing, this algorithm came out to be about 400% faster
- // than 'bslh::SpookyHashAlgorithm', which is the default hashing algorithm
- // in 'bslh' hashing framework. Note that while
- // 'bslh::SpookyHashAlgorithm' is slower, it may have a better uniform
- // distribution than this algorithm (although some literature claims djb2
- // to have a very good distribution as well). Both algorithms were found
- // to be collision free in testing (see mqbu_messageguidtutil.t).
-
- // We have slightly modified the djb2 algorithm by unrolling djb2 'while'
- // loop, by using our knowledge that 'numBytes' is always 16 for
- // 'bmqt::MessageGUID'. For reference, the unmodified djb2 algorithm has
- // been specified at the end of this method. Our unrolled version comes
- // out to be about 25% faster than the looped version. The unrolled
- // version has data dependency, so its not the ILP but probably the absence
- // of branching which makes it faster than the looped version.
-
- d_result = 5381ULL;
-
- const char *start = reinterpret_cast<const char*>(data);
- d_result = (d_result << 5) + d_result + start[0];
- d_result = (d_result << 5) + d_result + start[1];
- d_result = (d_result << 5) + d_result + start[2];
- d_result = (d_result << 5) + d_result + start[3];
- d_result = (d_result << 5) + d_result + start[4];
- d_result = (d_result << 5) + d_result + start[5];
- d_result = (d_result << 5) + d_result + start[6];
- d_result = (d_result << 5) + d_result + start[7];
- d_result = (d_result << 5) + d_result + start[8];
- d_result = (d_result << 5) + d_result + start[9];
- d_result = (d_result << 5) + d_result + start[10];
- d_result = (d_result << 5) + d_result + start[11];
- d_result = (d_result << 5) + d_result + start[12];
- d_result = (d_result << 5) + d_result + start[13];
- d_result = (d_result << 5) + d_result + start[14];
- d_result = (d_result << 5) + d_result + start[15];
-
- // For reference, 'loop' version of djb2 algorithm:
- //..
- // size_t index = 0;
- // while (index++ < numBytes) {
- // d_result = (d_result << 5) + d_result + // same as 'd_result * 33'
- // (reinterpret_cast<const char*>(data))[index];
- // }
- //..
-}
-
-inline
-MessageGUIDHashAlgo::result_type
-MessageGUIDHashAlgo::computeHash()
-{
- return d_result;
-}
-
-} // close package namespace
-
-
- // -----------------
- // class MessageGUID
- // -----------------
-
-// FREE OPERATORS
-inline
-bool
-bmqt::operator==(const bmqt::MessageGUID& lhs,
- const bmqt::MessageGUID& rhs)
-{
- return 0 == bsl::memcmp(lhs.d_buffer,
- rhs.d_buffer,
- MessageGUID::e_SIZE_BINARY);
-}
-
-inline
-bool
-bmqt::operator!=(const bmqt::MessageGUID& lhs,
- const bmqt::MessageGUID& rhs)
-{
- return !(lhs == rhs);
-}
-
-inline
-bool
-bmqt::operator<(const bmqt::MessageGUID& lhs,
- const bmqt::MessageGUID& rhs)
-{
- MessageGUIDLess less;
- return less(lhs, rhs);
-}
-
-inline
-bsl::ostream&
-bmqt::operator<<(bsl::ostream& stream,
- const bmqt::MessageGUID& rhs)
-{
- return rhs.print(stream, 0, -1);
-}
-
-} // close enterprise namespace
-
-#endif
-
-Generated on Thu Jun 15 2023 11:58:51 by
-
- 1.7.1
-
-
diff --git a/docs/docs/apidocs/cpp_apidocs/bmqt__propertytype_8h_source.html b/docs/docs/apidocs/cpp_apidocs/bmqt__propertytype_8h_source.html
deleted file mode 100644
index 1771993ba..000000000
--- a/docs/docs/apidocs/cpp_apidocs/bmqt__propertytype_8h_source.html
+++ /dev/null
@@ -1,166 +0,0 @@
-
-
-Bloomberg Development Environment
-
-
-// Copyright 2016-2023 Bloomberg Finance L.P.
-// SPDX-License-Identifier: Apache-2.0
-//
-// Licensed under the Apache License, Version 2.0 (the "License");
-// you may not use this file except in compliance with the License.
-// You may obtain a copy of the License at
-//
-// http://www.apache.org/licenses/LICENSE-2.0
-//
-// Unless required by applicable law or agreed to in writing, software
-// distributed under the License is distributed on an "AS IS" BASIS,
-// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-// See the License for the specific language governing permissions and
-// limitations under the License.
-
-// bmqt_propertytype.h -*-C++-*-
-#ifndef INCLUDED_BMQT_PROPERTYTYPE
-#define INCLUDED_BMQT_PROPERTYTYPE
-
-//@PURPOSE: Provide enum for the supported data types for a message property.
-//
-//@CLASSES:
-// bmqt::PropertyType: Enum for supported data types for a message property.
-//
-//@DESCRIPTION: This component contains 'bmqt::PropertyType' which describes
-// various data types that are supported for message properties.
-//
-///Data Types and Size
-///-------------------
-// This section describes the size of each data type:
-//..
-//
-// +----------------------------------------------------+
-// | Data Type | Size (in bytes) |
-// +====================================================+
-// | BOOL | 1
-// | CHAR | 1 |
-// +----------------------------------------------------+
-// | SHORT | 2 |
-// +----------------------------------------------------+
-// | INT | 4 |
-// +----------------------------------------------------+
-// | INT64 | 8 |
-// +----------------------------------------------------+
-// | STRING | variable |
-// +----------------------------------------------------+
-// | BINARY | variable |
-// +----------------------------------------------------+
-//..
-//
-// Note that the difference between 'BINARY' and 'STRING' data types is that
-// the former allows null ('\0') character while the later does not.
-
-
-// BMQ
-#include <bmqscm_version.h>
-
-// BDE
-#include <bsl_iosfwd.h>
-#include <bsl_string.h>
-
-namespace BloombergLP {
-namespace bmqt {
-
- // ===================
- // struct PropertyType
- // ===================
-
-struct PropertyType {
- // This enum represents the supported data types for a message property.
-
- // TYPES
- enum Enum {
- e_UNDEFINED = 0
- , e_BOOL = 1
- , e_CHAR = 2
- , e_SHORT = 3
- , e_INT32 = 4
- , e_INT64 = 5
- , e_STRING = 6
- , e_BINARY = 7
- };
-
- // CONSTANTS
- static const int k_LOWEST_SUPPORTED_PROPERTY_TYPE = e_BOOL;
- // NOTE: This value must always be equal to the lowest type in the
- // enum because it is being used as a lower bound to verify that a
- // Property's 'type' field is a supported type.
-
- static const int k_HIGHEST_SUPPORTED_PROPERTY_TYPE = e_BINARY;
- // NOTE: This value must always be equal to the highest type in the
- // enum because it is being used as an upper bound to verify a
- // Property's 'type' field is a supported type.
-
- // CLASS METHODS
- static bsl::ostream& print(bsl::ostream& stream,
- PropertyType::Enum value,
- int level = 0,
- int spacesPerLevel = 4);
- // Write the string representation of the specified enumeration 'value'
- // to the specified output 'stream', and return a reference to
- // 'stream'. Optionally specify an initial indentation 'level', whose
- // absolute value is incremented recursively for nested objects. If
- // 'level' is specified, optionally specify 'spacesPerLevel', whose
- // absolute value indicates the number of spaces per indentation level
- // for this and all of its nested objects. If 'level' is negative,
- // suppress indentation of the first line. If 'spacesPerLevel' is
- // negative, format the entire output on one line, suppressing all but
- // the initial indentation (as governed by 'level'). See 'toAscii' for
- // what constitutes the string representation of a
- // 'PropertyType::Enum' value.
-
- static const char *toAscii(PropertyType::Enum value);
- // Return the non-modifiable string representation corresponding to the
- // specified enumeration 'value', if it exists, and a unique (error)
- // string otherwise. The string representation of 'value' matches its
- // corresponding enumerator name with the 'e_' prefix elided. Note
- // that specifying a 'value' that does not match any of the enumerators
- // will result in a string representation that is distinct from any of
- // those corresponding to the enumerators, but is otherwise
- // unspecified.
-
- static bool fromAscii(PropertyType::Enum *out,
- const bslstl::StringRef& str);
- // Return true and fills the specified 'out' with the enum value
- // corresponding to the specified 'str', if valid, or return false and
- // leave 'out' untouched if 'str' doesn't correspond to any value of
- // the enum.
-};
-
-// FREE OPERATORS
-bsl::ostream& operator<<(bsl::ostream& stream,
- PropertyType::Enum value);
- // Format the specified 'value' to the specified output 'stream' and return
- // a reference to the modifiable 'stream'.
-
-} // close package namespace
-
-
-// ============================================================================
-// INLINE DEFINITIONS
-// ============================================================================
-
- // -------------------
- // struct PropertyType
- // -------------------
-
-inline
-bsl::ostream&
-bmqt::operator<<(bsl::ostream& stream,
- bmqt::PropertyType::Enum value)
-{
- return bmqt::PropertyType::print(stream, value, 0 , -1);
-}
-
-} // close enterprise namespace
-
-#endif
-
-Generated on Thu Jun 15 2023 11:58:51 by
-
- 1.7.1
-
-
diff --git a/docs/docs/apidocs/cpp_apidocs/bmqt__queueflags_8h_source.html b/docs/docs/apidocs/cpp_apidocs/bmqt__queueflags_8h_source.html
deleted file mode 100644
index 92d5661ca..000000000
--- a/docs/docs/apidocs/cpp_apidocs/bmqt__queueflags_8h_source.html
+++ /dev/null
@@ -1,346 +0,0 @@
-
-
-Bloomberg Development Environment
-
-
-// Copyright 2014-2023 Bloomberg Finance L.P.
-// SPDX-License-Identifier: Apache-2.0
-//
-// Licensed under the Apache License, Version 2.0 (the "License");
-// you may not use this file except in compliance with the License.
-// You may obtain a copy of the License at
-//
-// http://www.apache.org/licenses/LICENSE-2.0
-//
-// Unless required by applicable law or agreed to in writing, software
-// distributed under the License is distributed on an "AS IS" BASIS,
-// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-// See the License for the specific language governing permissions and
-// limitations under the License.
-
-// bmqt_queueflags.h -*-C++-*-
-#ifndef INCLUDED_BMQT_QUEUEFLAGS
-#define INCLUDED_BMQT_QUEUEFLAGS
-
-//@PURPOSE: Provide enumerators for flags to use at Queue open.
-//
-//@CLASSES:
-// bmqt::QueueFlags: flags to use at Queue open
-// bmqt::QueueFlagsUtil: utilities to manipulate queue flags bit-mask values
-//
-//@DESCRIPTION: This file contains an enum, 'bmqt::QueueFlags' of all the flags
-// that can be used at Queue open. Each value of the enum correspond to a bit
-// of a bit-mask integer. It also exposes a set of utilities, in the
-// 'bmqt::QueueFlagsUtil' namespace to manipulate such bit-mask value.
-
-// BMQ
-#include <bmqscm_version.h>
-
-// BDE
-#include <bsl_iosfwd.h>
-#include <bsl_string.h>
-#include <bsls_types.h>
-
-namespace BloombergLP {
-namespace bmqt {
-
-
- // =================
- // struct QueueFlags
- // =================
-
-struct QueueFlags {
- // This enum represents queue flags
-
- // TYPES
- enum Enum {
- e_ADMIN = (1 << 0) // The queue is opened in admin mode (Valid only
- // for BlazingMQ admin tasks)
- , e_READ = (1 << 1) // The queue is opened for consuming messages
- , e_WRITE = (1 << 2) // The queue is opened for posting messages
- , e_ACK = (1 << 3) // Set to indicate interested in receiving
- // 'ACK' events for all message posted
- };
-
- // PUBLIC CONSTANTS
- static const int k_LOWEST_SUPPORTED_QUEUE_FLAG = e_ADMIN;
- // NOTE: This value must always be equal to the lowest type in the
- // enum because it is being used as a lower bound to verify that a
- // QueueFlags field is a supported type.
-
- static const int k_HIGHEST_SUPPORTED_QUEUE_FLAG = e_ACK;
- // NOTE: This value must always be equal to the highest *supported*
- // type in the enum because it is being used to verify a QueueFlags
- // field is a supported type.
-
-
- // CLASS METHODS
- static bsl::ostream& print(bsl::ostream& stream,
- QueueFlags::Enum value,
- int level = 0,
- int spacesPerLevel = 4);
- // Write the string representation of the specified enumeration 'value'
- // to the specified output 'stream', and return a reference to
- // 'stream'. Optionally specify an initial indentation 'level', whose
- // absolute value is incremented recursively for nested objects. If
- // 'level' is specified, optionally specify 'spacesPerLevel', whose
- // absolute value indicates the number of spaces per indentation level
- // for this and all of its nested objects. If 'level' is negative,
- // suppress indentation of the first line. If 'spacesPerLevel' is
- // negative, format the entire output on one line, suppressing all but
- // the initial indentation (as governed by 'level'). See 'toAscii' for
- // what constitutes the string representation of a
- // 'GenericResult::Enum' value.
-
- static const char *toAscii(QueueFlags::Enum value);
- // Return the non-modifiable string representation corresponding to the
- // specified enumeration 'value', if it exists, and a unique (error)
- // string otherwise. The string representation of 'value' matches its
- // corresponding enumerator name with the 'e_' prefix elided. Note
- // that specifying a 'value' that does not match any of the enumerators
- // will result in a string representation that is distinct from any of
- // those corresponding to the enumerators, but is otherwise
- // unspecified.
-
- static bool fromAscii(QueueFlags::Enum *out, const bslstl::StringRef& str);
- // Return true and fills the specified 'out' with the enum value
- // corresponding to the specified 'str', if valid, or return false and
- // leave 'out' untouched if 'str' doesn't correspond to any value of
- // the enum.
-};
-
-// FREE OPERATORS
-bsl::ostream& operator<<(bsl::ostream& stream, QueueFlags::Enum value);
- // Format the specified 'value' to the specified output 'stream' and return
- // a reference to the modifiable 'stream'.
-
-
- // =====================
- // struct QueueFlagsUtil
- // =====================
-
-struct QueueFlagsUtil {
-
- public:
- // CLASS METHODS
- static bool isSet(bsls::Types::Uint64 flags, QueueFlags::Enum flag);
- // Return true if the bit-mask in the specified 'flags' has the
- // specified 'flag' set, or false if not.
- //
- // DEPRECATED: This method is deprecated in favor of the below more
- // specific accessors; and should be made private once all
- // clients have been updated to the new APIs.
-
- public:
- // CLASS METHODS
- static
- bool isValid(bsl::ostream& errorDescription, bsls::Types::Uint64 flags);
- // Check whether the specified 'flags' represent a valid combination of
- // flags to use for opening a queue. Return true if it does, or false
- // if some exclusive flags are both set, and populate the specified
- // 'errorDescription' with the reason of the failure.
-
- static bsls::Types::Uint64 empty();
- // The 'empty' value for flags.
-
- static bool isEmpty(bsls::Types::Uint64 flags);
- // Returns 'true' if the specified 'flags' have the 'empty' value.
-
- static bool isReader(bsls::Types::Uint64 flags);
- // Returns 'true' if the specified 'flags' represent a reader.
-
- static bool isWriter(bsls::Types::Uint64 flags);
- // Returns 'true' if the specified 'flags' represent a writer.
-
- static bool isAdmin(bsls::Types::Uint64 flags);
- // Returns 'true' if the specified 'flags' represent an admin.
-
- static bool isAck(bsls::Types::Uint64 flags);
- // Returns 'true' if the specified 'flags' represent ack required.
-
- static void setReader(bsls::Types::Uint64 *flags);
- // Sets the specified 'flags' representation for reader.
-
- static void setAdmin(bsls::Types::Uint64 *flags);
- // Sets the specified 'flags' representation for admin.
-
- static void setWriter(bsls::Types::Uint64 *flags);
- // Sets the specified 'flags' representation for writer.
-
- static void setAck(bsls::Types::Uint64 *flags);
- // Sets the specified 'flags' representation for ack.
-
- static void unsetReader(bsls::Types::Uint64 *flags);
- // Resets the specified 'flags' representation for reader.
-
- static void unsetAdmin(bsls::Types::Uint64 *flags);
- // Resets the specified 'flags' representation for admin.
-
- static void unsetWriter(bsls::Types::Uint64 *flags);
- // Resets the specified 'flags' representation for writer.
-
- static void unsetAck(bsls::Types::Uint64 *flags);
- // Resets the specified 'flags' representation for ack.
-
- static bsls::Types::Uint64 additions(bsls::Types::Uint64 oldFlags,
- bsls::Types::Uint64 newFlags);
- // Return a new flag mask that only set bits are the ones that are in
- // the specified 'newFlags' and not in the specified 'oldFlags'.
-
- static bsls::Types::Uint64 removals(bsls::Types::Uint64 oldFlags,
- bsls::Types::Uint64 newFlags);
- // Return a new flag mask that only set bits are the ones that are in
- // the specified 'oldFlags' and not in the specified 'newFlags'.
-
- static
- bsl::ostream& prettyPrint(bsl::ostream& stream, bsls::Types::Uint64 flags);
- // Print the ascii-representation of all the values set in the
- // specified 'flags' to the specified 'stream'. Each value is ','
- // separated.
-
- static int fromString(bsl::ostream& errorDescription,
- bsls::Types::Uint64 *out,
- const bsl::string& str);
- // Convert the string representation of the enum bit mask from the
- // specified 'str' (which format corresponds to the one of the
- // 'prettyPrint' method) and populate the specified 'out' with the
- // result on success returning 0, or return a non-zero error code on
- // error, populating the specified 'errorDescription' with a
- // description of the error.
-};
-
-// ============================================================================
-// INLINE DEFINITIONS
-// ============================================================================
-
-
- // ---------------------
- // struct QueueFlagsUtil
- // ---------------------
-
-inline
-bool
-QueueFlagsUtil::isSet(bsls::Types::Uint64 flags,
- QueueFlags::Enum flag)
-{
- return ((flags & flag) != 0);
-}
-
-inline
-void
-QueueFlagsUtil::setReader(bsls::Types::Uint64 *flags)
-{
- *flags |= bmqt::QueueFlags::e_READ;
-}
-
-inline
-void
-QueueFlagsUtil::setAdmin(bsls::Types::Uint64 *flags)
-{
- *flags |= bmqt::QueueFlags::e_ADMIN;
-}
-
-inline
-void
-QueueFlagsUtil::setWriter(bsls::Types::Uint64 *flags)
-{
- *flags |= bmqt::QueueFlags::e_WRITE;
-}
-
-inline
-void
-QueueFlagsUtil::setAck(bsls::Types::Uint64 *flags)
-{
- *flags |= bmqt::QueueFlags::e_ACK;
-}
-
-inline
-void
-QueueFlagsUtil::unsetReader(bsls::Types::Uint64 *flags)
-{
- *flags &= ~bmqt::QueueFlags::e_READ;
-}
-
-inline
-void
-QueueFlagsUtil::unsetAdmin(bsls::Types::Uint64 *flags)
-{
- *flags &= ~bmqt::QueueFlags::e_ADMIN;
-}
-
-inline
-void
-QueueFlagsUtil::unsetWriter(bsls::Types::Uint64 *flags)
-{
- *flags &= ~bmqt::QueueFlags::e_WRITE;
-}
-
-inline
-void
-QueueFlagsUtil::unsetAck(bsls::Types::Uint64 *flags)
-{
- *flags &= ~bmqt::QueueFlags::e_ACK;
-}
-
-inline
-bool
-QueueFlagsUtil::isReader(bsls::Types::Uint64 flags)
-{
- return isSet(flags, bmqt::QueueFlags::e_READ);
-}
-
-inline
-bool
-QueueFlagsUtil::isWriter(bsls::Types::Uint64 flags)
-{
- return isSet(flags, bmqt::QueueFlags::e_WRITE);
-}
-
-inline
-bool
-QueueFlagsUtil::isAdmin(bsls::Types::Uint64 flags)
-{
- return isSet(flags, bmqt::QueueFlags::e_ADMIN);
-}
-
-inline
-bool
-QueueFlagsUtil::isAck(bsls::Types::Uint64 flags)
-{
- return isSet(flags, bmqt::QueueFlags::e_ACK);
-}
-
-inline
-bool
-QueueFlagsUtil::isEmpty(bsls::Types::Uint64 flags)
-{
- return flags == empty();
-}
-
-inline
-bsls::Types::Uint64
-QueueFlagsUtil::empty()
-{
- return 0;
-}
-
-} // close package namespace
-
- // -----------------
- // struct QueueFlags
- // -----------------
-
-inline
-bsl::ostream&
-bmqt::operator<<(bsl::ostream& stream,
- bmqt::QueueFlags::Enum value)
-{
- return bmqt::QueueFlags::print(stream, value, 0 , -1);
-}
-
-} // close enterprise namespace
-
-#endif
-
-Generated on Thu Jun 15 2023 11:58:51 by
-
- 1.7.1
-
-
diff --git a/docs/docs/apidocs/cpp_apidocs/bmqt__queueoptions_8h_source.html b/docs/docs/apidocs/cpp_apidocs/bmqt__queueoptions_8h_source.html
deleted file mode 100644
index 7575a739f..000000000
--- a/docs/docs/apidocs/cpp_apidocs/bmqt__queueoptions_8h_source.html
+++ /dev/null
@@ -1,399 +0,0 @@
-
-
-Bloomberg Development Environment
-
-
-// Copyright 2015-2023 Bloomberg Finance L.P.
-// SPDX-License-Identifier: Apache-2.0
-//
-// Licensed under the Apache License, Version 2.0 (the "License");
-// you may not use this file except in compliance with the License.
-// You may obtain a copy of the License at
-//
-// http://www.apache.org/licenses/LICENSE-2.0
-//
-// Unless required by applicable law or agreed to in writing, software
-// distributed under the License is distributed on an "AS IS" BASIS,
-// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-// See the License for the specific language governing permissions and
-// limitations under the License.
-
-// bmqt_queueoptions.h -*-C++-*-
-#ifndef INCLUDED_BMQT_QUEUEOPTIONS
-#define INCLUDED_BMQT_QUEUEOPTIONS
-
-//@PURPOSE: Provide a value-semantic type for options related to a queue.
-//
-//@CLASSES:
-// bmqt::QueueOptions: options related to a queue.
-//
-//@DESCRIPTION: 'bmqt::QueueOptions' provides a value-semantic type,
-// 'QueueOptions', which is used to specify parameters for a queue.
-//
-//
-// The following parameters are supported:
-//: o !maxUnconfirmedMessages!:
-//: Maximum number of outstanding messages that can be sent by the broker
-//: without being confirmed.
-//:
-//: o !maxUnconfirmedBytes!:
-//: Maximum accumulated bytes of all outstanding messages that can be sent
-//: by the broker without being confirmed.
-//:
-//: o !consumerPriority!:
-//: Priority of a consumer with respect to delivery of messages.
-//:
-//: o !suspendsOnBadHostHealth!:
-//: Sets whether the queue should suspend operation when the host machine
-//: is unhealthy.
-
-
-// BMQ
-#include <bmqscm_version.h>
-#include <bmqt_subscription.h>
-
-//BDE
-#include <bsl_iosfwd.h>
-#include <bsl_optional.h>
-#include <bsl_vector.h>
-#include <bsl_unordered_map.h>
-#include <bslma_allocator.h>
-#include <bslma_usesbslmaallocator.h>
-#include <bslmf_nestedtraitdeclaration.h>
-
-namespace BloombergLP {
-
-namespace bmqt {
-
-
- // ==================
- // class QueueOptions
- // ==================
-
-class QueueOptions {
- // Value-semantic type for options related to a queue.
-
- public:
- // PUBLIC CONSTANTS
- static const int k_CONSUMER_PRIORITY_MIN;
- // Constant representing the minimum
- // valid consumer priority
-
- static const int k_CONSUMER_PRIORITY_MAX;
- // Constant representing the maximum
- // valid consumer priority
-
- static const int k_DEFAULT_MAX_UNCONFIRMED_MESSAGES;
- static const int k_DEFAULT_MAX_UNCONFIRMED_BYTES;
- static const int k_DEFAULT_CONSUMER_PRIORITY;
- static const bool k_DEFAULT_SUSPENDS_ON_BAD_HOST_HEALTH;
-
- private:
- // PRIVATE TYPES
- typedef bsl::unordered_map<SubscriptionHandle, Subscription> Subscriptions;
-
- private:
- // DATA
- Subscription d_info;
-
- bsl::optional<bool> d_suspendsOnBadHostHealth;
- // Whether the queue suspends operation
- // while the host is unhealthy.
-
- Subscriptions d_subscriptions;
-
- bool d_hadSubscriptions;
- // 'true' if 'd_subscriptions' had a value, 'false'
- // otherwise. Emulates 'bsl::optional' for
- // 'd_subscriptions'.
-
- bslma::Allocator *d_allocator_p;
- // Allocator
-
- public:
- // PUBLIC TYPES
-
- typedef bsl::pair<SubscriptionHandle, Subscription> HandleAndSubscription;
- typedef bsl::vector<HandleAndSubscription> SubscriptionsSnapshot;
- // 'loadSubscriptions' return types
- //
- // EXPERIMENTAL. Do not use until this feature is announced.
-
- public:
- // TRAITS
- BSLMF_NESTED_TRAIT_DECLARATION(QueueOptions, bslma::UsesBslmaAllocator)
-
- // CREATORS
- explicit QueueOptions(bslma::Allocator *allocator = 0);
- // Create a new QueueOptions using the optionally specified
- // 'allocator'.
-
- QueueOptions(const QueueOptions& other,
- bslma::Allocator *allocator = 0);
- // Create a new QueueOptions by copying values from the specified
- // 'other', using the optionally specified 'allocator'.
-
- // MANIPULATORS
- QueueOptions& setMaxUnconfirmedMessages(int value);
- // Set the maxUnconfirmedMessages to the specified 'value'. The
- // behavior is undefined unless 'value >= 0'. If the specified 'value'
- // is set to 0, it means that the consumer does not receive any
- // messages. This might be useful when the consumer is shutting down
- // and wants to process only pending messages, or when it is unable to
- // process new messages because of transient issues.
-
- QueueOptions& setMaxUnconfirmedBytes(int value);
- // Set the maxUnconfirmedBytes to the specified 'value'. The behavior
- // is undefined unless 'value >= 0'.
-
- QueueOptions& setConsumerPriority(int value);
- // Set the consumerPriority to the specified 'value'. The behavior is
- // undefined unless 'k_CONSUMER_PRIORITY_MIN <= value <=
- // k_CONSUMER_PRIORITY_MAX'
-
- QueueOptions& setSuspendsOnBadHostHealth(bool value);
- // Set whether the queue suspends operation while host is unhealthy.
-
- QueueOptions& merge(const QueueOptions& other);
- // "Merges" another 'QueueOptions' into this one, by invoking
- // setF(other.F())
- // for all fields 'F' for which 'other.hasF()' is true. Returns the
- // instance on which the method was invoked.
-
- bool addOrUpdateSubscription(bsl::string *errorDescription,
- const SubscriptionHandle& handle,
- const Subscription& subscription);
- // Add, or update if it exists, the specified 'subscription' for the
- // specified 'handle'. Return true on success, otherwise return false
- // and load the specified 'errorDescription' with a description of the
- // error. Note that 'errorDescription' may be null if the caller does
- // not care about getting error messages, but users are strongly
- // encouraged to log error string if this API returns failure.
- //
- // EXPERIMENTAL. Do not use until this feature is announced.
-
- bool removeSubscription(const SubscriptionHandle& handle);
- // Return false if subscription does not exist.
- //
- // EXPERIMENTAL. Do not use until this feature is announced.
-
- void removeAllSubscriptions();
- // Remove all subscriptions.
- //
- // EXPERIMENTAL. Do not use until this feature is announced.
-
- // ACCESSORS
- int maxUnconfirmedMessages() const;
- // Get the number for the maxUnconfirmedMessages parameter.
-
- int maxUnconfirmedBytes() const;
- // Get the number for the maxUnconfirmedBytes parameter.
-
- int consumerPriority() const;
- // Get the number for the consumerPriority parameter.
-
- bool suspendsOnBadHostHealth() const;
- // Get whether the queue suspends operation while host is unhealthy.
-
- bool hasMaxUnconfirmedMessages() const;
- // Returns whether 'maxUnconfirmedMessages' has been set for this
- // object, or whether it implicitly holds
- // 'k_DEFAULT_MAX_UNCONFIRMED_MESSAGES'.
-
- bool hasMaxUnconfirmedBytes() const;
- // Returns whether 'maxUnconfirmedBytes' has been set for this object,
- // or whether it implicitly holds 'k_DEFAULT_MAX_UNCONFIRMED_BYTES'.
-
- bool hasConsumerPriority() const;
- // Returns whether 'consumerPriority' has been set for this object, or
- // whether it implicitly holds 'k_DEFAULT_CONSUMER_PRIORITY'.
-
- bool hasSuspendsOnBadHostHealth() const;
- // Returns whether 'suspendsOnBadHostHealth' has been set for this
- // object, or whether it implicitly holds
- // 'k_DEFAULT_SUSPENDS_ON_BAD_HOST_HEALTH'.
-
- bool loadSubscription(Subscription *subscription,
- const SubscriptionHandle& handle) const;
- // Return false if subscription does not exist.
- //
- // EXPERIMENTAL. Do not use until this feature is announced.
-
- void loadSubscriptions(SubscriptionsSnapshot *snapshot) const;
- // Load all handles and subscriptions into the specified 'snapshot'.
- //
- // EXPERIMENTAL. Do not use until this feature is announced.
-
- bsl::ostream& print(bsl::ostream& stream,
- int level = 0,
- int spacesPerLevel = 4) const;
- // Format this object to the specified output 'stream' at the (absolute
- // value of) the optionally specified indentation 'level' and return a
- // reference to 'stream'. If 'level' is specified, optionally specify
- // 'spacesPerLevel', the number of spaces per indentation level for
- // this and all of its nested objects. If 'level' is negative,
- // suppress indentation of the first line. If 'spacesPerLevel' is
- // negative format the entire output on one line, suppressing all but
- // the initial indentation (as governed by 'level'). If 'stream' is
- // not valid on entry, this operation has no effect.
-};
-
-// FREE OPERATORS
-bool operator==(const QueueOptions& lhs, const QueueOptions& rhs);
- // Return 'true' if the specified 'rhs' object contains the value of the
- // same type as contained in the specified 'lhs' object and the value
- // itself is the same in both objects, return false otherwise.
-
-bool operator!=(const QueueOptions& lhs, const QueueOptions& rhs);
- // Return 'false' if the specified 'rhs' object contains the value of the
- // same type as contained in the specified 'lhs' object and the value
- // itself is the same in both objects, return 'true' otherwise.
-
-bsl::ostream& operator<<(bsl::ostream& stream, const QueueOptions& rhs);
- // Format the specified 'rhs' to the specified output 'stream' and return a
- // reference to the modifiable 'stream'.
-
-
-// ============================================================================
-// INLINE DEFINITIONS
-// ============================================================================
-
-
- // ------------------
- // class QueueOptions
- // ------------------
-
-// MANIPULATORS
-inline
-QueueOptions&
-QueueOptions::setMaxUnconfirmedMessages(int value)
-{
- d_info.setMaxUnconfirmedMessages(value);
- return *this;
-}
-
-inline
-QueueOptions&
-QueueOptions::setMaxUnconfirmedBytes(int value)
-{
- d_info.setMaxUnconfirmedBytes(value);
- return *this;
-}
-
-inline
-QueueOptions&
-QueueOptions::setConsumerPriority(int value)
-{
- d_info.setConsumerPriority(value);
- return *this;
-}
-
-inline
-QueueOptions&
-QueueOptions::setSuspendsOnBadHostHealth(bool value)
-{
- d_suspendsOnBadHostHealth.emplace(value);
- return *this;
-}
-
-// ACCESSORS
-inline
-int
-QueueOptions::maxUnconfirmedMessages() const
-{
- return d_info.maxUnconfirmedMessages();
-}
-
-inline
-int
-QueueOptions::maxUnconfirmedBytes() const
-{
- return d_info.maxUnconfirmedBytes();
-}
-
-inline
-int
-QueueOptions::consumerPriority() const
-{
- return d_info.consumerPriority();
-}
-
-inline
-bool
-QueueOptions::suspendsOnBadHostHealth() const
-{
- return d_suspendsOnBadHostHealth.value_or(
- k_DEFAULT_SUSPENDS_ON_BAD_HOST_HEALTH);
-}
-
-inline
-bool
-QueueOptions::hasMaxUnconfirmedMessages() const
-{
- return d_info.hasMaxUnconfirmedMessages();
-}
-
-inline
-bool
-QueueOptions::hasMaxUnconfirmedBytes() const
-{
- return d_info.hasMaxUnconfirmedBytes();
-}
-
-inline
-bool
-QueueOptions::hasConsumerPriority() const
-{
- return d_info.hasConsumerPriority();
-}
-
-inline
-bool
-QueueOptions::hasSuspendsOnBadHostHealth() const
-{
- return d_suspendsOnBadHostHealth.has_value();
-}
-
-} // close package namespace
-
-
- // ------------------
- // class QueueOptions
- // ------------------
-
-inline
-bool
-bmqt::operator==(const bmqt::QueueOptions& lhs,
- const bmqt::QueueOptions& rhs)
-{
- return lhs.maxUnconfirmedMessages() == rhs.maxUnconfirmedMessages()
- && lhs.maxUnconfirmedBytes() == rhs.maxUnconfirmedBytes()
- && lhs.consumerPriority() == rhs.consumerPriority()
- && lhs.suspendsOnBadHostHealth() == rhs.suspendsOnBadHostHealth();
-}
-
-inline
-bool
-bmqt::operator!=(const bmqt::QueueOptions& lhs,
- const bmqt::QueueOptions& rhs)
-{
- return lhs.maxUnconfirmedMessages() != rhs.maxUnconfirmedMessages()
- || lhs.maxUnconfirmedBytes() != rhs.maxUnconfirmedBytes()
- || lhs.consumerPriority() != rhs.consumerPriority()
- || lhs.suspendsOnBadHostHealth() != rhs.suspendsOnBadHostHealth();
-}
-
-inline
-bsl::ostream&
-bmqt::operator<<(bsl::ostream& stream,
- const bmqt::QueueOptions& rhs)
-{
- return rhs.print(stream, 0, -1);
-}
-
-} // close enterprise namespace
-
-#endif
-
-Generated on Thu Jun 15 2023 11:58:51 by
-
- 1.7.1
-
-
diff --git a/docs/docs/apidocs/cpp_apidocs/bmqt__resultcode_8h_source.html b/docs/docs/apidocs/cpp_apidocs/bmqt__resultcode_8h_source.html
deleted file mode 100644
index df4975fcd..000000000
--- a/docs/docs/apidocs/cpp_apidocs/bmqt__resultcode_8h_source.html
+++ /dev/null
@@ -1,670 +0,0 @@
-
-
-Bloomberg Development Environment
-
-
-// Copyright 2014-2023 Bloomberg Finance L.P.
-// SPDX-License-Identifier: Apache-2.0
-//
-// Licensed under the Apache License, Version 2.0 (the "License");
-// you may not use this file except in compliance with the License.
-// You may obtain a copy of the License at
-//
-// http://www.apache.org/licenses/LICENSE-2.0
-//
-// Unless required by applicable law or agreed to in writing, software
-// distributed under the License is distributed on an "AS IS" BASIS,
-// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-// See the License for the specific language governing permissions and
-// limitations under the License.
-
-// bmqt_resultcode.h -*-C++-*-
-#ifndef INCLUDED_BMQT_RESULTCODE
-#define INCLUDED_BMQT_RESULTCODE
-
-//@PURPOSE: Provide enums for various publicly exposed result code.
-//
-//@CLASSES:
-// bmqt::GenericResult: generic common result values
-// bmqt::AckResult: result code status of an ack message
-// bmqt::CloseQueueResult: result of a close queue operation
-// bmqt::EventBuilderResult: result of eventBuilder pack operation
-// bmqt::OpenQueueResult: result of an open queue operation
-// bmqt::ConfigureQueueResult: result of a configure queue operation
-// bmqt::PostResult: result of a post operation
-//
-//@DESCRIPTION: This file contains a list of Enums ('bmqt::GenericResult',
-// 'bmqt::AckResult', 'bmqt::CloseQueueResult', 'bmqt::EventBuilderResult',
-// 'bmqt::OpenQueueResult', 'bmqt::ConfigureQueueResult', and
-// 'bmqt::PostResult') that are publicly exposed to Application (via bmqa), but
-// whose value comes from the internal implementation (bmqimp). Having them
-// defined in bmqt allows bmqa to return the enum returned by bmqimp with no
-// transformation.
-//
-// All enums are using the convention that < 0 values are errors, while > 0 are
-// warnings.
-//
-// The 'GenericStatus' enum contains values that are common for most or all of
-// the other status enums, such as 'success', 'timeout', ... The values of its
-// members can range from -99 to 99.
-//
-// Each other enum should duplicate any values from the 'GenericStatus' one
-// that it intends to be able to represent (aliasing the values to the ones
-// from the 'GenericStatus' enum) and extend with specialized values in the
-// ']..., -99[' or ']99, ...[' ranges.
-//
-
-
-// BMQ
-#include <bmqscm_version.h>
-
-// BDE
-#include <bsl_iosfwd.h>
-#include <bsl_string.h>
-
-namespace BloombergLP {
-namespace bmqt {
-
- // ====================
- // struct GenericResult
- // ====================
-
-struct GenericResult {
- // This enum represents generic common status
-
- // TYPES
- enum Enum {
- e_SUCCESS = 0 // Operation was success
- , e_UNKNOWN = -1 // Operation failed for unknown reason
- , e_TIMEOUT = -2 // Operation timedout
- , e_NOT_CONNECTED = -3 // Cant process, not connected to the broker
- , e_CANCELED = -4 // Operation was canceled
- , e_NOT_SUPPORTED = -5 // Operation is not supported
- , e_REFUSED = -6 // Operation was refused
- , e_INVALID_ARGUMENT = -7 // An invalid argument was provided
- , e_NOT_READY = -8 // Not ready to process the request
- , e_LAST = e_NOT_READY
- // Used in test driver only, to validate
- // consistency between this enum and the
- // 'bmqp_ctrlmsg.xsd::StatusCategory' one
- };
-
- // CLASS METHODS
- static bsl::ostream& print(bsl::ostream& stream,
- GenericResult::Enum value,
- int level = 0,
- int spacesPerLevel = 4);
- // Write the string representation of the specified enumeration 'value'
- // to the specified output 'stream', and return a reference to
- // 'stream'. Optionally specify an initial indentation 'level', whose
- // absolute value is incremented recursively for nested objects. If
- // 'level' is specified, optionally specify 'spacesPerLevel', whose
- // absolute value indicates the number of spaces per indentation level
- // for this and all of its nested objects. If 'level' is negative,
- // suppress indentation of the first line. If 'spacesPerLevel' is
- // negative, format the entire output on one line, suppressing all but
- // the initial indentation (as governed by 'level'). See 'toAscii' for
- // what constitutes the string representation of a
- // 'GenericResult::Enum' value.
-
- static const char *toAscii(GenericResult::Enum value);
- // Return the non-modifiable string representation corresponding to the
- // specified enumeration 'value', if it exists, and a unique (error)
- // string otherwise. The string representation of 'value' matches its
- // corresponding enumerator name with the 'e_' prefix elided. Note
- // that specifying a 'value' that does not match any of the enumerators
- // will result in a string representation that is distinct from any of
- // those corresponding to the enumerators, but is otherwise
- // unspecified.
-
- static bool fromAscii(GenericResult::Enum *out,
- const bslstl::StringRef& str);
- // Return true and fills the specified 'out' with the enum value
- // corresponding to the specified 'str', if valid, or return false and
- // leave 'out' untouched if 'str' doesn't correspond to any value of
- // the enum.
-};
-
-// FREE OPERATORS
-bsl::ostream& operator<<(bsl::ostream& stream,
- GenericResult::Enum value);
- // Format the specified 'value' to the specified output 'stream' and return
- // a reference to the modifiable 'stream'.
-
-
- // ======================
- // struct OpenQueueResult
- // ======================
-
-struct OpenQueueResult {
- // This enum represents the result of an openQueue operation
-
- // TYPES
- enum Enum {
- // GENERIC
- e_SUCCESS = GenericResult::e_SUCCESS
- , e_UNKNOWN = GenericResult::e_UNKNOWN
- , e_TIMEOUT = GenericResult::e_TIMEOUT
- , e_NOT_CONNECTED = GenericResult::e_NOT_CONNECTED
- , e_CANCELED = GenericResult::e_CANCELED
- , e_NOT_SUPPORTED = GenericResult::e_NOT_SUPPORTED
- , e_REFUSED = GenericResult::e_REFUSED
- , e_INVALID_ARGUMENT = GenericResult::e_INVALID_ARGUMENT
- , e_NOT_READY = GenericResult::e_NOT_READY
-
- // SPECIALIZED
- // WARNINGS
- , e_ALREADY_OPENED = 100 // The queue is already opened
- , e_ALREADY_IN_PROGRESS = 101 // The queue is already being opened
-
- // ERRORS
- , e_INVALID_URI = -100 // The queue uri is invalid
- , e_INVALID_FLAGS = -101 // The flags provided are invalid
- , e_CORRELATIONID_NOT_UNIQUE = -102 // The correlationdId is not unique
- };
-
- // CLASS METHODS
- static bsl::ostream& print(bsl::ostream& stream,
- OpenQueueResult::Enum value,
- int level = 0,
- int spacesPerLevel = 4);
- // Write the string representation of the specified enumeration 'value'
- // to the specified output 'stream', and return a reference to
- // 'stream'. Optionally specify an initial indentation 'level', whose
- // absolute value is incremented recursively for nested objects. If
- // 'level' is specified, optionally specify 'spacesPerLevel', whose
- // absolute value indicates the number of spaces per indentation level
- // for this and all of its nested objects. If 'level' is negative,
- // suppress indentation of the first line. If 'spacesPerLevel' is
- // negative, format the entire output on one line, suppressing all but
- // the initial indentation (as governed by 'level'). See 'toAscii' for
- // what constitutes the string representation of a
- // 'OpenQueueResult::Enum' value.
-
- static const char *toAscii(OpenQueueResult::Enum value);
- // Return the non-modifiable string representation corresponding to the
- // specified enumeration 'value', if it exists, and a unique (error)
- // string otherwise. The string representation of 'value' matches its
- // corresponding enumerator name with the 'e_' prefix elided. Note
- // that specifying a 'value' that does not match any of the enumerators
- // will result in a string representation that is distinct from any of
- // those corresponding to the enumerators, but is otherwise
- // unspecified.
-
- static bool fromAscii(OpenQueueResult::Enum *out,
- const bslstl::StringRef& str);
- // Return true and fills the specified 'out' with the enum value
- // corresponding to the specified 'str', if valid, or return false and
- // leave 'out' untouched if 'str' doesn't correspond to any value of
- // the enum.
-};
-
-// FREE OPERATORS
-bsl::ostream& operator<<(bsl::ostream& stream,
- OpenQueueResult::Enum value);
- // Format the specified 'value' to the specified output 'stream' and return
- // a reference to the modifiable 'stream'.
-
-
- // ===========================
- // struct ConfigureQueueResult
- // ===========================
-
-struct ConfigureQueueResult {
- // This enum represents the result of a configureQueue operation
-
- // TYPES
- enum Enum {
- // GENERIC
- e_SUCCESS = GenericResult::e_SUCCESS
- , e_UNKNOWN = GenericResult::e_UNKNOWN
- , e_TIMEOUT = GenericResult::e_TIMEOUT
- , e_NOT_CONNECTED = GenericResult::e_NOT_CONNECTED
- , e_CANCELED = GenericResult::e_CANCELED
- , e_NOT_SUPPORTED = GenericResult::e_NOT_SUPPORTED
- , e_REFUSED = GenericResult::e_REFUSED
- , e_INVALID_ARGUMENT = GenericResult::e_INVALID_ARGUMENT
- , e_NOT_READY = GenericResult::e_NOT_READY
-
- // SPECIALIZED WARNINGS
- , e_ALREADY_IN_PROGRESS = 100 // The queue is already being configured
-
- // ERRORS
- , e_INVALID_QUEUE = -101
- };
-
- // CLASS METHODS
- static bsl::ostream& print(bsl::ostream& stream,
- ConfigureQueueResult::Enum value,
- int level = 0,
- int spacesPerLevel = 4);
- // Write the string representation of the specified enumeration 'value'
- // to the specified output 'stream', and return a reference to
- // 'stream'. Optionally specify an initial indentation 'level', whose
- // absolute value is incremented recursively for nested objects. If
- // 'level' is specified, optionally specify 'spacesPerLevel', whose
- // absolute value indicates the number of spaces per indentation level
- // for this and all of its nested objects. If 'level' is negative,
- // suppress indentation of the first line. If 'spacesPerLevel' is
- // negative, format the entire output on one line, suppressing all but
- // the initial indentation (as governed by 'level'). See 'toAscii' for
- // what constitutes the string representation of a
- // 'ConfigureQueueResult::Enum' value.
-
- static const char *toAscii(ConfigureQueueResult::Enum value);
- // Return the non-modifiable string representation corresponding to the
- // specified enumeration 'value', if it exists, and a unique (error)
- // string otherwise. The string representation of 'value' matches its
- // corresponding enumerator name with the 'e_' prefix elided. Note
- // that specifying a 'value' that does not match any of the enumerators
- // will result in a string representation that is distinct from any of
- // those corresponding to the enumerators, but is otherwise
- // unspecified.
-
- static bool fromAscii(ConfigureQueueResult::Enum *out,
- const bslstl::StringRef& str);
- // Return true and fills the specified 'out' with the enum value
- // corresponding to the specified 'str', if valid, or return false and
- // leave 'out' untouched if 'str' doesn't correspond to any value of
- // the enum.
-};
-
-// FREE OPERATORS
-bsl::ostream& operator<<(bsl::ostream& stream,
- ConfigureQueueResult::Enum value);
- // Format the specified 'value' to the specified output 'stream' and return
- // a reference to the modifiable 'stream'.
-
-
- // =======================
- // struct CloseQueueResult
- // =======================
-
-struct CloseQueueResult {
- // This enum represents the result of a closeQueue operation
-
- // TYPES
- enum Enum {
- // GENERIC
- e_SUCCESS = GenericResult::e_SUCCESS
- , e_UNKNOWN = GenericResult::e_UNKNOWN
- , e_TIMEOUT = GenericResult::e_TIMEOUT
- , e_NOT_CONNECTED = GenericResult::e_NOT_CONNECTED
- , e_CANCELED = GenericResult::e_CANCELED
- , e_NOT_SUPPORTED = GenericResult::e_NOT_SUPPORTED
- , e_REFUSED = GenericResult::e_REFUSED
- , e_INVALID_ARGUMENT = GenericResult::e_INVALID_ARGUMENT
- , e_NOT_READY = GenericResult::e_NOT_READY
-
- // SPECIALIZED
- // WARNINGS
- , e_ALREADY_CLOSED = 100 // The queue is already closed
- , e_ALREADY_IN_PROGRESS = 101 // The queue is already being closed
-
- // ERRORS
- , e_UNKNOWN_QUEUE = -100 // The queue doesn't exist
- , e_INVALID_QUEUE = -101 // The queue provided is invalid
- };
-
- // CLASS METHODS
- static bsl::ostream& print(bsl::ostream& stream,
- CloseQueueResult::Enum value,
- int level = 0,
- int spacesPerLevel = 4);
- // Write the string representation of the specified enumeration 'value'
- // to the specified output 'stream', and return a reference to
- // 'stream'. Optionally specify an initial indentation 'level', whose
- // absolute value is incremented recursively for nested objects. If
- // 'level' is specified, optionally specify 'spacesPerLevel', whose
- // absolute value indicates the number of spaces per indentation level
- // for this and all of its nested objects. If 'level' is negative,
- // suppress indentation of the first line. If 'spacesPerLevel' is
- // negative, format the entire output on one line, suppressing all but
- // the initial indentation (as governed by 'level'). See 'toAscii' for
- // what constitutes the string representation of a
- // 'PublishResult::Enum' value.
-
- static const char *toAscii(CloseQueueResult::Enum value);
- // Return the non-modifiable string representation corresponding to the
- // specified enumeration 'value', if it exists, and a unique (error)
- // string otherwise. The string representation of 'value' matches its
- // corresponding enumerator name with the 'e_' prefix elided. Note
- // that specifying a 'value' that does not match any of the enumerators
- // will result in a string representation that is distinct from any of
- // those corresponding to the enumerators, but is otherwise
- // unspecified.
-
- static bool fromAscii(CloseQueueResult::Enum *out,
- const bslstl::StringRef& str);
- // Return true and fills the specified 'out' with the enum value
- // corresponding to the specified 'str', if valid, or return false and
- // leave 'out' untouched if 'str' doesn't correspond to any value of
- // the enum.
-};
-
-// FREE OPERATORS
-bsl::ostream& operator<<(bsl::ostream& stream,
- CloseQueueResult::Enum value);
- // Format the specified 'value' to the specified output 'stream' and return
- // a reference to the modifiable 'stream'.
-
-
- // =========================
- // struct EventBuilderResult
- // =========================
-
-struct EventBuilderResult {
- // This enum represents the result of an EventBuilder's packMessage()
- // operation
-
- // TYPES
- enum Enum {
- // GENERIC
- e_SUCCESS = GenericResult::e_SUCCESS
- , e_UNKNOWN = GenericResult::e_UNKNOWN
-
- // SPECIALIZED
- // ERRORS
- , e_QUEUE_INVALID = -100
- , e_QUEUE_READONLY = -101
- , e_MISSING_CORRELATION_ID = -102
- , e_EVENT_TOO_BIG = -103
- , e_PAYLOAD_TOO_BIG = -104
- , e_PAYLOAD_EMPTY = -105
- , e_OPTION_TOO_BIG = -106
-#ifdef BMQ_ENABLE_MSG_GROUPID
- , e_INVALID_MSG_GROUP_ID = -107
-#endif
- , e_QUEUE_SUSPENDED = -108
- };
-
- // CLASS METHODS
- static bsl::ostream& print(bsl::ostream& stream,
- EventBuilderResult::Enum value,
- int level = 0,
- int spacesPerLevel = 4);
- // Write the string representation of the specified enumeration 'value'
- // to the specified output 'stream', and return a reference to
- // 'stream'. Optionally specify an initial indentation 'level', whose
- // absolute value is incremented recursively for nested objects. If
- // 'level' is specified, optionally specify 'spacesPerLevel', whose
- // absolute value indicates the number of spaces per indentation level
- // for this and all of its nested objects. If 'level' is negative,
- // suppress indentation of the first line. If 'spacesPerLevel' is
- // negative, format the entire output on one line, suppressing all but
- // the initial indentation (as governed by 'level'). See 'toAscii' for
- // what constitutes the string representation of a
- // 'EventBuilderResult::Enum' value.
-
- static const char *toAscii(EventBuilderResult::Enum value);
- // Return the non-modifiable string representation corresponding to the
- // specified enumeration 'value', if it exists, and a unique (error)
- // string otherwise. The string representation of 'value' matches its
- // corresponding enumerator name with the 'e_' prefix elided. Note
- // that specifying a 'value' that does not match any of the enumerators
- // will result in a string representation that is distinct from any of
- // those corresponding to the enumerators, but is otherwise
- // unspecified.
-
- static bool fromAscii(EventBuilderResult::Enum *out,
- const bslstl::StringRef& str);
- // Return true and fills the specified 'out' with the enum value
- // corresponding to the specified 'str', if valid, or return false and
- // leave 'out' untouched if 'str' doesn't correspond to any value of
- // the enum.
-};
-
-// FREE OPERATORS
-bsl::ostream& operator<<(bsl::ostream& stream,
- EventBuilderResult::Enum value);
- // Format the specified 'value' to the specified output 'stream' and return
- // a reference to the modifiable 'stream'.
-
-
- // ================
- // struct AckResult
- // ================
-
-struct AckResult {
- // This enum represents the result code status of an ack message
-
- // TYPES
- enum Enum {
- // GENERIC
- e_SUCCESS = GenericResult::e_SUCCESS
- , e_UNKNOWN = GenericResult::e_UNKNOWN
- , e_TIMEOUT = GenericResult::e_TIMEOUT
- , e_NOT_CONNECTED = GenericResult::e_NOT_CONNECTED
- , e_CANCELED = GenericResult::e_CANCELED
- , e_NOT_SUPPORTED = GenericResult::e_NOT_SUPPORTED
- , e_REFUSED = GenericResult::e_REFUSED
- , e_INVALID_ARGUMENT = GenericResult::e_INVALID_ARGUMENT
- , e_NOT_READY = GenericResult::e_NOT_READY
-
- // SPECIALIZED
- // ERRORS
- , e_LIMIT_MESSAGES = -100 // Messages limit reached
- , e_LIMIT_BYTES = -101 // Bytes limit reached
-
- // TBD:DEPRECATED >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >libbmq-1.3.5
- // The below 4 values are deprecated in favor of the above two ones
- , e_LIMIT_DOMAIN_MESSAGES = -100 // The domain is full (messages)
- , e_LIMIT_DOMAIN_BYTES = -101 // The domain is full (bytes)
- , e_LIMIT_QUEUE_MESSAGES = -102 // The queue is full (messages)
- , e_LIMIT_QUEUE_BYTES = -103 // The queue is full (bytes)
- // TBD:DEPRECATED >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >libbmq-1.3.5
- , e_STORAGE_FAILURE = -104 // The storage (on disk) is full
- };
-
- // CLASS METHODS
- static bsl::ostream& print(bsl::ostream& stream,
- AckResult::Enum value,
- int level = 0,
- int spacesPerLevel = 4);
- // Write the string representation of the specified enumeration 'value'
- // to the specified output 'stream', and return a reference to
- // 'stream'. Optionally specify an initial indentation 'level', whose
- // absolute value is incremented recursively for nested objects. If
- // 'level' is specified, optionally specify 'spacesPerLevel', whose
- // absolute value indicates the number of spaces per indentation level
- // for this and all of its nested objects. If 'level' is negative,
- // suppress indentation of the first line. If 'spacesPerLevel' is
- // negative, format the entire output on one line, suppressing all but
- // the initial indentation (as governed by 'level'). See 'toAscii' for
- // what constitutes the string representation of a
- // 'PublishResult::Enum' value.
-
- static const char *toAscii(AckResult::Enum value);
- // Return the non-modifiable string representation corresponding to the
- // specified enumeration 'value', if it exists, and a unique (error)
- // string otherwise. The string representation of 'value' matches its
- // corresponding enumerator name with the 'e_' prefix elided. Note
- // that specifying a 'value' that does not match any of the enumerators
- // will result in a string representation that is distinct from any of
- // those corresponding to the enumerators, but is otherwise
- // unspecified.
-
- static bool fromAscii(AckResult::Enum *out,
- const bslstl::StringRef& str);
- // Return true and fills the specified 'out' with the enum value
- // corresponding to the specified 'str', if valid, or return false and
- // leave 'out' untouched if 'str' doesn't correspond to any value of
- // the enum.
-};
-
-// FREE OPERATORS
-bsl::ostream& operator<<(bsl::ostream& stream,
- AckResult::Enum value);
- // Format the specified 'value' to the specified output 'stream' and return
- // a reference to the modifiable 'stream'.
-
-
- // =================
- // struct PostResult
- // =================
-
-struct PostResult {
- // This enum represents the result code status of a post message
-
- // TYPES
- enum Enum {
- // GENERIC
- e_SUCCESS = GenericResult::e_SUCCESS
- , e_UNKNOWN = GenericResult::e_UNKNOWN
- , e_TIMEOUT = GenericResult::e_TIMEOUT
- , e_NOT_CONNECTED = GenericResult::e_NOT_CONNECTED
- , e_CANCELED = GenericResult::e_CANCELED
- , e_NOT_SUPPORTED = GenericResult::e_NOT_SUPPORTED
- , e_REFUSED = GenericResult::e_REFUSED
- , e_INVALID_ARGUMENT = GenericResult::e_INVALID_ARGUMENT
- , e_NOT_READY = GenericResult::e_NOT_READY
-
- // SPECIALIZED
- // WARNINGS
- , e_BW_LIMIT = 100 // The application has been posting too much
- // data, and the IO or broker are temporarily
- // rejecting new messages.
- };
-
- // CLASS METHODS
- static bsl::ostream& print(bsl::ostream& stream,
- PostResult::Enum value,
- int level = 0,
- int spacesPerLevel = 4);
- // Write the string representation of the specified enumeration 'value'
- // to the specified output 'stream', and return a reference to
- // 'stream'. Optionally specify an initial indentation 'level', whose
- // absolute value is incremented recursively for nested objects. If
- // 'level' is specified, optionally specify 'spacesPerLevel', whose
- // absolute value indicates the number of spaces per indentation level
- // for this and all of its nested objects. If 'level' is negative,
- // suppress indentation of the first line. If 'spacesPerLevel' is
- // negative, format the entire output on one line, suppressing all but
- // the initial indentation (as governed by 'level'). See 'toAscii' for
- // what constitutes the string representation of a
- // 'PublishResult::Enum' value.
-
- static const char *toAscii(PostResult::Enum value);
- // Return the non-modifiable string representation corresponding to the
- // specified enumeration 'value', if it exists, and a unique (error)
- // string otherwise. The string representation of 'value' matches its
- // corresponding enumerator name with the 'e_' prefix elided. Note
- // that specifying a 'value' that does not match any of the enumerators
- // will result in a string representation that is distinct from any of
- // those corresponding to the enumerators, but is otherwise
- // unspecified.
-
- static bool fromAscii(PostResult::Enum *out,
- const bslstl::StringRef& str);
- // Return true and fills the specified 'out' with the enum value
- // corresponding to the specified 'str', if valid, or return false and
- // leave 'out' untouched if 'str' doesn't correspond to any value of
- // the enum.
-};
-
-// FREE OPERATORS
-bsl::ostream& operator<<(bsl::ostream& stream,
- PostResult::Enum value);
- // Format the specified 'value' to the specified output 'stream' and return
- // a reference to the modifiable 'stream'.
-
-} // close package namespace
-
-
-// ============================================================================
-// INLINE DEFINITIONS
-// ============================================================================
-
-
- // --------------------
- // struct GenericResult
- // --------------------
-
-inline
-bsl::ostream&
-bmqt::operator<<(bsl::ostream& stream,
- bmqt::GenericResult::Enum value)
-{
- return bmqt::GenericResult::print(stream, value, 0 , -1);
-}
-
-
- // ----------------------
- // struct OpenQueueResult
- // ----------------------
-
-inline
-bsl::ostream&
-bmqt::operator<<(bsl::ostream& stream,
- bmqt::OpenQueueResult::Enum value)
-{
- return bmqt::OpenQueueResult::print(stream, value, 0 , -1);
-}
-
- // ---------------------------
- // struct ConfigureQueueResult
- // ---------------------------
-
-inline
-bsl::ostream&
-bmqt::operator<<(bsl::ostream& stream,
- bmqt::ConfigureQueueResult::Enum value)
-{
- return bmqt::ConfigureQueueResult::print(stream, value, 0 , -1);
-}
-
- // -----------------------
- // struct CloseQueueResult
- // -----------------------
-
-inline
-bsl::ostream&
-bmqt::operator<<(bsl::ostream& stream,
- bmqt::CloseQueueResult::Enum value)
-{
- return bmqt::CloseQueueResult::print(stream, value, 0 , -1);
-}
-
- // -------------------------
- // struct EventBuilderResult
- // -------------------------
-
-inline
-bsl::ostream&
-bmqt::operator<<(bsl::ostream& stream,
- bmqt::EventBuilderResult::Enum value)
-{
- return bmqt::EventBuilderResult::print(stream, value, 0 , -1);
-}
-
- // ----------------
- // struct AckResult
- // ----------------
-
-inline
-bsl::ostream&
-bmqt::operator<<(bsl::ostream& stream,
- bmqt::AckResult::Enum value)
-{
- return bmqt::AckResult::print(stream, value, 0 , -1);
-}
-
-
- // -----------------
- // struct PostResult
- // -----------------
-
-inline
-bsl::ostream&
-bmqt::operator<<(bsl::ostream& stream,
- bmqt::PostResult::Enum value)
-{
- return bmqt::PostResult::print(stream, value, 0 , -1);
-}
-
-} // close enterprise namespace
-
-#endif
-
-Generated on Thu Jun 15 2023 11:58:51 by
-
- 1.7.1
-
-
diff --git a/docs/docs/apidocs/cpp_apidocs/bmqt__sessioneventtype_8h_source.html b/docs/docs/apidocs/cpp_apidocs/bmqt__sessioneventtype_8h_source.html
deleted file mode 100644
index 8583e1795..000000000
--- a/docs/docs/apidocs/cpp_apidocs/bmqt__sessioneventtype_8h_source.html
+++ /dev/null
@@ -1,210 +0,0 @@
-
-
-Bloomberg Development Environment
-
-
-// Copyright 2014-2023 Bloomberg Finance L.P.
-// SPDX-License-Identifier: Apache-2.0
-//
-// Licensed under the Apache License, Version 2.0 (the "License");
-// you may not use this file except in compliance with the License.
-// You may obtain a copy of the License at
-//
-// http://www.apache.org/licenses/LICENSE-2.0
-//
-// Unless required by applicable law or agreed to in writing, software
-// distributed under the License is distributed on an "AS IS" BASIS,
-// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-// See the License for the specific language governing permissions and
-// limitations under the License.
-
-// bmqt_sessioneventtype.h -*-C++-*-
-#ifndef INCLUDED_BMQT_SESSIONEVENTTYPE
-#define INCLUDED_BMQT_SESSIONEVENTTYPE
-
-//@PURPOSE: Provide an enumeration for the different types of session events.
-//
-//@CLASSES:
-// bmqt::SessionEventType: Enumeration for the types of session events.
-//
-//@DESCRIPTION: 'bmqt::SessionEventType' is an enumeration for the different
-// types of session events.
-//
-//: o !CONNECTED!: The connection with the broker is established, this event is
-//: only fired once (if for any reason the connection gets lost and
-//: automatically reconnected, this will emit a 'CONNECTION_RESTORED' event).
-//
-//: o !DISCONNECTED!: The connection with the broker is terminated (after the
-//: user called stop on the session). This is the last event that will be
-//: delivered.
-//
-//: o !CONNECTION_LOST!: The session was connected to the broker, but that
-//: connection dropped.
-//
-//: o !RECONNECTED!: The connection to the broker has been re-established.
-//: This event is followed by zero or more 'QUEUE_REOPEN_RESULT' events, and
-//: one 'STATE_RESTORED' event.
-//
-//: o !STATE_RESTORED!: Session's state has been restored after connection
-//: has been re-established with the broker. This event is preceded by one
-//: 'RECONNECTED' event, and zero or more 'QUEUE_REOPEN_RESULT' events.
-//
-//: o !CONNECTION_TIMEOUT!: The connection to the broker has timedout.
-//
-//: o !QUEUE_OPEN_RESULT!: Indicates the result of an 'openQueue' operation.
-//
-//: o !QUEUE_REOPEN_RESULT!: Indicates the result of an 'openQueue' operation,
-//: which happens when the connection to the broker has been restored and
-//: queues previously opened have been automatically reopened. This event is
-//: preceded by a 'RECONNECTED' event and followed by zero or more
-//: 'QUEUE_REOPEN_RESULT' events, and one 'STATE_RESTORED' event.
-//
-//: o !QUEUE_CLOSE_RESULT!: Indicates the result of a 'closeQueue' operation
-//
-//: o !SLOWCONSUMER_NORMAL!: Notifies that the EventQueue is back to its low
-//: watermark level.
-//
-//: o !SLOWCONSUMER_HIGHWATERMARK!: Notifies that events are accumulating in
-//: the EventQueue, which has now reached it's high watermark level.
-//
-//: o !QUEUE_CONFIGURE_RESULT!: Indicates the result of a 'configureQueue'
-//: operation.
-//
-//: o !HOST_UNHEALTHY!: Indicates the host has become unhealthy. Only issued if
-// a 'bmqpi::HostHealthMonitor' has been installed to the session, via the
-// 'bmqt::SessionOptions' object.
-//
-//: o !HOST_HEALTH_RESTORED!: Indicates the health of the host has restored,
-// and all queues have resumed operation. Following a Host Health incident,
-// this indicates that the application has resumed normal operation.
-//
-//: o !QUEUE_SUSPENDED!: Indicates that an open queue has suspended operation:
-// * Consumers are configured to receive no more messages from broker
-// (i.e., maxUnconfirmedMessages := 0, maxUnconfirmedBytes := 0,
-// consumerPriority := INT_MIN).
-// * Attempts to pack messages targeting queue will be rejected by
-// 'bmqa::MessageEventBuilder::pack()'. Clients may still attempt to POST
-// existing packed events.
-// * Attempts by client to reconfigure queue will not take effect until the
-// queue has resumed.
-//
-//: o !QUEUE_RESUMED!: Indicates that a suspended queue has resumed normal
-// operation (i.e., effects of QUEUE_SUSPENDED state no longer apply).
-//
-//: o !ERROR!: Indicates a generic error.
-//
-//: o !TIMEOUT! Indicates that the specified operation has timed out.
-//
-//: o !CANCELED!: Indicates that the specified operation was canceled.
-//
-
-// BMQ
-#include <bmqscm_version.h>
-
-// BDE
-#include <bsl_ostream.h>
-#include <bsl_string.h>
-
-namespace BloombergLP {
-namespace bmqt {
-
- // =======================
- // struct SessionEventType
- // =======================
-
-struct SessionEventType {
- // Enumeration for the types of session events
-
- // TYPES
- enum Enum {
- e_ERROR = -1 // Generic error
- , e_TIMEOUT = -2 // Time out of the operation
- , e_CANCELED = -3 // The operation was canceled
- , e_UNDEFINED = 0
- , e_CONNECTED = 1 // Session started
- , e_DISCONNECTED = 2 // Session terminated
- , e_CONNECTION_LOST = 3 // Lost connection to the broker
- , e_RECONNECTED = 4 // Reconnected with the broker
- , e_STATE_RESTORED = 5 // Client's state has been restored
- , e_CONNECTION_TIMEOUT = 6 // The connection to broker timedOut
- , e_QUEUE_OPEN_RESULT = 7 // Result of openQueue operation
- , e_QUEUE_REOPEN_RESULT = 8 // Result of re-openQueue operation
- , e_QUEUE_CLOSE_RESULT = 9 // Result of closeQueue operation
- , e_SLOWCONSUMER_NORMAL = 10 // EventQueue is at lowWatermark
- , e_SLOWCONSUMER_HIGHWATERMARK = 11 // EventQueue is at highWatermark
- , e_QUEUE_CONFIGURE_RESULT = 12 // Result of configureQueue
- , e_HOST_UNHEALTHY = 13 // Host has become unhealthy
- , e_HOST_HEALTH_RESTORED = 14 // Host's health has been restored
- , e_QUEUE_SUSPENDED = 15 // Queue has suspended operation
- , e_QUEUE_RESUMED = 16 // Queue has resumed operation
- };
-
- // CLASS METHODS
- static bsl::ostream& print(bsl::ostream& stream,
- SessionEventType::Enum value,
- int level = 0,
- int spacesPerLevel = 4);
- // Write the string representation of the specified enumeration 'value'
- // to the specified output 'stream', and return a reference to
- // 'stream'. Optionally specify an initial indentation 'level', whose
- // absolute value is incremented recursively for nested objects. If
- // 'level' is specified, optionally specify 'spacesPerLevel', whose
- // absolute value indicates the number of spaces per indentation level
- // for this and all of its nested objects. If 'level' is negative,
- // suppress indentation of the first line. If 'spacesPerLevel' is
- // negative, format the entire output on one line, suppressing all but
- // the initial indentation (as governed by 'level'). See 'toAscii' for
- // what constitutes the string representation of a
- // 'SessionEventType::Value' value.
-
- static const char *toAscii(SessionEventType::Enum value);
- // Return the non-modifiable string representation corresponding to the
- // specified enumeration 'value', if it exists, and a unique (error)
- // string otherwise. The string representation of 'value' matches its
- // corresponding enumerator name with the 'BMQT_' prefix elided. Note
- // that specifying a 'value' that does not match any of the enumerators
- // will result in a string representation that is distinct from any of
- // those corresponding to the enumerators, but is otherwise
- // unspecified.
-
- static bool fromAscii(SessionEventType::Enum *out,
- const bslstl::StringRef& str);
- // Return true and fills the specified 'out' with the enum value
- // corresponding to the specified 'str', if valid, or return false and
- // leave 'out' untouched if 'str' doesn't correspond to any value of
- // the enum.
-
-};
-
-// FREE OPERATORS
-bsl::ostream& operator<<(bsl::ostream& stream,
- SessionEventType::Enum value);
- // Format the specified 'value' to the specified output 'stream' and return
- // a reference to the modifiable 'stream'.
-
-} // close package namespace
-
-
-// ============================================================================
-// INLINE DEFINITIONS
-// ============================================================================
-
- // -----------------------
- // struct SessionEventType
- // -----------------------
-
-// FREE OPERATORS
-inline
-bsl::ostream&
-bmqt::operator<<(bsl::ostream& stream,
- bmqt::SessionEventType::Enum value)
-{
- return SessionEventType::print(stream, value, 0 , -1);
-}
-
-} // close enterprise namespace
-
-#endif
-
-Generated on Thu Jun 15 2023 11:58:51 by
-
- 1.7.1
-
-
diff --git a/docs/docs/apidocs/cpp_apidocs/bmqt__sessionoptions_8h_source.html b/docs/docs/apidocs/cpp_apidocs/bmqt__sessionoptions_8h_source.html
deleted file mode 100644
index 0f7d435a7..000000000
--- a/docs/docs/apidocs/cpp_apidocs/bmqt__sessionoptions_8h_source.html
+++ /dev/null
@@ -1,714 +0,0 @@
-
-
-Bloomberg Development Environment
-
-
-// Copyright 2014-2023 Bloomberg Finance L.P.
-// SPDX-License-Identifier: Apache-2.0
-//
-// Licensed under the Apache License, Version 2.0 (the "License");
-// you may not use this file except in compliance with the License.
-// You may obtain a copy of the License at
-//
-// http://www.apache.org/licenses/LICENSE-2.0
-//
-// Unless required by applicable law or agreed to in writing, software
-// distributed under the License is distributed on an "AS IS" BASIS,
-// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-// See the License for the specific language governing permissions and
-// limitations under the License.
-
-// bmqt_sessionoptions.h -*-C++-*-
-#ifndef INCLUDED_BMQT_SESSIONOPTIONS
-#define INCLUDED_BMQT_SESSIONOPTIONS
-
-//@PURPOSE: Provide a value-semantic type to configure session with the broker.
-//
-//@CLASSES: bmqt::SessionOptions: options to configure a session with a
-// BlazingMQ broker.
-//
-//@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
-// 'Session'; the default parameters are fine.
-//
-// The following parameters are supported:
-//: o !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:
-//: o an explicit hostname or 'localhost'
-//: o an ip, example 10.11.12.13
-//: o 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
-//: 'SessionOptions' and use the value from this environment variable
-//: instead.
-//:
-//: o !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.
-//:
-//: o !numProcessingThreads!:
-//: Number of threads to use for processing events. Default is 1. Note
-//: that this setting has an effect only if providing a
-//: 'SessionEventHandler' to the session.
-//:
-//: o !blobBufferSize!:
-//: Size (in bytes) of the blob buffers to use. Default value is 4k.
-//:
-//: o !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'.
-//:
-//: o !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].
-//:
-//: o !connectTimeout!,
-//: o !disconnetTimeout!,
-//: o !openQueueTimeout!,
-//: o !configureQueueTimeout!,
-//: o !closeQueueTimeout!,
-//: Default timeout to use for various operations.
-//:
-//: o !eventQueueLowWatermark!,
-//: o !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.
-//:
-//: o !hostHealthMonitor!:
-//: Optional instance of a class derived from 'bmqpi::HostHealthMonitor',
-//: responsible for notifying the '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.
-//:
-//: o !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).
-//
-
-
-// BMQ
-#include <bmqscm_version.h>
-
-// BDE
-#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>
-
-namespace BloombergLP {
-
-// FORWARD DECLARATIONS
-namespace bmqpi { class DTContext; }
-namespace bmqpi { class DTTracer; }
-namespace bmqpi { class HostHealthMonitor; }
-
-namespace bmqt {
-
-
- // ====================
- // class SessionOptions
- // ====================
-
-class SessionOptions {
- // value-semantic type for options to configure a session with a BlazingMQ
- // broker
-
- public:
- // CONSTANTS
- static const char k_BROKER_DEFAULT_URI[];
- // Default URI of the 'bmqbrkr' to connect to.
-
- static const int k_BROKER_DEFAULT_PORT = 30114;
- // Default port the 'bmqbrkr' is listening to for client
- // to connect.
-
- static const int k_QUEUE_OPERATION_DEFAULT_TIMEOUT =
- 5 * bdlt::TimeUnitRatio::k_SECONDS_PER_MINUTE;
- // The default, and minimum recommended, value for queue
- // operations (open, configure, close).
-
- private:
- // DATA
- bsl::string d_brokerUri;
- // URI of the broker to connect to (ex:
- // 'tcp://localhost:30114'). Default
- // is to connect to the local broker.
-
- bsl::string d_processNameOverride;
- // If not empty, use this value for the
- // processName in the identity message
- // (useful for scripted language
- // bindings).
-
- int d_numProcessingThreads;
- // Number of processing threads.
- // Default is 1 thread.
-
- int d_blobBufferSize;
- // Size of the blobs buffer.
-
- bsls::Types::Int64 d_channelHighWatermark;
- // Write cache high watermark to use on
- // the channel
-
- bsls::TimeInterval d_statsDumpInterval;
- // Interval at which to dump stats to
- // log file (0 to disable dump)
-
- bsls::TimeInterval d_connectTimeout;
-
- bsls::TimeInterval d_disconnectTimeout;
-
- bsls::TimeInterval d_openQueueTimeout;
-
- bsls::TimeInterval d_configureQueueTimeout;
-
- bsls::TimeInterval d_closeQueueTimeout;
- // Timeout for operations of the
- // corresponding type.
-
- int d_eventQueueLowWatermark;
-
- int d_eventQueueHighWatermark;
- // Parameters to configure the
- // EventQueue.
-
- int d_eventQueueSize;
- // DEPRECATED: This parameter is no
- // longer relevant and will be removed
- // in future release of libbmq.
-
- bsl::shared_ptr<bmqpi::HostHealthMonitor> d_hostHealthMonitor_sp;
-
- bsl::shared_ptr<bmqpi::DTContext> d_dtContext_sp;
- bsl::shared_ptr<bmqpi::DTTracer> d_dtTracer_sp;
-
- public:
- // TRAITS
- BSLMF_NESTED_TRAIT_DECLARATION(SessionOptions, bslma::UsesBslmaAllocator)
-
- // CREATORS
- explicit SessionOptions(bslma::Allocator *allocator = 0);
- // Create a new SessionOptions using the optionally specified
- // 'allocator'.
-
- SessionOptions(const SessionOptions& other,
- bslma::Allocator *allocator = 0);
- // Create a new SessionOptions by copying values from the specified
- // 'other', using the optionally specified 'allocator'.
-
- // MANIPULATORS
- SessionOptions& setBrokerUri(const bslstl::StringRef& value);
- // Set the broker URI to the specified 'value'.
-
- SessionOptions&
- setProcessNameOverride(const bslstl::StringRef& value);
- // Set an override of the proces name to the specified 'value'.
-
- SessionOptions& setNumProcessingThreads(int value);
- // Set the number of processing threads to the specified 'value'.
-
- SessionOptions& setBlobBufferSize(int value);
- // Set the specified 'value' for the size of blobs buffers.
-
- SessionOptions& setChannelHighWatermark(bsls::Types::Int64 value);
- // Set the specified 'value' (in bytes) for the channel high
- // watermark. The behavior is undefined unless
- // '8 * 1024 * 1024 < value'.
-
- SessionOptions& setStatsDumpInterval(const bsls::TimeInterval& value);
- // Set the statsDumpInterval to the specified 'value'. The behavior is
- // undefined unless 'value' is a multiple of 30s and less than 60
- // minutes.
-
- SessionOptions& setConnectTimeout(const bsls::TimeInterval& value);
- SessionOptions& setDisconnectTimeout(const bsls::TimeInterval& value);
- SessionOptions& setOpenQueueTimeout(const bsls::TimeInterval& value);
- SessionOptions& setConfigureQueueTimeout(const bsls::TimeInterval& value);
- SessionOptions& setCloseQueueTimeout(const bsls::TimeInterval& value);
- // Set the timeout for operations of the corresponding type to the
- // specified 'value'.
-
- SessionOptions&
- setHostHealthMonitor(
- const bsl::shared_ptr<bmqpi::HostHealthMonitor>& monitor);
- // Set a 'HostHealthMonitor' object that will notify the session when
- // the health of the host has changed.
-
- SessionOptions&
- setTraceOptions(const bsl::shared_ptr<bmqpi::DTContext>& dtContext,
- const bsl::shared_ptr<bmqpi::DTTracer>& dtTracer);
- // Set the 'DTContext' and 'DTTracer' objects needed to integrate with
- // Distributed Trace frameworks. Either both arguments must point to
- // valid instances, or both must be empty shared_ptr's; if either is an
- // empty shared_ptr and the other is not, then behavior is undefined.
-
- SessionOptions& configureEventQueue(int queueSize,
- int lowWatermark,
- int highWatermark);
- // DEPRECATED: Use 'configureEventQueue(int lowWatermark,
- // int highWatermark)'
- // instead. This method will be marked as
- // 'BSLS_ANNOTATION_DEPRECATED' in future release of
- // libbmq.
-
- SessionOptions& configureEventQueue(int lowWatermark, int highWatermark);
- // Configure the EventQueue notification watermarks thresholds with the
- // specified 'lowWatermark' and 'highWatermark' value. Refer to the
- // component level documentation for explanation of those watermarks.
- // The behavior is undefined unless 'lowWatermark < highWatermark'.
-
- // ACCESSORS
- const bsl::string& brokerUri() const;
- // Get the broker URI.
-
- const bsl::string& processNameOverride() const;
- // Return the process name override.
-
- int numProcessingThreads() const;
- // Get the number of processing threads.
-
- int blobBufferSize() const;
- // Get the size of the blobs buffer.
-
- bsls::Types::Int64 channelHighWatermark() const;
- // Get the channel high watermark.
-
- const bsls::TimeInterval& statsDumpInterval() const;
- // Get the stats dump interval.
-
- const bsls::TimeInterval& connectTimeout() const;
- const bsls::TimeInterval& disconnectTimeout() const;
- const bsls::TimeInterval& openQueueTimeout() const;
- const bsls::TimeInterval& configureQueueTimeout() const;
- const bsls::TimeInterval& closeQueueTimeout() const;
- // Get the timeout for the operations of the corresponding type.
-
- const bsl::shared_ptr<bmqpi::HostHealthMonitor>& hostHealthMonitor() const;
-
- const bsl::shared_ptr<bmqpi::DTContext>& traceContext() const;
- // Get the Distributed Trace context object.
-
- const bsl::shared_ptr<bmqpi::DTTracer>& tracer() const;
- // Get the Distributed Trace tracer object.
-
- int eventQueueLowWatermark() const;
- int eventQueueHighWatermark() const;
-
- int eventQueueSize() const;
- // DEPRECATED: This parameter is no longer relevant and will be removed
- // in future release of libbmq.
-
- bsl::ostream& print(bsl::ostream& stream,
- int level = 0,
- int spacesPerLevel = 4) const;
- // Format this object to the specified output 'stream' at the (absolute
- // value of) the optionally specified indentation 'level' and return a
- // reference to 'stream'. If 'level' is specified, optionally specify
- // 'spacesPerLevel', the number of spaces per indentation level for
- // this and all of its nested objects. If 'level' is negative,
- // suppress indentation of the first line. If 'spacesPerLevel' is
- // negative format the entire output on one line, suppressing all but
- // the initial indentation (as governed by 'level'). If 'stream' is
- // not valid on entry, this operation has no effect.
-};
-
-// FREE OPERATORS
-bool operator==(const SessionOptions& lhs, const SessionOptions& rhs);
- // Return 'true' if the specified 'rhs' object contains the value of the
- // same type as contained in the specified 'lhs' object and the value
- // itself is the same in both objects, return false otherwise.
-
-bool operator!=(const SessionOptions& lhs, const SessionOptions& rhs);
- // Return 'false' if the specified 'rhs' object contains the value of the
- // same type as contained in the specified 'lhs' object and the value
- // itself is the same in both objects, return 'true' otherwise.
-
-bsl::ostream& operator<<(bsl::ostream& stream, const SessionOptions& rhs);
- // Format the specified 'rhs' to the specified output 'stream' and return a
- // reference to the modifiable 'stream'.
-
-
-// ============================================================================
-// INLINE DEFINITIONS
-// ============================================================================
-
-
- // --------------------
- // class SessionOptions
- // --------------------
-
-// MANIPULATORS
-inline
-SessionOptions&
-SessionOptions::setBrokerUri(const bslstl::StringRef& value)
-{
- d_brokerUri.assign(value.data(), value.length());
- return *this;
-}
-
-inline
-SessionOptions&
-SessionOptions::setProcessNameOverride(const bslstl::StringRef& value)
-{
- d_processNameOverride.assign(value.data(), value.length());
- return *this;
-}
-
-inline
-SessionOptions&
-SessionOptions::setNumProcessingThreads(int value)
-{
- d_numProcessingThreads = value;
- return *this;
-}
-
-inline
-SessionOptions&
-SessionOptions::setBlobBufferSize(int value)
-{
- d_blobBufferSize = value;
- return *this;
-}
-
-inline
-SessionOptions&
-SessionOptions::setChannelHighWatermark(bsls::Types::Int64 value)
-{
- // PRECONDITIONS
- BSLS_ASSERT_OPT(8 * 1024 * 1024 < value);
- // We reserve 4MB for control message (see
- // 'bmqimp::BrokerSession::k_CONTROL_DATA_WATERMARK_EXTRA') so make
- // sure the provided value is greater than it.
-
- d_channelHighWatermark = value;
- return *this;
-}
-
-inline
-SessionOptions&
-SessionOptions::setStatsDumpInterval(const bsls::TimeInterval& value)
-{
- // PRECONDITIONS
- BSLS_ASSERT_OPT( value.seconds() % 30 == 0
- && "value must be a multiple of 30s");
- BSLS_ASSERT_OPT( value.seconds()
- < bdlt::TimeUnitRatio::k_SECONDS_PER_HOUR
- && "value must be < 10 min");
-
- d_statsDumpInterval = value;
- return *this;
-}
-
-inline
-SessionOptions&
-SessionOptions::setConnectTimeout(const bsls::TimeInterval& value)
-{
- d_connectTimeout = value;
- return *this;
-}
-
-inline
-SessionOptions&
-SessionOptions::setDisconnectTimeout(const bsls::TimeInterval& value)
-{
- d_disconnectTimeout = value;
- return *this;
-}
-
-inline
-SessionOptions&
-SessionOptions::setOpenQueueTimeout(const bsls::TimeInterval& value)
-{
- d_openQueueTimeout = value;
- return *this;
-}
-
-inline
-SessionOptions&
-SessionOptions::setConfigureQueueTimeout(const bsls::TimeInterval& value)
-{
- d_configureQueueTimeout = value;
- return *this;
-}
-
-inline
-SessionOptions&
-SessionOptions::setCloseQueueTimeout(const bsls::TimeInterval& value)
-{
- d_closeQueueTimeout = value;
- return *this;
-}
-
-inline
-SessionOptions&
-SessionOptions::setHostHealthMonitor(
- const bsl::shared_ptr<bmqpi::HostHealthMonitor>& monitor)
-{
- d_hostHealthMonitor_sp = monitor;
- return *this;
-}
-
-inline
-SessionOptions&
-SessionOptions::setTraceOptions(
- const bsl::shared_ptr<bmqpi::DTContext>& context,
- const bsl::shared_ptr<bmqpi::DTTracer>& tracer)
-{
- BSLS_ASSERT_OPT((context && tracer) || (!context && !tracer));
-
- d_dtContext_sp = context;
- d_dtTracer_sp = tracer;
- return *this;
-}
-
-inline
-SessionOptions&
-SessionOptions::configureEventQueue(int queueSize,
- int lowWatermark,
- int highWatermark)
-{
- d_eventQueueSize = queueSize;
- return configureEventQueue(lowWatermark, highWatermark);
-}
-
-inline
-SessionOptions&
-SessionOptions::configureEventQueue(int lowWatermark,
- int highWatermark)
-{
- // PRECONDITIONS
- BSLS_ASSERT_OPT(lowWatermark < highWatermark);
-
- d_eventQueueLowWatermark = lowWatermark;
- d_eventQueueHighWatermark = highWatermark;
-
- return *this;
-}
-
-// ACCESSORS
-inline
-const bsl::string&
-SessionOptions::brokerUri() const
-{
- return d_brokerUri;
-}
-
-inline
-const bsl::string&
-SessionOptions::processNameOverride() const
-{
- return d_processNameOverride;
-}
-
-inline
-int
-SessionOptions::numProcessingThreads() const
-{
- return d_numProcessingThreads;
-}
-
-inline
-int
-SessionOptions::blobBufferSize() const
-{
- return d_blobBufferSize;
-}
-
-inline
-bsls::Types::Int64
-SessionOptions::channelHighWatermark() const
-{
- return d_channelHighWatermark;
-}
-
-inline
-const bsls::TimeInterval&
-SessionOptions::statsDumpInterval() const
-{
- return d_statsDumpInterval;
-}
-
-inline
-const bsls::TimeInterval&
-SessionOptions::connectTimeout() const
-{
- return d_connectTimeout;
-}
-
-inline
-const bsls::TimeInterval&
-SessionOptions::disconnectTimeout() const
-{
- return d_disconnectTimeout;
-}
-
-inline
-const bsls::TimeInterval&
-SessionOptions::openQueueTimeout() const
-{
- return d_openQueueTimeout;
-}
-
-inline
-const bsls::TimeInterval&
-SessionOptions::configureQueueTimeout() const
-{
- return d_configureQueueTimeout;
-}
-
-inline
-const bsls::TimeInterval&
-SessionOptions::closeQueueTimeout() const
-{
- return d_closeQueueTimeout;
-}
-
-inline
-const bsl::shared_ptr<bmqpi::HostHealthMonitor>&
-SessionOptions::hostHealthMonitor() const
-{
- return d_hostHealthMonitor_sp;
-}
-
-inline
-const bsl::shared_ptr<bmqpi::DTContext>&
-SessionOptions::traceContext() const
-{
- return d_dtContext_sp;
-}
-
-inline
-const bsl::shared_ptr<bmqpi::DTTracer>&
-SessionOptions::tracer() const
-{
- return d_dtTracer_sp;
-}
-
-inline
-int
-SessionOptions::eventQueueLowWatermark() const
-{
- return d_eventQueueLowWatermark;
-}
-
-inline
-int
-SessionOptions::eventQueueHighWatermark() const
-{
- return d_eventQueueHighWatermark;
-}
-
-inline
-int
-SessionOptions::eventQueueSize() const
-{
- return d_eventQueueSize;
-}
-
-} // close package namespace
-
- // --------------------
- // class SessionOptions
- // --------------------
-
-inline
-bool
-bmqt::operator==(const bmqt::SessionOptions& lhs,
- const bmqt::SessionOptions& rhs)
-{
- return lhs.brokerUri() == rhs.brokerUri()
- && lhs.numProcessingThreads() == rhs.numProcessingThreads()
- && lhs.blobBufferSize() == rhs.blobBufferSize()
- && lhs.channelHighWatermark() == rhs.channelHighWatermark()
- && lhs.statsDumpInterval() == rhs.statsDumpInterval()
- && lhs.connectTimeout() == rhs.connectTimeout()
- && lhs.openQueueTimeout() == rhs.openQueueTimeout()
- && lhs.configureQueueTimeout() == rhs.configureQueueTimeout()
- && lhs.closeQueueTimeout() == rhs.closeQueueTimeout()
- && lhs.eventQueueLowWatermark() == rhs.eventQueueLowWatermark()
- && lhs.eventQueueHighWatermark() == rhs.eventQueueHighWatermark()
- && lhs.hostHealthMonitor() == rhs.hostHealthMonitor()
- && lhs.traceContext() == rhs.traceContext()
- && lhs.tracer() == rhs.tracer();
-}
-
-inline
-bool
-bmqt::operator!=(const bmqt::SessionOptions& lhs,
- const bmqt::SessionOptions& rhs)
-{
- return lhs.brokerUri() != rhs.brokerUri()
- || lhs.numProcessingThreads() != rhs.numProcessingThreads()
- || lhs.blobBufferSize() != rhs.blobBufferSize()
- || lhs.channelHighWatermark() != rhs.channelHighWatermark()
- || lhs.statsDumpInterval() != rhs.statsDumpInterval()
- || lhs.connectTimeout() != rhs.connectTimeout()
- || lhs.openQueueTimeout() != rhs.openQueueTimeout()
- || lhs.configureQueueTimeout() != rhs.configureQueueTimeout()
- || lhs.closeQueueTimeout() != rhs.closeQueueTimeout()
- || lhs.eventQueueLowWatermark() != rhs.eventQueueLowWatermark()
- || lhs.eventQueueHighWatermark() != rhs.eventQueueHighWatermark()
- || lhs.hostHealthMonitor() != rhs.hostHealthMonitor()
- || lhs.traceContext() != rhs.traceContext()
- || lhs.tracer() != rhs.tracer();
-}
-
-inline
-bsl::ostream&
-bmqt::operator<<(bsl::ostream& stream,
- const bmqt::SessionOptions& rhs)
-{
- return rhs.print(stream, 0, -1);
-}
-
-} // close enterprise namespace
-
-#endif
-
-Generated on Thu Jun 15 2023 11:58:51 by
-
- 1.7.1
-
-
diff --git a/docs/docs/apidocs/cpp_apidocs/bmqt__subscription_8h_source.html b/docs/docs/apidocs/cpp_apidocs/bmqt__subscription_8h_source.html
deleted file mode 100644
index 88d778282..000000000
--- a/docs/docs/apidocs/cpp_apidocs/bmqt__subscription_8h_source.html
+++ /dev/null
@@ -1,565 +0,0 @@
-
-
-Bloomberg Development Environment
-
-
-// Copyright 2022-2023 Bloomberg Finance L.P.
-// SPDX-License-Identifier: Apache-2.0
-//
-// Licensed under the Apache License, Version 2.0 (the "License");
-// you may not use this file except in compliance with the License.
-// You may obtain a copy of the License at
-//
-// http://www.apache.org/licenses/LICENSE-2.0
-//
-// Unless required by applicable law or agreed to in writing, software
-// distributed under the License is distributed on an "AS IS" BASIS,
-// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-// See the License for the specific language governing permissions and
-// limitations under the License.
-
-// bmqt_subscription.h -*-C++-*-
-#ifndef INCLUDED_BMQT_SUBSCRIPTION
-#define INCLUDED_BMQT_SUBSCRIPTION
-
-//@PURPOSE: Provide a value-semantic types for subscription related API.
-//
-//@CLASSES:
-// bmqt::Subscription_Handle: uniquely identifies Subscription
-// bmqt::Subscription_Expression: Subscription criteria
-// bmqt::Subscription: Subscription parameters
-//
-//@DESCRIPTION: 'bmqt::Subscription' provides a value-semantic type carried
-// by 'bmqt::QueueOptions', when opening and configuring a queue.
-//
-//@NOTE: Experimental. Do not use until this feature is announced.
-//
-
-
-// BMQ
-#include <bmqscm_version.h>
-#include <bmqt_correlationid.h>
-
-//BDE
-#include <bsl_optional.h>
-#include <bsl_ostream.h>
-#include <bsl_string.h>
-#include <bslim_printer.h>
-#include <bslma_allocator.h>
-#include <bsls_types.h>
-
-
-namespace BloombergLP {
-
-namespace bmqt {
-
-class QueueOptions;
- // =========================
- // class Subscription_Handle
- // =========================
-
-class SubscriptionHandle {
- // Value-semantic type for unique Subscription id.
- private:
- // PRIVATE DATA
- unsigned int d_id;
- // Internal, unique key
-
- const bmqt::CorrelationId d_correlationId;
- // User-specified, not required to be
- // unique
- private:
- // PRIVATE CLASS METHODS
- static unsigned int nextId();
-
- public:
- // CREATORS
- SubscriptionHandle(const bmqt::CorrelationId& cid);
- SubscriptionHandle(const SubscriptionHandle& other);
-
- // ACCESSORS
- const bmqt::CorrelationId& correlationId() const;
-
- unsigned int id() const;
-
- bsl::ostream& print(bsl::ostream& stream,
- int level = 0,
- int spacesPerLevel = 4) const;
- // Format this object to the specified output 'stream' at the (absolute
- // value of) the optionally specified indentation 'level' and return a
- // reference to 'stream'. If 'level' is specified, optionally specify
- // 'spacesPerLevel', the number of spaces per indentation level for
- // this and all of its nested objects. If 'level' is negative,
- // suppress indentation of the first line. If 'spacesPerLevel' is
- // negative format the entire output on one line, suppressing all but
- // the initial indentation (as governed by 'level'). If 'stream' is
- // not valid on entry, this operation has no effect.
-
- // FRIENDS
- friend bool operator<(const SubscriptionHandle& lhs,
- const SubscriptionHandle& rhs);
- friend bool operator==(const SubscriptionHandle& lhs,
- const SubscriptionHandle& rhs);
- friend bool operator!=(const SubscriptionHandle& lhs,
- const SubscriptionHandle& rhs);
-
- template <class HASH_ALGORITHM>
- friend void hashAppend(HASH_ALGORITHM& hashAlgo,
- const SubscriptionHandle& id);
-
- // Will only consider 'd_id' field when comparing 'lhs' and 'rhs'
-};
-
-class SubscriptionExpression {
- // Value-semantic type to carry Subscription criteria.
-
- public:
- // TYPES
- enum Enum {
- // Enum representing criteria format
- e_NONE = 0 // EMPTY
- , e_VERSION_1 = 1 // Simple Evaluator
- };
-
- private:
- bsl::string d_expression; // e.g., "firmId == foo"
-
- Enum d_version; // Required to support newer style
- // of expressions in future
-
- public:
- // CREATORS
- SubscriptionExpression();
- SubscriptionExpression(const bsl::string& expression, Enum version);
-
- // ACCESSORS
- const bsl::string& text() const;
-
- Enum version() const;
-
- bool isValid() const;
-
- bsl::ostream& print(bsl::ostream& stream,
- int level = 0,
- int spacesPerLevel = 4) const;
- // Format this object to the specified output 'stream' at the (absolute
- // value of) the optionally specified indentation 'level' and return a
- // reference to 'stream'. If 'level' is specified, optionally specify
- // 'spacesPerLevel', the number of spaces per indentation level for
- // this and all of its nested objects. If 'level' is negative,
- // suppress indentation of the first line. If 'spacesPerLevel' is
- // negative format the entire output on one line, suppressing all but
- // the initial indentation (as governed by 'level'). If 'stream' is
- // not valid on entry, this operation has no effect.
-};
-
-class Subscription {
- // Value-semantic type to carry Subscription parameters.
-
- public:
- // PUBLIC CONSTANTS
- static const int k_CONSUMER_PRIORITY_MIN;
- // Constant representing the minimum
- // valid consumer priority
-
- static const int k_CONSUMER_PRIORITY_MAX;
- // Constant representing the maximum
- // valid consumer priority
-
- static const int k_DEFAULT_MAX_UNCONFIRMED_MESSAGES;
- static const int k_DEFAULT_MAX_UNCONFIRMED_BYTES;
- static const int k_DEFAULT_CONSUMER_PRIORITY;
-
- private:
- // PRIVATE DATA
- bsl::optional<int> d_maxUnconfirmedMessages;
- // Maximum number of outstanding
- // messages that can be sent by the
- // broker without being confirmed.
-
- bsl::optional<int> d_maxUnconfirmedBytes;
- // Maximum accumulated bytes of all
- // outstanding messages that can be
- // sent by the broker without being
- // confirmed.
-
- bsl::optional<int> d_consumerPriority;
- // Priority of a consumer with respect
- // to delivery of messages
-
- SubscriptionExpression d_expression;
-
- public:
- // CREATORS
- Subscription();
-
- // Create a new Subscription
- Subscription(const Subscription& other);
- // Create a new Subscription by copying values from the specified
- // 'other'.
-
- // MANIPULATORS
- Subscription& setMaxUnconfirmedMessages(int value);
- // Set the maxUnconfirmedMessages to the specified 'value'. The
- // behavior is undefined unless 'value >= 0'. If the specified 'value'
- // is set to 0, it means that the consumer does not receive any
- // messages. This might be useful when the consumer is shutting down
- // and wants to process only pending messages, or when it is unable to
- // process new messages because of transient issues.
-
- Subscription& setMaxUnconfirmedBytes(int value);
- // Set the maxUnconfirmedBytes to the specified 'value'. The behavior
- // is undefined unless 'value >= 0'.
-
- Subscription& setConsumerPriority(int value);
- // Set the consumerPriority to the specified 'value'. The behavior is
- // undefined unless 'k_CONSUMER_PRIORITY_MIN <= value <=
- // k_CONSUMER_PRIORITY_MAX'
-
- Subscription& setExpression(const SubscriptionExpression& value);
-
- // ACCESSORS
- int maxUnconfirmedMessages() const;
- // Get the number for the maxUnconfirmedMessages parameter.
-
- int maxUnconfirmedBytes() const;
- // Get the number for the maxUnconfirmedBytes parameter.
-
- int consumerPriority() const;
- // Get the number for the consumerPriority parameter.
-
- const SubscriptionExpression& expression() const;
-
- bool hasMaxUnconfirmedMessages() const;
- // Returns whether 'maxUnconfirmedMessages' has been set for this
- // object, or whether it implicitly holds
- // 'k_DEFAULT_MAX_UNCONFIRMED_MESSAGES'.
-
- bool hasMaxUnconfirmedBytes() const;
- // Returns whether 'maxUnconfirmedBytes' has been set for this object,
- // or whether it implicitly holds 'k_DEFAULT_MAX_UNCONFIRMED_BYTES'.
-
- bool hasConsumerPriority() const;
- // Returns whether 'consumerPriority' has been set for this object, or
- // whether it implicitly holds 'k_DEFAULT_CONSUMER_PRIORITY'.
-
- bsl::ostream& print(bsl::ostream& stream,
- int level = 0,
- int spacesPerLevel = 4) const;
- // Format this object to the specified output 'stream' at the (absolute
- // value of) the optionally specified indentation 'level' and return a
- // reference to 'stream'. If 'level' is specified, optionally specify
- // 'spacesPerLevel', the number of spaces per indentation level for
- // this and all of its nested objects. If 'level' is negative,
- // suppress indentation of the first line. If 'spacesPerLevel' is
- // negative format the entire output on one line, suppressing all but
- // the initial indentation (as governed by 'level'). If 'stream' is
- // not valid on entry, this operation has no effect.
-};
-
-// FREE OPERATORS
-bsl::ostream& operator<<(bsl::ostream& stream, const Subscription& rhs);
- // Format the specified 'rhs' to the specified output 'stream' and return a
- // reference to the modifiable 'stream'.
-
-
-// ============================================================================
-// INLINE DEFINITIONS
-// ============================================================================
-
- // ----------------------
- // class Subscription_Handle
- // ----------------------
-
-inline
-SubscriptionHandle::SubscriptionHandle(const bmqt::CorrelationId& cid)
-: d_id(nextId())
-, d_correlationId(cid)
-{
- // NOTHING
-}
-
-inline
-SubscriptionHandle::SubscriptionHandle(const SubscriptionHandle& other)
-: d_id(other.d_id)
-, d_correlationId(other.d_correlationId)
-{
- // NOTHING
-}
-
-// ACCESSORS
-inline
-const bmqt::CorrelationId&
-SubscriptionHandle::correlationId() const
-{
- return d_correlationId;
-}
-
-inline
-unsigned int
-SubscriptionHandle::id() const
-{
- return d_id;
-}
-
-inline
-bsl::ostream&
-SubscriptionHandle::print(bsl::ostream& stream,
- int level,
- int spacesPerLevel) const
-{
- if (stream.bad()) {
- return stream; // RETURN
- }
-
- bslim::Printer printer(&stream, level, spacesPerLevel);
- printer.start();
-
- printer.printAttribute("id", d_id);
- printer.printAttribute("CorrelationId", d_correlationId);
-
- printer.end();
-
- return stream;
-}
- // ----------------------------
- // class SubscriptionExpression
- // ----------------------------
-inline
-SubscriptionExpression::SubscriptionExpression()
-: d_expression()
-, d_version(e_NONE)
-{
- // NOTHING
-}
-
-inline
-SubscriptionExpression::SubscriptionExpression(const bsl::string& expression,
- Enum version)
-: d_expression(expression)
-, d_version(version)
-{
- // NOTHING
-}
-
-inline
-const bsl::string&
-SubscriptionExpression::text() const
-{
- return d_expression;
-}
-
-inline
-SubscriptionExpression::Enum
-SubscriptionExpression::version() const
-{
- return d_version;
-}
-
-inline
-bool
-SubscriptionExpression::isValid() const
-{
- return
- d_expression.length() == 0 ? d_version == e_NONE : d_version > e_NONE;
-}
-
-inline
-bsl::ostream&
-SubscriptionExpression::print(bsl::ostream& stream,
- int level,
- int spacesPerLevel) const
-{
- if (stream.bad()) {
- return stream; // RETURN
- }
-
- bslim::Printer printer(&stream, level, spacesPerLevel);
- printer.start();
-
- printer.printAttribute("Expression", d_expression);
- printer.printAttribute("Version", d_version);
-
- printer.end();
-
- return stream;
-}
-
- // ----------------------
- // class Subscription
- // ----------------------
-
-inline
-Subscription::Subscription()
-: d_maxUnconfirmedMessages()
-, d_maxUnconfirmedBytes()
-, d_consumerPriority()
-, d_expression()
-{
- // NOTHING
-}
-
-inline
-Subscription::Subscription(const Subscription& other)
-: d_maxUnconfirmedMessages(other.d_maxUnconfirmedMessages)
-, d_maxUnconfirmedBytes(other.d_maxUnconfirmedBytes)
-, d_consumerPriority(other.d_consumerPriority)
-, d_expression(other.d_expression)
-{
- // NOTHING
-}
-
-inline
-bsl::ostream&
-Subscription::print(bsl::ostream& stream,
- int level,
- int spacesPerLevel) const
-{
- if (stream.bad()) {
- return stream; // RETURN
- }
-
- bslim::Printer printer(&stream, level, spacesPerLevel);
- printer.start();
- printer.printAttribute("maxUnconfirmedMessages", maxUnconfirmedMessages());
- printer.printAttribute("maxUnconfirmedBytes", maxUnconfirmedBytes());
- printer.printAttribute("consumerPriority", consumerPriority());
-
- d_expression.print(stream, level, spacesPerLevel);
-
- printer.end();
-
- return stream;
-}
-
-// MANIPULATORS
-inline
-Subscription&
-Subscription::setMaxUnconfirmedMessages(int value)
-{
- d_maxUnconfirmedMessages.emplace(value);
- return *this;
-}
-
-inline
-Subscription&
-Subscription::setMaxUnconfirmedBytes(int value)
-{
- d_maxUnconfirmedBytes.emplace(value);
- return *this;
-}
-
-inline
-Subscription&
-Subscription::setConsumerPriority(int value)
-{
- d_consumerPriority.emplace(value);
- return *this;
-}
-
-inline
-Subscription&
-Subscription::setExpression(const SubscriptionExpression& value)
-{
- d_expression = value;
- return *this;
-}
-
-// ACCESSORS
-inline
-int
-Subscription::maxUnconfirmedMessages() const
-{
- return d_maxUnconfirmedMessages.value_or(
- k_DEFAULT_MAX_UNCONFIRMED_MESSAGES);
-}
-
-inline
-int
-Subscription::maxUnconfirmedBytes() const
-{
- return d_maxUnconfirmedBytes.value_or(k_DEFAULT_MAX_UNCONFIRMED_BYTES);
-}
-
-inline
-int
-Subscription::consumerPriority() const
-{
- return d_consumerPriority.value_or(k_DEFAULT_CONSUMER_PRIORITY);
-}
-
-inline
-const SubscriptionExpression&
-Subscription::expression() const
-{
- return d_expression;
-}
-
-inline
-bool
-Subscription::hasMaxUnconfirmedMessages() const
-{
- return d_maxUnconfirmedMessages.has_value();
-}
-
-inline
-bool
-Subscription::hasMaxUnconfirmedBytes() const
-{
- return d_maxUnconfirmedBytes.has_value();
-}
-
-inline
-bool
-Subscription::hasConsumerPriority() const
-{
- return d_consumerPriority.has_value();
-}
-
-// FREE FUNCTIONS
-template <class HASH_ALGORITHM>
-void
-hashAppend(HASH_ALGORITHM& hashAlgo, const SubscriptionHandle& id)
- // Apply the specified 'hashAlgo' to the specified 'id'.
-{
- using bslh::hashAppend; // for ADL
- hashAppend(hashAlgo, id.d_id);
-}
-
-inline
-bool
-operator<(const SubscriptionHandle& lhs, const SubscriptionHandle& rhs)
-{
- return lhs.d_id < rhs.d_id;
-}
-
-inline
-bool
-operator==(const SubscriptionHandle& lhs, const SubscriptionHandle& rhs)
-{
- return lhs.d_id == rhs.d_id;
-}
-
-inline
-bool
-operator!=(const SubscriptionHandle& lhs, const SubscriptionHandle& rhs)
-{
- return lhs.d_id != rhs.d_id;
-}
-
-inline
-bsl::ostream&
-operator<<(bsl::ostream&stream, const Subscription& rhs)
-{
- return rhs.print(stream, 0, -1);
-}
-
-
-} // close package namespace
-
-} // close enterprise namespace
-
-#endif
-
-Generated on Thu Jun 15 2023 11:58:51 by
-
- 1.7.1
-
-
diff --git a/docs/docs/apidocs/cpp_apidocs/bmqt__uri_8h_source.html b/docs/docs/apidocs/cpp_apidocs/bmqt__uri_8h_source.html
deleted file mode 100644
index 3f1707d9f..000000000
--- a/docs/docs/apidocs/cpp_apidocs/bmqt__uri_8h_source.html
+++ /dev/null
@@ -1,604 +0,0 @@
-
-
-Bloomberg Development Environment
-
-
-// Copyright 2014-2023 Bloomberg Finance L.P.
-// SPDX-License-Identifier: Apache-2.0
-//
-// Licensed under the Apache License, Version 2.0 (the "License");
-// you may not use this file except in compliance with the License.
-// You may obtain a copy of the License at
-//
-// http://www.apache.org/licenses/LICENSE-2.0
-//
-// Unless required by applicable law or agreed to in writing, software
-// distributed under the License is distributed on an "AS IS" BASIS,
-// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-// See the License for the specific language governing permissions and
-// limitations under the License.
-
-// bmqt_uri.h -*-C++-*-
-#ifndef INCLUDED_BMQT_URI
-#define INCLUDED_BMQT_URI
-
-//@PURPOSE: Provide value-semantic type and utilities for a BlazingMQ queue
-//URI.
-//
-//@CLASSES:
-// bmqt::Uri : value-semantic type representing a URI
-// bmqt::UriParser : utility to parse a string into a URI
-// bmqt::UriBuilder : builder mechanism to create a URI
-//
-//@DESCRIPTION: This component provides a value-semantic type, 'bmqt::Uri'
-// representing a URI for a BlazingMQ queue. A 'bmqt:Uri' can be built by
-// parsing from a string representation, using the 'bmqt::UriParser', or built
-// using the 'bmqt::UriBuilder'.
-//
-//@SEE_ALSO:
-//----------
-// https://tools.ietf.org/html/rfc3986
-//
-///URI format
-///----------
-// In a nutshell, a URI representing an application queue managed by a
-// BlazingMQ broker on a given machine looks like one of the following:
-//..
-// bmq://ts.trades.myapp/my.queue
-// bmq://ts.trades.myapp.~bt/my.queue
-// bmq://ts.trades.myapp/my.queue?id=foo
-//..
-// where:
-//
-//: o The URI scheme is always "bmq".
-//
-//: o The URI authority is the name of BlazingMQ domain (such as
-// "ts.trades.myapp")
-//: as registered with the BlazingMQ infrastructure. The domain name may
-//: contain alphanumeric characters, dots and dashes (it has to match the
-//: following regular expression: '[-a-zA-Z0-9\\._]+'). The domain may be
-//: followed by an optional tier, introduced by the ".~" sequence and
-//: consisting of alphanumeric characters and dashes. The ".~" sequence is
-//: not part of the tier.
-//
-//: o The URI path is the name of the queue ("my.queue" above) and may contain
-//: alphanumeric characters, dashes, underscores and tild (it has to match
-//: the following regular expression: '[-a-zA-Z0-9_~\\.]+'). The queue name
-//: must be less than 'bmqt::Uri::k_QUEUENAME_MAX_LENGTH' characters long.
-//
-//: o The name of the queue ("my.queue" above) may contain alphanumeric
-//: characters and dots.
-//
-//: o The URI may contain an optional query with a key-value pair. Currently
-//: supported keys are:
-//: o !id!: the corresponding value represents a name that will be used by
-//: BlazingMQ broker to uniquely identify the client.
-//
-//: o The URI fragment part is currently unused.
-//
-///Usage Example 1
-///---------------
-// First, call the 'initialize' method of the 'UriParser'. This call is only
-// needed one time; you can call it when your task starts.
-//
-// Note that the 'bmq' library takes care of that, so users of 'bmq' don't
-// have to explicitly do it themselves.
-//..
-// bmqt::UriParser::initialize();
-//..
-// Then, parse a URI string created on the stack to populate a 'Uri' object.
-// The parse function takes an optional error string which is populated with a
-// short error message if the URI is not formatted correctly.
-//..
-// bsl::string input = "bmq://my.domain/queue";
-// bmqt::Uri uri(allocator);
-// bsl::string errorDescription;
-//
-// int rc = bmqt::UriParser::parse(&uri, &errorDescription, input);
-// if (rc != 0) {
-// BALL_LOG_ERROR << "Invalid URI [error: " << errorDescription << "]";
-// }
-// assert(rc == 0);
-// assert(error == "");
-// assert(uri.scheme() == "bmq");
-// assert(uri.domain() == "my.domain");
-// assert(uri.queue() == "queue");
-//..
-//
-/// Usage Example 2
-///----------------
-// Instantiate a 'Uri' object with a string representation of the URI and an
-// allocator.
-//..
-// bmqt::Uri uri("bmq://my.domain/queue", allocator);
-// assert(uri.scheme() == "bmq");
-// assert(uri.domain() == "my.domain");
-// assert(uri.queue() == "queue");
-//..
-
-///Thread Safety
-///-------------
-//: o 'bmqt::UriBuilder' is NOT thread safe
-//: o 'bmqt::UriParser' should be thread safe: the component depends on
-//: 'bdepcre_regex' that is a wrapper around "pcre.h". See
-//: http://www.pcre.org/pcre.txt.
-
-
-// BMQ
-#include <bmqscm_version.h>
-
-// BDE
-#include <ball_log.h>
-#include <bsl_cstddef.h>
-#include <bsl_iosfwd.h>
-#include <bsl_string.h>
-#include <bslh_hash.h>
-#include <bslma_usesbslmaallocator.h>
-#include <bslmf_nestedtraitdeclaration.h>
-
-
-namespace BloombergLP {
-
-// FORWARD DECLARATION
-namespace bmqt { class UriBuilder; }
-namespace bmqt { struct UriParser; }
-
-namespace bmqt {
-
-
- // =========
- // class Uri
- // =========
-
-class Uri {
- // Value semantic type representing a URI
-
- public:
- // PUBLIC CONSTANTS
- static const int k_QUEUENAME_MAX_LENGTH = 64;
- // The maximum authorized length for the queue name part of the URI.
-
- private:
- // CLASS-SCOPE CATEGORY
- BALL_LOG_SET_CLASS_CATEGORY("BMQT.URI");
-
- private:
- // FRIENDS
- friend struct UriParser;
- friend class UriBuilder;
- template <class HASH_ALGORITHM>
- friend void hashAppend(HASH_ALGORITHM& hashAlgo, const Uri& uri);
-
- private:
- // DATA
- bsl::string d_uri; // The full URI
-
- bslstl::StringRef d_scheme; // URI scheme (must be "bmq").
-
- bslstl::StringRef d_authority; // URI authority (domain + optional
- // tier)
-
- bslstl::StringRef d_domain; // URI domain
-
- bslstl::StringRef d_tier; // URI tier
-
- bslstl::StringRef d_path; // URI path (i.e queue name).
-
- bslstl::StringRef d_query_id; // Optional application id, part of the
- // URI query if present.
-
- bool d_wasParserInitialized;
- // Flag indicating whether the URI
- // parser was initialized (and whether
- // shutdown should be called on it at
- // destruction)
-
- private:
- // PRIVATE MANIPULATORS
- void reset();
- // Reset this object to the default value.
-
- void copyImpl(const Uri& src);
- // Implementation of the copy of the specified 'src' URI into this
- // object.
-
- public:
- // TRAITS
- BSLMF_NESTED_TRAIT_DECLARATION(Uri, bslma::UsesBslmaAllocator)
-
- // CREATORS
- explicit Uri(bslma::Allocator *allocator = 0);
- // Constructor of an invalid Uri with all fields empty, using the
- // optionally specified 'allocator'.
-
- Uri(const Uri& original,
- bslma::Allocator *allocator = 0); // IMPLICIT
- // Copy constructor, create a new Uri having the same values as the
- // specified 'original', and using the optionally specified
- // 'allocator'.
-
- Uri(const bsl::string& uri,
- bslma::Allocator *allocator = 0); // IMPLICIT
- Uri(const bslstl::StringRef& uri,
- bslma::Allocator *allocator = 0); // IMPLICIT
- Uri(const char *uri,
- bslma::Allocator *allocator = 0); // IMPLICIT
- // Implicit constructor of this object from the specified 'uri' string
- // using the optionally specified 'allocator'. If the 'uri' input
- // string doesn't not represent a valid URI, this object is left in an
- // invalid state (isValid() will return false).
-
- ~Uri();
- // Destructor.
-
- // MANIPULATORS
- Uri& operator=(const Uri& rhs);
- // Set the value of this object to the specified 'rhs'.
-
- // ACCESSORS
- const bsl::string& asString() const;
- // Return the string representation of this URI.
-
- bool isValid() const;
- // Return true if this object represents a valid URI.
-
- bool isCanonical() const;
- // Return true if this object represents a canonical URI.
-
- const bslstl::StringRef& scheme() const;
- const bslstl::StringRef& authority() const;
- const bslstl::StringRef& path() const;
- // Return the corresponding (raw) part of the URI, matching to the URI
- // RFC terminology.
-
- const bslstl::StringRef& qualifiedDomain() const;
- const bslstl::StringRef& domain() const;
- const bslstl::StringRef& tier() const;
- const bslstl::StringRef& queue() const;
- const bslstl::StringRef& id() const;
- // Return the corresponding (extracted) part of the URI, provided as
- // convenient accessors using the BlazingMQ terminology.
-
- bslstl::StringRef canonical() const;
- // Return the canonical form of the URI. Note that canonical form
- // includes everything except the query part of the URI.
-
- bsl::ostream& print(bsl::ostream& stream,
- int level = 0,
- int spacesPerLevel = 4) const;
- // Format this object to the specified output 'stream' at the (absolute
- // value of) the optionally specified indentation 'level' and return a
- // reference to 'stream'. If 'level' is specified, optionally specify
- // 'spacesPerLevel', the number of spaces per indentation level for
- // this and all of its nested objects. If 'level' is negative,
- // suppress indentation of the first line. If 'spacesPerLevel' is
- // negative format the entire output on one line, suppressing all but
- // the initial indentation (as governed by 'level'). If 'stream' is
- // not valid on entry, this operation has no effect.
-};
-
-// FREE OPERATORS
-bool operator==(const Uri& lhs,
- const Uri& rhs);
- // Return 'true' if the specified 'rhs' object contains the value of the
- // same type as contained in the specified 'lhs' object and the value
- // itself is the same in both objects, return false otherwise.
-
-bool operator!=(const Uri& lhs,
- const Uri& rhs);
- // Return 'false' if the specified 'rhs' object contains the value of the
- // same type as contained in the specified 'lhs' object and the value
- // itself is the same in both objects, return 'true' otherwise.
-
-bool operator<(const Uri& lhs,
- const Uri& rhs);
- // Return 'true' if the specified 'lhs' object compares less than the
- // specified 'rhs' object.
-
-
-bsl::ostream& operator<<(bsl::ostream& stream,
- const Uri& rhs);
- // Format the specified 'rhs' to the specified output 'stream' and return
- // a reference to the modifiable 'stream'.
-
-
- // ================
- // struct UriParser
- // ================
-
-struct UriParser {
- // Utility namespace of methods for parsing URI strings into 'Uri' objects.
-
- // CLASS METHODS
- static void initialize(bslma::Allocator *allocator = 0);
- // Initialize the 'UriParser'. Note that this will compile the regular
- // expression used by 'parseUri'. This method only needs to be called
- // once before any other method, but can be called multiple times
- // provided that for each call to 'initialize' there is a corresponding
- // call to 'shutdown'. Use the optionally specified 'allocator' for
- // any memory allocation, or the 'global' allocator if none is
- // provided. Note that specifying the allocator is provided for test
- // drivers only, and therefore users should let it default to the
- // global allocator.
-
- static void shutdown();
- // Pendant operation of the 'initialize' one. Note that behaviour
- // after calling the '.parse()' method of the 'UriParser' after
- // 'shutdown' has been called is undefined. The number of calls to
- // 'shutdown' must equal the number of calls to 'initialize', without
- // corresponding 'shutdown' calls, to fully destroy the parser. It is
- // safe to call 'initialize' after calling 'shutdown'. Behaviour is
- // undefined if 'shutdown' is called without 'initialize' first being
- // called.
-
- static int parse(Uri *result,
- bsl::string *errorDescription,
- const bslstl::StringRef& uriString);
- // Parse the specified 'uriString' into the specified 'result' object
- // if 'uriString' is a valid URI, otherwise load the specified
- // 'errorDescription' with a description of the syntax error present in
- // 'uriString'. Return 0 on success and non-zero if 'uriString' does
- // not have a valid syntax. Note that 'errorDescription' may be null
- // if the caller does not care about getting error messages. The
- // behavior is undefined unless 'initialize' has been called
- // previously.
-
- private:
- // CLASS-SCOPE CATEGORY
- BALL_LOG_SET_CLASS_CATEGORY("BMQT.URI");
-};
-
-
- // ================
- // class UriBuilder
- // ================
-
-class UriBuilder {
- // This component implements a mechanism, 'bmqt::UriBuilder', that can be
- // used for creating queue URI for BMQ.
-
- private:
- // DATA
- Uri d_uri; // Placeholder object for URI object being built.
-
- private:
- // NOT IMPLEMENTED
- UriBuilder(const UriBuilder&);
- UriBuilder& operator=(const UriBuilder&);
- // Copy constructor and assignment operator not implemented.
-
- public:
- // TRAITS
- BSLMF_NESTED_TRAIT_DECLARATION(UriBuilder, bslma::UsesBslmaAllocator)
-
- // CREATORS
- explicit UriBuilder(bslma::Allocator *allocator = 0);
- // Create a new UriBuilder using the optionally specified 'allocator'.
-
- explicit UriBuilder(const bmqt::Uri& uri,
- bslma::Allocator *allocator = 0);
- // Create a new UriBuilder initialized with the specified 'uri' and
- // using the optionally specified 'allocator'.
-
- // MANIPULATORS
- UriBuilder& setDomain(const bslstl::StringRef& value);
- UriBuilder& setTier(const bslstl::StringRef& value);
- UriBuilder& setQualifiedDomain(const bslstl::StringRef& value);
- UriBuilder& setQueue(const bslstl::StringRef& value);
- UriBuilder& setId(const bslstl::StringRef& value);
- // Set the corresponding field of the URI to the specified 'value'.
- // The behavior is undefined unless 'value' remains valid until URI has
- // been built by invoking 'uri()'. 'setDomain()' and 'setTier()'
- // should be preferred over 'setQualifiedDomain()' whenever possible.
-
- void reset();
- // Reset all fields of this builder.
-
- // ACCESSORS
- int uri(Uri *result,
- bsl::string *errorDescription = 0) const;
- // Build and populate the specified 'result' with the built URI,
- // returning 0 on success, or return non-zero on error, populating the
- // optionally specified 'errorDescription' if provided.
-};
-
-
-// ============================================================================
-// INLINE DEFINITIONS
-// ============================================================================
-
-
- // ---------
- // class Uri
- // ---------
-
-inline
-Uri&
-Uri::operator=(const Uri& rhs)
-{
- copyImpl(rhs);
-
- return *this;
-}
-
-inline
-const bsl::string&
-Uri::asString() const
-{
- return d_uri;
-}
-
-inline
-bool
-Uri::isValid() const
-{
- // URI can only be set using either 'UriBuilder' or 'UriParser', which are
- // resetting the d_uri on failure.
- return !d_uri.empty();
-}
-
-inline
-bool
-Uri::isCanonical() const
-{
- return d_query_id.isEmpty();
-}
-
-inline
-const bslstl::StringRef&
-Uri::scheme() const
-{
- return d_scheme;
-}
-
-inline
-const bslstl::StringRef&
-Uri::authority() const
-{
- return d_authority;
-}
-
-inline
-const bslstl::StringRef&
-Uri::path() const
-{
- return d_path;
-}
-
-inline
-const bslstl::StringRef&
-Uri::domain() const
-{
- return d_domain;
-}
-
-inline
-const bslstl::StringRef&
-Uri::qualifiedDomain() const
-{
- return d_authority;
-}
-
-inline
-const bslstl::StringRef&
-Uri::tier() const
-{
- return d_tier;
-}
-
-inline
-const bslstl::StringRef&
-Uri::queue() const
-{
- return d_path;
-}
-
-inline
-const bslstl::StringRef&
-Uri::id() const
-{
- return d_query_id;
-}
-
-inline
-bslstl::StringRef
-Uri::canonical() const
-{
- size_t queryBeginPos = d_uri.find_first_of('?');
- if (bsl::string::npos == queryBeginPos) {
- return d_uri; // RETURN
- }
-
- return bslstl::StringRef(d_uri.c_str(), queryBeginPos);
-}
-
-// FREE FUNCTIONS
-template <class HASH_ALGORITHM>
-void
-hashAppend(HASH_ALGORITHM& hashAlgo,
- const Uri& uri)
-{
- using bslh::hashAppend; // for ADL
- hashAppend(hashAlgo, uri.d_uri); // hashes full uri string
-}
-
-
- // ----------------
- // class UriBuilder
- // ----------------
-
-inline
-UriBuilder&
-UriBuilder::setDomain(const bslstl::StringRef& value)
-{
- d_uri.d_domain = value;
- return *this;
-}
-
-inline
-UriBuilder&
-UriBuilder::setTier(const bslstl::StringRef& value)
-{
- d_uri.d_tier = value;
- return *this;
-}
-
-inline
-UriBuilder&
-UriBuilder::setQueue(const bslstl::StringRef& value)
-{
- d_uri.d_path = value;
- return *this;
-}
-
-inline
-UriBuilder&
-UriBuilder::setId(const bslstl::StringRef& value)
-{
- d_uri.d_query_id = value;
- return *this;
-}
-
-
-} // close package namespace
-
-// FREE OPERATORS
-
-inline
-bool
-bmqt::operator==(const bmqt::Uri& lhs,
- const bmqt::Uri& rhs)
-{
- return (lhs.asString() == rhs.asString());
-}
-
-inline
-bool
-bmqt::operator!=(const bmqt::Uri& lhs,
- const bmqt::Uri& rhs)
-{
- return (lhs.asString() != rhs.asString());
-}
-
-inline
-bool
-bmqt::operator<(const bmqt::Uri& lhs,
- const bmqt::Uri& rhs)
-{
- return (lhs.asString() < rhs.asString());
-}
-
-inline
-bsl::ostream&
-bmqt::operator<<(bsl::ostream& stream,
- const bmqt::Uri& rhs)
-{
- return rhs.print(stream, 0, -1);
-}
-
-} // close enterprise namespace
-
-#endif
-
-Generated on Thu Jun 15 2023 11:58:51 by
-
- 1.7.1
-
-
diff --git a/docs/docs/apidocs/cpp_apidocs/bmqt__version_8h_source.html b/docs/docs/apidocs/cpp_apidocs/bmqt__version_8h_source.html
deleted file mode 100644
index 19e09c7bd..000000000
--- a/docs/docs/apidocs/cpp_apidocs/bmqt__version_8h_source.html
+++ /dev/null
@@ -1,234 +0,0 @@
-
-
-Bloomberg Development Environment
-
-
-// Copyright 2014-2023 Bloomberg Finance L.P.
-// SPDX-License-Identifier: Apache-2.0
-//
-// Licensed under the Apache License, Version 2.0 (the "License");
-// you may not use this file except in compliance with the License.
-// You may obtain a copy of the License at
-//
-// http://www.apache.org/licenses/LICENSE-2.0
-//
-// Unless required by applicable law or agreed to in writing, software
-// distributed under the License is distributed on an "AS IS" BASIS,
-// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-// See the License for the specific language governing permissions and
-// limitations under the License.
-
-// bmqt_version.h -*-C++-*-
-#ifndef INCLUDED_BMQT_VERSION
-#define INCLUDED_BMQT_VERSION
-
-//@PURPOSE: Provide a value-semantic type representing a version (major minor).
-//
-//@CLASSES:
-// bmqt::Version: version with major and minor parts.
-//
-//@DESCRIPTION: This component implements a simple value-semantic type,
-// 'bmqt::Version' representing the version of an object. It is used in
-// particular to attach a version attribute to a 'bmqa::Message', so that a
-// consuming application receiving a message knows the version of the schema
-// that was used for publishing.
-//
-// A version is represented by two numbers: a major and a minor version. Both
-// are positive integers within the range [0-255].
-//
-///Usage Example
-///-------------
-//..
-// bmqt::Version version(1, 3);
-// BSLS_ASSERT(version.major() == 1);
-// BSLS_ASSERT(version.minor() == 3);
-// version.setMajor(2).setMinor(4);
-// BSLS_ASSERT(version.major() == 2);
-// BSLS_ASSERT(version.minor() == 4);
-//..
-
-
-// BMQ
-#include <bmqscm_version.h>
-
-// BDE
-#include <bsl_iosfwd.h>
-
-namespace BloombergLP {
-namespace bmqt {
-
- // =============
- // class Version
- // =============
-
-class Version {
- // A version consisting of a major and minor version number.
-
- private:
- // DATA
- unsigned char d_major; // Major part of the version
- unsigned char d_minor; // Minor part of the version
-
- public:
- // CREATORS
- Version();
- // Create an object of type 'Version' having the default value. Note
- // that major is set to zero and minor is set to zero.
-
- Version(unsigned char major, unsigned char minor);
- // Create an object of type 'Version' initialized with the specified
- // 'major' and 'minor' versions.
-
- // MANIPULATORS
- Version& setMajor(unsigned char value);
- // Set the major part of the version to the specified 'value' and
- // return a reference to this object.
-
- Version& setMinor(unsigned char value);
- // Set the minor part of the version to the specified 'value' and
- // return a reference to this object.
-
- // ACCESSORS
- bsl::ostream& print(bsl::ostream& stream,
- int level = 0,
- int spacesPerLevel = 4) const;
- // Format this object to the specified output 'stream' at the
- // optionally specified indentation 'level' and return a reference to
- // the modifiable 'stream'. If 'level' is specified, optionally
- // specify 'spacesPerLevel', the number of spaces per indentation level
- // for this and all of its nested objects. Each line is indented by
- // the absolute value of 'level * spacesPerLevel'. If 'level' is
- // negative, suppress indentation of the first line. If
- // 'spacesPerLevel' is negative, suppress line breaks and format the
- // entire output on one line. If 'stream' is initially invalid, this
- // operation has no effect. Note that a trailing newline is provided
- // in multiline mode only.
-
- unsigned char major() const;
- // Return the major part of the version.
-
- unsigned char minor() const;
- // Return the minor part of the version.
-};
-
-// FREE OPERATORS
-bsl::ostream& operator<<(bsl::ostream& stream, const Version& rhs);
- // Format the specified 'rhs' to the specified output 'stream' and return
- // a reference to the modifiable 'stream'.
-
-bool operator==(const Version& lhs, const Version& rhs);
- // Return 'true' if the object in the specified 'lhs' represents the same
- // version as the the one in the specified 'rhs', return false otherwise.
-
-bool operator!=(const Version& lhs, const Version& rhs);
- // Return 'true' if the object in the specified 'lhs' represents a
- // different version than the the one in the specified 'rhs', return false
- // otherwise.
-
-bool operator<(const Version& lhs, const Version& rhs);
- // Return 'true' if the version represented by the specified 'lhs' is less
- // than the version represented by the specified 'rhs'.
-
-// ============================================================================
-// INLINE DEFINITIONS
-// ============================================================================
-
- // -------------
- // class Version
- // -------------
-
-// CREATORS
-inline
-Version::Version()
-: d_major(0)
-, d_minor(0)
-{
- // NOTHING
-}
-
-inline
-Version::Version(unsigned char major,
- unsigned char minor)
-: d_major(major)
-, d_minor(minor)
-{
- // NOTHING
-}
-
-// MANIPULATORS
-inline
-Version&
-Version::setMajor(unsigned char value)
-{
- d_major = value;
- return *this;
-}
-
-inline
-Version&
-Version::setMinor(unsigned char value)
-{
- d_minor = value;
- return *this;
-}
-
-// ACCESSORS
-inline
-unsigned char
-Version::major() const
-{
- return d_major;
-}
-
-inline
-unsigned char
-Version::minor() const
-{
- return d_minor;
-}
-
-} // close package namespace
-
-
-// FREE OPERATORS
-inline
-bsl::ostream&
-bmqt::operator<<(bsl::ostream& stream,
- const bmqt::Version& rhs)
-{
- return rhs.print(stream, 0, -1);
-}
-
-inline
-bool
-bmqt::operator==(const bmqt::Version& lhs,
- const bmqt::Version& rhs)
-{
- return lhs.major() == rhs.major()
- && lhs.minor() == rhs.minor();
-}
-
-inline
-bool
-bmqt::operator!=(const bmqt::Version& lhs,
- const bmqt::Version& rhs)
-{
- return lhs.major() != rhs.major()
- || lhs.minor() != rhs.minor();
-}
-
-inline
-bool
-bmqt::operator<(const bmqt::Version& lhs,
- const bmqt::Version& rhs)
-{
- return lhs.major() < rhs.major()
- || (lhs.major() == rhs.major() && lhs.minor() < rhs.minor());
-}
-
-} // close enterprise namespace
-
-#endif
-
Invoked as a response to an asynchronous open queue operation, OpenQueueCallback is an alias for a callback function object (functor) that takes as an argument the specified result, providing the result and context of the requested operation.
Invoked as a response to an asynchronous configure queue operation, ConfigureQueueCallback is an alias for a callback function object (functor) that takes as an argument the specified result, providing the result and context of the requested operation.
Invoked as a response to an asynchronous close queue operation, CloseQueueCallback is an alias for a callback function object (functor) that takes as an argument the specified result, providing the result and context of the requested operation.
Connect to the BlazingMQ broker and start the message processing for this Session. This method blocks until either the Session is connected to the broker, fails to connect, or the operation times out. If the optionally specified timeout is not populated, use the one defined in the session options. Return 0 on success, or a non-zero value corresponding to the bmqt::GenericResult::Enum enum values otherwise. The behavior is undefined if this method is called on an already started Session.
Connect to the BlazingMQ broker and start the message processing for this Session. This method returns without blocking. The result of the operation is communicated with a session event. If the optionally specified timeout is not populated, use the one defined in the session options. Return 0 on success (this doesn't imply the session is connected !), or a non-zero value corresponding to the bmqt::GenericResult::Enum enum values otherwise. The behavior is undefined if this method is called on an already started Session.
Gracefully disconnect from the BlazingMQ broker and stop the operation of this Session. This method blocks waiting for all already invoked event handlers to exit and all session-related operations to be finished. No other method but start() may be used after this method returns. This method must NOT be called if the session is in synchronous mode (i.e., not using the EventHandler), stopAsync() should be called in this case.
Disconnect from the BlazingMQ broker and stop the operation of this Session. This method returns without blocking and neither enforce nor waits for any already started session-related operation to be finished. No method may be used after this method returns.
This method is only to be used if the session is in synchronous mode (i.e., not using the EventHandler): it must be called once all threads getting events with nextEvent() have been joined.
Load into the specified builder an instance of bmqa::MessageEventBuilder that can be used to build message event for posting on this session. The behavior is undefined unless the session has been successfully started and builder is non-null. Note that lifetime of the loaded object is bound by the lifetime of this session instance (i.e., loaded instance cannot outlive this session instance). Also note that the MessageEventBuilder objects are pooled, so this operation is cheap, and MessageEventBuilder can be obtained on demand and kept on the stack.
Load into the specified builder an instance of bmqa::ConfirmEventBuilder that can be used to build a batch of CONFIRM messages for sending to the broker. The behavior is undefined unless the session has been successfully started and builder is non-null. Note that the lifetime of the loaded object is bound by the lifetime of this session instance (i.e., loaded instance cannot outlive this session instance).
Load into the specified buffer an instance of MessageProperties that can be used to specify and associate properties while building a bmqa::Message. The behavior is undefined unless the session has been successfully started and buffer is non-null. Note that lifetime of the loaded object is bound by the lifetime of this session instance (i.e., loaded instance cannot outlive this session instance).
Load in the specified queueId the queue corresponding to the specified uri and return 0 if such a queue was found, or leave queueId untouched and return a non-zero value if no queue corresponding to uri is currently open.
Load in the specified queueId the queue corresponding to the specified correlationId and return 0 if such a queue was found, or leave queueId untouched and return a non-zero value if no queue corresponding to correlationId is currently open.
Open the queue having the specified uri with the specified flags (a combination of the values defined in bmqt::QueueFlags::Enum), using the specified queueId to correlate events related to that queue. The object queueId referring to is modified, so the queueId represents the actual queue uri, flags and options. Return a result providing the status and context of the operation. Use the optionally specified options to configure some advanced settings. Note that this operation fails if queueId is non-unique. If the optionally specified timeout is not populated, use the one defined in the session options. This operation will block until either success, failure, or timing out happens.
-
THREAD: Note that calling this method from the event processing thread(s) (i.e., from the EventHandler callback, if provided) WILL lead to a DEADLOCK.
DEPRECATED: Use the openQueueAsync(...) with callback flavor instead. This method will be marked as BSLS_ANNOTATION_DEPRECATED in future release of libbmq.
Asynchronously open the queue having the specified uri with the specified flags (a combination of the values defined in bmqt::QueueFlags::Enum), using the specified queueId to correlate events related to that queue and the optionally specified options to configure some advanced settings. The object queueId referring to is modified, so the queueId represents the actual queue uri, flags and options. The result of the operation is communicated to the specified callback via a bmqa::OpenQueueStatus, providing the status and context of the requested operation. Note that this operation fails if queueId is non-unique. If the optionally specified timeout is not populated, use the one defined in the session options.
-
THREAD: The callback will ALWAYS be invoked from the EventHandler thread(s) (or if a SessionEventHandler was not specified, from the thread invoking nextEvent).
DEPRECATED: Use the 'configureQueueSync(QueueId *queueId...) instead. This method will be marked as BSLS_ANNOTATION_DEPRECATED in future release of libbmq.
Configure the queue identified by the specified queueId using the specified options and return a result providing the status and context of the operation. Fields from options that have not been explicitly set will not be modified. If the optionally specified timeout is not populated, use the one defined in the session options. This operation returns error if there is a pending configure for the same queue. This operation will block until either success, failure, or timing out happens.
-
THREAD: Note that calling this method from the event processing thread(s) (i.e., from the EventHandler callback, if provided) WILL lead to a DEADLOCK.
DEPRECATED: Use the configureQueueAsync(...) with callback flavor instead. This method will be marked as BSLS_ANNOTATION_DEPRECATED in future release of libbmq.
DEPRECATED: Use the 'closeQueueSync(QueueId *queueId...) instead. This method will be marked as BSLS_ANNOTATION_DEPRECATED in future release of libbmq.
Close the queue identified by the specified queueId and return a result providing the status and context of the operation. If the optionally specified timeout is not populated, use the one defined in the session options. Any outstanding configureQueue request for this queueId will be canceled. This operation will block until either success, failure, or timing out happens. Once this method returns, there is guarantee that no more messages and events for this queueId will be received. Note that successful processing of this request in the broker closes this session's view of the queue; the underlying queue may not be deleted in the broker. When this method returns, the correlationId associated to the queue is cleared.
-
THREAD: Note that calling this method from the event processing thread(s) (i.e., from the EventHandler callback, if provided) WILL lead to a DEADLOCK.
DEPRECATED: Use the closeQueueAsync(...) with callback flavor instead. This method will be marked as BSLS_ANNOTATION_DEPRECATED in future release of libbmq.
Asynchronously close the queue identified by the specified queueId. Any outstanding configureQueue requests will be canceled. The result of the operation is communicated to the specified callback via a bmqa::CloseQueueStatus, providing the status and context of the operation. If the optionally specified timeout is not populated, use the one defined in the session options. Note that successful processing of this request in the broker closes this session's view of the queue; the underlying queue may not be deleted in the broker. The correlationId associated to the queue remains valid until the bmqa::CloseQueueStatus result has been received and processed by the callback, after which it will be cleared and no more messages and events for this queueId will be received.
-
THREAD: The callback will ALWAYS be invoked from the EventHandler thread(s) (or if a SessionEventHandler was not specified, from the thread invoking nextEvent).
Return the next available event received for this session. If there is no event available, this method blocks for up to the optionally specified timeout time interval for an event to arrive. An empty time interval for timeout (the default) indicates that the method should not timeout (the method will not return until the next event is available). Return a bmqa::SessionEvent of type bmqt::SessionEventType::e_TIMEOUT if a timeout was specified and that timeout expired before any event was received. Note that this method can only be used if the session is in synchronous mode (ie not using the EventHandler). The behavior is undefined unless the session was started.
Asynchronously post the specified event that must contain one or more Messages. The return value is one of the values defined in the bmqt::PostResult::Enum enum. Return zero on success and a non-zero value otherwise. Note that success implies that SDK has accepted the event and will eventually deliver it to the broker. The behavior is undefined unless the session was started.
Asynchronously confirm the receipt of the specified message. This indicates that the application is done processing the message and that the broker can safely discard it from the queue according to the retention policy set up for that queue. Return 0 on success, and a non-zero value otherwise. Note that success implies that SDK has accepted the message and will eventually send confirmation notification to the broker.
Asynchronously confirm the receipt of the message with which the specified cookie is associated. This indicates that the application is done processing the message and that the broker can safely discard it from the queue according to the retention policy set up for that queue. Return 0 on success, and a non-zero value otherwise. Note that success implies that SDK has accepted the message and will eventually send confirmation notification to the broker.
Asynchronously confirm the receipt of the batch of CONFIRM messages contained in the specified builder. This indicates that the application is done processing all of the messages and that the broker can safely discard them from the queue according to the retention policy set up for that queue. Return 0 on success, and a non-zero value otherwise. Note that in case of success, the instance pointed by the builder will be reset. Also note that success implies that SDK has accepted all of the messages in builder and will eventually send confirmation notification to the broker. Behavior is undefined unless builder is non-null.
virtual int bmqa::AbstractSession::configureMessageDumping
-
(
-
const bslstl::StringRef &
-
command
-
)
-
[virtual]
-
-
-
-
-
Configure this session instance to dump messages to the installed logger at ball::Severity::INFO level according to the specified command that should adhere to the following pattern:
-
IN|OUT ON|OFF|100|10s
-
where each token has a specific meaning:
-
-
-IN : incoming (PUSH and ACK) events
-
-OUT : outgoing (PUT and CONFIRM) events
-
-ON : turn on message dumping until explicitly turned off
-
-OFF : turn off message dumping
-
-100 : turn on message dumping for the next 100 messages
-
-10s : turn on message dumping for the next 10 seconds
-
-
Note that above, 100 and 10 numerical values are for just for illustration purposes, and application can choose an appropriate value for them. Also note that pattern is case-insensitive. Return zero if command is valid and message dumping has been configured, non-zero value otherwise. The behavior is undefined unless the session has been started.
Create a new bmqa::CloseQueueStatus object having the specified queueId, result, and errorDescription, using the optionally specified allocator to supply memory.
Return a printable description of the error, if result indicates failure. Return an empty string otherwise.
-
-
-
-
-
-
-
-
-
bsl::ostream& bmqa::CloseQueueStatus::print
-
(
-
bsl::ostream &
-
stream,
-
-
-
-
-
int
-
level = 0,
-
-
-
-
-
int
-
spacesPerLevel = 4
-
-
-
-
)
-
const
-
-
-
-
-
Format this object to the specified output stream at the (absolute value of) the optionally specified indentation level and return a reference to stream. If level is specified, optionally specify spacesPerLevel, the number of spaces per indentation level for this and all of its nested objects. If level is negative, suppress indentation of the first line. If spacesPerLevel is negative format the entire output on one line, suppressing all but the initial indentation (as governed by level). If stream is not valid on entry, this operation has no effect.
-
-
-
-The documentation for this class was generated from the following file:
Create a new bmqa::ConfigureQueueStatus object having the specified queueId, result, and errorDescription, using the optionally specified allocator to supply memory.
Return a printable description of the error, if result indicates failure. Return an empty string otherwise.
-
-
-
-
-
-
-
-
-
bsl::ostream& bmqa::ConfigureQueueStatus::print
-
(
-
bsl::ostream &
-
stream,
-
-
-
-
-
int
-
level = 0,
-
-
-
-
-
int
-
spacesPerLevel = 4
-
-
-
-
)
-
const
-
-
-
-
-
Format this object to the specified output stream at the (absolute value of) the optionally specified indentation level and return a reference to stream. If level is specified, optionally specify spacesPerLevel, the number of spaces per indentation level for this and all of its nested objects. If level is negative, suppress indentation of the first line. If spacesPerLevel is negative format the entire output on one line, suppressing all but the initial indentation (as governed by level). If stream is not valid on entry, this operation has no effect.
-
-
-
-The documentation for this class was generated from the following file:
Append a confirmation message for the specified message. Return zero on success, and a non-zero value otherwise. Behavior is undefined unless this instance was obtained using bmqa::Session::loadConfirmEventBuilder.
Reset the builder, effectively discarding the batch of confirmation messages under construction.
-
-
-
-
-
-
-
-
-
int bmqa::ConfirmEventBuilder::messageCount
-
(
-
-
)
-
const
-
-
-
-
-
Return the number of messages currently in the ConfirmEvent being built. Behavior is undefined unless this instance was obtained using bmqa::Session::loadConfirmEventBuilder.
Return a reference not offering modifiable access to the blob of confirmation messages batch built by this builder. If no messages were added, this will return an empty blob, i.e., a blob with length == 0. Behavior is undefined unless this instance was obtained using bmqa::Session::loadConfirmEventBuilder.
-
-
-
-The documentation for this class was generated from the following file:
Return the MessageEvent variant. The behavior is undefined unless isMessageEvent returns true.
-
-
-
-
-
-
-
-
-
bool bmqa::Event::isSessionEvent
-
(
-
-
)
-
const
-
-
-
-
-
Return true if the event is a session event.
-
-
-
-
-
-
-
-
-
bool bmqa::Event::isMessageEvent
-
(
-
-
)
-
const
-
-
-
-
-
Return true if the event is a message event.
-
-
-
-
-
-
-
-
-
bsl::ostream& bmqa::Event::print
-
(
-
bsl::ostream &
-
stream,
-
-
-
-
-
int
-
level = 0,
-
-
-
-
-
int
-
spacesPerLevel = 4
-
-
-
-
)
-
const
-
-
-
-
-
Format this object to the specified output stream at the (absolute value of) the optionally specified indentation level and return a reference to stream. If level is specified, optionally specify spacesPerLevel, the number of spaces per indentation level for this and all of its nested objects. If level is negative, suppress indentation of the first line. If spacesPerLevel is negative format the entire output on one line, suppressing all but the initial indentation (as governed by level). If stream is not valid on entry, this operation has no effect.
-
-
-
-The documentation for this class was generated from the following file:
Constructs a ManualHostHealthMonitor with the given initial state. Optionally specify an allocator to supply memory. If allocator is 0, the currently installed default allocator is used.
Set the payload of this message to the blob pointed to by the specified data. Behavior is undefined unless data is non-null and payload's length is greater than zero. Note that payload pointed to by data is not copied right away, and should not be destroyed or modified until this message has been packed (see bmqa::MessageEventBuilder component level documentation for correct usage).
-
This method is deprecated, please use setDataRef() instead.
Set the payload of this message to the specified length bytes starting at the specified data address. The behavior is undefined unless data is non-null and length is greater than zero. Note that payload pointed to by data is not copied right away, and should not be destroyed or modified until this message has been packed (see bmqa::MessageEventBuilder component level documentation for correct usage).
-
This method is deprecated, please use setDataRef() instead.
Set the payload of this message to the blob pointed to by the specified data. Behavior is undefined unless data is non-null and payload's length is greater than zero. Note that payload pointed to by data is not copied right away, and should not be destroyed or modified until this message has been packed (see bmqa::MessageEventBuilder component level documentation for correct usage).
Set the payload of this message to the specified length bytes starting at the specified data address. The behavior is undefined unless data is non-null and length is greater than zero. Note that payload pointed to by data is not copied right away, and should not be destroyed or modified until this message has been packed (see bmqa::MessageEventBuilder component level documentation for correct usage).
Set the properties of this message to the MessageProperties instance pointed by the specified properties. Behavior is undefined unless properties is non-null. Note that properties are not copied right away, and should not be destroyed or modified until this message has been packed (see bmqa::MessageEventBuilder component level documentation for correct usage).
Clear out and properties associated with this message. Note that if there are no properties associated with this message, this method has no effect. Also note that the associated MessageProperties instance, if any, is not modified; it's simply dissociated from this message.
Return a copy of this message, using the optionally specified basicAllocator with the copy holding all the data of this instance and not backed by any MessageEvent. Note that this operation does not copy underlying data.
Return the queue ID indicating the queue for which this message has been received from. The behavior is undefined unless this instance represents a PUT, PUSH or ACK message.
Return the correlation Id associated with this message. The behavior is undefined unless this instance represents a PUT or an ACK, or a PUSH message. Note that in case of failure to accept a PUT message, BlazingMQ sends an ACK message with failed status, even if an ACK message was not requested by the application (i.e., no correlationId was specified when posting the message). In such cases, correlationId associated with the ACK message will be unset, and as such, application must check for that by invoking isUnset on the returned correlationId object. In the case of a PUSH message, the return value is the one specified as the correlation id of the corresponding Subscription. Invoking thePointer, theNumeric or theSharedPtr on an unset correlationId instance will lead to undefined behavior.
Return the unique message Id generated by the SDK for this message. The behavior is undefined unless this instance represents a PUT, a PUSH or an ACK message.
Return a cookie which can be used to confirm this message. The behavior is undefined unless this instance represents a PUSH message.
-
-
-
-
-
-
-
-
-
int bmqa::Message::ackStatus
-
(
-
-
)
-
const
-
-
-
-
-
Return the status of the ACK message. The behavior is undefined unless this instance represents an ACK message. This value correspond to the bmqt::AckResult::Enum enum.
-
-
-
-
-
-
-
-
-
int bmqa::Message::getData
-
(
-
bdlbb::Blob *
-
blob
-
)
-
const
-
-
-
-
-
Load into the specified blob the payload of the message, if any. Return zero if the message has a payload and non-zero value otherwise. The behaviour is undefined unless this instance represents a PUT or PUSH message. Note that for efficiency, application should fetch payload once and cache the value, instead of invoking this method multiple times on a message.
-
-
-
-
-
-
-
-
-
int bmqa::Message::dataSize
-
(
-
-
)
-
const
-
-
-
-
-
Return the number of bytes in the payload. The behaviour is undefined unless this instance represents a PUT or a PUSH message. Note that for efficiency, application should fetch payload size once and cache the value, instead of invoking this method multiple times on a message.
-
-
-
-
-
-
-
-
-
bool bmqa::Message::hasProperties
-
(
-
-
)
-
const
-
-
-
-
-
Return true if this instance has at least one message property associated with it, false otherwise. Behavior is undefined unless this instance represents a PUT or a PUSH message.
Load into the specified buffer the properties associated with this message. Return zero on success, and a non-zero value otherwise. Behavior is undefined unless this instance represents a PUT or a PUSH message, and unless buffer is non-null. Note that if there are no properties associated with this message, zero will be returned and the MessageProperties instance pointed by buffer will be cleared. Also note that for efficiency, application should fetch properties once and cache the value, instead of invoking this method multiple times on a message.
-
-
-
-
-
-
-
-
-
bsl::ostream& bmqa::Message::print
-
(
-
bsl::ostream &
-
stream,
-
-
-
-
-
int
-
level = 0,
-
-
-
-
-
int
-
spacesPerLevel = 4
-
-
-
-
)
-
const
-
-
-
-
-
Format this object to the specified output stream at the (absolute value of) the optionally specified indentation level and return a reference to stream. If level is specified, optionally specify spacesPerLevel, the number of spaces per indentation level for this and all of its nested objects. If level is negative, suppress indentation of the first line. If spacesPerLevel is negative format the entire output on one line, suppressing all but the initial indentation (as governed by level). If stream is not valid on entry, this operation has no effect.
-
-
-
-The documentation for this class was generated from the following file:
Create an instance with the specified queueId and messageGUID. Users should not use that constructor directly, but rather load the message cookie from an existing bmqa::Message with the bmqa::Message::confirmationCookie accessor.
Return a MessageIterator object usable for iterating over the Message objects contained in this MessageEvent. Note that obtaining an iterator invalidates (resets) any previously obtained iterator. The behavior is undefined if type() returns bmqt::MessageEventType::UNDEFINED.
Return the type of messages contained in this MessageEvent.
-
-
-
-
-
-
-
-
-
bsl::ostream& bmqa::MessageEvent::print
-
(
-
bsl::ostream &
-
stream,
-
-
-
-
-
int
-
level = 0,
-
-
-
-
-
int
-
spacesPerLevel = 4
-
-
-
-
)
-
const
-
-
-
-
-
Format this object to the specified output stream at the (absolute value of) the optionally specified indentation level and return a reference to stream. If level is specified, optionally specify spacesPerLevel, the number of spaces per indentation level for this and all of its nested objects. If level is negative, suppress indentation of the first line. If spacesPerLevel is negative format the entire output on one line, suppressing all but the initial indentation (as governed by level). If stream is not valid on entry, this operation has no effect.
-
-
-
-The documentation for this class was generated from the following file:
Reset the current message being built, and return a reference to the current message. Note that returned Message is valid until this builder is reset or destroyed. Behavior is undefined if this builder was earlier used to build an event and has not been reset since then.
Add the current message into the message event under construction, setting the destination queue of the current message to match the specified queueId. Return zero on success, non-zero value otherwise. In case of failure, this method has no effect on the underlying message event being built. The behavior is undefined unless all mandatory attributes of the current Message have been set, andqueueId is valid and has been opened in WRITE mode. The result is one of the values from the bmqt::EventBuilderResult::Enum enum. Note that this method can be called multiple times in a row with different queueId if the application desires to post the same bmqa::Message to multiple queues: all attributes on the message are unchanged, exception for the correlationId which is cleared.
-
-
-
-
-
-
-
-
-
void bmqa::MessageEventBuilder::reset
-
(
-
-
)
-
-
-
-
-
-
Reset the builder, effectively discarding the MessageEvent under construction.
Return the MessageEvent that was built. Note that returned MessageEvent is valid until this builder is reset or destroyed, calling this method multiple times in a row will return the same bmqa::MessageEvent instance. Also note that this builder must be reset before calling startMessage again.
Return the number of messages currently in the MessageEvent being built.
-
-
-
-
-
-
-
-
-
int bmqa::MessageEventBuilder::messageEventSize
-
(
-
-
)
-
const
-
-
-
-
-
Return the size in bytes of the event built after last successful call to packMessage(), otherwise return zero. Note that returned value represents the length of entire message event, including BlazingMQ wire protocol overhead.
-
-
-
-The documentation for this class was generated from the following file:
Advance the position of the iterator to the next message in the event. Return true if there is a next message and false otherwise. Note that advancing to the next message will invalidate any previously returned bmqa::Message retrieved from the message() call.
Return the message to which the iterator is pointing, if any; otherwise return an invalid message. Note that nextMessage must be called before message in order to advance the iterators position to the first message in the event.
-
-
-
-The documentation for this class was generated from the following file:
< Create an empty instance of MessageProperties. Optionally specify a basicAllocator used to supply memory. Note that it is more efficient to use a MessageProperties object retrieved via Session::loadMessageProperties, instead of creating it via this constructor. Create an instance of MessageProperties having the same value as the specified other, that will use the optionally specified basicAllocator to supply memory.
Remove the property with the specified name if one exists and return true and load into the optionally specified buffer the data type of the property. Return false if the name property does not exist, and leave the buffer unchanged.
-
-
-
-
-
-
-
-
-
void bmqa::MessageProperties::clear
-
(
-
-
)
-
-
-
-
-
-
Remove all properties from this instance. Note that numProperties will return zero after invoking this method.
-
-
-
-
-
-
-
-
-
int bmqa::MessageProperties::setPropertyAsBool
-
(
-
const bsl::string &
-
name,
-
-
-
-
-
bool
-
value
-
-
-
-
)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
int bmqa::MessageProperties::setPropertyAsChar
-
(
-
const bsl::string &
-
name,
-
-
-
-
-
char
-
value
-
-
-
-
)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
int bmqa::MessageProperties::setPropertyAsShort
-
(
-
const bsl::string &
-
name,
-
-
-
-
-
short
-
value
-
-
-
-
)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
int bmqa::MessageProperties::setPropertyAsInt32
-
(
-
const bsl::string &
-
name,
-
-
-
-
-
bsl::int32_t
-
value
-
-
-
-
)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
int bmqa::MessageProperties::setPropertyAsInt64
-
(
-
const bsl::string &
-
name,
-
-
-
-
-
bsls::Types::Int64
-
value
-
-
-
-
)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
int bmqa::MessageProperties::setPropertyAsString
-
(
-
const bsl::string &
-
name,
-
-
-
-
-
const bsl::string &
-
value
-
-
-
-
)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
int bmqa::MessageProperties::setPropertyAsBinary
-
(
-
const bsl::string &
-
name,
-
-
-
-
-
const bsl::vector< char > &
-
value
-
-
-
-
)
-
-
-
-
-
-
Set a property with the specified name having the specified value with the corresponding data type. Return zero on success, and a non-zero value in case of failure. Note that if a property with name and the same type exists, it will be updated with the provided value, however if the data type of the existing property differs, an error will be returned.
-
-
-
-
-
-
-
-
-
int bmqa::MessageProperties::streamIn
-
(
-
const bdlbb::Blob &
-
blob
-
)
-
-
-
-
-
-
Populate this instance with its BlazingMQ wire protocol representation from the specified blob. Return zero on success, and a non-zero value otherwise.
-
-
-
-
-
-
-
-
-
int bmqa::MessageProperties::numProperties
-
(
-
-
)
-
const
-
-
-
-
-
Return the total number of properties set in this instance.
-
-
-
-
-
-
-
-
-
int bmqa::MessageProperties::totalSize
-
(
-
-
)
-
const
-
-
-
-
-
Return the total size (in bytes) of the wire representation of this instance. Note that returned value includes the BlazingMQ wire protocol overhead as well.
Return the property having the corresponding type and the specified name if property with such a name exists. Return the specified value if property with name does not exist.
Return a blob having the BlazingMQ wire protocol representation of this instance, using the specified bufferFactory to build the blob. Behavior is undefined unless bufferFactory is non-null. Note that if this instance is empty (i.e., numProperties() == 0), returned blob will be empty. In other words, an empty instance has no wire representation.
-
-
-
-
-
-
-
-
-
bsl::ostream& bmqa::MessageProperties::print
-
(
-
bsl::ostream &
-
stream,
-
-
-
-
-
int
-
level = 0,
-
-
-
-
-
int
-
spacesPerLevel = 4
-
-
-
-
)
-
const
-
-
-
-
-
Format this object to the specified output stream at the (absolute value of) the optionally specified indentation level and return a reference to stream. If level is specified, optionally specify spacesPerLevel, the number of spaces per indentation level for this and all of its nested objects. If level is negative, suppress indentation of the first line. If spacesPerLevel is negative format the entire output on one line, suppressing all but the initial indentation (as governed by level). If stream is not valid on entry, this operation has no effect.
Provide a mechanism to iterator over all the properties in an instance of bmqa::MessageProperties. The order of the iteration is implementation defined. An iterator is valid if it is associated with a property , otherwise it is invalid. Behavior is undefined if the underlying instance of bmqa::MessageProperties is modified during the lifetime of this iterator.
Advance this iterator to refer to the next property of the associated MessageProperties instance, if there is one and return true, return false otherwise. Behavior is undefined unless this method is being invoked for the first time on this object or previous call to hasNext returned true. Note that the order of the iteration is not specified.
Return a reference offering non-modifiable access to the name of the property being pointed by the iterator. Behavior is undefined unless last call to hasNext returned true.
Return property value having the corresponding type being currently being pointed by this iterator instance. Behavior is undefined unless last call to hasNext returned true. Behavior is also undefined unless property's data type matches the requested type.
-
-
-
-The documentation for this class was generated from the following file:
Callback used to inform the test driver of an assertion failure. The application test driver using the MockSession may provide an implementation that makes the test driver fail (for instance, calling BDE's test driver ASSERT macro).
Invoked as a response to an asynchronous open queue operation, OpenQueueCallback is an alias for a callback function object (functor) that takes as an argument the specified result, providing the result and context of the requested operation.
Invoked as a response to an asynchronous configure queue operation, ConfigureQueueCallback is an alias for a callback function object (functor) that takes as an argument the specified result, providing the result and context of the requested operation.
Invoked as a response to an asynchronous close queue operation, CloseQueueCallback is an alias for a callback function object (functor) that takes as an argument the specified result, providing the result and context of the requested operation.
Create a new MockSession in synchronous mode using the optionally specified options. In such mode, events have to be fetched by the application using the nextEvent() method. Optionally specify an allocator used to supply memory. If allocator is 0, the currently installed default allocator is used.
Create a MockSession in asynchronous mode using the specified eventHandler as callback for event processing and the optionally specified options. Optionally specify an allocator used to supply memory. If the optionally specified allocator is 0, the currently installed default allocator is used.
Perform a one time initialization needed by components used in MockSession and MockSessionUtil. This method only needs to be called once before any other method, but can be called multiple times provided that for each call to initialize there is a corresponding call to shutdown. Use the optionally specified allocator for any memory allocation, or the global allocator if none is provided. Note that specifying the allocator is provided for test drivers only, and therefore users should let it default to the global allocator. NOTE: This method will need to be invoked only if the application needs to use MockSessionUtil outside the scope of MockSession.
-
-
-
-
-
-
-
-
-
static void bmqa::MockSession::shutdown
-
(
-
-
)
-
[static]
-
-
-
-
-
Pendant operation of the initialize one. The number of calls to shutdown must equal the number of calls to initialize, without corresponding shutdown calls, to fully destroy the objects. It is safe to call initialize after calling shutdown. The behaviour is undefined if shutdown is called without initialize first being called.
Enqueue the specified event in the queue of events to be emitted. NOTE: This method is unique to MockSession and is valid only in unit tests.
-
-
-
-
-
-
-
-
-
bool bmqa::MockSession::emitEvent
-
(
-
int
-
numEvents = 1
-
)
-
-
-
-
-
-
Emit the specified number of numEvents from the queue of events to be emitted. Return true if at least one event was emitted, and false otherwise. NOTE: This method is unique to MockSession and is valid only in unit tests.
Expect a call to the function and return a reference offering modifiable access to the corresponding Call object.
-
NOTE: Do not use these method directly, use the macro BMQA_EXPECT_CALL instead.
-
-
-
-
-
-
-
-
-
int bmqa::MockSession::start
-
(
-
const bsls::TimeInterval &
-
timeout = bsls::TimeInterval()
-
)
-
[virtual]
-
-
-
-
-
Connect to the BlazingMQ broker and start the message processing for this Session. This method blocks until either the Session is connected to the broker, fails to connect, or the operation times out. If the optionally specified timeout is not populated, use the one defined in the session options. Return 0 on success, or a non-zero value corresponding to the bmqt::GenericResult::Enum enum values otherwise. The behavior is undefined if this method is called on an already started Session.
Start the MockSession with an optionally specified timeout. The return values are elucidated in bmqt::GenericResult. In general a call to start or startAsync emits a SessionEvent of type e_CONNECTED or e_CONNECTION_TIMEOUT.
Gracefully disconnect from the BlazingMQ broker and stop the operation of this Session. This method blocks waiting for all already invoked event handlers to exit and all session-related operations to be finished. No other method but start() may be used after this method returns. This method must NOT be called if the session is in synchronous mode (i.e., not using the EventHandler), stopAsync() should be called in this case.
This method is only to be used if the session is in synchronous mode (i.e., not using the EventHandler): it must be called once all threads getting events with nextEvent() have been joined.
Open the queue having the specified uri with the specified flags (a combination of the values defined in bmqt::QueueFlags::Enum), using the specified queueId to correlate events related to that queue. The object queueId referring to is modified, so the queueId represents the actual queue uri, flags and options. Return a result providing the status and context of the operation. Use the optionally specified options to configure some advanced settings. In general, a call to openQueueSync emits nothing.
DEPRECATED: Use the openQueueAsync(...) with callback flavor instead. This method will be marked as BSLS_ANNOTATION_DEPRECATED in future release of libbmq.
Asynchronously open the queue having the specified uri with the specified flags (a combination of the values defined in bmqt::QueueFlags::Enum). The object queueId referring to is modified, so the queueId represents the actual queue uri, flags and options. The result of the operation is communicated to the specified callback via a bmqa::OpenQueueStatus, providing an automatically generated correlation queueId and the status and context of the requested operation. Use the optionally specified options to configure some advanced settings. In general, a call to openQueueAsync does not emit a SessionEvent, but rather invokes the callback (if provided) instead when the corresponding emitEvent is called.
-
NOTE: openQueueAsync updates the queue state to e_OPENING which is further updated upon invocation of the callback (if provided) with a successful bmqa::OpenQueueStatus.
DEPRECATED: Use the 'configureQueueSync(QueueId *queueId...) instead. This method will be marked as BSLS_ANNOTATION_DEPRECATED in future release of libbmq.
Configure the queue identified by the specified queueId using the specified options to configure some advanced settings and return a result providing the status and context of the operation. In general, a call to configureQueueSync emits nothing.
DEPRECATED: Use the configureQueueAsync(...) with callback flavor instead. This method will be marked as BSLS_ANNOTATION_DEPRECATED in future release of libbmq.
Asynchronously configure the queue identified by the specified queueId using the specified options to configure some advanced settings. The result of the operation is communicated to the specified callback via a bmqa::ConfigureQueueStatus, providing the status and context of the requested operation. In general, a call to configureQueueAsync does not emit a SessionEvent, but rather invokes the callback (if provided) instead when the corresponding emitEvent is called.
Close the queue identified by the specified queueId using the specified timeout. Populate the optionally specified result with the status and context of the operation and return a value providing the status of the operation. In general, a call to closeQueueSync emits nothing.
DEPRECATED: Use the closeQueueAsync(...) with callback flavor instead. This method will be marked as BSLS_ANNOTATION_DEPRECATED in future release of libbmq.
Asynchronously close the queue identified by the specified queueId using the specified timeout. The result of the operation is communicated to the specified callback via a bmqa::CloseQueueStatus, providing the status and context of the requested operation. In general, a call to closeQueueAsync does not emit a SessionEvent, but rather invokes the callback (if provided) instead when the corresponding emitEvent is called.
NOTE: This method should only be used when the MockSession has been created in synchronous mode. It is invalid if used in asynchronous mode and your test case is likely to be faulty if used with such a set up.
Post the specified messageEvent. Return values are defined as per bmqt::PostResult. In general a call to post emits a MessageEvent of type e_ACK or no response if acks are not requested.
Asynchronously confirm the receipt of the specified message. This indicates that the application is done processing the message and that the broker can safely discard it from the queue according to the retention policy set up for that queue. Return 0 on success, and a non-zero value otherwise. Note that success implies that SDK has accepted the message and will eventually send confirmation notification to the broker.
Asynchronously confirm the receipt of the message with which the specified cookie is associated. This indicates that the application is done processing the message and that the broker can safely discard it from the queue according to the retention policy set up for that queue. Return 0 on success, and a non-zero value otherwise. Note that success implies that SDK has accepted the message and will eventually send confirmation notification to the broker.
Confirm messages specified by the message, cookie or builder. Return values are defined as per bmqt::GenericResult. No event is emitted for calls to confirmMessage.
Configure this session instance to dump messages to the installed logger at ball::Severity::INFO level according to the specified command that should adhere to the following pattern:
-
IN|OUT ON|OFF|100|10s
-
where each token has a specific meaning:
-
-
-IN : incoming (PUSH and ACK) events
-
-OUT : outgoing (PUT and CONFIRM) events
-
-ON : turn on message dumping until explicitly turned off
-
-OFF : turn off message dumping
-
-100 : turn on message dumping for the next 100 messages
-
-10s : turn on message dumping for the next 10 seconds
-
-
Note that above, 100 and 10 numerical values are for just for illustration purposes, and application can choose an appropriate value for them. Also note that pattern is case-insensitive. Return zero if command is valid and message dumping has been configured, non-zero value otherwise. The behavior is undefined unless the session has been started.
Load into the specified event the next posted event on this session, if any, and return true; leave event unchanged and return false otherwise.
-
-
-
-
-
-
-
-
-
size_t bmqa::MockSession::unconfirmedMessages
-
(
-
-
)
-
const
-
-
-
-
-
Get the number of unconfirmed messages. This corresponds to the number of push messages enqueued to the session object but not yet confirmed by the application.
-
-
-
-The documentation for this class was generated from the following file:
Create a new bmqa::OpenQueueStatus object having the specified queueId, result, and errorDescription, using the optionally specified allocator to supply memory.
Return a printable description of the error, if result indicates failure. Return an empty string otherwise.
-
-
-
-
-
-
-
-
-
bsl::ostream& bmqa::OpenQueueStatus::print
-
(
-
bsl::ostream &
-
stream,
-
-
-
-
-
int
-
level = 0,
-
-
-
-
-
int
-
spacesPerLevel = 4
-
-
-
-
)
-
const
-
-
-
-
-
Format this object to the specified output stream at the (absolute value of) the optionally specified indentation level and return a reference to stream. If level is specified, optionally specify spacesPerLevel, the number of spaces per indentation level for this and all of its nested objects. If level is negative, suppress indentation of the first line. If spacesPerLevel is negative format the entire output on one line, suppressing all but the initial indentation (as governed by level). If stream is not valid on entry, this operation has no effect.
-
-
-
-The documentation for this class was generated from the following file:
Create a new QueueId associated to the correlation Id having the specified correlationId value, using the optionally specified allocator.
-
-
-
-
-
-
-
-
-
bmqa::QueueId::QueueId
-
(
-
bsls::Types::Int64
-
numeric,
-
-
-
-
-
bslma::Allocator *
-
allocator = 0
-
-
-
-
)
-
[explicit]
-
-
-
-
-
Create a new QueueId associated to the correlation Id having the specified numeric correlationId value, using the optionally specified allocator.
-
-
-
-
-
-
-
-
-
bmqa::QueueId::QueueId
-
(
-
void *
-
pointer,
-
-
-
-
-
bslma::Allocator *
-
allocator = 0
-
-
-
-
)
-
[explicit]
-
-
-
-
-
Create a new QueueId associated to the correlation Id having the specified pointer correlationId value, using the optionally specified allocator.
-
-
-
-
-
-
-
-
-
bmqa::QueueId::QueueId
-
(
-
const bsl::shared_ptr< void > &
-
sharedPtr,
-
-
-
-
-
bslma::Allocator *
-
allocator = 0
-
-
-
-
)
-
[explicit]
-
-
-
-
-
Create a new QueueId associated to the correlation Id having the specified sharedPtr correlationId value, using the optionally specified allocator. The lifetime of sharedPtr is tied to this object, and it is the responsibility of the user to manage it accordingly.
Return whether this QueueId is valid, i.e., is associated to an opened queue.
-
-
-
-
-
-
-
-
-
bsl::ostream& bmqa::QueueId::print
-
(
-
bsl::ostream &
-
stream,
-
-
-
-
-
int
-
level = 0,
-
-
-
-
-
int
-
spacesPerLevel = 4
-
-
-
-
)
-
const
-
-
-
-
-
Format this object to the specified output stream at the (absolute value of) the optionally specified indentation level and return a reference to stream. If level is specified, optionally specify spacesPerLevel, the number of spaces per indentation level for this and all of its nested objects. If level is negative, suppress indentation of the first line. If spacesPerLevel is negative format the entire output on one line, suppressing all but the initial indentation (as governed by level). If stream is not valid on entry, this operation has no effect.
Return true if rhs object contains the value of the same type as contained in lhs object and the value itself is the same in both objects, return false otherwise.
Return false if rhs object contains the value of the same type as contained in lhs object and the value itself is the same in both objects, return true otherwise.
Invoked as a response to an asynchronous open queue operation, OpenQueueCallback is an alias for a callback function object (functor) that takes as an argument the specified result, providing the result and context of the requested operation.
Invoked as a response to an asynchronous configure queue operation, ConfigureQueueCallback is an alias for a callback function object (functor) that takes as an argument the specified result, providing the result and context of the requested operation.
Invoked as a response to an asynchronous close queue operation, CloseQueueCallback is an alias for a callback function object (functor) that takes as an argument the specified result, providing the result and context of the requested operation.
Create a new Session in synchronous mode using the optionally specified options. In such mode, events have to be fetched by the application using the nextEvent() method. Optionally specify an allocator used to supply memory. If allocator is 0, the currently installed default allocator is used.
Create a Session in asynchronous mode using the specified eventHandler as callback for event processing and the optionally specified options. Optionally specify an allocator used to supply memory. If the optionally specified allocator is 0, the currently installed default allocator is used.
Connect to the BlazingMQ broker and start the message processing for this Session. This method blocks until either the Session is connected to the broker, fails to connect, or the operation times out. If the optionally specified timeout is not populated, use the one defined in the session options. Return 0 on success, or a non-zero value corresponding to the bmqt::GenericResult::Enum enum values otherwise. The behavior is undefined if this method is called on an already started Session.
Connect to the BlazingMQ broker and start the message processing for this Session. This method returns without blocking. The result of the operation is communicated with a session event. If the optionally specified timeout is not populated, use the one defined in the session options. Return 0 on success (this doesn't imply the session is connected !), or a non-zero value corresponding to the bmqt::GenericResult::Enum enum values otherwise. The behavior is undefined if this method is called on an already started Session.
Gracefully disconnect from the BlazingMQ broker and stop the operation of this Session. This method blocks waiting for all already invoked event handlers to exit and all session-related operations to be finished. No other method but start() may be used after this method returns. This method must NOT be called if the session is in synchronous mode (i.e., not using the EventHandler), stopAsync() should be called in this case.
Disconnect from the BlazingMQ broker and stop the operation of this Session. This method returns without blocking and neither enforce nor waits for any already started session-related operation to be finished. No method may be used after this method returns.
This method is only to be used if the session is in synchronous mode (i.e., not using the EventHandler): it must be called once all threads getting events with nextEvent() have been joined.
Return a MessageEventBuilder that can be used to build message event for posting on this session. The behavior is undefined unless the session has been successfully started. Note that lifetime of the returned object is bound by the lifetime of this session instance (i.e., returned instance cannot outlive this session instance). Also note that the MessageEventBuilder objects are pooled, so this operation is cheap, and MessageEventBuilder can be obtained on demand and kept on the stack.
-
DEPRECATED: Use the 'loadMessageEventBuilder instead. This method will be marked as BSLS_ANNOTATION_DEPRECATED in future release of libbmq.
Load into the specified builder an instance of bmqa::MessageEventBuilder that can be used to build message event for posting on this session. The behavior is undefined unless the session has been successfully started and builder is non-null. Note that lifetime of the loaded object is bound by the lifetime of this session instance (i.e., loaded instance cannot outlive this session instance). Also note that the MessageEventBuilder objects are pooled, so this operation is cheap, and MessageEventBuilder can be obtained on demand and kept on the stack.
Load into the specified builder an instance of bmqa::ConfirmEventBuilder that can be used to build a batch of CONFIRM messages for sending to the broker. The behavior is undefined unless the session has been successfully started and builder is non-null. Note that the lifetime of the loaded object is bound by the lifetime of this session instance (i.e., loaded instance cannot outlive this session instance).
Load into the specified buffer an instance of MessageProperties that can be used to specify and associate properties while building a bmqa::Message. The behavior is undefined unless the session has been successfully started and buffer is non-null. Note that lifetime of the loaded object is bound by the lifetime of this session instance (i.e., loaded instance cannot outlive this session instance).
Load in the specified queueId the queue corresponding to the specified uri and return 0 if such a queue was found, or leave queueId untouched and return a non-zero value if no queue corresponding to uri is currently open.
Load in the specified queueId the queue corresponding to the specified correlationId and return 0 if such a queue was found, or leave queueId untouched and return a non-zero value if no queue corresponding to correlationId is currently open.
Open the queue having the specified uri with the specified flags (a combination of the values defined in bmqt::QueueFlags::Enum), using the specified queueId to correlate events related to that queue. The object queueId referring to is modified, so the queueId represents the actual queue uri, flags and options. Return a result providing the status and context of the operation. Use the optionally specified options to configure some advanced settings. Note that this operation fails if queueId is non-unique. If the optionally specified timeout is not populated, use the one defined in the session options. This operation will block until either success, failure, or timing out happens.
-
THREAD: Note that calling this method from the event processing thread(s) (i.e., from the EventHandler callback, if provided) WILL lead to a DEADLOCK.
DEPRECATED: Use the openQueueAsync(...) with callback flavor instead. This method will be marked as BSLS_ANNOTATION_DEPRECATED in future release of libbmq.
Asynchronously open the queue having the specified uri with the specified flags (a combination of the values defined in bmqt::QueueFlags::Enum), using the specified queueId to correlate events related to that queue and the optionally specified options to configure some advanced settings. The object queueId referring to is modified, so the queueId represents the actual queue uri, flags and options. The result of the operation is communicated to the specified callback via a bmqa::OpenQueueStatus, providing the status and context of the requested operation. Note that this operation fails if queueId is non-unique. If the optionally specified timeout is not populated, use the one defined in the session options.
-
THREAD: The callback will ALWAYS be invoked from the EventHandler thread(s) (or if a SessionEventHandler was not specified, from the thread invoking nextEvent).
DEPRECATED: Use the 'configureQueueSync(QueueId *queueId...) instead. This method will be marked as BSLS_ANNOTATION_DEPRECATED in future release of libbmq.
Configure the queue identified by the specified queueId using the specified options and return a result providing the status and context of the operation. If the optionally specified timeout is not populated, use the one defined in the session options. This operation returns error if there is a pending configure for the same queue. This operation will block until either success, failure, or timing out happens.
-
Note that the following bmqt::QueueOptions fields cannot be reconfigured after the queue has been opened:
-
-
suspendsOnBadHostHealth Attempts to reconfigure these fields will yield an e_NOT_SUPPORTED error code.
-
-
THREAD: Note that calling this method from the event processing thread(s) (i.e., from the EventHandler callback, if provided) WILL lead to a DEADLOCK.
DEPRECATED: Use the configureQueueAsync(...) with callback flavor instead. This method will be marked as BSLS_ANNOTATION_DEPRECATED in future release of libbmq.
Asynchronously configure the queue identified by the specified queueId using the specified options to configure some advanced settings. The result of the operation is communicated to the specified callback via a bmqa::ConfigureQueueStatus, providing the status and context of the requested operation. If the optionally specified timeout is not populated, use the one defined in the session options.
-
Note that the following bmqt::QueueOptions fields cannot be reconfigured after the queue has been opened:
-
-
suspendsOnBadHostHealth Attempts to reconfigure these fields will yield an e_NOT_SUPPORTED error code.
-
-
THREAD: The callback will ALWAYS be invoked from the EventHandler thread(s) (or if a SessionEventHandler was not specified, from the thread invoking nextEvent).
DEPRECATED: Use the 'closeQueueSync(QueueId *queueId...) instead. This method will be marked as BSLS_ANNOTATION_DEPRECATED in future release of libbmq.
Close the queue identified by the specified queueId and return a result providing the status and context of the operation. If the optionally specified timeout is not populated, use the one defined in the session options. Any outstanding configureQueue request for this queueId will be canceled. This operation will block until either success, failure, or timing out happens. Once this method returns, there is guarantee that no more messages and events for this queueId will be received. Note that successful processing of this request in the broker closes this session's view of the queue; the underlying queue may not be deleted in the broker. When this method returns, the correlationId associated to the queue is cleared.
-
THREAD: Note that calling this method from the event processing thread(s) (i.e., from the EventHandler callback, if provided) WILL lead to a DEADLOCK.
DEPRECATED: Use the closeQueueAsync(...) with callback flavor instead. This method will be marked as BSLS_ANNOTATION_DEPRECATED in future release of libbmq.
Asynchronously close the queue identified by the specified queueId. Any outstanding configureQueue requests will be canceled. The result of the operation is communicated to the specified callback via a bmqa::CloseQueueStatus, providing the status and context of the operation. If the optionally specified timeout is not populated, use the one defined in the session options. Note that successful processing of this request in the broker closes this session's view of the queue; the underlying queue may not be deleted in the broker. The correlationId associated to the queue remains valid until the bmqa::CloseQueueStatus result has been received and processed by the callback, after which it will be cleared and no more messages and events for this queueId will be received.
-
THREAD: The callback will ALWAYS be invoked from the EventHandler thread(s) (or if a SessionEventHandler was not specified, from the thread invoking nextEvent).
DEPRECATED: Use the closeQueueAsync(...) with callback flavor instead. This method will be marked as BSLS_ANNOTATION_DEPRECATED in future release of libbmq.
Return the next available event received for this session. If there is no event available, this method blocks for up to the optionally specified timeout time interval for an event to arrive. An empty time interval for timeout (the default) indicates that the method should not timeout (the method will not return until the next event is available). Return a bmqa::SessionEvent of type bmqt::SessionEventType::e_TIMEOUT if a timeout was specified and that timeout expired before any event was received. Note that this method can only be used if the session is in synchronous mode (ie not using the EventHandler). The behavior is undefined unless the session was started.
Asynchronously post the specified event that must contain one or more Messages. The return value is one of the values defined in the bmqt::PostResult::Enum enum. Return zero on success and a non-zero value otherwise. Note that success implies that SDK has accepted the event and will eventually deliver it to the broker. The behavior is undefined unless the session was started.
Asynchronously confirm the receipt of the specified message. This indicates that the application is done processing the message and that the broker can safely discard it from the queue according to the retention policy set up for that queue. Return 0 on success, and a non-zero value otherwise. Note that success implies that SDK has accepted the message and will eventually send confirmation notification to the broker.
Asynchronously confirm the receipt of the message with which the specified cookie is associated. This indicates that the application is done processing the message and that the broker can safely discard it from the queue according to the retention policy set up for that queue. Return 0 on success, and a non-zero value otherwise. Note that success implies that SDK has accepted the message and will eventually send confirmation notification to the broker.
Asynchronously confirm the receipt of the batch of CONFIRM messages contained in the specified builder. This indicates that the application is done processing all of the messages and that the broker can safely discard them from the queue according to the retention policy set up for that queue. The return value is one of the values defined in the bmqt::GenericResult::Enum enum. Note that in case of success, the instance pointed by the builder will be reset. Also note that success implies that SDK has accepted all of the messages in builder and will eventually send confirmation notification to the broker, whereas failure implies that none of the messages in builder were accepted. Behavior is undefined unless builder is non-null.
Configure this session instance to dump messages to the installed logger at ball::Severity::INFO level according to the specified command that should adhere to the following pattern:
-
IN|OUT|PUSH|ACK|PUT|CONFIRM ON|OFF|100|10s
-
where each token has a specific meaning:
-
-
-IN : incoming (PUSH and ACK) events
-
-OUT : outgoing (PUT and CONFIRM) events
-
-PUSH : incoming PUSH events
-
-ACK : incoming ACK events
-
-PUT : outgoing PUT events
-
-CONFIRM : outgoing CONFIRM events
-
-ON : turn on message dumping until explicitly turned off
-
-OFF : turn off message dumping
-
-100 : turn on message dumping for the next 100 messages
-
-10s : turn on message dumping for the next 10 seconds
-
-
Above, the numerical values 100 and 10 are just for illustration purposes, and application can choose an appropriate positive numeric value for them. Also, pattern is case-insensitive. Return zero if command is valid and message dumping has been configured, non-zero value otherwise. The behavior is undefined unless the session has been started.
Return the queueId associated to this event, if any. The behavior is undefined unless this event corresponds to a queue related event (i.e. OPEN, CONFIGURE, CLOSE, REOPEN).
-
-
-
-
-
-
-
-
-
int bmqa::SessionEvent::statusCode
-
(
-
-
)
-
const
-
-
-
-
-
Return the status code that indicates success or the cause of a failure.
Return a printable description of the error, if statusCode returns non-zero. Return an empty string otherwise.
-
-
-
-
-
-
-
-
-
bsl::ostream& bmqa::SessionEvent::print
-
(
-
bsl::ostream &
-
stream,
-
-
-
-
-
int
-
level = 0,
-
-
-
-
-
int
-
spacesPerLevel = 4
-
-
-
-
)
-
const
-
-
-
-
-
Format this object to the specified output stream at the (absolute value of) the optionally specified indentation level and return a reference to stream. If level is specified, optionally specify spacesPerLevel, the number of spaces per indentation level for this and all of its nested objects. If level is negative, suppress indentation of the first line. If spacesPerLevel is negative format the entire output on one line, suppressing all but the initial indentation (as governed by level). If stream is not valid on entry, this operation has no effect.
Return true if the specified rhs object contains the value of the same type as contained in the specified lhs object and the value itself is the same in both objects, return false otherwise.
Return false if the specified rhs object contains the value of the same type as contained in the specified lhs object and the value itself is the same in both objects, return true otherwise.
-
-
-
-The documentation for this class was generated from the following file:
Letting previous = span() on some thread T, returns an object token which promises:
-
-
-span() will return newSpan when called on thread T, following the construction of token.
-
-span() will return previous when called on thread T, following the destruction of token.
-
-
Note that if token2 = scope(otherSpan) is called on thread T during the lifetime of token, then span() will return otherSpan. After token2 is destroyed, it will again return newSpan.
-
-
-
-The documentation for this class was generated from the following file:
Returns the value currently associated with key, or dflt if no associated value is currently held.
-
Beware that if key is not found and the returned string_view outlives dflt, then the string_view will reference a deallocated address.
-
-
-
-
-
-
-
-
-
void bmqpi::DTSpan::BSLS_KEYWORD_FINAL::put
-
(
-
const bsl::string_view &
-
key,
-
-
-
-
-
const bsl::string_view &
-
value
-
-
-
-
)
-
-
-
-
-
-
Stores the specified value associated with the specified key. Note that if such a key was already stored, then its associated value will be replaced by the supplied one.
-
-
-
-
-
-
-
-
-
bool bmqpi::DTSpan::BSLS_KEYWORD_FINAL::erase
-
(
-
const bsl::string &
-
key
-
)
-
-
-
-
-
-
Erases any value currently associated with key, and returns whether any such value was previously held.
-
-
-
-The documentation for this class was generated from the following file:
Format this object to the specified output stream at the (absolute value of) the optionally specified indentation level and return a reference to stream. If level is specified, optionally specify spacesPerLevel, the number of spaces per indentation level for this and all of its nested objects. If level is negative, suppress indentation of the first line. If spacesPerLevel is negative format the entire output on one line, suppressing all but the initial indentation (as governed by level). If stream is not valid on entry, this operation has no effect.
Return true if rhs object contains the value of the same type as contained in lhs object and the value itself is the same in both objects, return false otherwise.
Return false if rhs object contains the value of the same type as contained in lhs object and the value itself is the same in both objects, return true otherwise.
Return true if the specified buffer is a valid hex representation of a MessageGUID. The behavior is undefined unless buffer is non-null and length of the buffer is equal to e_SIZE_HEX.
Initialize this MessageGUID with the binary representation from the specified buffer, in binary format. Behavior is undefined unless buffer is non-null and of length e_SIZE_BINARY. Return a reference offering modifiable access to this object.
Initialize this MessageGUID with the hexadecimal representation from the specified buffer. Behavior is undefined unless isValidHexRepresentation() returns true for the provided buffer. Return a reference offering modifiable access to this object.
-
-
-
-
-
-
-
-
-
bool bmqt::MessageGUID::isUnset
-
(
-
-
)
-
const
-
-
-
-
-
Return true if the value of this object is not set.
-
-
-
-
-
-
-
-
-
void bmqt::MessageGUID::toBinary
-
(
-
unsigned char *
-
destination
-
)
-
const
-
-
-
-
-
Write the binary representation of this object to the specified destination. Behavior is undefined unless destination is of length e_SIZE_BINARY. Note that destination can later be used to populate a MessageGUID object using fromBinary method.
-
-
-
-
-
-
-
-
-
void bmqt::MessageGUID::toHex
-
(
-
char *
-
destination
-
)
-
const
-
-
-
-
-
Write the hex representation of this object to the specified destination. Behavior is undefined unless destination is of length e_SIZE_HEX. Note that destination can later be used to populate a MessageGUID object using fromHex method.
-
-
-
-
-
-
-
-
-
bsl::ostream& bmqt::MessageGUID::print
-
(
-
bsl::ostream &
-
stream,
-
-
-
-
-
int
-
level = 0,
-
-
-
-
-
int
-
spacesPerLevel = 4
-
-
-
-
)
-
const
-
-
-
-
-
Write the value of this object to the specified output stream in a human-readable format, and return a reference to stream. Optionally specify an initial indentation level. If level is specified, optionally specify spacesPerLevel, whose absolute value indicates the number of spaces per indentation level for this object. If level is negative, suppress indentation of the first line. If spacesPerLevel is negative, format the entire output on one line, suppressing all but the initial indentation (as governed by level). If stream is not valid on entry, this operation has no effect. Note that this human-readable format is not fully specified, and can change without notice. Applications relying on a fixed length format must use toHex method.
Return true if rhs object contains the value of the same type as contained in lhs object and the value itself is the same in both objects, return false otherwise.
Return false if rhs object contains the value of the same type as contained in lhs object and the value itself is the same in both objects, return true otherwise.
This class provides a hashing algorithm for bmqt::MessageGUID. At the time of writing, this algorithm was found to be approximately 4x faster than the default hashing algorithm that comes with bslh package. Performance-critical applications may want to use this hashing algorithm instead of the default one.
Set the maxUnconfirmedMessages to the specified value. The behavior is undefined unless value >= 0. If the specified value is set to 0, it means that the consumer does not receive any messages. This might be useful when the consumer is shutting down and wants to process only pending messages, or when it is unable to process new messages because of transient issues.
"Merges" another QueueOptions into this one, by invoking setF(other.F()) for all fields F for which other.hasF() is true. Returns the instance on which the method was invoked.
Add, or update if it exists, the specified subscription for the specified handle. Return true on success, otherwise return false and load the specified errorDescription with a description of the error. Note that errorDescription may be null if the caller does not care about getting error messages, but users are strongly encouraged to log error string if this API returns failure.
-
EXPERIMENTAL. Do not use until this feature is announced.
Load all handles and subscriptions into the specified snapshot.
-
EXPERIMENTAL. Do not use until this feature is announced.
-
-
-
-
-
-
-
-
-
bsl::ostream& bmqt::QueueOptions::print
-
(
-
bsl::ostream &
-
stream,
-
-
-
-
-
int
-
level = 0,
-
-
-
-
-
int
-
spacesPerLevel = 4
-
-
-
-
)
-
const
-
-
-
-
-
Format this object to the specified output stream at the (absolute value of) the optionally specified indentation level and return a reference to stream. If level is specified, optionally specify spacesPerLevel, the number of spaces per indentation level for this and all of its nested objects. If level is negative, suppress indentation of the first line. If spacesPerLevel is negative format the entire output on one line, suppressing all but the initial indentation (as governed by level). If stream is not valid on entry, this operation has no effect.
Set the DTContext and DTTracer objects needed to integrate with Distributed Trace frameworks. Either both arguments must point to valid instances, or both must be empty shared_ptr's; if either is an empty shared_ptr and the other is not, then behavior is undefined.
DEPRECATED: Use 'configureEventQueue(int lowWatermark, int highWatermark)' instead. This method will be marked as BSLS_ANNOTATION_DEPRECATED in future release of libbmq.
Configure the EventQueue notification watermarks thresholds with the specified lowWatermark and highWatermark value. Refer to the component level documentation for explanation of those watermarks. The behavior is undefined unless lowWatermark < highWatermark.
DEPRECATED: This parameter is no longer relevant and will be removed in future release of libbmq.
-
-
-
-
-
-
-
-
-
bsl::ostream& bmqt::SessionOptions::print
-
(
-
bsl::ostream &
-
stream,
-
-
-
-
-
int
-
level = 0,
-
-
-
-
-
int
-
spacesPerLevel = 4
-
-
-
-
)
-
const
-
-
-
-
-
Format this object to the specified output stream at the (absolute value of) the optionally specified indentation level and return a reference to stream. If level is specified, optionally specify spacesPerLevel, the number of spaces per indentation level for this and all of its nested objects. If level is negative, suppress indentation of the first line. If spacesPerLevel is negative format the entire output on one line, suppressing all but the initial indentation (as governed by level). If stream is not valid on entry, this operation has no effect.
Set the maxUnconfirmedMessages to the specified value. The behavior is undefined unless value >= 0. If the specified value is set to 0, it means that the consumer does not receive any messages. This might be useful when the consumer is shutting down and wants to process only pending messages, or when it is unable to process new messages because of transient issues.
Returns whether maxUnconfirmedMessages has been set for this object, or whether it implicitly holds k_DEFAULT_MAX_UNCONFIRMED_MESSAGES.
-
-
-
-
-
-
-
-
-
bool bmqt::Subscription::hasMaxUnconfirmedBytes
-
(
-
-
)
-
const
-
-
-
-
-
Returns whether maxUnconfirmedBytes has been set for this object, or whether it implicitly holds k_DEFAULT_MAX_UNCONFIRMED_BYTES.
-
-
-
-
-
-
-
-
-
bool bmqt::Subscription::hasConsumerPriority
-
(
-
-
)
-
const
-
-
-
-
-
Returns whether consumerPriority has been set for this object, or whether it implicitly holds k_DEFAULT_CONSUMER_PRIORITY.
-
-
-
-
-
-
-
-
-
bsl::ostream& bmqt::Subscription::print
-
(
-
bsl::ostream &
-
stream,
-
-
-
-
-
int
-
level = 0,
-
-
-
-
-
int
-
spacesPerLevel = 4
-
-
-
-
)
-
const
-
-
-
-
-
Format this object to the specified output stream at the (absolute value of) the optionally specified indentation level and return a reference to stream. If level is specified, optionally specify spacesPerLevel, the number of spaces per indentation level for this and all of its nested objects. If level is negative, suppress indentation of the first line. If spacesPerLevel is negative format the entire output on one line, suppressing all but the initial indentation (as governed by level). If stream is not valid on entry, this operation has no effect.
Format this object to the specified output stream at the (absolute value of) the optionally specified indentation level and return a reference to stream. If level is specified, optionally specify spacesPerLevel, the number of spaces per indentation level for this and all of its nested objects. If level is negative, suppress indentation of the first line. If spacesPerLevel is negative format the entire output on one line, suppressing all but the initial indentation (as governed by level). If stream is not valid on entry, this operation has no effect.
-
-
-
-The documentation for this class was generated from the following file:
Format this object to the specified output stream at the (absolute value of) the optionally specified indentation level and return a reference to stream. If level is specified, optionally specify spacesPerLevel, the number of spaces per indentation level for this and all of its nested objects. If level is negative, suppress indentation of the first line. If spacesPerLevel is negative format the entire output on one line, suppressing all but the initial indentation (as governed by level). If stream is not valid on entry, this operation has no effect.
IMPLICIT: Copy constructor, create a new Uri having the same values as the specified original, and using the optionally specified allocator.
-
-
-
-
-
-
-
-
-
bmqt::Uri::Uri
-
(
-
const bsl::string &
-
uri,
-
-
-
-
-
bslma::Allocator *
-
allocator = 0
-
-
-
-
)
-
-
-
-
-
-
IMPLICIT:
-
-
-
-
-
-
-
-
-
bmqt::Uri::Uri
-
(
-
const bslstl::StringRef &
-
uri,
-
-
-
-
-
bslma::Allocator *
-
allocator = 0
-
-
-
-
)
-
-
-
-
-
-
IMPLICIT:
-
-
-
-
-
-
-
-
-
bmqt::Uri::Uri
-
(
-
const char *
-
uri,
-
-
-
-
-
bslma::Allocator *
-
allocator = 0
-
-
-
-
)
-
-
-
-
-
-
IMPLICIT: Implicit constructor of this object from the specified uri string using the optionally specified allocator. If the uri input string doesn't not represent a valid URI, this object is left in an invalid state (isValid() will return false).
Return the corresponding (extracted) part of the URI, provided as convenient accessors using the BlazingMQ terminology.
-
-
-
-
-
-
-
-
-
bslstl::StringRef bmqt::Uri::canonical
-
(
-
-
)
-
const
-
-
-
-
-
Return the canonical form of the URI. Note that canonical form includes everything except the query part of the URI.
-
-
-
-
-
-
-
-
-
bsl::ostream& bmqt::Uri::print
-
(
-
bsl::ostream &
-
stream,
-
-
-
-
-
int
-
level = 0,
-
-
-
-
-
int
-
spacesPerLevel = 4
-
-
-
-
)
-
const
-
-
-
-
-
Format this object to the specified output stream at the (absolute value of) the optionally specified indentation level and return a reference to stream. If level is specified, optionally specify spacesPerLevel, the number of spaces per indentation level for this and all of its nested objects. If level is negative, suppress indentation of the first line. If spacesPerLevel is negative format the entire output on one line, suppressing all but the initial indentation (as governed by level). If stream is not valid on entry, this operation has no effect.
Set the corresponding field of the URI to the specified value. The behavior is undefined unless value remains valid until URI has been built by invoking uri(). setDomain() and setTier() should be preferred over setQualifiedDomain() whenever possible.
Build and populate the specified result with the built URI, returning 0 on success, or return non-zero on error, populating the optionally specified errorDescription if provided.
-
-
-
-The documentation for this class was generated from the following file:
Set the minor part of the version to the specified value and return a reference to this object.
-
-
-
-
-
-
-
-
-
bsl::ostream& bmqt::Version::print
-
(
-
bsl::ostream &
-
stream,
-
-
-
-
-
int
-
level = 0,
-
-
-
-
-
int
-
spacesPerLevel = 4
-
-
-
-
)
-
const
-
-
-
-
-
Format this object to the specified output stream at the optionally specified indentation level and return a reference to the modifiable stream. If level is specified, optionally specify spacesPerLevel, the number of spaces per indentation level for this and all of its nested objects. Each line is indented by the absolute value of level * spacesPerLevel. If level is negative, suppress indentation of the first line. If spacesPerLevel is negative, suppress line breaks and format the entire output on one line. If stream is initially invalid, this operation has no effect. Note that a trailing newline is provided in multiline mode only.
-
-
-
-
-
-
-
-
-
unsigned char bmqt::Version::major
-
(
-
-
)
-
const
-
-
-
-
-
Return the major part of the version.
-
-
-
-
-
-
-
-
-
unsigned char bmqt::Version::minor
-
(
-
-
)
-
const
-
-
-
-
-
Return the minor part of the version.
-
-
-
-The documentation for this class was generated from the following file:
BlazingmQ (package group bmq) is a message-queue framework allowing application developers to use reliable distributed queues.
-
The bmqa and bmqt packages contain all components that constitute the public API for BlazingmQ users to use. A client should only use the components in these packages, and should not use any other package under the bmq package group since they are implementation components that may change at any time.
-
-
-
Hierarchical Synopsis:
The bmq group library currently has 5 packages forming 5 levels of physical dependency.
bmqa:
- Provide applications public API for the BlazingmQ SDK.
-
bmqimp:
- [INTERNAL] Provide implementation for the API of the BlazingMQ SDK.
-
bmqp:
- [INTERNAL] Provide BlazingMQ protocol definition, builders and parsers.
-
bmqscm:
- Provide versioning information for library components in bmq.
-
bmqt:
- Provide value-semantic vocabulary types.
-
-
-
-
Package Overview:
The following provides a brief overview of several of the packages within the bmq package group, arranged in alphabetical order. The descriptions here are still very brief; see the respective Package Level documents for more details and usage examples.
-
-
-
bmqa:
bmqa provides the top-level public APIs application can use to interact with BlazingMQ framework in their applications.
-
-
-
bmqt:
bmqt provides value-semantic vocabulary types used in the bmqa APIs.
This component provides a specific value-semantic type for the result of a close queue operation with the BlazingMQ broker, providing applications with the result and context of the requested operation.
-result: indicates the status of the operation (success, failure, etc.) as specified in the corresponding result code enum, bmqt::CloseQueueResult::Enum
-
-queueId: queueId associated with the close queue operation
-
-errorDescription: optional string with a human readable description of the error, if any
This component provides a specific value-semantic type for the result of a configure queue operation with the BlazingMQ broker, providing applications with the result and context of the requested operation.
-result: indicates the status of the operation (success, failure, etc.) as specified in the corresponding result code enum, bmqt::ConfigureQueueResult::Enum
-
-queueId: queueId associated with the configure queue operation
-
-errorDescription: optional string with a human readable description of the error, if any
This component implements a mechanism, bmqa::ConfirmEventBuilder, that can be used for batching CONFIRM messages. The resulting batch can be sent to the BlazingMQ broker using the bmqa::Session (refer to bmqa_session for details). Wherever possible, a BlazingMQ consumer should try to send a batch of CONFIRM messages, which is more efficient than confirming messages individually.
-
The builder holds a batch of CONFIRM messages under construction, and provides two flavors of addMessageConfirmation method to add a CONFIRM message to the batch. It also provides a routine to retrieve number of CONFIRM messages added to the batch. Once application is done creating the batch, it can retrieve the blob (wire-representation) of the batch and send it via bmqa::Session. See Usage section for more details.
-
-
-
Usage:
-
-An instance of bmqa::ConfirmEventBuilder (the builder) can be used to create multiple batches of CONFIRM messages. The recommended approach is to create one instance of the builder and use it throughout the lifetime of the task (if the task is multi-threaded, an instance per thread must be created and maintained). See usage example #1 for an illustration.
-
-The lifetime of an instance of the builder is bound by the bmqa::Session from which it was created. In other words, bmqa::Session instance must outlive the builder instance.
-
-
-
-
-
Example 1 - Basic Usage:
// In this snippet, we will send a batch of CONFIRMs for all the
- // 'bmqa::Message' messages received in a 'bmqa::MessageEvent'.
-
- // Note that error handling is omitted from the snippet for the sake of
- // brevity.
-
- bmqa::Session session;
- // Session start up logic elided.
-
- // Create and load an instance of the ConfirmEventBuilder. Note that in
- // this example, we are creating the builder on the stack everytime a
- // message event is received. Another approach can be to maintain the
- // builder as a data member and use it everytime.
-
- bmqa::ConfirmEventBuilder builder;
- session.loadConfirmEventBuilder(&builder);
-
- // Assuming that a 'bmqa::MessageEvent' is received.
-
- bmqa::MessageIterator iter = messageEvent.messageIterator();
- while (iter.nextMessage()) {
- constbmqa::Message& msg = iter.message();
-
- // Business logic for processing 'msg' elided.
-
- int rc = builder.addMessageConfirmation(msg);
- // Error handling elided.
- }
-
- // All messages in the event have been processed and their corresponding
- // CONFIRM messages have been batched. Now its time to send the batch to
- // the BlazingMQ broker.
-
- int rc = session.confirmMessages(&builder);
- // Error handling elided. Note that in case of success, above method
- // will also reset the 'builder'.
-
-
-
-
Thread Safety:
This component is NOT thread safe. If it is desired to create a batch of CONFIRM messages from multiple threads, an instance of the builder must be created and maintained perthread.
This component provides a generic bmqa::Event notification object used by the bmqa::Session to provide BlazingMQ applications with information regarding the status of the session or data coming from queues. This bmqa::Event object is only used when user wants to process messages from the EventQueue using its own thread, by calling the bmqa::Session::nextEvent method.
-
A bmqa::Event can either be a bmqa::SessionEvent or a bmqa::MessageEvent. The former describes notifications such as the result of a session start or the opening of a queue. The latter carries application messages retrieved from a queue.
-
Note that event is implemented using the pimpl idiom, so copying an event is very cheap (a pointer copy). All copies of this bmqa::Event, as well as any SessionEvent or MessageEvent extracted from it will share the same underlying implementation.
A bmqa::Message represents the data message to put on a queue, or retrieved from a queue. It is composed of the following fields:
-
-
-A message GUID, which is a printable string generated by the broker to uniquely identify this message.
-
-A correlation Id, which is a user-provided identifier for the message.
-
-A queue Id, to map with the queue this message is associated with.
-
-The payload, which is opaque to the framework. At some point, framework may provide utilities to encode and decode schema messages using various CODECs. For example, a JavaScript publisher may publish a message into a queue using a JSON object as payload, and the consumer may be receiving that payload as a BER-encoded schema object.
-
-At some point, system properties such as version, encoding, timestamp, priority, message group and "reply-to" will be supported. System properties will be used by the broker; for example to deliver high-priority messages first or to filter based on a minimum version.
-
-At some point, application-defined message properties will also be supported, where properties are a list of name-value pairs.
-
-
-
A bmqa::MessageConfirmationCookie is a small object which allows to confirm a bmqa::Message asynchronously without having to hold on to the entire message. This can be useful when, for example, the message is decoded in the event handler, and the resulting object is enqueued for asynchronous processing, along with that small cookie object for confirming the message once successfully processed.
This component provides a bmqa::MessageEvent notification object used by the bmqa::Session to provide BlazingMQ applications with data messages received from the broker. The application can consume the messages by asking this MessageEvent for a MessageIterator.
-
Note that MessageEvent is implemented using the pimpl idiom, so copying a MessageEvent is very cheap (a pointer copy). All copies of this MessageEvent will share the same underlying implementation.
This component implements a mechanism, bmqa::MessageEventBuilder, that can be used for creating message events containing one or multiple messages. The resulting MessageEvent can be sent to the BlazingMQ broker using the bmqa::Session (refer to bmqa_session for details).
-
The builder holds a MessageEvent under construction, and provides methods to return a reference to the current message (in order to set its various members), as well as to append a new message. Once the application is done, the builder provides a method to get the message event that has been constructed. See Usage section for more details.
-
Note that publishing events containing multiple messages may be more efficient than events limited to a single message for applications that send large volume of small messages.
-
-
-
Usage:
-
-An instance of bmqa::MessageEventBuilder (the builder) can be used to create multiple bmqa::MessageEvent's, as long as the instance is reset in between. This reset is preferably to do right after sending the event to guarantee that all user resources bound to the bmqa::MessageEvent (e.g. CorrelationIds with user's shared_ptr) are kept no longer than expected (e.g. until related ACK event is received). The recommended approach is to create one instance of the builder and use that throughout the lifetime of the task (if the task is multi-threaded, an instance per thread must be created and maintained). See usage example #1 for an illustration.
-
-The lifetime of an instance of the builder is bound by the bmqa::Session from which it was created. In other words, bmqa::Session instance must outlive the builder instance.
-
-If it is desired to post the same bmqa::Message to different queues, packMessage can be called multiple times in a row with different queue IDs. The builder will append the previously packed message with the new queue ID to the underlying message event. Note that after calling packMessage, the message keeps all the attributes (payload, properties, etc) that were previously set (except for the correlationId which must be set explicitly for each individual message). If desired, any attribute can be tweaked before being packing the message again. Refer to usage example #2 for an illustration.
-
-
-
-
-
Example 1 - Basic Usage:
// Note that error handling is omitted below for the sake of brevity
-
- bmqa::Session session;
- // Session start up logic omitted for brevity.
-
- // Obtain a valid instance of message properties.
- bmqt::MessageProperties properties;
- session.loadMessageProperties(&properties);
-
- // Set common properties that will be applicable to all messages sent by
- // this application.
- int rc = properties.setPropertyAsChar(
- "encoding",
- static_cast<char>(MyEncodingEnum::e_BER));
-
- rc = properties.setPropertyAsString("producerId", "MyUniqueId");
-
- // Obtain a valid instance of message event builder.
- bmqa::MessageEventBuilder builder;
- session.loadMessageEventBuilder(&builder);
-
- // Create and post a message event containing 1 message. Associate
- // properties with this message.
- bmqa::Message& msg = builder.startMessage();
-
- msg.setCorrelationId(myCorrelationId);
-
- // Set payload (where 'myPayload' is of type 'bdlbb::Blob')
- msg.setDataRef(&myPayload);
-
- // Set current timestamp as one of the properties.
- rc = properties.setPropertyAsInt64(
- "timestamp",
- bdlt::EpochUtil::convertToTimeT64(bdlt::CurrentTime::now()));
-
- // Set properties.
- msg.setPropertiesRef(&properties);
-
- // Pack the message.
- rc = builder.packMessage(myQueueId);
-
- // Post message event
- rc = session.post(builder.messageEvent());
-
-
- // Create and post another message event containing 1 message.
-
- // bmqa::MessageEventBuilder must be reset before reuse.
- builder.reset();
-
- // Start a new message.
- bmqa::Message& msg = builder.startMessage();
-
- msg.setCorrelationId(myAnotherCorrelationId);
- msg.setDataRef(&myAnotherPayload);
-
- // It's okay (and recommended) to use same properties instance.
- rc = properties.setPropertyAsInt64(
- "timestamp",
- bdlt::EpochUtil::convertToTimeT64(bdlt::CurrentTime::now()));
-
- msg.setPropertiesRef(&properties);
- rc = builder.packMessage(myAnotherQueueId);
-
- // Post second message event
- rc = session.post(builder.messageEvent());
-
- // Reset the builder to free resources earlier.
- builder.reset();
-
-
-
-
Example 2 - Packing multiple messages in a message event:
// Note that error handling is omitted below for the sake of brevity
-
- bmqa::Session session;
- // Session start up logic omitted for brevity.
-
- // Obtain a valid instance of message properties.
- bmqt::MessageProperties properties;
- session.loadMessageProperties(&properties);
-
- // Set common properties that will be applicable to all messages sent by
- // this application.
- int rc = properties.setPropertyAsChar(
- "encoding",
- static_cast<char>(MyEncodingEnum::e_BER));
-
- rc = properties.setPropertyAsString("producerId", "MyUniqueId");
-
- // Obtain a valid instance of message event builder.
- bmqa::MessageEventBuilder builder;
- session.loadMessageEventBuilder(&builder);
-
- // Create and post a message event containing 4 messages.
- bmqa::Message& msg = builder.startMessage();
-
- // Pack message #1
- msg.setCorrelationId(correlationId1);
- msg.setDataRef(&payload1); // where 'payload1' is of type 'bdlbb::Blob'
-
- // Set current timestamp as one of the properties.
- int rc = properties.setPropertyAsInt64(
- "timestamp",
- bdlt::EpochUtil::convertToTimeT64(bdlt::CurrentTime::now()));
-
- // Pack the message.
- rc = builder.packMessage(queueId1);
-
- // Pack message #2
- // We want to send message #1 to another queue. In order to do so, we
- // just update the correlation ID of message #1. There is no need to set
- // the payload or properties again. Because 'payload1' and 'properties'
- // objects are being reused for the second message, they should not be
- // destroyed before packing the second message.
-
- msg.setCorrelationId(correlationId2);
-
- // Also note that the "timestamp" property for the second message will be
- // updated for this message. There is no need to invoke
- // 'setPropertiesRef' on the message though.
- rc = properties.setPropertyAsInt64(
- "timestamp",
- bdlt::EpochUtil::convertToTimeT64(bdlt::CurrentTime::now()));
-
- rc = builder.packMessage(queueId2);
-
- // 'payload1' can be safely destroyed at this point if it will not be
- // reused again for another message.
-
- // Pack message #3
- // Message #3 has a different payload, no properties and destined to
- // 'queueId1'.
- msg.setCorrelationId(correlationId3);
- msg.setDataRef(&payload2); // where 'payload2' is of type 'bdlbb::Blob'
-
- // We need to explicitly clear out the associated properties.
- msg.clearProperties();
-
- rc = builder.packMessage(queueId1);
-
- // Pack message #4
- // Message #4 has different payload and destined to 'queueId3'.
- msg.setCorrelationId(correlationId4);
- msg.setDataRef(&payload3); // where 'payload3' is of type 'bdlbb::Blob'
-
- // Update "timestamp" property.
- rc = properties.setPropertyAsInt64(
- "timestamp",
- bdlt::EpochUtil::convertToTimeT64(bdlt::CurrentTime::now()));
-
- // Need to associate properties with the message, since they were cleared
- // out while packing message #3 above.
- msg.setPropertiesRef(&properties);
-
- rc = builder.packMessage(queueId3);
-
- // Post second message event
- rc = session.post(builder.messageEvent());
-
- // Reset the builder to free resources earlier.
- builder.reset();
-
bmqa::MessageProperties provides a VST representing message properties. Message properties are a collection of name-value pairs that producer can associate with a message, and consumer can retrieve from the corresponding message. In order to keep their usage flexible, no schema is enforced for the message properties, and their format (names and data types) should be negotiated by producers and consumers. Message properties can be used for routing, pipelining or filtering messages within the application. It can be efficient to specify such message attributes in the properties instead of the message payload, because application does not have to decode entire payload to retrieve these attributes. bmqa::MessagePropertiesIterator provides a mechanism to iterate over all the properties of a bmqa::MessageProperties object.
This component provides a mechanism implementing the bmqa::AbstractSession protocol, for mocking a bmqa::Session and can be used to write a test for an application that uses BMQ. The bmqa::MockSession provides all the methods that Session provides, with added methods to specify return codes and emitted events and expected calls. This can be used to test BlazingMQ application code without a connection to the broker. bmqa::MockSessionUtil is a utility namespace providing useful methods to build bmqa::Event objects that are typically only emitted from the broker.
-
The following documentation elucidates the API that this component provides and some simple use cases to get you started.
-
-
-
-
Disclaimer:
THIS COMPONENT SHOULD ONLY BE USED IN TEST DRIVERS. IT WILL NOT WORK WITH PRODUCTION CODE.
-
-
-
-
Usable Components:
-
-BMQA_EXPECT_CALL: Macro to specify an expected call to a bmqa::MockSession object. This macro is used to specify which is the next expected call on the bmqa::MockSession. If an incorrect call is invoked or incorrect parameters are used, an assert will be invoked.
-
-
-
-
-returning : Specify a return value for the expected call. This is the value that will be returned when the method on bmqa::MockSession is invoked.
-
-
-
-
-emitting : Specify an event to be emitted when the expected call is invoked. The events specified are enqueued to the internal event queue and are delivered to the application when emitEvent is invoked.
-
-
-
-
-
Static Helper Methods:
-
-createAckEvent : Create an acknowledgment message event for messages posted to BMQ.
-
-
-
-
-createPushEvent : Create a push message event for messages to be consumed from BMQ.
-
-
-
-
-createOpenQueueStatus : Create an openQueue result (relating to an async open queue operation)
-
-
-
-
-createConfigureQueueStatus: Create a configureQueue result (relating to an async configure queue operation)
-
-
-
-
-createCloseQueueStatus : Create a closeQueue result (relating to an async close queue operation)
-
-
-
-
-createSessionEvent : Create a specified type of session event except for events related to open, close and configure queue.
-
-
-
The static event builder specified above are typically built inside the broker but are now available to be built in the SDK. The expected use of such events is to build them and specify them to either the BMQA_EXPECT_CALL macro in the emitting parameter, or enqueued to the bmqa::MockSession directly through the enqueueEvent method. They can then be emitted by invoking the emitEvent method, which in turn would be processed through the application-provided bmqa::SessionEventHandler.
-
-
-
Additional Note:
MockSession does not check if methods have been invoked in the correct order. The user is responsible for ensuring that the methods are invoked and events enqueued in the correct order.
-
The following methods do not emit events:
-
-getQueueId
-
-loadMessageEventBuilder
-
-loadConfirmEventBuilder
-
-loadMessageProperties
-
-confirmMessage
-
-confirmMessages
-
-
-
Calls to the following methods do not require an expect:
-
-getQueueId
-
-loadMessageEventBuilder
-
-loadConfirmEventBuilder
-
-loadMessageProperties
-
-
-
-
-
-
Creating a mock session in asynchronous mode:
The MockSession is created in asynchronous mode when a SessionEventHandler is provided to it. If it is not provided a handler, the MockSession is started in synchronous mode, requiring the application to call nextEvent to access enqueued events. A sample handler could look like this:
This section illustrates intended use of this component.
-
-
-
Example 1:
The folowing example shows a simple producer in asynchronous mode, which will start the session, open a queue, post a message to the queue, generate an ack for that message and finally stop the session (skipping over close queue because it is analogous to opening a queue). In theory, you can use emitting on the BMQA_EXPECT_CALL macro and enqueueEvent interchangeably, but in practice it is important to note that events from the broker are generated asynchronously, which means that they are not emitted as you call the method. You can control emission of events, however, by delaying the call to emitEvent.
-
NOTE: As with bmqa::Session, calling nextEvent is meaningless in asynchronous mode.
-
void unitTest()
- {
- // Create an event handler
- EventHandler eventHandler(d_allocator_p);
-
- // The following static initializer method calls all the appropriate
- // static initializers of the underlying components needed for the
- // 'MockSession'. The constructor of 'MockSession' will call it in
- // any case but if events need to be built outside the scope of the
- // creation of 'MockSession' you will need to explicitly invoke this
- // static initializer method.
- // bmqa::MockSession::initialize(s_allocator_p);
-
- bslma::ManagedPtr<bmqa::SessionEventHandler> handlerMp;
- handlerMp.load(&eventHandler, 0, bslma::ManagedPtrUtil::noOpDeleter);
-
- bmqa::MockSession mockSession(handlerMp,
- bmqt::SessionOptions(d_allocator_p),
- d_allocator_p);
-
- bmqa::QueueId queueId(bmqt::CorrelationId(1), d_allocator_p);
- bmqt::CorrelationId corrId(1);
-
- // Expect a call to start and the call emits an 'e_CONNECTED' event.
- BMQA_EXPECT_CALL(mockSession, startAsync())
- .returning(0)
- .emitting(bmqa::MockSessionUtil::createSessionEvent(
- bmqt::SessionEventType::e_CONNECTED,
- 0, // statusCode
- "", // errorDescription
- d_allocator_p));
-
- // Make a call to startAsync and emit the event that is enqueued from
- // that call.
- ASSERT_EQ(mockSession.startAsync(), 0);
-
- // Emit our enqueued event. This fully sets up the session which is
- // now ready to use. Typically you would have some business logic on
- // 'e_CONNECTED' that makes your application ready to use.
- ASSERT_EQ(mockSession.emitEvent(), true);
-
- // Our event handler internally just stores the event emitted, so pop
- // it out and examine.
- bmqa::SessionEvent startEvent(eventHandler.popSessionEvent());
-
- ASSERT_EQ(startEvent.type(), bmqt::SessionEventType::e_CONNECTED);
- ASSERT_EQ(startEvent.statusCode(), 0);
-
- // Create the uri to your queue as you would in your application.
- constbmqt::Uri uri("bmq://my.domain/queue");
-
- // Initialize the queue flags for a producer with acks enabled
- bsls::Types::Uint64 flags = 0;
- bmqt::QueueFlagsUtil::setWriter(&flags);
- bmqt::QueueFlagsUtil::setAck(&flags);
-
- // We use the macro to expect a call to 'openQueueAsync', binding the
- // 'uri' and 'queueId' objects as well as the 'flags' that we created.
- bmqa::MockSession::OpenQueueCallback openQueueCallback =
- bdlf::BindUtil::bind(&EventHandler::onOpenQueueStatus,
- &eventHandler,
- bdlf::PlaceHolders::_1); // result
-
- BMQA_EXPECT_CALL(mockSession,
- openQueueAsync(uri1,
- flags,
- openQueueCallback));
- BMQA_EXPECT_CALL(mockSession,
- openQueueAsync(uri, flags, openQueueCallback));
-
- // Now that we have set our expectations we can try to open the queue.
- mockSession.openQueueAsync(uri1, flags, openQueueCallback);
-
- // Since the application may not have direct access to the queue, we
- // need to get the 'queueId' from the session. We can then bind this
- // retrieved 'queueId' to the 'e_QUEUE_OPEN_RESULT' session event and
- // enqueue it to the 'MockSession'.
- // Note: You can only get the 'queueId' after 'openQueue' or
- // 'openQueueAsync' has been invoked on the session.
- bmqa::QueueId queueId1(corrId1);
- bmqa::OpenQueueStatus openQueueResult =
- bmqa::MockSessionUtil::createOpenQueueStatus(
- queueId1,
- bmqt::OpenQueueResult::e_TIMEOUT, // statusCode
- "Local Timeout", // errorDescription
- d_allocator_p);
- mockSession.enqueueEvent(openQueueResult);
-
- // We just enqueued a 'bmqa::OpenQueueStatus' to be emitted. We can
- // emit it using 'emitEvent'.
- ASSERT_EQ(mockSession.emitEvent(), true);
-
- // Pop out this event from the handler and examine it.
- bmqa::OpenQueueStatus result = eventHandler.popOpenQueueStatus();
- ASSERT_EQ(result, openQueueResult);
-
- // On emission of 'bmqa::OpenQueueStatus', the queue is fully open and
- // we can now post to it.
- bmqa::MessageEventBuilder builder;
- mockSession.loadMessageEventBuilder(&builder);
-
- BMQA_EXPECT_CALL(mockSession, post(builder.messageEvent()))
- .returning(0);
-
- // Use the builder to build a mesage event and pack it for the queue
- // that has been opened. If you try to pack the message for an
- // invalid or closed queue, packing the message will fail. This has
- // been elided for brevity.
-
- // Now that the event has been built we can 'post' it to BMQ.
- ASSERT_EQ(mockSession.post(builder.messageEvent()), 0);
-
- // Simply creating a blob buffer factory on the stack to be used by
- // 'createAckEvent'. Typically you would have one for the component.
- bdlbb::PooledBlobBufferFactory bufferFactory(4 * 1024, d_allocator_p);
-
- // The method 'createAckEvent' takes a vector of 'AckParams' to
- // specify multiple acks per event, but here we are only acknowledging
- // 1 message. Specify a positive ack with 'e_SUCCESS' here but you
- // can specify any from 'bmqt::AckResult::Enum'.
- bsl::vector<bmqa::MockSessionUtil::AckParams> acks(d_allocator_p);
- acks.emplace_back(bmqt::AckResult::e_SUCCESS,
- bmqt::CorrelationId(1),
- bmqt::MessageGUID(), // Real GUID needed if you want
- // to record ack messages.
- bmqa::QueueId(1));
-
- // Enqueuing ack event to be emitted. We use the helper function
- // 'createAckEvent' to generate this event.
- mockSession.enqueueEvent(bmqa::MockSessionUtil::createAckEvent(
- acks,
- &bufferFactory,
- d_allocator_p));
-
- // Emit the enqueued ack event.
- ASSERT_EQ(mockSession.emitEvent(), true);
-
- // As we did earlier, pop it out and examine.
- bmqa::MessageEvent ackEvent(eventHandler.popMessageEvent());
- ASSERT_EQ(ackEvent.type(), bmqt::MessageEventType::e_ACK);
- bmqa::MessageIterator mIter = ackEvent.messageIterator();
- mIter.nextMessage();
- ASSERT_EQ(mIter.message().ackStatus(), bmqt::AckResult::e_SUCCESS);
-
- // This is a simple test. After posting our message and receiving the
- // ack, we are now shutting down our application. Therefore we expect
- // a 'stopAsync' call.
- BMQA_EXPECT_CALL(mockSession, stopAsync());
-
- // Now make a call to 'stopAsync' to stop our session.
- mockSession.stopAsync();
-
- // Here we are enqueuing an 'e_DISCONNECTED' event as you would
- // receive from the broker on a successful shutdown.
- mockSession.enqueueEvent(bmqa::MockSessionUtil::createSessionEvent(
- bmqt::SessionEventType::e_DISCONNECTED,
- 0, // statusCode
- "", // errorDescription
- d_allocator_p));
- ASSERT_EQ(mockSession.emitEvent(), true);
-
- // Our event handler internally just stores the event emitted, so pop
- // it out and examine.
- bmqa::SessionEvent stopEvent(eventHandler.popSessionEvent());
- ASSERT_EQ(stopEvent.type(), bmqt::SessionEventType::e_DISCONNECTED);
- ASSERT_EQ(stopEvent.statusCode(), 0);
-
- // The corresponding pendant operation of the 'initialize' which would
- // need to be called only if 'initialize' was explicitly called.
- // bmqa::MockSession::shutdown();
- }
-
-
-
-
Example 2:
The folowing example shows a consumer in synchronous mode, which will start the session, generate a push message (simulating the broker), confirm the message and then stop the session. Additionally, this test case also sets all expectations up front before running the code, as this is the alternate way of writing your test driver.
-
NOTE: Using enqueue or emitEvent on bmqa::MockSession or emitting on the BMQA_EXPECT_CALL macro in synchronous mode is meaningless.
-
void unitTest()
- {
- // MockSession created without an eventHandler.
- bmqa::MockSession mockSession(bmqt::SessionOptions(d_allocator_p),
- d_allocator_p);
-
- // The following static initializer method calls all the appropriate
- // static initializers of the underlying components needed for the
- // 'MockSession'. The constructor of 'MockSession' will call it in
- // any case but if events need to be built outside the scope of the
- // creation of 'MockSession' you will need to explicitly invoke this
- // static initializer method.
- // bmqa::MockSession::initialize(s_allocator_p);
-
- // Create simple queueIds and corrIds
- bmqa::QueueId queueId(1);
- bmqt::CorrelationId corrId(1);
-
- // Create the uri to your queue as you would in your application.
- bmqt::Uri uri("bmq://my.domain/queue");
-
- // Expecting that 'startAsync' will be called on the MockSession.
- BMQA_EXPECT_CALL(mockSession, startAsync())
- .returning(0);
-
- // Simply creating a blob buffer factory on the stack to be used by
- // 'createAckEvent'. Typically you would have one for the component.
- bdlbb::PooledBlobBufferFactory bufferFactory(4 * 1024, d_allocator_p);
-
- // We then expect that 'nextEvent' will be called to return the
- // 'e_CONNECTED' event from the broker
- BMQA_EXPECT_CALL(mockSession, nextEvent(bsls::TimeInterval()))
- .returning(bmqa::MockSessionUtil::createSessionEvent(
- bmqt::SessionEventType::e_CONNECTED,
- bmqt::CorrelationId::autoValue(),
- 0, // errorCode
- "", // errorDescription
- d_allocator_p));
- // Note that we use an 'autoValue' for correlationId because it's
- // irrelevant for a 'CONNECTED' event.
-
- // Initialize the queue flags for a consumer
- bsls::Types::Uint64 flags = 0;
- bmqt::QueueFlagsUtil::setReader(&flags);
-
- // We use the macro to expect a call to 'openQueueSync', binding the
- // 'uri' and 'queueId' objects as well as the flags that we created.
- // Note that the 'queueId' object will be modified as 'openQueueSync'
- // takes it as an output parameter.
- bmqa::OpenQueueStatus expectedResult =
- bmqa::MockSessionUtil::createOpenQueueStatus(
- queueId,
- bmqt::OpenQueueResult::e_SUCCESS, // statusCode
- "", // errorDescription
- d_allocator_p);
- BMQA_EXPECT_CALL(mockSession, openQueueSync(&queueId, uri, flags))
- .returning(expectedResult);
-
- // Build our incoming message event.
- bsl::vector<bmqa::MockSessionUtil::PushMessageParams> pushMsgs(
- d_allocator_p);
- bdlbb::Blob payload(&bufferFactory, d_allocator_p);
- bdlbb::BlobUtil::append(&payload, "hello", 6);
-
- constchar guidHex[] = "00000000000000000000000000000001";
- bmqt::MessageGUID guid;
- guid.fromHex(guidHex);
-
- bmqa::MessageProperties properties;
- mockSession.loadMessageProperties(&properties);
-
- // For each message that we are supposed to receive from the broker,
- // we need to specify the payload, the queueId, a guid (the hex is
- // random but unique within your test driver) and properties which
- // could be empty.
- pushMsgs.emplace_back(payload, queueId, guid, properties);
- bmqa::Event pushMsgEvent = bmqa::MockSessionUtil::createPushEvent(
- pushMsgs,
- &bufferFactory,
- d_allocator_p);
- BMQA_EXPECT_CALL(mockSession, nextEvent(bsls::TimeInterval()))
- .returning(pushMsgEvent);
-
- // Next we expect a call to 'confirmMessages', to confirm the 1 message
- // that we received from the broker.
- bmqa::ConfirmEventBuilder confirmBuilder;
- mockSession.loadConfirmEventBuilder(&confirmBuilder);
- BMQA_EXPECT_CALL(mockSession, confirmMessages(&confirmBuilder))
- .returning(0);
-
- // Expectations have been set up. Now we run the code.
- // 'startAsync' is the first call. We expect it to return 0 and we
- // expect 'nextEvent' to return the 'e_CONNECTED' session event.
- int rc = mockSession.startAsync();
- ASSERT_EQ(rc, 0);
- bmqa::SessionEvent startEvent = mockSession.nextEvent(
- bsls::TimeInterval())
- .sessionEvent();
- ASSERT_EQ(startEvent.type(), bmqt::SessionEventType::e_CONNECTED);
- ASSERT_EQ(startEvent.statusCode(), 0);
- ASSERT_EQ(startEvent.errorDescription(), "");
-
- // Next we expect a call to 'openQueue' to open the queue.
- bmqa::OpenQueueStatus result = mockSession.openQueueSync(&queueId,
- uri,
- 10);
- ASSERT_EQ(result, expectedResult);
-
- // Now our call to 'nextEvent' will generate a push message from the
- // broker, which we will then go on to confirm.
- bmqa::MessageEvent pushMsgEvt(mockSession.nextEvent(
- bsls::TimeInterval())
- .messageEvent());
- ASSERT_EQ(pushMsgEvt.type(), bmqt::MessageEventType::e_PUSH);
-
- // Now that we have received a push message which has yet to be
- // confirmed, we can confirm that 1 unconfirmed message exists.
- ASSERT_EQ(mockSession.unconfirmedMessages(), 1U);
-
- // Since there is only 1 message in our message event, we dont have to
- // iterate over the event but in reality you will want to iterate over
- // each message and add it to the confirm builder.
- bmqa::MessageIterator mIter = pushMsgEvt.messageIterator();
- mIter.nextMessage();
- confirmBuilder.addMessageConfirmation(mIter.message());
- ASSERT_EQ(confirmBuilder.messageCount(), 1);
-
- // Confirm the messages using the builder that has been populated.
- rc = mockSession.confirmMessages(&confirmBuilder);
- ASSERT_EQ(rc, 0);
-
- // Voila! We now have no unconfirmed messages.
- ASSERT_EQ(mockSession.unconfirmedMessages(), 0u);
- // 'stop' has been elided for brevity and is analogous to 'start'
-
- // The corresponding pendant operation of the 'initialize' which would
- // need to be called only if 'initialize' was explicitly called.
- // bmqa::MockSession::shutdown();
- }
-
This component provides a specific value-semantic type for the result of an open queue operation with the BlazingMQ broker, providing applications with the result and context of the requested operation.
-result: indicates the status of the operation (success, failure, etc.) as specified in the corresponding result code enum, bmqt::OpenQueueResult::Enum
-
-queueId: queueId associated with the open queue operation
-
-errorDescription: optional string with a human readable description of the error, if any
This component implements a value-semantic class, bmqa::QueueId, which can be used to efficiently identify the queue associated with a message event. A bmqa::QueueId instance can be created with a 64-bit integer, raw pointer, shared pointer, or bmqt::CorrelationId.
This component provides a mechanism, bmqa::Session, that provides access to a message queue broker and an interface, bmqa::SessionEventHandler for asynchronous notification of events. The broker manages named, persistent queues of messages. This broker allows a client to open queues, post messages to them, or retrieve messages from them. All of these operations take place within the context of the session opened by the client application.
-
Messages received from a broker are communicated to the application by the session associated with that broker in the form of events (see bmqa_event). Events can be of two different types: (1) Messages and message status events (bmqa::MessageEvent), or (2) Session or queue status events (bmqa::SessionEvent).
-
A Session can dispatch events to the application in either a synchronous or asynchronous mode. In synchronous mode, the application must call the nextEvent method in order to obtain events from the Session. In asynchronous mode, the application must supply a concrete SessionEventHandler object at construction time. The concrete SessionEventHandler provided by the application must implement the onSessionEvent and onMessageEvent methods, which will be called by the Session every time a session event or a message event is received. Note that by default, a session created in asynchronous mode creates only one internal thread to dispatch events, but a different value for number of threads can be specified in bmqt::SessionOptions.
-
A Session is created either in synchronous or in asynchronous mode, and it will remain in that mode until destruction. Allowing a mix between synchronous or asynchronous would make the SDK complicated. The only exceptions are the "start" and "open" operations that must be available in synchronous or asynchronous version for the convenience of the programmer.
-
By default a Session connects to the local broker, which in turn may connect to a remote cluster based on configuration.
-
After a bmqa::Session is started, the application has to open one or several queues in read and/or write mode.
-
-
-
Disclaimer:
A Session object is a heavy object representing the negotiated TCP session with the broker, and the entire associated state (opened queues, statistics, ...). Therefore, sessions should be always reused if possible, preferably with only one session per lifetime of a component/library/task. Note that at the time of this writing multiplexing of different logical sessions over the same physical connection is not supported, so in certain circumstances reuse of the same session across the whole of a single application will not be possible. For example, if an application uses two unrelated libraries both of which use BlazingMQ under the hood, they won't be able to share a session as it stands. An example of an extreme inefficiency and an abuse of resources is to create a session ad-hoc every time a message needs to be posted by the same component.
-
-
-
Thread-safety:
This session object is threadenabled, meaning that two threads can safely call any methods on the sameinstance without external synchronization.
-
-
-
Connecting to the Broker:
A Session establishes a communication with a broker service using TCP/IP. Each Session object must be constructed with a bmqa::SessionOptions object, which provides the necessary information to connect to the broker. In particular, the SessionOptions object must specify the IP address and port needed to connect to the broker. The SessionOptions object may also provide extra parameters for tuning the TCP connection behavior (see bmqa_sessionoptions for details).
-
Note that in most cases the user does not need to explicitly construct a SessionOptions object: the default constructor for SessionOptions creates an instance that will connect to the broker service on the local machine using the standard port.
-
Some options can also be provided using environment variables.
-
-BMQ_BROKER_URI: Corresponds to SessionOptions::brokerUri. If this environment variable is set, its value will override the one specified in the SessionOptions.
-
-
-
A Session object is created in an unconnected state. The start or startAsync method must be called to connect to the broker. Note that start method is blocking, and returns either after connection to broker has been established (success), or after specified timeout (failure). startAsync method, as the name suggests, connects to the broker asynchronously (i.e., it returns immediately), and the result of the operation is notified via bmqt::SessionEventType::CONNECTED session event.
-
When the Session is no longer needed, the application should call the stop (blocking) or stopAsync (non-blocking) method to shut down the Session and disconnect from the broker. Note that destroying a Session automatically stops it. The session can be restarted with a call to start or startAsync once it has been fully stopped.
-
-
-
Connection loss and reconnection:
If the connection between the application and the broker is lost, the Session will automatically try to reconnect periodically. The Session will also notify the application of the event of losing the connection via bmqt::SessionEventType::CONNECTION_LOST session event.
-
Once the connection has been re-established with the broker (as a result of one of the periodic reconnection attempts), the Session will notify the application via bmqt::SessionEventType::RECONNECTED session event. After the connection re-establishment, the Session will attempt to reopen the queues that were in OPEN state prior to connection loss. The Session will notify the application of the result of reopen operation via bmqt::SessionEventType::QUEUE_REOPEN_RESULT for each queue. Note that a reopen operation on a queue may fail (due to broker issue, machine issue, etc), so the application must keep track on these session events, and stop posting on a queue that failed to reopen.
-
After all reopen operations are complete and application has been notified with all bmqt::SessionEventType::QUEUE_REOPEN_RESULT events, the Session delivers a bmqt::SessionEventType::STATE_RESTORED session event to the application.
-
-
-
Example 1:
The following example illustrates how to create a Session in synchronous mode, start it, and stop it.
void runSession()
- {
- bmqt::SessionOptions options;
- options.setBrokerUri("tcp://localhost:30114");
-
- bmqa::Session session(options);
- int res = session.start();
- if (0 != res) {
- bsl::cout << "Failed to start session (" << res << ")"
- << bsl::endl;
- return;
- }
- bsl::cout << "Session started." << bsl::endl;
-
- // Open queue in READ or WRITE or READ/WRITE mode, and receive or
- // post messages, etc.
- // ...
-
- session.stop();
- }
-
This example can be simplified because the constructor for Session uses a default SessionOptions object that will connect to the local broker service. The example may be rewritten as follow:
void runSession()
- {
- bmqa::Session session; // using default 'SessionOptions'
- int res = session.start();
- if (0 != res) {
- bsl::cout << "Failed to start session (" << res << ")"
- << bsl::endl;
- return;
- }
- bsl::cout << "Session started." << bsl::endl;
-
- // Open queue in READ or WRITE or READ/WRITE mode, and receive or
- // post messages, etc.
- // ...
-
- session.stop();
- }
-
-
-
-
Processing session events - synchronous mode:
If the Session is created in synchronous mode, the application needs to call the nextEvent method on a regular basis in order to receive events. This method takes an optional wait timeout as a parameter, and it will return the next available Event from the session's internal event queue or it will block the calling thread execution until new Event arrives or until the specified timeout expires. It is safe to call the nextEvent method from different threads simultaneously: the Session class provides proper synchronization logic to protect the internal event queue from corruption in this scenario.
-
-
-
Example 2:
The following example demonstrates how to write a function that queries and processes events synchronously. In this example the switch form checks the type of the Event and performs the necessary actions.
-
We first define two functions to process SessionEvent and MessageEvent. These functions return true if we should keep processing events and false otherwise (i.e., no more events are expected from the Session).
bool processSessionEvent(constbmqa::SessionEvent& event)
- {
- bool result = true;
- switch (event.type()) {
-
- casebmqt::SessionEventType::e_CONNECTED:
- // The connection to the broker is established (as a result
- // of a call to the 'start' method).
- openQueues();
- startPostingToQueues();
- break;
-
- casebmqt::SessionEventType::e_DISCONNECTED:
- // The connection to the broker is terminated (as a result
- // of a call to the 'stop' method).
- result = false;
- break;
-
- casebmqt::SessionEventType::e_CONNECTION_LOST:
- // The connection to the broker dropped. Stop posting to the queue.
- stopPostingToQueues();
- break;
-
- casebmqt::SessionEventType::e_STATE_RESTORED:
- // The connection to the broker has been restored (i.e., all queues
- // have been re-opened. Resume posting to the queue.
- resumePostingToQueues();
- break;
-
- casebmqt::SessionEventType::e_CONNECTION_TIMEOUT:
- // The connection to the broker has timed out.
- result = false;
- break;
-
- casebmqt::SessionEventType::e_ERROR:
- // Internal error
- bsl::cout << "Unexpected session error: "
- << event.errorDescription() << bsl::endl;
- break;
-
- } // end switch
-
- return result;
- }
-
- bool processMessageEvent(constbmqa::MessageEvent& event)
- {
- bool result = true;
- switch (event.type()) {
-
- casebmqt::MessageEventType::e_PUSH: {
- // Received a 'PUSH' event from the broker.
- bmqa::MessageIterator msgIter = event.messageIterator();
- while (msgIter.nextMessage()) {
- constbmqa::Message& msg = msgIter.message();
- // Process 'PUSH' msg here (omitted for brevity)
- // ...
- }
- } break;
-
- casebmqt::MessageEventType::e_ACK: {
- // Received an 'ACK' event from the broker.
- bmqa::MessageIterator msgIter = event.messageIterator();
- while (msgIter.nextMessage()) {
- constbmqa::Message& msg = msgIter.message();
- // Process 'ACK' msg here (omitted for brevity)
- // ...
- }
- } break;
-
- } // end switch
-
- return result;
- }
-
-
Next, we define a function that handles events synchronously using the processSessionEvent and processMessageEvent functions.
void handleEventsSynchronously(bmqa::Session *startedSession)
- {
- bool more = true;
- while (more) {
- bmqa::Eventevent =
- startedSession->nextEvent(bsls::TimeInterval(2.0));
- if (event.isSessionEvent()) {
- more = processSessionEvent(event.sessionEvent());
- }
- else {
- more = processMessageEvent(event.messageEvent());
- }
- }
- }
-
-
-
-
Processing session events - asynchronous mode:
If application wishes to use Session in asynchronous mode, it must pass a managed pointer to an event handler implementing the SessionEventHandler. In this case, when Session is started, a thread pool owned by the Session is also started for processing events asynchronously. The Session will call event handler's onSessionEvent or onMessageEvent method every time a session event or a message event is available.
-
Note that after the Session is associated with some event handler, this association cannot be changed or canceled. The event handler will be used for processing events until the Session object is destroyed.
-
-
-
Example 3:
The following example demonstrates how to implement an event handler and how to make the Session use an instance of this event handler for processing events.
-
First, we define a concrete implementation of SessionEventHandler.
-
class MyHandler: public bmqa::SessionEventHandler {
- public:
- MyHandler() { }
- virtual ~MyHandler() { }
- virtualvoid onSessionEvent(constbmqa::SessionEvent& event);
- virtualvoid onMessageEvent(constbmqa::MessageEvent& event);
- };
-
- void MyHandler::onSessionEvent(constbmqa::SessionEvent& event)
- {
- // The implementation is similar to our 'processSessionEvent' function
- // defined in the previous example.
- processSessionEvent(event);
- }
-
- void MyHandler::onMessageEvent(constbmqa::MessageEvent& event)
- {
- // The implementation is similar to our 'processMessageEvent' function
- // defined in the previous example.
- processMessageEvent(event);
- }
-
Next, we define a function that creates a Session using our implementation of SessionEventHandler.
void runAsyncSession()
- {
- bslma::ManagedPtr<SessionEventHandler> handlerMp(new MyHandler());
-
- bmqa::Session session(handlerMp); // using default 'SessionOptions'
- int res = session.start();
- if (0 != res) {
- bsl::cout << "Failed to start session (" << res << ")"
- << bsl::endl;
- return;
- }
-
- // ...
-
- session.stop();
- }
-
-
-
-
Opening queues:
Once the Session has been created and started, the application can use it to open queues for producing and/or consuming messages. A queue is associated with a domain. Domain metadata must be deployed in the BlazingMQ infrastructure prior to opening queues under that domain, because opening a queue actually loads the metadata deployed for the associated domain.
-
The metadata associated with a domain defines various parameters like maximum queue size and capacity, persistent policy, routing policy, etc.
-
Queue are identified by URIs (Unified Resource Identifiers) that must follow the BlazingMQsyntax, manipulated as bmqt::Uri objects. A queue URI is typically formatted as follows:
bmq://my.domain/my.queue
-
Note that domain names are unique in BlazingMQ infrastructure, which makes a fully qualified queue URI unique too.
-
Queues in BlazingMQ infrastructure are created by applications on demand. Broke creates a queue when it receives an open-queue request from an application for a queue that does not exist currently.
-
Application can open a queue by calling openQueue or openQueueAsync method on a started session. Application must pass appropriate flags to indicate if it wants to post messages to queue, consume messages from the queue, or both.
-
Note that openQueue is a blocking method, and returns after specified queue has been successfully opened (success) or after specified timeout has expired (failure). openQueueAsync method, as the name suggests, is non blocking, and the result of the operation is notified via bmqt::SessionEventType::QUEUE_OPEN_RESULT session event.
-
-
-
Example 4:
The following example demonstrates how to open a queue for posting messages. The code first opens the queue with appropriate flags, and then uses bmqa::MessageEventBuilder to build a message event and post to the queue.
// Session creation and startup logic elided for brevity
- constchar *queueUri = "bmq://my.domain/my.queue";
- bmqa::QueueId myQueueId(1); // ID for the queue
- int rc = session.openQueue(
- &myQueueId,
- queueUri,
- bmqt::QueueFlags::e_WRITE | bmqt::QueueFlags::e_ACK,
- bsls::TimeInterval(30, 0));
-
- if (rc != 0) {
- bsl::cerr << "Failed to open queue, rc: "
- << bmqt::OpenQueueResult::Enum(rc)
- << bsl::endl;
- return;
- }
-
Note that apart from WRITE flag, ACK flag has been passed to openQueue method above. This indicates that application is interested in receiving ACK notification for each message it posts to the queue, irrespective of whether or not the message was successfully received by the broker and posted to the queue.
-
Once the queue has been successfully opened for writing, messages can be posted to the queue for consumption by interested applications. We will use bmqa::MessageEventBuilder to build a message event.
// Create a message event builder
- bmqa::MessageEventBuilder builder;
- session.loadMessageEventBuilder(&builder);
-
- // Create and post a message event containing 1 message
- bmqa::Message& msg = builder.startMessage();
-
- msg.setCorrelationId(myCorrelationId);
- msg.setDataRef(&myPayload); // where 'myPayload' is of type 'bdlbb::Blob'
- rc = builder.packMessage(myQueueId);
- if (rc != 0) {
- bsl::cerr << "Failed to pack message, rc: "
- << bmqt::EventBuilderResult::Enum(rc)
- << bsl::endl;
- return;
- }
-
- // Post message event
- rc = session.post(builder.messageEvent());
- if (rc != 0) {
- bsl::cerr << "Failed to post message event to the queue, rc: "
- << bmqt::PostResult::Enum(rc)
- << bsl::endl;
- return;
- }
-
- // ... post more messages
-
-
-
-
Closing queues:
After an application no longer needs to produce or consume messages from a queue, it can be closed by closeQueue or closeQueueAsync method. Note that closing a queue closes an application's "view" on the queue, and may not lead to queue deletion in the broker. A Session does not expose any method to explicitly delete a queue.
-
Note that closeQueue is a blocking method and returns after the specified queue has been successfully closed (success) or after specified timeout has expired (failure). closeQueueAsync, as the name suggests, is a non-blocking method, and result of the operation is notified via bmqt::SessionEventType::e_QUEUE_CLOSE_RESULT session event.
-
There are 3 flavors which behave differently with regard to thread blocking and callback execution: | openQueue | openQueueSync | openQueueAsync | configureQueue | configureQueueSync | configureQueueAsync | closeQueue | closeQueueSync | closeQueueAsync | (deprecated Sync) | (Synchronous) | (Asynchronous) -----------|-------------------|----------------------|---------------------- event | unblocks in | unblocks in event | executes callback in handler | internal thread | handler thread (*) | event handler thread | | | nextEvent | unblocks in | unblocks in | executes callback | internal thread | internal thread | in nextEvent thread -----------------------------------------------------------------------------
-
(*) - guarantees unblocking after all previously enqueued events have been emitted to the eventHandler, allowing the user to have proper serialization of events for the given queue (for example no more PUSH messages will be delivered through the eventHandler for the queue after configureQueueSync(maxUnconfirmed = 0) returns).
This component provides a generic bmqa::SessionEvent notification object used by the bmqa::Session to provide BlazingMQ applications with information regarding changes in the session status or the result of operations with the message queue broker.
-
A SessionEvent is composed of 4 attributes:
-
-type: indicate the type of the notification
-
-statusCode: indicate the status of the operation (success, failure)
-
-correlationId: optional correlationId used during async response
-
-queueId: optional queueId associated with the event, of type OPEN, CONFIGURE, CLOSE, REOPEN
-
-errorDescription: optional string with a human readable description of the error, if any
-
-
-
Note that SessionEvent is implemented using the pimpl idiom, so copying a SessionEvent is very cheap (a pointer copy). All copies of this SessionEvent will share the same underlying implementation.
Provide an interface for monitoring the health of the host.
-
-
-
MNEMONIC: BlazingMQ Public Interfaces (bmqpi):
-
-
-
-
Description:
The bmqpi package provides pure abstract interfaces, which are intended for clients to extend in their own applications and libraries. These extension points facilitate integration with other aspects of a runtime environment (e.g. authentication, host health-checking), which may vary significantly from organization to organization.
-
-
-
Hierarchical Synopsis:
The bmqpi package currently has 1 component having 1 level of physical dependency. The list below shows the hierarchical ordering of the components.
1. bmqpi_hosthealthmonitor
-
-
-
-
Component Synopsis:
-
bmqpi_hosthealthmonitor:
- Provide an interface for monitoring the health of the host.
Interface for a context with a notion of a current span.
-
-
-
-
-
Description:
-
bmqpi::DTContext is a pure interface representing a context which defines a "current" bmqpi::DTSpan for the calling thread. Implementations may return different spans for each thread, or return a single span shared by all calling threads.
-
Many distributed trace libraries provide a well-defined thread-local storage slot for the span currently under execution, which allows a function to obtain a reference to its caller across library boundaries, without changes to its API to facilitate dependency injection. This storage slot is set by instantiating an RAII "Span Guard" that writes a span to the TLS at construction, and reverts its state on destruction (emulating the semantics of a call-stack). The API of bmqpi::DTContext aims to make it easy to wrap these common patterns in a library-agnostic manner, while also facilitating test double implementations.
bmqpi::DTSpan is a pure interface representing a node within a distributed trace graph (which forms a DAG with edges as invocations).
-
bmqpi::DTSpan::Baggage represents a set of key-values used to describe metadata belonging to a DTSpan. The phrase "baggage" is borrowed from the OpenTelemetry standard's terminology.
bmqpi::HostHealthMonitor is a pure interface for a monitor of the health of the host. BlazingMQ sessions can use such objects to conditionally suspend queue activity while the host is marked unhealthy.
This component implements a value-semantic class, bmqt::CorrelationId, which can be used to identify any async operations. The correlationId contains a value (64-bit integer, raw pointer or sharedPtr) supplied by the application or uses an auto-assigned value. The type and the value of the correlationId can be set at construction time and changed later via the setNumeric(), setPointer() and setSharedPointer methods. Alternatively, a CorrelationId::AutoValue can be used to generate a unique correlationId from within the process. The bmqt::CorrelationIdLess comparison functor can be used for storing CorrelationId in a map as the key element; and a hash functor specialization is provided in the bsl::hash namespace.
-
-
-
AutoValue:
If the application doesn't care about the actual value of the correlation, AutoValue type can be used to create a unique correlationId. An AutoValue correlationId behaves exactly the same as any other type of correlation, with the exception that it's value can not be retrieved (but two correlationId can be still compared equal).
This section illustrates intended use of this component.
-
-
-
Example 1: Correlating Responses:
Suppose that we have the following asynchronous messaging interface that we want to use to implement a basic request/response class.
class Messenger {
-
- public:
- // TYPES
- typedef bsl::function<
- void(void *buffer,
- int bufferLength,
- constbmqt::CorrelationId& correlationId)> MessageHandler;
- // 'MessageHandler' is an alias for a functor that handles received
- // messages consisting of the specified 'buffer', having the
- // specified 'bufferLength', as well as the specified associated
- // 'correlationId' if the message is in response to a previously
- // transmitted message.
-
- // MANIPULATORS
- void sendMessage(void *buffer,
- int bufferLength,
- constbmqt::CorrelationId& correlationId);
- // Send a message containing the specified 'buffer' of the
- // specified 'bufferLength', associating the specified
- // 'correlationId' with any messages later received in response.
-
- void setMessageHandler(const MessageHandler& handler);
- // Set the functor to handle messages received by this object to
- // the specified 'handler'.
- };
-
First we declare a requester class.
class Requester {
-
- // DATA
- Messenger *d_messenger_p; // used to send messages (held)
- bslma::Allocator *d_allocator_p; // memory supply (held)
-
- // PRIVATE CLASS METHODS
- staticvoid handleMessage(void *buffer,
- int bufferLength,
- constbmqt::CorrelationId& correlationId);
- // Handle the response message consisting fo the specified 'buffer'
- // having the specified 'bufferLength', and associated
- // 'correlationId'.
-
- public:
- // TYPES
- typedef bsl::function<void(void *buffer, int bufferLength)>
- ResponseCallback;
- // 'ResponseCallback' is an alias for a functor that is used to
- // process received responses consisting of the specified 'buffer'
- // having the specified 'bufferLength'.
-
- // CREATORS
- explicit Requester(Messenger *messenger,
- bslma::Allocator *basicAllocator);
- // Create a 'Requester' that uses the specified 'messenger' to send
- // requests and receive responses, and the specified
- // 'basicAllocator' to supply memory.
-
- // MANIPULATORS
- void sendRequest(void *buffer,
- int bufferLength,
- const ResponseCallback& callback);
- // Send a request consisting of the specified 'buffer' having the
- // specified 'bufferLength', and invoke the specified 'callback'
- // with any asynchronous response.
- };
-
Then, we implement the constructor, setting the message handler on the provided Messenger to our class method.
Finally, we implement our message handler, extracting the response callback from the correlationId, and invoking it with the received response message.
bmqt::MessageGUID provides a value-semantic global unique identifier for BlazingMQ messages. Each bmqa::Message delivered to BlazingMQ client from BlazingMQ broker contains a unique MessageGUID. The binary function bmqt::MessageGUIDLess can be used for comparing GUIDs, and an optimized custom hash function is provided with bmqt::MessageGUIDHashAlgo.
-
-
-
-
Externalization:
For convenience, this class provides toHex method that can be used to externalize a bmqt::MessageGUID instance. Applications can persist the resultant buffer (on filesystem, in database) to keep track of last processed message ID across task instantiations. fromHex method can be used to convert a valid externalized buffer back to a message ID.
-
-
-
Efficient comparison and hash function:
This component also provides efficient comparison and hash functions for convenience, and thus, applications can use this component as a key in associative containers.
-
-
-
-
Example 1: Externalizing:
// Below, 'msg' is a valid instance of 'bmqa::Message' obtained from an
- // instance of 'bmqa::Session':
-
- bmqt::MessageGUID g1 = msg.messageId();
-
- char buffer[bmqt::MessageGUID::e_SIZE_HEX];
- g1.toHex(buffer);
-
- BSLS_ASSERT(true == bmqt::MessageGUID::isValidHexRepresentation(buffer));
-
- bmqt::MessageGUID g2;
- g2.fromHex(buffer);
-
- BSLS_ASSERT(g1 == g2);
-
utilities to manipulate queue flags bit-mask values
-
-
-
-
-
Description:
This file contains an enum, bmqt::QueueFlags of all the flags that can be used at Queue open. Each value of the enum correspond to a bit of a bit-mask integer. It also exposes a set of utilities, in the bmqt::QueueFlagsUtil namespace to manipulate such bit-mask value.
All enums are using the convention that < 0 values are errors, while > 0 are warnings.
-
The GenericStatus enum contains values that are common for most or all of the other status enums, such as success, timeout, ... The values of its members can range from -99 to 99.
-
Each other enum should duplicate any values from the GenericStatus one that it intends to be able to represent (aliasing the values to the ones from the GenericStatus enum) and extend with specialized values in the ]..., -99[ or ]99, ...[ ranges.
-CONNECTED: The connection with the broker is established, this event is only fired once (if for any reason the connection gets lost and automatically reconnected, this will emit a CONNECTION_RESTORED event).
-
-
-
-
-DISCONNECTED: The connection with the broker is terminated (after the user called stop on the session). This is the last event that will be delivered.
-
-
-
-
-CONNECTION_LOST: The session was connected to the broker, but that connection dropped.
-
-
-
-
-RECONNECTED: The connection to the broker has been re-established. This event is followed by zero or more QUEUE_REOPEN_RESULT events, and one STATE_RESTORED event.
-
-
-
-
-STATE_RESTORED: Session's state has been restored after connection has been re-established with the broker. This event is preceded by one RECONNECTED event, and zero or more QUEUE_REOPEN_RESULT events.
-
-
-
-
-CONNECTION_TIMEOUT: The connection to the broker has timedout.
-
-
-
-
-QUEUE_OPEN_RESULT: Indicates the result of an openQueue operation.
-
-
-
-
-QUEUE_REOPEN_RESULT: Indicates the result of an openQueue operation, which happens when the connection to the broker has been restored and queues previously opened have been automatically reopened. This event is preceded by a RECONNECTED event and followed by zero or more QUEUE_REOPEN_RESULT events, and one STATE_RESTORED event.
-
-
-
-
-QUEUE_CLOSE_RESULT: Indicates the result of a closeQueue operation
-
-
-
-
-SLOWCONSUMER_NORMAL: Notifies that the EventQueue is back to its low watermark level.
-
-
-
-
-SLOWCONSUMER_HIGHWATERMARK: Notifies that events are accumulating in the EventQueue, which has now reached it's high watermark level.
-
-
-
-
-QUEUE_CONFIGURE_RESULT: Indicates the result of a configureQueue operation.
-
-
-
-
-HOST_UNHEALTHY: Indicates the host has become unhealthy. Only issued if
-HOST_HEALTH_RESTORED: Indicates the health of the host has restored,
-
-and all queues have resumed operation. Following a Host Health incident, this indicates that the application has resumed normal operation.
-
-
-QUEUE_SUSPENDED: Indicates that an open queue has suspended operation:
-
-
-* Consumers are configured to receive no more messages from broker (i.e., maxUnconfirmedMessages := 0, maxUnconfirmedBytes := 0, consumerPriority := INT_MIN). * Attempts to pack messages targeting queue will be rejected by bmqa::MessageEventBuilder::pack(). Clients may still attempt to POST existing packed events. * Attempts by client to reconfigure queue will not take effect until the queue has resumed.
-
-
-QUEUE_RESUMED: Indicates that a suspended queue has resumed normal
-
-operation (i.e., effects of QUEUE_SUSPENDED state no longer apply).
-
-
-ERROR: Indicates a generic error.
-
-
-
-
-TIMEOUT Indicates that the specified operation has timed out.
-
-
-
-
-CANCELED: Indicates that the specified operation was canceled.
Provide a value-semantic type to configure session with the broker.
-
-
-
Classes:
BlazingMQ broker.
-
-
-
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 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: o an explicit hostname or localhost o an ip, example 10.11.12.13 o 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 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 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,
-
-disconnetTimeout,
-
-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 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 `bmqpiDTContext` and `bmqpiDTTracer` 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).
This component provides a value-semantic type, bmqt::Uri representing a URI for a BlazingMQ queue. A bmqt:Uri can be built by parsing from a string representation, using the bmqt::UriParser, or built using the bmqt::UriBuilder.
-The URI authority is the name of BlazingMQ domain (such as
-
-"ts.trades.myapp")
-
as registered with the BlazingMQ infrastructure. The domain name may
-
contain alphanumeric characters, dots and dashes (it has to match the
-
following regular expression: [-a-zA-Z0-9\\._]+). The domain may be
-
followed by an optional tier, introduced by the ".~" sequence and
-
consisting of alphanumeric characters and dashes. The ".~" sequence is
-
not part of the tier.
-
-
-
-The URI path is the name of the queue ("my.queue" above) and may contain alphanumeric characters, dashes, underscores and tild (it has to match the following regular expression: [-a-zA-Z0-9_~\\.]+). The queue name must be less than bmqt::Uri::k_QUEUENAME_MAX_LENGTH characters long.
-
-
-
-
-The name of the queue ("my.queue" above) may contain alphanumeric characters and dots.
-
-
-
-
-
The URI may contain an optional query with a key-value pair. Currently supported keys are:
-
-
-id: the corresponding value represents a name that will be used by BlazingMQ broker to uniquely identify the client.
-
-
-
-
-
-
-
-The URI fragment part is currently unused.
-
-
-
-
-
Usage Example 1:
First, call the initialize method of the UriParser. This call is only needed one time; you can call it when your task starts.
-
Note that the bmq library takes care of that, so users of bmq don't have to explicitly do it themselves.
Then, parse a URI string created on the stack to populate a Uri object. The parse function takes an optional error string which is populated with a short error message if the URI is not formatted correctly.
This component implements a simple value-semantic type, bmqt::Version representing the version of an object. It is used in particular to attach a version attribute to a bmqa::Message, so that a consuming application receiving a message knows the version of the schema that was used for publishing.
-
A version is represented by two numbers: a major and a minor version. Both are positive integers within the range [0-255].
Return true if the specified rhs object contains the value of the same type as contained in the specified lhs object and the value itself is the same in both objects, return false otherwise.
-
-
-
-
-
-
-
-
-
bool bmqa::operator!=
-
(
-
const CloseQueueStatus &
-
lhs,
-
-
-
-
-
const CloseQueueStatus &
-
rhs
-
-
-
-
)
-
-
-
-
-
-
Return false if the specified rhs object contains the value of the same type as contained in the specified lhs object and the value itself is the same in both objects, return true otherwise.
-
-
-
-
-
-
-
-
-
bsl::ostream& bmqa::operator<<
-
(
-
bsl::ostream &
-
stream,
-
-
-
-
-
const CloseQueueStatus &
-
rhs
-
-
-
-
)
-
-
-
-
-
-
Format the specified rhs to the specified output stream and return a reference to the modifiable stream.
-
-
-
-
-
-
-
-
-
bool bmqa::operator==
-
(
-
const ConfigureQueueStatus &
-
lhs,
-
-
-
-
-
const ConfigureQueueStatus &
-
rhs
-
-
-
-
)
-
-
-
-
-
-
Return true if the specified rhs object contains the value of the same type as contained in the specified lhs object and the value itself is the same in both objects, return false otherwise.
-
-
-
-
-
-
-
-
-
bool bmqa::operator!=
-
(
-
const ConfigureQueueStatus &
-
lhs,
-
-
-
-
-
const ConfigureQueueStatus &
-
rhs
-
-
-
-
)
-
-
-
-
-
-
Return false if the specified rhs object contains the value of the same type as contained in the specified lhs object and the value itself is the same in both objects, return true otherwise.
-
-
-
-
-
-
-
-
-
bsl::ostream& bmqa::operator<<
-
(
-
bsl::ostream &
-
stream,
-
-
-
-
-
const ConfigureQueueStatus &
-
rhs
-
-
-
-
)
-
-
-
-
-
-
Format the specified rhs to the specified output stream and return a reference to the modifiable stream.
-
-
-
-
-
-
-
-
-
bsl::ostream& bmqa::operator<<
-
(
-
bsl::ostream &
-
stream,
-
-
-
-
-
const Event &
-
rhs
-
-
-
-
)
-
-
-
-
-
-
Format the specified rhs to the specified output stream and return a reference to the modifiable stream.
-
-
-
-
-
-
-
-
-
bsl::ostream& bmqa::operator<<
-
(
-
bsl::ostream &
-
stream,
-
-
-
-
-
const Message &
-
rhs
-
-
-
-
)
-
-
-
-
-
-
Format the specified rhs to the specified output stream and return a reference to the modifiable stream.
-
-
-
-
-
-
-
-
-
bsl::ostream& bmqa::operator<<
-
(
-
bsl::ostream &
-
stream,
-
-
-
-
-
const MessageEvent &
-
rhs
-
-
-
-
)
-
-
-
-
-
-
Format the specified rhs to the specified output stream and return a reference to the modifiable stream.
-
-
-
-
-
-
-
-
-
bsl::ostream& bmqa::operator<<
-
(
-
bsl::ostream &
-
stream,
-
-
-
-
-
const MessageProperties &
-
rhs
-
-
-
-
)
-
-
-
-
-
-
Format the specified rhs to the specified output stream and return a reference to the modifiable stream.
-
-
-
-
-
-
-
-
-
bool bmqa::operator==
-
(
-
const OpenQueueStatus &
-
lhs,
-
-
-
-
-
const OpenQueueStatus &
-
rhs
-
-
-
-
)
-
-
-
-
-
-
Return true if the specified rhs object contains the value of the same type as contained in the specified lhs object and the value itself is the same in both objects, return false otherwise.
-
-
-
-
-
-
-
-
-
bool bmqa::operator!=
-
(
-
const OpenQueueStatus &
-
lhs,
-
-
-
-
-
const OpenQueueStatus &
-
rhs
-
-
-
-
)
-
-
-
-
-
-
Return false if the specified rhs object contains the value of the same type as contained in the specified lhs object and the value itself is the same in both objects, return true otherwise.
-
-
-
-
-
-
-
-
-
bsl::ostream& bmqa::operator<<
-
(
-
bsl::ostream &
-
stream,
-
-
-
-
-
const OpenQueueStatus &
-
rhs
-
-
-
-
)
-
-
-
-
-
-
Format the specified rhs to the specified output stream and return a reference to the modifiable stream.
-
-
-
-
-
-
-
-
-
bsl::ostream& bmqa::operator<<
-
(
-
bsl::ostream &
-
stream,
-
-
-
-
-
const QueueId &
-
rhs
-
-
-
-
)
-
-
-
-
-
-
Format the specified rhs to the specified output stream and return a reference to the modifiable stream.
-
-
-
-
-
-
-
-
-
bool bmqa::operator==
-
(
-
const QueueId &
-
lhs,
-
-
-
-
-
const QueueId &
-
rhs
-
-
-
-
)
-
-
-
-
-
-
Return true if rhs object contains the value of the same type as contained in lhs object and the value itself is the same in both objects, return false otherwise.
-
-
-
-
-
-
-
-
-
bool bmqa::operator!=
-
(
-
const QueueId &
-
lhs,
-
-
-
-
-
const QueueId &
-
rhs
-
-
-
-
)
-
-
-
-
-
-
Return false if rhs object contains the value of the same type as contained in lhs object and the value itself is the same in both objects, return true otherwise.
-
-
-
-
-
-
-
-
-
bool bmqa::operator<
-
(
-
const QueueId &
-
lhs,
-
-
-
-
-
const QueueId &
-
rhs
-
-
-
-
)
-
-
-
-
-
-
Operator used to allow comparison between the specified lhs and rhs CorrelationId objects so that CorrelationId can be used as key in a map.
-
-
-
-
-
-
-
-
-
bool bmqa::operator==
-
(
-
const SessionEvent &
-
lhs,
-
-
-
-
-
const SessionEvent &
-
rhs
-
-
-
-
)
-
-
-
-
-
-
Return true if the specified rhs object contains the value of the same type as contained in the specified lhs object and the value itself is the same in both objects, return false otherwise.
-
-
-
-
-
-
-
-
-
bool bmqa::operator!=
-
(
-
const SessionEvent &
-
lhs,
-
-
-
-
-
const SessionEvent &
-
rhs
-
-
-
-
)
-
-
-
-
-
-
Return false if the specified rhs object contains the value of the same type as contained in the specified lhs object and the value itself is the same in both objects, return true otherwise.
-
-
-
-
-
-
-
-
-
bsl::ostream& bmqa::operator<<
-
(
-
bsl::ostream &
-
stream,
-
-
-
-
-
const SessionEvent &
-
rhs
-
-
-
-
)
-
-
-
-
-
-
Format the specified rhs to the specified output stream and return a reference to the modifiable stream.
Format the specified value to the specified output stream and return a reference to the modifiable stream.
-
-
-
-
-
-
-
-
-
bsl::ostream& bmqt::operator<<
-
(
-
bsl::ostream &
-
stream,
-
-
-
-
-
const CorrelationId &
-
rhs
-
-
-
-
)
-
-
-
-
-
-
Format the specified rhs to the specified output stream and return a reference to the modifiable stream.
-
-
-
-
-
-
-
-
-
bool bmqt::operator==
-
(
-
const CorrelationId &
-
lhs,
-
-
-
-
-
const CorrelationId &
-
rhs
-
-
-
-
)
-
-
-
-
-
-
Return true if rhs object contains the value of the same type as contained in lhs object and the value itself is the same in both objects, return false otherwise.
-
-
-
-
-
-
-
-
-
bool bmqt::operator!=
-
(
-
const CorrelationId &
-
lhs,
-
-
-
-
-
const CorrelationId &
-
rhs
-
-
-
-
)
-
-
-
-
-
-
Return false if rhs object contains the value of the same type as contained in lhs object and the value itself is the same in both objects, return true otherwise.
-
-
-
-
-
-
-
-
-
bool bmqt::operator<
-
(
-
const CorrelationId &
-
lhs,
-
-
-
-
-
const CorrelationId &
-
rhs
-
-
-
-
)
-
-
-
-
-
-
Operator used to allow comparison between the specified lhs and rhsCorrelationId objects so that CorrelationId can be used as key in a map.
-
-
-
-
-
-
-
-
-
bsl::ostream& bmqt::operator<<
-
(
-
bsl::ostream &
-
stream,
-
-
-
-
-
EncodingType::Enum
-
value
-
-
-
-
)
-
-
-
-
-
-
Format the specified value to the specified output stream and return a reference to the modifiable stream.
-
-
-
-
-
-
-
-
-
bsl::ostream& bmqt::operator<<
-
(
-
bsl::ostream &
-
stream,
-
-
-
-
-
HostHealthState::Enum
-
value
-
-
-
-
)
-
-
-
-
-
-
Format the specified value to the specified output stream and return a reference to the modifiable stream.
-
-
-
-
-
-
-
-
-
bsl::ostream& bmqt::operator<<
-
(
-
bsl::ostream &
-
stream,
-
-
-
-
-
MessageEventType::Enum
-
value
-
-
-
-
)
-
-
-
-
-
-
Format the specified value to the specified output stream and return a reference to the modifiable stream.
-
-
-
-
-
-
-
-
-
bsl::ostream& bmqt::operator<<
-
(
-
bsl::ostream &
-
stream,
-
-
-
-
-
const MessageGUID &
-
rhs
-
-
-
-
)
-
-
-
-
-
-
Write the value of the specified rhs object to the specified output stream in a human-readable format, and return a reference to stream. Note that this human-readable format is not fully specified, and can change without notice. Applications relying on a fixed length format must use toHex method.
-
-
-
-
-
-
-
-
-
bool bmqt::operator==
-
(
-
const MessageGUID &
-
lhs,
-
-
-
-
-
const MessageGUID &
-
rhs
-
-
-
-
)
-
-
-
-
-
-
Return true if rhs object contains the value of the same type as contained in lhs object and the value itself is the same in both objects, return false otherwise.
-
-
-
-
-
-
-
-
-
bool bmqt::operator!=
-
(
-
const MessageGUID &
-
lhs,
-
-
-
-
-
const MessageGUID &
-
rhs
-
-
-
-
)
-
-
-
-
-
-
Return false if rhs object contains the value of the same type as contained in lhs object and the value itself is the same in both objects, return true otherwise.
-
-
-
-
-
-
-
-
-
bool bmqt::operator<
-
(
-
const MessageGUID &
-
lhs,
-
-
-
-
-
const MessageGUID &
-
rhs
-
-
-
-
)
-
-
-
-
-
-
Return true if the specified lhs instance is smaller than the specified rhs instance, false otherwise. Note that criteria for comparison is implementation defined, and result of this routine doesnot in any way signify the order of creation/arrival/delivery of messages to which lhs and rhs instances belong. Note that this operator is provided so that MessageGUID can be used as a key in associative containers (map, set, etc).
-
-
-
-
-
-
-
-
-
bsl::ostream& bmqt::operator<<
-
(
-
bsl::ostream &
-
stream,
-
-
-
-
-
PropertyType::Enum
-
value
-
-
-
-
)
-
-
-
-
-
-
Format the specified value to the specified output stream and return a reference to the modifiable stream.
-
-
-
-
-
-
-
-
-
bsl::ostream& bmqt::operator<<
-
(
-
bsl::ostream &
-
stream,
-
-
-
-
-
QueueFlags::Enum
-
value
-
-
-
-
)
-
-
-
-
-
-
Format the specified value to the specified output stream and return a reference to the modifiable stream.
-
-
-
-
-
-
-
-
-
bool bmqt::operator==
-
(
-
const QueueOptions &
-
lhs,
-
-
-
-
-
const QueueOptions &
-
rhs
-
-
-
-
)
-
-
-
-
-
-
Return true if the specified rhs object contains the value of the same type as contained in the specified lhs object and the value itself is the same in both objects, return false otherwise.
-
-
-
-
-
-
-
-
-
bool bmqt::operator!=
-
(
-
const QueueOptions &
-
lhs,
-
-
-
-
-
const QueueOptions &
-
rhs
-
-
-
-
)
-
-
-
-
-
-
Return false if the specified rhs object contains the value of the same type as contained in the specified lhs object and the value itself is the same in both objects, return true otherwise.
-
-
-
-
-
-
-
-
-
bsl::ostream& bmqt::operator<<
-
(
-
bsl::ostream &
-
stream,
-
-
-
-
-
const QueueOptions &
-
rhs
-
-
-
-
)
-
-
-
-
-
-
Format the specified rhs to the specified output stream and return a reference to the modifiable stream.
-
-
-
-
-
-
-
-
-
bsl::ostream& bmqt::operator<<
-
(
-
bsl::ostream &
-
stream,
-
-
-
-
-
GenericResult::Enum
-
value
-
-
-
-
)
-
-
-
-
-
-
Format the specified value to the specified output stream and return a reference to the modifiable stream.
-
-
-
-
-
-
-
-
-
bsl::ostream& bmqt::operator<<
-
(
-
bsl::ostream &
-
stream,
-
-
-
-
-
OpenQueueResult::Enum
-
value
-
-
-
-
)
-
-
-
-
-
-
Format the specified value to the specified output stream and return a reference to the modifiable stream.
-
-
-
-
-
-
-
-
-
bsl::ostream& bmqt::operator<<
-
(
-
bsl::ostream &
-
stream,
-
-
-
-
-
ConfigureQueueResult::Enum
-
value
-
-
-
-
)
-
-
-
-
-
-
Format the specified value to the specified output stream and return a reference to the modifiable stream.
-
-
-
-
-
-
-
-
-
bsl::ostream& bmqt::operator<<
-
(
-
bsl::ostream &
-
stream,
-
-
-
-
-
CloseQueueResult::Enum
-
value
-
-
-
-
)
-
-
-
-
-
-
Format the specified value to the specified output stream and return a reference to the modifiable stream.
-
-
-
-
-
-
-
-
-
bsl::ostream& bmqt::operator<<
-
(
-
bsl::ostream &
-
stream,
-
-
-
-
-
EventBuilderResult::Enum
-
value
-
-
-
-
)
-
-
-
-
-
-
Format the specified value to the specified output stream and return a reference to the modifiable stream.
-
-
-
-
-
-
-
-
-
bsl::ostream& bmqt::operator<<
-
(
-
bsl::ostream &
-
stream,
-
-
-
-
-
AckResult::Enum
-
value
-
-
-
-
)
-
-
-
-
-
-
Format the specified value to the specified output stream and return a reference to the modifiable stream.
-
-
-
-
-
-
-
-
-
bsl::ostream& bmqt::operator<<
-
(
-
bsl::ostream &
-
stream,
-
-
-
-
-
PostResult::Enum
-
value
-
-
-
-
)
-
-
-
-
-
-
Format the specified value to the specified output stream and return a reference to the modifiable stream.
-
-
-
-
-
-
-
-
-
bsl::ostream& bmqt::operator<<
-
(
-
bsl::ostream &
-
stream,
-
-
-
-
-
SessionEventType::Enum
-
value
-
-
-
-
)
-
-
-
-
-
-
Format the specified value to the specified output stream and return a reference to the modifiable stream.
-
-
-
-
-
-
-
-
-
bool bmqt::operator==
-
(
-
const SessionOptions &
-
lhs,
-
-
-
-
-
const SessionOptions &
-
rhs
-
-
-
-
)
-
-
-
-
-
-
Return true if the specified rhs object contains the value of the same type as contained in the specified lhs object and the value itself is the same in both objects, return false otherwise.
-
-
-
-
-
-
-
-
-
bool bmqt::operator!=
-
(
-
const SessionOptions &
-
lhs,
-
-
-
-
-
const SessionOptions &
-
rhs
-
-
-
-
)
-
-
-
-
-
-
Return false if the specified rhs object contains the value of the same type as contained in the specified lhs object and the value itself is the same in both objects, return true otherwise.
-
-
-
-
-
-
-
-
-
bsl::ostream& bmqt::operator<<
-
(
-
bsl::ostream &
-
stream,
-
-
-
-
-
const SessionOptions &
-
rhs
-
-
-
-
)
-
-
-
-
-
-
Format the specified rhs to the specified output stream and return a reference to the modifiable stream.
-
-
-
-
-
-
-
-
-
bsl::ostream& bmqt::operator<<
-
(
-
bsl::ostream &
-
stream,
-
-
-
-
-
const Subscription &
-
rhs
-
-
-
-
)
-
-
-
-
-
-
Format the specified rhs to the specified output stream and return a reference to the modifiable stream.
-
-
-
-
-
-
-
-
-
bool bmqt::operator==
-
(
-
const Uri &
-
lhs,
-
-
-
-
-
const Uri &
-
rhs
-
-
-
-
)
-
-
-
-
-
-
Return true if the specified rhs object contains the value of the same type as contained in the specified lhs object and the value itself is the same in both objects, return false otherwise.
-
-
-
-
-
-
-
-
-
bool bmqt::operator!=
-
(
-
const Uri &
-
lhs,
-
-
-
-
-
const Uri &
-
rhs
-
-
-
-
)
-
-
-
-
-
-
Return false if the specified rhs object contains the value of the same type as contained in the specified lhs object and the value itself is the same in both objects, return true otherwise.
-
-
-
-
-
-
-
-
-
bool bmqt::operator<
-
(
-
const Uri &
-
lhs,
-
-
-
-
-
const Uri &
-
rhs
-
-
-
-
)
-
-
-
-
-
-
Return true if the specified lhs object compares less than the specified rhs object.
-
-
-
-
-
-
-
-
-
bsl::ostream& bmqt::operator<<
-
(
-
bsl::ostream &
-
stream,
-
-
-
-
-
const Uri &
-
rhs
-
-
-
-
)
-
-
-
-
-
-
Format the specified rhs to the specified output stream and return a reference to the modifiable stream.
-
-
-
-
-
-
-
-
-
bsl::ostream& bmqt::operator<<
-
(
-
bsl::ostream &
-
stream,
-
-
-
-
-
const Version &
-
rhs
-
-
-
-
)
-
-
-
-
-
-
Format the specified rhs to the specified output stream and return a reference to the modifiable stream.
-
-
-
-
-
-
-
-
-
bool bmqt::operator==
-
(
-
const Version &
-
lhs,
-
-
-
-
-
const Version &
-
rhs
-
-
-
-
)
-
-
-
-
-
-
Return true if the object in the specified lhs represents the same version as the the one in the specified rhs, return false otherwise.
-
-
-
-
-
-
-
-
-
bool bmqt::operator!=
-
(
-
const Version &
-
lhs,
-
-
-
-
-
const Version &
-
rhs
-
-
-
-
)
-
-
-
-
-
-
Return true if the object in the specified lhs represents a different version than the the one in the specified rhs, return false otherwise.
-
-
-
-
-
-
-
-
-
bool bmqt::operator<
-
(
-
const Version &
-
lhs,
-
-
-
-
-
const Version &
-
rhs
-
-
-
-
)
-
-
-
-
-
-
Return true if the version represented by the specified lhs is less than the version represented by the specified rhs.
Struct containing the internal (private) members of Message (That is so that we can access private members of Message to initialize it, without having to expose them publicly).
-
IMPLEMENTATION NOTE: If adding new data members to this struct that are lazily populated (such as queueId or correlationId), then they should be reset in bmqa::MessageIterator.nextMessage().
Struct to hold the impl of the MessageIterator; that is so that we can keep the real impl private and use some special cast to manipulate it, without publicly exposing private members.
Create and return an Event configured as a message event of type e_ACK with the specified acks params using the specified bufferFactory and the specified allocator to supply memory.
Create and return an Event configured as a message event of type e_PUSH and with the specified pushEventParams, using the specified bufferFactory and the specified allocator to supply memory.
DEPRECATED: Use the createOpenQueueStatus(...), createConfigureQueueStatus(...), or createCloseQueueStatus(...) methods instead. This method will be marked as BSLS_ANNOTATION_DEPRECATED in future release of libbmq.
Create and return an Event configured as a session event with the specified sessionEventType, errorCode and errorDescription and using the specified allocator to supply memory. Note that this method will not create queue related session events.
Create and return a bmqa::OpenQueueStatus object with the specified queueId, statusCode, and errorDescription, using the optionally specified allocator to supply memory in the result.
Create and return a bmqa::ConfigureQueueStatus object with the specified queueId, statusCode, and errorDescription, using the optionally specified allocator to supply memory in the result.
Create and return a bmqa::CloseQueueStatus object with the specified queueId, statusCode, and errorDescription, using the optionally specified allocator to supply memory in the result.
-
-
-
-The documentation for this struct was generated from the following file:
Impl structure for the session data members, so that special task such as bmqadm can access them by reinterpret casting a Session object. Care should be taken though since Session is a polymorphic class.
Write the string representation of the specified enumeration value to the specified output stream, and return a reference to stream. Optionally specify an initial indentation level, whose absolute value is incremented recursively for nested objects. If level is specified, optionally specify spacesPerLevel, whose absolute value indicates the number of spaces per indentation level for this and all of its nested objects. If level is negative, suppress indentation of the first line. If spacesPerLevel is negative, format the entire output on one line, suppressing all but the initial indentation (as governed by level). See toAscii for what constitutes the string representation of a PublishResult::Enum value.
Return the non-modifiable string representation corresponding to the specified enumeration value, if it exists, and a unique (error) string otherwise. The string representation of value matches its corresponding enumerator name with the e_ prefix elided. Note that specifying a value that does not match any of the enumerators will result in a string representation that is distinct from any of those corresponding to the enumerators, but is otherwise unspecified.
Return true and fills the specified out with the enum value corresponding to the specified str, if valid, or return false and leave out untouched if str doesn't correspond to any value of the enum.
-
-
-
-The documentation for this struct was generated from the following file:
Write the string representation of the specified enumeration value to the specified output stream, and return a reference to stream. Optionally specify an initial indentation level, whose absolute value is incremented recursively for nested objects. If level is specified, optionally specify spacesPerLevel, whose absolute value indicates the number of spaces per indentation level for this and all of its nested objects. If level is negative, suppress indentation of the first line. If spacesPerLevel is negative, format the entire output on one line, suppressing all but the initial indentation (as governed by level). See toAscii for what constitutes the string representation of a PublishResult::Enum value.
Return the non-modifiable string representation corresponding to the specified enumeration value, if it exists, and a unique (error) string otherwise. The string representation of value matches its corresponding enumerator name with the e_ prefix elided. Note that specifying a value that does not match any of the enumerators will result in a string representation that is distinct from any of those corresponding to the enumerators, but is otherwise unspecified.
Return true and fills the specified out with the enum value corresponding to the specified str, if valid, or return false and leave out untouched if str doesn't correspond to any value of the enum.
-
-
-
-The documentation for this struct was generated from the following file:
Write the string representation of the specified enumeration value to the specified output stream, and return a reference to stream. Optionally specify an initial indentation level, whose absolute value is incremented recursively for nested objects. If level is specified, optionally specify spacesPerLevel, whose absolute value indicates the number of spaces per indentation level for this and all of its nested objects. If level is negative, suppress indentation of the first line. If spacesPerLevel is negative, format the entire output on one line, suppressing all but the initial indentation (as governed by level). See toAscii for what constitutes the string representation of a CompressionAlgorithmType::Enum value.
Return the non-modifiable string representation corresponding to the specified enumeration value, if it exists, and a unique (error) string otherwise. The string representation of value matches its corresponding enumerator name with the "e_" prefix eluded. For example:
Note that specifying a value that does not match any of the enumerators will result in a string representation that is distinct from any of those corresponding to the enumerators, but is otherwise unspecified.
Update the specified out with correct enum corresponding to the specified string str, if it exists, and return true. Otherwise in case of an error or unidentified string, return false. The expected str is the enumerator name with the "e_" prefix excluded. For example:
Note that specifying a str that does not match any of the enumerators excluding "e_" prefix will result in the function returning false and the specified out will not be touched.
Return true incase of valid specified str i.e. a enumerator name with the "e_" prefix excluded. Otherwise in case of invalid str return false and populate the specified stream with error message.
Write the string representation of the specified enumeration value to the specified output stream, and return a reference to stream. Optionally specify an initial indentation level, whose absolute value is incremented recursively for nested objects. If level is specified, optionally specify spacesPerLevel, whose absolute value indicates the number of spaces per indentation level for this and all of its nested objects. If level is negative, suppress indentation of the first line. If spacesPerLevel is negative, format the entire output on one line, suppressing all but the initial indentation (as governed by level). See toAscii for what constitutes the string representation of a ConfigureQueueResult::Enum value.
Return the non-modifiable string representation corresponding to the specified enumeration value, if it exists, and a unique (error) string otherwise. The string representation of value matches its corresponding enumerator name with the e_ prefix elided. Note that specifying a value that does not match any of the enumerators will result in a string representation that is distinct from any of those corresponding to the enumerators, but is otherwise unspecified.
Return true and fills the specified out with the enum value corresponding to the specified str, if valid, or return false and leave out untouched if str doesn't correspond to any value of the enum.
-
-
-
-The documentation for this struct was generated from the following file:
Write the string representation of the specified enumeration value to the specified output stream, and return a reference to stream. Optionally specify an initial indentation level, whose absolute value is incremented recursively for nested objects. If level is specified, optionally specify spacesPerLevel, whose absolute value indicates the number of spaces per indentation level for this and all of its nested objects. If level is negative, suppress indentation of the first line. If spacesPerLevel is negative, format the entire output on one line, suppressing all but the initial indentation (as governed by level). See toAscii for what constitutes the string representation of a EncodingType::Value value.
Return the non-modifiable string representation corresponding to the specified enumeration value, if it exists, and a unique (error) string otherwise. The string representation of value matches its corresponding enumerator name with the BMQT_ prefix elided. Note that specifying a value that does not match any of the enumerators will result in a string representation that is distinct from any of those corresponding to the enumerators, but is otherwise unspecified.
Return true and fills the specified out with the enum value corresponding to the specified str, if valid, or return false and leave out untouched if str doesn't correspond to any value of the enum.
-
-
-
-
-
-
-
-
-
static bool bmqt::EncodingType::isValid
-
(
-
const bsl::string *
-
string,
-
-
-
-
-
bsl::ostream &
-
stream
-
-
-
-
)
-
[static]
-
-
-
-
-
Return true if the specified string is a valid representation of the EncodingType, otherwise return false and print a description of the error to the specified stream.
Write the string representation of the specified enumeration value to the specified output stream, and return a reference to stream. Optionally specify an initial indentation level, whose absolute value is incremented recursively for nested objects. If level is specified, optionally specify spacesPerLevel, whose absolute value indicates the number of spaces per indentation level for this and all of its nested objects. If level is negative, suppress indentation of the first line. If spacesPerLevel is negative, format the entire output on one line, suppressing all but the initial indentation (as governed by level). See toAscii for what constitutes the string representation of a EventBuilderResult::Enum value.
Return the non-modifiable string representation corresponding to the specified enumeration value, if it exists, and a unique (error) string otherwise. The string representation of value matches its corresponding enumerator name with the e_ prefix elided. Note that specifying a value that does not match any of the enumerators will result in a string representation that is distinct from any of those corresponding to the enumerators, but is otherwise unspecified.
Return true and fills the specified out with the enum value corresponding to the specified str, if valid, or return false and leave out untouched if str doesn't correspond to any value of the enum.
-
-
-
-The documentation for this struct was generated from the following file:
Write the string representation of the specified enumeration value to the specified output stream, and return a reference to stream. Optionally specify an initial indentation level, whose absolute value is incremented recursively for nested objects. If level is specified, optionally specify spacesPerLevel, whose absolute value indicates the number of spaces per indentation level for this and all of its nested objects. If level is negative, suppress indentation of the first line. If spacesPerLevel is negative, format the entire output on one line, suppressing all but the initial indentation (as governed by level). See toAscii for what constitutes the string representation of a GenericResult::Enum value.
Return the non-modifiable string representation corresponding to the specified enumeration value, if it exists, and a unique (error) string otherwise. The string representation of value matches its corresponding enumerator name with the e_ prefix elided. Note that specifying a value that does not match any of the enumerators will result in a string representation that is distinct from any of those corresponding to the enumerators, but is otherwise unspecified.
Return true and fills the specified out with the enum value corresponding to the specified str, if valid, or return false and leave out untouched if str doesn't correspond to any value of the enum.
-
-
-
-The documentation for this struct was generated from the following file:
Write the string representation of the specified enumeration value to the specified output stream, and return a reference to stream. Optionally specify an initial indentation level, whose absolute value is incremented recursively for nested objects. If level is specified, optionally specify spacesPerLevel, whose absolute value indicates the number of spaces per indentation level for this and all of its nested objects. If level is negative, suppress indentation of the first line. If spacesPerLevel is negative, format the entire output on one line, suppressing all but the initial indentation (as governed by level). See toAscii for what constitutes the string representation of a HostHealthState::Value value.
Return the non-modifiable string representation corresponding to the specified enumeration value, if it exists, and a unique (error) string otherwise. The string representation of value matches its corresponding enumerator name with the BMQT_ prefix elided. Note that specifying a value that does not match any of the enumerators will result in a string representation that is distinct from any of those corresponding to the enumerators, but is otherwise unspecified.
Return true and fills the specified out with the enum value corresponding to the specified str, if valid, or return false and leave out untouched if str doesn't correspond to any value of the enum.
-
-
-
-The documentation for this struct was generated from the following file:
Write the string representation of the specified enumeration value to the specified output stream, and return a reference to stream. Optionally specify an initial indentation level, whose absolute value is incremented recursively for nested objects. If level is specified, optionally specify spacesPerLevel, whose absolute value indicates the number of spaces per indentation level for this and all of its nested objects. If level is negative, suppress indentation of the first line. If spacesPerLevel is negative, format the entire output on one line, suppressing all but the initial indentation (as governed by level). See toAscii for what constitutes the string representation of a MessageEventType::Value value.
Return the non-modifiable string representation corresponding to the specified enumeration value, if it exists, and a unique (error) string otherwise. The string representation of value matches its corresponding enumerator name with the BMQT_ prefix elided. Note that specifying a value that does not match any of the enumerators will result in a string representation that is distinct from any of those corresponding to the enumerators, but is otherwise unspecified.
Return true and fills the specified out with the enum value corresponding to the specified str, if valid, or return false and leave out untouched if str doesn't correspond to any value of the enum.
Write the string representation of the specified enumeration value to the specified output stream, and return a reference to stream. Optionally specify an initial indentation level, whose absolute value is incremented recursively for nested objects. If level is specified, optionally specify spacesPerLevel, whose absolute value indicates the number of spaces per indentation level for this and all of its nested objects. If level is negative, suppress indentation of the first line. If spacesPerLevel is negative, format the entire output on one line, suppressing all but the initial indentation (as governed by level). See toAscii for what constitutes the string representation of a OpenQueueResult::Enum value.
Return the non-modifiable string representation corresponding to the specified enumeration value, if it exists, and a unique (error) string otherwise. The string representation of value matches its corresponding enumerator name with the e_ prefix elided. Note that specifying a value that does not match any of the enumerators will result in a string representation that is distinct from any of those corresponding to the enumerators, but is otherwise unspecified.
Return true and fills the specified out with the enum value corresponding to the specified str, if valid, or return false and leave out untouched if str doesn't correspond to any value of the enum.
-
-
-
-The documentation for this struct was generated from the following file:
Write the string representation of the specified enumeration value to the specified output stream, and return a reference to stream. Optionally specify an initial indentation level, whose absolute value is incremented recursively for nested objects. If level is specified, optionally specify spacesPerLevel, whose absolute value indicates the number of spaces per indentation level for this and all of its nested objects. If level is negative, suppress indentation of the first line. If spacesPerLevel is negative, format the entire output on one line, suppressing all but the initial indentation (as governed by level). See toAscii for what constitutes the string representation of a PublishResult::Enum value.
Return the non-modifiable string representation corresponding to the specified enumeration value, if it exists, and a unique (error) string otherwise. The string representation of value matches its corresponding enumerator name with the e_ prefix elided. Note that specifying a value that does not match any of the enumerators will result in a string representation that is distinct from any of those corresponding to the enumerators, but is otherwise unspecified.
Return true and fills the specified out with the enum value corresponding to the specified str, if valid, or return false and leave out untouched if str doesn't correspond to any value of the enum.
-
-
-
-The documentation for this struct was generated from the following file:
Write the string representation of the specified enumeration value to the specified output stream, and return a reference to stream. Optionally specify an initial indentation level, whose absolute value is incremented recursively for nested objects. If level is specified, optionally specify spacesPerLevel, whose absolute value indicates the number of spaces per indentation level for this and all of its nested objects. If level is negative, suppress indentation of the first line. If spacesPerLevel is negative, format the entire output on one line, suppressing all but the initial indentation (as governed by level). See toAscii for what constitutes the string representation of a PropertyType::Enum value.
Return the non-modifiable string representation corresponding to the specified enumeration value, if it exists, and a unique (error) string otherwise. The string representation of value matches its corresponding enumerator name with the e_ prefix elided. Note that specifying a value that does not match any of the enumerators will result in a string representation that is distinct from any of those corresponding to the enumerators, but is otherwise unspecified.
Return true and fills the specified out with the enum value corresponding to the specified str, if valid, or return false and leave out untouched if str doesn't correspond to any value of the enum.
Write the string representation of the specified enumeration value to the specified output stream, and return a reference to stream. Optionally specify an initial indentation level, whose absolute value is incremented recursively for nested objects. If level is specified, optionally specify spacesPerLevel, whose absolute value indicates the number of spaces per indentation level for this and all of its nested objects. If level is negative, suppress indentation of the first line. If spacesPerLevel is negative, format the entire output on one line, suppressing all but the initial indentation (as governed by level). See toAscii for what constitutes the string representation of a GenericResult::Enum value.
Return the non-modifiable string representation corresponding to the specified enumeration value, if it exists, and a unique (error) string otherwise. The string representation of value matches its corresponding enumerator name with the e_ prefix elided. Note that specifying a value that does not match any of the enumerators will result in a string representation that is distinct from any of those corresponding to the enumerators, but is otherwise unspecified.
Return true and fills the specified out with the enum value corresponding to the specified str, if valid, or return false and leave out untouched if str doesn't correspond to any value of the enum.
Return true if the bit-mask in the specified flags has the specified flag set, or false if not.
-
DEPRECATED: This method is deprecated in favor of the below more specific accessors; and should be made private once all clients have been updated to the new APIs.
-
-
-
-
-
-
-
-
-
static bool bmqt::QueueFlagsUtil::isValid
-
(
-
bsl::ostream &
-
errorDescription,
-
-
-
-
-
bsls::Types::Uint64
-
flags
-
-
-
-
)
-
[static]
-
-
-
-
-
Check whether the specified flags represent a valid combination of flags to use for opening a queue. Return true if it does, or false if some exclusive flags are both set, and populate the specified errorDescription with the reason of the failure.
Print the ascii-representation of all the values set in the specified flags to the specified stream. Each value is , separated.
-
-
-
-
-
-
-
-
-
static int bmqt::QueueFlagsUtil::fromString
-
(
-
bsl::ostream &
-
errorDescription,
-
-
-
-
-
bsls::Types::Uint64 *
-
out,
-
-
-
-
-
const bsl::string &
-
str
-
-
-
-
)
-
[static]
-
-
-
-
-
Convert the string representation of the enum bit mask from the specified str (which format corresponds to the one of the prettyPrint method) and populate the specified out with the result on success returning 0, or return a non-zero error code on error, populating the specified errorDescription with a description of the error.
-
-
-
-The documentation for this struct was generated from the following file:
Write the string representation of the specified enumeration value to the specified output stream, and return a reference to stream. Optionally specify an initial indentation level, whose absolute value is incremented recursively for nested objects. If level is specified, optionally specify spacesPerLevel, whose absolute value indicates the number of spaces per indentation level for this and all of its nested objects. If level is negative, suppress indentation of the first line. If spacesPerLevel is negative, format the entire output on one line, suppressing all but the initial indentation (as governed by level). See toAscii for what constitutes the string representation of a SessionEventType::Value value.
Return the non-modifiable string representation corresponding to the specified enumeration value, if it exists, and a unique (error) string otherwise. The string representation of value matches its corresponding enumerator name with the BMQT_ prefix elided. Note that specifying a value that does not match any of the enumerators will result in a string representation that is distinct from any of those corresponding to the enumerators, but is otherwise unspecified.
Return true and fills the specified out with the enum value corresponding to the specified str, if valid, or return false and leave out untouched if str doesn't correspond to any value of the enum.
-
-
-
-The documentation for this struct was generated from the following file:
Initialize the UriParser. Note that this will compile the regular expression used by parseUri. This method only needs to be called once before any other method, but can be called multiple times provided that for each call to initialize there is a corresponding call to shutdown. Use the optionally specified allocator for any memory allocation, or the global allocator if none is provided. Note that specifying the allocator is provided for test drivers only, and therefore users should let it default to the global allocator.
-
-
-
-
-
-
-
-
-
static void bmqt::UriParser::shutdown
-
(
-
-
)
-
[static]
-
-
-
-
-
Pendant operation of the initialize one. Note that behaviour after calling the .parse() method of the UriParser after shutdown has been called is undefined. The number of calls to shutdown must equal the number of calls to initialize, without corresponding shutdown calls, to fully destroy the parser. It is safe to call initialize after calling shutdown. Behaviour is undefined if shutdown is called without initialize first being called.
Parse the specified uriString into the specified result object if uriString is a valid URI, otherwise load the specified errorDescription with a description of the syntax error present in uriString. Return 0 on success and non-zero if uriString does not have a valid syntax. Note that errorDescription may be null if the caller does not care about getting error messages. The behavior is undefined unless initialize has been called previously.
-
-
-
-The documentation for this struct was generated from the following file:
Connect to the BlazingMQ broker and start the message processing
-
-
This method returns without blocking. The result of the operation is communicated with a
- session event. If the optionally specified 'timeout' is not populated, use the one defined in
- the session options.
Gracefully disconnect from the BlazingMQ broker and stop the operation of this 'Session'.
-
-
This method returns without blocking. The result of the operation is communicated with a
- session event. If the optionally specified 'timeout' is not populated, use the one defined in
- the session options.
ACK message is sent by the broker to the producer to confirm that it gets PUT message sent by
- the producer. ACK message holds unique MessageGUID assigned by the
- broker and CorrelationId that equals to the corresponding value from
- the PutMessage and allows to identify related PUT message.
Returns an array containing the constants of this enum type, in
-the order they are declared. This method may be used to iterate
-over the constants as follows:
-
-for (CompressionAlgorithm c : CompressionAlgorithm.values())
- System.out.println(c);
-
-
-
Returns:
-
an array containing the constants of this enum type, in the order they are declared
Returns the enum constant of this type with the specified name.
-The string must match exactly an identifier used to declare an
-enum constant in this type. (Extraneous whitespace characters are
-not permitted.)
-
-
Parameters:
-
name - the name of the enum constant to be returned.
Provides an interface usable as an efficient identifier.
-
-
This is an interface, which can be used to identify any async operations. The CorrelationId internally provides an auto-assigned value (32-bit integer with 24 meaningful
- bits). It may also contain an optional user provided Object. PutMessage.setCorrelationId() can be used to consecutively generate a unique
- CorrelationId starting from 1 and up to 0xFFFFFF from multiple execution threads.
- Another flavour of the PutMessage#setCorrelationId can be used to generate similar unique
- CorrelationId that will held a user specified Object.
Provides an interface for monitoring the health of the host. BlazingMQ sessions can use such
- objects to conditionally suspend queue activity while the host is marked unhealthy
Returns an array containing the constants of this enum type, in
-the order they are declared. This method may be used to iterate
-over the constants as follows:
-
-for (HostHealthState c : HostHealthState.values())
- System.out.println(c);
-
-
-
Returns:
-
an array containing the constants of this enum type, in the order they are declared
Returns the enum constant of this type with the specified name.
-The string must match exactly an identifier used to declare an
-enum constant in this type. (Extraneous whitespace characters are
-not permitted.)
-
-
Parameters:
-
name - the name of the enum constant to be returned.
Provides a value-semantic global unique identifier for BlazingMQ messages.
-
-
MessageGUID provides a value-semantic global unique identifier for BlazingMQ messages.
- Each message delivered to BlazingMQ client from BlazingMQ broker contains a unique MessageGUID.
-
-
Externalization
-
- For convenience, this class provides toHex method that can be used to externalize a
- MessageGUID instance. Applications can persist the resultant buffer (on filesystem, in
- database) to keep track of last processed message ID across task instantiations. fromHex
- method can be used to convert a valid externalized buffer back to a message ID.
-
-
Writes a binary representation of this object to the specified destination which
- length should be SIZE_BINARY. Note that destination can later be used to
- populate a MessageGUID object using fromBinary(byte[]) method.
-
-
Parameters:
-
destination - byte array to store a binary representation of this GUID
Returns a hex representation of this object as a String. Note that the returned
- string can later be used to create a MessageGUID object using fromHex method.
Returns a new MessageGUID created from the specified String contained
- hexadecimal representation of the GUID.
-
-
Parameters:
-
val - string with a hexadecimal representation of the GUID
-
Returns:
-
MessageGUID newly created MessageGUID object
-
Throws:
-
IllegalArgumentException - in case of the specified string is not a valid
- hexadecimal representation of the GUID, or if error happens during string decoding
Returns an array containing the constants of this enum type, in
-the order they are declared. This method may be used to iterate
-over the constants as follows:
-
-for (MessageProperty.Type c : MessageProperty.Type.values())
- System.out.println(c);
-
-
-
Returns:
-
an array containing the constants of this enum type, in the order they are declared
Returns the enum constant of this type with the specified name.
-The string must match exactly an identifier used to declare an
-enum constant in this type. (Extraneous whitespace characters are
-not permitted.)
-
-
Parameters:
-
name - the name of the enum constant to be returned.
Sets and returns a new CorrelationId that binds an auto-assigned integer value
- starting from 1 and up to 0xFFFFFF and the user specified Object. The user
- can expect that a valid CorrelationId provided to the PutMessage and the
- CorrelationId obtained from the corresponding AckMessage will hold the same
- Object available via CorrelationId.userData() accessor.
-
-
Parameters:
-
obj - user specified object
-
Returns:
-
CorrelationId auto-generated correlation ID that stores the user specified object
Returns an array containing the constants of this enum type, in
-the order they are declared. This method may be used to iterate
-over the constants as follows:
-
-for (QueueControlEvent.Type c : QueueControlEvent.Type.values())
- System.out.println(c);
-
-
-
Returns:
-
an array containing the constants of this enum type, in the order they are declared
Returns the enum constant of this type with the specified name.
-The string must match exactly an identifier used to declare an
-enum constant in this type. (Extraneous whitespace characters are
-not permitted.)
-
-
Parameters:
-
name - the name of the enum constant to be returned.
Returns an array containing the constants of this enum type, in
-the order they are declared. This method may be used to iterate
-over the constants as follows:
-
-for (QueueFlags c : QueueFlags.values())
- System.out.println(c);
-
-
-
Returns:
-
an array containing the constants of this enum type, in the order they are declared
Returns the enum constant of this type with the specified name.
-The string must match exactly an identifier used to declare an
-enum constant in this type. (Extraneous whitespace characters are
-not permitted.)
-
-
Parameters:
-
name - the name of the enum constant to be returned.
Returns maximum accumulated bytes of all outstanding messages that can be sent by the broker
- without being confirmed. If not set returns default value.
-
-
Returns:
-
long maximum accumulated bytes of all outstanding messages without being confirmed
Returns an array containing the constants of this enum type, in
-the order they are declared. This method may be used to iterate
-over the constants as follows:
-
-for (ResultCodes.AckResult c : ResultCodes.AckResult.values())
- System.out.println(c);
-
-
-
Returns:
-
an array containing the constants of this enum type, in the order they are declared
Returns the enum constant of this type with the specified name.
-The string must match exactly an identifier used to declare an
-enum constant in this type. (Extraneous whitespace characters are
-not permitted.)
-
-
Parameters:
-
name - the name of the enum constant to be returned.
Returns an array containing the constants of this enum type, in
-the order they are declared. This method may be used to iterate
-over the constants as follows:
-
-for (ResultCodes.CloseQueueResult c : ResultCodes.CloseQueueResult.values())
- System.out.println(c);
-
-
-
Returns:
-
an array containing the constants of this enum type, in the order they are declared
Returns the enum constant of this type with the specified name.
-The string must match exactly an identifier used to declare an
-enum constant in this type. (Extraneous whitespace characters are
-not permitted.)
-
-
Parameters:
-
name - the name of the enum constant to be returned.
Returns an array containing the constants of this enum type, in
-the order they are declared. This method may be used to iterate
-over the constants as follows:
-
-for (ResultCodes.ConfigureQueueResult c : ResultCodes.ConfigureQueueResult.values())
- System.out.println(c);
-
-
-
Returns:
-
an array containing the constants of this enum type, in the order they are declared
Returns the enum constant of this type with the specified name.
-The string must match exactly an identifier used to declare an
-enum constant in this type. (Extraneous whitespace characters are
-not permitted.)
-
-
Parameters:
-
name - the name of the enum constant to be returned.
Returns an array containing the constants of this enum type, in
-the order they are declared. This method may be used to iterate
-over the constants as follows:
-
-for (ResultCodes.GenericResult c : ResultCodes.GenericResult.values())
- System.out.println(c);
-
-
-
Returns:
-
an array containing the constants of this enum type, in the order they are declared
Returns the enum constant of this type with the specified name.
-The string must match exactly an identifier used to declare an
-enum constant in this type. (Extraneous whitespace characters are
-not permitted.)
-
-
Parameters:
-
name - the name of the enum constant to be returned.
Returns an array containing the constants of this enum type, in
-the order they are declared. This method may be used to iterate
-over the constants as follows:
-
-for (ResultCodes.OpenQueueResult c : ResultCodes.OpenQueueResult.values())
- System.out.println(c);
-
-
-
Returns:
-
an array containing the constants of this enum type, in the order they are declared
Returns the enum constant of this type with the specified name.
-The string must match exactly an identifier used to declare an
-enum constant in this type. (Extraneous whitespace characters are
-not permitted.)
-
-
Parameters:
-
name - the name of the enum constant to be returned.
This component provides access to a message queue broker. The broker manages named, persistent
- queues of messages. This broker allows a client to open queues, post messages to them, or
- retrieve messages from them. All of these operations take place within the context of the session
- opened by the client application.
-
-
Messages received from a broker are communicated to the application by the session associated
- with that broker in the form of events (see Event). Events can be of
- two different types: (1) Messages and queue status events (QueueEvent),
- or (2) Session status events (SessionEvent).
-
-
A Session dispatches events to the application in an asynchronous mode. The applicaton
- must supply a concrete SessionEventHandler object at construction time.
- The concrete SessionEventHandler provided by the application must implement the SessionEventHandler.handleSessionEvent() method, which will be called by the Session
- every time a session event is received.
-
-
Note that the concrete SessionEventHandler may implement a handler for the specific
- session event type and it will be called by the Session for that event instead of the
- default handleSessionEvent.
-
-
A Session allows start and stop operations in synchronous or
- asynchronous version for the convenience of the programmer.
-
-
By default a Session connects to the local broker, which in turn may connect to a
- remote cluster based on configuration.
-
-
After a Session started, the application has to open one or several queues in read
- and/or write mode (see AbstractSession.getQueue()).
-
-
Disclaimer
-
- A Session object is a heavy object representing the negotiated TCP session with the
- broker, and the entire associated state (opened queues, etc.) Therefore, there should only be
- one session per task, created at task startup and closed at task shutdown. It is extremely
- inefficient, and an abuse of resource to create a session ad-hoc every time a message needs to be
- posted.
-
-
Thread-safety
-
- This session object is thread enabled, meaning that two threads can safely call any
- methods on the same instance without external synchronization.
-
-
Connecting to the Broker
-
- A Session establishes a communication with a broker service using TCP/IP. Each Session object must be constructed with a SessionOptions object, which
- provides the necessary information to connect to the broker. In particular, the SessionOptions object must specify the IP address and port needed to connect to the broker. The
- SessionOptions object may also provide extra parameters for tuning the TCP connection
- behavior.
-
-
Note that in most cases the user does not need to explicitly construct a SessionOptions object: the default factory method SessionOptions.createDefault() creates an instance that will connect to the
- broker service on the local machine using the standard port.
-
-
A Session object is created in an unconnected state. The start or startAsync method must be called to connect to the broker. Note that start method is
- blocking, and returns either after connection to broker has been established (success), or after
- specified timeout (failure). startAsync method, as the name suggests, connects to the
- broker asynchronously (i.e., it returns immediately), and the result of the operation is notified
- via SessionEvent.StartStatus session event.
-
-
When the Session is no longer needed, the application should call the stop
- (blocking) or stopAsync (non-blocking) method to disconnect from the broker. Note that
- the session can be restarted with a call to start or startAsync once it has been
- fully stopped. To fully shut down the session linger should be called after stop, and
- after that the session restart is not possible any more.
-
-
Connection loss and reconnection
-
- If the connection between the application and the broker is lost, the Session will
- automatically try to reconnect periodically. The Session will also notify the application
- of the event of losing the connection via SessionEvent.ConnectionLost
- session event.
-
-
Once the connection has been re-established with the broker (as a result of one of the
- periodic reconnection attempts), the Session will notify the application via SessionEvent.Reconnected session event. After the connection re-establishment,
- the Session will attempt to reopen the queues that were in OPEN state prior to
- connection loss. The Session will notify the application of the result of reopen
- operation via QueueControlEvent.ReopenQueueResult for each queue. Note
- that a reopen operation on a queue may fail (due to broker issue, machine issue, etc), so the
- application must keep track on these session events, and stop posting on a queue that failed to
- reopen.
-
-
After all reopen operations are complete and application has been notified with all ReopenQueueResult events, the Session delivers a SessionEvent.StateRestored session event to the application.
-
-
Note that if there were no opened queues prior to connection loss then the Session
- will send StateRestored event immediately after Reconnected session event.
-
-
Example 1
-
- The following example illustrates how to create a Session start it, stop and shutdown it.
-
-
- void runSession() {
- SessionOptions sessionOptions = SessionOptions.builder()
- .setBrokerUri(URI.create(tcp://localhost:30114")
- .build();
- AbstractSession session = new Session(sessionOptions, null);
- try {
- session.start(Duration.ofSeconds(10));
- System.out.println("Session started");
-
- // Open queue in READ or WRITE or READ/WRITE mode, and receive or
- // post messages, etc.
-
- session.stop(Duration.ofSeconds(10));
- } catch (BMQException e) {
- System.out.println("Operation error: " + e);
- } finally {
- session.linger();
- }
- }
-
-
- This example can be simplified because the constructor for Session uses a default SessionOptions object that will connect to the local broker service. The example may be
- rewritten as follow:
-
-
- void runSession() {
- AbstractSession session = new Session(null);
- try {
- session.start(Duration.ofSeconds(10));
- System.out.println("Session started");
-
- // Open queue in READ or WRITE or READ/WRITE mode, and receive or
- // post messages, etc.
-
- session.stop(Duration.ofSeconds(10));
- } catch (BMQException e) {
- System.out.println("Operation error: " + e);
- } finally {
- session.linger();
- }
- }
-
-
-
Processing session events
-
- If the Session is created with non null SessionEventHandler
- then it will be used to notify the application about session events like results of Session.startAsync() and Session.stopAsync() operations, and connection statuses like
- SessionEvent.ConnectionLost, SessionEvent.Reconnected, SessionEvent.StateRestored. Each event may be handled in its special callback if the application
- implements related method, e.g. SessionEventHandler.handleStartStatusSessionEvent(), or it can use the default implementation
- that calls SessionEventHandler.handleSessionEvent(), for each session event without user defined handler.
-
-
Example 2
-
- The following example demonstrates a usage of the simplest SessionEventHandler
-
-
- Session session = new Session(new SessionEventHandler() {
-
- public void handleSessionEvent(SessionEvent event) {
- switch (event.type()) {
- case START_STATUS_SESSION_EVENT:
- GenericResult result = ((SessionEvent.StartStatus)event).result();
- if (result.isSuccess()) {
- System.out.println("The connection to the broker is established");
- openQueues();
- startPostingToQueues();
- } else if (result.isTimeout()) {
- System.out.println("The connection to the broker has timed out");
- }
- break;
- case STOP_STATUS_SESSION_EVENT:
- GenericResult result = ((SessionEvent.StopStatus)event).result();
- if (result.isSuccess()) {
- System.out.println("The connection to the broker is closed gracefully");
- }
- break;
- case CONNECTION_LOST_SESSION_EVENT:
- // The connection to the broker dropped. Stop posting to the queue.
- stopPostingToQueues();
- break;
- case RECONNECTED_SESSION_EVENT:
- // The connection to the broker has been restored, but the queue may not be ready yet.
- break;
- case STATE_RESTORED_SESSION_EVENT:
- // The connection to the broker has been restored and all queues
- // have been re-opened. Resume posting to the queue.
- resumePostingToQueues();
- break;
- cae UNKNOWN_SESSION_EVENT:
- default:
- System.out.println("Unexpected session event: " + event);
- }
- }
- });
-
- session.startAsync(Duration.ofSeconds(10));
-
-
- And in the following version session start status event will be handled in a separate callback
- while all the other session events will be passed to handleSessionEvent
-
-
-
- Session session = new Session( new SessionEventHandler() {
-
- public void handleSessionEvent(SessionEvent event) {
- System.out.println("Other session event: " + event);
- }
-
- public void handleStartStatusSessionEvent(SessionEvent.StartStatus event) {
- System.out.println("Session start status: " + event.result());
- if (event.result().isSuccess()) {
- System.out.println("The connection to the broker is established");
- }
- }
- });
-
- session.startAsync(Duration.ofSeconds(10));
-
-
- Note that after the Session is associated with some session event handler, this
- association cannot be changed or canceled. The event handler will be used for processing events
- until the Session.linger() is called.
-
-
Opening queues
-
- Once the Session has been created and started, the application can use it to open queues
- for producing and/or consuming messages. A queue is associated with a domain. Domain metadata
- must be deployed in the BlazingMQ infrastructure prior to opening queues under that domain,
- because opening a queue actually loads the metadata deployed for the associated domain.
-
-
The metadata associated with a domain defines various parameters like maximum queue size and
- capacity, persistent policy, routing policy, etc.
-
-
Queue are identified by URIs (Unified Resource Identifiers) that must follow the BlazingMQ
- syntax, manipulated as Uri objects. A queue URI is typically formatted
- as follows:
-
-
-
- bmq://my.domain/my.queue
-
-
- Note that domain names are unique in BlazingMQ infrastructure, which makes a fully qualified
- queue URI unique too.
-
-
Queues in BlazingMQ infrastructure are created by applications on demand. Broker creates a
- queue when it receives an open-queue request from an application for a queue that does not exist
- currently.
-
-
Application can open a queue by calling AbstractSession.getQueue() method on a started session. Application must pass appropriate flags
- to indicate if it wants to post messages to queue, consume messages from the queue, or both. Also
- it has to provide concrete QueueEventHandler to recieve queue related
- events. Depending on the queue flags it also needs to supply concrete AckMessageHandler it the queue will be used for message posting. This handler
- will be called each time when ACK event comes from the broker. And if the queue will be
- used for comsuming the messages then PushMessageHandler should be
- supplied. It will be called on each incoming PushMessage. Once the
- application obtainns the Queue interface it can call Queue.open() or Queue.openAsync().
-
-
Note that open is a blocking method, and returns after the queue has been successfully
- opened (success) or after specified timeout has expired (failure). openAsync method, as
- the name suggests, is non blocking, and the result of the operation is notified via QueueControlEvent.OpenQueueResult session event.
-
-
Example 3
-
- The following example demonstrates how to open a queue for posting messages. The code first opens
- the queue with appropriate flags, and then uses Queue.createPutMessage(java.nio.ByteBuffer...)
- to create a message and post to the queue.
-
-
- // Session creation, startup logic and exception handling elided for brevity
- Uri queueUri = new Uri("bmq://my.domain/my.queue");
-
- // Application can implement concrete QueueMessageHandler and AckMessageHandler,
- // or e.g. use a functional interface feature with a standard collection.
- ArrayList<QueueControlEvent> queueEvents = new ArrayList();
- ArrayList<AckMessage> ackMessages = new ArrayList();
-
- long flags = QueueFlags.setWriter(0);
- flags = QueueFlags.setAck(flags);
-
- Queue myQueue = session.getQueue(
- queueUri,
- flags, // Setup queue flag for producer
- queueEvents::add, // QueueEventHandler is a functional interface
- ackMessages::add, // AckMessageHandler is a functional interface
- null); // PushMessageHandler is null since we don't want
- // to receive messages
- myQueue.open(QueueOptions.createDefault(), Duration.ofSeconds(5));
-
-
- Note that apart from QueueFlags.WRITE flag, QueueFlags.ACK flag has been passed to getQueue method above. This
- indicates that application is interested in receiving ACK notification for each message
- it posts to the queue, irrespective of whether or not the message was successfully received by
- the broker and posted to the queue. Also note that if the queue has QueueFlags.ACK} flag
- then every PUT message that is going to be posted via this queue should have a valid
- CorrelationId, see Queue.createPutMessage(java.nio.ByteBuffer...).
-
-
Once the queue has been successfully opened for writing, messages can be posted to the queue
- for consumption by interested applications.
-
-
- // Prepare user payload
- String userMessage = "Hello!";
- ByteBuffer byteBuffer = ByteBuffer.wrap(userMessage.getBytes());
-
- // Get PUT message interface from the opened queue
- PutMessage msg = myQueue.createPutMessage(byteBuffer);
-
- // Add unique correlation ID. The broker will send ACK in response to this message.
- // The ID can be used to bind this message with the corresponding ACK.
- msg.setAutoCorrelationId();
-
- // Add some optional properties
- MessageProperties mp = msg.messageProperties();
- mp.setPropertyAsString("myId", "abcd-efgh-ijkl");
- mp.setPropertyAsInt64("timestamp", 123456789L);
-
- // Post this message to the queue
- myQueue.post(msg);
-
-
- To post multiple messages at once the application may use Queue.pack() and Queue.flush() methods:
-
-
- for (int i = 0; i < 10; i++) {
- PutMessage msg = myQueue.createPutMessage(payload);
- // ... Set CorrelationID message properties
-
- myQueue.pack(msg);
- }
- // Now post the messages all together
- myQueue.flush();
-
-
-
Closing queues
-
- After an application no longer needs to produce or consume messages from a queue, it can be
- closed by Queue.close() or Queue.closeAsync() method. Note that closing a queue closes
- an application's "view" on the queue, and may not lead to queue deletion in the broker. A Session does not expose any method to explicitly delete a queue.
-
-
Note that close is a blocking method and returns after the queue has been successfully
- closed (success) or after specified timeout has expired (failure). closeAsync, as the
- name suggests, is a non-blocking method, and result of the operation is notified via QueueControlEvent.CloseQueueResult queue event.
Connects to the BlazingMQ broker and start the message processing
-
-
This method returns without blocking. The result of the operation is communicated with a
- session event. If the optionally specified 'timeout' is not populated, use the one defined in
- the session options.
Gracefully disconnects from the BlazingMQ broker and stop the operation of this session.
-
-
This method returns without blocking. The result of the operation is communicated with a
- session event. If the optionally specified timeout is not populated, use the one
- defined in the session options.
Session event generated in case the host has become unhealthy. Only issued if a HostHealthMonitor has been installed to the session, via the SessionOptions object.
public static final SessionEvent.Type HOST_HEALTH_RESTORED_SESSION_EVENT
-
Session event generated in case the health of the host has restored, and all queues have
- resumed operation. Following a Host Health incident, this indicates that the application
- has resumed normal operation.
Returns an array containing the constants of this enum type, in
-the order they are declared. This method may be used to iterate
-over the constants as follows:
-
-for (SessionEvent.Type c : SessionEvent.Type.values())
- System.out.println(c);
-
-
-
Returns:
-
an array containing the constants of this enum type, in the order they are declared
Returns the enum constant of this type with the specified name.
-The string must match exactly an identifier used to declare an
-enum constant in this type. (Extraneous whitespace characters are
-not permitted.)
-
-
Parameters:
-
name - the name of the enum constant to be returned.
@Immutable
-public static class SessionOptions.InboundEventBufferWaterMark
-extends Object
-
Immutable helper class to set sizes (in number of events) for the inbound event buffer high
- and low watermarks. Default value for high watermark is 1000 events. Default value for low
- watermark is 500 events.
@Immutable
-public static class SessionOptions.WriteBufferWaterMark
-extends Object
-
Immutable helper class to set sizes (in bytes) for write cache high and low watermarks on the
- channel. Default value for high watermark is 64MB. Default value for low watermark is 1MB.
A value-semantic type to configure session with the broker.
-
-
Provides a value-semantic type which is used to specify session-level configuration
- parameters.
-
-
Most applications should not need to change the parameters for creating a AbstractSession; 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, example foobar (or localhost)
-
an ip, example 10.11.12.13
-
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.
-
-
WriteBufferWaterMark: Sizes (in bytes) to use for write cache high and low
- watermarks on the channel. Default value for high watermark is 64MB. Note that BlazingMQ
- reserves 4MB of this value for control message, so the actual watermark for data published
- is 'HighWatermark - 4MB'. Default value for low watermark is 1MB.
-
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.
-
Default timeouts to use for various operations:
-
-
startTimeout,
-
stopTimeout,
-
openQueueTimeout,
-
configureQueueTimeout,
-
closeQueueTimeout.
-
-
hostHealthMonitor: Optional instance of a class implementing HostHealthMonitor interface responsible for notifying the session when the health of the
- host machine has changed. A hostHealthMonitor must be specified in oder for queues
- opened through the session to suspend on unhealthy hosts.
-
-
-
Thread Safety
-
- Once created SessionOptions object is immutable and thread safe. Helper class Builder is provided for SessionOptions creation.
-
-
Usage Example 1
-
- Create SessionOptions object with default values:
-
-
Returns interval (in seconds) at which to dump stats in the logs. Default is 5min. "0" means
- disabled recurring dump of stats (final stats are always dumped at end of session).
Returns an object which monitors the health of the host. BlazingMQ sessions can use such
- objects to conditionally suspend queue activity while the host is marked unhealthy. Default
- value is null that means no monitor is set.
Provides value-semantic type and utilities for a BlazingMQ queue URI.
-
-
This class provides a value-semantic type, representing a URI for a BlazingMQ queue. A Uri can be built by parsing from a string representation provided to the class constructor.
-
-
URI format
-
- In a nutshell, a URI representing an application queue managed by a BlazingMQ broker on a given
- machine looks like one of the following:
-
-
The URI authority is the name of BlazingMQ domain (such as "ts.trades.myapp") as registered
- with the BlazingMQ infrastructure. The domain name may contain alphanumeric characters,
- dots and dashes (it has to match the following regular expression: [-a-zA-Z0-9\\._]+'. The domain may be followed by an optional tier, introduced by the ".~"
- sequence and consisting of alphanumeric characters and dashes. The ".~" sequence is not
- part of the tier.
-
The URI path is the name of the queue ("my.queue" above) and may contain alphanumeric
- characters, dashes, underscores and tild (it has to match the following regular expression:
- [-a-zA-Z0-9_~\\.]+).
-
The name of the queue (my.queue above) may contain alphanumeric characters and
- dots.
-
The URI may contain an optional query with a key-value pair, where key is always id, and corresponding value represents a name that will be used by BlazingMQ broker to
- uniquely identify the client.
-
The URI fragment part is currently unused.
-
-
-
Usage Example
-
- Instantiate a Uri object with a string representation of the URI:
-
-
-
- Uri uri = new Uri("bmq://my.domain/queue");
- assert uri.scheme() == "bmq";
- assert uri.domain() == "my.domain";
- assert uri.queue() == "queue";
-
-
-
Thread Safety
-
- Once created Uri object is immutable and thread safe.
This API (Application Programming Interface) document has pages corresponding to the items in the navigation bar, described as follows.
-
-
-
-
-
Package
-
Each package has a page that contains a list of its classes and interfaces, with a summary for each. This page can contain six categories:
-
-
Interfaces (italic)
-
Classes
-
Enums
-
Exceptions
-
Errors
-
Annotation Types
-
-
-
-
Class/Interface
-
Each class, interface, nested class and nested interface has its own separate page. Each of these pages has three sections consisting of a class/interface description, summary tables, and detailed member descriptions:
-
-
Class inheritance diagram
-
Direct Subclasses
-
All Known Subinterfaces
-
All Known Implementing Classes
-
Class/interface declaration
-
Class/interface description
-
-
-
Nested Class Summary
-
Field Summary
-
Constructor Summary
-
Method Summary
-
-
-
Field Detail
-
Constructor Detail
-
Method Detail
-
-
Each summary entry contains the first sentence from the detailed description for that item. The summary entries are alphabetical, while the detailed descriptions are in the order they appear in the source code. This preserves the logical groupings established by the programmer.
-
-
-
Annotation Type
-
Each annotation type has its own separate page with the following sections:
-
-
Annotation Type declaration
-
Annotation Type description
-
Required Element Summary
-
Optional Element Summary
-
Element Detail
-
-
-
-
Enum
-
Each enum has its own separate page with the following sections:
-
-
Enum declaration
-
Enum description
-
Enum Constant Summary
-
Enum Constant Detail
-
-
-
-
Use
-
Each documented package, class and interface has its own Use page. This page describes what packages, classes, methods, constructors and fields use any part of the given class or package. Given a class or interface A, its Use page includes subclasses of A, fields declared as A, methods that return A, and methods and constructors with parameters of type A. You can access this page by first going to the package, class or interface, then clicking on the "Use" link in the navigation bar.
-
-
-
Tree (Class Hierarchy)
-
There is a Class Hierarchy page for all packages, plus a hierarchy for each package. Each hierarchy page contains a list of classes and a list of interfaces. The classes are organized by inheritance structure starting with java.lang.Object. The interfaces do not inherit from java.lang.Object.
-
-
When viewing the Overview page, clicking on "Tree" displays the hierarchy for all packages.
-
When viewing a particular package, class or interface page, clicking "Tree" displays the hierarchy for only that package.
-
-
-
-
Deprecated API
-
The Deprecated API page lists all of the API that have been deprecated. A deprecated API is not recommended for use, generally due to improvements, and a replacement API is usually given. Deprecated APIs may be removed in future implementations.
-
-
-
Index
-
The Index contains an alphabetic list of all classes, interfaces, constructors, methods, and fields.
-
-
-
Prev/Next
-
These links take you to the next or previous class, interface, package, or related page.
-
-
-
Frames/No Frames
-
These links show and hide the HTML frames. All pages are available with or without frames.
-
-
-
All Classes
-
The All Classes link shows all classes and interfaces except non-static nested types.
-
-
-
Serialized Form
-
Each serializable or externalizable class has a description of its serialization fields and methods. This information is of interest to re-implementors, not to developers using the API. While there is no link in the navigation bar, you can get to this information by going to any serialized class and clicking "Serialized Form" in the "See also" section of the class description.
Running the entire test-suite with all supported interpreters on all
-supported architectures is difficult to do, and should already be set
-up with GitHub Actions. We advise testing with a single version of
-Python on a single architecture locally, and using the GitHub Actions
-CI to test on all other combinations in your pull request. See
-.github/workflows/build.yaml for more details on how we build and
-test on all supported interpreters and architectures.
-
The instructions below assume PYEXEC=python3.9 and will focus on Linux only.
-This should be sufficient in most cases.
-
Before following any of the instructions, make sure to gitclone the project onto the host machine.
Once the build environment is properly initialized, the project can
-be built in-tree (in the project’s working directory tree) using
-makebuild. This is useful to iterate quickly. However, it has the
-disadvantages of having to install all of the required
-build/test/lint dependencies, along with the potential to
-accidentally test against the wrong artifact due to the in-tree build.
-
For a more comprehensive, self-contained setup, use tox to build the project
-and run the entire test suite targeting a specific version of the interpreter.
-Run tox-l to see all available tox environments.
When in an interactive command line prompt, you can use the following make
-targets to build and test the BlazingMQ Python SDK. Check the
-appropriate GitHub Actions configuration to set up the appropriate environment
-variables that may be needed prior to running these commands (such as setting
-PYEXEC). With a BlazingMQ broker running at tcp://localhost:30114, the
-following targets build and test the Python SDK:
You should NOT add new change log entries to this file, this
-file is managed by towncrier. You may edit previous change logs to
-fix problems like typo corrections or such.
-# Copyright 2019-2023 Bloomberg Finance L.P.
-# SPDX-License-Identifier: Apache-2.0
-#
-# Licensed under the Apache License, Version 2.0 (the "License");
-# you may not use this file except in compliance with the License.
-# You may obtain a copy of the License at
-#
-# http://www.apache.org/licenses/LICENSE-2.0
-#
-# Unless required by applicable law or agreed to in writing, software
-# distributed under the License is distributed on an "AS IS" BASIS,
-# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-# See the License for the specific language governing permissions and
-# limitations under the License.
-
-fromenumimportEnum
-
-
-
-[docs]
-classAckStatus(Enum):
-"""An enum representing the status of an Ack message
-
- An `AckStatus` is a status of a received `Ack` message
- which is the result of an attempted put to some particular queue.
- Anything other than `AckStatus.SUCCESS` represents a failure.
- """
-
- SUCCESS=object()
- UNKNOWN=object()
- TIMEOUT=object()
- NOT_CONNECTED=object()
- CANCELED=object()
- NOT_SUPPORTED=object()
- REFUSED=object()
- INVALID_ARGUMENT=object()
- NOT_READY=object()
- LIMIT_BYTES=object()
- LIMIT_MESSAGES=object()
- STORAGE_FAILURE=object()
- UNRECOGNIZED=object()
-"""The `AckStatus` was not recognized by the binding layer"""
-
- def__repr__(self)->str:
- # hide the unimportant value of `object()`
- returnf"<{self.__class__.__name__}.{self.name}>"
-
-
-
-
-[docs]
-classCompressionAlgorithmType(Enum):
-"""An enum representing compression algorithm used by a producer"""
-
- NONE=object()
- ZLIB=object()
-
- def__repr__(self)->str:
- returnf"<{self.__class__.__name__}.{self.name}>"
-
-
-
-
-[docs]
-classPropertyType(Enum):
-"""An enum representing various data types understood by BlazingMQ"""
-
- BOOL=object()
- CHAR=object()
- SHORT=object()
- INT32=object()
- INT64=object()
- STRING=object()
- BINARY=object()
-
- def__repr__(self)->str:
- # hide the unimportant value of `object()`
- returnf"<{self.__class__.__name__}.{self.name}>"
-# Copyright 2019-2023 Bloomberg Finance L.P.
-# SPDX-License-Identifier: Apache-2.0
-#
-# Licensed under the Apache License, Version 2.0 (the "License");
-# you may not use this file except in compliance with the License.
-# You may obtain a copy of the License at
-#
-# http://www.apache.org/licenses/LICENSE-2.0
-#
-# Unless required by applicable law or agreed to in writing, software
-# distributed under the License is distributed on an "AS IS" BASIS,
-# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-# See the License for the specific language governing permissions and
-# limitations under the License.
-
-from__future__importannotations
-
-fromtypingimportOptional
-fromtypingimportTYPE_CHECKING
-
-from._enumsimportAckStatus
-from._typingimportPropertyTypeDict
-from._typingimportPropertyValueDict
-from.exceptionsimportError
-
-ifTYPE_CHECKING:
- # Safely perform circular references only during static type analysis
- from.import_ext# pragma: no cover
-
-
-defpretty_hex(blob:bytes)->str:
- returnblob.hex().upper()
-
-
-defcreate_message(
- data:bytes,
- guid:bytes,
- queue_uri:str,
- properties:PropertyValueDict,
- property_types:PropertyTypeDict,
-)->Message:
- inst=Message.__new__(Message)
- assertisinstance(inst,Message)
- inst._set_attrs(data,guid,queue_uri,properties,property_types)
- returninst
-
-
-
-[docs]
-classMessage:
-"""A class representing a message received from BlazingMQ.
-
- A `Message` represents a message delivered by BlazingMQ from a producer
- to this queue. This message can only be received if the queue is
- opened with 'read=True' mode enabled.
-
- Attributes:
- data (bytes): Payload for the message received from BlazingMQ.
- guid (bytes): Globally unique id for this message.
- queue_uri (str): Queue URI this message is for.
- properties (dict): A dictionary of BlazingMQ message properties.
- The dictionary keys must be :class:`str` representing the property
- names and the values must be of type :class:`str`, :class:`bytes`,
- :class:`bool` or :class:`int`.
- property_types (dict): A mapping of property names to
- `PropertyType` types. The dictionary is guaranteed to provide
- a value for each key already present in `Message.properties`
- """
-
- def_set_attrs(
- self,
- data:bytes,
- guid:bytes,
- queue_uri:str,
- properties:PropertyValueDict,
- property_types:PropertyTypeDict,
- )->None:
-"""Teach mypy what our instance variables are despite our private __init__"""
- self.data=data
- self.guid=guid
- self.queue_uri=queue_uri
- self.properties=properties
- self.property_types=property_types
-
- def__init__(self)->None:
- raiseError("The Message class does not have a public constructor.")
-
- def__repr__(self)->str:
- returnf"<Message[{pretty_hex(self.guid)}] for {self.queue_uri}>"
-[docs]
-classMessageHandle:
-"""Operations that can be performed on a `Message`.
-
- An instance of this class is received in the ``on_message``
- callback along with an instance of a `Message`.
- """
-
-
-[docs]
- defconfirm(self)->None:
-"""Confirm the message received along with this handle.
-
- See `Session.confirm` for more details.
-
- Raises:
- `~blazingmq.Error`: If the confirm message request
- was not successful.
- """
- self._ext_session.confirm(self._message)
-
-
- def_set_attrs(self,message:Message,ext_session:_ext.Session)->None:
-"""Teach mypy what our instance variables are despite our private __init__"""
- self._message=message
- self._ext_session=ext_session
-
- def__init__(self)->None:
- raiseError("The MessageHandle class does not have a public constructor.")
-
- def__repr__(self)->str:
- return"<MessageHandle[{}] for {}>".format(
- pretty_hex(self._message.guid),
- self._message.queue_uri,
- )
-[docs]
-classAck:
-"""Acknowledgment message
-
- An `Ack` is a notification from BlazingMQ to the application,
- specifying that the message has been received. This is valuable
- for ensuring delivery of messages.
-
- These messages will be received in the optionally provided callback to
- `Session.post()`.
-
- An `Ack` is by itself not an indication of success unless it has a status of
- `AckStatus.SUCCESS`.
-
- Attributes:
- guid (bytes): a globally unique identifier generated by BlazingMQ for the
- message that was successfully posted. This can be correlated between the
- producer and consumer to verify the flow of messages.
- queue_uri (str): the queue that this message was routed to. This is useful
- if you have many queues and you want to route this particular `Ack` to a
- particular queue.
- status (AckStatus): the `AckStatus` indicating the result of the post
- operation. Unless this is of type `AckStatus.SUCCESS`, the post has
- failed and potentially needs to be dealt with.
- """
-
- def_set_attrs(
- self,
- guid:Optional[bytes],
- status:AckStatus,
- status_description:str,
- queue_uri:str,
- )->None:
-"""Teach mypy what our instance variables are despite our private __init__"""
- self.guid=guid
- self.status=status
- self._status_description=status_description
- self.queue_uri=queue_uri
-
- def__init__(self)->None:
- raiseError("The Ack class does not have a public constructor.")
-
- def__repr__(self)->str:
- guid_identifier=""ifself.guidisNoneelsef"[{pretty_hex(self.guid)}]"
- return"<Ack{}{} for {}>".format(
- guid_identifier,
- self._status_description,
- self.queue_uri,
- )
-# Copyright 2019-2023 Bloomberg Finance L.P.
-# SPDX-License-Identifier: Apache-2.0
-#
-# Licensed under the Apache License, Version 2.0 (the "License");
-# you may not use this file except in compliance with the License.
-# You may obtain a copy of the License at
-#
-# http://www.apache.org/licenses/LICENSE-2.0
-#
-# Unless required by applicable law or agreed to in writing, software
-# distributed under the License is distributed on an "AS IS" BASIS,
-# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-# See the License for the specific language governing permissions and
-# limitations under the License.
-
-from._extimportFakeHostHealthMonitor
-
-
-
-[docs]
-classBasicHealthMonitor:
-"""Control whether a `.Session` sees the host as healthy or unhealthy.
-
- When a *BasicHealthMonitor* is passed for the `.Session` constructor's
- *host_health_monitor* parameter, you can control whether the BlazingMQ
- session sees the host as healthy or unhealthy by calling the `.set_healthy`
- and `.set_unhealthy` methods. Newly created instances default to the
- healthy state.
- """
-
- def__init__(self)->None:
- self._monitor=FakeHostHealthMonitor()
-
-
-[docs]
- defset_healthy(self)->None:
-"""Tell any associated `.Session` that the host is healthy."""
- self._monitor.set_healthy()
-
-
-
-[docs]
- defset_unhealthy(self)->None:
-"""Tell any associated `.Session` that the host is unhealthy."""
- self._monitor.set_unhealthy()
-# Copyright 2019-2023 Bloomberg Finance L.P.
-# SPDX-License-Identifier: Apache-2.0
-#
-# Licensed under the Apache License, Version 2.0 (the "License");
-# you may not use this file except in compliance with the License.
-# You may obtain a copy of the License at
-#
-# http://www.apache.org/licenses/LICENSE-2.0
-#
-# Unless required by applicable law or agreed to in writing, software
-# distributed under the License is distributed on an "AS IS" BASIS,
-# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-# See the License for the specific language governing permissions and
-# limitations under the License.
-
-from__future__importannotations
-
-fromtypingimportAny
-fromtypingimportCallable
-fromtypingimportDict
-fromtypingimportOptional
-fromtypingimportTuple
-fromtypingimportUnion
-
-from.import_sixassix
-from._enumsimportCompressionAlgorithmType
-from._enumsimportPropertyType
-from._extimportDEFAULT_CONSUMER_PRIORITY
-from._extimportDEFAULT_MAX_UNCONFIRMED_BYTES
-from._extimportDEFAULT_MAX_UNCONFIRMED_MESSAGES
-from._extimportDEFAULT_SUSPENDS_ON_BAD_HOST_HEALTH
-from._extimportPROPERTY_TYPES_FROM_PY_MAPPING
-from._extimportSessionasExtSession
-from._messagesimportAck
-from._messagesimportMessage
-from._messagesimportMessageHandle
-from._monitorsimportBasicHealthMonitor
-from._timeoutsimportTimeouts
-from._typingimportPropertyTypeDict
-from._typingimportPropertyValueDict
-from._typingimportPropertyValueType
-from.exceptionsimportError
-from.session_eventsimportSessionEvent
-
-
-classDefaultTimeoutType(float):
- def__repr__(self)->str:
- return"..."
-
-
-defDefaultMonitor()->Union[BasicHealthMonitor,None]:
- returnNone
-
-
-DEFAULT_TIMEOUT=DefaultTimeoutType()
-KNOWN_MONITORS=("blazingmq.BasicHealthMonitor",)
-
-
-def_validate_timeouts(timeouts:Timeouts)->Timeouts:
-"""Validate a `.Timeouts` instance for use by the Cython layer.
-
- If any of the timeouts contained within the `.Timeouts` instance are the
- `DEFAULT_TIMEOUT` sentinel or `None`, return `None`. Otherwise, validate
- that it is within the range accepted by `bsls::TimeInterval` and return it.
- """
- returnTimeouts(
- connect_timeout=_convert_timeout(timeouts.connect_timeout),
- disconnect_timeout=_convert_timeout(timeouts.disconnect_timeout),
- open_queue_timeout=_convert_timeout(timeouts.open_queue_timeout),
- configure_queue_timeout=_convert_timeout(timeouts.configure_queue_timeout),
- close_queue_timeout=_convert_timeout(timeouts.close_queue_timeout),
- )
-
-
-def_convert_timeout(timeout:Optional[float])->Optional[float]:
-"""Convert the timeout for use by the Cython layer.
-
- If it is the DEFAULT_TIMEOUT sentinel or None, return None. Otherwise,
- validate that it is within the range accepted by bsls::TimeInterval and
- return it.
- """
- iftimeoutisDEFAULT_TIMEOUTortimeoutisNone:
- returnNone
- elif0.0<timeout<2**63:
- returntimeout
- raiseValueError(f"timeout must be greater than 0.0, was {timeout}")
-
-
-def_convert_stats_dump_interval(interval:Optional[float])->Optional[float]:
-"""Convert the stats dump interval for use by the Cython layer.
-
- If is None, return None. Otherwise, validate that it is within the range
- accepted by bsls::TimeInterval and return it.
- """
- ifintervalisNone:
- returninterval
- if0.0<=interval<2**63:
- returninterval
- raiseValueError(f"stats_dump_interval must be nonnegative, was {interval}")
-
-
-def_collect_properties_and_types(
- properties:Optional[PropertyValueDict],
- property_type_overrides:Optional[PropertyTypeDict],
-)->Dict[bytes,Tuple[Union[int,bytes],int]]:
- property_val_by_name:Dict[bytes,PropertyValueType]={}
- property_type_by_name:Dict[bytes,PropertyType]={}
-
- ifproperties:
- forname,valinproperties.items():
- ifisinstance(val,bool):
- default_type=PropertyType.BOOL
- elifisinstance(val,int):
- default_type=PropertyType.INT64
- elifisinstance(val,str):
- default_type=PropertyType.STRING
- elifisinstance(val,bytes):
- default_type=PropertyType.BINARY
- else:
- raiseError(
- "Property values of type %r are not supported"%type(val).__name__
- )
-
- name_bytes=six.ensure_binary(name)
- property_val_by_name[name_bytes]=val
- property_type_by_name[name_bytes]=default_type
-
- ifproperty_type_overrides:
- forname,override_typeinproperty_type_overrides.items():
- name_bytes=six.ensure_binary(name)
- ifname_bytesnotinproperty_type_by_name:
- raiseError("Received override for non-existent property %r"%name)
- property_type_by_name[name_bytes]=override_type
-
- merged:Dict[bytes,Tuple[Union[int,bytes],int]]={}
- forname_bytes,valinproperty_val_by_name.items():
- property_type=property_type_by_name[name_bytes]
- type_code=PROPERTY_TYPES_FROM_PY_MAPPING[property_type]
- ifproperty_typeisPropertyType.STRINGandisinstance(val,str):
- merged[name_bytes]=(val.encode("utf-8"),type_code)
- else:
- merged[name_bytes]=(val,type_code)# type: ignore[assignment]
- # mypy warns because `merged` can still contain Text if a Text value was
- # passed for a non-STRING field. If so, the extension gives a nice error.
-
- returnmerged
-
-
-
-[docs]
-classQueueOptions:
-"""A value semantic type representing the settings for a queue.
-
- Each option can be set either by passing it as a keyword argument when
- constructing a *QueueOptions* instance, or by setting it as an attribute on
- a constructed instance.
-
- The default for every option is `None`. When calling `.configure_queue`,
- options set to `None` are not changed from their current setting. When
- calling `.open_queue`, options set to `None` are given default values.
- These default values are accessible as class attributes on the
- *QueueOptions* class.
-
- Args:
- max_unconfirmed_messages:
- The maximum number of messages that can be delivered to the queue
- without confirmation. This limit can be reached if the queue
- receives messages faster than it confirms received messages. Once
- this limit is reached, at least one message must be confirmed
- before the queue will receive any more messages.
- max_unconfirmed_bytes:
- The maximum number of bytes that can be delivered to the queue
- without confirmation. Like *max_unconfirmed_messages*, this limit
- can be reached if incoming messages are queued up waiting for
- already delivered messages to be confirmed.
- consumer_priority:
- The precedence of this consumer compared to other consumers of the
- same queue. The consumer with the highest priority receives the
- messages. If multiple consumers share the highest priority,
- messages are delivered to them in a round-robin fashion.
- suspends_on_bad_host_health:
- Whether or not this queue should suspend operation while the host
- machine is unhealthy. While operation is suspended, a queue opened
- with ``read=True`` will not receive messages and a queue opened
- with ``write=True`` will raise if you try to `.post` a message.
- By default, queues are not sensitive to the host's health.
- """
-
- DEFAULT_MAX_UNCONFIRMED_MESSAGES=DEFAULT_MAX_UNCONFIRMED_MESSAGES
-"""The *max_unconfirmed_messages* used by `.open_queue` by default."""
-
- DEFAULT_MAX_UNCONFIRMED_BYTES=DEFAULT_MAX_UNCONFIRMED_BYTES
-"""The *max_unconfirmed_bytes* used by `.open_queue` by default."""
-
- DEFAULT_CONSUMER_PRIORITY=DEFAULT_CONSUMER_PRIORITY
-"""The *consumer_priority* used by `.open_queue` by default."""
-
- DEFAULT_SUSPENDS_ON_BAD_HOST_HEALTH=DEFAULT_SUSPENDS_ON_BAD_HOST_HEALTH
-"""The *suspends_on_bad_host_health* used by `.open_queue` by default."""
-
- def__init__(
- self,
- max_unconfirmed_messages:Optional[int]=None,
- max_unconfirmed_bytes:Optional[int]=None,
- consumer_priority:Optional[int]=None,
- suspends_on_bad_host_health:Optional[bool]=None,
- )->None:
- self.max_unconfirmed_messages=max_unconfirmed_messages
- self.max_unconfirmed_bytes=max_unconfirmed_bytes
- self.consumer_priority=consumer_priority
- self.suspends_on_bad_host_health=suspends_on_bad_host_health
-
- def__eq__(self,other:object)->bool:
- ifnotisinstance(other,QueueOptions):
- returnFalse
- return(
- self.max_unconfirmed_messages==other.max_unconfirmed_messages
- andself.max_unconfirmed_bytes==other.max_unconfirmed_bytes
- andself.consumer_priority==other.consumer_priority
- andself.suspends_on_bad_host_health==other.suspends_on_bad_host_health
- )
-
- def__ne__(self,other:object)->bool:
- returnnotself==other
-
- def__repr__(self)->str:
- attrs=(
- "max_unconfirmed_messages",
- "max_unconfirmed_bytes",
- "consumer_priority",
- "suspends_on_bad_host_health",
- )
-
- params=[]
- forattrinattrs:
- value=getattr(self,attr)
- ifvalueisnotNone:
- params.append(f"{attr}={value!r}")
-
- returnf"QueueOptions({', '.join(params)})"
-
-
-
-
-[docs]
-classSessionOptions:
-"""A value semantic type representing session options.
-
- Each option can be set either by passing it as a keyword argument when
- constructing a *SessionOptions* instance, or by setting it as an attribute
- on a constructed instance.
-
- The default for every option is `None`. When constructing a `Session`,
- options set to `None` are given reasonable default values.
-
- Args:
- message_compression_algorithm:
- The type of compression to apply to messages being posted via the
- session this object is configuring.
- timeouts:
- The maximum number of seconds to wait for requests for each
- operation on this session. If not provided, reasonable defaults
- are used.
- host_health_monitor:
- A `.BasicHealthMonitor` is used by default, so your tests can
- control whether the session sees the machine as healthy or not by
- calling `.set_healthy` and `.set_unhealthy` on that instance. If
- you instead pass `None`, the session will always see the machine as
- healthy, `.HostUnhealthy` and `.HostHealthRestored` events with
- never be emitted, and the *suspends_on_bad_host_health* option of
- `QueueOptions` cannot be used.
- num_processing_threads:
- The number of threads for the SDK to use for processing events.
- This defaults to 1.
- blob_buffer_size:
- The size (in bytes) of the blob buffers to use. This defaults to
- 4k.
- channel_high_watermark:
- The size (in bytes) to use for the write cache high watermark on
- the channel. The default value is 128MB. Note that BlazingMQ
- reserves 4MB of this value for control messages, so the actual
- watermark for data published is ``channel_high_watermark - 4MB``.
- event_queue_watermarks:
- A tuple containing the low and high notification watermark
- thresholds for the buffer containing all incoming messages from the
- broker, respectively. A warning `.SlowConsumerHighWaterMark` is
- emitted when the buffer reaches the high watermark value, and a
- notification `.SlowConsumerNormal` is emitted when the buffer is
- back to the low watermark.
- stats_dump_interval:
- The interval (in seconds) at which to dump stats into the logs. If
- 0, disable the recurring dump of stats (final stats are always
- dumped at the end of the session). The default is 5min; the value
- must be a multiple of 30s, in the range ``[0s - 60min]``.
- """
-
- def__init__(
- self,
- message_compression_algorithm:Optional[CompressionAlgorithmType]=None,
- timeouts:Optional[Timeouts]=None,
- host_health_monitor:Union[BasicHealthMonitor,None]=(DefaultMonitor()),
- num_processing_threads:Optional[int]=None,
- blob_buffer_size:Optional[int]=None,
- channel_high_watermark:Optional[int]=None,
- event_queue_watermarks:Optional[tuple[int,int]]=None,
- stats_dump_interval:Optional[float]=None,
- )->None:
- self.message_compression_algorithm=message_compression_algorithm
- self.timeouts=timeouts
- self.host_health_monitor=host_health_monitor
- self.num_processing_threads=num_processing_threads
- self.blob_buffer_size=blob_buffer_size
- self.channel_high_watermark=channel_high_watermark
- self.event_queue_watermarks=event_queue_watermarks
- self.stats_dump_interval=stats_dump_interval
-
- def__eq__(self,other:object)->bool:
- ifnotisinstance(other,SessionOptions):
- returnFalse
- return(
- self.message_compression_algorithm==other.message_compression_algorithm
- andself.timeouts==other.timeouts
- andself.host_health_monitor==other.host_health_monitor
- andself.num_processing_threads==other.num_processing_threads
- andself.blob_buffer_size==other.blob_buffer_size
- andself.channel_high_watermark==other.channel_high_watermark
- andself.event_queue_watermarks==other.event_queue_watermarks
- andself.stats_dump_interval==other.stats_dump_interval
- )
-
- def__ne__(self,other:object)->bool:
- returnnotself==other
-
- def__repr__(self)->str:
- attrs=(
- "message_compression_algorithm",
- "timeouts",
- "host_health_monitor",
- "num_processing_threads",
- "blob_buffer_size",
- "channel_high_watermark",
- "event_queue_watermarks",
- "stats_dump_interval",
- )
-
- params=[]
- forattrinattrs:
- value=getattr(self,attr)
- ifvalueisnotNone:
- params.append(f"{attr}={value!r}")
-
- returnf"SessionOptions({', '.join(params)})"
-
-
-
-
-[docs]
-classSession:
-"""Represents a connection with the BlazingMQ broker.
-
- The session represents a connection to the broker.
- This object can be manipulated to modify the state of the application from
- the point of view of the broker, including opening queues, and starting or
- stopping the connection with the broker.
-
- Args:
- on_session_event: a required callback to process `.SessionEvent` events
- received by the session.
- on_message: an optional callback to process `Message` objects received
- by the session.
- broker: TCP address of the broker (default: 'tcp://localhost:30114').
- If the environment variable ``BMQ_BROKER_URI`` is set, its value
- will override whatever broker address is passed via this argument.
- message_compression_algorithm: the type of compression to apply to messages
- being posted via this session object.
- timeout: maximum number of seconds to wait for requests on this
- session. If not provided, reasonable defaults are used. This
- argument may either be a simple ``float``, which sets the same
- timeout for each operation, or an instance of the `Timeouts` class,
- which allows setting the timeout for each operation independently.
- host_health_monitor: A `.BasicHealthMonitor` is used by default, so
- your tests can control whether the session sees the machine as
- healthy or not by calling `.set_healthy` and `.set_unhealthy` on
- that instance. If you instead pass `None`, the session will always
- see the machine as healthy, `.HostUnhealthy` and
- `.HostHealthRestored` events will never be emitted, and the
- *suspends_on_bad_host_health* option of `QueueOptions` cannot be
- used.
- num_processing_threads: The number of threads for the SDK to use for
- processing events. This defaults to 1.
- blob_buffer_size: The size (in bytes) of the blob buffers to use. This
- defaults to 4k.
- channel_high_watermark: The size (in bytes) to use for the write cache
- high watermark on the channel. The default value is 128MB. Note
- that BlazingMQ reserves 4MB of this value for control messages, so
- the actual watermark for data published is
- ``channel_high_watermark - 4MB``.
- event_queue_watermarks: A tuple containing the low and high
- notification watermark thresholds for the buffer containing all
- incoming messages from the broker, respectively. A warning
- `.SlowConsumerHighWaterMark` is emitted when the buffer reaches the
- high watermark value, and a notification `.SlowConsumerNormal` is
- emitted when the buffer is back to the low watermark.
- stats_dump_interval: The interval (in seconds) at which to dump stats
- into the logs. If 0, disable the recurring dump of stats (final
- stats are always dumped at the end of the session). The default is
- 5min; the value must be a multiple of 30s, in the range
- ``[0s - 60min]``.
-
- Raises:
- `~blazingmq.Error`: If the session start request was not successful.
- `~blazingmq.exceptions.BrokerTimeoutError`: If the broker didn't respond
- to the request within a reasonable amount of time.
- `ValueError`: If any of the timeouts are provided and not > 0.0, or if
- the ``stats_dump_interval`` is provided and is < 0.0.
- """
-
- def__init__(
- self,
- on_session_event:Callable[[SessionEvent],None],
- on_message:Optional[Callable[[Message,MessageHandle],None]]=None,
- broker:str="tcp://localhost:30114",
- message_compression_algorithm:CompressionAlgorithmType=(
- CompressionAlgorithmType.NONE
- ),
- timeout:Union[Timeouts,float]=DEFAULT_TIMEOUT,
- host_health_monitor:Union[BasicHealthMonitor,None]=(DefaultMonitor()),
- num_processing_threads:Optional[int]=None,
- blob_buffer_size:Optional[int]=None,
- channel_high_watermark:Optional[int]=None,
- event_queue_watermarks:Optional[tuple[int,int]]=None,
- stats_dump_interval:Optional[float]=None,
- )->None:
- ifhost_health_monitorisnotNone:
- ifnotisinstance(host_health_monitor,BasicHealthMonitor):
- raiseTypeError(
- f"host_health_monitor must be None or an instance of "
- f"{' or '.join(KNOWN_MONITORS)}"
- )
-
- monitor_host_health=host_health_monitorisnotNone
- fake_host_health_monitor=getattr(host_health_monitor,"_monitor",None)
-
- self._has_no_on_message=on_messageisNone
-
- # Using our Timeouts class, preserve the old behavior of passing in a
- # simple float as a timeout. Avoid setting the `connect_timeout` and
- # `disconnect_timeout`.
- ifnotisinstance(timeout,Timeouts):
- timeout=Timeouts(
- open_queue_timeout=timeout,
- configure_queue_timeout=timeout,
- close_queue_timeout=timeout,
- )
-
- self._ext=ExtSession(
- on_session_event,
- on_message=on_message,
- broker=six.ensure_binary(broker),
- message_compression_algorithm=message_compression_algorithm,
- num_processing_threads=num_processing_threads,
- blob_buffer_size=blob_buffer_size,
- channel_high_watermark=channel_high_watermark,
- event_queue_watermarks=event_queue_watermarks,
- stats_dump_interval=_convert_stats_dump_interval(stats_dump_interval),
- timeouts=_validate_timeouts(timeout),
- monitor_host_health=monitor_host_health,
- fake_host_health_monitor=fake_host_health_monitor,
- )
-
-
-[docs]
- @classmethod
- defwith_options(
- cls,
- on_session_event:Callable[[SessionEvent],None],
- on_message:Optional[Callable[[Message,MessageHandle],None]]=None,
- broker:str="tcp://localhost:30114",
- session_options:SessionOptions=(SessionOptions()),
- )->Session:
-"""Construct a *Session* instance using `.SessionOptions`.
-
- This is the recommended way to construct a new session, as the
- `.SessionOptions` class provides an easier to use interface for
- configuring only those options you need.
-
- Args:
- on_session_event: a required callback to process `.SessionEvent` events
- received by the session.
- on_message: an optional callback to process `Message` objects received
- by the session.
- broker: TCP address of the broker (default: 'tcp://localhost:30114').
- If the environment variable ``BMQ_BROKER_URI`` is set, its value
- will override whatever broker address is passed via this argument.
- session_options: an instance of `.SessionOptions` that represents the
- session's configuration.
-
- Raises:
- `~blazingmq.Error`: If the session start request was not successful.
- `~blazingmq.exceptions.BrokerTimeoutError`: If the broker didn't respond
- to the request within a reasonable amount of time.
- `ValueError`: If any of the timeouts are provided and not > 0.0, or if
- the ``stats_dump_interval`` is provided and is < 0.0.
- """
- message_compression_algorithm=session_options.message_compression_algorithm
- ifmessage_compression_algorithmisNone:
- message_compression_algorithm=CompressionAlgorithmType.NONE
-
- ifsession_options.timeoutsisNone:
- returncls(
- on_session_event,
- on_message,
- broker,
- message_compression_algorithm,
- DEFAULT_TIMEOUT,
- session_options.host_health_monitor,
- session_options.num_processing_threads,
- session_options.blob_buffer_size,
- session_options.channel_high_watermark,
- session_options.event_queue_watermarks,
- session_options.stats_dump_interval,
- )
- else:
- returncls(
- on_session_event,
- on_message,
- broker,
- message_compression_algorithm,
- session_options.timeouts,
- session_options.host_health_monitor,
- session_options.num_processing_threads,
- session_options.blob_buffer_size,
- session_options.channel_high_watermark,
- session_options.event_queue_watermarks,
- session_options.stats_dump_interval,
- )
-
-
-
-[docs]
- defopen_queue(
- self,
- queue_uri:str,
- read:bool=False,
- write:bool=False,
- options:QueueOptions=QueueOptions(),
- timeout:float=DEFAULT_TIMEOUT,
- )->None:
-"""Open a queue with the specified parameters
-
- Open a queue at the specified *queue_uri*. The *queue_uri* is the
- identifier for any future interactions with this opened queue.
-
- Note:
- Invoking this method from the ``on_message`` or
- ``on_session_event`` of the `Session` or the ``on_ack`` callback of
- a posted message will cause a deadlock.
-
- Note:
- It's possible to override the default tier by adding an optional
- tier to the queue URI. See `URI format`__.
-
- __ https://bloomberg.github.io/blazingmq/docs/apidocs/cpp_apidocs/group__bmqt__uri.html
-
- Args:
- queue_uri: unique resource identifier for the queue to be opened.
- read: open the queue for reading, enabling the `Session` to receive
- `Message` objects for this queue.
- write: open the queue for writing, allowing posting to this queue.
- options (~blazingmq.QueueOptions): options to configure the queue
- with
- timeout: maximum number of seconds to wait for this request.
- If not provided, the *timeout* provided to the `Session` when
- it was created it used. If that was not provided either,
- a reasonable default is used.
-
- Raises:
- `~blazingmq.Error`: If the open queue request was not successful.
- `~blazingmq.exceptions.BrokerTimeoutError`: If the broker didn't
- respond to the request within a reasonable amount of time.
- `ValueError`: If *timeout* is not > 0.0.
- """
- ifreadandself._has_no_on_message:
- raiseError(
- "Can't open queue {} in read mode: no on_message "
- "callback was provided at Session construction".format(queue_uri)
- )
-
- ifoptions.suspends_on_bad_host_healthandnotself._ext.monitor_host_health:
- raiseError(
- "Queues cannot use suspends_on_bad_host_health if host health"
- " monitoring was disabled when the Session was created"
- )
-
- self._ext.open_queue_sync(
- six.ensure_binary(queue_uri),
- read=read,
- write=write,
- consumer_priority=options.consumer_priority,
- max_unconfirmed_messages=options.max_unconfirmed_messages,
- max_unconfirmed_bytes=options.max_unconfirmed_bytes,
- suspends_on_bad_host_health=options.suspends_on_bad_host_health,
- timeout=_convert_timeout(timeout),
- )
-
-
-
-[docs]
- defclose_queue(self,queue_uri:str,timeout:float=DEFAULT_TIMEOUT)->None:
-"""Close an opened queue at the specified *queue_uri*.
-
- Close the queue at the specified *queue_uri*. After this method
- successfully returns, the *queue_uri* will no longer correspond to valid
- queue to do any operations.
-
- Note:
- Invoking this method from the ``on_message`` or
- ``on_session_event`` of the `Session` or the ``on_ack`` callback of
- a posted message will cause a deadlock.
-
- Args:
- queue_uri: unique resource identifier for the queue to be closed.
- timeout: maximum number of seconds to wait for this request.
- If not provided, the *timeout* provided to the `Session` when
- it was created it used. If that was not provided either,
- a reasonable default is used.
-
- Raises:
- `~blazingmq.Error`: If the close queue request was not successful.
- `~blazingmq.exceptions.BrokerTimeoutError`: If the broker didn't
- respond to the request within a reasonable amount of time.
- `ValueError`: If *timeout* is not > 0.0.
- """
- self._ext.close_queue_sync(
- six.ensure_binary(queue_uri),
- timeout=_convert_timeout(timeout),
- )
-
-
-
-[docs]
- defconfigure_queue(
- self,
- queue_uri:str,
- options:QueueOptions,
- timeout:float=DEFAULT_TIMEOUT,
- )->None:
-"""Modify the options on an opened queue at the specified *queue_uri*.
-
- Modify the options of the queue at the specified *queue_uri*. After this
- method successfully returns, the *queue_uri* will be configured with the
- specified *options*.
-
- Note:
- Invoking this method from the ``on_message`` or ``on_session_event`` of
- the `Session` or the ``on_ack`` callback of a posted message will
- cause a deadlock.
-
- Args:
- queue_uri: unique resource identifier for the queue to be configured.
- options (~blazingmq.QueueOptions): options to configure the queue with
- timeout: maximum number of seconds to wait for this request.
- If not provided, the *timeout* provided to the `Session` when
- it was created it used. If that was not provided either,
- a reasonable default is used.
-
- Raises:
- `~blazingmq.Error`: If the configure queue request was not successful.
- `~blazingmq.exceptions.BrokerTimeoutError`: If the broker didn't
- respond to the request within a reasonable amount of time.
- `ValueError`: If *timeout* is not > 0.0.
- """
- ifoptions.suspends_on_bad_host_healthandnotself._ext.monitor_host_health:
- raiseError(
- "Queues cannot use suspends_on_bad_host_health if host health"
- " monitoring was disabled when the Session was created"
- )
-
- self._ext.configure_queue_sync(
- six.ensure_binary(queue_uri),
- consumer_priority=options.consumer_priority,
- max_unconfirmed_messages=options.max_unconfirmed_messages,
- max_unconfirmed_bytes=options.max_unconfirmed_bytes,
- suspends_on_bad_host_health=options.suspends_on_bad_host_health,
- timeout=_convert_timeout(timeout),
- )
-
-
-
-[docs]
- defget_queue_options(self,queue_uri:str)->QueueOptions:
-"""Get configured options of an opened queue.
-
- Get the previously set options of an opened queue at the specified
- *queue_uri*.
-
- Args:
- queue_uri: unique resource identifier for the queue to be configured.
-
- Returns:
- `~blazingmq.QueueOptions`: The queue's configured options.
-
- Raises:
- `~blazingmq.Error`: If the queue with the given URI is not open, or
- its options cannot be retrieved.
-
- Note:
- Options that only affect message consumption, including
- *consumer_priority*, *max_unconfirmed_messages*, and
- *max_unconfirmed_bytes*, are ignored when opening or configuring
- a write-only queue, so any attempt to set those options on
- a write-only queue won't be reflected in the `QueueOptions`
- returned by a later call to *get_queue_options*.
- """
- options=self._ext.get_queue_options(six.ensure_binary(queue_uri))
- returnQueueOptions(*options)
-
-
-
-[docs]
- defstop(self)->None:
-"""Teardown the broker connection
-
- Stop the session with the connected BlazingMQ broker which implies
- tearing down the connection. This session cannot be used to execute any
- actions after this method returns.
-
- Note:
- Invoking this method from the ``on_message`` or
- ``on_session_event`` of the `Session` or the ``on_ack`` callback of
- a posted message will cause a deadlock.
- """
-
- self._ext.stop()
-
-
-
-[docs]
- defpost(
- self,
- queue_uri:str,
- message:bytes,
- properties:Optional[PropertyValueDict]=None,
- property_type_overrides:Optional[PropertyTypeDict]=None,
- on_ack:Optional[Callable[[Ack],None]]=None,
- )->None:
-"""Post a message to an opened queue specified by *queue_uri*.
-
- Post the payload and optional properties and overrides to the opened
- queue specified by *queue_uri*. Optionally take an *on_ack* callback
- that is invoked with the incoming acknowledgment for the message posted.
-
- Args:
- queue_uri: unique resource identifier for the queue to posted to.
- message: the payload of the message.
- properties (Optional[`~blazingmq.PropertyValueDict`]): optionally
- provided properties to be associated with the message.
- property_type_overrides (Optional[`~blazingmq.PropertyTypeDict`]):
- optionally provided type overrides for the properties.
- on_ack (Optional[Callable[[~blazingmq.Ack], None]]): optionally
- specified callback which is invoked with the acknowledgment
- status of the message being posted.
-
- Raises:
- `~blazingmq.Error`: If the post request was not successful.
- """
- props:Optional[Dict[bytes,Tuple[Union[int,bytes],int]]]=None
- ifpropertiesorproperty_type_overrides:
- props=_collect_properties_and_types(properties,property_type_overrides)
-
- self._ext.post(
- six.ensure_binary(queue_uri),
- message,
- properties=props,
- on_ack=on_ack,
- )
-
-
-
-[docs]
- defconfirm(self,message:Message)->None:
-"""Confirm the specified message from this queue.
-
- Mark the specified *message*, as confirmed. If successful, this will
- indicate to the BlazingMQ framework that the processing for this
- message has been completed and that the message must not be
- re-delivered, if this queue is opened again by any consumer.
-
- It's often more convenient to use `MessageHandle.confirm`
- instead. An instance of `MessageHandle` is received with every
- new `Message` delivered via the ``on_message`` callback.
-
- Args:
- message (~blazingmq.Message): message to be confirmed.
-
- Raises:
- `~blazingmq.Error`: If the confirm message request was not
- successful.
- """
- self._ext.confirm(message)
-# Copyright 2019-2023 Bloomberg Finance L.P.
-# SPDX-License-Identifier: Apache-2.0
-#
-# Licensed under the Apache License, Version 2.0 (the "License");
-# you may not use this file except in compliance with the License.
-# You may obtain a copy of the License at
-#
-# http://www.apache.org/licenses/LICENSE-2.0
-#
-# Unless required by applicable law or agreed to in writing, software
-# distributed under the License is distributed on an "AS IS" BASIS,
-# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-# See the License for the specific language governing permissions and
-# limitations under the License.
-
-from__future__importannotations
-
-fromtypingimportOptional
-
-
-
-[docs]
-classTimeouts:
-"""A value semantic type representing session timeouts.
-
- Each option can be set either by passing it as a keyword argument when
- constructing a *Timeouts* instance, or by setting it as an attribute on
- a constructed instance.
-
- The default for every option is `None`. When constructing a `Session`,
- either directly or using `SessionOptions`, options set to `None` are given
- reasonable default values.
-
- Args:
- connect_timeout:
- The maximum number of seconds to wait for connection requests on
- this session.
- disconnect_timeout:
- The maximum number of seconds to wait for disconnection requests
- on this session.
- open_queue_timeout:
- The maximum number of seconds to wait for open queue requests on
- this session.
- configure_queue_timeout:
- The maximum number of seconds to wait for configure queue requests
- on this session.
- close_queue_timeout:
- The maximum number of seconds to wait for close queue requests on
- this session.
- """
-
- def__init__(
- self,
- connect_timeout:Optional[float]=None,
- disconnect_timeout:Optional[float]=None,
- open_queue_timeout:Optional[float]=None,
- configure_queue_timeout:Optional[float]=None,
- close_queue_timeout:Optional[float]=None,
- )->None:
- self.connect_timeout=connect_timeout
- self.disconnect_timeout=disconnect_timeout
- self.open_queue_timeout=open_queue_timeout
- self.configure_queue_timeout=configure_queue_timeout
- self.close_queue_timeout=close_queue_timeout
-
- def__eq__(self,other:object)->bool:
- ifnotisinstance(other,Timeouts):
- returnFalse
- return(
- self.connect_timeout==other.connect_timeout
- andself.disconnect_timeout==other.disconnect_timeout
- andself.open_queue_timeout==other.open_queue_timeout
- andself.configure_queue_timeout==other.configure_queue_timeout
- andself.close_queue_timeout==other.close_queue_timeout
- )
-
- def__ne__(self,other:object)->bool:
- returnnotself==other
-
- def__repr__(self)->str:
- attrs=(
- "connect_timeout",
- "disconnect_timeout",
- "open_queue_timeout",
- "configure_queue_timeout",
- "close_queue_timeout",
- )
-
- params=[]
- forattrinattrs:
- value=getattr(self,attr)
- ifvalueisnotNone:
- params.append(f"{attr}={value!r}")
-
- returnf"Timeouts({', '.join(params)})"
-# Copyright 2019-2023 Bloomberg Finance L.P.
-# SPDX-License-Identifier: Apache-2.0
-#
-# Licensed under the Apache License, Version 2.0 (the "License");
-# you may not use this file except in compliance with the License.
-# You may obtain a copy of the License at
-#
-# http://www.apache.org/licenses/LICENSE-2.0
-#
-# Unless required by applicable law or agreed to in writing, software
-# distributed under the License is distributed on an "AS IS" BASIS,
-# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-# See the License for the specific language governing permissions and
-# limitations under the License.
-
-
-
-# Copyright 2019-2023 Bloomberg Finance L.P.
-# SPDX-License-Identifier: Apache-2.0
-#
-# Licensed under the Apache License, Version 2.0 (the "License");
-# you may not use this file except in compliance with the License.
-# You may obtain a copy of the License at
-#
-# http://www.apache.org/licenses/LICENSE-2.0
-#
-# Unless required by applicable law or agreed to in writing, software
-# distributed under the License is distributed on an "AS IS" BASIS,
-# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-# See the License for the specific language governing permissions and
-# limitations under the License.
-
-from__future__importannotations
-
-importlogging
-fromtypingimportOptional
-
-LOGGER=logging.getLogger(__name__)
-
-
-
-[docs]
-classQueueEvent(SessionEvent):
-"""Base type for session events relating to a single queue.
-
- Attributes:
- queue_uri (str): Queue URI this event is associated with.
- """
-
- def__init__(self,queue_uri:str,message:Optional[str]=None)->None:
- self.queue_uri=queue_uri
- super().__init__(message)
-
- def__repr__(self)->str:
- ifself._message:
- return"<{}: {}{}>".format(
- self.__class__.__name__,self.queue_uri,self._message
- )
- else:
- returnf"<{self.__class__.__name__}: {self.queue_uri}>"
-
- def__eq__(self,other:object)->bool:
- iftype(self)isnottype(other):
- returnNotImplemented
-
- assertisinstance(other,QueueEvent)# for mypy's sake
- return(
- self.__class__isother.__class__
- andself._message==other._message
- andself.queue_uri==other.queue_uri
- )
-
-
-
-
-[docs]
-classConnected(SessionEvent):
-"""Notification of successful connection with the broker"""
-
-
-
-
-[docs]
-classDisconnected(SessionEvent):
-"""Notification of successful disconnection with the broker"""
-
-
-
-
-[docs]
-classConnectionLost(SessionEvent):
-"""Notification of a lost connection with the broker"""
-
-
-
-
-[docs]
-classReconnected(SessionEvent):
-"""Notification of a re-connection with the broker in case connection was lost earlier"""
-
-
-
-
-[docs]
-classStateRestored(SessionEvent):
-"""Notification of successfully restoring state of application as it was before lost
- connection or disconnection"""
-
-
-
-
-[docs]
-classConnectionTimeout(SessionEvent):
-"""Notification that a requested connection could not be initiated in within the
- timeout period"""
-
-
-
-
-[docs]
-classHostUnhealthy(SessionEvent):
-"""Notification that the host has been marked unhealthy.
-
- This is emitted only if ``host_health_monitor=None`` was not provided when
- the `.Session` was created. This will be emitted whenever the machine
- becomes unhealthy. It is also emitted if the machine is initially unhealthy
- when the `.Session` is created.
-
- .. versionadded:: 0.7.0
- """
-
-
-
-
-[docs]
-classHostHealthRestored(SessionEvent):
-"""Notification that the host is no longer marked unhealthy.
-
- This is emitted only if ``host_health_monitor=None`` was not provided when
- the `.Session` was created. It will be emitted once the machine is becomes
- healthy after an earlier `.HostUnhealthy` event. Before this event
- is emitted, you will receive a `QueueResumed` or `QueueResumeFailed` for
- each queue that was suspended due to ``suspends_on_bad_host_health=True``.
-
- .. versionadded:: 0.7.0
- """
-
-
-
-
-[docs]
-classQueueSuspended(QueueEvent):
-"""A queue that is sensitive to host health has been suspended.
-
- After a `.HostUnhealthy` event is emitted, any queue that was opened with
- ``suspend_on_bad_host_health=True`` will suspend operation. This event will
- be emitted once for each suspended queue.
-
- Note:
- If ``host_health_monitor=None`` was provided when the `.Session` was
- created, this event will never be emitted because the host will never
- be considered unhealthy.
-
- Attributes:
- queue_uri (str): URI of the queue that has been successfully suspended.
-
- .. versionadded:: 0.7.0
- """
-
-
-
-
-[docs]
-classQueueSuspendFailed(QueueEvent):
-"""A queue that is sensitive to host health could not be suspended.
-
- Whenever a `QueueSuspended` event would be expected, this event may be
- emitted instead if the SDK is unable to suspend the queue as expected.
-
- Note:
- The BlazingMQ SDK considers the failure to suspend a queue as evidence
- of an unusually serious problem with the connection to the broker, so
- if this event occurs the SDK follows it up by dropping the connection
- to the broker and trying to re-establish it.
-
- Attributes:
- queue_uri (str): URI of the queue that could not be suspended.
-
- .. versionadded:: 0.7.0
- """
-
-
-
-
-[docs]
-classQueueResumed(QueueEvent):
-"""A queue that is sensitive to host health has been resumed.
-
- Once an unhealthy machine becomes healthy again, the SDK will automatically
- attempt to resume each queue that was suspended when the machine became
- unhealthy. This event will be emitted once for each queue that had been
- suspended, only after which will `HostHealthRestored` be emitted.
-
- Attributes:
- queue_uri (str): URI of the queue that has been successfully resumed.
-
- .. versionadded:: 0.7.0
- """
-
-
-
-
-[docs]
-classQueueResumeFailed(QueueEvent):
-"""A queue that is sensitive to host health could not be resumed.
-
- Whenever a `QueueResumed` event would be expected, this event may be
- emitted instead if the SDK is unable to resume the queue as expected.
-
- Note:
- Unlike if suspending a queue fails, the SDK will not automatically drop
- the connection to the broker if resuming a queue fails.
-
- Attributes:
- queue_uri (str): URI of the queue that could not be resumed.
-
- .. versionadded:: 0.7.0
- """
-
-
-
-
-[docs]
-classQueueReopened(QueueEvent):
-"""A queue has been successfully reopened after a connection loss.
-
- If the connection with the broker is lost, `ConnectionLost` is emitted.
- Once it is reestablished, `Reconnected` is emitted, followed by either
- a `QueueReopened` or `QueueReopenFailed` for each queue that was
- previously open, and finally `StateRestored` is emitted.
-
- Attributes:
- queue_uri (str): URI of the queue that has been successfully reopened.
- """
-
-
-
-
-[docs]
-classQueueReopenFailed(QueueEvent):
-"""A queue couldn't be reopened after a connection loss.
-
- Attributes:
- queue_uri (str): URI of the queue that could not be reopened.
- """
-
-
-
-
-[docs]
-classSlowConsumerNormal(SessionEvent):
-"""Notification that the consumer has resumed acceptable rate of consumption"""
-
-
-
-
-[docs]
-classSlowConsumerHighWaterMark(SessionEvent):
-"""Notification that the consumer is consuming at the lowest rate acceptable"""
-
-
-
-
-[docs]
-classError(SessionEvent):
-"""Notification of a miscellaneous error"""
-
-
-
-
-[docs]
-classInterfaceError(SessionEvent):
-"""The BlazingMQ SDK behaved in an unexpected way."""
-
-
-
-
-[docs]
-deflog_session_event(event:SessionEvent)->None:
-"""Log incoming session event as appropriate
-
- A callback that can be used as a default for the *on_session_event*
- parameter on the `.Session` object. All `.Connected`, `.Disconnected`,
- `.StateRestored`, `.SlowConsumerNormal`, and `.QueueReopened` events are
- logged at INFO level, and any `.ConnectionLost`, `.SlowConsumerHighWaterMark`,
- and `.Reconnected` events are logged at WARN level, as they may indicate issues
- with the application. Any other events are most likely an error in the
- application and are logged at ERROR level.
-
- Args:
- event (~blazingmq.session_events.SessionEvent): incoming `SessionEvent`
- object.
- """
- ifisinstance(
- event,
- (
- Connected,
- Disconnected,
- StateRestored,
- SlowConsumerNormal,
- QueueReopened,
- HostUnhealthy,
- HostHealthRestored,
- QueueSuspended,
- QueueResumed,
- ),
- ):
- level=logging.INFO
- elifisinstance(event,(ConnectionLost,Reconnected,SlowConsumerHighWaterMark)):
- level=logging.WARN
- else:
- # ConnectionTimeout, Error, InterfaceError, QueueReopenFailed,
- # QueueSuspendFailed, QueueResumeFailed
- level=logging.ERROR
-
- LOGGER.log(level,"Received session event: %s",event)
A producer can ensure that a message has been successfully posted by requesting an
-acknowledgment for the message being posted. This can be requested by passing a
-callable to the on_ack parameter on post. This callback will always get invoked
-with an Ack message.
-
A useful pattern for the producer is using the on_ack callback to add the
-incoming ack to a queue and then waiting to recieve it. This allows you to
-synchronously Session.post to a BlazingMQ queue like:
If you want to post without blocking on acknowledgments, you can leverage
-functools.partial to bind parameters to the on_ack callable. This can be
-useful if you need to do provide a recovery mechanism for messages that failed to
-post.
Represents a connection with the BlazingMQ broker.
-
The session represents a connection to the broker.
-This object can be manipulated to modify the state of the application from
-the point of view of the broker, including opening queues, and starting or
-stopping the connection with the broker.
-
-
Parameters:
-
-
on_session_event (Callable[[SessionEvent], None]) – a required callback to process SessionEvent events
-received by the session.
-
on_message (Optional[Callable[[Message, MessageHandle], None]]) – an optional callback to process Message objects received
-by the session.
-
broker (str) – TCP address of the broker (default: ‘tcp://localhost:30114’).
-If the environment variable BMQ_BROKER_URI is set, its value
-will override whatever broker address is passed via this argument.
-
message_compression_algorithm (CompressionAlgorithmType) – the type of compression to apply to messages
-being posted via this session object.
-
timeout (Union[Timeouts, float]) – maximum number of seconds to wait for requests on this
-session. If not provided, reasonable defaults are used. This
-argument may either be a simple float, which sets the same
-timeout for each operation, or an instance of the Timeouts class,
-which allows setting the timeout for each operation independently.
-
host_health_monitor (Union[BasicHealthMonitor, None]) – A BasicHealthMonitor is used by default, so
-your tests can control whether the session sees the machine as
-healthy or not by calling set_healthy and set_unhealthy on
-that instance. If you instead pass None, the session will always
-see the machine as healthy, HostUnhealthy and
-HostHealthRestored events will never be emitted, and the
-suspends_on_bad_host_health option of QueueOptions cannot be
-used.
-
num_processing_threads (Optional[int]) – The number of threads for the SDK to use for
-processing events. This defaults to 1.
-
blob_buffer_size (Optional[int]) – The size (in bytes) of the blob buffers to use. This
-defaults to 4k.
-
channel_high_watermark (Optional[int]) – The size (in bytes) to use for the write cache
-high watermark on the channel. The default value is 128MB. Note
-that BlazingMQ reserves 4MB of this value for control messages, so
-the actual watermark for data published is
-channel_high_watermark-4MB.
-
event_queue_watermarks (Optional[tuple[int, int]]) – A tuple containing the low and high
-notification watermark thresholds for the buffer containing all
-incoming messages from the broker, respectively. A warning
-SlowConsumerHighWaterMark is emitted when the buffer reaches the
-high watermark value, and a notification SlowConsumerNormal is
-emitted when the buffer is back to the low watermark.
-
stats_dump_interval (Optional[float]) – The interval (in seconds) at which to dump stats
-into the logs. If 0, disable the recurring dump of stats (final
-stats are always dumped at the end of the session). The default is
-5min; the value must be a multiple of 30s, in the range
-[0s-60min].
-
-
-
Raises:
-
-
Error – If the session start request was not successful.
-
BrokerTimeoutError – If the broker didn’t respond
- to the request within a reasonable amount of time.
-
ValueError – If any of the timeouts are provided and not > 0.0, or if
- the stats_dump_interval is provided and is < 0.0.
Close the queue at the specified queue_uri. After this method
-successfully returns, the queue_uri will no longer correspond to valid
-queue to do any operations.
-
-
Note
-
Invoking this method from the on_message or
-on_session_event of the Session or the on_ack callback of
-a posted message will cause a deadlock.
-
-
-
Parameters:
-
-
queue_uri (str) – unique resource identifier for the queue to be closed.
-
timeout (float) – maximum number of seconds to wait for this request.
-If not provided, the timeout provided to the Session when
-it was created it used. If that was not provided either,
-a reasonable default is used.
-
-
-
Raises:
-
-
Error – If the close queue request was not successful.
-
BrokerTimeoutError – If the broker didn’t
- respond to the request within a reasonable amount of time.
Modify the options on an opened queue at the specified queue_uri.
-
Modify the options of the queue at the specified queue_uri. After this
-method successfully returns, the queue_uri will be configured with the
-specified options.
-
-
Note
-
Invoking this method from the on_message or on_session_event of
-the Session or the on_ack callback of a posted message will
-cause a deadlock.
-
-
-
Parameters:
-
-
queue_uri (str) – unique resource identifier for the queue to be configured.
-
options (QueueOptions) – options to configure the queue with
-
timeout (float) – maximum number of seconds to wait for this request.
-If not provided, the timeout provided to the Session when
-it was created it used. If that was not provided either,
-a reasonable default is used.
-
-
-
Raises:
-
-
Error – If the configure queue request was not successful.
-
BrokerTimeoutError – If the broker didn’t
- respond to the request within a reasonable amount of time.
Mark the specified message, as confirmed. If successful, this will
-indicate to the BlazingMQ framework that the processing for this
-message has been completed and that the message must not be
-re-delivered, if this queue is opened again by any consumer.
-
It’s often more convenient to use MessageHandle.confirm
-instead. An instance of MessageHandle is received with every
-new Message delivered via the on_message callback.
Error – If the queue with the given URI is not open, or
- its options cannot be retrieved.
-
-
-
-
Note
-
Options that only affect message consumption, including
-consumer_priority, max_unconfirmed_messages, and
-max_unconfirmed_bytes, are ignored when opening or configuring
-a write-only queue, so any attempt to set those options on
-a write-only queue won’t be reflected in the QueueOptions
-returned by a later call to get_queue_options.
Open a queue at the specified queue_uri. The queue_uri is the
-identifier for any future interactions with this opened queue.
-
-
Note
-
Invoking this method from the on_message or
-on_session_event of the Session or the on_ack callback of
-a posted message will cause a deadlock.
-
-
-
Note
-
It’s possible to override the default tier by adding an optional
-tier to the queue URI. See URI format.
-
-
-
Parameters:
-
-
queue_uri (str) – unique resource identifier for the queue to be opened.
-
read (bool) – open the queue for reading, enabling the Session to receive
-Message objects for this queue.
-
write (bool) – open the queue for writing, allowing posting to this queue.
-
options (QueueOptions) – options to configure the queue
-with
-
timeout (float) – maximum number of seconds to wait for this request.
-If not provided, the timeout provided to the Session when
-it was created it used. If that was not provided either,
-a reasonable default is used.
-
-
-
Raises:
-
-
Error – If the open queue request was not successful.
-
BrokerTimeoutError – If the broker didn’t
- respond to the request within a reasonable amount of time.
Post a message to an opened queue specified by queue_uri.
-
Post the payload and optional properties and overrides to the opened
-queue specified by queue_uri. Optionally take an on_ack callback
-that is invoked with the incoming acknowledgment for the message posted.
-
-
Parameters:
-
-
queue_uri (str) – unique resource identifier for the queue to posted to.
properties (Optional[PropertyValueDict]) – optionally
-provided properties to be associated with the message.
-
property_type_overrides (Optional[PropertyTypeDict]) – optionally provided type overrides for the properties.
-
on_ack (Optional[Callable[[Ack], None]]) – optionally
-specified callback which is invoked with the acknowledgment
-status of the message being posted.
Stop the session with the connected BlazingMQ broker which implies
-tearing down the connection. This session cannot be used to execute any
-actions after this method returns.
-
-
Note
-
Invoking this method from the on_message or
-on_session_event of the Session or the on_ack callback of
-a posted message will cause a deadlock.
This is the recommended way to construct a new session, as the
-SessionOptions class provides an easier to use interface for
-configuring only those options you need.
-
-
Parameters:
-
-
on_session_event (Callable[[SessionEvent], None]) – a required callback to process SessionEvent events
-received by the session.
broker (str) – TCP address of the broker (default: ‘tcp://localhost:30114’).
-If the environment variable BMQ_BROKER_URI is set, its value
-will override whatever broker address is passed via this argument.
A value semantic type representing session timeouts.
-
Each option can be set either by passing it as a keyword argument when
-constructing a Timeouts instance, or by setting it as an attribute on
-a constructed instance.
-
The default for every option is None. When constructing a Session,
-either directly or using SessionOptions, options set to None are given
-reasonable default values.
-
-
Parameters:
-
-
connect_timeout (Optional[float]) – The maximum number of seconds to wait for connection requests on
-this session.
-
disconnect_timeout (Optional[float]) – The maximum number of seconds to wait for disconnection requests
-on this session.
-
open_queue_timeout (Optional[float]) – The maximum number of seconds to wait for open queue requests on
-this session.
-
configure_queue_timeout (Optional[float]) – The maximum number of seconds to wait for configure queue requests
-on this session.
-
close_queue_timeout (Optional[float]) – The maximum number of seconds to wait for close queue requests on
-this session.
A value semantic type representing session options.
-
Each option can be set either by passing it as a keyword argument when
-constructing a SessionOptions instance, or by setting it as an attribute
-on a constructed instance.
-
The default for every option is None. When constructing a Session,
-options set to None are given reasonable default values.
-
-
Parameters:
-
-
message_compression_algorithm (Optional[CompressionAlgorithmType]) – The type of compression to apply to messages being posted via the
-session this object is configuring.
-
timeouts (Optional[Timeouts]) – The maximum number of seconds to wait for requests for each
-operation on this session. If not provided, reasonable defaults
-are used.
-
host_health_monitor (Union[BasicHealthMonitor, None]) – A BasicHealthMonitor is used by default, so your tests can
-control whether the session sees the machine as healthy or not by
-calling set_healthy and set_unhealthy on that instance. If
-you instead pass None, the session will always see the machine as
-healthy, HostUnhealthy and HostHealthRestored events with
-never be emitted, and the suspends_on_bad_host_health option of
-QueueOptions cannot be used.
-
num_processing_threads (Optional[int]) – The number of threads for the SDK to use for processing events.
-This defaults to 1.
-
blob_buffer_size (Optional[int]) – The size (in bytes) of the blob buffers to use. This defaults to
-4k.
-
channel_high_watermark (Optional[int]) – The size (in bytes) to use for the write cache high watermark on
-the channel. The default value is 128MB. Note that BlazingMQ
-reserves 4MB of this value for control messages, so the actual
-watermark for data published is channel_high_watermark-4MB.
-
event_queue_watermarks (Optional[tuple[int, int]]) – A tuple containing the low and high notification watermark
-thresholds for the buffer containing all incoming messages from the
-broker, respectively. A warning SlowConsumerHighWaterMark is
-emitted when the buffer reaches the high watermark value, and a
-notification SlowConsumerNormal is emitted when the buffer is
-back to the low watermark.
-
stats_dump_interval (Optional[float]) – The interval (in seconds) at which to dump stats into the logs. If
-0, disable the recurring dump of stats (final stats are always
-dumped at the end of the session). The default is 5min; the value
-must be a multiple of 30s, in the range [0s-60min].
A value semantic type representing the settings for a queue.
-
Each option can be set either by passing it as a keyword argument when
-constructing a QueueOptions instance, or by setting it as an attribute on
-a constructed instance.
-
The default for every option is None. When calling configure_queue,
-options set to None are not changed from their current setting. When
-calling open_queue, options set to None are given default values.
-These default values are accessible as class attributes on the
-QueueOptions class.
-
-
Parameters:
-
-
max_unconfirmed_messages (Optional[int]) – The maximum number of messages that can be delivered to the queue
-without confirmation. This limit can be reached if the queue
-receives messages faster than it confirms received messages. Once
-this limit is reached, at least one message must be confirmed
-before the queue will receive any more messages.
-
max_unconfirmed_bytes (Optional[int]) – The maximum number of bytes that can be delivered to the queue
-without confirmation. Like max_unconfirmed_messages, this limit
-can be reached if incoming messages are queued up waiting for
-already delivered messages to be confirmed.
-
consumer_priority (Optional[int]) – The precedence of this consumer compared to other consumers of the
-same queue. The consumer with the highest priority receives the
-messages. If multiple consumers share the highest priority,
-messages are delivered to them in a round-robin fashion.
-
suspends_on_bad_host_health (Optional[bool]) – Whether or not this queue should suspend operation while the host
-machine is unhealthy. While operation is suspended, a queue opened
-with read=True will not receive messages and a queue opened
-with write=True will raise if you try to post a message.
-By default, queues are not sensitive to the host’s health.
A class representing a message received from BlazingMQ.
-
A Message represents a message delivered by BlazingMQ from a producer
-to this queue. This message can only be received if the queue is
-opened with ‘read=True’ mode enabled.
A dictionary of BlazingMQ message properties.
-The dictionary keys must be str representing the property
-names and the values must be of type str, bytes,
-bool or int.
A mapping of property names to
-PropertyType types. The dictionary is guaranteed to provide
-a value for each key already present in Message.properties
An Ack is a notification from BlazingMQ to the application,
-specifying that the message has been received. This is valuable
-for ensuring delivery of messages.
-
These messages will be received in the optionally provided callback to
-Session.post().
-
An Ack is by itself not an indication of success unless it has a status of
-AckStatus.SUCCESS.
a globally unique identifier generated by BlazingMQ for the
-message that was successfully posted. This can be correlated between the
-producer and consumer to verify the flow of messages.
the AckStatus indicating the result of the post
-operation. Unless this is of type AckStatus.SUCCESS, the post has
-failed and potentially needs to be dealt with.
Control whether a Session sees the host as healthy or unhealthy.
-
When a BasicHealthMonitor is passed for the Session constructor’s
-host_health_monitor parameter, you can control whether the BlazingMQ
-session sees the host as healthy or unhealthy by calling the set_healthy
-and set_unhealthy methods. Newly created instances default to the
-healthy state.
An AckStatus is a status of a received Ack message
-which is the result of an attempted put to some particular queue.
-Anything other than AckStatus.SUCCESS represents a failure.
Notification that the host has been marked unhealthy.
-
This is emitted only if host_health_monitor=None was not provided when
-the Session was created. This will be emitted whenever the machine
-becomes unhealthy. It is also emitted if the machine is initially unhealthy
-when the Session is created.
Notification that the host is no longer marked unhealthy.
-
This is emitted only if host_health_monitor=None was not provided when
-the Session was created. It will be emitted once the machine is becomes
-healthy after an earlier HostUnhealthy event. Before this event
-is emitted, you will receive a QueueResumed or QueueResumeFailed for
-each queue that was suspended due to suspends_on_bad_host_health=True.
A queue that is sensitive to host health has been suspended.
-
After a HostUnhealthy event is emitted, any queue that was opened with
-suspend_on_bad_host_health=True will suspend operation. This event will
-be emitted once for each suspended queue.
-
-
Note
-
If host_health_monitor=None was provided when the Session was
-created, this event will never be emitted because the host will never
-be considered unhealthy.
A queue that is sensitive to host health could not be suspended.
-
Whenever a QueueSuspended event would be expected, this event may be
-emitted instead if the SDK is unable to suspend the queue as expected.
-
-
Note
-
The BlazingMQ SDK considers the failure to suspend a queue as evidence
-of an unusually serious problem with the connection to the broker, so
-if this event occurs the SDK follows it up by dropping the connection
-to the broker and trying to re-establish it.
A queue that is sensitive to host health has been resumed.
-
Once an unhealthy machine becomes healthy again, the SDK will automatically
-attempt to resume each queue that was suspended when the machine became
-unhealthy. This event will be emitted once for each queue that had been
-suspended, only after which will HostHealthRestored be emitted.
This was originally exposed only for testing purposes, but is now supported for
-general use. The original name has been retained for backwards compatibility,
-but new code should prefer to use blazingmq.BasicHealthMonitor directly.
A complete example of a program that posts a message and waits for it to be acknowledged
-by the broker.
-
Note that on_ack is an optional argument. However, receiving acknowledgment is the only
-way to guarantee that your message was received by the broker. In this example, messages are sent
-in a fully synchronous fashion - the program waits for an acknowledgement before terminating.
-
# Copyright 2019-2023 Bloomberg Finance L.P.
-# SPDX-License-Identifier: Apache-2.0
-#
-# Licensed under the Apache License, Version 2.0 (the "License");
-# you may not use this file except in compliance with the License.
-# You may obtain a copy of the License at
-#
-# http://www.apache.org/licenses/LICENSE-2.0
-#
-# Unless required by applicable law or agreed to in writing, software
-# distributed under the License is distributed on an "AS IS" BASIS,
-# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-# See the License for the specific language governing permissions and
-# limitations under the License.
-
-from__future__importannotations
-
-importfunctools
-importthreading
-
-importblazingmq
-
-QUEUE_URI="bmq://bmq.test.mmap.priority/blazingmq-examples"
-
-
-defon_ack(event:threading.Event,ack:blazingmq.Ack)->None:
- ifack.status!=blazingmq.AckStatus.SUCCESS:
- print("Received NAck: %r"%ack)
- else:
- print("Received Ack: %r"%ack)
- event.set()
-
-
-defmain()->None:
- withblazingmq.Session(blazingmq.session_events.log_session_event)assession:
- print("Connected to BlazingMQ broker")
- session.open_queue(QUEUE_URI,write=True)
- event=threading.Event()
- on_ack_with_event=functools.partial(on_ack,event)
- print("Posting message")
- session.post(QUEUE_URI,b"\xde\xad\x00\x00\xbe\xef",on_ack=on_ack_with_event)
- print("Waiting for acknowledgement")
- event.wait(timeout=5.0)
-
-
-if__name__=="__main__":
- main()
-
A complete example of a program that consumes messages from a BlazingMQ
-queue. The main thread is blocked waiting for threading.Event to be set upon
-receiving SIGTERM, while incoming messages are processed in the callback on
-the BlazingMQ event handler thread.
-
# Copyright 2019-2023 Bloomberg Finance L.P.
-# SPDX-License-Identifier: Apache-2.0
-#
-# Licensed under the Apache License, Version 2.0 (the "License");
-# you may not use this file except in compliance with the License.
-# You may obtain a copy of the License at
-#
-# http://www.apache.org/licenses/LICENSE-2.0
-#
-# Unless required by applicable law or agreed to in writing, software
-# distributed under the License is distributed on an "AS IS" BASIS,
-# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-# See the License for the specific language governing permissions and
-# limitations under the License.
-
-from__future__importannotations
-
-importsignal
-importthreading
-fromtypingimportAny
-
-importblazingmq
-
-QUEUE_URI="bmq://bmq.test.mmap.priority/blazingmq-examples"
-EXITING=threading.Event()
-
-
-defon_message(msg:blazingmq.Message,msg_handle:blazingmq.MessageHandle)->None:
- print("Confirming: ",msg)
- msg_handle.confirm()
-
-
-defmain()->None:
- withblazingmq.Session(
- blazingmq.session_events.log_session_event,
- on_message=on_message,
- )assession:
- print("Connected to BlazingMQ broker")
- print("Send SIGTERM to exit")
- session.open_queue(QUEUE_URI,read=True)
-
- EXITING.wait()
- print("Waiting to process all outstanding messages")
- session.configure_queue(QUEUE_URI,blazingmq.QueueOptions(0,0,0))
- print("Session stopped.")
-
-
-defon_signal(signum:int,_frame:Any)->None:
- print(f"Received signal: {signum}. Exiting...")
- EXITING.set()
-
-
-if__name__=="__main__":
- signal.signal(signal.SIGINT,on_signal)# handle CTRL-C
- signal.signal(signal.SIGTERM,on_signal)
- main()
-
Correct synchronization may be difficult to implement. It sometimes helps to use the
-Python standard library queue.Queue. The following example consumes messages from
-a BlazingMQ queue and uses queue.Queue for synchronization.
-
The main thread is blocked in a Queue.get while all new messages are immediately
-added to the in-process queue. There will be no more than max_unconfirmed_messages
-in the in-process queue at any given time (unless more than max_unconfirmed_bytes
-was received first) because the broker will pause delivery once
-this value has been reached. Once SIGTERM is received, a sentinel object is added to
-the in-process queue; all BlazingMQ messages received after the signal will be ignored.
-
Also note that, in this example, we provide suspends_on_bad_host_health=True
-when we open the queue. This stops the queue from receiving messages if the
-machine is marked unhealthy, so that we don’t unintentionally process a message
-on an unhealthy machine.
-
# Copyright 2019-2023 Bloomberg Finance L.P.
-# SPDX-License-Identifier: Apache-2.0
-#
-# Licensed under the Apache License, Version 2.0 (the "License");
-# you may not use this file except in compliance with the License.
-# You may obtain a copy of the License at
-#
-# http://www.apache.org/licenses/LICENSE-2.0
-#
-# Unless required by applicable law or agreed to in writing, software
-# distributed under the License is distributed on an "AS IS" BASIS,
-# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-# See the License for the specific language governing permissions and
-# limitations under the License.
-
-from__future__importannotations
-
-importqueue
-importsignal
-fromtypingimportAny
-fromtypingimportOptional
-
-importblazingmq
-
-QUEUE_URI="bmq://bmq.test.mmap.priority/blazingmq-examples"
-
-MESSAGES:queue.Queue[Optional[blazingmq.Message]]=queue.Queue()
-
-
-defon_message(msg:blazingmq.Message,_msg_handle:blazingmq.MessageHandle)->None:
- MESSAGES.put(msg)
-
-
-defmain()->None:
- print("Starting consumer2")
- print("Send SIGTERM to exit.")
- withblazingmq.Session(
- blazingmq.session_events.log_session_event,
- on_message=on_message,
- )assession:
- print("Connected to BlazingMQ broker")
- session.open_queue(
- QUEUE_URI,
- read=True,
- options=blazingmq.QueueOptions(
- max_unconfirmed_messages=100,
- suspends_on_bad_host_health=False,
- ),
- )
-
- whileTrue:
- msg=MESSAGES.get()
- ifmsgisNone:
- break
- print("Confirming: ",msg)
- session.confirm(msg)
- print("Waiting to receive all outstanding messages")
- session.configure_queue(QUEUE_URI,blazingmq.QueueOptions(0,0,0))
-
- print("Session stopped.")
-
-
-defon_signal(signum:int,_frame:Any)->None:
- print(f"Received signal: {signum}. Exiting...")
- MESSAGES.put(None)
-
-
-if__name__=="__main__":
- signal.signal(signal.SIGINT,on_signal)# handle CTRL-C
- signal.signal(signal.SIGTERM,on_signal)
- main()
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
\ No newline at end of file
diff --git a/docs/docs/apidocs/python_apidocs/genindex.html b/docs/docs/apidocs/python_apidocs/genindex.html
deleted file mode 100644
index 135795ac5..000000000
--- a/docs/docs/apidocs/python_apidocs/genindex.html
+++ /dev/null
@@ -1,495 +0,0 @@
-
-
-
-
-
- Index — blazingmq 1.2.0 documentation
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Index
-
-
-
-
-
-
-
-
-
-
Index
-
-
- A
- | B
- | C
- | D
- | E
- | G
- | H
- | I
- | L
- | M
- | N
- | O
- | P
- | Q
- | R
- | S
- | T
- | U
- | W
- | Z
-
-
A message can have some arbitrary metadata associated with it. This metadata is
-represented by a dictionary of key-value pairs. Here, we cover how to associate
-properties with messages being posted, and how to retrieve properties when consuming
-messages.
When invoking Session.post with a message, you can provide a dict to the optional
-properties parameter to associate properties with the message being posted.
-
BlazingMQ has particular types of property values that can be part of this
-dictionary – as enumerated in PropertyType.
-
If you do not particularly care about which exact PropertyType is being targeted,
-the types inferred by default are as follows:
However, if you want to target a particular PropertyType, you can leverage the
-property_type_overrides in Session.post. Be aware that any key included in
-property_type_overridesmust be present in properties. For any particular
-property, if an override is missing, the default is inferred as above.
-
The following table describes the properties that can be set and the accepted types:
If the Message received in your on_message callback installed on Session
-contains any properties, it will always contain both a Message.properties and a
-fully populated Message.property_types. This means that, for every property denoted
-by a key in Message.properties, there will also be a corresponding key in
-Message.property_types to denote the BlazingMQ type of the property received.
-
The Python types that you can expect will be a mirror of the second table in the
-section above.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
\ No newline at end of file
diff --git a/docs/docs/apidocs/python_apidocs/objects.inv b/docs/docs/apidocs/python_apidocs/objects.inv
deleted file mode 100644
index e0860a38d..000000000
Binary files a/docs/docs/apidocs/python_apidocs/objects.inv and /dev/null differ
diff --git a/docs/docs/apidocs/python_apidocs/py-modindex.html b/docs/docs/apidocs/python_apidocs/py-modindex.html
deleted file mode 100644
index 67412914c..000000000
--- a/docs/docs/apidocs/python_apidocs/py-modindex.html
+++ /dev/null
@@ -1,136 +0,0 @@
-
-
-
-
-
- Python Module Index — blazingmq 1.2.0 documentation
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
There are several available options for configuring a queue’s behavior. The
-documentation for QueueOptions shows all of the options available for you to
-configure.
Most applications will use default values for their queue settings, but if you
-need to adjust an option, you can provide QueueOptions when you open the
-queue. For example, if you want to configure the priority of your consumer
-relative to other consumers of the same queue, you could set the
-consumer_priority option when you open the queue:
You can also adjust the options of an already opened queue to meet the
-application’s needs. If the application enters a phase where it’s receiving
-larger messages, you might want to tell the broker that it’s okay for you to
-have twice as many bytes as normal for messages that have been received but
-have not yet been confirmed. You could do that with:
An application can ask the broker to stop delivering new messages. This is most
-common as part of a graceful shutdown (as seen in the User Guide’s
-Simple Consumer), but you could choose to do this at any time. You
-accomplish this by setting max_unconfirmed_messages to zero:
If your application wants to resume receiving messages later, it should save
-the queue’s original options with a call to get_queue_options before setting
-max_unconfirmed_messages=0, and then supply those original options to
-configure_queue when it’s ready for new messages again.
When multiple consumers are attached to a queue with the default
-consumer_priority, the broker delivers messages in a round-robin
-fashion. However, it may be preferable to have a single consumer receiving the
-messages, with one or more backup consumers that can take over if the primary
-consumer goes offline. This can be achieved by supplying a unique
-consumer_priority for each consumer, in which case every message for the
-queue will be delivered to the highest priority consumer that is connected and
-not suspended.
The guide will walk you through building a simple producer and consumer using the
-blazingmq package. This guide however does not cover some of the more complex
-concepts including message properties, queue options, queue configuration and the
-Message object. For reference documentation see the API Reference.
First, you need create an instance of the Session object.
-The only required positional argument is a callback that takes a single argument of
-type SessionEvent. For example, the on_session_event callback could look like:
-
defon_session_event(event):
- print(event)
-
-
-
In the following example however, we use the library function
-session_events.log_session_event which provides some default configured logging for
-incoming session events:
-
importblazingmq
-
-withblazingmq.Session(blazingmq.session_events.log_session_event)assession:
- # session can be used inside this block
-
-
-
-
Note
-
There should be only oneSession object per process since it is very
-heavyweight, holds a lot of state, and consumes both broker and operating system
-resources.
-
-
The session is the object responsible for network connections, thread pools, internal
-memory and storage. The context manager will make sure that its resources are
-correctly managed even if an exception is raised in the block. On enter, the context
-manager will ensure that the Session is started and valid and on exit, it will
-ensure that the Session is stopped and cleaned up.
-
Using the Session, you can open a queue in write mode. Using write=True enables
-our queue for posting messages:
-
session.open_queue(queue_uri,write=True)
-
-
-
Once opened, you can use the queue URI to post a message on the session like:
-
session.post(queue_uri,b"Some message here")
-
-
-
The Session.post optionally also takes an on_ack callback if the user wants to
-receive an acknowledgment for the message being posted. This on_ack callback will
-be invoked with the result of the post.
The first thing you need to do for any BlazingMQ application is to create the
-Session. Since we intend to consume messages from a queue opened in read
-mode, we also want to specify the optional on_message callback in addition
-to the required on_session_event callback:
-
withblazingmq.Session(blazingmq.session_events.log_session_event,
- on_message=on_message_callback)assession:
- # session can be used inside this block
-
-
-
-
Note
-
There should be only oneSession object per process since it is very
-heavyweight, holds a lot of state, and consumes both broker and operating system
-resources.
-
-
-
Note
-
The on_message callback will receive messages for all queues in read mode. If
-the program is reading from multiple queues, Message.queue_uri will indicate which
-queue this message is associated with.
You can then use the Session to open a queue. When you are opening a queue in read
-mode, you must specify an on_message callback to process incoming messages as
-documented above:
-
session.open_queue(queue_uri,read=True)
-
-
-
-
Note
-
You can create a queue that is both a producer and a consumer,
-by passing in both read=True and write=True.
-
-
To open the queue you need to provide the URI that uniquely identifies the
-queue within the BlazingMQ framework
-(bmq://bmq.tutorial.workqueue/example_queue). To open it in read mode,
-read=True is used.
-
-
Note
-
The QueueOptions parameter has been elided, and
-the default is being used.
-
-
When Session.open_queue method returns, messages directed towards the specified
-queue will start being received in the on_message_callback.
-
Once you get a Message object in the callback, you can inspect the data inside
-the message:
-
print(message.data)
-
-
-
The data contained inside will be of type bytes. To correctly decode the data
-inside the Message object you need to know the encoding that the producer
-used when it placed the message in the queue. This could be JSON, XML, BER or
-any other type of encoding. From the perspective of BlazingMQ, the encoding
-does not matter since only bytes are transmitted.
-
Assuming at this point the processing of the message was successful and you do
-not want to receive it again, you can call Session.confirm with this message
-passed as an argument. This will notify the BlazingMQ broker that the message
-should not be re-delivered to another consumer.
-
session.confirm(message)
-
-
-
Alternatively, an instance of blazingmq.MessageHandle is received along with every message.
-It can be used to confirm the message with which it was received. Notice that you don’t
-need to pass the message as an argument.
-
message_handle.confirm()
-
-
-
At the end, when the queue has served its purpose, you want to first pause incoming
-messages and ensure in-flight callbacks to finish processing by calling
-Session.configure_queue with zero-ed queue options:
Finally, once this returns successfully, you can safely close it by calling
-Session.close_queue with the appropriate queue URI:
-
session.close_queue(queue_uri)
-
-
-
Once this method returns, you will no longer receive messages for the queue and the
-queue URI can no longer be used for any operations, other than Session.open_queue.
You can pass host_health_monitor=None to the Session constructor if you
-don’t want any host health monitoring, in which case you won’t be able to use
-the suspends_on_bad_host_health queue option, and you will never get any host
-health related session events.
-
For testing purposes, you can pass an instance of BasicHealthMonitor as the
-host_health_monitor argument for the Session constructor, and your tests
-can control whether the Session believes the host is healthy or not by
-calling the set_healthy and set_unhealthy methods of that instance.
-
-
New in version 0.7.0: Host health monitoring and queue suspension
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
\ No newline at end of file
diff --git a/docs/docs/architecture/client_broker_protocol.md b/docs/docs/architecture/client_broker_protocol.md
deleted file mode 100644
index b0f1515e7..000000000
--- a/docs/docs/architecture/client_broker_protocol.md
+++ /dev/null
@@ -1,1225 +0,0 @@
----
-layout: default
-title: Client/Broker Protocol
-parent: Architecture
-nav_order: 8
----
-
-# BlazingMQ Client/Broker Protocol
-{: .no_toc }
-
-* toc
-{:toc}
-
-## Introduction
-
-This article documents the protocol between a BlazingMQ client and broker, and
-also goes over some best practices for designing and implementing BlazingMQ
-client library. Readers interested in implementing a BlazingMQ client library
-may find this article useful.
-
-Before we dive in, it is worth noting that:
-
-1. BlazingMQ has native client libraries in C++ and Java. The Python library
- is a wrapper over C++ library. BlazingMQ does not have a C library.
-
-2. In order to provide a good user experience, shield applications from various
- transient issues and support high performance, BlazingMQ C++ and Java
- libraries are quite stateful, highly asynchronous and carefully designed.
- If the goal of author of BlazingMQ client library is to reach as many
- audience as possible, they should attempt to do the same with their library
- design and implementation.
-
-3. Ideally, the author should be willing to help us maintain the client library
- in the long run. As a provider of an infrastructure framework, we want to
- provide good support to our users, and having the author's help in handling
- any bug fixes and enhancements in the library will make our job easy!
-
-4. We have had queries about client libraries in Go, .NET and Rust, so
- targeting one of those languages may provide maximum benefits to our users.
-
-
-The rest of this document is divided into three main parts:
-
-- *BlazingMQ wire protocol*, which goes over format of messages exchanged
- between BlazingMQ client and broker.
-
-- *BlazingMQ client/server interaction*, which goes over the order in which
- these messages are exchanged.
-
-- *Client library design guide*, which goes over some recommendations for
- implementing a BlazingMQ client library in a language-agnostic way.
-
-Let's dive into some details now!
-
----
-
-## BlazingMQ Wire Protocol
-
-BlazingMQ wire protocol sits at the lowest level in the BlazingMQ client/server
-interaction. BlazingMQ has a custom protocol over TCP. This protocol defines
-the format of messages exchanged between BlazingMQ client and broker. There
-were four guiding principles when this protocol was designed:
-
-- *Compactness*: The protocol should have minimal overhead.
-
-- *Forward and backward compatibility*: The protocol should be easily
- extensible while remaining backward compatible.
-
-- *Batching*: The protocol should support batching of messages wherever
- possible.
-
-- *Efficiency*: The protocol should avoid encoding/decoding overhead for
- frequent messages, while still taking into consideration concerns like
- endianness, etc.
-
-### BlazingMQ Network Packet
-
-Before we get into various types of messages in BlazingMQ wire protocol, let's
-understand the layout of a BlazingMQ network packet.
-
-Every BlazingMQ network packet begins with an 8-byte header called the
-`EventHeader`
-([C++](https://github.com/bloomberg/blazingmq/blob/ca6491f69eea8d91733fa36ef3e82c4facc734fc/src/groups/bmq/bmqp/bmqp_protocol.h#L727),
-[Java](https://github.com/bloomberg/blazingmq-sdk-java/blob/main/bmq-sdk/src/main/java/com/bloomberg/bmq/impl/infr/proto/EventHeader.java)).
-
-The meaning of every field in the header is documented in the files linked
-above. Some important things to know about:
-
-- In BlazingMQ, a full BlazingMQ network packet is often referred to as an
- `Event`.
-
-- The fragment bit `F` is currently unused and always set to zero.
-
-- Remaining 31 bits capture the entire length of the packet, including the
- header, sub-headers, any options, padding, etc.
-
-- The `Type` field captures
- [type](https://github.com/bloomberg/blazingmq/blob/ca6491f69eea8d91733fa36ef3e82c4facc734fc/src/groups/bmq/bmqp/bmqp_protocol.h#L457)
- of the packet. Note that a BlazingMQ packet is homogeneous. In other words,
- a packet can contain more than one BlazingMQ message, but all of those
- messages will be of the same type. For example, if the type of the packet is
- `PUT`, all messages which appear in the packet will be `PUT` messages.
-
-- The `HeaderWords` field captures the size of the `EventHeader` itself. This
- helps with backward and forward compatibility as the wire protocol evolves.
- Here's how: suppose 4 more bytes are added to `EventHeader` as part of a new
- feature implementation, and a new BlazingMQ broker is rolled out and starts
- sending BlazingMQ network packets with the additional 4 bytes in the
- `EventHeader`. If BlazingMQ brokers derived the size of `EventHeader` using,
- `sizeof(EventHeader)` in C++, old BlazingMQ brokers will continue to assume
- that the size of `EventHeader` is still 8 bytes, and will interpret the new 4
- bytes as the next part of the packet (e.g., a sub-header, payload, etc).
- However, instead of using `sizeof` operators, if BlazingMQ broker code reads
- size of the header from the `HeaderWords` field of the received packet, old
- brokers will know that `EventHeader` is 12 bytes instead of 8. Obviously,
- old brokers will not understand how to interpret those 4 new bytes, but they
- will skip it, which is good enough. Almost every header struct in BlazingMQ
- wire protocol contains the `HeaderWords` field.
-
-- Every `EventHeader` is followed by the event-specific details. For example,
- if it is a packet of type `PUT`, `EventHeader` will be followed by one or
- more pairs of `PutHeader` and message payload (more on this later).
-
-### Types of Messages
-
-Now that we understand top level structure of a BlazingMQ network packet,
-let's dive into the next level of detail. At a high level, there are two types
-of messages in the protocol:
-
-- **Binary messages**: This type of messages are not encoded/decoded. They are
- simple 'structs' (sequence of raw bytes) directly written/read to/from the
- wire. This format is used for messages which are exchanged frequently
- between client and broker (typically data messages or 'data plane'). Some
- examples of such messages are `PutMessage`, `ConfirmMessage`, etc. The goal
- is to avoid paying encoding/decoding overhead for frequent messages.
-
-- **Schema messages**: This type of messages are defined in a schema and are
- encoded/decoded using coding schemes like JSON, BER, XML, etc. This format
- is used for messages which are infrequent (typically control messages or
- 'control plane'). Some examples of such messages are `OpenQueueRequest`,
- `CloseQueueRequest`, `DisconnectRequest`, etc. Since such messages are
- infrequent, it is okay to pay the overhead of encoding/decoding them in lieu
- of flexibility and ease of use.
-
-Let's look into both of these message types in detail.
-
-### Binary Messages
-
-Binary messages in BlazingMQ are defined
-[here](https://github.com/bloomberg/blazingmq/blob/main/src/groups/bmq/bmqp/bmqp_protocol.h)
-for C++, and
-[here](https://github.com/bloomberg/blazingmq-sdk-java/tree/main/bmq-sdk/src/main/java/com/bloomberg/bmq/impl/infr/proto)
-for Java.
-
-> [!NOTE]
-> The C++ header file `bmqp_protocol.h` linked above also contains some
-> binary messages which are exchanged only between BlazingMQ brokers. This can
-> cause confusion when trying to look at the list of messages which are
-> exchanged only between client and broker. A better place to look at the
-> messages exchanged between client and broker would be in the Java link above.
-
-Here's a list of binary messages which are exchanged between BlazingMQ client
-and broker, along with their purpose:
-
-- **PutMessage**: A message posted by the producer to the BlazingMQ queue. This
- message contains the payload and any associated metadata that producer wants
- to be delivered to the consumer.
-
-- **AckMessage**: An acknowledgement sent by BlazingMQ queue to the producer in
- response to the PUT message. The *AckMessage* carries the success/failure
- status, telling the producer if BlazingMQ accepted the *PutMessage* or not.
-
-- **PushMessage**: A message sent by the BlazingMQ queue to a consumer
- application. This message is same as a *PutMessage* except for a few
- details.
-
-- **ConfirmMessage**: A message sent by the consumer to the BlazingMQ queue
- indicating that the *PushMessage* was successfully processed by the consumer
- and that the BlazingMQ queue can mark the message as consumed and delete it
- at any time.
-
-See [this](#binary-messages-wire-layout) section below which goes over more
-details about how binary messages are packed for their wire representation.
-
-### Schema Messages
-
-Schema messages in BlazingMQ are defined
-[here](https://github.com/bloomberg/blazingmq/blob/main/src/groups/bmq/bmqp/bmqp_ctrlmsg.xsd)
-for C++, and [here](https://github.com/bloomberg/blazingmq-sdk-java/tree/main/bmq-sdk/src/main/java/com/bloomberg/bmq/impl/infr/msg) for Java.
-
-> [!NOTE]
-> Similar to the note in binary messages, the schema `bmqp_ctrlmsg.xsd` linked
-> above also contains some schema messages which are exchanged only between
-> BlazingMQ brokers. This can cause confusion when trying to look at the list
-> of schema messages which are exchanged only between client and broker. A
-> better place to look at the messages exchanged between client and broker
-> would be in the Java link above.
-
-The recommendation is to use the JSON codec for schema messages. Other encodings
-like BER, XML, etc are also supported but not recommended. The C++ SDK uses the
-[`baljsn`](https://github.com/bloomberg/bde/tree/main/groups/bal/baljsn) codec
-for JSON encoding, and the Java SDK uses [`gson`](https://github.com/google/gson)
-codec.
-
-Here's a list of schema messages which are exchanged between BlazingMQ client
-and broker, along with their purpose:
-
-- **NegotiationMessage**: The first message sent by the client to the broker
- upon establishing a TCP connection with the broker (see
- [this](https://github.com/bloomberg/blazingmq-sdk-java/blob/main/bmq-sdk/src/main/java/com/bloomberg/bmq/impl/infr/msg/NegotiationMessageChoice.java)).
- It's a choice, and the client always sets the choice to
- [`ClientIdentity`](https://github.com/bloomberg/blazingmq-sdk-java/blob/main/bmq-sdk/src/main/java/com/bloomberg/bmq/impl/infr/msg/ClientIdentity.java),
- and populates various fields in `ClientIdentity` accordingly. Broker
- responds with a `NegotiationMessage` as well, but sets
- [`BrokerResponse`](https://github.com/bloomberg/blazingmq-sdk-java/blob/main/bmq-sdk/src/main/java/com/bloomberg/bmq/impl/infr/msg/BrokerResponse.java)
- instead of `ClientIdentity`. A `NegotiationMessage` from the client can be
- thought of as an application level handshake with the broker to establish a
- BlazingMQ session. The client advertises some of its capabilities, version, and
- some other details in the `NegotiationMessage`. Based on this information,
- the broker can choose to accept or reject the connection with the client
- (e.g., if the client is using a very old version of the SDK, the broker may
- refuse to connect with the client).
-
-- **OpenQueue**: The request that the client sends to the broker to attach to a
- queue (see
- [this](https://github.com/bloomberg/blazingmq-sdk-java/blob/main/bmq-sdk/src/main/java/com/bloomberg/bmq/impl/infr/msg/OpenQueue.java)).
- `OpenQueue` contains a
- [`QueueHandleParameters`](https://github.com/bloomberg/blazingmq-sdk-java/blob/main/bmq-sdk/src/main/java/com/bloomberg/bmq/impl/infr/msg/QueueHandleParameters.java)
- field. The client populates each field of `QueueHandleParameters` appropriately.
- An `OpenQueue` request can be logically thought as a request by a BlazingMQ
- application to get a handle on the queue or connecting to a queue. Note that
- an `OpenQueue` request is always followed by a
- [`ConfigureQueue`](https://github.com/bloomberg/blazingmq-sdk-java/blob/main/bmq-sdk/src/main/java/com/bloomberg/bmq/impl/infr/msg/ConfigureQueueStream.java)
- request.
-
-- **OpenQueueResponse**: The response sent by the broker for an `OpenQueue`
- request (see [this](https://github.com/bloomberg/blazingmq-sdk-java/blob/main/bmq-sdk/src/main/java/com/bloomberg/bmq/impl/infr/msg/OpenQueueResponse.java)).
-
-- **ConfigureQueueStream**: The request sent by the client to the broker to
- configure the client's configuration for a queue which was opened earlier by
- the client by making an `OpenQueue` request (see
- [this](https://github.com/bloomberg/blazingmq-sdk-java/blob/main/bmq-sdk/src/main/java/com/bloomberg/bmq/impl/infr/msg/ConfigureQueueStream.java)).
- The main field in this request is
- [`QueueStreamParameters`](https://github.com/bloomberg/blazingmq-sdk-java/blob/main/bmq-sdk/src/main/java/com/bloomberg/bmq/impl/infr/msg/ConfigureQueueStream.java).
- A producer or consumer application can start using a queue only after sending
- an `OpenQueue` request and then a `ConfigureQueueStream` request. A
- `ConfigureQueueStream` request is used by the producer/consumer to set its
- priority or flow-control parameters for the queue. A producer/consumer can
- also send a stand-alone `ConfigureQueueStream` request at any time to do the
- same. However, it must send one upon receiving a successful
- `OpenQueueResponse` from the broker.
-
-- **ConfigureQueueStreamResponse**: The message sent by the broker in response
- to the `ConfigureQueueStream` request from the client (see
- [this](https://github.com/bloomberg/blazingmq-sdk-java/blob/main/bmq-sdk/src/main/java/com/bloomberg/bmq/impl/infr/msg/ConfigureQueueStreamResponse.java)).
-
-- **CloseQueue**: The request sent by the client to the broker to indicate that
- client no longer wants to be attached to the queue (see
- [this](https://github.com/bloomberg/blazingmq-sdk-java/blob/main/bmq-sdk/src/main/java/com/bloomberg/bmq/impl/infr/msg/CloseQueue.java)).
- A `CloseQueue` request is the opposite of an `OpenQueue` request. Note that
- a `CloseQueue` request is always preceded by an `ConfigureQueueStream`
- request.
-
-- **Disconnect**: The request sent by the client to tear down the BlazingMQ
- session with the broker (see
- [this](https://github.com/bloomberg/blazingmq-sdk-java/blob/main/bmq-sdk/src/main/java/com/bloomberg/bmq/impl/infr/msg/Disconnect.java)).
-
-- **DisconnectResponse**: The message sent by the broker to the client in
- response to a `Disconnect` request (see
- [this](https://github.com/bloomberg/blazingmq-sdk-java/blob/main/bmq-sdk/src/main/java/com/bloomberg/bmq/impl/infr/msg/DisconnectResponse.java)). Once `DisconnectResponse` is
- sent by the broker, no other message is sent by it to the client.
-
-See [this](#schema-messages-wire-layout) section below which goes over more
-details about how schema messages are packed for their wire representation.
-
----
-
-## Binary Messages Wire Layout
-
-This section explains how binary messages are typically packed for their wire
-representation.
-
-As mentioned earlier in the article, every BlazingMQ network packet starts with
-an
-`EventHeader`([C++](https://github.com/bloomberg/blazingmq/blob/ca6491f69eea8d91733fa36ef3e82c4facc734fc/src/groups/bmq/bmqp/bmqp_protocol.h#L727),
-[Java](https://github.com/bloomberg/blazingmq-sdk-java/blob/main/bmq-sdk/src/main/java/com/bloomberg/bmq/impl/infr/proto/EventHeader.java)).
-
-### Endianness
-
-When serializing binary messages, one needs to be careful about endianness.
-Readers may already be aware that network byte order is big-endian. As of
-writing this, BlazingMQ runs on both little-endian (x86) as well as big-endian
-(SPARC, PowerPC) architectures. In order to minimize errors when
-(de)serializing BlazingMQ network packets, BlazingMQ uses some helper classes.
-
-In Java, there are two wrapper classes in BlazingMQ --
-[`ByteBufferInputStream`](https://github.com/bloomberg/blazingmq-sdk-java/blob/main/bmq-sdk/src/main/java/com/bloomberg/bmq/impl/infr/io/ByteBufferInputStream.java)
-and
-[`ByteBufferOutputStream`](https://github.com/bloomberg/blazingmq-sdk-java/blob/main/bmq-sdk/src/main/java/com/bloomberg/bmq/impl/infr/io/ByteBufferOutputStream.java)
-which under the hood use
-[`java.nio.ByteBuffer`](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/nio/ByteBuffer.html),
-which in turn takes care of flipping the bytes when reading/writing integers,
-doubles, etc.
-
-In C++, BlazingMQ uses various
-[`bdlb::BigEndian`](https://github.com/bloomberg/bde/blob/main/groups/bdl/bdlb/bdlb_bigendian.h)
-classes from one of our helper libraries. These classes take care of swapping
-the bytes seamlessly. As an example,
-[here](https://github.com/bloomberg/blazingmq/blob/69f0f8f5b188ca1eb07b9d262093f949729db538/src/groups/bmq/bmqp/bmqp_protocol.h#L779)
-we use the
-[`bdlb::BigEndianUint32`](https://github.com/bloomberg/bde/blob/cf44cbb2cc179077f687f5408d92d6949fae75af/groups/bdl/bdlb/bdlb_bigendian.h#L517)
-type to represent an `uint32_t` to capture the `fragment` and `length`
-fields of an `EventHeader`.
-
-Let's go over the wire layout of every binary message exchanged between client
-and the broker.
-
-### PUT Event
-
-A PUT event is a BlazingMQ network packet which is sent by the producer
-application to the BlazingMQ backend, with one or more messages destined for
-one or more BlazingMQ queues.
-
-A PUT event wire layout looks like this:
-
-```
-[EventHeader][PutHeader #1][Option #1][Option #2]...[Option #N][Message Properties][Message Payload][PutHeader #2][Option #1][Option #2]...[Option #N][Message Properties][Message Payload]...
-```
-
-To describe above layout in words:
-
-- `EventHeader` represents the top-level header which captures some details of
- the entire PUT event (event type, total length, protocol version, etc).
-
-- `PutHeader #1` represents the header of the first PUT message in the event.
- A
- [`PutHeader`](https://github.com/bloomberg/blazingmq/blob/e3ddd4fdc8e024e3abff96aa91555f042ce4e565/src/groups/bmq/bmqp/bmqp_protocol.h#L1337)
- contains fields like:
-
- - `MessageWords`: Length of the entire PUT message (including options,
- properties, payload and padding) in words (1 word == 4 bytes).
-
- - `OptionsWords`: Length of all options, if any, in words.
-
- - `CAT`: Compression algorithm type (see
- [this](https://github.com/bloomberg/blazingmq/blob/main/src/groups/bmq/bmqt/bmqt_compressionalgorithmtype.h)).
-
- - `HeaderWords`: Length of the `PutHeader` itself, in words.
-
- - `QueueId`: unique integer identifier of the queue that was previously
- opened by the client. The `QueueId` integer field is sent by the client in
- the `OpenQueue` request to the broker, and then later on, used to identify
- that queue in any message or request.
-
- - `MessageGuid`: Globally unique identifier for a PUT message generated by
- the client library. See
- [this](https://github.com/bloomberg/blazingmq/blob/main/src/groups/bmq/bmqt/bmqt_messageguid.h)
- and
- [this](https://github.com/bloomberg/blazingmq/blob/main/src/groups/bmq/bmqp/bmqp_messageguidgenerator.h)
- for the layout of the GUID and how it is generated by the C++ SDK.
-
- - `CRC32C`: checksum of the PUT message (checksum of message properties and
- payload, see
- [this](https://github.com/bloomberg/blazingmq/blob/main/src/groups/bmq/bmqp/bmqp_crc32c.h)).
-
- - `SchemaId`: unique identifier for the sequence of message properties, for
- subscriptions.
-
-- `Option #N` represents one of the many options. **NOTE**: As of now, PUT
- messages do not contain any options, but this may change in the future.
-
-- `Message Properties` represent a list of key/value pairs that a producer can
- optionally associate with a PUT message. Each message properties area itself
- begins with a
- [`MessagePropertiesHeader`](https://github.com/bloomberg/blazingmq/blob/e3ddd4fdc8e024e3abff96aa91555f042ce4e565/src/groups/bmq/bmqp/bmqp_protocol.h#L1075),
- followed by *N* [`MessagePropertyHeader`](https://github.com/bloomberg/blazingmq/blob/e3ddd4fdc8e024e3abff96aa91555f042ce4e565/src/groups/bmq/bmqp/bmqp_protocol.h#L1229)s, where
- *N* is the number of key/value pairs in the PUT message, followed by the list
- of key/value pairs. In other words:
-
- ```
- [MessagePropertiesHeader][MessagePropertyHeader #1][MessagePropertyHeader #2]...
- [MessagePropertyHeader #N][PropertyName #1][PropertyValue #1][PropertyName #2]
- [PropertyValue #2]...[PropertyName #n][PropertyValue #N][Word Alignment padding]
- ```
-
- BlazingMQ broker can peek into the message properties area if needed. For
- example, broker can read one or more message properties to evaluate a
- subscription expression.
-
-- `Message Payload` is the payload of the message. BlazingMQ does not
- peek into the message payload. Producer application can indicate to the SDK
- to compress a PUT message, in which case, SDK will compress only the message
- payload (any header, options and message properties are not compressed).
-
-In both C++ and Java SDKs, there are builder and iterator classes for PUT
-event, which encapsulate the logic of building and parsing PUT event
-respectively. PUT event builder and iterator in C++ can be found
-[here](https://github.com/bloomberg/blazingmq/blob/main/src/groups/bmq/bmqp/bmqp_puteventbuilder.h)
-and
-[here](https://github.com/bloomberg/blazingmq/blob/main/src/groups/bmq/bmqp/bmqp_putmessageiterator.h).
-PUT event builder and iterator in Java can be found
-[here](https://github.com/bloomberg/blazingmq-sdk-java/blob/main/bmq-sdk/src/main/java/com/bloomberg/bmq/impl/infr/proto/PutEventBuilder.java)
-and
-[here](https://github.com/bloomberg/blazingmq-sdk-java/blob/main/bmq-sdk/src/main/java/com/bloomberg/bmq/impl/infr/proto/PutMessageIterator.java).
-
-### ACK Event
-
-An ACK event is a BlazingMQ network packet which is sent by the broker to the
-producer application, with one or more ACK messages indicating success/failure
-result for one or more PUT messages previously sent by the producer.
-
-An ACK event wire layout looks like this:
-
-```
-[EventHeader][AckHeader][AckMessage #1][AckMessage #2]...[AckMessage #N]
-```
-
-An ACK event contains one
-[`AckHeader`](https://github.com/bloomberg/blazingmq/blob/e3ddd4fdc8e024e3abff96aa91555f042ce4e565/src/groups/bmq/bmqp/bmqp_protocol.h#L1725C19-L1725C19),
-followed by one or more
-[`AckMessage`](https://github.com/bloomberg/blazingmq/blob/e3ddd4fdc8e024e3abff96aa91555f042ce4e565/src/groups/bmq/bmqp/bmqp_protocol.h#L1849)s.
-
-Note that unlike a PUT event, there is only one `AckHeader` in an ACK event,
-irrespective of the number of `AckMessage`s.
-
-Let's go over various fields in a `AckHeader`:
-
-- `HeaderWords`: Size (in words) of the `AckHeader`.
-
-- `PerMessageWords`: Size (in words) of each `AckMessage`.
-
-Now let's go over various fields in a `AckMessage`:
-
-- `Status`: result of the PUT message (was it accepted or rejected by
- BlazingMQ, with specific error code in case of failure).
-
-- `CorrelationId`: **TODO**
-
-- `MessageGUID`: the 16 byte globally unique identifier of a message. See
- [this](https://github.com/bloomberg/blazingmq/blob/main/src/groups/bmq/bmqt/bmqt_messageguid.h)
- and
- [this](https://github.com/bloomberg/blazingmq/blob/main/src/groups/bmq/bmqp/bmqp_messageguidgenerator.h)
- for the layout of the GUID and how it is generated by the C++ SDK.
-
-- `QueueId`: the integer which uniquely identifies the queue. This integer
- needs to be unique only between a BlazingMQ client application and the
- BlazingMQ backend. It does not need to be globally unique. The integer
- value is chosen by the SDK and sent in the `OpenQueue` request.
-
-In both C++ and Java SDKs, there are builder and iterator classes for ACK
-event, which encapsulate the logic of building and parsing ACK event
-respectively. ACK event builder and iterator in C++ can be found
-[here](https://github.com/bloomberg/blazingmq/blob/main/src/groups/bmq/bmqp/bmqp_ackeventbuilder.h)
-and
-[here](https://github.com/bloomberg/blazingmq/blob/main/src/groups/bmq/bmqp/bmqp_ackmessageiterator.h).
-PUT event builder and iterator in Java can be found
-[here](https://github.com/bloomberg/blazingmq-sdk-java/blob/main/bmq-sdk/src/main/java/com/bloomberg/bmq/impl/infr/proto/AckEventBuilder.java)
-and
-[here](https://github.com/bloomberg/blazingmq-sdk-java/blob/main/bmq-sdk/src/main/java/com/bloomberg/bmq/impl/infr/proto/AckMessageIterator.java).
-
-### PUSH Event
-
-A PUSH event is a BlazingMQ network packet which is sent by the BlazingMQ
-broker to the consumer application, with one or more messages belonging to one
-or more BlazingMQ queues.
-
-A PUSH event wire layout is very similar to the PUT event's layout, and looks
-like this:
-
-```
-[EventHeader][PushHeader #1][Option #1][Option #2]...[Option #N][Message Properties][Message Payload][PushHeader #2][Option #1][Option #2]...[Option #N][Message Properties][Message Payload]...
-```
-
-Just like PUT event, one PUSH event can contain more than one PUSH message.
-Each PUSH message starts with a
-[`PushHeader`](https://github.com/bloomberg/blazingmq/blob/e3ddd4fdc8e024e3abff96aa91555f042ce4e565/src/groups/bmq/bmqp/bmqp_protocol.h#L1962), which itself closely resembles a
-`PutEvent`, except that there is no `CRC32C` field in `PushHeader`. All the
-other fields are same or similar to the ones in `PutHeader`.
-
-**NOTE**: As mentioned earlier, even though every PUT message in a PUT event
-supports zero or more options, currently no options are added in a PUT message.
-That is not the case for PUSH messages. A PUSH message can have one option --
-the
-[`SubQueueInfos`](https://github.com/bloomberg/blazingmq-sdk-java/blob/main/bmq-sdk/src/main/java/com/bloomberg/bmq/impl/infr/proto/SubQueueInfosOption.java).
-If present, this option contains one or more
-[`SubQueueInfo`](https://github.com/bloomberg/blazingmq/blob/e3ddd4fdc8e024e3abff96aa91555f042ce4e565/src/groups/bmq/bmqp/bmqp_protocol.h#L264)
-structs. A `SubQueueInfo` captures details about a sub-stream ("*AppId*") of
-the queue. **TODO**: add more details about `SubQueueInfo` option here
-(fan-out, rda counter, etc).
-
-In both C++ and Java SDKs, there are builder and iterator classes for PUSH
-event, which encapsulate the logic of building and parsing PUSH event
-respectively. PUSH event builder and iterator in C++ can be found
-[here](https://github.com/bloomberg/blazingmq/blob/main/src/groups/bmq/bmqp/bmqp_pusheventbuilder.h)
-and
-[here](https://github.com/bloomberg/blazingmq/blob/main/src/groups/bmq/bmqp/bmqp_pushmessageiterator.h).
-PUSH event builder and iterator in Java can be found
-[here](https://github.com/bloomberg/blazingmq-sdk-java/blob/main/bmq-sdk/src/main/java/com/bloomberg/bmq/impl/infr/proto/PushEventBuilder.java)
-and
-[here](https://github.com/bloomberg/blazingmq-sdk-java/blob/main/bmq-sdk/src/main/java/com/bloomberg/bmq/impl/infr/proto/PushMessageIterator.java).
-
-
-### CONFIRM Event
-
-A CONFIRM event is a BlazingMQ network packet which is sent by the consumer
-application to the BlazingMQ backend, with one or more CONFIRM messages
-indicating that the consumer has processed the corresponding one or more PUSH
-messages previously sent by the BlazingMQ broker.
-
-A CONFIRM event wire layout looks like this:
-
-```
-[EventHeader][ConfirmHeader][ConfirmMessage #1][ConfirmMessage #2]...[ConfirmMessage #N]
-```
-
-A CONFIRM event contains one
-[`ConfirmHeader`](https://github.com/bloomberg/blazingmq/blob/e3ddd4fdc8e024e3abff96aa91555f042ce4e565/src/groups/bmq/bmqp/bmqp_protocol.h#L2296)
-followed by one or more
-[`ConfirmMessage`](https://github.com/bloomberg/blazingmq/blob/e3ddd4fdc8e024e3abff96aa91555f042ce4e565/src/groups/bmq/bmqp/bmqp_protocol.h#L2387)s.
-
-Note that unlike PUT and PUSH events, there is only one `ConfirmHeader` in a
-CONFIRM event, irrespective of the number of `ConfirmMessage`s.
-
-Let's go over various fields in a `ConfirmHeader`:
-
-- `HeaderWords`: Size (in words) of the `ConfirmHeader`.
-
-- `PerMessageWords`: Size (in words) of each `ConfirmMessage`.
-
-Now let's go over various fields in a `ConfirmMessage`:
-
-- `QueueId`: the integer which uniquely identifies the queue. This integer
- needs to be unique only between a BlazingMQ client application and the
- BlazingMQ backend. It does not need to be globally unique. The integer
- value is chosen by the SDK and sent in the `OpenQueue` request.
-
-- `MessageGUID`: the 16 byte globally unique identifier of a message. See
- [this](https://github.com/bloomberg/blazingmq/blob/main/src/groups/bmq/bmqt/bmqt_messageguid.h)
- and
- [this](https://github.com/bloomberg/blazingmq/blob/main/src/groups/bmq/bmqp/bmqp_messageguidgenerator.h)
- for the layout of the GUID and how it is generated by the C++ SDK.
-
-- `SubQueueId`: the integer which uniquely identifies the sub-stream in the
- queue. This integer needs to be unique only between a BlazingMQ client
- application and the BlazingMQ backend within the scope of a queue. It does
- not need to be globally unique and does not need to be unique across various
- queues opened by the same client. The integer value is chosen by the SDK and
- sent in the `ConfigureStream` request.
-
-In both C++ and Java SDKs, there are builder and iterator classes for ACK
-event, which encapsulate the logic of building and parsing ACK event
-respectively. ACK event builder and iterator in C++ can be found
-[here](https://github.com/bloomberg/blazingmq/blob/main/src/groups/bmq/bmqp/bmqp_ackeventbuilder.h)
-and
-[here](https://github.com/bloomberg/blazingmq/blob/main/src/groups/bmq/bmqp/bmqp_ackmessageiterator.h).
-PUT event builder and iterator in Java can be found
-[here](https://github.com/bloomberg/blazingmq-sdk-java/blob/main/bmq-sdk/src/main/java/com/bloomberg/bmq/impl/infr/proto/AckEventBuilder.java)
-and
-[here](https://github.com/bloomberg/blazingmq-sdk-java/blob/main/bmq-sdk/src/main/java/com/bloomberg/bmq/impl/infr/proto/AckMessageIterator.java).
-
----
-
-## Schema Messages Wire Layout
-
-While the wire layout of binary messages can be non-trivial to implement,
-schema messages are (de)serialized fairly easily. Since every schema message's
-wire layout is similar, we will describe the layout in general terms instead of
-going over every schema message. Wire layout of every schema message looks
-like this:
-
-```
-[EventHeader][Encoded Schema Message]
-```
-
-Note that schema messages are not batched. One BlazingMQ network event will
-contain only one encoded schema message.
-
-JSON is the recommended encoding to use. The Java SDK uses
-[`gson`](https://github.com/google/gson) library for JSON codecs, and wraps the
-encoding/decoding logic in two simple
-[components](https://github.com/bloomberg/blazingmq-sdk-java/blob/main/bmq-sdk/src/main/java/com/bloomberg/bmq/impl/infr/codec).
-On the outgoing path, the Java SDK also uses
-[`SchemaEventBuilder`](https://github.com/bloomberg/blazingmq-sdk-java/blob/main/bmq-sdk/src/main/java/com/bloomberg/bmq/impl/TcpBrokerConnection.java)
-to prepend [`EventHeader`] to the outgoing message. On the incoming side, the
-SDK uses `JsonDecoderUtil` as shown
-[here](https://github.com/bloomberg/blazingmq-sdk-java/blob/ed0eb848f5ac2897cfe32cc481575d689a4cb1c2/bmq-sdk/src/main/java/com/bloomberg/bmq/impl/infr/proto/ControlEventImpl.java#L54).
-
----
-
-## BlazingMQ Client Server Interaction
-
-Now that we have an understanding of various types of messages (and their wire
-layouts) exchanged between BlazingMQ client and broker, it's time to understand
-the sequence in which these messages are exchanged. Note that general API and
-design guidelines for the SDK are discussed in a
-[later](#client-library-design-guide) section.
-
-Before we go into details, it is worth pointing out these two files from the
-BlazingMQ Java repo --
-[`PlainProducerIT.java`](https://github.com/bloomberg/blazingmq-sdk-java/blob/main/bmq-sdk/src/test/java/com/bloomberg/bmq/it/PlainProducerIT.java)
-and
-[`PlainConsumerIT.java`](https://github.com/bloomberg/blazingmq-sdk-java/blob/main/bmq-sdk/src/test/java/com/bloomberg/bmq/it/PlainConsumerIT.java).
-These two files implement a rudimentary and "raw" BlazingMQ producer and
-consumer respectively. By "raw", we mean that this producer and consumer do
-not use the Java SDK APIs to talk to the BlazingMQ backend. Instead, they just
-create a TCP socket and build, write and read schema and binary messages
-themselves. These files can be useful to get a basic understanding of the flow
-and order of messages between a BlazingMQ client and broker. We will refer to
-these files when describing the message exchange in this section.
-
-### Starting a Session with BlazingMQ Broker
-
-There are two steps involved in establishing a session with BlazingMQ broker --
-connecting with the broker over TCP, and afterwards, carrying out a BlazingMQ
-protocol specific handshake (aka negotiation). Let's look into these steps in
-detail.
-
-#### TCP Connection
-
-The first step in a BlazingMQ client/broker interaction is the client initiating
-a TCP connection with the broker.
-
-Before we go into the mechanics of that, it's worth briefly discussing how a
-BlazingMQ client can figure out the right TCP endpoint (IP + Port) of the
-BlazingMQ broker to connect to. In an enterprise setting, the correct endpoint
-would typically be retrieved via some [service
-discovery](https://dzone.com/articles/microservices-architectures-what-is-service-discov)
-mechanism, where a BlazingMQ client might ask the service discovery APIs to
-resolve a BlazingMQ domain to a BlazingMQ cluster endpoint, and pass that
-endpoint to BlazingMQ's
-[`SessionOptions`](https://github.com/bloomberg/blazingmq-sdk-java/blob/ed0eb848f5ac2897cfe32cc481575d689a4cb1c2/bmq-sdk/src/main/java/com/bloomberg/bmq/SessionOptions.java#L418C37-L418C37).
-Another way could be a using a hard-coded DNS endpoint which points to the
-BlazingMQ cluster, and pass that endpoint to the `SessionOptions`. And yet
-another approach could be to deploy BlazingMQ in the [*Alternative
-Topology*](https://bloomberg.github.io/blazingmq/docs/architecture/clustering/#alternative-deployment)
-and have BlazingMQ client applications connect to the local BlazingMQ proxy
-which could listen on a fixed port number.
-
-Coming back to the TCP connection, SDK initiates the connection by calling some
-flavor of `connect` API in the underlying language or library being used. As
-an example, BlazingMQ Java SDK uses [`netty`](https://netty.io) for its TCP
-connection management and initiates a connection as shown
-[here](https://github.com/bloomberg/blazingmq-sdk-java/blob/ed0eb848f5ac2897cfe32cc481575d689a4cb1c2/bmq-sdk/src/main/java/com/bloomberg/bmq/impl/infr/net/NettyTcpConnection.java#L370).
-On the other hand, the `PlainProducerIT.java` file mentioned above simply uses
-the basic
-[`connect`](https://github.com/bloomberg/blazingmq-sdk-java/blob/ed0eb848f5ac2897cfe32cc481575d689a4cb1c2/bmq-sdk/src/test/java/com/bloomberg/bmq/it/PlainProducerIT.java#L80) API
-provided by the Java language.
-
-An important thing to note here is that both the BlazingMQ C++ and Java SDKs
-use [non-blocking
-I/O](https://beej.us/guide/bgnet/html//#slightly-advanced-techniques), which
-can help with asynchronous and flexible design in the SDK, but at the added
-cost of more complexity. In our experience, the complexity is worth it, and an
-SDK implementation in any language should consider using non-blocking I/O if
-possible.
-
-#### Negotiation
-
-Once the `connect` operation succeeds, the BlazingMQ SDK will have a TCP
-connection established with the broker. The next step is for the SDK to carry
-out a handshake with the broker. This is known as *negotiation* in BlazingMQ.
-Immediately after establishing a TCP connection, the SDK sends a
-[`NegotiationMessage`](https://github.com/bloomberg/blazingmq/blob/69f0f8f5b188ca1eb07b9d262093f949729db538/src/groups/bmq/bmqp/bmqp_ctrlmsg.xsd#L1592)
-to the broker. This is a schema message, and hence needs to be encoded. See
-the [previous](#schema-messages-wire-layout) section for more details on the
-wire layout. Note that `NegotationMessage` is one of the top level schema
-messages, the other being
-[`ControlMessage`](https://github.com/bloomberg/blazingmq/blob/9b692fe25f74543e954a27e30b6b15b0ae057c8d/src/groups/bmq/bmqp/bmqp_ctrlmsg.xsd#L84).
-There is no way to discriminate between these two top level schema messages.
-It is implicit that the `NegotiationMessage` will only be used during the
-handshake phase, and every other schema message exchanged after that will be
-the top level `ControlMessage`.
-
-A `NegotiationMessage` can be one of three possible sub-types. The SDK always
-sends the
-[`ClientIdentity`](https://github.com/bloomberg/blazingmq/blob/69f0f8f5b188ca1eb07b9d262093f949729db538/src/groups/bmq/bmqp/bmqp_ctrlmsg.xsd#L1663)
-sub-type, which contains various fields as described in its documentation in
-the link.
-[Here's](https://github.com/bloomberg/blazingmq-sdk-java/blob/ed0eb848f5ac2897cfe32cc481575d689a4cb1c2/bmq-sdk/src/main/java/com/bloomberg/bmq/impl/TcpBrokerConnection.java#L355-L377)
-the relevant snippet of code from the Java SDK which populates various fields
-in `ClientIdentity`. And
-[here's](https://github.com/bloomberg/blazingmq-sdk-java/blob/ed0eb848f5ac2897cfe32cc481575d689a4cb1c2/bmq-sdk/src/test/java/com/bloomberg/bmq/it/PlainProducerIT.java#L98-L134)
-the `PlainProducerIT.java` producer doing the same thing as well as encoding
-the message and sending it over the socket to the broker.
-
-Looking at
-[`ClientIdentity`](https://github.com/bloomberg/blazingmq/blob/c8acf1b840fcd9e907d4404f43e5e687edd660f5/src/groups/bmq/bmqp/bmqp_ctrlmsg.xsd#L1708),
-one of the fields is
-[`GuidInfo`](https://github.com/bloomberg/blazingmq/blob/c8acf1b840fcd9e907d4404f43e5e687edd660f5/src/groups/bmq/bmqp/bmqp_ctrlmsg.xsd#L1646-L1661). Readers should refer to the
-documentation in header files of [`MessageGUIDGenerator`](https://github.com/bloomberg/blazingmq/blob/main/src/groups/bmq/bmqp/bmqp_messageguidgenerator.h) for more details.
-
-Once the `NegotiationMessage` has been sent, the SDK waits for the broker to
-respond with a `NegotiationMessage` of sub-type
-[`BrokerIdentity`](https://github.com/bloomberg/blazingmq/blob/69f0f8f5b188ca1eb07b9d262093f949729db538/src/groups/bmq/bmqp/bmqp_ctrlmsg.xsd#L1712).
-The `result` field in the `BrokerResponse` indicates if the BlazingMQ broker
-accepted the handshake or not, along with some other information.
-[Here's](https://github.com/bloomberg/blazingmq-sdk-java/blob/ed0eb848f5ac2897cfe32cc481575d689a4cb1c2/bmq-sdk/src/test/java/com/bloomberg/bmq/it/PlainProducerIT.java#L136-L160)
-the `PlainProducerIT.java` receiving, decoding and printing the
-`NegotiationMessage` from the broker. Note that this simple example is not
-checking the `result` field in the response. A SDK must check it though. If
-the `result` indicates failure, then the SDK must close the connection with the
-broker.
-
-### Opening a Queue
-
-Assuming that the SDK has completed a successful handshake with the broker, the
-client application will attempt to open a queue. Opening a queue from the SDK
-is a two step process (i.e., it requires two pairs of request/response
-exchanges with the broker). Both of these steps are encapsulated in the C++
-and Java SDKs by the `openQueue` API, which looks like
-[this](https://github.com/bloomberg/blazingmq-sdk-java/blob/ed0eb848f5ac2897cfe32cc481575d689a4cb1c2/bmq-sdk/src/main/java/com/bloomberg/bmq/Queue.java#L24-L34)
-in Java and like
-[this](https://github.com/bloomberg/blazingmq/blob/f4a4f55ae74caf24995ca540a0fbf70a33fbd9c3/src/groups/bmq/bmqa/bmqa_session.h#L819-L840)
-in the C++ SDK.
-
-Let's go over the two pairs of request/response exchanges which occur under the
-hood when one calls the `openQueue` API:
-
-#### `OpenQueue` Request
-
-The
-[`OpenQueue`](https://github.com/bloomberg/blazingmq/blob/69f0f8f5b188ca1eb07b9d262093f949729db538/src/groups/bmq/bmqp/bmqp_ctrlmsg.xsd#L177)
-request provides a way to the BlazingMQ client to attach to a queue.
-`OpenQueue` contains only one field:
-[`QueueHandleParameters`](https://github.com/bloomberg/blazingmq/blob/69f0f8f5b188ca1eb07b9d262093f949729db538/src/groups/bmq/bmqp/bmqp_ctrlmsg.xsd#L303). Let's look at various
-fields in this type:
-
-- `uri`: A string which contains the full BlazingMQ queue
- [`URI`](https://github.com/bloomberg/blazingmq-sdk-java/blob/main/bmq-sdk/src/main/java/com/bloomberg/bmq/Uri.java)
- to which client wants to attach.
-
-- `qId`: An integer identifier that the SDK and broker will use to identify any
- message for this queue. This integer needs to be unique only between this
- SDK client and the broker. A simple implementation would be to start with
- zero, and simply increment the value any time the client opens a new queue.
- The goal is to avoid passing the full queue URI in every message, and instead
- just use this 4-byte integer to save space on the wire.
-
-- `subQueueIdInfo`: This field's type is
- [`SubQueueIdInfo`](https://github.com/bloomberg/blazingmq/blob/9b692fe25f74543e954a27e30b6b15b0ae057c8d/src/groups/bmq/bmqp/bmqp_ctrlmsg.xsd#L364-L380).
- This type captures details about the sub-stream of the queue. **TODO**
-
-- `flags`: An integer which indicates the intent with which a BlazingMQ client
- wants to open the queue. Valid values can be found
- [here](https://github.com/bloomberg/blazingmq/blob/9b692fe25f74543e954a27e30b6b15b0ae057c8d/src/groups/bmq/bmqt/bmqt_queueflags.h#L46). Note that the `e_ADMIN` is reserved and
- should not be used.
-
-- `readCount`: An integer whose value should be one if the client wants to
- attach to the queue as a consumer, and zero otherwise.
-
-- `writeCount`: An integer whose value should be one if the client wants to
- attach to the queue as a producer, and zero otherwise.
-
-- `adminCount`: An integer whose value should always be zero.
-
-[Here](https://github.com/bloomberg/blazingmq-sdk-java/blob/ed0eb848f5ac2897cfe32cc481575d689a4cb1c2/bmq-sdk/src/test/java/com/bloomberg/bmq/it/PlainProducerIT.java#L162-L203), we
-see the `PlainProducerIT.java` creating and sending an `OpenQueue` request.
-
-Upon success, the BlazingMQ broker responds to the `OpenQueue` request by
-sending an
-[`OpenQueueResponse`](https://github.com/bloomberg/blazingmq/blob/9b692fe25f74543e954a27e30b6b15b0ae057c8d/src/groups/bmq/bmqp/bmqp_ctrlmsg.xsd#L191-L211). Let's go over the three
-fields in this type:
-
-- `originalRequest`: A field whose type is `OpenQueue`, and it simply carries
- the `OpenQueue` request sent by the client.
-
-- `routingConfiguration`: An integer which indicates information about the
- message routing strategy of the queue, as indicated by the broker. Possible
- values for the flag can be found
- [here](https://github.com/bloomberg/blazingmq/blob/9b692fe25f74543e954a27e30b6b15b0ae057c8d/src/groups/bmq/bmqp/bmqp_routingconfigurationutils.h#L51-L61).
-
-- `deduplicationTimeMs`: An integer which indicates the time interval (in ms)
- for which the SDK should keep the unacknowledged PUT messages in the
- retransmission buffer before generating a local negative acknowledgement.
- This field can be ignored in the initial implementation of the SDK.
-
-> [!NOTE]
-> For every request/response type like `OpenQueue`/`OpenQueueResponse`, the top
-> level schema message is always
-> [`ControlMessage`](https://github.com/bloomberg/blazingmq/blob/9b692fe25f74543e954a27e30b6b15b0ae057c8d/src/groups/bmq/bmqp/bmqp_ctrlmsg.xsd#L84).
-> Readers will notice that the first field in this type is `rId`, which
-> represents the request ID. Any time the SDK sends any schema message request
-> to the broker, the SDK populates `rId` field with a unique value. The broker
-> always echoes back this value in the response, which enables the SDK to
-> correlate the response back to the original request, particularly in the
-> presence of multiple concurrent pending requests. In the absence of this
-> integer, the SDK will not be able to identify the request to which the
-> response belongs. This integer can be assigned any value by the SDK, as long
-> as it is unique among all the pending requests in the SDK at that time.
-
-As mentioned before, opening a queue is a two-step process. The first one
-`OpenQueue`/`OpenQueueResponse`. Let's look at the second step. Note that a
-BlazingMQ client cannot start producing to/consuming from a queue until the
-second step is complete.
-
-#### `ConfigureStream` Request
-
-As the name suggests, the
-[`ConfigureStream`](https://github.com/bloomberg/blazingmq/blob/69f0f8f5b188ca1eb07b9d262093f949729db538/src/groups/bmq/bmqp/bmqp_ctrlmsg.xsd#L274)
-request provides a way to the BlazingMQ client to configure its "connection"
-with the queue. Note that the connection is being used logically here, and
-should not be confused with a TCP connection. This request is mostly a no-op
-for producers in the BlazingMQ backend (but the producers still need to send
-it).
-
-This request is very important for consumers in many ways:
-
-- It enables a consumer to specify one or more subscriptions.
-
-- It enables a consumer to dynamically alter its subscriptions at any time.
-
-- It enables a consumer to configure various attributes of a
- [subscription](../../features/subscriptions), like priority, [flow
- control](../../features/consumer_flow_control), etc.
-
-Now that we have a high level understanding of this request, let's dig deeper.
-
-The `ConfigureStream` request contains two fields. The first one is `qId`,
-which was explained above. The second one is
-[`streamParameters`](https://github.com/bloomberg/blazingmq/blob/9b692fe25f74543e954a27e30b6b15b0ae057c8d/src/groups/bmq/bmqp/bmqp_ctrlmsg.xsd#L287C22-L287C38).
-Let's look at the fields of this
-[type](https://github.com/bloomberg/blazingmq/blob/9b692fe25f74543e954a27e30b6b15b0ae057c8d/src/groups/bmq/bmqp/bmqp_ctrlmsg.xsd#L382-L398):
-
-- `appId`: This string contains the name of *appId*, if any, for the consumer.
- *AppId*s are specified by consumers who are attaching to a *fan-out* queue.
- Consumers of non-fan-out queues, as well as any producers don't need to
- specify any appId.
-
-- `subscriptions`: This field is an array of zero or more
- [`Subscription`](https://github.com/bloomberg/blazingmq/blob/9b692fe25f74543e954a27e30b6b15b0ae057c8d/src/groups/bmq/bmqp/bmqp_ctrlmsg.xsd#L455-L471)s.
- Each `Subscription` type contains these fields:
-
- - `sId`: This integer represents a unique identifier for this subscription.
- This integer needs to be unique only between this client and the broker. A
- simple incrementing
- [variable](https://github.com/bloomberg/blazingmq/blob/9b692fe25f74543e954a27e30b6b15b0ae057c8d/src/groups/bmq/bmqt/bmqt_subscription.cpp#L44-L49)
- can be used for generating unique `sId`s.
-
- - `expression`: This field, which is of type
- [`Expression`](https://github.com/bloomberg/blazingmq/blob/9b692fe25f74543e954a27e30b6b15b0ae057c8d/src/groups/bmq/bmqp/bmqp_ctrlmsg.xsd#L412C4-L426)
- contains the actual subscription expression as a string type as well as the
- version of the expression grammar.
-
- - `consumers`: This field is an array of type
- [`ConsumerInfo`](https://github.com/bloomberg/blazingmq/blob/9b692fe25f74543e954a27e30b6b15b0ae057c8d/src/groups/bmq/bmqp/bmqp_ctrlmsg.xsd#L428-L453),
- and represents various attributes related to a subscription.
-
-> [!NOTE]
-> As previously mentioned, opening a queue in BlazingMQ is a two-step operation
-> -- the client needs to send `OpenQueue` request, followed by
-> `ConfigureStream` request. At the API level, both of these steps should be
-> hidden by simply exposing something like `openQueue` API, similar to the
-> [C++](https://github.com/bloomberg/blazingmq/blob/9b692fe25f74543e954a27e30b6b15b0ae057c8d/src/groups/bmq/bmqa/bmqa_session.h#L819-L840)
-> and
-> [Java](https://github.com/bloomberg/blazingmq-sdk-java/blob/ed0eb848f5ac2897cfe32cc481575d689a4cb1c2/bmq-sdk/src/main/java/com/bloomberg/bmq/Queue.java#L24-L34)
-> SDKs.
-
-### Posting Messages (Producers)
-
-Let's assume that a producer application opened a BlazingMQ queue by following
-the steps mentioned in the [above](#opening-a-queue) section. The next step
-for the producer application would be to post some messages (PUT messages) on
-the queue.
-
-#### Post API
-
-Both C++ and Java SDKs support batching of messages i.e., producer application
-can send a batch of messages in one shot instead of sending them one by one.
-Batching can have a significant impact on the performance. Additionally, in
-both SDKs, the `post()` API is asynchronous i.e., the API does not wait for the
-BlazingMQ broker to respond with ACK messages. In fact, in some cases, the API
-does not write the PUT messages to the TCP socket. Instead, the SDK just
-accepts the messages, adds them to an internal buffer, and sends them later.
-This can occur if the TCP layer is enforcing some flow control, or in case the
-client is not connected to the broker, etc.
-
-Keeping the above complications aside, the simplest way to send PUT messages is
-to do what the [Java
-SDK](https://github.com/bloomberg/blazingmq-sdk-java/blob/ed0eb848f5ac2897cfe32cc481575d689a4cb1c2/bmq-sdk/src/main/java/com/bloomberg/bmq/Queue.java#L109-L115)
-does. A public class called `PutMessage` could be created, with data members
-like the payload, message properties and a callback which will be invoked by
-the SDK when it receives the ACK message for the PUT message from the broker.
-`PutMessage` could look like this (in pseudo-code):
-
-```
-class PutMessage {
- ByteArray mesasgePayload;
- MessageProperties properties;
- AckCallback ackCallback;
-}
-```
-
-Here:
-
-- `ByteArray` is, well, an array of bytes.
-
-- `MessageProperties` is a class similar to
- [this](https://github.com/bloomberg/blazingmq-sdk-java/blob/main/bmq-sdk/src/main/java/com/bloomberg/bmq/MessageProperties.java),
- with concrete implementation
- [here](https://github.com/bloomberg/blazingmq-sdk-java/blob/main/bmq-sdk/src/main/java/com/bloomberg/bmq/impl/infr/proto/MessagePropertiesImpl.java).
-
-- `AckCallback` could be similar to
- [this](https://github.com/bloomberg/blazingmq-sdk-java/blob/main/bmq-sdk/src/main/java/com/bloomberg/bmq/AckMessageHandler.java)
- Java interface.
-
-And the `post` API could look like this:
-
-```
-Result post(PutMessage msg);
-```
-
-Here, `Result` could be a custom type or enum indicating success or failure.
-Alternatively, depending upon best practices in the language, the API could
-throw.
-
-Note that we did not specify the class of which the `post` API is a data
-member of. There are at least two options here:
-
-- The `post` API can be part of a top level object like `Session` or
- `Connection`, which represent the BlazingMQ context/session/connection in the
- SDK. In this case, the API might look similar to the
- [one](https://github.com/bloomberg/blazingmq/blob/c8acf1b840fcd9e907d4404f43e5e687edd660f5/src/groups/bmq/bmqa/bmqa_session.h#L819-L840)
- in C++.
-
-- Alternatively, another approach could be similar to the
- [one](https://github.com/bloomberg/blazingmq-sdk-java/blob/ed0eb848f5ac2897cfe32cc481575d689a4cb1c2/bmq-sdk/src/main/java/com/bloomberg/bmq/Queue.java#L109-L115)
- taken by the Java SDK, where `Queue` is represented as a first class object.
-
-Yet another approach could be making a BlazingMQ `Domain` as a first class
-object, such that:
-
-- One creates a `Session`, `Connection` or `Context` object first
-- Then, one opens a `Domain` object from the top-level object
-- Then, one can open a `Queue` from the `Domain` object.
-
-#### `post` API Implementation
-
-The implementation of the `post` API should simply create a PUT event from the
-PUT message(s) specified by the application, by following guidelines
-[here](#put-event). Some other things to keep in mind:
-
-- Ensure that the queue has already been opened by the application. Since the
- application is calling `post`, it must have opened the queue with *WRITE*
- intent.
-
-- Ensure that the queue is in the process of being closed or already closed.
-
-- Ensure that the connection with BlazingMQ broker is up, and not stopping or
- disconnected.
-
-- Ensure that message payload is not empty. By policy, we don't allow other
- BlazingMQ SDKs to post empty message payloads.
-
-One of the fields in `PutHeader` is `MessageGUID`, which was described in
-previous sections. MessageGUIDs are generated in the SDK every time `post`
-API is invoked.
-
-### Processing Acknowledgement Messages (Producers)
-
-After posting one or more messages, the SDK should expect a response from the
-BlazingMQ broker in the form of an ACK (acknowledgement) message containing the
-result of the `post` operation. Multiple ACK messages can be delivered by the
-broker in one ACK event, so the SDK must be able to handle them. The wire
-layout of an ACK event was discussed in a [previous](#ack-event) section.
-
-One of the fields in ACK message is `MessageGUID`, which is used to correlate
-the ACK message to its PUT message. For example, when the application calls
-the `post` API, SDK should generate a `MessageGUID`, add it to the PUT header
-of that message before sending it, and also keep track of the `MessageGUID`
-along with any relevant information for that PUT message (e.g., the
-`AckCallback` specified by the application for that PUT message). When the ACK
-message arrives, SDK can extract `MessageGUID` from it, retrieve the
-`AckCallback` and then invoke it to deliver the result to the application.
-
-### Receiving Messages (Consumers)
-
-An application which opens a queue as a consumer (i.e., with *READ* intent)
-will receive PUSH messages from the broker anytime a new message is posted on
-the queue. Like ACK messages, PUSH messages can be delivered in a batch in a
-PUSH event, and the SDK must be ready to handle it.
-
-#### Consume API
-
-As far as handing over PUSH messages to the application is concerned, it can be
-done by asking for a callback from the application when it opens the queue, and
-dispatching PUSH messages by invoking that callback. There are various ways to
-ask applications for this callback, but the most obvious one could be in the
-`openQueue` API (or a flavor of it). For example, the Java SDK has a
-[`PushMessageHandler`](https://github.com/bloomberg/blazingmq-sdk-java/blob/main/bmq-sdk/src/main/java/com/bloomberg/bmq/PushMessageHandler.java)
-interface, which the consumer application should specify when
-[creating](https://github.com/bloomberg/blazingmq-sdk-java/blob/ed0eb848f5ac2897cfe32cc481575d689a4cb1c2/bmq-examples/src/main/java/com/bloomberg/bmq/examples/SimpleConsumer.java#L117C42-L117C42)
-a queue.
-
-Since multiple PUSH messages can appear in a PUSH event, the SDK implementation
-must be able to handle that, and it may need to dispatch PUSH messages one by
-one in the callback if the callback's signature does not support handing over
-multiple PUSH messages to the application in one go.
-
-#### Consume API Implementation
-
-The wire layout of a PUSH event was described in a [previous](#push-event)
-section. As far as implementation is concerned, the SDK logic should keep some
-of these things in mind when receiving and dispatching a PUSH event:
-
-- Ensure that the queue is still open, and not closed or being closed by the
- application.
-
-- Ensure that the PUSH event parsing passes basic sanity checks e.g., length of
- the packet is equal to the length specified in the `EventHeader`, etc
-
-- Ensure that the `queueId` field specified in the `PushHeader` is valid and
- known to the SDK
-
-### Confirming Messages (Consumers)
-
-After opening a queue, a consumer application will receive messages which are
-being posted on the queue. Some details about handling PUSH messages were
-described in the previous section. Once the consumer application processes a
-PUSH message by executing its business logic, it needs to indicate to the
-BlazingMQ backend that the message has been processed successfully and can be
-removed from the queue. This is done by the consumer application sending a
-CONFIRM message.
-
-#### ConfirmMessage API
-
-Similar to the **Post API**, C++ and Java SDKs support batching of CONFIRM
-messages i.e., consumer application can send a batch of CONFIRM messages in one
-shot instead of sending them one by one. Batching can improve performance.
-Additionally, in both SDKs, the `confirmMessage()` API is asynchronous; i.e.,
-the API may not immediately write the CONFIRM messages to the TCP socket.
-Instead, the SDK just accepts the CONFIRM messages, adds them to an internal
-buffer, and sends them later. This can occur if the TCP layer is enforcing
-some flow control, or in case the SDK is not connected to the broker, etc.
-
-Keeping above complications aside, the simplest way to send CONFIRM messages is
-to do what the [Java
-SDK](https://github.com/bloomberg/blazingmq-sdk-java/blob/ed0eb848f5ac2897cfe32cc481575d689a4cb1c2/bmq-sdk/src/main/java/com/bloomberg/bmq/PushMessage.java#L70C8-L76)
-does. Alternatively, depending upon the API design, the `confirmMessage`
-API could be part of a top level object like `Connection`, `Session`,
-`Context`, `Domain`, etc, as in the [C++
-SDK](https://github.com/bloomberg/blazingmq/blob/f4a4f55ae74caf24995ca540a0fbf70a33fbd9c3/src/groups/bmq/bmqa/bmqa_session.h#L1052-L1059).
-
-#### ConfirmMessage API Implementation
-
-The `confirmMessage` API simply needs to create and send CONFIRM message(s) to
-the broker. As explained in the [previous](#confirm-event) section, a CONFIRM
-event contains a `ConfirmHeader` followed by one or more `ConfirmMessage`.
-
-### Configuring a Queue (Standalone)
-
-The BlazingMQ client/broker protocol also supports a standalone
-*Configure Queue* request. Recall that we have already encountered this request
-in the **ConfigureStream Request** paragraph of a [previous](#opening-a-queue)
-section. Readers should refer back to that discussion for more details on this
-request.
-
-### Closing a Queue
-
-Once a client application no longer wants to produce to or consumer from a
-queue that it previously opened, it should close the queue. Closing a queue
-will not delete the queue in BlazingMQ backend. It will simply detach the
-application from the queue.
-
-Just like opening a queue, closing a queue is a two step process (i.e., it
-requires two pairs of request/response exchanges with the broker). Both of
-these steps are encapsulated in the C++ and Java SDKs by the `closeQueue` API,
-which looks like
-[this](https://github.com/bloomberg/blazingmq-sdk-java/blob/ed0eb848f5ac2897cfe32cc481575d689a4cb1c2/bmq-sdk/src/main/java/com/bloomberg/bmq/Queue.java#L78-L86)
-in Java and like
-[this](https://github.com/bloomberg/blazingmq/blob/f4a4f55ae74caf24995ca540a0fbf70a33fbd9c3/src/groups/bmq/bmqa/bmqa_session.h#L961C3-L980)
-in the C++ SDK.
-
-Let's go over the two pairs of request/response exchanges which occur under the
-hood when one calls the `closeQueue` API:
-
-#### `ConfigureStream` Request
-
-This request has been described in the previous section. When sending this
-request as part of closing a queue, any flow control and subscription
-parameters in the request are emptied out (or set to null/zero) to indicate
-that the client application is about to detach from the queue.
-
-#### `CloseQueue` Request
-
-The
-[`CloseQueue`](https://github.com/bloomberg/blazingmq/blob/58044d8e4579665fffa0419df820c8be5cdbc2eb/src/groups/bmq/bmqp/bmqp_ctrlmsg.xsd#L242-L260)
-request provides a way to the BlazingMQ client to detach from a queue.
-`CloseQueue` contains two fields. Let's look at them:
-
-- `QueueHandleParameters`: this type has been described in a previous section.
-
-- `isFinal`: this boolean flag indicates if this is the final close-queue
- request for the specified queue from the client.
-
-Upon success, the BlazingMQ broker responds to the `CloseQueue` request by
-sending a
-[`CloseQueueResponse`](https://github.com/bloomberg/blazingmq/blob/58044d8e4579665fffa0419df820c8be5cdbc2eb/src/groups/bmq/bmqp/bmqp_ctrlmsg.xsd#L262-L272).
-
-> [!NOTE]
-> The `ConfigureStream` request is sent by the SDK in three cases:
->
-> 1) As the second step in the open-queue workflow (i.e., when an application
-> calls one of the flavors of the `openQueue` APIs).
->
-> 2) As a standalone request when an application calls one of the flavors of
-> the `configureQueue` APIs.
->
-> 3) As the first step in the close-queue workflow (i.e., when application
-> calls one of the flavors of the `closeQueue` APIs).
-
-### Stopping a Session with BlazingMQ Broker
-
-When a client application decides that it no longer wants to interact with
-BlazingMQ, it can tear down its connection/session with the BlazingMQ broker.
-This typically happens when the application is shutting down, but in theory, an
-application can stop the BlazingMQ session at any time.
-
-Stopping the BlazingMQ session is typically done by calling a
-[`stop`](https://github.com/bloomberg/blazingmq-sdk-java/blob/358eda1e6ea7917e63ee6fb50d15ecd5873dbf56/bmq-sdk/src/main/java/com/bloomberg/bmq/Session.java#L512-L524)
-method on the top level Session/Connection/Context object. This method needs
-to carry out three things -- it needs to inform the broker about its intent to
-disconnect intent and wait for a response from the broker, and then finally it
-needs to close the TCP socket with the broker. Let's look into these steps in
-detail.
-
-#### `Disconnect` Request
-
-The
-[`Disconnect`](https://github.com/bloomberg/blazingmq/blob/58044d8e4579665fffa0419df820c8be5cdbc2eb/src/groups/bmq/bmqp/bmqp_ctrlmsg.xsd#L124-L134)
-request is sent by the SDK to the broker to indicate that the client about to
-close the TCP connection. This is an opportunity for the broker to clean up
-any state related to this session. Once the broker has completed the cleanup,
-it responds to this request by sending a
-[`DisconnectResponse`](https://github.com/bloomberg/blazingmq/blob/58044d8e4579665fffa0419df820c8be5cdbc2eb/src/groups/bmq/bmqp/bmqp_ctrlmsg.xsd#L136-L147).
-A guarantee provided by the broker is that once the `DisconnectResponse` has
-been sent, the broker will not send any other
-message/request/response/notification to the client. Logically, the
-*Disconnect* request/response pair can be thought of as a way to ensure that
-the "pipe" between client and broker is empty.
-
-#### Closing the TCP Connection
-
-Once the SDK receives the `DisconnectResponse`, it can proceed to close the TCP
-socket with the broker, and release any resources associated with the
-connection. Care must be taken to ensure that the resources are released in
-the right order without any dangling references or leaks.
-
----
-
-## Client Library Design Guide
-
-Apart from implementing the BlazingMQ wire protocol and the sequence of message
-exchanges between SDK and broker correctly, a good SDK should also expose easy
-to use (and hard to misuse) APIs, and should have an efficient implementation.
-In this section, we will go over some details about the SDK APIs and
-implementation which authors of a new SDK may find useful.
-
-### APIs
-
-We list some guiding principles for designing BlazingMQ client APIs:
-
-1. APIs should be designed so that they are easy to use and hard to misuse.
-
-2. APIs should provide high enough abstraction so that users can focus on
- implementing their business logic instead of trying to understand intricate
- API interactions.
- [This](https://github.com/bloomberg/blazingmq-sdk-java/blob/main/bmq-examples/src/main/java/com/bloomberg/bmq/examples/SimpleProducer.java) Java sample producer is a good
- example which demonstrates this.
-
-3. For certain higher level languages like Python, Ruby, etc., APIs can be
- opinionated and expose a minimal "surface area", which can simplify the APIs
- while also catering to the needs of the majority of users.
-
-4. For languages where people often write high performance applications, APIs
- should be asynchronous as much as possible, while also providing synchronous
- flavor in some cases.
-
-5. Overall, in our experience, BlazingMQ Java SDK provides a set of APIs which
- can be a good starting point for anyone. SDKs in higher level languages
- should aim to further simplify the Java SDK APIs, while lower level
- languages can implement something similar to Java APIs.
-
-### Implementation
-
-We list some implementation details which authors of new BlazingMQ SDKs may
-find useful:
-
-1. The network I/O logic could be made asynchronous (i.e., could use
- non-blocking sockets). This is not very important for higher level
- languages like Python, etc. but is for languages like Rust, etc.
- Non-blocking I/O can enable client applications to achieve higher
- throughput, at the cost of higher complexity of SDK implementation. One
- could leverage some well known open source libraries which make it easier to
- achieve async I/O. For example, the Java SDK uses
- [`netty`](https://github.com/bloomberg/blazingmq-sdk-java/tree/main/bmq-sdk/src/main/java/com/bloomberg/bmq/impl/infr/net)
- to achieve async I/O fairly easily.
-
-2. For SDKs which are highly asynchronous in their implementation, it can be
- difficult to reason about when multiple events are occurring concurrently.
- For example, events like a user-initiated *CloseQueue* operation, network
- disconnection with the BlazingMQ broker, and timeout of an outstanding
- *OpenQueue* request could occur at the same time, and it might become
- unreasonably difficult to reason about the code. As one of the potential
- solutions, authors may find a Finite-State Machine-based (FSM) approach easy
- to implement and reason about. In this approach, all states, state
- transitions, events and actions can be codified in the form of enums,
- callbacks, etc. Any incoming or outgoing event (initiated by any entity
- like the user, timer, network, etc) on the queue or the top level session
- object can be applied to the appropriate FSM (queue or session), and desired
- outcome (state transition) and action can be dispatched from the FSM table.
- As an example, the C++ SDK takes this approach (but only partially) by
- introducing concepts like:
-
- - [`QueueFSM`](https://github.com/bloomberg/blazingmq/blob/58044d8e4579665fffa0419df820c8be5cdbc2eb/src/groups/bmq/bmqimp/bmqimp_brokersession.h#L456)
-
- - [`QueueFsmEvent`](https://github.com/bloomberg/blazingmq/blob/58044d8e4579665fffa0419df820c8be5cdbc2eb/src/groups/bmq/bmqimp/bmqimp_brokersession.h#L257)
-
- - [`QueueStateTransition`](https://github.com/bloomberg/blazingmq/blob/58044d8e4579665fffa0419df820c8be5cdbc2eb/src/groups/bmq/bmqimp/bmqimp_brokersession.h#L320)
-
- - [`SessionFsm`](https://github.com/bloomberg/blazingmq/blob/58044d8e4579665fffa0419df820c8be5cdbc2eb/src/groups/bmq/bmqimp/bmqimp_brokersession.h#L365)
-
-3. Testability of the SDK should be kept in mind, and all classes which are
- mechanisms should ideally be an interface so that they can be mocked easily.
-
----
diff --git a/docs/docs/architecture/clustering.md b/docs/docs/architecture/clustering.md
deleted file mode 100644
index e2e085c82..000000000
--- a/docs/docs/architecture/clustering.md
+++ /dev/null
@@ -1,390 +0,0 @@
----
-layout: default
-title: Clustering
-parent: Architecture
-nav_order: 2
----
-
-# BlazingMQ Cluster, Storage and Replication
-{: .no_toc }
-
-* toc
-{:toc}
-
-## Introduction
-
-This article provides a high level overview of clustering, replication and
-storage subsystems in BlazingMQ.
-
-## Clustering
-
-Like several other distributed storage systems, BlazingMQ stores messages by
-leveraging a cluster of commodity machines in order to provide redundancy and
-high availability. BlazingMQ clusters can be anywhere from 3-7 machines in
-size. Smaller as well as larger sized clusters are possible but not
-recommended. In practice, clusters with 5 nodes are ideal.
-
-### Typical Deployment
-
-
-
-The above figure shows the typical deployment of BlazingMQ. The four nodes in
-the middle represent a BlazingMQ cluster where queues are persisted and
-replicated. The blue node in the cluster represents a queue's **primary**
-node, which is in charge of managing the queue (replication, message routing,
-etc.). Orange nodes represent **replicas** which, as the name suggests, are in
-charge of storing a local copy of the queue.
-
-A producer or consumer client application can connect to any node in the
-BlazingMQ cluster instead of always requiring a connection to the primary node.
-If a client application connects to a replica node, the replica will
-automatically make the primary node aware of the client application. It also
-means that all messages flowing to and from the client application will go
-through the replica.
-
-### Alternative Deployment
-
-
-
-The above figure shows an alternative deployment of BlazingMQ. As can be seen,
-the applications (green nodes) running on machines A and B connect to local
-BlazingMQ agents (yellow nodes), which then connect to any node (primary or
-replica; blue or orange nodes) in the BlazingMQ cluster. These local BlazingMQ
-agents are known as **proxies**. See [*Benefits of Proxy*](#benefits-of-proxy)
-section below for more details.
-
-Proxies are optional in BlazingMQ deployments and should be used only if their
-presence is required for performance reasons. If you are just starting with
-BlazingMQ, we recommend skipping proxy-aware deployment.
-
-### Multi Hop Topology
-
-An interesting aspect of BlazingMQ network topology that is obvious from the
-above figure is that client applications don't need to directly connect to a
-queue's primary node. There can be any number of hops between an application
-and the primary node. In this example, clients connect to the local BlazingMQ
-proxy running on their machines, which in turn may connect to a replica node in
-the cluster. In fact, a BlazingMQ proxy can connect to another BlazingMQ
-proxy, and so on. Moreover, clients don't have to connect to the local proxy.
-They can connect to a remote proxy cluster, which in turn connects to the
-BlazingMQ cluster hosting the queues, etc. The BlazingMQ network topology is
-very flexible in this regard, and generally speaking, a queue's primary node
-builds a distribution tree rooted at itself, with replicas and proxies at
-intermediate levels in the tree, and producers and consumers at leaf nodes.
-Please see the [*Network Topology*](../network_topology) article for an
-in-depth discussion as well as to see how its topoloy enables BlazingMQ to
-achieve very high fan-out and tremendous bandwidth savings in certain
-scenarios.
-
-### Benefits of Proxies
-
-A local BlazingMQ proxy can provide several benefits:
-
-- It hides applications from any changes in the cluster's composition as well
- as transient network issues. For example, the entire BlazingMQ cluster could
- disappear from the network for a few minutes, and the proxy will hide this
- event from the applications by simply buffering any new messages being sent
- by the producer applications and retransmit them when conditions improve.
- Applications won't get any *DISCONNECTION* events.
-
-- It aggregates all local TCP connections into just a few connections to
- clusters, which allows for a large number of local clients, and also reduces
- fail-over times for cluster nodes.
-
-- Lastly, and arguably most importantly, the proxy carries out fan-out closer
- to the user applications. Imagine a scenario where there are *N* consumer
- applications running on a machine and *all* applications are interested in
- receiving messages posted on a queue. In the absence of the proxy, BlazingMQ
- cluster would have to send a message *N* times to this machine. However, due
- to the proxy's presence, the message is sent only once by the BlazingMQ
- cluster to the local proxy. This local proxy then carries a local fan-out to
- *N* consumer applications, thereby dramatically increasing scalability and
- performance, and reducing latency and bandwidth requirements for such
- scenarios.
-
-### Quorum based System
-
-BlazingMQ is a quorum based system, which means that as long as the majority of
-the nodes in a BlazingMQ cluster are available, the system will be available to
-users. Quorum is required for two reasons -- to maintain continued leadership
-in the cluster as well as to provide strong consistency in storage replication.
-Both of these concepts are explained later in this article as well as in
-[this](../election_rsm) document.
-
-At a high level, a BlazingMQ cluster manages two types of information -- its
-own metadata and the queues (to be specific, messages across various queues).
-Let's look deeper into each of them.
-
-### Cluster Metadata
-
-Unlike some other distributed systems that depend on a metadata stores like
-Apache ZooKeeper to manage their metadata, a BlazingMQ cluster hosts its own
-metadata. The decision to manage metadata within a BlazingMQ cluster was made
-very early in the design phase of BlazingMQ, for mainly two reasons --
-minimizing dependencies on external software and having flexibility around
-metadata management as far as deployment, performance and future enhancements
-are concerned.
-
-Metadata is managed by one node in the cluster, known as the leader node, while
-other cluster nodes simply follow the leader node. The leader node is solely
-responsible for issuing writes to the metadata, persisting it locally, and also
-replicating it to peer nodes ("followers"), which it does by implementing a
-replicated state machine similar to (but not exactly same as) the
-[*Raft*](https://raft.github.io) consensus algorithm. More details on this
-topic can be found [here](../election_rsm).
-
-Metadata in a BlazingMQ cluster comprises of:
-
-- The cluster's health and cluster membership.
-
-- A list of queues being hosted on the cluster.
-
-- Details about internal *storage shards* configured in the cluster. More
- details about *storage shards* can be found in the *Storage* section later in
- this document. For now, a shard can be assumed to be a logical file on disk.
- The number of *storage shards* in a BlazingMQ cluster is configured
- statically.
-
-- *Storage Shard* -> Primary node mapping. Each *storage shard* is managed by
- a node in the cluster, known as the primary node for that shard. A shard is
- assigned a primary node by the leader at startup or anytime a shard loses its
- primary node. Note that the leader node can assign itself as the primary
- node of some or all *storage shards* depending upon the configuration.
-
-- Queue -> shard mapping. Any time a queue gets created in a BlazingMQ
- cluster, the leader node assigns that queue to a *storage shard*. Similarly,
- any time a queue qualifies to be garbage-collected, the leader node removes
- it from the cluster state.
-
-- Any internal queue identifiers, and other miscellaneous details.
-
-Note that cluster metadata does not include contents of the queues.
-
-### Queues
-
-Another type of information maintained by a BlazingMQ cluster is the messages
-across various queues.
-
-Any time a new queue comes into existence in a BlazingMQ cluster, the leader
-node assigns it to an internal *storage shard*. From that point onwards, the
-primary node assigned to that *storage shard* is in charge of managing the
-queue. A primary node carries out things like:
-
-- Receiving all messages arriving on the queue.
-
-- Persisting messages locally and replicating them to the replica nodes.
-
-- Acknowledging messages back to the producer applications at the appropriate
- time.
-
-- Choosing the right set of consumers to route newly arriving messages. This
- can involve determining consumers' current capacities, consumers' priorities,
- any filtering criteria specified by consumers, etc.
-
-- Bringing a replica node which was recently (re)started up to date by
- synchronizing its *storage shards* so that it has the latest messages.
-
-### Summary of Nodes' Roles
-
-With the concepts of leader, follower, primary and replica nodes introduced
-above, it is worth summarizing them here:
-
-- **Leader**: A node in a BlazingMQ cluster is elected as leader with a quorum
- based election algorithm. This node is in charge of managing BlazingMQ
- cluster metadata and replicating it to follower nodes, in addition to
- maintaining it in memory. Every leader node gets assigned a unique,
- monotonically increasing number called the *term*.
-
-- **Follower**: A node which maintains a local copy of the metadata (in memory
- as well as on disk) and updates it upon receiving notifications from the
- leader node. By default, all nodes apart from the leader node in a BlazingMQ
- cluster become follower nodes and maintain metadata.
-
-- **Primary**: A node which manages a *storage shard* in a BlazingMQ cluster
- and replicates it to the peer nodes (replicas). The leader node manages the
- *storage shard* <-> primary node mapping. The leader node typically assigns
- a primary node to a *storage shard* at startup or when an existing primary node
- goes away (crash, graceful shutdown, removal, etc). The leader node can
- assign itself as the primary node of one or more *storage shards*. Every
- primary node gets assigned a monotonically increasing number by the leader
- called the *PrimaryLeaseId*.
-
-- **Replica**: A node which maintains a local copy of the *storage shard* and
- updates it upon receiving notifications from the primary node. All nodes
- apart from the primary node become replicas of that *storage shard*.
-
-The following combinations of roles are valid for a BlazingMQ node:
-
-- A node can be the leader and the primary of one or more *storage shards* and
- a replica of the remaining *storage shards*.
-
-- A node can be a follower and the primary of one or more *storage shards* and
- a replica of the remaining *storage shards*.
-
-- A node can be the leader and a replica of all *storage shards*.
-
-- A node can be a follower and a replica of all *storage shards*.
-
----
-
-## Replication
-
-As mentioned above, the leader node is in charge of replicating cluster
-metadata to other nodes in the cluster, and the primary node of each *storage
-shard* is in charge of replicating the shard to other nodes. It is worth
-pointing out that primary nodes are not elected but assigned by the leader
-node.
-
-Every node in the BlazingMQ cluster has a full copy of cluster metadata as well
-as every *storage shard*. In other words, nodes are homogeneous.
-
-An interesting corollary of the above fact is that adding more nodes in a
-BlazingMQ cluster increases availability of the system, but it does not
-increase the cluster's capacity. In fact, clients may observe lower throughput
-because now the primary node has to carry out additional replication to the new
-node.
-
-Each *storage shard* has its own independent logical stream of replication,
-which, among other things, includes sequence numbers for every packet
-replicated by the primary node. These sequence numbers are used by the replica
-nodes to ensure that they stay in sync with the primary node, as well as to
-request any missing parts of the stream at startup or in the event of a primary
-node change. Nodes in a BlazingMQ cluster maintain only one TCP connection
-with each other, and replication for all *storage shards* occurs over that
-connection.
-
-
-### Eventual vs Strong Consistency in Replication
-
-Upon receiving a new message from the producer, the primary node writes it to
-its local storage and replicates it. Depending upon a queue's static
-configuration, the primary node may or may not wait for acknowledgements from
-replica nodes before returning the result back to the producer. If the queue
-is configured in eventual consistency mode, the primary node will not wait for
-acknowledgements from replicas with the hope that replicas will eventually
-receive the message and apply it locally.
-
-On the other hand, if the queue is configured in strong consistency mode, the
-primary node will wait for acknowledgements from a certain number of replicas
-before returning results to the producer. The number of replicas is chosen in
-such a way that ensures that a majority of the nodes have a copy of the message
-before returning results to the producer.
-
-Needless to say, while eventual consistency may provide lower latency, it comes
-at the risk of potential message loss. Consider a scenario where the primary
-node crashes right after returning a "success" result to the producer, but the
-replicated message is still sitting somewhere in its memory or socket buffer,
-waiting to be sent to the replicas. In this case, one of the replicas will be
-promoted as a primary node by the leader node and neither the new primary node
-nor other replicas will have the message, leading to message loss even though
-the producer received a success notification from the previous primary node.
-
-We do not recommend using eventual consistency mode unless you can tolerate
-message loss. By default, all queues are configured to be strongly consistent.
-
----
-
-## Storage
-
-Now that we know about high level concepts of clustering and replication in a
-BlazingMQ cluster, it's time to look into the details of the storage layer and
-understand how BlazingMQ message brokers interact with local disk.
-
-### Storage Shard
-
-A BlazingMQ cluster divides storage into shards, and distributes queues across
-these shards. A shard is also known as *partition* in BlazingMQ. A shard can
-be thought of as a logical file on disk (see next section for details). A
-shard is an internal detail of BlazingMQ and users don't need to know about it.
-Every BlazingMQ cluster is statically configured with a number of shards as
-well as the total storage capacity of each shard. The number or size of shards
-cannot be changed at runtime and requires a broker restart. The number and
-size of the shards is chosen considering the total storage capacity as well
-as total anticipated number of queues that the cluster will host. Typically,
-the number of shards is much less than the total number of queues hosted on a
-cluster. For example, having less than 50 shards for a cluster which is
-hosting 10,000+ queues is normal. Every node in a BlazingMQ cluster has full
-knowledge (and a full copy) of all the shards.
-
-### Storage Shard Internals
-
-Until now, a storage shard has been described as a logical file on disk. To be
-specific, a shard is a collection of two regular physical files on the
-filesystem -- a *JOURNAL* file and a *DATA* file.
-
-A JOURNAL file is, well, a journal of events. All events, like the arrival of
-a message in a queue, confirmation of a message by a consumer, deletion of a
-message, creation of a queue, deletion of a queue, etc., are recorded in the
-journal. The DATA file is used to store the actual messages themselves.
-
-Let's walk through an example -- when a message arrives from a producer for a
-queue at the queue's primary node, it identifies the shard to which a queue has
-been mapped, and "routes" the message to that shard ("routing" implies handing
-over the message to the correct subsystem or thread). The shard copies the
-message payload to the DATA file, and creates a *MessageRecord* in the JOURNAL
-file. One of the fields in the *MessageRecord* is the offset of the message in
-the DATA file, which can be used to retrieve the message later. At some time
-after writing the message to the files, the primary node replicates it to the
-replicas, which then update their DATA and JOURNAL files of the same shard with
-the message payload and *MessageRecord* respectively. And some time after
-that, the primary node replies to the producer with an acknowledgement.
-
-BlazingMQ carries out strictly sequential writes to the JOURNAL and DATA files
-for performance purposes. In addition, files are memory-mapped, although this
-can change in the future. Memory mapping the files brings certain advantages
-like avoiding system calls during read/write operations and easier file offset
-management. On the other hand, it can pollute the page cache and also
-introduce some unpredictability in latency due to page cache misses. BlazingMQ
-message brokers do not flush memory-mapped files to disk and rely on the
-operating system to periodically flush dirty pages to disk. While in theory
-this exposes a crashed node to data loss, in practice this does not happen.
-Upon restart, the crashed node synchronizes its storage with peer nodes in the
-cluster before going "live". Failure of an entire cluster simultaneously could
-indeed result in the loss of committed data, though at Bloomberg we defend
-against this with a truly shared nothing architecture.
-
-### JOURNAL File Details
-
-As mentioned above, a JOURNAL file contains relevant storage events. These
-events are written to the JOURNAL file in the form of various fixed length
-records (structs). Types of records:
-
-- *MessageRecord*: Record containing details about a message, like message
- GUID, queue name, time of arrival of message, CRC32C checksum, offset to
- message payload in the DATA file, etc.
-
-- *ConfirmRecord*: Record containing details about confirmation of a message by
- a consumer, like consumer ID (if any), message GUID, queue name, time of
- confirmation, etc.
-
-- *DeletionRecord*: Record containing details about deletion of a message, like
- message GUID, queue, reason of deletion (processed by all consumers,
- garbage-collected due to TTL expiration, purged due to poison pill detection,
- etc).
-
-- *QueueOpRecord*: Record containing details about any queue related operations
- like queue creation, deletion, modification, etc.
-
-- *JournalOpRecord*: A meta record containing periodic markers from the primary
- node in the replication stream, etc.
-
-Every JOURNAL record is 60 bytes in length. Having fixed length records helps
-with bidirectional traversals and scans of records during storage recovery
-phase at broker startup as well as when the primary node needs to heal a
-recently started replica.
-
-
-### DATA File Details
-
-DATA files are simpler than JOURNAL files, because they just contain message
-payload records. Each record starts with a header describing the message
-payload record. Note than unlike the JOURNAL file, records in the DATA file
-are of variable length.
-
-More details about BlazingMQ's storage protocol can be found in the
-[`mqbs_filestoreprotocol.h`](https://github.com/bloomberg/blazingmq/blob/main/src/groups/mqb/mqbs/mqbs_filestoreprotocol.h)
-header file. This file contains definitions of all the `struct`s as they are
-laid out on disk. To ensure consistency, data is written to disk in network
-byte order.
-
----
diff --git a/docs/docs/architecture/election_rsm.md b/docs/docs/architecture/election_rsm.md
deleted file mode 100644
index 2851028b9..000000000
--- a/docs/docs/architecture/election_rsm.md
+++ /dev/null
@@ -1,438 +0,0 @@
----
-layout: default
-title: Leader Election
-parent: Architecture
-nav_order: 6
----
-
-# Leader Election and State Machine Replication in BlazingMQ
-{: .no_toc }
-
-* toc
-{:toc}
-
-## Summary
-
-This articles introduces readers to the leader election algorithm in BlazingMQ.
-The article explains the motivation for having a **leader** node in a given
-BlazingMQ cluster, and then goes on to explain the leader election algorithm
-implementation, which is inspired by the algorithm proposed in the
-[*Raft*](https://raft.github.io/) consensus protocol. The article also
-discusses an extension to the leader election algorithm (what Raft refers to as
-*PreVote*), which helps BlazingMQ's leader election implementation achieve
-stability during network disruptions. Note that *Raft* is a state machine
-replication algorithm, and indeed, BlazingMQ's replication model is also
-inspired by it, although with some important differences. This article
-primarily focuses only on BlazingMQ's leader election algorithm, and explains
-state machine replication only briefly. Similarly, differences with *Raft* are
-discussed briefly.
-
----
-
-## Introduction
-
-Before we jump into the nitty-gritty of the leader election algorithm, let's
-first look at why some distributed systems like BlazingMQ need a node in their
-clusters to act as a coordinator or "leader".
-
-A distributed system often needs to carry out some bookkeeping and management
-of its workload as well as nodes in the cluster. These responsibilities can
-take various forms for different distributed systems, including but not limited
-to:
-
-- Keeping an eye on the health of nodes in the cluster (e.g., demoting an
- unhealthy node, synchronizing a newly joined node, etc.)
-
-- Distributing work across nodes in the cluster (e.g., assigning a primary node
- to a stream of data, distributing ranges of keys across nodes in the cluster,
- etc.)
-
-- Storing and replicating any metadata required to bootstrap the cluster upon
- restart
-
-In order to avoid conflicting decisions, only one node in the cluster (the
-"leader") should be authorized to carry out such work, while other nodes (the
-"followers") must honor the decisions made by the leader node.
-
-It is worth noting that not all distributed systems require a leader node to
-work. In such systems, each node can act as a coordinator for a request that
-it receives from the user. Such systems are out of the scope of this article.
-
-### Responsibilities of the Leader Node in BlazingMQ
-
-At this point, it is worth discussing the role of a leader node in BlazingMQ
-cluster. A BlazingMQ leader node performs the following responsibilities:
-
-- **Managing Cluster Metadata**: A BlazingMQ cluster hosts its metadata itself,
- instead of relying on an external metadata store like *Apache ZooKeeper*,
- *etcd*, etc. It is the responsibility of the leader to store and replicate
- metadata among nodes in the cluster. See [*Cluster
- Metadata*](../clustering#cluster-metadata) section for more details about
- metadata.
-
-- **Synchronizing New Nodes**: The leader node is also in charge of bringing a
- new node (which just restarted or joined the BlazingMQ cluster) up to date
- with cluster's metadata and other information which helps the new node catch
- up with other nodes.
-
-- **Checking the Health of Peer Nodes**: Leader node keeps an eye on the health
- of peer nodes, and may choose to assign another node as the primary upon
- detecting a failing or crashed primary node.
-
----
-
-## The Leader Election Algorithm in BlazingMQ
-
-As mentioned previously, a BlazingMQ cluster elects a node as the leader which
-acts as a coordinator for the cluster's metadata and healthiness of nodes. The
-leader node maintains a replicated state machine to ensure that the cluster's
-metadata is persisted at the majority of the nodes. This section explains the
-leader election algorithm at a high level. It is by no means exhaustive and
-deliberately avoids any formal specification or proof. Readers looking for an
-exhaustive explanation should refer to the *Raft*
-[paper](https://raft.github.io/raft.pdf), which acts as a strong inspiration
-for BlazingMQ's leader election algorithm.
-
-### Naïve Leader Election Algorithm
-
-Instead of jumping into the final version of algorithm, let's try to write one,
-starting from something simple. Here's our first attempt:
-
-1. When a node in the BlazingMQ cluster detects the absence of a leader, it
- proposes election by sending an `ElectionProposal` request to the peer
- nodes.
-
-2. Peers can respond to the `ElectionProposal` request with a *yes* or a *no*,
- depending upon their elector state machine.
-
-3. If the proposing node gets support from the majority of the peer nodes, it
- becomes the leader. Here, majority would mean `N/2 + 1`, where `N` is the
- total number of nodes in the cluster. Enforcing quorum ensures that at any
- given time, there is no more than one leader in the BlazingMQ cluster.
-
-4. New leader starts sending periodic heartbeats to the peers ("followers").
-
-5. Follower nodes periodically check for heartbeats from the leader. If a
- configured number of consecutive heartbeats are missed, then the follower
- may assume that the leader node has disappeared, and may decide to propose
- an election immediately or after some time.
-
-
-### Problems with the Naïve Algorithm
-
-While the above algorithm looks reasonable enough, it has several problems:
-
-- **Concurrent Election Proposals**: It cannot handle concurrent election
- proposals. Let's say the two follower nodes notice that the leader has
- disappeared, and decide to propose an election at the same time. As a
- result, other nodes would receive multiple election proposals, one from each
- of the nodes proposing an election. How should a node decide which proposal
- to respond to with a *yes* and which one with a *no*?
-
-- **Unneeded Election Proposals**: It cannot handle unneeded election
- proposals. Let's say a follower node already views a node as the leader, but
- then receives an election proposal from another node. Should the follower
- node continue to follow the original leader, or should it support the second
- one? What if the second one has more up-to-date information? There is no
- way for the follower node to figure that out from the proposal.
-
-- **Stale Leader Detection**: It cannot detect a stale leader. Let's say a
- follower node already views a node as the leader, but then starts receiving
- leader heartbeats from another node as well. How does the follower node
- determine which of the two leaders is the stale one?
-
-- **Ordering Leader Updates**: It cannot help nodes to order updates published
- by the leader. Given two updates, there is no way to figure out which update
- originated from an old leader and which one from a new leader.
-
-
-### Introducing Election *Term*
-
-All of the above problems can be solved by introducing a monotonically
-increasing integer in our election algorithm. Here are the details:
-
-- Every message exchanged within the algorithm (e.g., `ElectionProposal`,
- `ElectionProposalResponse`, `LeaderHeartbeat`, etc) will contain an integer.
-
-- Every node will maintain its own copy of the integer.
-
-- A node will *always* honor an election request/notification/heartbeat message
- if the message contains a higher value for this integer than its own copy
- (and will also update its own copy with the higher value).
-
-This integer can be thought of as a logical clock, a generation count, a
-fencing token, or as *Raft* calls it: an election *term*.
-
-
-### Updated Algorithm using Term
-
-Here's the updated algorithm which now uses a term:
-
-1. When a node in the BlazingMQ cluster detects the absence of a leader, it
- proposes an election by sending an `ElectionProposal` request to the peer
- nodes containing `proposedTerm == ++selfTerm`.
-
-2. A peer node responds to `ElectionProposal` with a:
-
- - *Yes* if `proposedTerm > peer's selfTerm`, and also updates `selfTerm =
- proposedTerm`.
-
- - *No* if `proposedTerm <= peer's selfTerm`
-
-3. If the proposing node gets support from the majority of the peer nodes, it
- transitions to leader (at this point the leader's `selfTerm ==
- proposedTerm`).
-
-4. The new leader starts sending periodic heartbeats to the peers
- ("followers"). Every `Heartbeat` message contains the leader's term.
-
-5. Follower nodes periodically check for heartbeats from the leader and ensure
- that `selfTerm == term in heartbeat message`. If a configured number of
- consecutive heartbeats are missed, then follower may assume that the leader
- node has disappeared.
-
-Additional notes on elector term:
-
-- One can see that every leader will have a unique term associated with it, and
- a newer leader will have a higher term than the previous leader. This can
- help followers detect and ignore stale leaders.
-
-- A leader can also use its term to create composite sequence numbers to be
- used in any application-level messages sent by the leader. These sequence
- numbers can be of the form *(Term, Counter)* where *Counter* is an integer
- starting from zero for every new leader. In BlazingMQ, these composite
- sequence numbers are referred to as *Leader Sequence Numbers* or *LSNs*. So
- a leader with a term of 5 can issue messages with LSNs *(5, 1)*, *(5,2)* and
- so on. LSNs can also be used to order messages from the leader as well as to
- ignore messages from stale leaders. For example, a message LSN *(5, 2)* is
- newer than a message with LSN *(4, 1000)*.
-
-- Lastly, what *Raft* refers to as a term is referred to as *view*, *ballot
- number*, *proposal number*, *round number*, *epoch*, etc by other similar
- systems like *Paxos*, *Apache ZooKeeper* etc. Moreover, what we refer to as
- *Leader Sequence Number* in BlazingMQ is referred to as *Log Sequence
- Number*, *ZXID*, etc by other systems.
-
-
-### Elector State Machine
-
-At a given time, every participating node can be in one of the three states:
-
-- *FOLLOWER*: a follower node is not the leader and has not proposed an
- election. It may or may not be aware of the leader.
-
-- *CANDIDATE*: a candidate node is not the leader, but has a pending election
- proposal.
-
-- *LEADER*: a leader node is one which currently enjoys support of the majority
- of the nodes in the cluster.
-
-Some general notes on these elector states:
-
-- A node always starts as a *FOLLOWER* with `selfTerm = 0`. Upon start up, the
- node waits a configured amount of time in order to discover the existing
- leader, if one exists.
-
-- A *FOLLOWER* node will transition to *CANDIDATE* and propose an election if
- it cannot find a leader node in the configured time.
-
-- A *CANDIDATE* waits for a configured amount of time to hear from all or the
- majority of its peers for its election proposal.
-
-- If a *CANDIDATE* receives an election proposal or a heartbeat with higher
- term, the *CANDIDATE* transitions back to *FOLLOWER* and supports the node
- with higher term.
-
-- Similarly, if a *LEADER* receives an election proposal or a heartbeat with
- higher term, it transitions back to *FOLLOWER* and supports the node with
- higher term.
-
-A node will *always* honor an election proposal or heartbeat message with
-higher term, irrespective of its role.
-
-### Elector Algorithm: Node Startup Scenario
-
-Let's walk through a common scenario where a node starts up and joins the peers
-participating in the election:
-
-1. The new node starts up as a *FOLLOWER* with `selfTerm = 0` and waits for the
- configured amount of time to discover the existing leader, if any.
-
-2. If the node discovers a leader via heartbeat messages, it updates `selfTerm
- = leaderTerm`, and also sends an unsolicited `ElectionProposal` response to
- the leader node, letting it know that it supports the leader.
-
-3. If the node does not find the leader node, it waits for some additional time
- (random interval between 0-3 seconds) before transitioning to a *CANDIDATE*
- and proposing an election with `++selfTerm`. The reason for waiting a
- random time interval before proposing an election is explained in the third
- bullet of the next section.
-
-
-### Elector Algorithm: Leader Crash Scenario
-
-Let's walk through another common scenario where the leader node crashes or
-stops gracefully:
-
-1. Once a *FOLLOWER* node starts following a *LEADER* node, it schedules a
- periodic event to check for heartbeat messages from the leader.
-
-2. If three consecutive heartbeats are missed, the follower waits for a random
- time interval (between 0-3 seconds) before proposing an election with
- `++selfTerm`.
-
-3. The additional random wait interval prevents multiple *FOLLOWER* nodes from
- proposing elections simultaneously. This helps to avoid failed election
- proposals, which helps with faster convergence to elect a new leader.
-
-
-### Differences from *Raft*'s Consensus Algorithm
-
-BlazingMQ's leader election and state machine replication differs from that of
-*Raft* in one way: in *Raft*s leader election, only the node having the most
-up-to-date log can become the leader. If a follower receives an election
-proposal from a node with stale view of the log, it will not support it. This
-ensures that the elected leader has up-to-date messages in the replicated
-stream, and simply needs to sync up any followers which are not up to date. A
-good thing about this choice is that messages always flow from leader to
-follower nodes.
-
-BlazingMQ's elector implementation relaxes this requirement. Any node in the
-cluster can become a leader, irrespective of its position in the log. This
-adds additional complexity in that a new leader needs to synchronize its state
-with the followers and that a follower node may need to send messages to the
-new leader if the latter is not up to date. However, this deviation from
-*Raft* and the custom synchronization protocol comes in handy because it allows
-BlazingMQ to avoid flushing (`fsync`) every message to disk. Readers familiar with
-Apache Kafka
-[internals](https://jack-vanlightly.com/blog/2023/4/24/why-apache-kafka-doesnt-need-fsync-to-be-safe)
-will see similarities between the two systems here.
-
-An additional benefit of this deviation is the case when we specifically want a
-particular node to become leader for testing, troubleshooting, or simulating
-disaster recovery scenarios. On some occasions, the target node could be
-behind in the replicated state machine, and would not be elected as the leader
-in the original *Raft* algorithm.
-
----
-
-## Extending the Leader Election Algorithm
-
-In the previous sections, we discussed a couple of scenarios (node start and
-leader crash) and saw how the election algorithm handles them well. Let's
-discuss a couple of scenarios where the BlazingMQ algorithm could do better.
-
-### Non-sticky Leader
-
-
-
-The figure above demonstrates a setup where there are 4 nodes in a cluster. In
-the absence of any disturbance, all 4 nodes connect to each other over TCP,
-creating full mesh. However, let's assume that due to network disruption, node
-B gets isolated from the other 3 nodes. Let's also assume that node A is the
-leader with a term of 10. Note that even after node B gets isolated, node A
-continues to enjoy support of the majority of the nodes in the cluster and thus
-continues to be the leader as perceived by itself and nodes C and D.
-
-However, since node B is isolated, it cannot see node A and its elector state
-machine eventually transitions to *CANDIDATE*, bumps up it's local term to 11
-and proposes an election. Inevitably, this election round fails after a
-timeout. Node B then waits for random time interval and proposes an election
-yet again, this time with a term of 12, which fails yet again. The cycle
-continues and node B's term keeps on incrementing with every failed election.
-
-Now, let's assume that network heals and node B is no longer isolated from its
-peers. Node B will eventually receive heartbeats from node A with a term of
-10, which node B will ignore since its own term is higher than that.
-Additionally, node B will propose an election with a term higher than 10.
-Nodes A, C, and D, upon receiving this proposal, will support node B because of
-higher term in the proposal, and node A will transition from *LEADER* to
-*FOLLOWER*. Eventually, node B will transition to *LEADER* with the other 3
-nodes following it.
-
-While our algorithm works correctly (at a given time, there is only one leader)
-one can see that there was an unnecessary leadership switch from node A to node
-B. It would be ideal if node A continued to be the leader, with node B simply
-following it upon re-joining the cluster.
-
-### Leader Ping-Pong
-
-
-
-The figure above demonstrates another scenario which is more disruptive than
-the one discussed in the previous section.
-
-In this scenario, let's assume that node A is the leader with a term of 10 with
-the other three nodes following it. Then, due to a network disturbance, let's
-assume that node B gets disconnected from node A, while still being connected
-to nodes C and D.
-
-In this scenario, node B will detect the dropped connection (or missed leader
-heartbeats) from node A, and will eventually transition to *FOLLOWER* and then
-become a *CANDIDATE* and propose an election with term 11. Node A will not
-receive this proposal, but nodes C and D will, and both of them will support
-node B because of higher term in the election proposal. Node B will get
-support from the majority of the nodes and will transition to *LEADER*.
-
-Node A will come to know that nodes C and D no longer support it as the leader
-when it receives an `InvalidHeartbeat` message from one or both of them with
-the latest term (11). Node A will transition to *FOLLOWER*, and since it
-cannot see the current leader (node B), it will propose an election with a term
-of 12. Again, nodes C and D will support this election, and node A will end up
-being the leader with a term of 12.
-
-The cycle will repeat with node B becoming a leader with a term of 13, then
-node A becoming a leader with a term of 14, and so on. Leadership will keep
-bouncing between nodes A and B. While at a given time, there will be only one
-leader, this scenario can be extremely disruptive for an application.
-
-### Solution: The `ElectionScouting` Request
-
-The problems of *non-sticky leaders* and *leader ping-pong* discussed above can
-be solved by introducing an `ElectionScouting` request (*Raft* calls this as
-*PreVote* request):
-
-1. A node, instead of sending an `ElectionProposal` request with `proposedTerm
- = ++selfTerm`, sends an `ElectionScouting` request with `proposedTerm =
- selfTerm + 1`. In other words, the node specifies an incremented term in
- the `ElectionScouting` request but *does not* bump up its own term. For
- example, a node with term 10 will specify term 11 in `ElectionScouting`
- request. Logically, an `ElectionScouting` request asks this question to the
- peer nodes: *"If I were to propose an election with the specified term, will
- you support me?"*.
-
-2. A node which receives `ElectionScouting` request responds as per this logic:
- - If it already perceives another node as the leader, it responds to the
- `ElectionScouting` request with a *No*.
- - If it does not perceive any node as the leader, it responds with a *Yes*
- if `selfNode < proposedNode`, otherwise a *No*.
-
-Introducing the `ElectionScouting` request ensures that a node does not
-needlessly bump up its own term every time it proposes an election, without
-even knowing if peers will support its proposal or not.
-
-Additionally, the logic in second bullet ensures that if a peer is already
-aware of a leader, it will not honor an `ElectionScouting` request from another
-node, even if the request contains a higher term. Note that the rule of
-honoring a message with higher term still applies to all other
-requests/notifications/heartbeats, except for `ElectionScouting` requests.
-
-Readers will notice that the two enhancements above ensure that the election
-algorithm is no longer susceptible to the *non-sticky leader* and *leader
-ping-pong* scenarios previously mentioned.
-
----
-
-## Testing
-
-Just like BlazingMQ's other subsystems, its leader election implementation (and
-general replicated state machinery) is tested with unit and integration tests.
-In addition, we periodically run chaos testing on BlazingMQ using our Jepsen
-chaos testing suite, which we will be publishing soon as open source. We have
-also tested our implementation with a TLA+
-[specification](https://github.com/bloomberg/blazingmq/tree/main/etc/tlaplus)
-for BlazingMQ's elector state machine.
-
----
diff --git a/docs/docs/architecture/high_availability.md b/docs/docs/architecture/high_availability.md
deleted file mode 100644
index aab9a76cd..000000000
--- a/docs/docs/architecture/high_availability.md
+++ /dev/null
@@ -1,337 +0,0 @@
----
-layout: default
-title: High Availability
-parent: Architecture
-nav_order: 4
----
-
-# High Availability in BlazingMQ
-{: .no_toc }
-
-* toc
-{:toc}
-
-## Summary
-
-This article introduces readers to a high level design and implementation of
-high availability in BlazingMQ. Readers are encouraged to read the *Network
-Topology* [article](../network_topology) and also get familiar with various
-[message routing patterns](../../features/message_routing_strategies) in
-BlazingMQ before reading this article.
-
-## Introduction
-
-### BlazingMQ Network Topology
-
-As described in the *Network Topology* [article](../network_topology) and shown
-in the figure below, BlazingMQ builds a distribution tree for every queue. The
-tree is rooted at a queue's primary node. Producer and consumer applications
-are represented as leaf nodes.
-
-
-
-This topology structure helps BlazingMQ achieve bandwidth savings in very high
-fan-out ratio setups (a scenario where every message posted on the queue needs
-to go to every consumer attached to that queue).
-
-### What is High Availability?
-
-Failure is inevitable in any distributed system. While total failure can be
-minimized or even avoided in a well designed distributed system, partial
-failures occur all the time as a result of misconfigurations, software bugs,
-machine crashes, network or disk issues, etc. Any formidable distributed
-system must shield applications from such transient failures and allow them to
-work seamlessly while healing itself in the background.
-
-While there is no agreed upon definition for a "highly available" system, such
-a system generally remains available for an extended period of time to its
-users and minimizes downtime (both scheduled and unscheduled). Often,
-availability is expressed in
-[*nines*](https://en.wikipedia.org/wiki/High_availability#%22Nines%22) and is
-calculated as a percentage of time the system was functional from users'
-perspective throughout a given year. The more *nines* a system has, the more
-available it is to the users.
-
----
-
-## Clustering
-
-In message queuing systems like BlazingMQ, high availability is achieved via
-clustering and replication. Every queue in BlazingMQ is stored on disk and
-replicated across a group of machines such that the queue continues to be
-accessible to applications in case some machines in the cluster become
-unavailable. Theoretically, as long as at least one machine in the cluster is
-available, queue remains accessible.
-
-In a BlazingMQ cluster, a node is dynamically assigned as primary for a queue
-such that all writes to the queue go through that node. Primary node also
-ensures that queue is replicated to other nodes (replicas) in the cluster. We
-believe that there is already enough literature available on the topic of
-clustering and replication and we won't go into more details about it in this
-article.
-
-While clustering and replication solve the problem of high availability to an
-extent, BlazingMQ network topology provides an additional challenge. As can be
-seen in the distribution tree in figure above, failure of any node or link in
-the tree directly affects BlazingMQ's availability to the applications. The
-higher the failing node in the tree, the higher the impact on BlazingMQ's
-availability to users. In fact, a node which is simply restarting also affects
-BlazingMQ's availability.
-
-The rest of the article documents BlazingMQ's data life cycle and approach to
-seamlessly handle failing or restarting nodes in the distribution tree.
-
----
-
-## Terminology
-
-Before we go further, lets quickly go over some BlazingMQ terminology which
-will be useful in the rest of the article.
-
-- *PUT*: A message sent (or "posted") by the producer to the queue.
-
-- *ACK*: An acknowledgement sent by BlazingMQ to the producer, informing
- whether the *PUT* message was successfully accepted or not. BlazingMQ tries
- as much as possible to accept the *PUT* message and send successful *ACK*s.
- However there are scenarios where BlazingMQ may not accept *PUT* messages
- sent by a producer: the queue getting full, a long standing network issue,
- etc. BlazingMQ guarantees is that producer will receive an *ACK* for every
- *PUT* message.
-
-- *PUSH*: A message sent by BlazingMQ to the consumer. This is effectively the
- same message as the corresponding *PUT*.
-
-- *CONFIRM*: A message sent by the consumer to BlazingMQ indicating that it has
- processed a specific *PUSH* message. Once a *CONFIRM* message is received,
- BlazingMQ is free to mark that message as deleted in the queue.
-
-- *GUID*: A globally unique identifier assigned to every *PUT* message by
- BlazingMQ framework. A *GUID* is used to identify a message throughout its
- lifetime, and as such, the *ACK* message sent to the producer by BlazingMQ
- contains the *GUID* that was assigned to the corresponding *PUT* message.
- Additionally, *PUSH* message sent by BlazingMQ to the consumer contains the
- *GUID* that was assigned to the corresponding *PUT* message, and lastly,
- *CONFIRM* message sent by consumer to BlazingMQ contains the same *GUID*.
- Each *GUID* is 16 bytes in length.
-
-- *Upstream*: Direction from a BlazingMQ client application to queue's primary
- node. *PUT* and *CONFIRM* messages always travel upstream.
-
-- *Downstream*: Direction from a queue's primary node to a BlazingMQ client
- application. *ACK* and *PUSH* messages always travel downstream.
-
----
-
-## BlazingMQ Data Life Cycle
-
-
-
-The figure above shows the path for various data messages in BlazingMQ. *PUT*
-and *CONFIRM* messages travel from client applications to primary node (i.e.,
-upstream) while *ACK* and *PUSH* messages travel from primary node to client
-applications (i.e., downstream).
-
-Several things can go wrong in this data path:
-
-- TCP connection(s) can drop due to network issues, missing heartbeats, etc.
-
-- BlazingMQ nodes can crash.
-
-- BlazingMQ nodes can undergo graceful shutdown or restart.
-
-In the absence of any buffering and retransmission logic in BlazingMQ nodes,
-any of the above conditions will lead to:
-
-- Lost *PUT* messages and thus producers receiving an *ACK* message indicating
- failure.
-
-- Lost *ACK* messages and thus producers not receiving any *ACK* messages for
- the *PUT* messages that they posted on the queue.
-
-- Duplicate *PUT* messages being posted on the queue if a producer application
- sends the same *PUT* message again upon receiving a failed *ACK* message.
-
-- Lost *CONFIRM* messages leading to duplicate *PUSH* messages to consumers.
-
-Clearly, none of the above scenarios are acceptable. Let's see in the
-following sections how BlazingMQ handles these scenarios.
-
----
-
-## High Availability in BlazingMQ
-
-All problems listed in the previous section have been solved by introducing
-these three principles in BlazingMQ nodes:
-
-- Buffering and retransmission when node to the right is failing (see previous
- figure).
-
-- Maintaining a history of message identifiers (*GUID*s) of the *PUT* messages
- posted on the queue.
-
-- Introducing a shutdown sequence for nodes stopping gracefully.
-
-Let's look into each of the above in detail.
-
-### Buffering and Retransmission
-
-Looking at the previous figure, one can see that in case of a failing node or
-link, the node to the left of it is in the best position to buffer and retry
-any messages until the failing node heals or a fail-over event occurs (i.e.,
-left node connects to another healthy node on the right).
-
-As an example, lets assume that replica 1 in the figure is failing. One can
-see that in such case, *PUT* messages sent by proxy 1 to replica 1 run the risk
-of getting lost. If such scenario occurs, producer application will forever
-keep waiting for an *ACK* for its *PUT* message. This is an extremely
-unpleasant user experience, since BlazingMQ is not only failing to accept a
-*PUT* message from the producer, but also failing to notify producer about it.
-
-One way to solve this would be for proxy 1 to keep a list of *GUID*s of
-unacknowledged *PUT*s. If upstream node fails, explicitly send a failed *ACK*
-for every *GUID* in the unacknowledged list. This will ensure that producer
-application now gets notified of BlazingMQ's failure to accept the *PUT*
-message. While this is an improvement, it is still not ideal as the producer
-application now has to resend the *PUT* message (potentially several times).
-
-A better way would be for proxy 1 to retransmit unacknowledged *PUT* messages
-once replica 1 becomes healthy again, or when proxy 1 fails over to another
-replica, whichever occurs first. This approach will provide seamless user
-experience for producer applications, and increase the chances of a successful
-*ACK* instead of a failed *ACK*.
-
-BlazingMQ adopts the following approach where every node along the path of a
-*PUT* message from producer to primary node keeps an *in-memory retransmission
-buffer* for *PUT* messages. A new *PUT* message is buffered unconditionally,
-is purged upon receiving an *ACK* message and retransmitted if a fail-over
-event occurs. This buffer is bound by both size and time, to ensure that a
-BlazingMQ node's memory does not grow beyond the configured limit, and so that
-producer applications can expect an *ACK* (success or failure) within the
-configured time interval.
-
-The presence of this retransmission buffer ensures that producer applications
-don't see any transient issues in the BlazingMQ back-end. In fact, today the
-entire BlazingMQ cluster (all replicas and primary node) can disappear from the
-network for a few minutes, and producer applications won't notice any failure
-from BlazingMQ APIs. Now this's high availability!
-
-On the *PUSH* message path, the replicated persistent storage acts as the
-retransmission buffer, and as such, there is no need for a separate in-memory
-retransmission buffer for *PUSH* messages. Consider a scenario in the figure
-where proxy 2 fails, leading to loss of in-flight *PUSH* messages. In this
-case, once a new path is established between replica 2 and the consumer,
-replica 2 can simply use the replicated persistent storage to retrieve messages
-that need to be sent to the consumer.
-
-### History of *GUID*s
-
-Readers may have noticed that if a node retransmits a *PUT* message after a
-fail-over scenario, there is a risk of duplicate messages i.e., same message
-could appear twice in the queue. In above figure, this can occur if replica 1
-failed right after forwarding a *PUT* message to the primary node. Depending
-upon the sequence of events, a primary node may or may not receive the message.
-If it receives it, it will replicate and "commit" it in the queue. However,
-once proxy 1 fails over to another replica, it will retransmit this *PUT*
-message, leading to the same message being posted twice on the queue.
-
-BlazingMQ solves this problem by having the primary node maintain a history of
-*GUID*s of *PUT* messages previously posted on the queue. This history is
-bound by a configurable time interval. At a high level, history is represented
-as a custom hash table where *GUID* is the key. This logic ensures downstream
-nodes can retransmit PUT messages without creating duplicates, thereby
-providing a better user experience.
-
-### Shutdown Sequence of Stopping Nodes
-
-Nodes in BlazingMQ can undergo graceful shutdown or restart, and we want
-BlazingMQ to provide a seamless user experience in this scenario as well.
-Specifically, we don't want producer or consumer applications to notice any
-failure when a node along the *PUT* or *PUSH* data paths is restarted or
-shutting down. Additionally, we want to ensure that the node shutting down
-does not take any additional work and drains any pending work in a timely
-manner.
-
-Shutdown sequence is implemented with the help of pairs of
-*StopRequest*/*StopResponse*. A node which is shutting down informs its peer
-nodes (both upstream and downstream) of this action by sending them
-*StopRequest*. Upon receiving a *StopRequest*, peer nodes stop sending any
-*PUT* and *PUSH* messages to the node. Peer nodes keep any new *PUT* messages
-in the retransmission buffer (described above) and *PUSH* messages stay in the
-replicated storage. This ensures that the node shutting down does not get any
-new work. *ACK* and *CONFIRM* messages are still sent to the node by peers.
-This is necessary to ensure that any pending *PUT* and *PUSH* messages no
-longer remain pending and remaining work at the node shutting down is drained.
-
-Lets walk through as example. In above figure, if replica 1 is shutting down,
-it will send *StopRequest*s to proxy 1 and primary nodes. Upon receiving the
-request, proxy 1 (the downstream node) will stop sending *PUT* messages and
-keep them in retransmission buffer. It will continue to forward *CONFIRM*
-messages, if any, to the replica. On the other side, the primary node will
-stop sending *PUSH* messages to the replica (primary may send them along
-another route, if applicable). The primary node will, however, continue to
-send *ACK* messages, which replica will forward to proxy 1. After a while, all
-*PUSH* messages which are pending (i.e., unconfirmed) along the route will be
-confirmed by consumer(s), and at that time, all pending work will be drained.
-At this time proxy 1 will send *StopResponse* to the replica and the link
-between them will be considered 'frozen'. In other words, once *StopResponse*
-has been sent, no further communication will occur between the two nodes.
-
-In the scenario shown in above figure, there is only one downstream (proxy 1)
-and one upstream node (primary) for replica 1. However, in practice, there can
-be tens or hundreds of downstream and more than one upstream nodes for the node
-shutting down. In such case, there will be a *StopRequest*/*StopResponse* pair
-for every such combination.
-
-Peers are required to respond back with *StopResponse* within a configured time
-interval. The chosen time interval has interesting effect -- a low value may
-not be enough to receive *CONFIRM* messages from consumers for all pending
-*PUSH* messages (some consumers take several seconds or even minutes to process
-and confirm messages, which is the whole point of a message queue!). In such
-scenario, those unconfirmed *PUSH* messages will be sent by primary node to
-another consumer, if any, on a different route, and as such, the same *PUSH*
-message could end up being processed twice by two different consumers in an
-application ecosystem. This is within contract, as BlazingMQ provides *at
-least once* delivery guarantees. On the other hand, choosing a higher time
-interval for *StopResponse* will lead to delayed fail over and delayed delivery
-of *ACK* and *PUSH* messages to producers and consumers respectively. In
-practice, the value of time interval varies for each BlazingMQ cluster, and is
-chosen keeping in mind the latency requirements and typical *CONFIRM* times of
-applications using that BlazingMQ cluster.
-
----
-
-## Extending High Availability to Client Libraries
-
-Readers may have noticed that the high availability support described above
-ensures uninterrupted service to BlazingMQ users in cases when a replica or a
-primary node fails or restarts, but not when a proxy node fails or restarts.
-This is indeed a correct observation. If currently if BlazingMQ proxy node
-(i.e., the node immediately connected to the client) goes bad, producer
-applications will receive failed *ACK*s messages. Additionally, when such
-producers attempt to post the same message again after conditions have
-improved, the message may appear twice in the queue. This is because the first
-copy of the message, which was posted while the proxy node failed, may or may
-not have reached the primary node. Moreover, the second copy of the message
-will be assigned a new *GUID* by the proxy (recall that *GUID*s are assigned by
-the BlazingMQ node immediately connected to the client).
-
-A simple solution for this is to update BlazingMQ client libraries to have the
-same high availability logic that exists in BlazingMQ nodes. And this is
-exactly what has been done! BlazingMQ C++ client library has been updated to
-contain a retransmission buffer, generate *GUID*s and support
-*StopRequest*/*StopResponse* work flow. More details about it can be found in
-[this](../high_availability_sdk) article.
-
----
-
-## Conclusion
-
-Addition of high availability support in BlazingMQ has undoubtedly improved
-BlazingMQ user experience and has helped provide uninterrupted service to users
-in case of transient issues in BlazingMQ back-end, including network and
-hardware. Applications can rely on BlazingMQ to buffer and retry messages
-seamlessly. Additionally, BlazingMQ nodes can be restarted at any time without
-service interruption, which helps BlazingMQ maintainers during software
-upgrades, machine or network maintenance, etc.
-
----
diff --git a/docs/docs/architecture/high_availability_sdk.md b/docs/docs/architecture/high_availability_sdk.md
deleted file mode 100644
index b2923e9c1..000000000
--- a/docs/docs/architecture/high_availability_sdk.md
+++ /dev/null
@@ -1,178 +0,0 @@
----
-layout: default
-title: High Availability in Client Libraries
-parent: Architecture
-nav_order: 5
----
-
-# High Availability in Client Libraries
-{: .no_toc }
-
-* toc
-{:toc}
-
-## Introduction
-
-This article introduces readers to the notion of high availability ("HA") in
-BlazingMQ client libraries (also referred to as SDKs). We will see how high
-availability in client libraries helps users write simpler applications than
-before, while protecting applications from transient issues in the BlazingMQ
-back-end, network issues, etc.
-
-High availability in client libraries complements [*High Availability in
-BlazingMQ Back-end*](../high_availability), and they work together to provide a
-seamless experience to BlazingMQ applications in case of framework crashes,
-machine issue, network faults, etc.
-
----
-
-## Motivation
-
-Looking at BlazingMQ's [network topology](../network_topology), one can see
-that there are several points of failure along the *producer -> primary node*
-as well as *primary node -> consumer* paths:
-
-1. Links between proxy and cluster nodes can go down
-
-2. Links among cluster nodes can go down
-
-3. Any number of nodes in the cluster can crash
-
-4. Links between applications and proxies can go down (as a result of proxy
- crash etc).
-
-Any of these events disrupt data flow and can impact applications. As a result
-of HA in BlazingMQ back-end, applications are protected from events in 1-3
-(readers can refer to [HA in BlazingMQ back-end](../high_availability) article
-for more details).
-
-However, event (4) can still impact applications. If BlazingMQ node to which
-applications are connected to (typically referred as "BlazingMQ proxy" or
-"local BlazingMQ proxy") goes down, applications can notice this behavior:
-
-1. Producer application will get an error when attempting to post a *PUT*
- message
-
-2. Consumer application will get an error which attempting to confirm a
- message
-
-3. Producer or consumer application will get an error when attempting to:
- - open a new queue
- - configure an existing queue
- - close a queue
-
-Any of these events can be very disruptive for applications and they need to
-implement a non-trivial state machine to handle scenarios where new work needs
-to be submitted to BlazingMQ, but SDK is not connected to BlazingMQ proxy.
-Lets take the example of a producer application and see how it gets affected:
-
-- A producer application needs to start buffering any *PUT* messages while
- connection with BlazingMQ proxy is down, and then transmit them once
- connectivity with BlazingMQ is reestablished.
-
-- Additionally, status of pending *PUT* messages (messages for which *ACK*s
- were not received before connection with BlazingMQ went down) becomes
- unknown. They may or may not have reached the BlazingMQ queue. Due to this
- ambiguity, prior to HA work, BlazingMQ SDK would generate negative *ACK*s for
- such *PUT* messages with `status = UNKNOWN`, indicating to the producer
- application that the message may or may not have made it to the queue. Some
- applications could choose to retransmit such *PUT* messages upon
- reconnectivity, with the possibility that same message could now appear in
- the queue twice. It is worth noting that the two copies of this message
- would have different Message GUIDs assigned to them, making it further
- challenging for consumer applications to deduplicate such copies.
-
----
-
-## Design
-
-Just like high availability in BlazingMQ back-end, all cases described above can
-be solved by buffering any work submitted to the SDK when connectivity is down,
-and transmitting buffered work and retransmitting any pending work upon
-reconnection. HA in BlazingMQ SDK takes the same approach. Specifically:
-
-1. All *PUT* messages which are submitted by producer application are buffered
- by the SDK in a collection, irrespective of the state of connectivity with
- BlazingMQ back-end. This means that once the queue has been successfully
- opened by the producer application, it can continue to post *PUT* messages
- without worrying about connection's status. This is one of the most
- important changes in the behavior of the SDK. Previously, producer
- application would get a `NOT_CONNECTED` error code from the API when
- attempting to post *PUT* message during disconnection, and would need to
- buffer such *PUT* messages. This is no longer required.
-
-2. In addition, SDK now generates and assigns a unique `bmqt::MessageGUID` to
- every *PUT* message submitted by the application. Prior to HA in SDK, GUIDs
- were assigned by the first BlazingMQ back-end (hop closest to the producer
- application, typically the local BlazingMQ proxy). Motivation for this
- change will be explained shortly.
-
-3. Upon receiving *ACK* message from BlazingMQ, SDK removes the corresponding
- *PUT* message from the collection mentioned in (1) above, since that *PUT*
- message is no longer pending (unacknowledged).
-
-4. When connection with BlazingMQ proxy is down, any new *PUT* messages
- submitted by the application will continue to be buffered in the collection
- in (1).
-
-5. Once the connection is restored and all queues are reopened, all *PUT*
- messages in the collection are transmitted to BlazingMQ back-end. It is
- important to note that some of these *PUT* message could have been sent to
- BlazingMQ back-end prior to connection drop and SDK was waiting for *ACK*s
- for them. Moreover, some of these *PUT* messages could have been accepted
- by BlazingMQ queue. Such *PUT* messages will be seamlessly deduped by
- BlazingMQ back-end, because BlazingMQ primary node maintains a history of
- *MessageGUIDs* seen in the last few minutes (configurable), and if a *PUT*
- message arrives on the queue with a *GUID* which exists in the historical
- list of *GUID*s, it is simply acknowledged back without being added to the
- queue. This ensures that producer application does not see any error, and
- only one copy of the message appears in the queue. For this logic to work
- correctly, it is important that the source (SDK) itself generates and
- assigns a *GUID* to every *PUT* message, as discussed in (2) above.
-
-6. Unlike *PUT* messages, *CONFIRM* messages will not be buffered by the SDK if
- connection to BlazingMQ proxy is down. While this may seem inconsistent,
- there is a good reason for this behavior -- very often, there are multiple
- consumers attached to a queue. If a BlazingMQ node loses route to the
- consumer which is processing *PUSH* messages and sending *CONFIRM*s, it is
- extremely likely that the BlazingMQ node will pick another consumer on a
- different route and start delivering those unconfirmed *PUSH* messages to
- the new consumer immediately. As such, even if original consumer buffers
- *CONFIRM* messages when it is disconnected to BlazingMQ proxy and transmits
- them upon reconnection, those *CONFIRM* messages will simply be ignored by
- BlazingMQ primary node as they are stale, and those *PUSH* messages will get
- processed twice -- once by original consumer and then by new consumer. Note
- that this behavior is within contract, as BlazingMQ provides *at least once*
- delivery guarantee by design. We do have some ideas to minimize such
- duplicate *PUSH* messages, and we may work on it in the near future.
-
-7. *OpenQueue* and *ConfigureQueue* requests will be buffered during
- disconnection and transmitted upon reconnection. Additionally, if a request
- is pending while connection goes down, it will not be failed, but instead
- seamlessly resent upon reconnection.
-
-8. Lastly, *CloseQueue* request is not buffered during disconnection. Queue is
- simply marked as closed in the SDK and a response is generated locally.
- Upon reconnection, this queue is not reopened, effectively leaving the queue
- in the closed state.
-
-### TCP High Watermark Handling
-
-Prior to HA logic in SDK, if TCP connection between SDK and BlazingMQ proxy is
-flow-controlled such that SDK receives a push back from TCP socket when
-attempting to send something, the SDK would buffer messages up to a certain
-limit (typically 128MB), and any attempt to send messages beyond that limit
-would return `BW_LIMIT` (*Bandwidth Limit*) error to the application, and in
-some cases, would simply drop the TCP connection.
-
-This is no longer the case. SDK will continue to accept messages from the
-application even when it is getting a push back from TCP socket, and instead of
-enforcing a size limit, it now enforces a time limit of 5 seconds
-(non-configurable, hard-coded in the SDK) for the TCP channel to be "open"
-again. After this time interval, if TCP channel is still flow-controlled, SDK
-will return `BW_LIMIT` error to the application. It is important to note that
-the wait for this time interval occurs in the application thread which calls
-the SDK API to send message. This is done to ensure that the push back
-indicated by TCP layer is exposed all the way back to the application.
-
----
diff --git a/docs/docs/architecture/index.md b/docs/docs/architecture/index.md
deleted file mode 100644
index 0d1ff0a35..000000000
--- a/docs/docs/architecture/index.md
+++ /dev/null
@@ -1,9 +0,0 @@
----
-layout: default
-title: Architecture
-nav_order: 5
-has_children: true
-permalink: /architecture
----
-
-# [](#architecture)Architecture
diff --git a/docs/docs/architecture/network_topology.md b/docs/docs/architecture/network_topology.md
deleted file mode 100644
index 976f9ea12..000000000
--- a/docs/docs/architecture/network_topology.md
+++ /dev/null
@@ -1,145 +0,0 @@
----
-layout: default
-title: Network Topology
-parent: Architecture
-nav_order: 3
----
-
-# BlazingMQ Network Topology
-{: .no_toc }
-
-* toc
-{:toc}
-
-## Introduction
-
-This document introduces readers to BlazingMQ's network topology and describes
-how its unique topology enables BlazingMQ to provide flexible deployments, high
-bandwidth savings and very high fan-out ratio (10,000+ and beyond).
-
----
-
-## Network Topology
-
-As seen in the [*Clustering*](../clustering#clustering) section of another
-article, a BlazingMQ setup can be deployed in a typical or an alternative
-topology.
-
-
-
-The above figure shows a typical deployment of BlazingMQ. The four nodes in
-the middle represent a BlazingMQ cluster. The blue node in the cluster
-represents a queue’s primary node, while the orange nodes represent
-replicas. Producer/consumer applications can connect to any node in the
-BlazingMQ cluster instead of always requiring to connect to the primary node.
-
-
-
-Above figure shows an alternate deployment of BlazingMQ. As can be seen,
-applications (green nodes) connect to local BlazingMQ agents (yellow nodes),
-which then connect to any node in the BlazingMQ cluster. These local BlazingMQ
-agents are known as proxies and are optional in a BlazingMQ deployment.
-
-An important conclusion can be made from above -- client applications don't
-need to directly connect to a queue's primary, and there can be any number of
-hops between an application and the primary node. This leads to an interesting
-design in BlazingMQ as discussed in the next section.
-
----
-
-## Distribution Tree
-
-There is another more generic way to redraw the above two figures for a given
-queue:
-
-
-
-In the above figure, blue node is queue's primary, orange nodes are the
-replicas, yellow nodes are proxies and green nodes are client applications. As
-mentioned previously, the case of producers is simple, so we will assume that
-all green nodes are consumer applications.
-
-As can be seen from the figure, for every queue, BlazingMQ builds a
-distribution tree rooted at queue's primary node, and as new links are
-established or existing links are torn down due to nodes (primary, replica,
-proxy, application) starting or stopping, BlazingMQ readjusts the routes in the
-affected sub-tree as necessary. This readjustment of routes occurs dynamically
--- every node at a given level attempts to establish a healthy connection with
-at least one node from the upper level.
-
----
-
-## Message Flow in the Distribution Tree
-
-An interesting feature of the topology shown in the previous figure is that it
-optimizes message flow for queues in fan-out and broadcast modes. Consider
-this setup:
-
-
-
-In this figure, there are hundreds of consumers for a broadcast queue. In the
-absence of a distribution tree, all consumers would connect directly with the
-primary node, which would then need to carry out the fan-out to all those
-consumers by itself. While this approach works up to a certain number of
-consumers (as well as the traffic rate), it does not scale well. After a
-certain threshold, primary node's network gets saturated and/or consumers start
-seeing higher latency.
-
-In a distribution tree, however, the primary node (and in fact, every
-intermediate node) carry out a fan-out to only a handful of nodes connected to
-it from the lower level, thereby ensuring a message is disseminated to all
-consumers in an efficient way. This approach effectively implements
-application level multicast (note that we are using the term 'multicast' in a
-logical sense; all communication occurs over TCP).
-
-This topology ensures that BlazingMQ can achieve very high (theoretically
-infinite) fan-out ratio. If at any time, we notice that the fan-out ratio is
-putting pressure on bandwidth or latency for nodes in particular level (yellow
-nodes), we can simply add another level of nodes (gray nodes) below the
-affected level in the tree, thereby reducing the fan-out ratio at all nodes in
-the affected level.
-
-This tree-based topology has been very successful at Bloomberg for supporting
-applications which demand very large number of consumers for a queue in fan-out
-or broadcast mode. BlazingMQ's topology provides tremendous bandwidth saving
-in such scenarios, and also helps cut down the latency of message delivery to
-consumers, as each node has to do minimal fan-out of a message.
-
-This approach is used to run queues with over 6,000 consumers in some Bloomberg
-production environments.
-
-Another benefit of a tree based architecture is efficient fail-overs. Imagine
-a scenario where primary node crashes or goes down gracefully. In the approach
-where all producer and consumer applications are connecting directly to the
-primary, they will now fail over to the new primary, and the new primary will
-see a deluge of incoming connections and requests (thousands or more). This
-can slow down the fail over process and introduce undesirable latency for
-applications. In the case of BlazingMQ's tree based approach, fail overs are
-very fast as only the affected sub-tree needs readjustment. So in the scenario
-where primary node crashes, the new primary receives fail over requests only
-from the replica nodes and the nodes connected to it from one level below,
-instead of thousands of requests from all producer and consumer applications.
-
-A question that may arise in this setup is the effect of multi-hop architecture
-on message latency. Since a message has to travel through several hops,
-additional latency is unavoidable. In most set ups, BlazingMQ provides an end
-to end median latency in single digit milliseconds. Ultimately, it comes down
-to carrying out end to end benchmarking in a production-like setup, reviewing
-the latency and bandwidth numbers, and then adjusting number of consumers or
-number of levels in the tree.
-
----
-
-## Conclusion
-
-The distribution tree based approach works very well for certain high fan-out
-use cases. While this approach comes at the cost of additional deployment
-footprint, it makes up for that by leading to network bandwidth savings for
-high traffic and high fan-out queues.
-
-How BlazingMQ manages to prevent or minimize disruption in message flow for
-applications in distribution tree like topology is an interesting topic.
-Please see [this](../high_availability) article for details about BlazingMQ's
-high availability design.
-
----
diff --git a/docs/docs/architecture/network_transport.md b/docs/docs/architecture/network_transport.md
deleted file mode 100644
index 871b9ec13..000000000
--- a/docs/docs/architecture/network_transport.md
+++ /dev/null
@@ -1,93 +0,0 @@
----
-layout: default
-title: Network Transport
-parent: Architecture
-nav_order: 7
----
-
-# Network Transport in BlazingMQ
-{: .no_toc }
-
-* toc
-{:toc}
-
-This article provides brief overview of the network transport layer of
-BlazingMQ.
-
-## Transport Type
-
-BlazingMQ exclusively uses TCP for all communication within the cluster as well
-as with clients. TCP provides nice properties of ordering and retransmissions
-of packets, which makes the implementation of networking logic simpler in
-BlazingMQ.
-
-## Transport Library
-
-Instead of implementing various low level network building blocks from scratch,
-BlazingMQ leverages Bloomberg's [Network Transport
-Framework](https://github.com/bloomberg/ntf-core), which was published as open
-source in March 2023. NTF enables BlazingMQ to implement non-blocking
-asynchronous network I/O in an efficient manner. In the words of its authors:
-
-*"The Network Transport Framework (NTF) is an open-source collection of
-libraries for asynchronous network programming for scalable, high-performance
-applications.*
-
-*In general, NTF provides building blocks and higher-level abstractions for
-asynchronously sending and receiving data between processes. More specifically,
-NTF provides an abstraction around the differences in the native networking
-APIs offered by the supported operating system, and introduces many useful
-features commonly required by networked applications. The principle feature of
-the sockets of this library is the introduction of virtual send and receive
-queues, which provide a message-oriented, thread-safe (concurrent), send and
-receive API for sockets using transports with either datagram semantics or
-stream semantics. Additionally, these virtual queues allow users to operate
-sockets both reactively (i.e. in the Unix readiness model) or proactively
-(i.e. in the Windows I/O completion model), regardless of the operating system
-and interface to that operating system (e.g. select, kqueue, epoll, io_uring,
-I/O completion ports etc.) NTF supports both stream sockets using TCP and
-datagram sockets using UDP communicating over either IPv4 or IPv6 networks. NTF
-also supports local (aka Unix) domain sockets for efficiently communicating
-between processes on the same machine.*
-
-*The mechanisms in NTF are scalable, efficient, and multi-threaded. Its
-libraries are intended for applications needing to manage anywhere from a
-single socket to many thousands of simultaneous sockets."*
-
-### Transport Abstraction
-
- In its implementation, BlazingMQ abstracts the transport by using
-[`bmqio`](https://github.com/bloomberg/blazingmq/blob/main/src/groups/bmq/bmqio/bmqio_channel.h)
-interface, which enables BlazingMQ to plug in any implementation which conforms
-to it. In fact, BlazingMQ was using a legacy network transport library instead
-of NTF some time back. We have also experimented with plugging in
-[`boost::asio`](https://www.boost.org/doc/libs/1_82_0/doc/html/boost_asio.html)
-as the transport implementation, and using it or another implementation remains
-a future possibility.
-
-## Wire Protocol
-
-BlazingMQ uses a custom wire protocol over TCP, the details of which can be
-found in
-[this](https://github.com/bloomberg/blazingmq/blob/main/src/groups/bmq/bmqp/bmqp_protocol.h)
-header file. There were four guiding principles when this protocol was
-designed:
-
-- *Compactness*: The protocol should have minimal overhead.
-
-- *Forward and backward compatibility*: The protocol should be easily
- extensible while remaining backward compatible.
-
-- *Batching*: The protocol should support batching of messages wherever
- possible.
-
-- *Efficiency*: The protocol should avoid encoding/decoding overhead for
- frequent messages, while still taking into consideration concerns like
- endianness, etc.
-
-Additionally, several components in the
-[`bmqp`](https://github.com/bloomberg/blazingmq/tree/main/src/groups/bmq/bmqp)
-package provide utilities to build and parse network packets conforming to the
-wire protocol.
-
----
diff --git a/docs/docs/community/index.md b/docs/docs/community/index.md
deleted file mode 100644
index a86facb30..000000000
--- a/docs/docs/community/index.md
+++ /dev/null
@@ -1,34 +0,0 @@
----
-layout: default
-title: Community
-nav_order: 10
-has_children: false
-permalink: /community
----
-
-# [](#community)Community
-{: .no_toc }
-
-* toc
-{:toc}
-
-Here is a list of community blogposts about BlazingMQ, tools that integrate
-with BlazingMQ, and other external projects using BlazingMQ. We haven’t
-looked through all of these, so they may be out-of-date or may not work
-anymore. Still, you may find inspiration from some of these resources.
-
-We’re looking to grow this list, so please [get in touch with us][get-in-touch]
-if you have written about or used BlazingMQ in your project. Better yet, [edit
-this page][edit-this-page] and then [send us a PR][contributing-guidelines]!
-
-## Blogposts
-
- - Andy Pearce’s series of blogposts on the features and architecture of
- BlazingMQ: [BlazingMQ: Introduction][andy-pearce-introduction] and
- [BlazingMQ: Clustering and Message Flow][andy-pearce-clustering-message-flow].
-
-[andy-pearce-clustering-message-flow]: https://www.andy-pearce.com/blog/posts/2024/Jul/blazingmq-clustering-and-message-flow/
-[andy-pearce-introduction]: https://www.andy-pearce.com/blog/posts/2024/Jun/blazingmq-introduction/
-[contributing-guidelines]: https://github.com/bloomberg/.github/blob/main/CONTRIBUTING.md
-[edit-this-page]: https://github.com/bloomberg/blazingmq/edit/main/docs/docs/community/index.md
-[get-in-touch]: https://github.com/bloomberg/blazingmq/discussions
diff --git a/docs/docs/contributions/index.md b/docs/docs/contributions/index.md
deleted file mode 100644
index 934727de7..000000000
--- a/docs/docs/contributions/index.md
+++ /dev/null
@@ -1,21 +0,0 @@
----
-layout: default
-title: Contributions
-nav_order: 9
-has_children: false
-permalink: /contributions
----
-
-# [](#contributions)Contributions
-
-{: .no_toc }
-
-We welcome your contributions to help us improve and extend BlazingMQ!
-
-We welcome issue reports [here](https://github.com/bloomberg/blazingmq/issues);
-be sure to choose the proper issue template for your issue, so that we can be
-sure you're providing the necessary information.
-
-Before sending a [Pull Request](https://github.com/bloomberg/blazingmq/pulls),
-please make sure you read our [Contribution
-Guidelines](https://github.com/bloomberg/.github/blob/main/CONTRIBUTING.md).
diff --git a/docs/docs/faqs/faq_general.md b/docs/docs/faqs/faq_general.md
deleted file mode 100644
index c733ef987..000000000
--- a/docs/docs/faqs/faq_general.md
+++ /dev/null
@@ -1,150 +0,0 @@
----
-layout: default
-title: General FAQs
-parent: FAQs
-nav_order: 2
----
-
-# General FAQs
-
-## What platforms are supported by BlazingMQ?
-
-BlazingMQ can run on Linux and Solaris operating systems. The minimum
-required versions of these operating systems are as follows:
-
-| Operating System | Version |
-| ---------------- | ------- |
-| Linux | 3.10.0 |
-| Solaris | 5.11 |
-
-Any operating system not listed above, or any operating system listed but with
-a version less than the minimum specified version is not supported.
-
-For development, BlazingMQ can also be built on Darwin, though production usage
-on Darwin is not supported.
-
-BlazingMQ message broker and C++ client library requires the following minimum
-compiler versions. Any compiler not listed, or any compiler listed but with a
-version less than the minimum specified version is not supported.
-
-| Compiler | Version |
-| -------- | ------- |
-| GCC | 7.3 |
-| clang | 10.0.1 |
-| Solaris Studio | 5.13 |
-
-BlazingMQ message broker and C++ client library require the C++03 version of
-the C++ language standard, or any version above it.
-
-BlazingMQ Java client library is supported on JDK 8, JDK 11 and JDK 17.
-
----
-
-## In what languages are BlazingMQ client libraries available?
-
-BlazingMQ client libraries are available in C++, Java and Python. C++ and Java
-client libraries are available in the initial open source release, and Python
-client library will follow soon.
-
----
-
-## How do I get started with BlazingMQ?
-
-[This](../../getting_started/blazingmq_in_action) article is a good starting
-point to set up a local BlazingMQ environment and play around with it.
-
----
-
-## Does BlazingMQ provide guaranteed message delivery?
-
-When a producer application posts a message on a BlazingMQ queue, BlazingMQ
-guarantees that it will either reliably accept the message or reliably inform
-the producer that it failed to do so.
-
-Above statement may come as a surprise to some readers, but the fact is that no
-framework can guarantee 100% success for its APIs. BlazingMQ may refuse to
-accept a new message in a queue for various reasons like queue storage quota
-getting full, a long running network outage, etc.
-
-To summarize, BlazingMQ provides these guarantees:
-
-- It will always notify the producer of the result of a *post* operation. The
- result can be a failure in some rare scenarios due to reasons mentioned
- above.
-
-- Once a message has been accepted by BlazingMQ, it is guaranteed to be
- delivered to consumer application(s), as long as the message is not
- garbage-collected by BlazingMQ due to message's *TTL* expiration.
-
----
-
-## Can the same message be delivered more than once to consumer(s)?
-
-Yes. BlazingMQ provides *at-least-once* delivery guarantee. BlazingMQ can
-send a message more than once to the same or different consumer. This never
-occurs in steady state but can occur in these scenarios:
-
-- A consumer crashes without confirming a message
-- A node in BlazingMQ back-end crashes
-- A node in BlazingMQ back-end restarts gracefully
-
-A consumer application must be able to handle duplicate delivery.
-
----
-
-## Do queues need to be created or declared upfront in BlazingMQ?
-
-No. Applications don't need to bother with creating or deleting queues. Once
-they have registered their BlazingMQ namespace ("domain") with the BlazingMQ
-cluster, their applications can simply open a queue (via the `openQueue` API)
-and BlazingMQ will automatically create the queue if it does not exist.
-
-Similarly, once a queue is empty and there are no producers and consumers
-attached to the queue, BlazingMQ will garbage-collect the queue automatically
-after a period of inactivity.
-
----
-
-## How many queues can I create under my BlazingMQ namespace?
-
-As mentioned above, a queue is created automatically by BlazingMQ when it is
-opened for the first time by applications. The representation of a queue in
-BlazingMQ cluster is very cheap and one can create tens of thousands of queues
-in their BlazingMQ namespace. However, having tens of thousands of queues can
-make events like application restart, BlazingMQ node restart or fail-over take
-longer than usual (up to 10 seconds). This is because as part of fail-over
-operation, all those queues may need to be opened again, and routes for all the
-applications using those queues may need to be re-established.
-
-Additionally, having tens of thousands of queues may make troubleshooting
-extremely difficult as events across all those queues will be interspersed with
-each other.
-
-Quite often, the need for having thousands of queues can be eliminated by
-application level sharding -- grouping some streams together into one queue,
-thereby reducing number of queues from thousands to hundreds or tens.
-
-Having said that, some BlazingMQ namespaces have several thousands of queues.
-
----
-
-## How does BlazingMQ compare to RabbitMQ and Apache Kafka?
-
-An article comparing these three frameworks can be found
-[here](../../introduction/comparison).
-
----
-
-## Where can I find performance numbers for BlazingMQ?
-
-Details about BlazingMQ latency numbers can be found in
-[this](../../performance/benchmarks) article.
-
----
-
-## How do I configure and deploy a BlazingMQ message broker, cluster or domain?
-
-Details about configuration and deployment can be found
-[here](../../../installation).
-
----
diff --git a/docs/docs/faqs/faq_programming.md b/docs/docs/faqs/faq_programming.md
deleted file mode 100644
index 2ca3d7138..000000000
--- a/docs/docs/faqs/faq_programming.md
+++ /dev/null
@@ -1,239 +0,0 @@
----
-layout: default
-title: Programming FAQs
-parent: FAQs
-nav_order: 3
----
-
-# Programming FAQs
-
-## Where is the reference documentation for BlazingMQ APIs?
-
-C++ SDK documentation can be found
-[here](../../apidocs/cpp_apidocs/index.html).
-
-Java SDK documentation can be found
-[here](../../apidocs/java_apidocs/index.html).
-
----
-
-## What are the different modes in which a queue can be opened?
-
-A queue can be opened in *READ* mode, *WRITE* mode or *READ|WRITE* mode which
-are self-explanatory. If *WRITE* mode is specified, additional `e_ACK` flag
-can also be specified while opening the queue.
-
----
-
-## What's the purpose of correlation ID in BlazingMQ C++ and Java APIs?
-
-When using BlazingMQ C++ or Java SDK, applications can receive events
-asynchronously. In order to enable applications to identify these events
-efficiently, each user action which can result in the delivery of an
-asynchronous event to the application takes an ID. For example, when opening a
-queue, the application needs to specify a `bmqt::CorrelationID` to the
-`bmqa::QueueId` instance, so that the open-queue result via
-`bmqa::SessionEventHandler::onSessionEvent` can be correlated with the
-open-queue request. Another example is posting a message: the application
-can specify a correlation ID when posting a message, so that message's
-acknowledgement status can be correlated to the message.
-
-A correlation ID can be used as a key in associative containers, and can be
-used to retrieve some context needed to process the asynchronous event. For
-example, if a consumer application has opened multiple queues, upon receiving a
-message, it can retrieve the correlation ID of the queue containing the message
-via `bmqa::Message::QueueId`, followed by a call to
-`bmqa::QueueId::correlationId`, and use that correlation ID to retrieve that
-queue's context, which may include things like the message processing callback
-for that queue, etc.
-
----
-
-## Does Correlation ID need to be unique every time I specify it?
-
-Yes, so that every asynchronous event can be uniquely identified by the
-application. Note that it needs to be unique *only* within the context of a
-`bmqa::Session` instance, not across your entire application ecosystem.
-
----
-
-## What does the e_ACK flag mean in `bmqa::Session::openQueue*` APIs? Do I need to specify a correlation ID every time?
-
-[*Correlation ID*](../../apidocs/cpp_apidocs/group__bmqt__correlationid.html)
-is an identifier specified by the producer in a *PUT* message to correlate an
-*ACK* message sent by the broker in response to that *PUT* message. An *ACK*
-message notifies the producer that the corresponding *PUT* message has been
-accepted by the broker (success) or rejected (failure; due to the queue being
-full, long running network issue, etc).
-
-If a producer has specified the `e_ACK` flag while opening the queue, then it
-*must* specify a correlation ID for each message. If the producer attempts to
-build a message without a correlation ID,
-[`bmqa::MessageEventBuilder::packMessage`](../../apidocs/cpp_apidocs/classbmqa_1_1MessageEventBuilder.html#a101f3eea6233a4ff2b78b6b8072e3c50)
-will return
-[`bmqt::EventBuilderResult::e_MISSING_CORRELATION_ID`](../../apidocs/cpp_apidocs/structbmqt_1_1EventBuilderResult.html#a04d8f1ec70faff7c9dce79d82c14844ca056766d02f68b50ea998c4a4a6490ad3).
-In other words, the SDK ensures that the application specifies a correlation ID
-for each message.
-
-If the producer has not specified the `e_ACK` flag while opening the queue,
-specifying correlation ID in a *PUT* message is optional. The general idea is
-that if an application considers a particular message important and wants to
-ensure that broker has accepted that message, it can specify a correlation ID,
-so that the broker sends an *ACK* message (with success/failure status) for
-that message.
-
-A critical application which needs to keep track of the status of every message
-that was posted to the queue should specify a correlation ID for each message,
-and should also specify the `e_ACK` flag while opening the queue in order to
-ensure that no message without a correlation ID is accidentally posted to the
-queue.
-
----
-
-## When does a producer application get ACK messages?
-
-A broker will send an *ACK* message to the producer for each message that the
-producer posted with a correlation ID, irrespective of an `e_ACK` flag provided
-by the producer while opening the queue.
-For domains configured with [strong consistency](../docs/features/consistency_levels/#strong-consistency), the broker only sends an *ACK* once
-the message has been replicated to a quorum number of nodes.
-
----
-
-## What is an *Event Queue*? I see references to it in my BlazingMQ application logs.
-
-Messages received by the BlazingMQ client library from a BlazingMQ broker are
-processed in an internal thread, and then enqueued in a buffer known as an
-*Event Queue* to be dispatched to an application in the BlazingMQ SDK's event
-handler thread. The *Event Queue* is just an in-memory inbound buffer, and is
-in *no* way related to the BlazingMQ queue, which is hosted on the BlazingMQ
-cluster.
-
-Various events like *ACK*, *PUSH*, responses, etc. are popped off from the
-event queue and delivered to the application in the BlazingMQ SDK's event
-handler thread, in methods like `bmqa::Session:onSessionEvent` and
-`bmqa::Session::onMessageEvent`. If the application carries out expensive
-business logic in these methods, the event handler thread will not be able to
-pop off events from the event queue in a timely manner, thereby leading to the
-growth of the event queue as new events are sent by BlazingMQ broker.
-
-In such cases, if the length of the event queue grows beyond the configured
-high-watermark value, the SDK will emit an `e_SLOWCONSUMER_HIGHWATERMARK` event
-as a warning to the application.
-
-The `SessionOptions` parameters `eventQueueLowWatermark` and
-`eventQueueHighWatermark` can be used to configure high and low watermarks for
-the event queue.
-
-If an application repeatedly encounters `e_SLOWCONSUMER_HIGHWATERMARK` event,
-it is likely an indication that the application is slow at processing events or
-needs to carry out processing of events in a thread different from BlazingMQ's
-event handler thread (a thread pool, etc). Additionally, the application can
-also bump up the value of `eventQueueHighWatermark` to a higher value, but it
-should be done cautiously because doing so may potentially hide slowness in the
-application.
-
----
-
-## I don't want BlazingMQ to push all messages to my consumer at once. How can I implement flow control?
-
-Flow control can be easily enforced by a consumer application by specifying
-appropriate values in the
-[`bmqt::QueueOptions`](../../apidocs/cpp_apidocs/classbmqt_1_1QueueOptions.html)
-parameter when opening or configuring a queue.
-
-`bmqt::QueueOptions` contains two variables which are pertinent to flow
-control: `MaxUnconfirmedMessages` and `MaxUnconfirmedBytes`. The former
-determines the maximum number of messages that the broker can deliver to the
-consumer for that queue, without having the consumer confirm them. The latter
-determines the same for maximum number of bytes. If any of these values are
-reached for a consumer, the broker will not send any new messages until the
-consumer confirms some of the messages. Such a consumer is said to have
-reached its capacity.
-
-In the meantime, messages will remain safely in the broker and may be
-distributed to other consumers if applicable.
-
-Note that the flow control parameters can be changed at any time by the
-consumer using the `configureQueue` API. This can be very useful for
-consumers. At interesting use of the `configureQueue` API is that consumers
-can tell BlazingMQ to not send them any more messages by specifying a value of
-zero for both `MaxUnconfirmedMessages` and `MaxUnconfirmedBytes`.
-
-Additionally, consumers can specify a value of 1 for `MaxUnconfirmedMessages`
-in the `openQueue` or `configureQueue` APIs which will ensure that BlazingMQ
-will send only one message at a time to the consumers. This can be useful for
-consumers where each message represents a heavy job and can run for hours.
-
-While it is okay for consumers to reach capacity on some occasions, they must
-not stay in that state forever. This would cause the queue to fill up and
-eventually reach its quota, which leads to new messages being rejected by
-BlazingMQ and the producer receiving failed *ACK* messages. BlazingMQ raises
-several alarms in the scenario of stuck consumers and queues getting full.
-
----
-
-## When does BlazingMQ redeliver a message to another consumer?
-
-In general, as far as BlazingMQ is concerned, once a message has been delivered
-to the consumer, it is 'processing' it, and BlazingMQ does not make any
-assumption about how long the processing step should take. However, BlazingMQ
-redelivers a message to another consumer, if available, in *any* of these
-conditions:
-
-- The original consumer crashes without confirming the message
-- The original consumer closes the queue without confirming the message
-- The original consumer stops BlazingMQ session without confirming the message
-- The TCP connection between original consumer and broker drops due to network
- issue
-
----
-
-## Can I open multiple queues from one `bmqa::Session` object?
-
-Yes. Any number of queues can be opened from one `bmqa::Session` object, and
-creating multiple queues per session object is the recommended approach,
-instead of creating one `bmqa::Session` object per queue.
-
----
-
-## Should I open and close a queue repeatedly in my application?
-
-No! The recommended approach is to open the queue when the application starts
-(or needs it first), and then keep the queue open until it is no longer needed.
-An application must not open and close a queue within a span of a few seconds (
-or even a few minutes). Particularly, applications must not open a queue, post
-a message, close the queue right away, and then repeat this pattern. A queue
-can be thought of as an equivalent to a database handle, which should not be
-acquired and released repeatedly.
-
-While the representation of a queue in a BlazingMQ cluster is cheap, the
-creation, opening and closing of a queue are expensive operations. Creation of
-a queue requires consensus among nodes of the BlazingMQ cluster, and opening
-and closing of a queue require 2 sets of requests and responses along the route
-of the application and the queue's primary node. One can see how opening and
-closing a queue repeatedly in a short span of time may keep the BlazingMQ
-cluster unnecessarily busy.
-
----
-
-## Can the `openQueue` API fail?
-
-Yes, it can fail, due to any of the reasons listed below:
-
-- An application attempts to open a queue for a namespace (BlazingMQ domain)
- which is not yet registered.
-
-- An application attempts to open a queue for a BlazingMQ domain from a machine
- which is not configured for that BlazingMQ domain.
-
-- A bad configuration deployed in BlazingMQ back-end (rare, but has non-zero
- probability).
-
-- A long-standing network issue leads to a connection failure between the
- application and the BlazingMQ back-end, or within various BlazingMQ nodes in
- the back-end (rare, but has non-zero probability).
-
-- A bug in the BlazingMQ back-end
-
----
diff --git a/docs/docs/faqs/index.md b/docs/docs/faqs/index.md
deleted file mode 100644
index ceb6d0a44..000000000
--- a/docs/docs/faqs/index.md
+++ /dev/null
@@ -1,9 +0,0 @@
----
-layout: default
-title: FAQs
-nav_order: 4
-has_children: true
-permalink: /faqs
----
-
-# [](#faqs)FAQs
diff --git a/docs/docs/features/compression.md b/docs/docs/features/compression.md
deleted file mode 100644
index 756b67a6a..000000000
--- a/docs/docs/features/compression.md
+++ /dev/null
@@ -1,181 +0,0 @@
----
-layout: default
-title: Compression
-parent: Features
-nav_order: 5
----
-
-# Compression
-{: .no_toc }
-
-* toc
-{:toc}
-
-## Summary
-
-* Producer applications can indicate to the BlazingMQ SDK to compress a
- message. BlazingMQ SDK will compress the message payload before sending
- it to the BlazingMQ back-end.
-
-* On the consumer side, upon receiving a compressed message, BlazingMQ SDK will
- seamlessly decompress it before presenting it to the application layer.
-
-* The BlazingMQ broker is not involved in the compression/decompression of the
- message.
-
----
-
-## Pros & Cons
-
-### Pros
-
-* *Reduced Network I/O:* A compressed message will lead to less data being sent
- over the network, thereby reducing transit latency as well as network
- bandwidth usage. Depending upon the nature of the message, compression can
- reduce the message size up to one-third of the original.
-
-* *Reduced Storage Quota:* A compressed message will lead to reduced usage of
- disk as well as BlazingMQ domain quota. This means that applications will be
- able to store more messages with the same quota. In certain scenarios, it
- can also help the BlazingMQ back-end, particularly in storage replication and
- synchronization. For *in-memory* queues, compressed messages will also help
- bring down the BlazingMQ broker's memory consumption.
-
-### Cons
-
-* *Higher CPU Usage:* There are no free lunches in life! The above mentioned
- advantages come at the cost of additional CPU cycles in the producer and
- consumers applications (note that BlazingMQ back-end does not decompress
- messages).
-
-* *Potentially Higher Latency:* Since producers compress messages, and
- consumers decompress messages, there will be some additional latency overhead
- involved in end-to-end message processing. This latency may or may not be
- higher than the gains obtained in the transit and storage replication latency
- mentioned above. As always, latency-sensitive applications must carry out
- careful end-to-end benchmarking with production-like traffic.
-
----
-
-## General Guidelines for Enabling Compression
-
-* Compression is useful for scenarios where the message payload contains textual
- data of around 1KB or more. In our benchmarks where messages contained randomly
- generated strings, we found meaningful gains when the message length was more
- than 1KB.
-
-* Producers should not enable compression in BlazingMQ SDK if message is
- already compressed.
-
----
-
-## Implementation Notes
-
-### API and Sample Producer Snippet
-{:.no_toc}
-
-In order to enable compression for a message, producers can use the newly added
-API:
-
-* C++: `bmqa::Message::setCompressionAlgorithmType`
-* Java: `PutMessage::setCompressionAlgorithm`
-
-Sample C++ snippet:
-
-```c++
-
-// (Unrelated details omitted for brevity)
-
-// Create message instance.
-bmqa::Message& message = builder.startMessage();
-
-// Set the compression algorithm type for the message.
-message.setCompressionAlgorithmType(bmqt::CompressionAlgorithmType::e_ZLIB);
-
-// Set message payload. Note that order of invocation of
-// 'setCompressionAlgorithmType' and 'setDataRef' does not matter.
-message.setDataRef(text.c_str(), text.length());
-
-// Add message to the builder.
-int rc = builder.packMessage(queueId);
-
-```
-
-### Supported Compression Types
-{:.no_toc}
-
-Currently, the BlazingMQ SDK supports *ZLIB* compression. In the future,
-support for additional compression algorithms can be provided as deemed
-necessary.
-
-### *ZLIB* Performance
-{:.no_toc}
-
-In our benchmark tests, we noticed that for strings larger than 1KB and
-containing randomly generated alphanumeric characters, *ZLIB* resulted in a
-compression ratio of around 1.6. One should expect *ZLIB* to perform even
-better in practical scenarios where a message is likely to contain repeated
-patterns.
-
----
-
-## Important Notes
-
-* Note that enabling compression in a producer application is only a hint to
- the BlazingMQ SDK. The SDK may not compress the message if compression's
- cost outweighs the benefits. As a rule of thumb, the SDK will generally
- ignore the compression hint if message size is less than 1KB, but note that
- this is an implementation detail, and must not be relied upon for any
- purposes.
-
-* The BlazingMQ SDK does not enable compression by default. A producer needs
- to explicitly enable compression on a message. This may change in subsequent
- versions of the SDK.
-
-* Only the message payload is compressed. Message properties are not
- compressed in order to ensure that the BlazingMQ message broker can read the
- properties efficiently if needed (for example, properties are read by the
- broker for evaluating subscriptions).
-
-* Consumer applications do not have to worry about detecting compression and
- carrying out decompression. The BlazingMQ SDK hides this detail from the
- consumer, and always presents a decompressed message to the application.
-
-* In the producer application, compression is carried out in the user thread
- (i.e., the thread which invokes `bmqa::MessageEventBuilder::packMessage` in
- C++ and `Queue.post` or `Queue.flush` in Java).
-
-* On the consumer side:
-
- - C++ SDK: Decompression is carried out when the application invokes
- `bmqa::Message::getData`, which is typically invoked by applications in an
- *event-handler* thread in async mode, and in user thread in sync mode (note
- that some applications may have a different thread management).
-
- - Java SDK: Decompression is carried out in an internal SDK thread, which is
- different from the *I/O* as well as the *event-handler* thread.
-
----
-
-## Compression Stats
-
-A BlazingMQ client can be configured to periodically report various internal
-metrics to the application log (this is switched on by default). As part of
-every report, these two compression related metrics are logged as part of the
-*Queue Stats* section:
-
-- Average compression ratio for all messages for that queue in the last 300
- seconds (delta).
-
-- Average compression ratio for all the messages from the beginning (absolute).
-
-Note that the accumulated size of messages reported in the stats is calculated
-from the compressed size of the messages. This, along with
-the compression ratio mentioned above, would help consumer applications get an
-idea about their actual message sizes as well as the effectiveness of
-compression.
-
-The SDK also reports a final summary of the average compression ratio when the
-application is stopped.
-
----
diff --git a/docs/docs/features/consistency_levels.md b/docs/docs/features/consistency_levels.md
deleted file mode 100644
index c18d3910d..000000000
--- a/docs/docs/features/consistency_levels.md
+++ /dev/null
@@ -1,138 +0,0 @@
----
-layout: default
-title: Consistency Levels
-parent: Features
-nav_order: 6
----
-
-# Consistency Levels in Storage Replication
-{: .no_toc }
-
-* toc
-{:toc}
-
-## Introduction
-
-Distributed systems, particularly distributed data stores, offer different
-consistency levels for various operations initiated by clients. The
-consistency level of a system defines the ordering and visibility of operations
-in the system.
-
-Knowing the consistency level of a distributed system can help users design
-their applications, as well as understand the scenarios in which operations
-initiated by them can succeed or fail.
-
-Several consistency levels exist in the world of distributed systems, but in
-the context of messaging systems like BlazingMQ, only two consistency levels
-are worth discussing -- *Eventual Consistency* and *Strong Consistency*. The
-former is sometimes also referred to as *Weak Consistency*.
-
-The rest of this section describes eventual and strong consistency levels in
-the context of BlazingMQ, compares the two consistency levels and also goes
-over some additional considerations, which will help BlazingMQ users choose the
-correct level of consistency for their BlazingMQ domains.
-
----
-
-## Eventual Consistency
-
-For a queue that is configured with the eventual consistency level in
-BlazingMQ, when the primary node of the queue receives a *PUT* message, it
-writes the message to its local storage, *asynchronously* sends it to the
-replicas, and immediately sends the *ACK* back to the producer application,
-without waiting for any confirmation from the replicas.
-
-This configuration relies on the fact that the message will *eventually* reach
-the replicas, which will then apply and store the message in their local
-storages respectively.
-
-Readers may have noticed that there is a chance of message loss in eventual
-consistency mode. This can occur when the primary node crashes (or goes down
-gracefully) immediately after sending the *ACK* to the producer, but before the
-message could be replicated to all or to the majority of the replicas (the
-message could still be in the user or kernel space TCP socket buffers).
-Additionally, it is also possible for the replicated message to get lost
-because of a network split etc, in which case replicas will not receive the
-message. This is the risk that comes with eventual consistency.
-
-However, the latency numbers for eventually consistent queues are very
-attractive. Since a primary node performs minimal work between receiving a
-*PUT* and sending an *ACK*, the producer application can expect the *ACK*
-fairly quickly. Additionally, consumers will also see the corresponding *PUSH*
-message earlier, because the primary node sends it right away to the consumer
-application, without waiting for acknowledgements from replicas.
-
-So when choosing an eventual consistency level, BlazingMQ users should know
-that while this consistency level will give low latency numbers, there is a
-non-zero probability of a message getting lost.
-
-We recommend using eventual consistency only in exceptional circumstances.
-
----
-
-## Strong Consistency
-
-A strong consistency level in BlazingMQ solves the problem of potential message
-loss, which can occur in eventual consistency mode as described above. This is
-done by ensuring that the primary node waits for acknowledgements (known as
-*Replica Receipts* in BlazingMQ lingo) from a sufficient number of replicas
-*before* sending *ACK* and *PUSH* messages to the producer and the consumer
-applications respectively.
-
-This ensures that even if the primary node crashes after sending an *ACK*
-message, replicas are guaranteed to have the *PUT* message, and as one of the
-replicas gets promoted to the role of primary, it will be able to send that
-message to the consumer application.
-
-The number of replicas which must send a receipt to the primary node for a
-message to be considered "committed" is derived from the size of the BlazingMQ
-cluster. In a cluster having 4 nodes, the primary node will wait for receipts
-from 2 replicas, which will ensure that the message ends up in at least 3 nodes
-(2 replicas plus 1 primary). Similarly, in a cluster of 6 nodes, the primary
-node will wait for receipts from 3 replicas, thereby ensuring that the message
-has been stored in at least 4 nodes. Generally speaking, to ensure strong
-consistency, BlazingMQ ensures that a total of `N/2 + 1` nodes in the cluster
-have recorded the message, where `N` is the total number of nodes in the
-cluster.
-
-While strong consistency provides higher message guarantees, it can come with
-some latency overhead. However, we have introduced several optimizations in
-the strong consistency implementation in BlazingMQ, and our tests have
-indicated that latency numbers for strong consistency are only slightly higher
-than the ones for eventual consistency.
-
-Some of the optimizations in the implementation include:
-
-- Replicas sending a receipt message to the primary for a batch of messages,
- instead of a receipt for every message.
-
-- Replicas further optimizing the receipt code path by taking into
- consideration if the link between the replica and the primary is overloaded,
- and trying to conflate the receipt messages.
-
----
-
-## Other Considerations
-
-### Timeouts at Primary Node
-{:.no_toc}
-
-Since the primary node waits for replicas to send replication receipts, it is
-possible for this operation to time out due to widespread BlazingMQ cluster or
-network issues. In such scenario, the primary node will issue a negative *ACK*
-with an *UNKNOWN* status to the producer application, and will give up on
-delivering this message to the consumer(s). Note that the message can still be
-delivered in the scenario where the current primary node goes down and a replica
-which received the message (and perhaps even sent its receipt) gets promoted as
-the new primary. In such case, the new primary will send the message to the
-consumer. Hence the *UNKNOWN* status in negative *ACK*. This timeout is
-configurable.
-
-### Flushing Messages to Disk
-{:.no_toc}
-
-Note that BlazingMQ does not flush messages to disk in either consistency level
-before sending an *ACK* to the producer. Instead, it relies on the OS to do so
-periodically.
-
----
diff --git a/docs/docs/features/consumer_flow_control.md b/docs/docs/features/consumer_flow_control.md
deleted file mode 100644
index d3aa045b4..000000000
--- a/docs/docs/features/consumer_flow_control.md
+++ /dev/null
@@ -1,48 +0,0 @@
----
-layout: default
-title: Consumer Flow Control
-parent: Features
-nav_order: 7
----
-
-# Consumer Flow Control
-{: .no_toc }
-
-* toc
-{:toc}
-
-BlazingMQ delivers messages to consumer applications using a push model i.e.
-BlazingMQ message broker pushes new messages as quickly as possible to the
-consumers. In order to ensure that consumers do not get overwhelmed and can
-implement flow control, BlazingMQ provide consumer applications APIs to specify
-maximum number and/or bytes of messages (or "flow control parameters") that
-BlazingMQ broker can send them. Consumers can specify flow control parameters
-when they are attaching to a queue via the
-[`openQueue`](../../apidocs/cpp_apidocs/classbmqa_1_1Session.html#a7b62b74a9a4d4dd3e24765d6e54e8c9a)
-API , and also update them anytime later on via the
-[`configureQueue`](../../apidocs/cpp_apidocs/classbmqa_1_1Session.html#af10950d3245e8acf6a4fc4403c7f433a)
-API. Flow control parameters are captured in `maxUnconfirmedMessages` and
-`maxUnconfirmedBytes` parameters of
-[`bmqt::QueueOptions`](../../apidocs/cpp_apidocs/group__bmqt__queueoptions.html).
-
-Once BlazingMQ has sent the specified number of messages or bytes to the
-consumer instance, it will not send any new messages to it, and such consumer
-is considered to be "at capacity". Any new messages arriving in the BlazingMQ
-queue will stay in the queue and will be delivered to the consumer only when
-consumer processes (i.e., confirms) pending messages that were delivered
-previously. BlazingMQ keeps track of outstanding messages sent to every
-consumer to determine if a consumer instance is at capacity or not.
-
-As an example, if a consumer instance wants no more than 1,000 messages or 100MB
-worth of messages, it can specify that in the flow control API. Specifying the
-value of zero of number or bytes of messages leads to effectively pausing the
-consumer -- BlazingMQ sees that consumer has no capacity and thus does not
-route any messages to it. This can be used by consumer to pause itself
-temporarily in case it is not able to process messages for some reason.
-Similarly, specifying a value of 1 of number of messages is equivalent to
-pulling one message at a time from the queue.
-
-Lastly, flow control parameters can be specified for every
-[subscription](../subscriptions) separately if desired.
-
----
diff --git a/docs/docs/features/distributed_trace.md b/docs/docs/features/distributed_trace.md
deleted file mode 100644
index 716834648..000000000
--- a/docs/docs/features/distributed_trace.md
+++ /dev/null
@@ -1,82 +0,0 @@
----
-layout: default
-title: Distributed Trace
-parent: Features
-nav_order: 8
----
-
-# Distributed Trace
-{: .no_toc }
-
-* toc
-{:toc}
-
-## Introduction
-
-The BlazingMQ C++ SDK can integrate with any distributed tracing framework for
-telemetry purposes. The SDK is not tied to a specific tracing library or
-implementation. Instead it provides hooks such that external tracing logic can
-be injected. See next section for implementation details.
-
-If a tracing implementation is provided, the BlazingMQ C++ SDK has the ability
-to create spans for control messages sent to the BlazingMQ broker on behalf of
-the client. This includes:
-
-* Session-Start and Session-Stop operations
-* Queue-Open, Queue-Close, and Queue-Configure operations
-
-Future work may also support creating spans for `PUT` and `CONFIRM` messages.
-
----
-
-## Code Snippet
-
-### C++ SDK
-
-Clients may enable Distributed Trace by installing two objects through the
-session options:
-
-- A **context** responsible for defining the "current" span for a thread
-
-- A **tracer** responsible for creating new spans
-
-Users can inject their custom distributed tracing logic by providing concrete
-implementations for these interfaces:
-
-- [`bmqpi::DTSpan`](../../apidocs/cpp_apidocs/group__bmqpi__dtspan.html)
-- [`bmqpi::DTContext`](../../apidocs/cpp_apidocs/group__bmqpi__dtcontext.html)
-- [`bmqpi::DTTracer`](../../apidocs/cpp_apidocs/group__bmqpi__dttracer.html)
-
-The custom implementation can then be installed through the session options as
-shown below.
-
-```cpp
-
-// Assuming that `MyDTContext` and `MyDTTracer` are concrete implementations of
-// `bmqpi::DTContext` and `bmqpi::DTTracer`:
-
-// Instantiate custom distributed trace objects.
-bsl::shared_ptr dtContext(new MyContext());
-bsl::shared_ptr dtTracer(new MyTracer());
-
-// Configure the session-options.
-bmqt::SessionOptions sessionOptions;
-options.setTraceOptions(dtContext, dtTracer);
-
-// Instantiate the session object.
-bmqa::Session session(sessionOptions);
-
-// Session-start will produce spans for each request sent to the BlazingMQ
-// broker on behalf of the client.
-session.start();
-
-// If a span is already active when an SDK operation is invoked, it will be
-// used as a parent for any spans created by the session object.
-
-```
-
-### Java and Python SDKs
-
-Distributed trace support is not yet available in the Java and Python SDKs.
-
----
diff --git a/docs/docs/features/host_health_monitoring.md b/docs/docs/features/host_health_monitoring.md
deleted file mode 100644
index 58cdce159..000000000
--- a/docs/docs/features/host_health_monitoring.md
+++ /dev/null
@@ -1,265 +0,0 @@
----
-layout: default
-title: Host Health Monitoring
-parent: Features
-nav_order: 8
----
-
-# Host Health Monitoring
-{: .no_toc }
-
-* toc
-{:toc}
-
-## Introduction
-
-The **Host Health Monitoring** feature allows BlazingMQ SDK clients to
-automatically suspend queues when the machine running the application becomes
-unhealthy. Applications using this feature can inject their custom logic to
-check the machine's health in the BlazingMQ SDK. The SDK will periodically
-invoke the custom logic and if the logic tells the SDK that the machine is
-unhealthy, the SDK will suspend the queues that expressed interest in getting
-suspended.
-
----
-
-## Code Snippets
-
-### C++ SDK
-
-Users can implement their custom host health monitoring logic by implementing
-[`bmqpi::HostHealthMonitor`](../../apidocs/cpp_apidocs/group__bmqpi__hosthealthmonitor.html).
-
-The custom class can then be installed through the session options as shown
-below.
-
-```cpp
-
-class MyHostHealthMonitor : public bmqpi::HostHealthMonitor {
- // Details elided
-};
-
-bsl::shared_ptr monitor(new MyHostHealthMonitor());
-if (err = monitor->start()) {
- // error handling
-}
-
-bmqt::SessionOptions sessionOptions;
-options.setHostHealthMonitor(monitor);
-
-bmqa::Session session(sessionOptions);
-
-// 'QueueOptions' are used to opt in to suspension on unhealthy hosts.
-bmqt::QueueOptions queueOptions;
-queueOptions.setSuspendsOnBadHostHealth(true);
-
-// This queue will suspend when 'monitor' reports that the host is unhealthy.
-bmqa::OpenQueueStatus status = session.openQueueSync(&otherId,
- k_OTHER_URL,
- bmqt::QueuFlags::e_READ,
- queueOptions);
-
-// Queues opened with default options *will not* suspend on an unhealthy host.
-status = session.openQueueSync(&queueId,
- k_QUEUE_URL,
- bmqt::QueueFlags::e_READ);
-```
-
-The `monitor` notifies the `bmqa::Session` when the host becomes unhealthy,
-allowing the `bmqa::Session` to suspend all queues that are sensitive to host
-health. A suspended queue behaves in the following ways:
-
-* **Consumers**: The queue is configured to receive no further messages from
- the broker (`maxUnconfirmedMessages := 0; maxUnconfirmedBytes := 0;
- consumerPriority := INT_MIN`). Any previously received CONFIRM messages can
- still be sent. can still be sent.
-
-* **Producers**: Attempts to pack messages targeting a suspended queue will be
- rejected by `bmqa::MessageEventBuilder::pack()`. Clients may still attempt to
- `POST` existing packed events.
-
-* **Reconfiguration**: Configuration changes to a suspended queue will only
- take effect when it resumes.
-
-Please note:
-
-- The SDK will by default assume that no queues are sensitive to host health
- even if the application has installed a `HostHealthMonitor`. Clients must
- explicitly enable host-health suspension through the `bmqt::QueueOptions`
- when opening a queue.
-
-- If a queue is sensitive to host health, and it is opened while the host is
- already unhealthy, it will be initialized into suspended state.
-
-#### Using the `bmqa::ManualHostHealthMonitor` class
-{:.no_toc}
-
-BlazingMQ C++ SDK also includes the `bmqa::ManualHostHealthMonitor` class. This
-class **does not** monitor machine status, but instead relies on clients to
-explicitly set the host health through a class method.
-
-```cpp
-bsl::shared_ptr monitor(
- new bmqa::ManualHostHealthMonitor());
-
-bmqt::SessionOptions sessionOptions;
-options.setHostHealthMonitor(monitor);
-
-bmqa::Session session(sessionOptions);
-if (rc = session.start()) {
- // error handling
-}
-
-// ...
-// Set up queues
-// ...
-
-monitor->setState(bmqt::HostHealthState::e_UNHEALTHY);
- // Notifies 'session' that host is now unhealthy.
-```
-
-While most projects will not use this type for production code, it can be
-useful for unit-testing code paths that are only reached during 'machine
-unhealthy' events. Less commonly, an application might use
-`bmqa::ManualHostHealthMonitor` to integrate BlazingMQ with a different system
-that is being used to report host health.
-
-### Java SDK
-
-Similar to C++ SDK, Java users can implement their custom host health
-monitoring logic by implementing
-[`com.bloomberg.bmq.HostHealthMonitor`](../../apidocs/java_apidocs/com/bloomberg/bmq/HostHealthMonitor.html)
-interface.
-
-The custom class can then be installed through the session options as shown
-below.
-
-```java
-// Create custom monitor implementation.
-com.enterprise.blazingmq.MyHostHealthMonitor monitor =
- new com.enterprise.blazingmq.MyHostHealthMonitor();
-
-// Start the monitor.
-// Do not forget to call 'stop()' in order to stop the monitoring in case
-// BlazingMQ session is stopped and the app is closing.
-monitor.start();
-
-// Configure session options
-SessionOptions sessionOptions = SessionOptions.builder()
- .setHostHealthMonitor(monitor)
- .build();
-
-// Create and start session
-Session session = new Session(sessionOptions,
- this); // SessionEventHandler
-
-session.start(Duration.ofSeconds(15));
-
-// Create queues
-Queue queue1 = d_session.getQueue(uri1, // Queue uri
- QueueFlags.setReader(0), // Queue mode (=READ)
- this, // QueueEventHandler
- this, // AckMessageHandler
- this); // PushMessageHandler
-
-Queue queue2 = d_session.getQueue(uri2, // Queue uri
- QueueFlags.setReader(0), // Queue mode (=READ)
- this, // QueueEventHandler
- this, // AckMessageHandler
- this); // PushMessageHandler
-
-// Configure queue options which are used to opt in to suspension on unhealthy hosts.
-QueueOptions queueOptions = QueueOptions.builder()
- .setSuspendsOnBadHostHealth(true)
- .build();
-
-// Queue1 *will* suspend when 'monitor' reports that the host is unhealthy.
-queue1.open(queueOptions, Duration.ofSeconds(15));
-
-// Queue2 opened with default options *will not* suspend on an unhealthy host.
-queue2.open(QueueOptions.createDefault(), Duration.ofSeconds(15));
-```
-
----
-
-## Host Health Transitions
-
-BlazingMQ SDK issues two session-level events and two queue-level events
-related to Host Health. Clients must install a Host Health monitor in their
-application to observe these event.
-
-**Session Event**
-
-- `e_HOST_UNHEALTHY`: The host running the application has become unhealthy.
-
-- `e_HOST_HEALTH_RESTORED`: The health of the host running the application has
- been restored.
-
-In Java SDK, the events are `HostUnhealthy` and `HostHealthRestored`
-(interfaces with `type` property set to `HOST_UNHEALTHY_SESSION_EVENT` and
-`HOST_HEALTH_RESTORED_SESSION_EVENT` accordingly).
-
-**Queue Events**
-
-- `e_QUEUE_SUSPENDED`: A queue has been suspended because of an unhealthy host.
-
-- `e_QUEUE_RESUMED`: A queue has resumed when the health of the host has been
- restored.
-
-In Java SDK the events are `SuspendQueueResult` and `ResumeQueueResult`
-(interfaces with `type` property set to `QUEUE_SUSPENDED` and `QUEUE_RESUMED`
-accordingly).
-
-### Queue Semantics
-
-An `e_QUEUE_SUSPENDED` event signals that no further messages will be delivered
-to that queue until an `e_QUEUE_RESUMED` event is received. The
-`bmqa::MessageEventBuilder` will reject messages from the time that an
-`e_QUEUE_SUSPENDED` event is read, until the time that an analogous
-`e_QUEUE_RESUMED` event is read.
-
-In Java SDK `com.bloomberg.bmq.Queue` will reject messages to pack/post from
-the time that an `QUEUE_SUSPENDED` event is read, until the time that an
-analogous `QUEUE_RESUMED` event is read.
-
-### Session Semantics
-
-Host Health session events are only issued when the health of the **whole
-application state** has changed. This distinction becomes important in certain
-corner cases, such as when the health of a host is "flapping" between healthy
-and unhealthy states. At such times, the BlazingMQ SDK will not issue the
-`e_HOST_HEALTH_RESTORED` event until every queue has resumed **and** the host
-is healthy. Conversely, the BlazingMQ SDK will only issue the
-`e_HOST_UNHEALTHY` event when passing from an entirely healthy state into a
-partially unhealthy one.
-
-Consequently, during an event in which a recently healthy machine again enters
-an unhealthy state before every suspended queue could be resumed, neither
-`e_HOST_UNHEALTHY` nor `e_HOST_HEALTH_RESTORED` would be published (since the
-SDK does not consider the whole application to have ever reentered a healthy
-state).
-
-As a corollary of this behavior, a client reading an `e_HOST_HEALTH_RESTORED`
-event can assume that every queue has resumed operation until a subsequent
-`e_HOST_UNHEALTHY` event is observed.
-
----
-
-## Error Behavior
-
-A host may become unhealthy for many reasons, so it's important that the
-BlazingMQ SDK be able to reliably suspend a queue. The failure of a suspend
-request is treated as evidence of an unusually serious problem with the
-connection to the broker; if a suspend request cannot be completed, then the
-session connection is dropped (this would also impact queues not configured to
-be sensitive to Host Health). The BlazingMQ SDK will then undergo the usual
-process to attempt to reestablish a connection.
-
-This same "nuclear option" does not apply to queue resumption. If a queue
-cannot be resumed, the error is reported as a status on the `e_QUEUE_RESUMED`
-event message. We recommend clients check for such errors (however unlikely),
-and decide whether it is best to close the queue, attempt again to reconfigure
-it, etc. Note that the SDK will publish the `e_HOST_HEALTH_RESTORED` session
-event regardless of errors encountered while resuming individual queues.
-
----
diff --git a/docs/docs/features/index.md b/docs/docs/features/index.md
deleted file mode 100644
index 561d0be16..000000000
--- a/docs/docs/features/index.md
+++ /dev/null
@@ -1,13 +0,0 @@
----
-layout: default
-title: Features
-nav_order: 2
-has_children: true
-permalink: /features
----
-
-# [](#features)Features
-
-In addition to providing durable and highly available queues, BlazingMQ also
-supports a rich set of features which help BlazingMQ users implement a variety
-of use cases. This section provides an overview of them.
diff --git a/docs/docs/features/message_routing_strategies.md b/docs/docs/features/message_routing_strategies.md
deleted file mode 100644
index bfe853569..000000000
--- a/docs/docs/features/message_routing_strategies.md
+++ /dev/null
@@ -1,176 +0,0 @@
----
-layout: default
-title: Message Routing Strategies
-parent: Features
-nav_order: 2
----
-
-# Message Routing Patterns
-{: .no_toc }
-
-* toc
-{:toc}
-
-The most interesting aspect of BlazingMQ is the various ways in which it can
-route messages to consumer applications attached to a queue. Given a queue,
-any number of producers and consumers can attach to it. The case of multiple
-producers is straightforward -- every producer can post messages to the queue.
-It becomes more interesting when multiple consumers are attached to the same
-queue -- BlazingMQ may decide to route a newly arrived message to:
-
-- A specific consumer instance
-- A subset of consumer instances
-- All consumer instances
-
-BlazingMQ may choose one or more consumer instances based on one or more of the
-following attributes:
-
-- A round-robin strategy
-- Capacity and/or priority advertised by the consumer(s)
-- Any criteria (filter) specified by the consumer(s)
-- Routing strategy with which the queue is configured
-
-Across all of the above, the most important aspect is the routing strategy of a
-queue (also referred to as "queue mode" in some places in BlazingMQ). Routing
-strategy is something that is statically configured when the BlazingMQ domain
-(application namespace) is registered with the BlazingMQ framework.
-
-## Work Queue
-
-
-
-In work queue mode, BlazingMQ routes messages arriving in the queue in a
-round-robin fashion to the attached consumers, such that a message goes to only
-one consumer. This mode ensures that messages are load balanced across all
-consumers. BlazingMQ marks a message as deleted once the consumer confirms the
-message. In case a consumer goes away without confirming messages, BlazingMQ
-reroutes those messages to other consumer instances, if there are any. It
-should be obvious that in work queue mode, the order of message processing by
-the consumers can be different from the order of arrival of messages in the
-queue.
-
-An extremely attractive feature of this mode is that as a new consumer attaches
-to the queue, BlazingMQ starts sending a subset of the messages to the new
-consumer. This means that applications can increase their processing capacity
-by simply spinning up a new consumer instance, without making any code or
-configuration changes or having to worry about creating additional queues. No
-consumer attached to the queue stays idle. In theory, an application can watch
-the queue's size, and decide to spin up new consumer instances if the queue is
-growing, or wind down existing instances if the queue's size has gone below a
-low watermark.
-
----
-
-## Consumer Priority Mode
-
-
-
-In this mode, consumers attaching to a queue can also declare their priorities,
-and BlazingMQ routes messages *only* to the consumer with the highest priority.
-If multiple consumers with the same highest priority exist, BlazingMQ routes
-messages across those consumers in a round-robin fashion. BlazingMQ marks a
-message as deleted once the consumer confirms the message. Readers may notice
-that the work queue mode described above is just a simpler case of priority
-mode where all consumers have same priority. In fact, there is no separate
-routing strategy called "work queue" in code or configuration, and BlazingMQ
-back-end does not treat "work queue" as a special mode.
-
-Consumer priorities give applications finer control over message processing, in
-that applications can direct the traffic to a specific consumer instance or
-machine as desired, by playing with consumers' priorities.
-
-Additionally, consumers can dynamically update their priorities via an API
-provided in the BlazingMQ SDK. One way in which this feature can be leveraged
-by applications is to have a primary/backup setup for their consumers, by
-ensuring that one consumer has highest priority while other consumer instances
-have a lower priority. Additionally, in case applications have multiple such
-queues, they can configure consumers' priorities such that primary consumers
-for their queues are evenly spread across the application cluster, thereby
-ensuring equal usage of resources. Moreover, the ability to adjust consumer
-priority dynamically also enables consumer applications to integrate well with
-other patterns like leader election -- a consumer instance elected as a leader
-can bump up its priority to a higher value, thereby ensuring that it is the
-only one consuming from the queue.
-
----
-
-## Fan-out Mode
-
-
-
-In both work queue and priority modes, a message goes to only one consumer
-instance. However, there are use cases where each message posted on the queue
-needs to go to all consumers attached to the queue. This is where fan-out mode
-comes into the picture.
-
-In this mode, consumers identify themselves with a string identifier when
-attaching to the queue (called *AppId* in BlazingMQ). *AppId*s are needed so
-that BlazingMQ can uniquely identify consumers across restarts, and need to be
-registered with the BlazingMQ framework upfront. So for example, if users of a
-BlazingMQ queue have registered five *AppId*s with BlazingMQ, they can bring up
-five consumers, each using one of the *AppId*s, and each consumer will receive
-every message posted on the queue.
-
-Consumers in fan-out mode can consume from the queue at their own pace and can
-also process and confirm messages in a different order. Logically, one can
-think of each *AppId* getting its own copy of the queue. However, under the
-hood, BlazingMQ maintains only one queue and thus, only one copy of the message
-in the storage (of course, replication leads to *N* copies of the message,
-where *N* is the replication factor). Storing the message only once
-irrespective of number of *AppId*s can lead to significant storage savings,
-especially in the case of a high number of *AppId*s (i.e., having a high
-fan-out ratio).
-
-BlazingMQ marks a message as deleted once *all* consumers have confirmed the
-message.
-
-A powerful feature supported in fan-out mode is that multiple consumers can use
-the same *AppId* and also specify priorities. In such scenario, BlazingMQ
-sends messages only to the consumer with the highest priority in *that* *AppId*
-group. If in an *AppId* group, multiple consumers with highest priority exist,
-messages are routed in a round-robin fashion across them. Thus, BlazingMQ
-ensures that one consumer in each *AppId* group receives every message posted
-on the queue.
-
-Readers will notice that consumer priority mode is just a simpler case of
-fan-out mode, where there is only one (default) *AppId*.
-
----
-
-## Broadcast Mode
-
-
-
-Broadcast mode is unique and significantly different from other queue modes
-found in BlazingMQ and in other message queuing systems. In this mode,
-messages arriving on a queue are neither persisted on disk nor buffered in
-memory. Instead, they are immediately dispatched to the consumers attached to
-the queue at that instant and then "dropped" by BlazingMQ. BlazingMQ makes no
-effort to keep messages for consumers which may arrive at a later time. As a
-consequence, broadcast mode provides an *at most once* delivery guarantee,
-contrasting with the *at least once* delivery guarantee provided by all other
-queue modes. Additionally, consumers can specify a priority when attaching to
-the queue, and BlazingMQ routes all messages to all consumers having highest
-priority.
-
-Apart from providing no persistence, another important way in which broadcast
-mode differs from fan-out mode is that the number of consumers in broadcast
-mode is dynamic. In other words, new consumers can attach to the queue at any
-time, and existing consumers can leave the queue any time without invoking any
-special API or without registering new consumers or *AppId*s with the BlazingMQ
-framework.
-
-Broadcast mode can be useful for scenarios where occasional message loss is
-acceptable for applications e.g., tick-type data stream, analytics, health
-check notifications, cache invalidation notifications, or when applications
-have other means to retry/recover lost messages.
-
-Broadcast mode makes BlazingMQ a very attractive messaging system to users,
-because along with the queue modes described above, BlazingMQ can provide them
-with a mix of both *at most once* as well as *at least once* delivery
-guarantees in their application ecosystems, and they don't need to pick any
-another messaging system for their *at most once* delivery requirements.
-Broadcast mode has exactly same set of APIs as other queue modes which means
-applications don't have to treat broadcast mode as a special case.
-
----
diff --git a/docs/docs/features/plugins.md b/docs/docs/features/plugins.md
deleted file mode 100644
index 7eaac383b..000000000
--- a/docs/docs/features/plugins.md
+++ /dev/null
@@ -1,267 +0,0 @@
----
-layout: default
-title: Plugins
-parent: Features
-nav_order: 9
----
-
-# Plugins
-{: .no_toc }
-
-* toc
-{:toc}
-
-## Prometheus plugin
-
-### Overview
-This plugin gathers BlazingMQ broker statistic and sends it to [Prometheus](https://prometheus.io/) monitoring system. Both `push` and `pool` modes of interaction with Prometheus are supported.
-
-### Configuration
-By default, plugin is disabled. To enable and configure it, edit `bmqbrkcfg.json` file as follows:
-
-1. Enable plugin and provide path to plugin library
- ```json
- "appConfig": {
- ...
- "plugins": {
- "libraries": [""],
- "enabled": ["PrometheusStatConsumer"]
- }
- }
- ```
-
-2. Provide plugin configuration
- ```json
- "appConfig": {
- "stats": {
- "snapshotInterval": 1,
- "plugins": [
- ...
- {
- "name": "PrometheusStatConsumer",
- "publishInterval": 10,
- "prometheusSpecific": {
- "host": "localhost",
- "port": 9091,
- "mode": "E_PUSH"
- }
- }
- ],
- ...
- }
- }
- ```
-
-where
-
-1. Common plugins configuration
-
- - `snapshotInterval`: represents how often stats are computed by broker
- internally, in seconds (typically every 1s);
-
-2. Prometheus plugin configuration
-
- - `name`: plugin name, must be "PrometheusStatConsumer";
- - `publishInterval`: Specified as a number of seconds. Must be a multiple of the `snapshotInterval`.
- - in `push` mode: it is the time period (in seconds) to send statistic to Prometheus Push Gateway;
- - in `pull` mode: it is time (in seconds) to update statistic;
- - `host`
- - in `push` mode: Prometheus Push Gateway URL;
- - in `pull` mode: Prometheus exposer (local http server) URL that should be accessible by Prometheus to pull the statistic, usually Host IP address;
- - `port`
- - in `push` mode: Prometheus Push Gateway port, usually 9091;
- - in `pull` mode: Prometheus exposer port that should be accessible by Prometheus to pull the statistic;
- - `mode`: interaction with Prometheus mode: `E_PUSH` or `E_PULL`;
-
-### Build and Run plugin in demo environment
-To build Prometheus plugin, pass '--plugins prometheus' argument to the build script, e.g.
-```bash
-bin/build-ubuntu.sh --plugins prometheus
-```
-To run plugin in demo environment, perform the following steps:
-
-1. Set plugin configuration:
- - For `push` mode:
- ```json
- {
- "host": "localhost",
- "port": 9091,
- "mode": "E_PUSH"
- }
- ```
- - For `pull` mode:
- ```json
- {
- "host": "localhost",
- "port": 8080,
- "mode": "E_PULL"
- }
- ```
-
-2. Run BlazingMQ broker, it will automatically load and configure the plugin;
-
-3. Run Prometheus and Grafana services in Docker:
- ```bash
- docker compose -f docker/plugins/prometheus/docker-compose.yml up
- ```
-
-4. In browser open link `http://localhost:9090/` with Prometheus UI to analyze available metrics;
-
-5. [Optional] In browser open link `http://localhost:3000/` with Grafana UI to analyze available metrics:
- - Select `Prometrheus` data source;
- - Set `http://prometheus:9090` as Prometheus server URL;
-
-### Integration tests
-Test plan:
-1. Test Prometheus plugin in 'push' mode:
- - Run Prometheus (in docker);
- - Run broker with local cluster and enabled Prometheus plugin in sandbox (temp folder);
- - Put several messages into different queues;
- - Request metrics from Prometheus and compare them with expected metric values.
-2. Test Prometheus plugin in 'pull' mode:
- - Run Prometheus (in docker);
- - Run broker with local cluster and enabled Prometheus plugin in sandbox (temp folder);
- - Put several messages into different queues;
- - Request metrics from Prometheus and compare them with expected metric values.
-
-Prerequisites:
-1. bmqbroker, bmqtool and prometheus plugin library should be built;
-2. Python3 should be installed;
-3. Docker should be installed, user launching the test script must be included into the group 'docker'.
-```bash
-Usage: ./src/plugins/prometheus/tests/prometheus_prometheusstatconsumer_test.py [-h] -p PATH
-options:
- -h, --help show this help message and exit
- -p PATH, --path PATH path to BlazingMQ build folder, e.g. './build/blazingmq'
-```
-
-### Labels
-The following labels may be used by each metric, whenever applicable. Refer to each individual metric documentation for restrictions which may apply.
-
-|Label Name|Description|
-|----------|-----------|
-|Instance|instance id of the broker (e.g. A), or 'default'|
-|Cluster|name of the cluster (e.g. bmqc01/A)|
-|Domain|name of the domain (e.g. my.domain)|
-|Tier|value of the tier (e.g. pd)|
-|Queue|name of the queue (e.g. my_queue)|
-|Role|role of the broker with regard to this queue (possible values are 'PRIMARY', 'PROXY', 'REPLICA')|
-|RemoteHost|name of the 'upstream' node or '_none_'|
-|AppId|application ID (e.g. my_app), applicable only in fanout mode, if feature is configured, see 'appIdTagDomains' setting|
-
-### Available BlazingMQ metrics
-This section lists all the metrics reported to Prometheus by BlazingMQ brokers. Note that any metric whose value is 0 is not published. The only exception to this rule is queue.heartbeat which is always published.
-
-In this section, report interval refers to how often stats are being published in `push` mode (typically every 30s) and snapshot represents how often stats are computed internally (typically every 1s).
-
-Note that all metrics published to Prometheus are also dumped by BlazingMQ broker on the local machine in a file, which is located at this location:
-
- /localBMQ/logs/stat.*
-
-These stat files can come in handy when Prometheus is unavailable or when metrics during certain time interval are missing from Prometheus for some reason.
-
-### System metrics
-System metrics represent BlazingMQ broker's overall operating system metrics. Every broker reports them, with 'Instance' label which is always set.
-
-#### CPU
-
-|Metric Name|Description|
-|-----------|-----------|
-|brkr_system_cpu_all|Average snapshot value over report interval window for the total system CPU usage.|
-|brkr_system_cpu_sys|Average snapshot value over report interval window for the total CPU usage.|
-|brkr_system_cpu_usr|Average snapshot value over report interval window for the total user CPU usage.|
-
-#### Operating System
-
-|Metric Name|Description|
-|-----------|-----------|
-|brkr_system_mem_res|Maximum snapshot value over report interval window for the resident memory usage.|
-|brkr_system_mem_virt|Maximum snapshot value over report interval window for the virtual memory usage.|
-
-#### Memory
-
-|Metric Name|Description|
-|-----------|-----------|
-|brkr_system_os_pagefaults_minor|Total number of times over the report interval window, a page fault serviced without any I/O activity. In this case, I/O activity is avoided by reclaiming a page frame from the list of pages awaiting reallocation.|
-|brkr_system_os_pagefaults_major|Total number of times over the report interval window, a page fault serviced that required I/O activity.|
-|brkr_system_os_swaps|Total number of times the process was swapped out of main memory over the report interval window.|
-|brkr_system_os_ctxswitch_voluntary|Total number of times, over the report interval window, a context switch resulted because the process voluntarily gave up the processor before its time slice was completed.|
-|brkr_system_os_ctxswitch_voluntary|Total number of times, over the report interval window, a context switch resulted because a higher priority process ran, or the current process exceeded its time slice.|
-
-#### Network metrics
-
-|Metric Name|Description|
-|-----------|-----------|
-|brkr_system_net_local_in_bytes|Total number of 'bytes' received by the broker from local TCP connections over the report interval window.|
-|brkr_system_net_local_out_bytes|Total number of 'bytes' sent by the broker to local TCP connections over the report interval window.|
-|brkr_system_net_remote_in_bytes|Total number of 'bytes' received by the broker from remote TCP connections over the report interval window.|
-|brkr_system_net_remote_out_bytes|Total number of 'bytes' sent by the broker to remote TCP connections over the report interval window.|
-
-### Broker metrics
-Broker summary metrics represent high level aggregated view of the activity on that broker. Every broker reports them, with 'Instance' label.
-
-|Metric Name|Description|
-|-----------|-----------|
-|brkr_summary_queues_count|Maximum snapshot'd value over the report interval window for the number of opened queues (including inactive not yet gc’ed queues).|
-|brkr_summary_clients_count|Maximum snapshot'd value over the report interval window for the number of clients connected to the broker.|
-
-### Cluster metrics
-Every broker reports this metric for each of the clusters it has created, with the following tags: 'Instance', 'Cluster' and 'Role'. If the 'Role' is 'PROXY', the 'RemoteHost' tag is also set (but can have the value '_none_').
-
-|Metric Name|Description|
-|-----------|-----------|
-|cluster_healthiness|Represents whether this cluster is healthy, as perceived from this host. If the cluster was considered healthy during the entire report interval, a value of 1 is reported; on the other hand, if the cluster was unhealthy for at least one snapshot during the report interval, a value of 2 is reported. Cluster being considered healthy means different things depending on if the host is a proxy to the cluster or a member of the cluster. If it is a proxy, having an active upstream node is sufficient for it to be healthy. For a member, it means being aware of an active leader, all partitions assigned to an active primary, etc.|
-
-### Cluster partitions metrics
-The following metrics are reported for each partition, only by the primary of the partition, with the 'Cluster' and 'Instance' tags set. Note that in the following metrics name \ represents the partition id (0 based integer).
-
-|Metric Name|Description|
-|-----------|-----------|
-|cluster_\_rollover_time|The time (in nanoseconds) it took for the rollover operation of the partition. Note that if more than one rollover happened for the partition during the report interval, then the maximum time is reported. This metric can be used to see how long, but also how often, rollover happens for a partition.|
-|cluster_\_journal_outstanding_bytes|The maximum observed outstanding bytes in the journal file of the partition over the report interval. Note that this value is internally updated at every sync point being generated, and therefore is not an absolute exact value, but a rather close estimate.|
-|cluster_\_data_outstanding_bytes|The maximum observed outstanding bytes in the data file of the partition over the report interval. Note that this value is internally updated at every sync point being generated, and therefore is not an absolute exact value, but a rather close estimate.|
-
-### Domain metrics
-Domain metrics represent high level metrics related to a domain. Only the leader node of the cluster reports them, with the 'Cluster', 'Domain', 'Tier' and 'Instance' tags set.
-
-|Metric Name|Description|
-|-----------|-----------|
-|domain_cfg_msgs|The configured domain messages capacity, used to compute percentage of resource used.|
-|domain_cfg_bytes|The configured domain bytes capacity, used to compute percentage of resource used.|
-|domain_queue_count|The maximum snapshot'd value over the report interval window for the number of opened queues (including inactive not yet gc’ed queues) on that domain.|
-
-### Queue metrics
-Queue metrics represent detailed, per queue, metrics. For each of them, the following tags are set: 'Cluster', 'Domain', 'Tier', 'Queue', 'Role' (which value can only be one of 'PRIMARY', 'REPLICA' or 'PROXY') and instanceName. 'AppId' tag could be applied on 'queue.confirm_time_max' and 'queue.queue_time_max' metrics in fanout mode if this feature is configured (see 'appIdTagDomains' setting).
-
-|Metric Name|Description|
-|-----------|-----------|
-|queue_producers_count|The maximum snapshot'd value over the report interval window for the number of aggregated producers downstream of that broker. When looking at the primary reported stats, this gives the global view.|
-|queue_consumers_count|The maximum snapshot'd value over the report interval window for the number of aggregated consumers downstream of that broker. When looking at the primary reported stats, this gives the global view.|
-|queue_put_msgs|Total number of 'put' messages for the queue received by this broker from its downstream clients over the report interval window.|
-|queue_put_bytes|Total cumulated bytes of all 'put' messages (only application payload, excluding bmq protocol overhead) for the queue received by this broker from its downstream clients over the report interval window.|
-|queue_push_msgs|Total number of 'push' messages for the queue received by this broker from its upstream connections over the report interval window.|
-|queue_push_bytes|Total cumulated bytes of all 'push' messages (only application payload, excluding bmq protocol overhead) for the queue received by this broker from its upstream connections over the report interval window.|
-|queue_ack_msgs|Total number of 'ack' messages (both positive acknowledgments as well as negative ones) for the queue received by this broker from its upstream connections over the report interval window.|
-|queue_ack_time_avg|Represent the average time elapsed between when a put message was received by the downstream and when its corresponding ack was received for the messages posted during the report interval window. Note that this metric is only reported at the primary and at the first hop, that is intermediary hops do not report it. On the primary, this represents how long it took for the message to be stored and replicated in the storage, on the last hop this represents the clients perceived 'post' time.|
-|queue_ack_time_max|Represent the maximum time elapsed between when a put message was received by the downstream and when its corresponding ack was received for the messages posted during the report interval window. Note that this metric is only reported at the primary and at the first hop, that is intermediary hops do not report it. On the primary, this represents how long it took for the message to be stored and replicated in the storage, on the last hop this represents the clients perceived 'post' time.|
-|queue_nack_msgs|Total number of failed 'nack’ (i.e. failed 'ack') generated by this broker, over the report interval window.|
-|queue_confirm_msgs|Total number of 'confirm' messages for the queue received by this broker from its downstream clients over the report interval window.|
-|queue_confirm_time_avg|This metric is only reported by the first hop, and represent the average time elapsed between when a message is pushed down to the client, and when the client confirms it, for the messages pushed during the report interval window.|
-|queue_confirm_time_max|This metric is only reported by the first hop, and represent the maximum time elapsed between when a message is pushed down to the client, and when the client confirms it, for the messages pushed during the report interval window.|
-|queue_heartbeat|This metric is always reported for every queue, so that there is guarantee to always (i.e. at any point in time) be a time series containing all the tags that can be leveraged in Prometheus|
-
-Metrics in the following section are reported only by the node primary of the queue.
-
-|Metric Name|Description|
-|-----------|-----------|
-|queue_gc_msgs|The number of messages which have been garbage collected from the queue (i.e. purged due to TTL expiration) over the report interval window.|
-|queue_cfg_msgs|The configured queue messages capacity, used to compute percentage of resource used.|
-|queue_cfg_bytes|The configured queue bytes capacity, used to compute percentage of resource used.|
-|queue_content_msgs|The maximum snapshot'd value over the report interval window for the number of messages pending in the queue.|
-|queue_content_bytes|The maximum snapshot'd value over the report interval window for the cumulated bytes of all messages pending in the queue.|
-|queue_queue_time_avg|Represent the average time elapsed between when the message was received by the primary, and when it was pushed downstream to the next hop consumer for the messages pushed during the report interval window. This basically represents how long a message stayed in the queue due to no (usable) consumer available. Note that if the primary has switched between the put and the push, then the reported time only has seconds precision.|
-|queue_queue_time_max|Represent the maximum time elapsed between when the message was received by the primary, and when it was pushed downstream to the next hop consumer for the messages pushed during the report interval window. This basically represents how long a message stayed in the queue due to no (usable) consumer available. Note that if the primary has switched between the put and the push, then the reported time only has seconds precision.|
-|queue_reject_msgs|Total number of rejected messages for the queue (where the number delivery attempts reaches 0) over the report interval window.|
-|queue_nack_noquorum_msgs|Total number of messages NACKed due to primary timing out waiting for quorum replication receipts.|
-
----
diff --git a/docs/docs/features/poison_pill_detection.md b/docs/docs/features/poison_pill_detection.md
deleted file mode 100644
index a029a8d25..000000000
--- a/docs/docs/features/poison_pill_detection.md
+++ /dev/null
@@ -1,61 +0,0 @@
----
-layout: default
-title: Poison Pill Detection
-parent: Features
-nav_order: 4
----
-
-# Poison Pill Detection
-{: .no_toc }
-
-* toc
-{:toc}
-
-## Introduction
-
-BlazingMQ has a built-in bad message ("poison pill") detection mechanism which
-auto detects and purges poison pill messages from the queue. This helps
-applications prevent a widespread outage in the scenario where a poison pill
-message is causing consumer applications to crash repeatedly.
-
-## Motivation
-
-Let's understand the motivation in more detail. One can attach multiple
-consumers to a BlazingMQ queue. Additionally, any time a consumer goes away
-without confirming messages that were sent to it, BlazingMQ re-routes those
-messages to other consumer(s), if available. If a message is acting as a
-poison pill and crashing consumers, BlazingMQ will continue to re-route to that
-message to any available consumer, until that message is confirmed by a
-consumer, or is removed from the queue as a result of message TTL expiration or
-is manually purged from the queue. Typically, messages are configured with
-higher values of TTL (10 minutes or more), and purging a specific message or
-entire queue requires manual intervention. It is easy to see how a poison pill
-message can lead to widespread application outage by repeatedly bringing down
-consumers and keeping them down for an extended period of time.
-
-## Solution
-
-BlazingMQ limits retransmissions of poison pill messages up to the limit
-specified in the BlazingMQ domain configuration (typical recommended value is
-five). Once the retransmission counter of a message reaches zero, the message
-is auto-purged from the queue. Additionally, the payload of the offending
-message is dumped in a file which can be inspected for troubleshooting
-purposes.
-
-
-## Caveats
-
-Note that this feature can introduce some additional latency in case BlazingMQ
-detects a message as *potentially* poisonous. BlazingMQ users might be aware
-that BlazingMQ delivers messages to consumer applications in batches for
-performance reasons. If one message in a batch is poisonous and causes a
-consumer to crash, BlazingMQ declares the entire batch as *potentially*
-poisonous, and a throttled delivery algorithm kicks in, which attempts to
-pinpoint the message which is actually poisonous. As the message continues to
-crash consumers and its transmission counter inches towards zero, the algorithm
-throttles the batch of messages aggressively to find the culprit. This
-throttling can introduce a delay of up to 5 seconds (configurable) in message
-transmission to consumers. Note that this feature does not introduce *any*
-throttling or overhead in the absence of consumer crashes.
-
----
diff --git a/docs/docs/features/subscriptions.md b/docs/docs/features/subscriptions.md
deleted file mode 100644
index 1b9a0802a..000000000
--- a/docs/docs/features/subscriptions.md
+++ /dev/null
@@ -1,443 +0,0 @@
----
-layout: default
-title: Subscriptions
-parent: Features
-nav_order: 3
----
-
-# Subscriptions
-{: .no_toc }
-
-* toc
-{:toc}
-
-## Introduction
-
-Subscriptions provide consumer applications a powerful mechanism to only
-receive the messages from a queue that match a specified expression.
-In essence, subscriptions allow the user to achieve topic-based message
-filtering and/or message routing.
-
-In the absence of subscriptions, a consumer attached to a queue can receive
-and should be able to process any and all messages posted on the queue. In
-other words, the queue is viewed as a logical stream of homogeneous data.
-While this may work in some or most cases, there are scenarios where this
-is limiting.
-
-For example, a user may prefer one set of consumers to handle messages of a
-certain type, and another set of consumers to handle messages of a certain
-other type. Or, a user may have a queue of messages that should all be
-processed by some consumer applications, but certain applications may only be
-interested in a certain subset of messages and want to ignore messages of a
-certain type. This is where subscriptions come in -- they enable consumer
-applications to "subscribe" to messages of a certain type and enable users
-to filter out messages for certain applications but not others, thereby
-*logically* converting a queue into a stream of heterogeneous data.
-
-Concretely speaking, producer applications can put any interesting message
-attributes in the *message properties* section of the message (*message
-properties* are a list of key/value pairs that a producer can associate with a
-message), and consumers can request BlazingMQ to filter messages using one or
-more of those *message properties*.
-
-For example, if a message contains these three properties:
-
-- `CustomerId = 1234`
-- `DestinationId = "ABC"`
-- `OrderType = EXPRESS`
-
-A consumer can provide a filter ("subscription expression") like so to "match"
-the above message:
-
-- `CustomerId == 1234 && OrderType == EXPRESS`
-
-In this case, a message having the properties as shown above will be routed
-to the consumer with the above filter (note that if a property is not specified
-in the subscription expression, it is considered to be a wildcard).
-
-Similarly, users can spin up any number of consumers, each with different
-filters. Users have to ensure that every message can be processed by at least
-one consumer.
-
-## Detailed Overview
-
-This section provides an in-depth overview of subscriptions -- motivation, high
-level design, selective implementation details, etc. This section assumes that
-reader is familiar with various routing strategies (aka 'queue modes') as well
-as general BlazingMQ terminology like *PUT*, *PUSH*, *ACK*, *CONFIRM* messages,
-etc.
-
-### Subscription Types
-
-BlazingMQ provides two types of subscriptions:
-
-- Application Subscriptions (message filtering)
-- Consumer Subscriptions (message routing)
-
-Users can leverage either or both types of subscriptions to achieve the desired
-behavior. The two types of subscriptions are described below.
-
-#### Application Subscriptions
-
-Application Subscriptions provide the ability to filter out messages from an
-application's queue in the BlazingMQ broker.
-
-When a message is produced to a queue, BlazingMQ will evaluate all Application
-Subscriptions and _auto-confirm_ the message on behalf of an application if
-the message does not match the application's subscription expression. Since
-BlazingMQ only routes unconfirmed messages to consumers, consumers will only
-receive messages that match the configured Application Subscription.
-
-Application Subscriptions are specified in the domain's configuration:
-
-* Application Subscriptions are configured and evaluated per-*AppId* for fanout
-queues.
- - Note the BlazingMQ broker will still store each message until it is
- confirmed by all *AppIds*, either via auto-confirm or a consumer.
-* Application Subscriptions are configured with an empty *AppId* (i.e.
-`appId=""`) for priority and broadcast queues. Auto-confirms apply to all
-consumers of these queues.
-
-#### Consumer Subscriptions
-
-Consumer subscriptions allow each consumer instance to express the messages
-it is capable of processing when it attaches to the queue. This allows users
-to define the subset of consumers that BlazingMQ can route any given message
-to.
-
-When a message is produced to a queue, BlazingMQ will evaluate all Application
-Subscriptions (as described above), and then evaluate Consumer Subscriptions
-to determine which consumers are capable of processing the message. Then, all
-standard routing logic (i.e. consumer priorities, round-robin, respecting
-`maxUnconfirmed*` configurations) is used to deliver the message to a consumer.
-
-Notes:
-
-- BlazingMQ will only route a message to a consumer if the message matches that
-consumer's subscription. If a consumer has no subscription, BlazingMQ can route
-any message to it.
-
-- If there is no matching consumer subscription for a message, the message will
-remain in the queue, unconfirmed, until a consumer configures a subscription
-matching the message. The message will count against the configured
-queue/domain quota limits until it is confirmed or expires due to TTL.
-
-- Each consumer instance can specify a different subscription.
-
-- Users have to ensure that every message can be processed by at least
-one consumer.
-
-### Background
-{:.no_toc}
-
-1. Consider a scenario where multiple consumers are attached to a queue in work
- queue or priority mode. Without subscriptions, there is no way for consumers
- to specify any restrictions on the messages that BlazingMQ will route to
- them. All consumers must be in a position to process any message posted on
- the queue. As an example, let’s assume that all messages being posted to the
- queue have an attribute called `CustomerId` with various possible values
- representing different customers. There could be a case where some consumers
- can process only those messages where `CustomerId == 1000` while others can
- process messages only where `CustomerId == 2000` and so on.
-
-2. Consider a slight variation of above scenario, such that although every
- consumer can process message with any `CustomerId`, but in order to provide
- better isolation and QoS, owners of the consumer application want to
- dedicate a set of consumers for every firm. So *M* consumers are dedicated
- for `CustomerId == 1000` , *N* consumers for `CustomerId == 2000` , etc.
-
-3. Consider another scenario where one or more consumers are attached to a
- queue, but none of them are ever interested in messages where `CustomerId`
- is different from 1000 or 2000 . Such a scenario can occur where one team is
- producing on the queue and other teams are consuming from it, and the later
- don’t control the types of messages being posted on the queue.
-
-Without subscriptions, there is no way in BlazingMQ in which users can
-implement a solution for these scenario. Some workarounds exist. Let's look at
-them:
-
-- Scenarios (1) and (2) can be solved by creating one BlazingMQ queue for each
- `CustomerId` and having producer(s) post a message on the appropriate
- queue. This solution can work as long as the total number of `CustomerId`s
- (and thus, queues) is limited to a few hundred (a large number of queues
- impacts applications’ and BlazingMQ cluster’s startup and failover
- times). Moreover, producer and consumer applications would have to agree on
- the naming convention of the queues.
-
-- Scenario (3) can be implemented by consumer applications by simply confirming
- those messages which they are not interested in. However, such messages are
- still routed to the consumers, which leads to wasted network bandwidth and
- CPU.
-
-### Design
-{:.no_toc}
-
-Scenarios described in the previous section can be solved by introducing the
-notion of subscriptions in BlazingMQ, and routing a message to consumer(s) with
-matching subscription(s). Here’s how subscriptions work at a high level:
-
-- Producers add any ‘interesting’ attributes of the message in its *message
- properties*.
-
-- Users specify one or more Application Subscriptions in the domain configuration
- for one or more *AppIds*. Each *AppId* can have one or more boolean expression
- containing one or more message properties. If there is no subscription for an
- *AppId*, the application will receive all messages.
-
-- Consumers specify one or more boolean expressions when opening the
- queue. Each expression can contain one or more message properties. As an
- example, an expression can look like:
-
- - `CustomerId == 1000`
- - `CustomerId == 2000 && DestinationId == "ABC"`
- - `CustomerId >= 1000 && CustomerId <= 2000`
-
- where `CustomerId` and `DestinationId` are message properties. Every such
- expression will be a subscription and we will be using these two terms
- interchangeably. Of course, subscriptions are optional and if a consumer does
- not specify any subscriptions, it will receive all of the messages posted on
- the queue.
-
-- In addition to specifying subscriptions when opening the queue (using the
- `openQueue` API), consumers will also be able to specify them when
- configuring the queue (`configureQueue` API). Consumers will be able to tweak
- existing subscriptions, remove an existing subscription or add a new
- subscription using the `configureQueue` API. In that regard, subscriptions
- will be completely dynamic.
-
-- In addition, consumers will also be able to specify certain options like
- priority and flow-control parameters for each subscription. Recall that
- currently, these options – `bmqt::QueueOptions` – are specified for the
- entire queue. However, after the introduction of subscriptions, consumers
- will be able to specify different values for each subscription. This means
- that priorities will now be applicable at the subscription level. For
- example, a consumer application can advertise priority 10 for one
- subscription, and priority 5 for another. These priorities will be taken into
- consideration by BlazingMQ when routing messages (as is currently the
- case). In addition, it will also help BlazingMQ provide some determinism when
- routing a message in a queue having multiple subscriptions (see *Order of
- Evaluation* bullet in *Implementation Details* section below).
-
-- Existing APIs will continue to work and consumer applications which do not
- use subscriptions will not need to make any changes.
-
-- In the BlazingMQ back-end, upon the arrival of a new message, the BlazingMQ
- primary node will first check each Application Subscription. The message
- will be auto-confirmed for each application that does not have a matching
- subscription. If there is a matching Application Subscription, Blazing will
- then try to match the message with a consumer's subscription and route the
- message to the corresponding consumer instance. See *Implementation Details*
- section below for more info.
-
-- Multiple expressions can be provided when using Application and/or Consumer
- Subscriptions. The BlazingMQ primary node will check if a message matches
- each provided expression, resulting in an implicit "OR" between expressions.
-
-### Implementation Details
-{:.no_toc}
-
-The *Design* section above gives a high level overview of the feature. There
-are, however, some additional details which are worth specifying.
-
-1. **Overlapping Consumer Subscriptions**: if consumers specify overlapping
- subscriptions (e.g., `CustomerId == 0` and `CustomerId >= 0` ), BlazingMQ
- will not make any attempt to merge those subscriptions, and the two
- subscriptions will be treated independently of each other. **NOTE**: While
- overlapping subscriptions are supported as described in this and next
- bullet, having overlapping subscriptions is questionable and can be
- confusing, and generally speaking, should be avoided.
-
-2. **Order of Evaluation**: A very common scenario would be a queue having
- consumers with different subscriptions. When a message arrives in a queue,
- BlazingMQ primary node takes the greedy approach and routes the message to
- the first matching subscription. A natural question that arises is in what
- order will the primary node evaluate subscriptions? BlazingMQ primary node
- will attempt to order subscriptions by priority and evaluate them from
- highest to lowest priority. This will help provide some determinism to the
- order of evaluation and can also help users implement interesting
- scenarios. As an example, taking the case of overlapping subscriptions in
- the previous bullet, if `CustomerId == 0` subscription has priority 10 and
- `CustomerId >= 0` subscription has priority 5, BlazingMQ will always try to
- route a message with `CustomerId = 0` attribute to the `CustomerId == 0`
- subscription.
-
-3. **Order of Message Delivery**: Messages will be evaluated for matching
- subscriptions in the order that they arrive on the queue. So if a matching
- subscription exists for every message, messages will be dispatched to
- consumer(s) in order. Of course, if there are multiple consumers, each with
- different subscriptions, messages could be processed by out of order. This
- behavior will be same as priority as well as fan-out modes. Order of
- delivery will not be guaranteed in case messages are re-routed due to
- consumer crashes. Again, this behavior will be same as priority as well as
- fan-out modes.
-
-4. **Spillover to Lower Priority Consumers**: If multiple consumers attach to a
- queue with the same subscription but with different priorities, BlazingMQ
- will route messages only to the consumer with highest priority. If there are
- multiple consumers with highest priority, BlazingMQ will round-robin
- messages across them. More importantly, if highest priority consumers reach
- capacity (flow-controlled), messages will not be spilled to lower priority
- consumers. This behavior is similar to the existing logic in various queue
- modes in BlazingMQ.
-
-5. **Merging of Subscriptions**: In case multiple consumers specify the same
- subscription, BlazingMQ back-end will seamlessly merge them by combining the
- options advertised by the consumers for that subscription. For example, if
- consumer A subscribes to `CustomerId == 1000` with priority 10 and capacity
- X , and consumer B subscribes to `CustomerId == 1000` with priority 10 and
- capacity Y , the two subscriptions will be merged by an intermediate hop in
- BlazingMQ back-end and advertised to the primary node as `CustomerId == 1000`
- with priority 10 and capacity X + Y . Two subscriptions will be determined
- to be same if they compare equal lexicographically. Merging of subscriptions
- will ensure that load-balancing across consumers having same subscription
- works seamlessly.
-
-6. **Evaluating Expressions**: BlazingMQ primary node will match subscriptions
- by reading corresponding message properties from the message and evaluating
- the expression. For example, while evaluating the `CustomerId == 1000`
- expression, primary node will read `CustomerId` property from the message
- and compare its value against `1000` to determine a match. It is worth
- noting that BlazingMQ back-end can read a property in a message extremely
- efficiently (in `O(1)` time) – we essentially build a hashtable on the wire.
-
-## Expression Language
-
-The expression language for subscriptions implements basic string and integer
-manipulation, as a tiny subset of the C programming language.
-
-### Expression
-{:.no_toc}
-
-- An expression consists of a combination of:
- - Identifiers
- - Integer, string and boolean literals
- - Arithmetic, relational and boolean operators
- - Parentheses
-- Spaces, tabs and line feeds are ignored
-- The language has three types: integer, string, and boolean
-- The final result of an expression must be a boolean
-- Limited to 128 characters in length
-
-### Identifiers
-{:.no_toc}
-
-- Identifiers consist of a combination of upper and lower-case alphabetical
- letters, digits, and underscores.
-
-- The first character may not be an underscore.
-
-- Property names are case sensitive. Example of valid identifiers are: `ask`,
- `Ask`, `askPrice`, `ask_price`, `sp500`; note that `ask` and `Ask` are
- different identifiers.
-
-- Examples of _invalid_ identifiers are:
- - `_ask` (begins with underscore)
- - `1Y` (begins with digit)
- - `a+b` (would be parsed as three tokens: `a`, `+`, and `b`).
-
-- When an identifier is evaluated, the value of the eponymous property, in the
- current message, is returned.
-
-- Note that the identifiers in an expression are not necessarily all evaluated
- (see boolean operators below).
-
-### Integer Literals
-{:.no_toc}
-
-- Integer literals consist of a sequence of digits, possibly preceded by the
- minus sign.
-
-### String Literals
-{:.no_toc}
-
-- String literals consist of a sequence of characters, enclosed in double
- quotes.
-
-- To insert a double quote or a backslash in the sequence, prefix it
- with a backslash (thus: `"a\"b"` is the string `a"b`, and `"a\\b"` is the
- string `a\b`).
-
-- No character other than `"` or `\` is allowed after a `\`. This is the syntax
- of strings in the C language.
-
-### Boolean Literals
-{:.no_toc}
-
-- Boolean literals are `true` and `false`.
-
-### Arithmetic Operators
-{:.no_toc}
-
-- Arithmetic operators are:
- - `+`
- - `-`
- - `*`
- - `/`
- - `%` (modulus)
-- They require two integer arguments.
-
-### Relational Operators
-{:.no_toc}
-
-- Relational operators are:
- - `=`
- - `!=`
- - `<`
- - `<=`
- - `>`
- - `>=`
-
-- They require two arguments of the same type.
-
-### Boolean Operators
-{:.no_toc}
-
-- Boolean operators are:
- - `&&`
- - `||` (junctions)
- - `!` (negation).
-
-- Negation requires one argument
-- Junctions require two boolean arguments
-- Junctions are short-circuiting: if the left side of `&&` is `false`, or if
- the left side of `||` is `true`, the right side is not evaluated.
- - As a consequence, identifiers in an expression do not all need to have a
- corresponding property of the right type.
- - For example, `type == "i" && shares 1000 || shares == "all"` is valid as
- long as the value of `type` and the type of `shares` are properly correlated.
- `order == "limit" and limit == 0` can be used to detect the messages that
- represent a Limit Order with a silly limit value, and e.g. log an error
- message.
-
-### Operator Precedence
-{:.no_toc}
-
- - Operator precedence and associativity are the same as in C; from high
- precedence to low:
-
-| Operator | Associativity |
-| ----------------- | ------------- |
-| `!` | Right |
-| `*` `/` `%` | Left |
-| `+` `-` | Left |
-| `<` `<=` `>` `>=` | Left |
-| `==` `!=` | Left |
-| `&&` | Left |
-| `||` | Left |
-
-- Expressions between parentheses are evaluated first, starting with the
- innermost.
-
-- Operations with higher precedence are evaluated before operations
- with lower precedence. For example, `a*x+b>0` is evaluated as `((a*x)+b)>0`.
-
-- When two operators have the same precedence, they are evaluated from left to
- right, except for `!` which is evaluated right to left. For example, in
- `a-b-c` is evaluated as `(a-b)-c`. `!!ok` is evaluated as `!(!ok)`.
-
-For a formal specification, see [Flex
-rules](https://github.com/bloomberg/blazingmq/blob/main/src/groups/bmq/bmqeval/bmqeval_simpleevaluatorscanner.l)
-for the tokenizer and the [Bison
-grammar](https://github.com/bloomberg/blazingmq/blob/main/src/groups/bmq/bmqeval/bmqeval_simpleevaluatorparser.y).
-
----
diff --git a/docs/docs/getting_started/blazingmq_in_action.md b/docs/docs/getting_started/blazingmq_in_action.md
deleted file mode 100644
index 4cbfc27ae..000000000
--- a/docs/docs/getting_started/blazingmq_in_action.md
+++ /dev/null
@@ -1,152 +0,0 @@
----
-layout: default
-title: BlazingMQ in Action
-parent: Getting Started
-nav_order: 2
----
-
-# BlazingMQ in Action
-{: .no_toc }
-
-* toc
-{:toc}
-
-The BlazingMQ project comes with an out-of-the-box docker cluster meant for
-experimentation. We'll walk through bringing up a BlazingMQ broker, demonstrate
-some tooling, and highlight a few BlazingMQ features. This image is meant for
-demo purposes only.
-
-To begin, first clone the BlazingMQ
-[project](https://github.com/bloomberg/blazingmq) and run the following
-commands from repo's root directory:
-
-```sh
-$ docker compose -f docker/single-node/docker-compose.yaml up --build -d
-$ docker compose -f docker/single-node/docker-compose.yaml run bmqtool
-$ bmqtool -b tcp://bmqbrkr:30114
-```
-
-This command will bring up a BlazingMQ cluster with a default domain
-provisioned according to a config file. It will then drop you into a shell
-which can run a CLI program called `bmqtool`. Note that by default, BlazingMQ
-broker listens on port number 30114.
-
-## BlazingMQ CLI
-
-BlazingMQ comes with a CLI tool to help test and interact with the broker
-called `bmqtool`. This program has several uses, including acting as a producer
-and/or consumer application. We will walk through its most basic workflow: the
-client REPL. The included docker compose workflow should get you started:
-
-```sh
-$ docker compose -f docker/single-node/docker-compose.yaml up bmqtool
-
-> help
-```
-
-### Creating your first queue
-
-When you start up `bmqtool`, it should drop you into its default CLI mode. By
-default the tool does not begin a **session** with the broker in this mode. To
-open a connection with the BlazingMQ back-end, you'll need to `start` a
-**session**:
-
-```sh
-> start
-
-10MAY2023_15:27:19.305 (140195584415616) INFO m_bmqtool_interactive.cpp:140 --> Starting session: [ async = false ]
-...
-10MAY2023_15:27:19.311 (140195584415616) INFO m_bmqtool_interactive.cpp:151 <-- session.start(5.0) => SUCCESS (0)
-```
-
-{: .highlight }
-**Note:** `bmqtool` may print log lines hiding the CLI prompt `>`.
-The CLI will still take commands you type into the CLI even if the `>` is not visible.
-
-Now we may open our first **queue**! We will open the queue both as a producer
-and consumer. This means that any messages that we post will be echoed back to
-us. Note that a queue does not need to be created or declared upfront in
-BlazingMQ. It is automatically created under the hood by the system when it is
-opened for the first time.
-
-```sh
-> open uri
-
-open uri="bmq://bmq.test.persistent.priority/my-first-queue" flags="read,write,ack"
-```
-
-The `open` command takes two parameters: the **queue**'s URI and
-permissions. Note that we are passing *write* and *read* flags when opening the
-queue. Producing messages to **queues** is done through the `post`
-operation. Try it out now:
-
-```sh
-> post uri="bmq://bmq.test.persistent.priority/my-first-queue" payload=["hello world"]
-```
-
-Since we opened the queue in the *read* mode as well, the message will be
-echoed back to us. This can be checked by the `list` command:
-
-```sh
-> list
-
-12MAY2023_16:47:45.073 (139815379564416) INFO m_bmqtool_interactive.cpp:648 Unconfirmed message listing: 1 messages
- # 1 [40000000001068A4B4B275EDF7D3228F] Queue: '[ uri = bmq://bmq.test.persistent.priority/my-first-queue correlationId = [ autoValue = 2 ] ]' = 'hello world'
-```
-
-**Messages** are composed of a payload and an optional set of properties, which
-can act as metadata for the message. A property can be represented as a JSON
-object like so:
-
-```json
-{
- "name": "string",
- "value": "any",
- "type": "string"
-}
-```
-
-**Queues** are opened in namespaces called **domains.** If an opened **queue**
-doesn't exist, then it will be created. **Domains** also help define default
-configurations for **queues**. We'll look at how to configure custom
-**domains** later.
-
-Once a message is delivered to a queue, it may be read by consumers and
-confirmed. In BlazingMQ, this is done with the `confirm` operation.
-
-```sh
-> confirm uri="bmq://bmq.test.persistent.priority/my-first-queue" guid="40000000001068A4B4B275EDF7D3228F"
-```
-
-Notice as part of the `confirm` operation we must pass a GUID, which matches
-the one from the output of the `list` command.
-
-And that's it! We just ran a BlazingMQ client application which acted as a
-producer and a consumer for a queue, posted a message and consumed it!
-
-More hands-on examples of playing around with BlazingMQ can be found in
-[this](../more_fun_with_blazingmq) article, where we see some intermediate and
-advanced features of BlazingMQ in action.
-
-We also encourage readers to visit these articles to learn more about
-BlazingMQ:
-
-- [*Concepts*](../../introduction/concepts), which explains some terminology
- mentioned in this article, like *domain*, *queue*, *queue uri*, *message*,
- etc.
-
-- Our [C++](https://github.com/bloomberg/blazingmq/tree/main/src/tutorials)
- and
- [Java](https://github.com/bloomberg/bmq-sdk-java/tree/main/bmq-examples)
- tutorials.
-
-- C++ and Java API reference [documentation](../../../apidocs)
-
-- BlazingMQ [architecture](../../architecture/clustering)
-
-## Building
-
-[bin/build-ubuntu.sh](bin/build-ubuntu) and
-[bin/build-darwin.sh](bin/build-darwin) build BlazingMQ and its dependencies,
-respectively, on Ubuntu 22.04.2 LTS and Darwin 22.6.0. They can serve as a basis
-to build BlazingMQ on other systems.
\ No newline at end of file
diff --git a/docs/docs/getting_started/client_examples.md b/docs/docs/getting_started/client_examples.md
deleted file mode 100644
index a4992016d..000000000
--- a/docs/docs/getting_started/client_examples.md
+++ /dev/null
@@ -1,14 +0,0 @@
----
-layout: default
-title: Client Examples
-parent: Getting Started
-nav_order: 4
----
-
-# BlazingMQ Client Examples
-
-- C++ client examples can be found
-[here](https://github.com/bloomberg/blazingmq/tree/main/src/tutorials).
-
-- Java client examples can be found
-[here](https://github.com/bloomberg/blazingmq-sdk-java/tree/main/bmq-examples/src/main/java/com/bloomberg/bmq/examples).
diff --git a/docs/docs/getting_started/index.md b/docs/docs/getting_started/index.md
deleted file mode 100644
index 3f6b7f55b..000000000
--- a/docs/docs/getting_started/index.md
+++ /dev/null
@@ -1,9 +0,0 @@
----
-layout: default
-title: Getting Started
-nav_order: 3
-has_children: true
-permalink: /getting_started
----
-
-# [](#getting-started)Getting Started
diff --git a/docs/docs/getting_started/more_fun_with_blazingmq.md b/docs/docs/getting_started/more_fun_with_blazingmq.md
deleted file mode 100644
index a9cfa9d40..000000000
--- a/docs/docs/getting_started/more_fun_with_blazingmq.md
+++ /dev/null
@@ -1,230 +0,0 @@
----
-layout: default
-title: More Fun with BlazingMQ
-parent: Getting Started
-nav_order: 3
----
-
-# More Fun with BlazingMQ
-{: .no_toc }
-
-* toc
-{:toc}
-
-BlazingMQ has several features for handling message delivery. We'll go over a
-few common situations, each of which can be demoed using the `docker compose`
-workflow in [BlazingMQ in Action](../blazingmq_in_action).
-
-As a reminder, here's the setup for bmqtool and a single broker node:
-
-```sh
-$ docker compose -f docker/single-node/docker-compose.yaml up --build -d
-$ docker compose -f docker/single-node/docker-compose.yaml run bmqtool
-$ bmqtool -b tcp://bmqbrkr:30114
-```
-
-{: .highlight }
-**Note:** `bmqtool` may print log lines hiding the CLI prompt `>`.
-The CLI will still take commands you type into the CLI even if the `>` is not visible.
-
----
-
-## Redelivery
-
-Open a queue as a reader & writer, post a message, and observe that the
-consumer has received the message with `list`.
-
-```sh
-> start
-> open uri="bmq://bmq.test.persistent.priority/redelivery" flags="read,write"
-> post uri="bmq://bmq.test.persistent.priority/redelivery" payload=["hello world"]
-> list
- # 1 [400000000002FAC11F098B1B47064911] Queue: '[ uri = bmq://bmq.test.persistent.priority/redelivery correlationId = [ autoValue = 2 ] ]' = 'hello world'
-```
-
-Then shutdown the consumer without confirming the message. Start it again, and
-show that message was redelivered to it.
-
-```sh
-> bye
-$ bmqtool -b tcp://bmqbrkr:30114
-> start
-> open uri="bmq://bmq.test.persistent.priority/redelivery" flags="read"
-> list
- # 1 [400000000002FAC11F098B1B47064911] Queue: '[ uri = bmq://bmq.test.persistent.priority/redelivery correlationId = [ autoValue = 2 ] ]' = 'hello world'
-```
-
----
-
-## Round Robin
-
-Start two instances of `bmqtool`.
-
-```sh
-# bmqtool 1
-> start
-> open uri="bmq://bmq.test.persistent.priority/round-robin" flags="read,write"
-```
-
-```sh
-# bmqtool 2
-> start
-> open uri="bmq://bmq.test.persistent.priority/round-robin" flags="read"
-```
-
-In the first one, post the following:
-
-```sh
-# bmqtool 1
-> post uri="bmq://bmq.test.persistent.priority/round-robin" payload=["alice", "bob", "charlie"]
-```
-
-Now run `list` in each `bmqtool` instance. You should see each message was
-distributed in a round-robin fashion:
-
-```sh
-# bmqtool 1
-> list
- # 1 [40000000027B90A85281EBBE64922B68] Queue: '[ uri = bmq://bmq.test.persistent.priority/round-robin correlationId = [ autoValue = 2 ] ]' = 'alice'
- # 2 [40000200027B90A8DE20EBBE64922B68] Queue: '[ uri = bmq://bmq.test.persistent.priority/round-robin correlationId = [ autoValue = 2 ] ]' = 'charlie'
-```
-
-```sh
-# bmqtool 2
-> list
- # 1 [40000100027B90A8C96FEBBE64922B68] Queue: '[ uri = bmq://bmq.test.persistent.priority/round-robin correlationId = [ autoValue = 2 ] ]' = 'bob'
-```
-
----
-
-## Rebalancing
-
-If a consumer shuts down with unconfirmed messages, those messages will be
-redelivered to other active consumers. Start multiple consumers, and post a
-message:
-
-```sh
-# bmqtool 1
-> start
-> open uri="bmq://bmq.test.persistent.priority/rebalance" flags="read,write"
-> post uri="bmq://bmq.test.persistent.priority/rebalance" payload=["alice"]
-```
-
-```sh
-# bmqtool 2
-> start
-> open uri="bmq://bmq.test.persistent.priority/rebalance" flags="read"
-```
-
-`list` both consumers to show that one received the message and the other
-didn't:
-
-```sh
-# bmqtool 1
-> list
-Unconfirmed message listing: 1 messages
- # 1 [40000000007A7B1DCAB1E7ED0CDB2FD1] Queue: '[ uri = bmq://bmq.test.persistent.priority/rebalance correlationId = [ autoValue = 8 ] ]' = 'alice'
-```
-
-```sh
-# bmqtool 2
-> list
-Unconfirmed message listing: 0 messages
-```
-
-Now kill the consumer that received the message and `list` in the other to
-confirm that the message was resent:
-
-```sh
-# bmqtool 1
-> bye
-```
-
-```sh
-# bmqtool 2
-> list
-Unconfirmed message listing: 1 messages
- # 1 [40000000007A7B1DCAB1E7ED0CDB2FD1] Queue: '[ uri = bmq://bmq.test.persistent.priority/rebalance correlationId = [ autoValue = 19 ] ]' = 'alice'
-```
-
----
-
-## Consumer Priority
-
-- Show [consumer
- priorities](../../features/message_routing_strategies#consumer-priority-mode)
- in action. Bring up two consumers, one with higher and another with lower
- priority. See that all messages are routed to the higher priority consumer.
-
-Consumers can be configured with priority. A higher priority will cause
-messages to be delivered with preference. The default priority is 0. Let's open
-two consumers, one with the default and one with a higher priority:
-
-```sh
-# bmqtool 1
-> start
-> open uri="bmq://bmq.test.persistent.priority/priority" flags="read" consumerPriority=0
-```
-
-```sh
-# bmqtool 2
-> start
-> open uri="bmq://bmq.test.persistent.priority/priority" flags="read,write" consumerPriority=1
-> post uri="bmq://bmq.test.persistent.priority/priority" payload=["alice", "bob", "charlie"]
-```
-
-Now run `list` in each to show that the higher priority consumer received all
-three messages:
-
-```sh
-# bmqtool 1
-> list
-Unconfirmed message listing: 0 messages
-```
-
-```sh
-# bmqtool 2
-> list
-Unconfirmed message listing: 3 messages
- # 1 [400000000005289E9887B8D6F559F164] Queue: '[ uri = bmq://bmq.test.persistent.priority/priority correlationId = [ autoValue = 2 ] ]' = 'alice'
- # 2 [400001000005289EF052B8D6F559F164] Queue: '[ uri = bmq://bmq.test.persistent.priority/priority correlationId = [ autoValue = 2 ] ]' = 'bob'
- # 3 [400002000005289EFD2BB8D6F559F164] Queue: '[ uri = bmq://bmq.test.persistent.priority/priority correlationId = [ autoValue = 2 ] ]' = 'charlie'
-```
-
----
-
-## Subscriptions
-
-- Show [subscriptions](../../features/subscriptions) in action. Bring up two
- consumers, both specifying a different subscription expression, see that
- first message, which satisfies first expression, is routed to consumer 1.
- Similary, second message satisfying second expression is routed to consumer
- 2.
-
-Consumers can open queues that receive messages conditionally based on message
-properties.
-
-Bring up a consumer and open a queue with a subscription:
-
-```sh
-> start
-> open uri="bmq://bmq.test.persistent.priority/subscription" flags="read,write" subscriptions=[{"expression": "x > 0"}]
-```
-
-Now `post` a message that fails to match `x > 0` in the message properties and observe the consumer fails to receive it:
-
-```sh
-> post uri="bmq://bmq.test.persistent.priority/subscription" payload=["alice"] messageProperties=[{"name": "x", "value": "0", "type": "E_INT"}]
-> list
-Unconfirmed message listing: 0 messages
-```
-
-Now send a message with `x > 0`:
-
-```sh
-> post uri="bmq://bmq.test.persistent.priority/subscription" payload=["alice"] messageProperties=[{"name": "x", "value": "1", "type": "E_INT"}]
-> list
- # 1 [40000400011AFF060B5DC6A7FA905D3D] Queue: '[ uri = bmq://bmq.test.persistent.priority/subscription correlationId = [ autoValue = 24 ] ]' = 'alice', with properties: [ x (INT32) = 1 ]
-```
-
----
diff --git a/docs/docs/home.md b/docs/docs/home.md
deleted file mode 100644
index 9511ad039..000000000
--- a/docs/docs/home.md
+++ /dev/null
@@ -1,44 +0,0 @@
----
-layout: home
-title: Home
-nav_order: 0
-description: ""
-permalink: /
----
-
-## Clustering and Quorum-based Replication
-
-Built on the [solid foundation](docs/architecture/clustering) of
-industry-standard best practices in the domain of distributed systems to
-provide highly-available queues.
-
-{% include animation.html asset_path="assets/animations/animations/bmq/message-paths/index.html" height="44%" %}
-
----
-
-## Message Routing Strategies
-
-Provides a set of [message routing
-strategies](docs/features/message_routing_strategies) to help applications
-implement complex message processing pipelines.
-
-### Routing Strategy - Work Queue
-
-{% include animation.html asset_path="assets/animations/animations/bmq/work-queue-mode/index.html" height="44%" %}
-
-### Routing Strategy - Consumer Priority
-
-{% include animation.html asset_path="assets/animations/animations/bmq/priority-mode/index.html" height="44%" %}
-
----
-
-## Multi-Hop Network Topology
-
-Supports a unique multi-hop network
-[topology](docs/architecture/network_topology) leading to a distribution tree
-for each queue, thereby leading to network bandwidth savings for certain use
-cases.
-
-{% include animation.html asset_path="assets/animations/animations/bmq/distribution-tree/index.html" height="82%" %}
-
----
diff --git a/docs/docs/installation/configuration.md b/docs/docs/installation/configuration.md
deleted file mode 100644
index fec94a83a..000000000
--- a/docs/docs/installation/configuration.md
+++ /dev/null
@@ -1,179 +0,0 @@
----
-layout: default
-title: Configuration
-parent: Installation
-nav_order: 2
----
-
-# BlazingMQ Configuration
-{: .no_toc }
-
-* toc
-{:toc}
-
-BlazingMQ is a highly flexible system, with the BlazingMQ message broker at its
-core. A broker, or _node_, participates in a _cluster_, which manages a
-collection of _domains_. This leads to three configurable entities in the
-system -- BlazingMQ message broker, BlazingMQ cluster and BlazingMQ domain.
-Configurations for all of them are expressed as a set of JSON files, located in
-a directory passed to message broker process (`bmqbrkr`) on the command line.
-
-The structure of the directory is:
-
-* `root/`
- * `bmqbrkrcfg.json`
- * `clusters.json`
- * `domains/`
- * `domain1.json`
- * `domain2.json`
- * ...
-
-
-## Broker Configuration
-
-`bmqbrkrcfg.json` contains configuration that is specific to an instance of the
-broker, i.e. a single process running `bmqbrkr`. It specifies various low-level
-parameters, like number of worker threads, initial size of memory pools, the
-location and the format of the log files, etc.
-
-The more important parameters in this file are:
-
-* `appConfig/hostName` \
- The name of the host, as it will appear in the cluster configuration
- file. Can be overriden on the command line with `-h` or `--hostName`.
-
-* `appConfig/brokerInstanceName` \
- The name of the broker instance, used to identify a broker if more than
- one broker runs on the same host. Set to "default" otherwise. Can be
- overriden on the command line with `-i` or `--instanceId`.
-
-* `appConfig/hostDataCenter` \
- The name of the "data center" of the host. In some circumstances, a broker
- will prefer to use a connection with another broker in the same data
- center, for performance. Can be overriden on the command line with `-d` or
- `--hostDataCenter`.
-
-* `appConfig/hostDataCenter/networkInterfaces/tcpInterface/port` \
- The port that the broker listens to. Can be overriden on the command line
- with `-p` or `--port`.
-
-For a complete list of settings, see the configuration
-[schema](https://github.com/bloomberg/blazingmq/blob/main/src/groups/mqb/mqbcfg/mqbcfg.xsd).
-The top level object is `Configuration`. For a sample configuration, see the
-Docker
-[example](https://github.com/bloomberg/blazingmq/blob/main/docker/cluster/config/bmqbrkrcfg.json).
-
----
-
-## Cluster Configuration
-
-`clusters.json` specifies all the clusters known to the broker. It contains
-two optional keys - `myClusters` and `proxyClusters`. The associated values
-are arrays of objects. Either keys are optional, and either arrays can be
-empty, but not at the same time.
-
-The objects in the `myClusters` array each specify a cluster that a broker
-instance is a member, or _node_, of. They consist of:
-
-* `name` \
- The name of the cluster.
-
-* `nodes` \
- An array of objects describing the nodes in the cluster. They consist of:
- * `name` \
- The name of the node.
- * `id` \
- An integer node identifier, unique within the cluster.
- * `dataCenter` \
- The data center of the node. Proxies will use connections to brokers
- in the same data center, if available.
- * `transport/tcp/endpoint` \
- A string in the form `"tcp://{hostName}:{port}"`
-
-* `partitionConfig` \
- Specifies the location of the
- [partitions](../../architecture/clustering#storage-shard) used to store
- the messages, maximum file sizes, whether to pre-allocate and prefault
- storage, etc.
-
-* `elector` \
- Settings for the leader election subsystem: quorum, maximum attempts to
- open a queue, and various timeouts.
-
-* `queueOperations` \
- Settings for queue operations (mostly timeouts).
-
-* `clusterMonitorConfig` \
- Controls how long transitional cluster states can perdure before raising
- an alert in the broker logs.
-
-* `messageThrottleConfig` \
- Sets limits on the rate at which a producer can post messages.
-
-The objects in the `proxyClusters` array specify the clusters the broker can
-proxy to. They are similar to the `myClusters` objects, but they lack the
-`masterAssignment`, `partitionConfig` and `elector` keys.
-
-For a complete list of settings, see the configuration
-[schema](https://github.com/bloomberg/blazingmq/blob/main/src/groups/mqb/mqbcfg/mqbcfg.xsd).
-The top level object is `ClustersDefinition`. For a sample configuration, see
-the Docker
-[example](https://github.com/bloomberg/blazingmq/blob/main/docker/cluster/config/clusters.json).
-
----
-
-## Domain Configurations
-
-Each file corresponds to one BlazingMQ domain that the broker can handle. It
-contains either a _definition_ or a _redirection_. For a complete list of
-settings, see the
-[schema](https://github.com/bloomberg/blazingmq/blob/main/src/groups/mqb/mqbconfm/mqbconf.xsd).
-The top level object is `DomainVariant`. For sample configurations, see the
-Docker
-[example](https://github.com/bloomberg/blazingmq/tree/main/docker/cluster/config/domains).
-
-### Domain Definition
-
-The more important parameters in the `definition` object are:
-
-* `definition/location` \
- The name of the cluster to contact to open a queue in the domain. It must
- be a name listed in the `myClusters` section of `clusters.json`, in which
- case the broker handles the request; or a name listed in `proxyClusters`,
- in which case the broker forwards the request.
-
-* `definition/parameters/mode` \
- The queue mode, either `priority`, `broadcast`, or `fanout`.
-
-* `definition/parameters/maxDeliveryAttempts` \
- The maximum number of times the cluster should attempt to deliver the same
- message. Any value other than zero enables [poison pill
- detection](../../features/poison_pill_detection).
-
-* `definition/parameters/consistency` \
- `eventual` or `strong`. Select
- the [consistency](../../architecture/clustering#eventual-vs-strong-consistency-in-replication)
- model.
-
-* `definition/parameters/storage/config` \
- `fileBacked` or `inMemory`. Specifies whether messages are kept on disk
- (typical for priority and fanout domains), or in memory (required for
- broadcast domains, allowed for 1-node clusters).
-
-* `definition/parameters/mode/fanout/appIDs` \
- For fanout mode only, a list of appId names.
-
-The other parameters configure per-domain and per-queue message and byte
-quotas, maxima for the number of producers, consumers, and queues, etc.
-
-### Domain Redirection
-
-Redirection is similar to a symbolic link, i.e. it gives an additional name to
-an existing domain. Unlike symlinks, only one level of redirection is allowed,
-and it is performed only by the first broker that handles the open queue
-request.
-
-A redirection consists of a single key-value pair: `redirect` and the new
-domain name.
-
----
diff --git a/docs/docs/installation/deployment.md b/docs/docs/installation/deployment.md
deleted file mode 100644
index a44c35ec3..000000000
--- a/docs/docs/installation/deployment.md
+++ /dev/null
@@ -1,159 +0,0 @@
----
-layout: default
-title: Deployment
-parent: Installation
-nav_order: 3
----
-
-# BlazingMQ Deployment
-{: .no_toc }
-
-* toc
-{:toc}
-
-As mentioned in the [configuration](../configuration) article, BlazingMQ is a
-highly flexible system, with the BlazingMQ message broker at its core. A
-broker, or _node_, participates in a _cluster_, which manages a collection of
-domains. A cluster can consist of a single node, which results in better speed;
-or of several nodes, which results in better availability and reliability in
-presence of network or other failures.
-
-Designing a BlazingMQ system thus involves deciding:
-
-- how many clusters to create
-- how many brokers to assign to each cluster
-
-Once this is done, it must be expressed as a set of JSON files, as described in
-the [configuration](../configuration) article, and placed in a configuration
-directory, which is passed on the command line to the broker when it is
-started. As it operates, the broker reads and writes various files.
-`bmqbrkrcfg.json` specifies the _log_ directory; `clusters.json` specifies, for
-each cluster, a _storage_ and an _archive_ directory. These three directories
-must be created prior starting the broker.
-
-When it starts, the broker creates a file (`bmqbrkr.pid`) and a named pipe
-(`bmqbrkr.ctl`) in the current directory, which must thus be writable.
-
-Brokers operate in the background, as "services" or "daemons". Thus, it often
-makes sense to run them under a dedicated Unix account. However, this is not
-mandatory: an application that runs under a normal user account could run a
-BlazingMQ broker as part of its implementation.
-
-The following sections describe in more details two typical configurations, and
-implements them in a set of Docker containers. Together, they provide a
-template for deployment that should cover the majority of use cases, and
-provide a good starting point for creating more complex installations.
-
-Much of the
-[Dockerfile](https://github.com/bloomberg/blazingmq/blob/main/docker/Dockerfile)
-has to do with buiding the broker from the sources, drawing the dependencies
-from various sources. In the end, `bmqbrkr` and `bmqtool` are installed in
-`/usr/local/bin`.
-
-The section relevant to deployment is at the bottom:
-
-```sh
-RUN addgroup bmq \
- && adduser bmq --home /var/local/bmq --system --ingroup bmq --shell /usr/bin/bash
-USER bmq
-WORKDIR /var/local/bmq
-RUN mkdir -p logs storage/archive
-```
-
-In English, these lines:
-* create a `bmq` group
-* create a `bmq` system user, with `/var/local/bmq` as its home directory
-* in the home directory, create log, storage and archive directories
-* set the default user for Docker commands to `bmq`, and the default current
- directory to `bmq`'s.
-
-The resulting image does not contain a configuration directory. Instead, each
-example maps a `config` directory on the host to `/etc/local/bmq` inside the
-container(s).
-
----
-
-## Single Node
-
-In this example (see the [docker-compose.yaml](https://github.com/bloomberg/blazingmq/blob/main/docker/single-node/docker-compose.yaml) file),
-a single machine, called _earth_, runs a broker that acts as the single node of
-a cluster named "local". The `hostName` in
-[`bmqbrkrcfg.json`](https://github.com/bloomberg/blazingmq/blob/main/docker/single-node/config/bmqbrkrcfg.json)
-is set to "earth". "localhost" would work as well, but an arbitrary value would
-not, as the broker resolves the name in `hostName`.
-
-The `hostDataCenter` is set to "UNUSED"; any value work, as this setting
-is irrelevant in single-node configurations.
-
-The broker is started with the command:
-
-```sh
-/usr/local/bin/bmqbrkr /etc/local/bmq
-```
-
-Note that this counts on the Docker image setting `bmq` as the default user,
-and `/var/local/bmq` as the default directory.
-
-The example can be run (from the root of the BlazingMQ source directory) with:
-
-```sh
-$ docker-compose -f docker/single-node/docker-compose.yaml up --detach
-```
-
-To interact with the broker:
-```sh
-$ docker-compose -f docker/single-node/docker-compose.yaml exec bmqbrkr bmqtool
-```
-
-```sh
-> start
-> open uri="bmq://bmq.test.persistent.priority/qqq" flags="read,write"
-> post uri="bmq://bmq.test.persistent.priority/qqq" payload=["foo"]
-> list
-```
-(etc)
-
----
-
-## Cluster
-
-In this example (see the [docker-compose.yaml
-file](https://github.com/bloomberg/blazingmq/blob/main/docker/cluster/docker-compose.yaml)),
-four machines in two data centers (_gallifrey_ and _skaro_ in _WHO_, _pacem_
-and _lusus_ in _HYPERION_) each run a broker. They are all nodes in the
-_planets_ cluster.
-
-It looks each machine needs its own set of configuration files, or, at least,
-its own `bmqbrkrcfg.json`, because, on each machine, the value of `hostName`
-needs to be the machine's name. Moreover, `hostDataCenter` must be set to
-either _WHO_ or _HYPERION_, depending on the machine. Fortunately, these
-settings can be overriden from the command line, with the `-h/--hostName` and
-`-d/--hostDataCenter`
-
-Thus, on _gallifrey_, the broker is started with the command:
-
-```sh
-/usr/local/bin/bmqbrkr -h gallifrey -d WHO /etc/local/bmq
-```
-
-And on _pacem_:
-
-```sh
-/usr/local/bin/bmqbrkr -h pacem -d HYPERION /etc/local/bmq
-```
-
-The example can be run (from the root of the BlazingMQ source directory) with:
-
-```sh
-$ docker-compose -f docker/cluster/docker-compose.yaml up --detach
-```
-
-This example also creates an additional machine - _earth_ - from which
-`bmqtool` can be run. Since the tool and the broker are not on the same machine
-this time, it is necessary to specify the broker's endpoint:
-
-```sh
-$ docker-compose -f docker/cluster/docker-compose.yaml run bmqtool bash
-bmq@earth:~$ bmqtool -b tcp://skaro:30114
-> start
-```
diff --git a/docs/docs/installation/index.md b/docs/docs/installation/index.md
deleted file mode 100644
index b2ba17774..000000000
--- a/docs/docs/installation/index.md
+++ /dev/null
@@ -1,9 +0,0 @@
----
-layout: default
-title: Installation
-nav_order: 7
-has_children: true
-permalink: /installation
----
-
-# [](#installation)Installation
diff --git a/docs/docs/introduction/architecture_overview.md b/docs/docs/introduction/architecture_overview.md
deleted file mode 100644
index fcba0fc9d..000000000
--- a/docs/docs/introduction/architecture_overview.md
+++ /dev/null
@@ -1,187 +0,0 @@
----
-layout: default
-title: Architecture Overview
-parent: Introduction
-nav_order: 4
----
-
-# Architecture Overview
-{: .no_toc }
-
-* toc
-{:toc}
-
-Here's a high-level overview of BlazingMQ's architecture,
-including details like clustering, typical network topology, and some common
-terminology.
-
-For additional information on BlazingMQ's's architecture and internal design,
-please see the [*Architecture*](../../../architecture) section.
-
-## Introduction
-
-BlazingMQ's infrastructure consists of message brokers and clients (producer and
-consumer applications) running in a distributed environment. Clients don't
-talk to each other directly -- they only connect to BlazingMQ brokers. Client libraries
-are available in C++, Java, and Python.
-
-In BlazingMQ, a queue represents a logical stream of data over which producer
-and consumer applications exchange messages. Queues enable producers and
-consumers to temporally and spatially isolate from one another, thereby ensuring
-they are decoupled.
-
-Queues are persisted on disk and replicated across machines in the BlazingMQ
-cluster. Queues are grouped into domains: a domain provides a namespace for
-applications and encapsulates common configuration associated with the queues,
-like routing mode, the queue's storage quota, message TTL, and other parameters.
-See also [*Concepts*](../concepts) for more details about BlazingMQ
-domains.
-
-BlazingMQ optionally supports the notion of tiers -- a queue can have multiple
-isolated instances across different tiers, such as *dev*, *alpha*, *beta*, *uat*,
-*qa*, *prod*, etc.
-
-BlazingMQ provides the following guarantees for messages:
-
-- **Guarantee of Delivery**
-
- - Any message posted by a producer application that is successfully accepted
- by BlazingMQ is guaranteed to be delivered to the consumer application(s) *at
- least once*. This means that consumers may receive duplicates in case of a
- software crash, hardware issues or network glitch. Note that a [*broadcast
- mode*](../../features/message_routing_strategies#broadcast-mode) routing
- strategy is an exception to this rule, since it provides *at most once* delivery
- guarantee by design.
-
- - Note that not all messages posted by a producer application are guaranteed
- to be successfully accepted by BlazingMQ. A message can be rejected by
- BlazingMQ due to reasons like a queue's storage quota limit being reached, a
- long-running network issue, etc. So, to rephrase the above bullet,
- BlazingMQ either reliably delivers the message to the consumer or reliably
- tells the producer that the message was not accepted.
-
-- **Guarantee of Ordering**
-
- - Messages are delivered in the publishing order, unless the queue has
- multiple consumers attached to it, along with a configuration (static or
- dynamic) which allows multiple consumers to consume messages from the
- queue concurrently.
-
----
-
-## Clustering
-
-### Typical Deployment
-
-
-
-The above figure shows the typical deployment of a BlazingMQ setup. The four nodes
-in the middle represent a BlazingMQ cluster where queues are persisted and
-replicated. The blue node represents the queue's primary node, which is in charge of
-managing the queue (replication, message routing, etc.). Orange nodes
-represent replicas which, as the name suggests, are in charge of storing a
-local copy of the queue.
-
-Producer/consumer applications can connect to any node in the BlazingMQ cluster
-instead of always being required to connect to the primary node. If a client
-application connects to a replica node, the replica will automatically make the
-primary node aware of the client application, and all messages flowing to/from
-the client application will go through the replica.
-
-More details about BlazingMQ's clustering and alternative deployments can be
-found [here](../../architecture/clustering), as well as in other entries in the
-[*Architecture*](../../../architecture) section.
-
----
-
-## Terminology
-
-This section reviews some common terminology used in BlazingMQ. Additional
-details about some of these concepts can be found [here](../concepts).
-
-- *BlazingMQ Cluster*: A group of machines where queues are hosted. The
- typical size of a BlazingMQ cluster varies from 3-7 machines. Application
- tasks generally don't run on BlazingMQ cluster machines, unless the BlazingMQ
- cluster is co-located. Co-location can help achieve the lowest possible latency.
-
-- *BlazingMQ Domain*: A namespace owned by an application using BlazingMQ. A
- domain encapsulates various configuration parameters like queue quota,
- message expiration time (TTL), queue mode (priority, fan-out, broadcast),
- consistency level (eventual or strong), etc. In addition, a domain can also
- capture the list of tiers. A domain is represented as `bmq://foo.bar.baz`.
- See [`bmqt::URI`](../../apidocs/cpp_apidocs/group__bmqt__uri.html) for more
- details.
-
-- *Queue*: A queue represents a logical stream of data in BlazingMQ over which
- producer and consumer applications exchange messages. A queue enables
- producers and consumers to temporally and spatially isolate from one another,
- thereby ensuring that they are decoupled from each other. A queue is
- identified by a URI, which takes the form of `bmq://foo.bar.baz/myQueueName`
- where `bmq://foo.bar.baz` is the domain and `myQueueName` is the queue name.
- See [`bmqt::URI`](../../apidocs/cpp_apidocs/group__bmqt__uri.html) for more
- details.
-
-- *Producer*: A BlazingMQ client application which sends ("posts") messages to
- a queue.
-
-- *Consumer*: A BlazingMQ client application which receives ("consumes")
- messages from a queue. An application can be both the producer and consumer
- for the same or different queues.
-
-- *BlazingMQ Broker*: A back-end application which is part of the BlazingMQ
- framework, and participates as a member of a BlazingMQ cluster. A broker can
- be either a primary or a replica for a queue hosted on that cluster.
-
-- *BlazingMQ Proxy*: An *optional* back-end application which is part of the
- BlazingMQ framework, and runs on client machines. A proxy is not a member of
- a BlazingMQ cluster, but communicates with the cluster on behalf of client
- applications. It's the same executable as the BlazingMQ broker but with a
- different configuration. In fact, a BlazingMQ broker instance can act as a
- proxy for some queues and a cluster member for other queues, though such
- configurations are very rare.
-
-- *Primary*: The node in a BlazingMQ cluster which is managing a queue. All
- writes for a queue go though its primary node. The primary node is also in charge
- of a queue's replication to other members in the cluster. At a given
- time, there can be only one primary mode for a given queue.
-
-- *Replica*: A node in BlazingMQ cluster which holds a copy of the queue.
- Replicas cannot initiate a write operation on the queue, although they push
- new messages to consumer applications when requested to do so by the primary node.
- A replica can be promoted to a primary node if the existing primary node goes
- down. All nodes in a BlazingMQ cluster which are not the primary node for a queue
- act as its replicas.
-
-- *Leader*: A node in a BlazingMQ cluster which is in charge of managing the
- BlazingMQ cluster, including things like cluster metadata, cluster
- membership, health of cluster nodes, list of partitions, list of all active
- queues, primary node(s), etc. A leader's goal is to ensure that every node
- in the cluster has up-to-date metadata information, so that the node can make
- the right decision. A node in a BlazingMQ cluster can act as both a leader and a primary.
-
-- *PUT*: A message sent (or "posted") by the producer to the queue.
-
-- *ACK*: An acknowledgement sent by BlazingMQ to the producer, informing the
- producer if the *PUT* message was successfully accepted or not. Note that
- the API to post a *PUT* message is asynchronous, and thus, an *ACK* message
- delivers the result to the producer. Also note that while BlazingMQ tries as
- much as possible to accept the *PUT* message and send successful *ACK*s,
- there are scenarios where a producer may receive a negative *ACK*, which
- indicates that *PUT* message could not be accepted by BlazingMQ. Reasons for
- a negative *ACK* could be the queue quota getting full, a long-standing
- network issue, etc. Note, what BlazingMQ guarantees is that the producer
- will receive an *ACK* for every *PUT* message.
-
-- *PUSH*: A message sent by BlazingMQ to the consumer. This is effectively the
- same message as the corresponding *PUT*.
-
-- *CONFIRM*: A message sent by the consumer to BlazingMQ indicating it has
- processed a specific *PUSH* message. Once a *CONFIRM* message is received,
- BlazingMQ is free to mark that message as deleted in the queue. Note that a
- consumer can send *CONFIRM* messages in any order. For example, if a
- consumer receives 5 *PUSH* messages, it can choose to send *CONFIRM*s for
- messages 2 and 4, and keep messages 1, 3 and 5 for later processing. This is
- a very powerful feature and this is what enables BlazingMQ to implement work
- queues, as well as for consumers to implement multi-threaded logic.
-
----
diff --git a/docs/docs/introduction/comparison.md b/docs/docs/introduction/comparison.md
deleted file mode 100644
index c2365e4bd..000000000
--- a/docs/docs/introduction/comparison.md
+++ /dev/null
@@ -1,335 +0,0 @@
----
-layout: default
-title: Comparison With Alternative Systems
-parent: Introduction
-nav_order: 5
----
-
-# Comparison With Alternative Systems
-{: .no_toc }
-
-* toc
-{:toc}
-
-## Introduction
-
-We compare BlazingMQ with two relevant and prominent open source distributed messaging systems -- RabbitMQ and Apache Kafka. While Apache
-Kafka doesn’t advertise itself as a message queue system, we include it here
-because it is widely used for its messaging features and overlaps with both
-BlazingMQ and RabbitMQ as far as its features and usage are concerned.
-
-In the enterprise environment where BlazingMQ originated, all three systems
-have been offered as managed services in production and complemented each other
-in a complete messaging infrastructure package. Some of the insights presented
-in this comparison are drawn from the wealth of knowledge accumulated over the
-years by offering all three technologies as a service.
-
-One of the goals of this document is to demonstrate that there is a unique
-combination of simplicity, performance, fault tolerance, and features that
-makes BlazingMQ competitive as a distributed messaging system.
-
-We also highlight that there may be no simple answer to the question “Which
-messaging system should I use?” due to the complexity of factors involved. Readers looking for a straightforward answer to that question will likely be
-disappointed. We deliberately avoid making a recommendation for a specific
-messaging system because, as we will see, each system is unique and better than
-the others in some aspects while lacking in other areas. Potential users are
-encouraged to carry out their own research and comparison of these systems,
-keeping in mind their current and potential future use cases.
-
-We assume the reader has a high-level understanding of distributed
-messaging systems. However, in order to keep the document accessible to a
-wider audience, we deliberately avoid using terminology specific to any of the
-systems under consideration.
-
-In order to understand and compare these three systems, we decompose their
-architecture and functionality across critical dimensions like storage and
-replication, message routing, fault tolerance, features, etc. In the next
-sections, we survey these systems across these dimensions.
-
----
-
-## Storage
-
-### Delivery Guarantees and Message Lifetime
-
-All three messaging systems offer ‘at-least once’ message delivery guarantee
-which requires persistence (storage) and inevitably, replication. Apart from
-storage, another important aspect in the life cycle of produced messages is
-data routing (i.e., the logic of distributing messages among consumers). Kafka
-stands apart from BlazingMQ and RabbitMQ
-([Streams](https://www.rabbitmq.com/streams.html) aside) here by decoupling
-storage from data routing. Reads in Kafka are not destructive (i.e., a
-message’s lifetime does not depend on message delivery or message processing).
-Messages are deleted according to the configured cleanup policy (e.g., based on
-time, size, compaction). This design choice permits Kafka consumers to read
-from the “past” (rewind or replay). This also requires each Kafka consumer to
-know the offset from where to read the data.
-
-On the other hand, BlazingMQ and RabbitMQ keep messages only until they are
-consumed. Consumers in these systems cannot go back to access messages which
-were previously processed.
-
-### Storage and Routing
-
-BlazingMQ and RabbitMQ further differ in message storage in the following ways:
-
-- BlazingMQ stores messages first and then routes, while RabbitMQ routes (via
- Exchange) before storing (to a queue). BlazingMQ’s approach ensures that the
- cost of storage and replication is constant, irrespective of fan-out ratio
- (number of consumers); however, this requires BlazingMQ to know the fan-out
- ratio up front. Meanwhile, RabbitMQ's approach offers the flexibility of any
- number of consumers joining the fan-out routing. But this comes at the expense of higher
- costs (CPU, disk, and network bandwidth), proportional to the number of
- routing destinations.
-
-- At the storage level, BlazingMQ differs from RabbitMQ by maintaining a log of
- messages on disk. In other words, BlazingMQ does not delete a message from
- the disk right away; it simply marks it as deleted or consumed. It deletes the
- entire log when the log reaches its maximum configured size and all messages
- in the log have been marked as consumed. On the other hand, RabbitMQ classic
- queues keep track of messages in Erlang’s distributed database (Mnesia) and
- deletes the messages from disk as they are consumed. At present, RabbitMQ quorum
- queues store the complete message in the Raft log (stored on disk) and
- truncate the log when safely possible.
-
----
-
-## Data Routing
-
-As mentioned earlier, data routing is the logic of distributing messages among
-consumers. Consumers can compete with each other, advertise
-different priorities, request selective messages (interest-based routing), or
-even be absent while messages are produced.
-
-All three messaging systems recognize simple routing modes such as round-robin
-and fan-out, and also dynamically adapt to changing consumers. As we will see
-below, BlazingMQ and RabbitMQ share several similarities in data routing and
-provide more flexibility, while Kafka stands out with its design choices in
-routing.
-
-### Load Balancing
-
-In BlazingMQ and RabbitMQ, consumer(s) explicitly attach to queue(s); the
-systems do not attempt to assign consumers to queues. On one hand, this
-gives consumers finer control over which queues to consume from. On the
-other hand, this requires them to know queue names a priori. Consumer groups
-in Kafka, however, assign partitions to consumers and ensures that every
-partition is assigned. Alternatively, consumers can assign a specific set of
-partitions manually.
-
-In both BlazingMQ and RabbitMQ, multiple consumers can attach to a queue
-configured in a round-robin mode, and the system will load balance messages
-across all consumers. In other words, adding new consumers to a queue
-automatically increases processing capacity. This may not be possible in Kafka
-if there are no partitions to consume from. For example, if a fifth consumer
-joins a Kafka topic with four partitions (and four consumers), the new consumer
-will stay idle. In Kafka, load balancing of messages can occur across
-partitions in a topic from the producer side (i.e., messages can be posted
-across different partitions in a topic at the time they are produced). In
-other words, unlike in BlazingMQ and RabbitMQ, adding a new consumer in Kafka
-does not decrease the load on existing consumers; adding new partitions does.
-
-### Consumer Priority
-
-BlazingMQ and RabbitMQ both support the notion of priority in consumers (not to
-be confused with priorities in queues, which are supported by RabbitMQ -- with some caveats). Priorities in consumers allow applications to control the
-flow of messages across their consumer instances and implement a desired
-failover behavior (messages will flow to lower priority consumers when higher
-priority consumers go away). In the case of RabbitMQ specifically, a large
-enough flow can direct messages to lower priority consumers even while higher
-priority consumers are still present. Kafka, however, does not support
-priorities in consumers. Furthermore, failover of consumers in Kafka may lead
-to a significant change in the partition <=> consumer assignment mapping.
-
-### Topic Based Routing
-
-Both BlazingMQ and RabbitMQ support topic-based routing, where queues/consumers
-can specify criteria (a filter or an expression) such that only those messages
-which satisfy the given criteria are routed to the consumer(s)/queues(s). In
-other words, topic-based routing gives applications the ability to support
-heterogeneous consumers by breaking the stream of data into a dynamic,
-non-fixed number of independent logical sub-streams using flexible criteria and
-produced data.
-
-### Broadcast Routing Strategy
-
-BlazingMQ supports [*broadcast
-strategy*](../../features/message_routing_strategies#broadcast-mode) for
-message routing which provides ‘at-most once’ delivery guarantees. This is a
-direct consequence of the fact that, in this strategy, BlazingMQ neither
-persists messages on disk nor buffers them in memory. Instead, they are
-immediately dispatched to the consumers attached to the queue at that instant
-and then "dropped" by BlazingMQ. BlazingMQ makes no effort to keep messages
-for consumers which may arrive at a later time. As a result of no buffering,
-persistence, or replication of messages, broadcast strategy has
-[better](../../performance/benchmarks#broadcast-routing-strategy) latency and
-throughput numbers compared to other routing strategies. To the best of our
-knowledge, this routing strategy is unique to BlazingMQ. This strategy can be
-useful for scenarios where consistently lower latency is extremely
-important and occasional data loss is acceptable.
-
----
-
-## Cluster Topology
-
-The topology of the system affects both its functionality (particularly data
-routing), as well as performance. The topology of a system includes composition and placement of cluster nodes, as well as any other participating nodes.
-
-### Cluster Membership
-
-BlazingMQ replicates data across a fixed sized cluster. All cluster nodes in
-BlazingMQ are equal as far as storage is concerned. In other words, every
-cluster node in BlazingMQ has a full copy of the data. This means that the replication factor for every queue in a
-BlazingMQ cluster is equal to the size of the cluster. This property has an interesting outcome – adding a new node
-in a BlazingMQ cluster increases its availability, but not throughput or
-capacity. While this approach simplifies BlazingMQ’s replication and cluster
-state management logic, it comes at the expense of fixed cluster size. Cluster
-size or membership in BlazingMQ can be changed only by restarting all nodes in
-the cluster and requires some operational overhead.
-
-RabbitMQ supports a wide range of possible deployment/replication
-topologies. Clusters can change size at runtime, and individual queues can
-operate with different - and dynamically configurable - replication sizes and
-patterns (provided that policies on both the broker and clients are configured
-appropriately).
-
-Kafka dissociates replication factor with cluster size, and adding more nodes
-in a Kafka cluster increases the cluster’s capacity. Kafka achieves this by
-spreading partition replicas across the cluster such that each node in the
-cluster replicates a subset of all the partitions hosted in the cluster.
-
-### Dependency on Other Systems
-
-BlazingMQ does not depend on any other software framework. RabbitMQ runs on
-the Erlang VM. Both systems are self-sufficient and can host their data, as
-well as metadata, by themselves. This is unlike Kafka, which requires Apache
-ZooKeeper for storing metadata. However, Kafka is in the process of getting
-rid of its dependency on ZooKeeper and will soon store its data and metadata
-within the Kafka cluster itself. Lastly, Kafka runs on the Java Virtual Machine.
-
-### Proxies
-
-A unique feature of BlazingMQ is the presence of proxy nodes. BlazingMQ
-applications have the option to connect to proxies instead of connecting
-directly to the BlazingMQ cluster nodes. Proxies don’t participate in data
-storage and replication, but they are part of routing, and are particularly helpful
-with very large fan-out ratio scenarios. Proxies also protect applications
-from transient network issues in the BlazingMQ cluster by providing seamless
-buffering, retransmission, or retries of messages as appropriate.
-
-As a result of proxies, BlazingMQ dynamically creates a distribution tree for every queue,
-which is rooted at the queue’s primary node. Replicas are the primary's child nodes,
-and proxies are replicas’ child nodes. Producer and consumer applications
-for the queue appear as leaf nodes in this tree. See [*Network
-Topology*](../../architecture/network_topology) for more details.
-Unlike BlazingMQ, applications using RabbitMQ and Kafka connect directly to
-cluster nodes, and neither of these systems support the notion of proxies, as found in BlazingMQ.
-
----
-
-## Fault Tolerance
-
-All three systems support 'at-least once' guarantees of message delivery, which
-requires persistence, as well as replication. They also support strongly
-consistent replication, where a producer is notified of success when N nodes in
-the cluster have accepted the messages, where the value of N is configurable
-and can be chosen to ensure consistency (by perhaps sacrificing availability)
-in scenarios like network splits. Note, however, that classic mirrored queues
-in RabbitMQ are [known](https://aphyr.com/posts/315-jepsen-rabbitmq) to be
-susceptible to loss of consistency during network partitions, which led to the
-development of *Raft*-based "quorum queues" in RabbitMQ v3.8. BlazingMQ
-successfully passes our chaos tests built on top of
-[Jepsen](https://github.com/jepsen-io/jepsen) and our chaos testing suite will
-be published as open source in the coming months.
-
----
-
-## BlazingMQ Use Cases
-
-There are several use cases at Bloomberg which BlazingMQ solves optimally.
-While we cannot provide specific details about these use cases, we capture enough
-information for readers to appreciate how BlazingMQ supports them.
-
-### High fan-out ratio with high data volume
-
-Courtesy of its multi-hop network topology and its ability to build a
-multi-level distribution tree for a queue as described [here](../../architecture/network_topology), one area where BlazingMQ
-excels is in its support of high fan-out with high data volumes. Consider a scenario where
-there are thousands of consumers (*N*) attached to the queue, all of which are interested in
-receiving every message posted in the queue, and the producer posts at a rate
-of hundreds of messages per second (*M*). In such case, due to fan-out, the
-messaging system would needs to deliver an aggregated *M * N* messages per
-second. Picking *N* = 5000, and *M* = 1000, the aggregate comes out to be
-5,000,000 messages per second on the outbound. In the absence of a
-distribution tree, the BlazingMQ primary node would have been required to
-support this outbound rate. However, due to its topology, BlazingMQ primary
-node may see a fan-out of only 10s (i.e., *N* = 10), leading to *drastic*
-improvements in latency, as well as bandwidth savings.
-
-### Storage Savings
-
-As mentioned in one of the previous sections, an interesting property of
-BlazingMQ is that messages are stored once, irrespective of the number of
-consumers in the fan-out mode (recall that BlazingMQ stores the message before
-routing it). This can lead to bandwidth and capacity savings, especially for
-queues with a higher number of consumers. There are several instances at
-Bloomberg where queues have fan-out ratios of 50+, which immediately leads to
-storage savings of 50x when compared to RabbitMQ.
-
-### High number of dynamic queues
-
-Some applications prefer to create a large number of queues (hundreds or
-thousands) in order to have fine-grained control over various data streams in
-their ecosystem. Applications can implement their own sharding schemes to
-distribute messages across these queues. In addition, some of these queues are
-long-lived, while others are short-lived. For example, a well-known queue
-which contains financial trade messages could be long-lived, while a queue
-which represents private communication between two processes could be short-lived. BlazingMQ helps applications achieve such design for various reasons –
-in BlazingMQ, queues are cheap, do not need to be declared up front (queues are
-created automatically when they are opened for the first time), and are garbage
-collected automatically when they are empty and unused for some time. There
-are several instances at Bloomberg in which a BlazingMQ domain has close to
-10,000 queues.
-
-### Mixed workload: different delivery guarantees for different data streams
-
-There are occasions where an application ecosystem has different data streams
-in their workflows, some of which require higher delivery guarantees (e.g., financial
-trade processing workflow), while others are okay with lower guarantees (e.g.,
-cache invalidation notifications). BlazingMQ has proven to be a good fit for
-such scenarios since it can provide both guarantees depending on the queue mode
-– priority or fan-out mode for at-least once delivery guarantees, and broadcast
-mode for at-most once delivery guarantees. This is convenient for applications
-because they can use the same middleware and same set of APIs in their
-applications and leverage both delivery guarantees, instead of using another
-middleware or raw TCP for *at-most once* delivery guarantees and a message
-queue for *at-least once* delivery guarantees. For some BlazingMQ users at
-Bloomberg, certain queues are priority or fan-out mode, while others are
-broadcast mode, and applications are using these queues to implement a variety
-of workflows like request/response, fan-out, one-way notifications, etc. For
-example, some applications broadcast requests to all instances of their
-workers because they may not know up front which worker can handle the request,
-while workers reply to the request over a priority queue back to the requester.
-
-### Good combination of features, performance and reliability
-
-Finally, BlazingMQ provides a good user experience along with its broad set
-of features, so users can rely on BlazingMQ for both good performance and reliability. In most cases, BlazingMQ provides a median latency of ~5ms or
-less with high data volumes, hides applications from transient network, software
-and hardware issues, as well as provides a set of features to help users
-implement their distributed messaging ecosystem in an efficient manner.
-
----
-
-## Conclusion
-
-In the last few decades, the world has moved towards extremely large, data-intensive workloads, and the need for reliable and efficient messaging systems has also
-increased and diversified. As we demonstrated in this document, no one system can provide a perfect solution across all dimensions for all
-applications. On several occasions, Bloomberg engineers have chosen BlazingMQ
-over RabbitMQ and Apache Kafka for their messaging needs because it has provided them with a
-clear advantage and solved their use cases in the most optimal way. As
-we continue to evolve BlazingMQ in the coming months and years, we expect it to
-become an even more compelling messaging solution for engineers outside of
-Bloomberg as well.
-
----
diff --git a/docs/docs/introduction/concepts.md b/docs/docs/introduction/concepts.md
deleted file mode 100644
index e6c6cb145..000000000
--- a/docs/docs/introduction/concepts.md
+++ /dev/null
@@ -1,218 +0,0 @@
----
-layout: default
-title: Concepts
-parent: Introduction
-nav_order: 3
----
-
-# BlazingMQ Concepts
-{: .no_toc }
-
-Let's review some high level, user-facing concepts in BlazingMQ.
-
-* toc
-{:toc}
-
-## Domain
-
-A domain is the top level namespace for a BlazingMQ user. A domain captures
-all the necessary attributes like storage quota, message expiration time (TTL),
-routing strategy (priority, fan-out, broadcast), etc. Multiple queues can be
-created in a domain, and all such queues inherit their domain's attributes. A
-domain can be thought of as a collection of segregated streams of data, where
-each queue in the domain represents one data stream.
-
-Queues in a domain do not need to be declared or created upfront. A queue will be
-created automatically when it is used for the first time.
-
-Depending on their needs, a BlazingMQ user can have multiple domains (with
-each domain containing one or more queues). This is usually needed when a user
-wants different sets of data streams, with each set behaving differently for storage quota, routing, and other configurations.
-
-### Domain Attributes
-
-A domain has several configuration parameters which dictate various functional
-aspects of the domain. A detailed overview of domain configuration can be
-found [here](../../installation/configuration#domain-configurations), but let's
-go over some of the important attributes:
-
-- **Routing Strategy**
-
- This attribute describes the routing strategy to be used by a BlazingMQ cluster
- for the queues belonging to the domain. More details about various routing
- strategies can be found [here](../../features/message_routing_strategies).
-
-- **Storage Attributes**
-
- These attributes describe storage-related configuration settings for a
- BlazingMQ domain. They include:
-
- - Maximum storage quota for the domain
- - Maximum storage quota for a queue in the domain (usually smaller than
- domain's quota)
-
- Note that *storage quota* captures numbers, as well as bytes, of messages.
-
-- **Message TTL**
-
- Amount of time after which messages will be garbage-collected by BlazingMQ if
- not consumed by the application. TTL duration can vary from a few minutes to
- a few days.
-
-- **Maximum Delivery Attempts**
-
- Total number of times a message will be transmitted to consumers if a
- consumer crashes without confirming the message, indicating that the message is
- likely a poison pill message. The recommended value is five. See [*Poison
- Pill Detection*](../../features/poison_pill_detection) for more details.
-
-- **Deduplication Time Interval**
-
- Total time interval for which a BlazingMQ cluster will keep track of
- *MessageId*s of the messages posted on the queue for the purpose of
- deduplication. See [*High
- Availability*](../../architecture/high_availability) for more details.
-
-- **Replication Consistency**
-
- Type of consistency for storage replication. There are two choices --
- eventual and strong. Strong consistency is strongly recommended (pun
- unintentional). See [this](../../features/consistency_levels) for more
- details.
-
-- Miscellaneous Settings
-
- A BlazingMQ domain contains some other configuration parameters described
- below:
-
- - *MaxConsumers*: Maximum number of consumers that can attach to a queue
-
- - *MaxProducers*: Maximum number of producers that can attach to a queue
-
- - *MaxQueues*: Maximum number of queues that can be created in a domain
-
- - *MaxIdleTime*: Amount of time interval after which BlazingMQ cluster will
- log an error message in its log if no messages were confirmed by the
- consumers during that interval. This error message can be used to raise an
- alarm in certain deployments.
-
----
-
-## Queue
-
-A queue in BlazingMQ represents a stream of data over which producer and
-consumer applications exchange data. A queue decouples applications from one
-another by acting as an intermediary, so that applications don't have to worry
-about each other's physical locations or lifetimes. In other words, a
-queue provides temporal and spatial isolation between various applications.
-
-In addition, a queue also protects consumer applications from bursty traffic by
-absorbing data spikes and enabling consumers to consume messages at their own
-pace.
-
-### Identifying a Queue
-
-A queue in BlazingMQ is identified by its *Uniform Resource Identifier* (URI).
-The queue URI follows [RFC 3986](https://datatracker.ietf.org/doc/html/rfc3986)
-and typically looks like `bmq://foo.bar.baz/quux`, where:
-
-- Leading `bmq` is the URI scheme
-
-- `foo.bar.baz` is the BlazingMQ domain name (the URI authority)
-
-- `quux` is the BlazingMQ queue name within the `foo.bar.baz` domain namespace
- (the URI path)
-
-More details about the format of a BlazingMQ queue URI can be found
-[here](../../apidocs/cpp_apidocs/group__bmqt__uri.html). Applications can
-address a queue by its URI.
-
-### Lifetime of a Queue
-
-Queues in BlazingMQ are completely dynamic, and applications don't have to worry
-about managing a BlazingMQ queue's lifetime. They do not need to be explicitly
-created or declared before being used. When an application gets a handle on a
-queue (by using one of the flavors from `openQueue` API), the queue is
-automatically created under the hood by a BlazingMQ cluster if it does not already exist.
-
-Similarly, applications don't have to worry about deleting a queue. A BlazingMQ
-cluster automatically garbage-collects a queue if it has no outstanding
-messages and no applications are attached to it.
-
-This feature removes the burden on applications to manage a queue's lifetime. It also enables a usage pattern where two or more applications
-create BlazingMQ queues which are tied to their own lifetimes. For example, while running, a
-pair of producer/consumer applications can exchange messages over a unique
-queue for their "private" communication, forget about the queue
-when they exit, and create a new one upon restart.
-
-On the other hand, some applications will continue to use the same queue
-in production for many months and years.
-
-### Persistence and Durability
-
-A very important attribute of a BlazingMQ queue is its durability. All queues are
-persisted and replicated. [Learn more](../../architecture/clustering) about clustering, storage, and replication in BlazingMQ.
-
-### Ordering in a Queue
-
-Each BlazingMQ queue is assigned a primary node in the BlazingMQ cluster, and
-that primary node enforces an order on the messages arriving in the queue.
-Depending upon the queue's [*Routing
-Strategies*](../../features/message_routing_strategies), consumers attached to
-the queue may or may not see messages in order. Additionally, consumers can
-see out of order messages in case a consumer application crashes or shuts down
-without confirming that all of the messages were routed to it.
-
----
-
-## Message
-
-A message is the basic unit of information that is exchanged between producer
-and consumer applications. In BlazingMQ, a message contains various attributes
-like:
-
-- **Message Payload**
-
-This field contains the message's contents. BlazingMQ APIs provide setter and
-getter functions for the message payload as binary data. Message payload is
-completely opaque to BlazingMQ and no parts of the system peek into it.
-Applications can serialize and deserialize messages using their favorite codecs
-(Protobuf, Avro, JSON, etc.).
-
-- **Message Properties**
-
-A producer application can associate an optional list of key/value pairs with
-every message. These key/value pairs are known as message properties in
-BlazingMQ. Applications can capture any meta information in the message
-properties, which could be useful for tracing, logging, and routing in the
-application ecosystem.
-
-- **Message Identifier**
-
-BlazingMQ assigns a unique message identifier to every message published by the
-producer application. This identifier is sent back to the producer in the
-message's acknowledgement notification, as well as to the consumer. BlazingMQ
-message brokers also use these identifiers to deduplicate any retransitted
-messages by maintaining a moving window of previously seen identifiers.
-
-### Message Acknowledgement
-
-For every message a producer application publishes, it receives a reply
-for it from BlazingMQ indicating the operation's result. This reply is known
-at *message acknowledgement* or *acknowlegement* or just *ACK* in BlazingMQ.
-Acknowledgement can be negative, which indicates BlazingMQ's failure to accept
-the message for various reasons (like a queue's storage quota has been reached, a long
-running network connectivity issue, etc). However, BlazingMQ tries to minimize
-negative acknowledgements as much as possible by seamlessly buffering and
-retransmitting messages whenever possible.
-
-In order to support high throughput workflows, acknowledgements are delivered
-asynchronously to the producer applications and may be delivered in batches.
-
-### Message Confirmation
-
-Once a consumer application has finished processing the message, it needs to
-notify BlazingMQ so the message can be removed from the queue. This notification is called *message confirmation* or *confirmation* or
-just *CONFIRM* in BlazingMQ. BlazingMQ client library provides an API to send confirmation to the queue.
-
----
diff --git a/docs/docs/introduction/index.md b/docs/docs/introduction/index.md
deleted file mode 100644
index f23266b38..000000000
--- a/docs/docs/introduction/index.md
+++ /dev/null
@@ -1,9 +0,0 @@
----
-layout: default
-title: Introduction
-nav_order: 1
-has_children: true
-permalink: /introduction
----
-
-# [](#introduction)Introduction
diff --git a/docs/docs/introduction/overview.md b/docs/docs/introduction/overview.md
deleted file mode 100644
index ad96b9765..000000000
--- a/docs/docs/introduction/overview.md
+++ /dev/null
@@ -1,141 +0,0 @@
----
-layout: default
-title: Overview
-parent: Introduction
-nav_order: 2
----
-
-# BlazingMQ Overview
-{: .no_toc }
-
-* toc
-{:toc}
-
-## What is BlazingMQ?
-
-BlazingMQ is generic message-oriented middleware usable for building
-decentralized applications which communicate using message queues. BlazingMQ
-provides durable, fault-tolerant, highly performant, and highly available
-queues, along with features like various message routing strategies (e.g., work
-queues, priority, fan-out, broadcast, etc.), compression, strong consistency,
-poison pill detection, etc.
-
-Message queues generally provide a loosely-coupled, asynchronous
-communication channel ("queue") between application services (producers and
-consumers) that send messages to one another. You can think about it like a mailbox for
-communication between application programs, where the 'producer' drops a message
-in a mailbox and the 'consumer' picks it up at its own leisure. Messages placed
-into the queue are stored until the recipient retrieves and processes them. In other
-words, producer and consumer applications can temporally and spatially isolate
-themselves from each other by using a message queue to facilitate communication.
-
-Within Bloomberg, the BlazingMQ framework processes billions of messages and
-terabytes of data every day and is used in production by thousands of applications.
-
-BlazingMQ client libraries are available in C++, Java and Python. Within
-Bloomberg, client applications and BlazingMQ clusters both run in a variety of
-environments, and BlazingMQ attempts to provide a consistent user experience
-across heterogeneous deployments. In general, BlazingMQ clusters can be hosted
-anywhere and do not depend on any other Bloomberg-specific or open source
-frameworks.
-
----
-
-## Benefits of BlazingMQ
-
-BlazingMQ's goal is to provide application developers with a well supported, feature rich, and highly
-performant message queuing framework. Here's a summary of its benefits:
-
-### Durability and High Availability
-{: .no_toc }
-
-It provides durable, highly available, and efficient queues, which enables
-asynchronous and loosely-coupled communication between applications. Queues
-can be replicated across data centers, thereby ensuring business continuity in
-case of disaster recovery (DR) scenarios.
-
-### Transport Abstraction
-{: .no_toc }
-
-It abstracts the transport and network, and producer and consumer applications
-don't need to worry about the underlying transport or one another's geographic
-locations.
-
-### Message Routing Strategies
-{: .no_toc }
-
-It enables applications to implement various enterprise architecture patterns
-as a result of its rich set of message routing strategies -- work queue,
-priority, fan-out, broadcast, request/response, etc. See [*Routing
-Patterns*](../../features/message_routing_strategies) for more details.
-
-### Rich Feature Set
-{: .no_toc }
-
-In addition to the above, it comes with additional features like compression,
-poison pill detection, a pluggable architecture, configurable consistency, a rich
-set of APIs in C++, Python, and Java SDKs, etc. See
-[*Features*](../../../features) for more details.
-
-### High Performance
-{: .no_toc }
-
-It provides low latency and high throughput at enterprise scale. Applications
-can rely on BlazingMQ to be highly performant. See
-[*Performance*](../../performance/benchmarks) for more details.
-
-### Reliability
-{: .no_toc }
-
-It provides a high level of reliability and attempts to protect applications
-from transient network or hardware disturbances. A BlazingMQ cluster can
-disappear from the network for a few (configurable) minutes, during which time producer
-applications can continue to submit work to it without noticing any errors.
-See [*High Availability*](../../architecture/high_availability) for
-more details.
-
-### Extensive Metrics
-{: .no_toc }
-
-It provides a rich set of monitoring metrics to help users determine and
-understand the behavior of their applications, as well as the BlazingMQ clusters.
-
----
-
-## Motivation for BlazingMQ
-
-BlazingMQ's development at Bloomberg more than eight years ago began at a time when similar open source
-and proprietary systems were immature, did not possess features we were
-looking for, had exorbitant licensing fees, or had questions about their
-reliability and performance. In addition, Bloomberg engineers had prior
-experience building other in-house middleware frameworks, and the decision to
-implement an in-house message queuing system was determined to be the right
-one.
-
-Over the last several years, BlazingMQ has become a compelling message queuing
-solution at Bloomberg, thanks to its performance, reliability, and features.
-See [*Comparison with Alternatives*](../comparison) where we carry out
-a high-level comparison of BlazingMQ with two of the most similar and dominant message queueing
-systems today.
-
----
-
-## Open Source Release
-
-This is BlazingMQ's first open source release, and we are publishing BlazingMQ
-message brokers, as well as client libraries in C++ and Java in this release.
-As with any mature enterprise system, BlazingMQ has a thriving ecosystem around
-it within Bloomberg, comprising of configuration management, self-service,
-Python client libraries, transport adapters, monitoring, alarming and testing
-(stress, fuzz, chaos, etc.). Most of these systems are closely integrated with
-Bloomberg enterprise, so publishing them as-is in the open is not
-feasible. In the coming months, we will be working towards publishing some of
-these systems as open source as well to ensure that BlazingMQ's ecosystem continues to
-grow outside of Bloomberg. Details can be found in the BlazingMQ
-[*Roadmap*](../roadmap) section.
-
-We hope that you'll give BlazingMQ a shot! Please don't hesitate to [reach
-out](https://github.com/bloomberg/blazingmq/issues) to us if you have any
-questions or feedback!
-
----
diff --git a/docs/docs/introduction/roadmap.md b/docs/docs/introduction/roadmap.md
deleted file mode 100644
index 80a056957..000000000
--- a/docs/docs/introduction/roadmap.md
+++ /dev/null
@@ -1,103 +0,0 @@
----
-layout: default
-title: Roadmap
-parent: Introduction
-nav_order: 6
----
-
-# BlazingMQ Roadmap
-{: .no_toc }
-
-* toc
-{:toc}
-
-BlazingMQ is an actively evolving product and we have several enhancements in the areas of security, stability, scalability, user-facing
-features, tooling, etc. in the pipeline. This document lists some of these short-, medium- and
-long-term projects. As with any large enterprise software framework, the priority
-of these projects can change. If you'd like to see a feature or enhancement in
-BlazingMQ, please reach out to us!
-
-## Short-Term
-
-### Testing Suites
-{: .no_toc }
-
-BlazingMQ has various test suites which will be published as open source in the
-coming months after general cleanup and refactoring:
-
-- Integration test suite
-
-- Chaos test suite built on top of [Jepsen](https://github.com/jepsen-io/jepsen)
-
-- Stress and performance test suite
-
-- Fuzz test suite
-
----
-
-## Medium-Term
-
-### Security: Authentication
-{: .no_toc }
-
-Authentication and encryption in transit will be added to BlazingMQ by adopting
-TLS support.
-
-### Security: Authorization
-{: .no_toc }
-
-In order to give clients better control over their namespaces and queues,
-support for authorization will be added to BlazingMQ. Users will be able to
-configure which identities are permissioned to access their BlazingMQ queues.
-
-### Overload Control
-{: .no_toc }
-
-BlazingMQ brokers will be updated to detect when they are overloaded (high
-memory, large volume of pending work, etc.). In turn, they will start
-throttling producer applications which are producing messages at a higher rate than normal
-and/or have a lot of pending (unacknowledged) messages piled up in the brokers.
-
-### Stuck Consumer Detection
-{: .no_toc }
-
-Any consumers which have not confirmed their messages in a configurable amount
-of time will be assumed to be dead and removed from the set of working
-consumers. This will ensure that consumers which are deadlocked or are stuck
-for some reason don't hold on to unprocessed messages forever.
-
-### Adminstrative Tooling
-{: .no_toc }
-
-A set of command line tools and scripts which can be used to manage and interact with a BlazingMQ cluster will be published as open source. Several such tools already exist, while some other new tools and scripts will be developed.
-
----
-
-## Long-Term
-
-### Distributed Tracing Support
-{: .no_toc }
-
-BlazingMQ contains pluggable support for distributed tracing. However, this
-support is partial and currently available only for a subset of requests in its
-control plane. BlazingMQ will be updated to support full-fledged distributed tracing across both its control and data planes.
-
-### Higher Storage Quota
-{: .no_toc }
-
-BlazingMQ's storage layer will be updated to ensure that it can leverage as much
-of the storage/disk as available in the cluster, such that queues with
-terabytes worth of quota can be supported.
-
-### Source and Sink Connectors
-{: .no_toc }
-
-Support for various source and sink connectors will be added in BlazingMQ for
-easier integration with other systems.
-
-### Multi-level Consumer Priority Support
-{: .no_toc }
-
-BlazingMQ's message routing logic will be updated to ensure that messages can be routed to lower priority consumers when those with highest priority are at capacity. Currently, if highest priority consumers are unable to accept any more messages, new messages stay in the queue and are not routed to lower priority consumers.
-
----
diff --git a/docs/docs/performance/benchmarks.md b/docs/docs/performance/benchmarks.md
deleted file mode 100644
index 335b234d1..000000000
--- a/docs/docs/performance/benchmarks.md
+++ /dev/null
@@ -1,164 +0,0 @@
----
-layout: default
-title: Benchmarks
-parent: Performance
-nav_order: 2
----
-
-# BlazingMQ Performance
-{: .no_toc }
-
-* toc
-{:toc}
-
-## Introduction
-
-Benchmarking any complex distributed system like BlazingMQ can be tricky
-because there are several moving parts - there is no one latency number for
-BlazingMQ, and any performance numbers are affected by factors including but
-not limited to:
-
-- Size of the BlazingMQ cluster and replication factor
-
-- Storage (no persistence, in-memory, HDD, SSD, etc)
-
-- Hardware and network capabilities
-
-- Producer message rate, message size and batch size
-
-- Producer publishing pattern (smooth vs bursty)
-
-- Number of consumers (fan-out ratio)
-
-- Network topology (location of producers/consumers, cluster nodes, etc) which
- has direct impact on ping latency among nodes
-
-- BlazingMQ message broker configuration (number of threads, initial size of
- various memory pools, etc)
-
-
-## Benchmarking Setup
-
-We provide results of a recent benchmark of BlazingMQ with this setup:
-
-- Six nodes in the BlazingMQ cluster
-
-- Each node with local SSDs attached to it
-
-- Nodes geographically spread across such that `ping` latency between them was
- around 1.5 milliseconds
-
-- Producer and consumer applications were running on other nodes and instead of
- connecting directly to the BlazingMQ cluster, they connected to BlazingMQ
- proxies (see [*Alternative
- Deployment*](../../architecture/clustering#alternative-deployment) for
- details about BlazingMQ proxies).
-
-- Queues storage replication was configured for strong consistency i.e.,
- primary node waited for acknowledgement from enough replicas such that the
- majority of the nodes recorded the message before returning success to the
- producer applications. So in this case, primary waited for acknowledgement
- from three replica nodes before replying to the producer. This ensured that
- a total of four nodes (primary and three replicas) recorded the message.
-
-- Queues with various [*routing
- strategies*](../../features/message_routing_strategies) were
- tested.
-
-It is worth mentioning that the cluster setup described above is an extreme one
-and the geographical distance between cluster nodes becomes a non-negligible
-factor in the final results. We provide some benchmarking results from a more
-friendly setup later in the article.
-
-How to interpret the tables below:
-
-- Latency number indicates the difference between the time a message was sent
- to the queue by the producer and the time it was received by the consumer.
- All latency numbers are in milliseconds.
-
-- Message size was 1KB and compression was disabled.
-
-- In the *Scenario* column, *Q*, *P* and *C* letters represent a queue, a
- producer and a consumer respectively. For example:
- - `1Q, 1P, 1C` in the first column means one producer, one consumer and one
- queue.
- - `10Q, 10P, 10C` means 10 queues, 10 producers and 10 consumers, such that
- there is one producer and one consumer for each queue.
- - `1Q, 1P, 5C` means one queue with one producer and five consumers, and each
- consumer receiving every message posted on the queue.
-
-- Second column, *"Total Produce Rate"* indicates the total produce rate
- accumulated across all producers running in that scenario.
-
-- Similarly, *"Total Consume Rate"* indicates the total consume rate
- accumulated across all consumers running in that scenario.
-
-### Priority Routing Strategy
-
-| Scenario | Total Produce Rate (msgs/sec) | Total Consume Rate (msgs/sec) | Median (p50) | Average | p90 | p99 |
-|------------------|-------------------------------|-------------------------------|--------------|---------|------|-------|
-| 1Q, 1P, 1C | 60,000 | 60,000 | 4.5 | 5.4 | 7.3 | 19.8 |
-| 10Q, 10P, 10C | 120,000 | 120,000 | 3.9 | 12.0 | 6.8 | 201.9 |
-| 50Q, 50P, 50C | 100,000 | 100,000 | 3.9 | 7.3 | 8.7 | 87.9 |
-| 100Q, 100P, 100C | 100,000 | 100,000 | 4.7 | 12.4 | 20.3 | 165.6 |
-
-
-### Fan-out Routing Strategy
-
-| Scenario | Total Produce Rate (msgs/sec) | Total Consume Rate (msgs/sec) | Median (p50) | Average | p90 | p99 |
-|------------|-------------------------------|-------------------------------|--------------|---------|-----|-----|
-| 1Q, 1P, 5C | 20,000 | 100,000 | 4.4 | 4.7 | 4.8 | 8.2 |
-
-
-### Broadcast Routing Strategy
-
-| Scenario | Total Produce Rate (msgs/sec) | Total Consume Rate (msgs/sec) | Median (p50) | Average | p90 | p99 |
-|-------------|-------------------------------|-------------------------------|--------------|---------|-----|-----|
-| 1Q, 1P, 1C | 160,000 | 160,000 | 4.5 | 5.1 | 5.5 | 8.8 |
-| 1Q, 1P, 5C | 110,000 | 550,000 | 3.7 | 3.8 | 4.1 | 7.2 |
-| 1Q, 1P, 10C | 20,000 | 200,000 | 2.8 | 3.0 | 3.6 | 5.4 |
-
----
-
-## Benchmarking in Friendly Setup
-
-We ran our BlazingMQ benchmarks in a friendlier setup which was different from
-the above setup in these ways:
-
-- Three nodes in the BlazingMQ cluster
-
-- Nodes geographically spread across such that `ping` latency between them was
- less than 30 microseconds.
-
-- Primary node waited for acknowledgement from one replica before replying to
- the producer, thereby ensuring that at least two nodes (primary and one
- replica) had recorded the message before replying to the producer.
-
-
-### Priority Routing
-
-| Scenario | Total Produce Rate (msgs/sec) | Total Consume Rate (msgs/sec) | Median (p50) | Average | p90 | p99 |
-|------------------|-------------------------------|-------------------------------|--------------|---------|-----|------|
-| 1Q, 1P, 1C | 60,000 | 60,000 | 1.5 | 1.7 | 2.1 | 4.9 |
-| 10Q, 10P, 10C | 120,000 | 120,000 | 1.1 | 2.1 | 2.7 | 35.7 |
-| 50Q, 50P, 50C | 100,000 | 100,000 | 0.7 | 1.5 | 1.1 | 23.1 |
-| 100Q, 100P, 100C | 100,000 | 100,000 | 0.9 | 2.5 | 2.7 | 43.8 |
-
-
-### Fan-out Routing Strategy
-
-| Scenario | Total Produce Rate (msgs/sec) | Total Consume Rate (msgs/sec) | Median (p50) | Average | p90 | p99 |
-|------------|-------------------------------|-------------------------------|--------------|---------|-----|------|
-| 1Q, 1P, 5C | 20,000 | 100,000 | 0.6 | 0.7 | 0.8 | 3.0 |
-| 1Q, 1P, 5C | 30,000 | 150,000 | 1.4 | 2.4 | 5.2 | 15.1 |
-
-
-### Broadcast Routing Strategy
-
-| Scenario | Total Produce Rate (msgs/sec) | Total Consume Rate (msgs/sec) | Median (p50) | Average | p90 | p99 |
-|-------------|-------------------------------|-------------------------------|--------------|---------|-----|-----|
-| 1Q, 1P, 1C | 160,000 | 160,000 | 2.0 | 2.0 | 2.3 | 2.9 |
-| 1Q, 1P, 5C | 110,000 | 550,000 | 1.7 | 1.8 | 1.9 | 4.0 |
-| 1Q, 1P, 10C | 20,000 | 200,000 | 0.6 | 0.6 | 0.9 | 1.2 |
-
----
diff --git a/docs/docs/performance/index.md b/docs/docs/performance/index.md
deleted file mode 100644
index d8c513fe9..000000000
--- a/docs/docs/performance/index.md
+++ /dev/null
@@ -1,9 +0,0 @@
----
-layout: default
-title: Performance
-nav_order: 6
-has_children: true
-permalink: /performance
----
-
-# [](#performance)Performance
diff --git a/docs/lib/tasks/search.rake b/docs/lib/tasks/search.rake
deleted file mode 100644
index d1f9fd47e..000000000
--- a/docs/lib/tasks/search.rake
+++ /dev/null
@@ -1,88 +0,0 @@
-namespace :search do
- desc 'Generate the files needed for search functionality'
- task :init do
- puts 'Creating search data json file...'
- mkdir_p 'assets/js'
- touch 'assets/js/zzzz-search-data.json'
- puts 'Done.'
- puts 'Generating content...'
-
- File.open('assets/js/zzzz-search-data.json', 'w') do |f|
- f.puts '---
-permalink: /assets/js/search-data.json
----
-{
-{%- assign i = 0 -%}
-{%- assign pages_array = "" | split: "" -%}
-{%- assign pages_array = pages_array | push: site.html_pages -%}
-{%- if site.just_the_docs.collections -%}
- {%- for collection_entry in site.just_the_docs.collections -%}
- {%- assign collection_key = collection_entry[0] -%}
- {%- assign collection_value = collection_entry[1] -%}
- {%- assign collection = site[collection_key] -%}
- {%- if collection_value.search_exclude != true -%}
- {%- assign pages_array = pages_array | push: collection -%}
- {%- endif -%}
- {%- endfor -%}
-{%- endif -%}
-{%- for pages in pages_array -%}
- {%- for page in pages -%}
- {%- if page.title and page.search_exclude != true -%}
- {%- assign page_content = page.content -%}
- {%- assign heading_level = site.search.heading_level | default: 2 -%}
- {%- for j in (2..heading_level) -%}
- {%- assign tag = \'\' -%}
- {%- assign title = titleAndContent[0] | replace_first: \'>\', \'
\' | split: \'
\' -%}
- {%- assign title = title[1] | strip_html -%}
- {%- assign content = titleAndContent[1] -%}
- {%- assign url = page.url -%}
- {%- if title == page.title and parts[0] == \'\' -%}
- {%- assign title_found = true -%}
- {%- else -%}
- {%- assign id = titleAndContent[0] -%}
- {%- assign id = id | split: \'id="\' -%}
- {%- if id.size == 2 -%}
- {%- assign id = id[1] -%}
- {%- assign id = id | split: \'"\' -%}
- {%- assign id = id[0] -%}
- {%- capture url -%}{{ url | append: \'#\' | append: id }}{%- endcapture -%}
- {%- endif -%}
- {%- endif -%}
- {%- unless i == 0 -%},{%- endunless -%}
- "{{ i }}": {
- "doc": {{ page.title | jsonify }},
- "title": {{ title | jsonify }},
- "content": {{ content | replace: \'
-
\ No newline at end of file
diff --git a/docs/_includes/components/mermaid.html b/docs/_includes/components/mermaid.html
deleted file mode 100644
index d6923e090..000000000
--- a/docs/_includes/components/mermaid.html
+++ /dev/null
@@ -1,5 +0,0 @@
-
diff --git a/docs/_includes/components/search_footer.html b/docs/_includes/components/search_footer.html
deleted file mode 100644
index fb4fe51b4..000000000
--- a/docs/_includes/components/search_footer.html
+++ /dev/null
@@ -1,7 +0,0 @@
-{% if site.search.button %}
-
- 
-
-
-
-
-
-
-
-
-
-
