qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fraser Adams <fraser.ad...@blueyonder.co.uk>
Subject Re: Java broker exchange questions
Date Sun, 10 Mar 2013 08:26:45 GMT
On 09/03/13 16:46, Rob Godfrey wrote:
> Yeah... The biggest gap is probable going to be broker <-> broker
> federation links.  That code did exist previously in the Java Broker,
> but it disappeared when we ripped out the QMF1 implementation.
I'm curious here, are you saying that federation existed in the Java 
Broker? As far as I was aware federation was only possible between C++ 
brokers and I thought that it was necessary to do some sort of client 
side bridge to link between C++ and Java Brokers or to connect Java 
Brokers. I was fairly sure I'd seen postings to that effect on the user 
list. Though as I say I'm vastly unfamiliar with the Java Broker and 
this work I'm doing is my first journey there.

Looking at the 0.20 code I've got installed there is a federation 
directory in

<qpid-root>/java/broker/src/main/java/org/apache/qpid/server

but it's empty in 0.20.

>   We
> could probably add it back in but it would have to fit within the new
> internal model for configuration that Alex/Robbie have been working
> on.
Just to be clear in my mind and to make sure that I'm using the right 
stuff in my QMF mapping by the new internal model are you talking about 
the stuff that lives in:

<qpid-root>/java/broker/src/main/java/org/apache/qpid/server/model

Please say yes :-)

My QmfManagementAgent is built following the same general patterns as 
the management-http and management-jmx stuff in broker-plugins using the 
ManagementFactory and ManagementPlugin stuff. I've basically used the 
ConfigurationChangeListener interface methods to track changes to the 
server/model ConfiguredObjects and when childAdded is called I use that 
to create concrete QmfAgentData objects that wrap the equivalent 
ConfiguredObject instance. There's *largely* a one-to-one between those 
objects and their QMF equivalents though some of the 
properties/statistics need to be mapped.

To be honest the hardest stuff I've had to cope with to date was due to 
the fact that qpid-config is a bit weird - it doesn't use object 
references correctly and has a hard coded ObjectId for the broker agent 
for method invocation (rather than discovering the broker object's 
ObjectId) so I had to make sure that my Agent copes with that.

>
> Other than that I don't think there are *huge* gaps, just a number of
> things done annoyingly differently (Gordon and I have tried to rectify
> this in fits and starts over the years).  The QMF schema also tended
> to make some assumptions based on how the C++ broker was modelled that
> just didn't hold true for the Java Broker.
If I'm doing it right from what I've seen the differences aren't so very 
bad with the new model. It's only taken me a couple of weekends to get 
to the state where both my QMF GUI and qpid-config can do useful things 
with the Java Broker.

One of the biggest quirks is actually the Virtual Host stuff in the Java 
Broker. Although there are Virtual Host QMF Objects I'm not aware that 
the C++ Broker is really Virtual Host aware? I don't believe that things 
like qpid-config are either - are they?

What I've done in order to allow things like qpid-config to work is to 
prefix queues/exchanges relating to the non-default vhost in other words:

[vhost:<vhost-name>/]<exchange-name> and [vhost:<vhost-name>/]<queue-name>

e.g.

qpid-config exchanges
Type      Exchange Name                 Attributes
============================================================
fanout    vhost:development/amq.fanout  --durable
topic     vhost:localhost/amq.topic     --durable
direct    vhost:localhost/amq.direct    --durable
fanout    vhost:localhost/amq.fanout    --durable
direct    vhost:localhost/test.direct   --durable
headers   vhost:localhost/amq.match     --durable
headers   vhost:development/amq.match   --durable
topic     monkey1
fanout    monkey3
direct    vhost:development/            --durable
direct    qmf.default.direct            --durable

I need to look to ordering the getObjects() query response base on name 
to make this look neater, but it seems to be the most interoperable 
approach at the moment.

> So, personally I'm mostly looking at AMQP 1.0 these days where there
> isn't the Exchange/Queue division and selection/distribution is a
> property of the links.
Is there a good simple reference explaining this stuff (aside from 
poring over the AMQP 1.0 specs, which I've not done yet - or could you 
point me at the relevant subsection?). I'm a little nervous 'cause to 
date I've mostly been thinking around exchanges, queues and bindings 
between them. From what I'd understood qpid::messaging was intended to 
provide an abstraction that was agnostic to the AMQP version so I'm 
assuming that existing AddressStrings still ought to work with AMQP 1.0??

>   As such I'm not sure I'd personally spend a
> lot of time writing an XML exchange... but given the XML tooling
> available in Java then I wouldn't imagine it would be a huge task.
That's why I was curious about the XML exchange. I personally prefer the 
idea of relatively simple subscriptions with finer grained filtering 
using Message Selectors but that was never really an option with C++ 
broker and clients. You could do it with C++ broker and Java clients but 
the Message Selectors were implemented in the client runtime so it 
wasn't a very efficient approach. Andrew Stitcher has just announced 
initial Message Selector support on the C++ broker, so I'm very excited 
about that.
> The larger task I would like to undertake is to make it possible to
> just drop in jars containing new Exchange / Queue types in a pluggable
> manner.
That sounds really cool.
>
> Speaking of AMQP 1.0, we're currently working on standardising
> Management over AMQP 1.0.  I'd expect the first draft of this to come
> out in the next month or so... covering the mechanisms but not
> attempting to define any "schema" for manageable objects.  This is
> probably where I'll be looking to expend any time I have relative to
> management work (especially when coupled with AMQP 1.0 over WebSockets
> and a pure JavaScript AMQP 1.0 implementation).
Rob as you might have gathered given all the work I've done on QMF and 
the QMF GUI I'm *extremely* interested in anything that is afoot with 
respect to Management. I've put a huge amount of effort into that stuff 
so I'm clearly keen to make sure that changes don't break things (well 
too badly :-)) and to evolve things where possible. I guess that the 
same is true of the broker internals such as the 
<qpid-root>/java/broker/src/main/java/org/apache/qpid/server/model which 
seems to be fairly recent.

I'd be really grateful if you could keep me in the loop on the current 
thinking on this.


Re "AMQP 1.0 over WebSockets and a pure JavaScript AMQP 1.0 
implementation" that sounds pretty cool. How far down the road has this 
travelled? Would the approach be to go from AMQP 1.0 in a browser say 
via a WebSocket Server such as Node.js then via TCP sockets to a Broker. 
I guess a pure JS Broker deployed into Node would be cool too. Is this 
likely to be limited to Node.js or would you expect the WebSocket bridge 
to be deployable on other Servers?

Cheers,
Frase

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message