[CONF] Apache Qpid: Java Broker Modularisation (page edited)

[confluence]

Page Edited : qpid : Java Broker Modularisation Java Broker Modularisation has been edited by Aidan Skinner (Jun 24, 2009). (View changes) Content: In order to support multiple protocol versions and to provide greater flexibility, the Java broker should be better modularised than it is currently Layers  Clean seperation of responsibility into the following areas: I/O Layer - TCP, HTTP etc. Protocol Layer - AMQP 0-8/0-9, AMQP 1-0, potentially others Sessions - Active thread Model - Queues, Messages etc. Store - Two types of store, transaction log for recovery and disk store for flow to disk Broker internals - Message expiry, configuration file parsing, management etc. There will be a thread pool which services Runnable entities in the broker internals and sessions. The I/O layer, Protocol Layer and Model can all be considered passive entities, although they may have threads for their own purpouses. They do not initiate actions within the overall broker.  Sessions When a thread is allocated to a Session it will do one of three things: send things to the protocol layer for encoding, execute events from the protocol layer and pull messages from a queue. A session has 0 or more links to queues in the model, which it can create, send, receive, or drop, and a transaction which is in either not begun or in progress. Commiting a transaction moves it to not begun.  Events Events are read from the I/O layer by the protocol layer when asked for by a session.  A protocol event's handler is called by a Session which has a thread. The handler has access to the current transaction. It is responsible for interacting with the model, enqueuing messages, creating queues etc  Model The model provides entities modelling version independent Queues, Messages and other entities which Protocol Events interact with, and which are maintained by the broker internals. The layout of model entities such as queues is likely to be stored in a SQL database for ease of tooling.  I/O layer This is responsible for reading and writing byte streams and making them available to the protocol layer for decoding. See Network IO Interface for more details.  Stores There are two types of store. There are transaction logs, which record events in a way which makes it possible to recover to a known state in the event of broker failure without losing messages. There are also on-disk stores which provide random-access retrieval of messages which are too large or too numerous to store in memory.  Protocol plugin A protocol plugin provides a set of ProtocolHandlers which implement a particular version of the AMQP specification. They contain handlers for the events necessary, codecs for message from other protocol versions and model entities to implement protocol-specific behaviour. For instance, the AMQP 0-8/0-9 plugin will contain a subclass of Queue which implements the Exchange behaviour for routing and support for immediate and mandatory message flags through dead letter queues and 0 span message TTLs. These queues would be 0 length and would have links to other queues which mapped to bindings. Messages would arrive at those queues and be moved onto the link by the queue subclass.

Powered by Atlassian Confluence (Version: 2.2.9 Build:#527 Sep 07, 2006) - Bug/feature request

Unsubscribe or edit your notifications preferences

--------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:commits-subscr...@qpid.apache.org