On 10 March 2013 09:26, Fraser Adams <[email protected]> wrote: > 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. >
Yeah... there was an implementation of the federation code which worked with the QMF1 implementation. I'm not sure it was 100% complete but it covered most of the functionality I was aware of. Unfortunately the QMF1 stuff kept getting broken and there was no other way of configuring it (I originally only implemented QMF1 so that I could add federation to the Java Broker and have a single set of management tools across the two brokers... it just ended up being more trouble than it was worth). I can't remember when we ripped out the QMF1 implementation (0.18 perhaps, but it wasn't *too* long ago). > 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 :-) > 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? Yeah - this is another biggie - the C++ broker doesn't really do vhosts. There are operatins on the QMF "broker" that actually relate to the vhost on the Java, but there are some things that truely are "broker" properties. > > 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?? > I'm not sure whether there's any really good summary documentation out there. In essence AMQP 1.0 only defines the semantics of reliable message transfer between peers - it does very little in terms of definition of the internal broker model. It talks of sending messages between sources and targets and defines some associated semantics (like the existence of fiters/selectors)... but nothing about what a broker might do in terms of internal routing. AddressStrings (in the qpid::messaging sense) should be a purely client side implementation detail, so if correctly implemented they should still "work" with AMQP 1.0... but they aren't really something an AMQP 1.0 broker would be aware of. > >> 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. > Yeah - I've not looked at Andrew's work in detail... other than to note that as ever it is close but not identical to the Java implementation ... I believe that the implementation is only as a filter on the consumer from a queue... In the Java Broker we also added the ability to add selectors to a binding between a queue and an exchange (in fact only on the topic exchange, but this is something we should extend to all exchanges). Adding selectors to bindings is necessary if you want to do pub/sub with selectors, else your temporary subscription queues fill up with stuff that you are never going to consume. >> 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. > > Sure - we (the OASIS AMQP Technical Committee) have not published anything yet, but should do in a couple of weeks. I don't suppose you work for a firm that is already an OASIS member, do you? > 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. Adding websockets as a transport to an existing broker is no big deal - I knocked up a prototype for the Java Broker in about an hour using Jetty. I'm not overly familiar with library availability in the C/C++ world but I'd expect it should be similarly easy to integrate websockets as a transport alternative to TCP for other languages too. > 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 > -- Rob > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
