JBossMQ is made up of multiple layers and plugins.
At the front end there is the javax.jms implementation which can be found in org.jboss.mq..
Some of the work is handled at this layer, but most of the work is handed off to the server using a simplified
API called the IL (invocation layer).
The invocation layer is made up of two interfaces.
ServerIL - the requests are handled by the ServerILService on the server
ClientIL - allows the server to invoke back on the client's ClientILService (mainly to push messages to the client as they arrive)
There are a number of implementations of these interfaces which depends upon your choice of ConnectionFactory
The ServerILService targets the JMSServerInvoker whose responsibilty is to pass the request through a series of
The standard interceptors are:
TraceInterceptor - For debugging requests
SecurityInterceptor - To authenticate and authorise requests
JMSDestinationManager - The main server
The JMSDestinationManager is the main broker for requests. It performs three main operations
Passing subscription related requests to the StateManager
Passing message send requests to the JMSDestination
Passing message receive requests to the ClientConsumer
The JMSDestination provides different behaviour depending upon the type of destination, either
JMSQueue - queues
JMSTopic - topics
The ClientConsumer is reponsible for keeping track of client subscriptions.
It also pushes messages back to the client over the ClientIL as messages arrive.
The JMSDestination and ClientConsumer target BasicQueue implementations. There are a number
of different types:
BasicQueue - a simple queue used for temporary queues
PersistentQueue - a queue that persists messages used for permenant queues and durable topic subscriptions
ExclusiveQueue - an optimization of BasicQueue for non durable subscriptions
SelectorPersistentQueue - an optimization of PersistentQueue for topic subscriptions that have selectors
The SecurityManager is used by the SecurityInterceptor.
The default implementation delegates to a JAAS login module for authentication and uses configuration from the
JMSDestination for authorization.
The StateManager is responsible for maintaining durable subscription information.
It can also be used to maintain users and roles.
The PersistenceManager handles the saving and restoring of persistent messages.
It also maintains a transaction log for transactional sessions.
The MessageCache is used to avoid too many messages causing an OutOfMemoryError.
Instead of holding direct references to the messages the server holds a MessageReference.
The MessageReference either holds a direct reference to the message or a pointer to the message in an
offline store. This allows the server to move messages in and out of memory.
An Example Send
QueueSender -> ServerIL -> network -> ServerILService -> JMSServerInvoker -> TracingInterceptor ->
SecurityInterceptor -> JMSDestinationManager -> JMSQueue -> PersistentQueue
An Example Receive
QueueReceiver -> ServerIL -> network -> ServerILService -> JMSServerInvoker -> TracingInterceptor ->
SecurityInterceptor -> JMSDestinationManager -> ClientConsumer -> JMSQueue -> PersistentQueue
If no message is available the call returns, then when a message arrives:
PersistentQueue -> ClientConsumer -> ClientIL -> network -> ClientILService -> QueueReceiver