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: [email protected]
For additional commands, e-mail: [email protected]
