Page History

...

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 IO Layer

There are two AMQP IO Layers in Broker-J.

• Traditional TCP/IP connections
• Websocket

We'll consider the two layers separately.

TCP/IP

This layer is implemented from first principles using Java NIO.

It is non-blocking in nature.  It uses a Selector to monitor all the connection sockets (and the accepting socket) for work.  Once work is detected (i.e. the selector awakens) the connection work is service by threads drawn from an IO thread pool.

An eat-what-you-kill pattern is used to reduce the need to dispatch.  This works in the following way.   The 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 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

Eat what you kill

...