Smile CDR v2023.11.PRE
On this page:

3.4.1Message Brokers


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.

3.4.2Subscription Channels


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.

3.4.3Subscription Channel Names


All Subscription Queue names end with -[NODE_ID]-[STORAGE_MODULE_ID] where [NODE_ID] and [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 Master and persistence respsectively.

The name of the Subscription Matching Queue is subscription-matching-[NODE_ID]-[STORAGE_MODULE_ID].

The name of each rest-hook delivery queue is subscription-delivery-rest-hook-[NAME]-[NODE_ID]-[STORAGE_MODULE_ID] where [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 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 then the queue name for that subscription delivery queue will be as follows.

  • ENDPOINT_HOST: "some-hostname-org"

  • 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.

  • ENDPOINT_HOST_PORT_PATH: "some-hostname-org-1234-app-path-subpath"

Similarly, the name of each email delivery queue is subscription-delivery-email-[NAME]-[NODE_ID]-[STORAGE_MODULE_ID].