qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <james.strac...@gmail.com>
Subject Re: A question for the ActiveMQ chaps on the list...
Date Fri, 22 Sep 2006 12:16:37 GMT
On 9/22/06, Gordon Sim <gsim@redhat.com> wrote:
> James Strachan wrote:
> > If other messaging providers are to support AMQP then it'd make sense
> > to make it as easy as possible for folks to reuse as much of the basic
> > plumbing code from the qpid project as possible.
> I agree. This would be useful and is not currently addressed. Rajith's
> earlier proposal on a protocol level api would help on the client side.
> On the broker side I can see two levels at which there could be some reuse.
> (i) The framing layer objects could be used to parse any stream, though
> they are currently tied to MINA.
> (ii) The whole io processing layer could be made more resuable, which is
> what your mail proposed.
> I think both are good goals. (i) would allow implementations that wanted
> to manage the threading and io themselves but still reuse the parsing
> code. (ii) allows implementations to focus purely on wiring the AMQP
> requests to their own internal structures.

Agreed  - sounds good. If we get loads of users using AMQP in ActiveMQ
I can see us switching to (i) later on to avoid the MINA dependency
and allowing us to reuse our existing threading/transport stuff - but
to get started (ii) would be ideal.

> On (ii), as the java code stands, pluggability of 'method' handlers is
> done through a (state sensitive) registry. So one approach would be to
> allow the registered handlers to be reconfigured for different
> implementations. This is done through the AMQStateManager (and in fact
> in the clustering code I used this to get a cheap way of modifying
> handling of methods. This approach above only works for the 'methods',
> not content for which another plug-in point would be required. You're
> right of course that there is still quite a bit of cleanup work needed.

Yeah - I tried to tinker around there but as soon as AMQStateManager
is used it pulls in AMQMessage, AMQChannel, MessageStore,
QueueRegistry, ExchangeRegistery and pretty much the entire kitchen
sink pretty quickly :). So I was wondering if we could put a little
plugin a little lower down maybe to keep things as abstract as
possible to have things as loosely coupled as possible?

> We have something not unlike your suggestion in the c++ broker, where
> the handler logic is invoked through a series of interfaces matching the
> 'classes' of the protocol requests. Each method frame can invoke the
> method it represents on an instance of these interfaces (see a snippet
> below if interested). Content & header frames aren't treated this way,
> though we do have a InputHandler that simply handles any frame and gives
> a lower level separation from the io processing.



Am thinking if providers are trying to share code, there's not gonna
be whole lot of difference between the core part of the protocol in
terms of creating connections & channels; its mostly handling the
channel commands/methods where different implementations are gonna
want to plugin. The more of the basic plumbing code we can reuse (such
as validation of the commands and implementing the AMQP processing
rules etc) the better.



View raw message