...
Threading
The threading model used by the model must be understood before changes can be made safely.
...
ConfiguredObject categories such as SystemConfig and VirtualhostNode take responsibility for managing the storage of their children. This is marked up in the model with the @ManagedObject annotation (#managesChildren). These objects utilise a DurableConfigurationStore to persist their durable children to storage. ConfigurationChangeListener are used to trigger the update of the storage each time a ConfiguredObject is changed.
AMQP
...
Transport Layer
There are two AMQP IO Transport Layers in Broker-J.
- Traditional TCP/IP connections
- Websocket
...
This layer is implemented from first principles using Java NIO.
It is non-blocking in nature. It
It uses a Selector to monitor all the connection connected sockets (and the accepting socket) for work. Once work is detected (i.e. the selector awakensreturns) the connection work is service serviced by threads drawn from an IO thread pool. An An eat-what-you-kill pattern is used to reduce the need to dispatch latency. This works in the following way. The worker thread that performed the select, after adding all the ready connections to the work queue, adds the selector task to the work queue and then starts to process the work queue itself (this is the eat what you kill bit). This approach potentially avoid this dispatch latency between the selector thread avoids the dispatch latency between the thread that performed select and another thread from the IO thread pool. Th
Java NIO to perform non-blocking IO across all the connected sockets.
The accepting socket is
A NIO Selector is used to monitor both
The layer
A pool of IO threads are dedicated
The AMQP IO Layer in Qpid uses Java NIO. It utilises a Selector
Java NIO
Selector
The Selector is the responsibility of the SelectorThread class.
Connections to peers are represented by a NonBlockingConnection. The SelectorThread causes the NonBlockingConnections that require IO work to be executed (NonBlockingConnection#doWork). On each work cycle, the NonBlockingConnection first goes through a write phase where pending work is pulled from the protocol engine producing bytes for the wire in the process. If all the pending work is sent completely (i.e. the network buffer is not exhausted), the next phase is a read phase, where the bytes are consumed from the channel and fed into the protocol engine. Finally there is a further write phase to send any new bytes resulting from the input we have just read. The write/read/write sequence is organised so in order that the Broker first evacuates as much state from memory as possible (thus freeing memory) before reading new bytes from the wire.
In addition to the NonBlockingConnection being scheduled when bytes arrive for it from the wire, the Broker may need to awaken them at other times. For instance, if a message arrives on a queue that is suitable for a consumer, the NonBlockingConnection associated with that consumer must added on to the work queue. The mechanism that does this is NetworkConnectionScheduler#schedule method. This is wired to the protocol engine via a listener.
Threading
The only threads that execute NonBlockingConnnections are those of the NetworkConnectionScheduler. Furthermore, it is imperative that no NonBlockingConnnection is executed by more than one thread at once. It is the job of ConnectorProcessor to organise this exclusivity. Updates made by NonBlockingConnnection must be published safely so they can be read consistently by the other threads in the pool.
There is a NetworkConnectionScheduler associated with each AMQP Port and each VirtiualHost. When a connection is made to the Broker, the initial interactions between peer and broker (exchange of protocol headers, authentication) take place on the thread pool of the NetworkConnectionScheduler of the Port. Once the connection has indicate which VirtualHost it wishes to connect to, responsibility for the NonBlockingConnection shifts to the NetworkConnectionScheduler of the VirtualHost.Eat what you kill
AMQP Protocol Engines
Queues
HTTP, REST and Web Management
...