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:
Two properties are shared by both JMS and Kafka:
module.clustermgr.config.subscription.consumers_per_matching_queue =2 module.clustermgr.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
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
masterModuleId are the node ID and module ID of the Master Node.
The name of the Subscription Matching Queue is
The name of each rest-hook delivery queue is
NAME depends on the value of
Similarly, the name of each email delivery queue is