...
Class | Description | |
---|---|---|
Inbound |
| All inbound events (such as message arrival, subscription add/close events etc.) are handled through this class. |
| The incoming message goes through this processor first, where its message ID and destination data are populated to ensure the message order closest to the message arrival time. | |
| This processor will take the message content chunks, convert them to the andes core chunk size and delegate the rest of the work to the | |
| This processor will write the message metadata and content chunks to the storage database using a batch approach. | |
| Upon saving the message to storage, this handler is triggered to notify a message received event, or to notify a message acknowledged event from the consumer. | |
| This event is used to communicate the transaction commit/rollback events from the publisher. | |
Outbound |
| This processor is used to deliver the message to one/all of the active subscriptions (based on the message destination). |
| This class is used to handover the message to the consumer after reading from the internal message buffer ( | |
| There are multiple slot delivery workers managed by the | |
| This is where the coordinator logic resides within WSO2 MB. All slots are managed and distributed through this class across the cluster. | |
AMQP |
| A channel is used for delivering and accepting messages to/from the broker. Each AMQP consumer/publisher has its own unique channel with a channel ID. |
| This is used as the bridge between the Qpid messaging events and Andes events. | |
MQTT |
| This is used as the bridge between the moquette messaging events and Andes events. |
| This handles all events coming through the moquette disruptor (such as subscriber-connect, pub-acks etc.) and connects to the | |
| This class acts as an interface before storing MQTT messages to the message store, validating the message format, in addition to handling events such as consumer/publisher creation and closing in terms of the message store. | |
| This class handles the lifecycle of MQTT subscriptions and also takes part in routing a given message to matching subscribers. |
Message tracing
This is an MB-specific logging implementation for tracing a message through its inbound event until it is delivered to the consumer application. This implementation has minimal impact on the performance of the broker functionality. To enable message tracing in WSO2 MB:
- Open the
log4j.properties
file stored in the<MB_HOME>/repository/conf
folder. Uncomment the following:
Code Block #log4j.logger.org.wso2.andes.tools.utils.MessageTracer=TRACE,CARBON_TRACE_LOGFILE
Once message tracing is enabled, you can start the server and execute a grep
command with the relevant message ID you want to trace. This will give print all the logs related to your message ID on your terminal.
...