SSB receives notifications every 5 seconds from the SQL engine's timer framework. SSB in turn counts these notifications and performs its various periodic maintenance tasks at different intervals.
Tasks performed every notification:
1. Internal activation feature of SSB uses monitors for each user queue. On every notification, these queue monitors adjust the number of internal activation tasks to keep up with user queue load.
2. SSB has an internal task infrastructure which creates up to 2 times the number of CPU’s task-handlers to execute SSB async tasks. These task-handlers are started when the SQL engine starts up and are always running. On every notification, the task infrastructure checks if any task-handler failed to start and restarts it if required.
3. Message dispatcher is the module that receives messages from the SSB transport, validates and buffers them in its in-memory queues per dialog, until they get saved to user queues by its async tasks. On every notification, it deletes all out-of-order and stale messages from its in-memory queues. Stale messages are the ones that have not been picked up by the dispatchers receiving tasks in 10 seconds since their arrival.
Tasks performed every 2nd notification:
1. SSB transport layer is responsible for maintenance of network connections and packaging/un-packaging messages into/from network packets. Once notified, it attempts to establish connections with remote destinations that have pending messages and are not currently suppressed. A destination is suppressed for 15 seconds after disconnection and for 60 seconds after each unsuccessful connection attempt.
2. SSB transmitter is the intermediate layer between the dialogs and the transport and is responsible for associating dialogs to transport connections. Once notified, it trims its caches and reclassifies all or selected dialogs as a side-effect of any metadata changes, resource (usually memory or contention) limitations and route expirations. Reclassification of a dialog unregisters it with the transmitter and triggers it to register again with the transmitter so that the changes (new metadata or available memory) get consumed. This reclassification may result in temporary gap in transmission of messages from the selected dialogs. It may also resume transmission of messages from dialogs that were unsuccessful earlier due to resource crunch or security validations.
Tasks performed every 5th notification:
1. Transport layer scans all established connections and closes connections that have been idle for the past 90 seconds.
2. SSB message forwarder deletes all stale messages that could not be forwarded within 60 seconds of being received. Note that forwarded messages are held in memory and not persisted in any queue.
3. SSB scans all databases for which broker failed to start for any reason (e.g. missing Master Key), initializes in-memory representation of broker and attempts to restart it. It also fires BCN (Broker Configuration Notification) for BCN clients and resumes (if not already running) background task for cleaning-up acked messages from transmission queues of the databases that have any dialogs.