Frame dispatch refactoring proposal.

Classes
class	FrameHandler
	Common interface for frame handlers. More...
class	Session
	Represents a Session. Much omitted. More...
class	ClusterSession
	Cluster session with extra chains. More...
class	Frame
	New Frame methods. More...

---

Detailed Description

Overview

More consistent & flexible use of handler chains for frame dispatch to enable clustering. Clustering needs to "intercept" the dispatch process at various points.

Qpid already has input and output handlers. This proposal would

• Unify InputHandler and OutputHandler to a single FrameHandler.
• Fold AMQFrame and AMQBody into a single Frame class hierarchy.
• Configure different behavior by altering handler chain configuration.
• Refactor request/reply numbering as a handler.
• Dipatch concrete frame type with all frame data not just method args.

Side/future benefits:

• Generally simpler, cleaner and more flexibly broker architecture.
• We can unify client and broker-side dispatch mechanisms.
• Helps multi-version, separates version-specific/generic code.
• Helps multi-protocol, can replace protocol handlers.

Session

A Session holds information about the context in which frames are processed. In 0-9 Sesions have 1-1 relationship with Channels.

A Frame holds a pointer to the Session it is associated with.

0-9 handler chains

Each Channel has an associated Session. A Session has two chains of FrameHandlers for incoming and outgoing frames. A channel delivers incoming frames to the Session::incoming() handler. Handlers are per-session and may hold per-session state.

For 0-9 the handlers are:

• SetSessionHandler: calls Frame::setSession(this)
• RequestResponseHandler: Update 0-9 request/response IDs.
• ProcessFrameHandler: Delegate to version-specific AMQP method handlers.

If an AMQP method handler wants to send frames back to the client it uses the Session::outgoing() chain. For 0-9 that would be:

• SetSessionHandler: calls Frame::setSession(this)
• RequestResponseHandler: update 0-9 request/response IDs.
• ConnectionSendHandler: send frame to client via AMQP connection.

Handler chains for clustering.

Initial cluster implementation will have a common broker model synchronized across all nodes with CPG (Closed Process Group, part of openais.)

CPG guarantees ordrer of delivery with "self-delivery". A node that sends a message cannot take actions associated with that message until it is self-delivered via the CPG API.

The sequence of events is:

• frame arrives via AMQP
• frame multicast via CPG
• frame delivered via CPG
• update the local model
• IF session is local then reply to client, else update local session model to indicate reply was sent.

ClusterSession::incoming has a short chain:

• ReplicateOutHandler: multicast frame to cluster

When a frame is (self-) delivered by CPG it is handed to the ClusterSession::clusterIncoming() chain which is just like a 0-9 incoming chain.

ClusterSession::outgoing depends on whether the session is local (current node is primary) or not. For a local session it is just like 0-9. For a remote session:

• SetSessionHandler: calls Frame::setSession(this)
• RequestResponseHandler: update 0-9 request/response IDs.
• UpdateSessionHandler: update local session replica.

Some important details omitted: esp correspondence between connections, Channels, Sessions and channel-ids/session-ids. Multicast frames will be accompanied by a cluster-wide unique session identifier so nodes identify the correct Session object.

Note that although this is not our final goal for clustering, the final goal can be reached by implementing additional handlers (e.g. PointToPointBackupHandler) and adding logic to choose the right handlers based on configuration of primary, backup etc.

We will retain multicast backup for wiring, so the above will still apply to queue.declare et. al.

We will probably need a Cluster class for inter-node communication at some point.

MethodContext and method handlers refactor.

Replace MethodContext with Frame in handler signatures to give handlers full access to frame data.

This actually makes all the other arguments redundant. Getting rid of them would open some interesting template possibilities that would help multi-version but it's not critical for clustering.

---