Fix trivial docstring typos (bloomberg#435)

Signed-off-by: Christopher Beard <[email protected]>

fixing Solaris build (bloomberg#434)

Signed-off-by: dorjesinpo <[email protected]>

Remove `-DBMQ_ENABLE_MSG_GROUPID` from the build system

We do not ever want to build with this flag when releasing, and users
often manage to enable this flag accidentally.  Because message group
IDs are not fully implemented, we remove this temporary definition.  It
can be added in later if we ever come back to this feature.

Signed-off-by: Patrick M. Niedzielski <[email protected]>

Make unit tests pass without `BMQ_ENABLE_MSG_GROUPID`

The unit tests currently assume that message group IDs are enabled, and
since have updated our build system to no longer enable this feature,
the unit tests now fail in CI.  This patch guards the message group ID
tests with preprocessor conditionals, disabling the parts of tests that
try to set and check message group IDs.  When `BMQ_ENABLE_MSG_GROUPID`
is set, these parts of the unit tests run again.

Signed-off-by: Patrick M. Niedzielski <[email protected]>

Fix mqbstat doc formatting (bloomberg#438)

Signed-off-by: Christopher Beard <[email protected]>

Fix[bmqeval]: limit expression length to avoid stack overflow (bloomberg#441)

Signed-off-by: Evgeny Malygin <[email protected]>

Fix Solaris unit tests (bloomberg#440)

Signed-off-by: Anton Pryakhin <[email protected]>

Docs[BMQ]: Use `.dox` files rather than `.md` files

Package group documentation in `libbmq` was converted to Markdown files
named `README.md`, and which was tied to the directory containing the
code for the package group using Doxygen `@dir` commands.  However, when
generating the documentation, this left several empty pages in the
documentation named `README`, which we were not able to remove.

The solution for this that this patch uses is to switch from `.md` files
to `.dox` files, which contain a single Doxygen-style C++ comment
containing the `@dir` command.  Unlike `.md` files, these do not
automatically create pages, so there is no empty `README` page created
for each package group.  The cost of this is that `.dox` files cannot be
simple Markdown files, but instead need to be wrapped in a C++ comment.

Signed-off-by: Patrick M. Niedzielski <[email protected]>

Docs[BMQ] bde -> doxygen conversion fixes (bloomberg#443)

* Doc[BMQT] minor bde -> doxygen docs

* Doc[BMQA] minor bde -> doxygen docs

* Doc[BMQA] re-wrap data member comments

* Doc[BMQT] re-wrap data member comments

* Apply suggestions from code review

---------

Signed-off-by: Christopher Beard <[email protected]>
Signed-off-by: Chris Beard <[email protected]>
Co-authored-by: Evgeny Malygin <[email protected]>

Feat: track queue depth per appId (bloomberg#320)

Signed-off-by: Evgeny Malygin <[email protected]>

configurator, bmqit: mode protos (bloomberg#447)

Signed-off-by: Jean-Louis Leroy <[email protected]>

Revert "configurator, bmqit: mode protos (bloomberg#447)" (bloomberg#449)

This reverts commit a4b20db.

Fix[mqbs_virtualstoragecatalog.cpp]: fix Solaris build (bloomberg#450)

Signed-off-by: Evgeny Malygin <[email protected]>

fix: configurator: apply app ids (bloomberg#452)

Signed-off-by: Jean-Louis Leroy <[email protected]>

Fix [MQB]: mqbc::StorageMgr: Transition to available only when all primary active (bloomberg#416)

* mqbc::StorageMgr: Ban 'processPrimaryStatusAdvisory' in non-FSM mode

Signed-off-by: Yuan Jing Vincent Yan <[email protected]>

* mqbc::StorageMgr: Transition to available only when all primary active

Signed-off-by: Yuan Jing Vincent Yan <[email protected]>

* mqbc::StorageMgr: clang-format

Signed-off-by: Yuan Jing Vincent Yan <[email protected]>

* mqbc::StorageMgr: Healing replica buffers primary status advisories

Signed-off-by: Yuan Jing Vincent Yan <[email protected]>

* mqbs::FileStore: Rename setPrimary -> setActivePrimary

Signed-off-by: Yuan Jing Vincent Yan <[email protected]>

* mqbc::StorageMgr: Comment about check if all partitions available

Signed-off-by: Yuan Jing Vincent Yan <[email protected]>

---------

Signed-off-by: Yuan Jing Vincent Yan <[email protected]>

Fix some compiler warnings in mqb (bloomberg#455)

* -Wunused-parameter
* -Wshadow
* -Wswitch-enum

Signed-off-by: Christopher Beard <[email protected]>

It: Include full path for admin stat it test failures (bloomberg#453)

* It: Include full path for admin stat it test failures

This patch makes it a little easier to debug the metric & operation that
causes an integration test for stats to fail.

Signed-off-by: Christopher Beard <[email protected]>

* Update src/integration-tests/test_admin_client.py

Co-authored-by: Evgeny Malygin <[email protected]>
Signed-off-by: Chris Beard <[email protected]>

---------

Signed-off-by: Christopher Beard <[email protected]>
Signed-off-by: Chris Beard <[email protected]>
Co-authored-by: Evgeny Malygin <[email protected]>

Feat: Add queue history size metric (bloomberg#436)

* [WIP] Feat: Add queue history size metric

This adds a new queue metric that counts the number of GUIDs in that
queue's history. This is useful for identifying excessive memory
utilization from history and potential history garbage collection issues
(where history is filled up faster than it's cleaned up).

Signed-off-by: Christopher Beard <[email protected]>

* It: Extend admin it for history size stat

Signed-off-by: Christopher Beard <[email protected]>

---------

Signed-off-by: Christopher Beard <[email protected]>

Feat[plugins]: report queue depth per appId to prometheus (bloomberg#446)

Signed-off-by: Evgeny Malygin <[email protected]>

[Fix] m_bmqstoragetool::FileManagerImpl: Asserts not have side effects (bloomberg#461)

Signed-off-by: Yuan Jing Vincent Yan <[email protected]>

Feat[MQB]: Enhance queue consumption monitor alarm log with additional details (bloomberg#420)

Enhance filebackedstorage alarm log

Signed-off-by: Aleksandr Ivanov <[email protected]>

Cleanup

Signed-off-by: Aleksandr Ivanov <[email protected]>

Add test to mqbu_capacitymeter.t

Signed-off-by: Aleksandr Ivanov <[email protected]>

mqbc::StorageUtil, mqbi::StorageMgr: updateQueue -> updateQueuePrimary (bloomberg#466)

Signed-off-by: Yuan Jing Vincent Yan <[email protected]>

Fix[MQB]: misc warnings (bloomberg#464)

Allow dots in subscription property names

Message properties allow arbitrary strings for property names, but our
subscription expression language is more limited, requiring an initial
alphabetic character followed by any number of alphanumeric characters
and underscores.  Some producers have begun using hierarchical message
property names, separated by dots (“.”), and are unable to use
subscriptions to filter or route according to these message properties.

This patch extends the expression language grammar to enable matching on
subscription property names with dots in them.  This change is a pure
extension: the language recognized by the subscription expression grammar
after this patch is a strict superset of the language recognized by the
subscription expression grammar before this patch.  This patch also
extends the unit test for the lexer to ensure this is a strict superset.

Signed-off-by: Patrick M. Niedzielski <[email protected]>

fix: clean app subscriptions on reconfigure

Signed-off-by: dorjesinpo <[email protected]>

Fix[mqbstat_domainstats.cpp]: empty tier StringRef (bloomberg#431)

Signed-off-by: Evgeny Malygin <[email protected]>

Fix Solaris build, it does not support ctor delegation

Signed-off-by: Aleksandr Ivanov <[email protected]>

Doc: Document app subscriptions (bloomberg#463)

* Docs upgrade jekyll -> 4.3.3

Signed-off-by: Christopher Beard <[email protected]>

* Docs: Document app subscriptions

Signed-off-by: Christopher Beard <[email protected]>

* Expand on difference in subscriptions

Signed-off-by: Christopher Beard <[email protected]>

* Minor subscription doc clarifications

Signed-off-by: Christopher Beard <[email protected]>

* Elaborate on subscription details

Signed-off-by: Christopher Beard <[email protected]>

* Clarify consumer subscription on broker

Signed-off-by: Christopher Beard <[email protected]>

---------

Signed-off-by: Christopher Beard <[email protected]>

fix: enhanced detection of duplciate PUSHes (bloomberg#472)

Signed-off-by: dorjesinpo <[email protected]>

Fix ntf-core version in build_darwin.sh

Signed-off-by: Aleksandr Ivanov <[email protected]>

Add logAppsSubscriptionInfoCb into InMemoryStorage

Signed-off-by: Aleksandr Ivanov <[email protected]>

Add IT for capacity meter enhanced log

Signed-off-by: Aleksandr Ivanov <[email protected]>

Fix comments

Signed-off-by: Aleksandr Ivanov <[email protected]>

Fix [CI] ntf-core version for macosx build (bloomberg#473)

Merge mwc into bmq

MWC or "MiddleWare Core" was a package group developed to support
a myriad of applications at Bloomberg. It's been useful to share
common middleware components between similar technologies, but doesn't
make much sense to support as its own open source library. Moving
forward we are merging it into the BMQ package group to better maintain
it for the BlazingMQ project.

Signed-off-by: Taylor Foxhall <[email protected]>

Fix conflict

Signed-off-by: Aleksandr Ivanov <[email protected]>

Fix conflict

Signed-off-by: Aleksandr Ivanov <[email protected]>

Fix mwctst

Signed-off-by: Aleksandr Ivanov <[email protected]>

.github/workflows/build.yaml

@@ -163,7 +163,7 @@ jobs:
       - name: Run C++ Unit Tests
         run: |
           cd ${{ github.workspace }}/build/blazingmq
-          ctest -E mwcsys_executil.t --output-on-failure
+          ctest -E bmqsys_executil.t --output-on-failure
 
   unit_tests_python:
     name: UT [python]

.github/workflows/sanitizers/build_sanitizer.sh

@@ -283,5 +283,5 @@ mkscript "${SANITIZER_ENV} \${@}" "${DIR_BUILD_BMQ}/run-env.sh"
 
 # 'run-unittests.sh' runs all instrumented unit-tests.
 CMD="cd $(realpath "${DIR_BUILD_BMQ}") && "
-CMD+="./run-env.sh ctest -E mwcsys_executil.t --output-on-failure"
+CMD+="./run-env.sh ctest -E bmqsys_executil.t --output-on-failure"
 mkscript "${CMD}" "${DIR_BUILD_BMQ}/run-unittests.sh"

CMakeLists.txt

@@ -93,7 +93,7 @@ if (CMAKE_BUILD_TYPE STREQUAL "Debug")
 endif()
 
 # This repo contains the canonical source of multiple, independently released,
-# UORs (mwc, bmq, bmqbrkr, bmqbrkrcfg, bmqtool).  When releasing a UOR, that
+# UORs (bmq, bmqbrkr, bmqbrkrcfg, bmqtool).  When releasing a UOR, that
 # specific target is selected through injection of the 'INSTALL_TARGETS'
 # variable.  Many static analysis tool leverage the generated
 # 'compile_commands.json' in order to know which sources to work with.
@@ -104,8 +104,8 @@ endif()
 # that we will only add targets to the intended ones, based on what is
 # currently being built.  We will set a "BMQ_TARGET_<xyz>_NEEDED" value to
 # YES/NO.
-# - if INSTALL_TARGETS is empty, this means we are not doing a DPKG build, but
-#   just a normal developer build, therefore include all targets
+# - if INSTALL_TARGETS is empty, this means we are not doing an integration
+#   build, but just a normal developer build, therefore include all targets
 # - otherwise, selectively enable targets based on what is being built
 
 if (NOT DEFINED INSTALL_TARGETS)
@@ -114,7 +114,6 @@ if (NOT DEFINED INSTALL_TARGETS)
   set(BMQ_TARGET_BMQBRKRCFG_NEEDED     YES)
   set(BMQ_TARGET_BMQTOOL_NEEDED        YES)
   set(BMQ_TARGET_BMQSTORAGETOOL_NEEDED YES)
-  set(BMQ_TARGET_MWC_NEEDED            YES)
   set(BMQ_TARGET_BMQ_NEEDED            YES)
   set(BMQ_TARGET_MQB_NEEDED            YES)
   set(BMQ_TARGET_E_BMQBRKR_NEEDED      YES)
@@ -137,26 +136,18 @@ else()
   set(BMQ_TARGET_BMQBRKRCFG_NEEDED     NO)
   set(BMQ_TARGET_BMQTOOL_NEEDED        NO)
   set(BMQ_TARGET_BMQSTORAGETOOL_NEEDED NO)
-  set(BMQ_TARGET_MWC_NEEDED            NO)
   set(BMQ_TARGET_BMQ_NEEDED            NO)
   set(BMQ_TARGET_MQB_NEEDED            NO)
   set(BMQ_TARGET_TUTORIAL_NEEDED       NO)
   set(BMQ_TARGET_PROMETHEUS_NEEDED     NO)
 
-  bbproject_check_install_target("mwc"            installMWC)
   bbproject_check_install_target("bmq"            installBMQ)
   bbproject_check_install_target("mqb"            installMQB)
   bbproject_check_install_target("bmqbrkrcfg"     installBMQBRKRCFG)
   bbproject_check_install_target("bmqtool"        installBMQTOOL)
   bbproject_check_install_target("bmqstoragetool" installBMQSTORAGETOOL)
   bbproject_check_install_target("prometheus"     installPROMETHEUS)
 
-  # NOTE: All targets should get 'mwc' from DPKG, except for the 'mwc' release
-  #       itself (and the development work).
-  if (installMWC)
-    set(BMQ_TARGET_MWC_NEEDED YES)
-  endif()
-
   if (installBMQ)
     set(BMQ_TARGET_BMQ_NEEDED YES)
   endif()
@@ -190,23 +181,12 @@ else()
   endif()
 
   if (installPROMETHEUS)
-    set(BMQ_TARGET_MWC_NEEDED        YES)
     set(BMQ_TARGET_BMQ_NEEDED        YES)
     set(BMQ_TARGET_MQB_NEEDED        YES)
     set(BMQ_TARGET_PROMETHEUS_NEEDED YES)
   endif()
 endif()
 
-# TBD: TEMPORARY >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
-if (NOT installBMQ)
-  # Enable MSG GroupId public APIs ONLY if not doing a DPKG build (i.e., a
-  # release) of libbmq; until the feature is fully implemented.
-  add_definitions("-DBMQ_ENABLE_MSG_GROUPID")
-else()
-  message(STATUS "Message GroupId APIs *NOT* exposed!")
-endif()
-# TBD: TEMPORARY <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
-
 # -----------------------------------------------------------------------------
 #                                   PROJECTS
 # -----------------------------------------------------------------------------

Doxyfile

@@ -989,7 +989,8 @@ INPUT_FILE_ENCODING    =
 FILE_PATTERNS          = *.c \
                          *.cpp \
                          *.h \
-                         *.md
+                         *.md \
+                         *.dox
 
 # The RECURSIVE tag can be used to specify whether or not subdirectories should
 # be searched for input files as well.

bin/build-darwin.sh

@@ -45,7 +45,7 @@ if [ ! -d "${DIR_THIRDPARTY}/bde" ]; then
     git clone --depth 1 --branch 4.8.0.0 https://github.com/bloomberg/bde.git "${DIR_THIRDPARTY}/bde"
 fi
 if [ ! -d "${DIR_THIRDPARTY}/ntf-core" ]; then
-    git clone --depth 1 --branch latest https://github.com/bloomberg/ntf-core.git "${DIR_THIRDPARTY}/ntf-core"
+    git clone --depth 1 --branch 2.4.2 https://github.com/bloomberg/ntf-core.git "${DIR_THIRDPARTY}/ntf-core"
 fi
 
 

bin/build-ubuntu.sh

@@ -87,7 +87,7 @@ if [ ! -d "${DIR_THIRDPARTY}/bde" ]; then
     git clone --depth 1 --branch 4.8.0.0 https://github.com/bloomberg/bde.git "${DIR_THIRDPARTY}/bde"
 fi
 if [ ! -d "${DIR_THIRDPARTY}/ntf-core" ]; then
-    git clone --depth 1 --branch latest https://github.com/bloomberg/ntf-core.git "${DIR_THIRDPARTY}/ntf-core"
+    git clone --depth 1 --branch 2.4.2 https://github.com/bloomberg/ntf-core.git "${DIR_THIRDPARTY}/ntf-core"
 fi
 # prometheus-cpp and its dependency for the plugin
 if [ "${BUILD_PROMETHEUS}" == true ]; then

docs/Gemfile

@@ -4,7 +4,7 @@ source 'https://rubygems.org'
 
 # gem "rails"
 
-gem "jekyll", "~> 4.2.2"
+gem "jekyll", "~> 4.3.3"
 gem "jekyll-seo-tag"
 gem "jekyll-github-metadata"
 gem "webrick"

docs/docs/architecture/network_transport.md

@@ -57,7 +57,7 @@ single socket to many thousands of simultaneous sockets."*
 ### Transport Abstraction
 
  In its implementation, BlazingMQ abstracts the transport by using
-[`mwcio`](https://github.com/bloomberg/blazingmq/blob/main/src/groups/mwc/mwcio/mwcio_channel.h)
+[`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

docs/docs/features/subscriptions.md

@@ -5,46 +5,55 @@ parent: Features
 nav_order: 3
 ---
 
-# Subscriptions (aka Topic-based Routing)
+# Subscriptions
 {: .no_toc }
 
 * toc
 {:toc}
 
 ## Introduction
 
-Subscriptions provide consumer applications a powerful mechanism to express
-interest in receiving only those messages which satisfy criteria specified by
-them.  In the absence of subscriptions, a consumer attached to a queue can
-receive any and all messages posted on the queue, and should be in a position
-to process all of them.  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 restriction prevents a more flexible or natural
-arrangement of consumer applications.  For example, some users 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.  This is where
-subscriptions come in -- they enable consumer applications to "subscribe" to
-messages of a certain type, thereby *logically* converting a queue into a
-stream of heterogeneous data.
+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 specify filters using one or more *message
-properties*.  For example, if a message contains these three properties:
+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 when
-attaching to a queue:
+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 three properties as shown above will be routed
-to the consumer with above filter (note that if a property is not specified by
-the consumer, it is considered to be a wildcard).
+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
@@ -58,6 +67,66 @@ 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}
 
@@ -110,6 +179,11 @@ 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:
@@ -147,18 +221,25 @@ matching subscription(s). Here’s how subscriptions work at a high level:
 - 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, BlazingMQ
-  primary node will try to match the message with a subscription and route the
-  message to the consumer with that subscription. See *Implementation Details*
+- 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 Subscriptions**: in case if consumers specify overlapping
+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
@@ -235,6 +316,7 @@ manipulation, as a tiny subset of the C programming language.
 - 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}

etc/cmake/BMQPlugins.cmake

@@ -38,7 +38,7 @@ function(bmq_add_plugin name)
     # -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
     # Configure link-time options.
     # -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-    _bmq_add_include_paths(${name} DEPS mqb bmq mwc)
+    _bmq_add_include_paths(${name} DEPS mqb bmq)
     target_link_libraries(${name} PRIVATE ${${name}_DEPENDS})
 
     # include( BMQTest )