Smile CDR uses a message broker for Subscription processing.
The message broker is associated with the overall Smile CDR cluster, meaning that one single logical broker is shared by all modules (although this broker may itself be clustered).
There are two broker technologies supported by Smile CDR:
The number of threads allocated to subscription processing is configured in the storage module using these properties:
module.persistence.config.subscription.consumers_per_matching_queue =2 module.persistence.config.subscription.consumers_per_delivery_queue =5
These determine the number of consumers (threads) that listen to the two different types of subscription queues used by Smile CDR. See Smile CDR Subscription Architecture.
consumers_per_matching_queue is the number of listener threads that match new resources against active subscriptions
consumers_per_delivery_queue is the number of listener threads created per subscription. These threads deliver subscription matches to subscription endpoints.
Smile CDR performs subscription matching by registering an interceptor with a FHIR Storage module and submits all incoming resources to the Subscription Matching Queue on the configured Message Broker. (In the case of Kafka, Kafka topics are used in place of JMS queues.) A Smile CDR Subscription Matching module subscribes to this Subscription Matching Queue and matches all incoming resources against all active subscriptions. Each active subscription has its own dedicated Delivery Queue. When a resource matches a subscription, it is placed on the Delivery Queue for that subscription. A separate consumer within the Subscription Matching module then picks up the matched resource from the Delivery Queue and attempts to deliver it to the endpoint specified by that subscription. If a single endpoint is down, only queues for subscriptions delivering to that endpoint are affected; deliveries to other endpoints continue unimpeded.
All Subscription Queue names end with
[STORAGE_MODULE_ID] are the Node ID and FHIR Storage module ID for the module that is submitting the events for processing. In the default Smile CDR configuration these will be
The name of the Subscription Matching Queue is
The name of each rest-hook delivery queue is
[NAME] depends on the value of
module.subscription.config.delivery_queue_naming. The value of
delivery_queue_naming can be one of the following options:
SUBSCRIPTION_ID: Create one delivery queue per subscription with the NAME equal to the subscription id. This is the default for backwards compatibility.
SHARED Create a single delivery queue shared by all subscriptions
DELIVERY_GROUP: Look for the extension
https://smilecdr.com/fhir/ns/StructureDefinition/subscription-channel-delivery-group on each subscription and use the value of that extension for the name of the delivery queue.
The following three options derive the delivery queue name from the REST endpoint url of the subscription. E.g. if the subscription endpoint url is http://some.hostname.org:1234/app/path/subpath?foo=bar&baz=some/path then the queue name for that subscription delivery queue will be as follows.
ENDPOINT_HOST_PORT: "some-hostname-org-1234". This is the recommended value for enterprise installations. The advantage of this option is that if there are issues delivering to a particular endpoint, those issues will be constrained to the single threadpool managing deliveries for that queue.
Similarly, the name of each email delivery queue is