I tried to follow these instructions, but they may be a bit dated because they are for the M1 client. I could not get the new M2 to interop, but I also admit that I did not try very hard. I fixed up the known differences (access tickets, strict flag, extra args on consume) but it would not go and I gave up there for now.
On 11/01/2008, Alexis Richardson <[EMAIL PROTECTED]> wrote: > > Rajith > > On Jan 11, 2008 2:52 PM, Rajith Attapattu <[EMAIL PROTECTED]> wrote: > > Robert, > > > > You highlight a good point. I think it was mistake for us to deviate > from > > the spec to support JMS. > > However I think we tried to make that configurable via the stritct AMQP > > flag. Apparently we seem to have fallen short there. > > The other major issue if the access ticket thing, but If I remember > Rabbit > > had someway of disabling this right? > > You can see how to do all this sort of thing here: > > http://www.rabbitmq.com/interoperability.html > > Please complain vociferously if you do not see any necessary > information to achieve what you want. > > alexis > > > > > > > > > > > > > > > On Jan 11, 2008 9:37 AM, Robert Godfrey <[EMAIL PROTECTED]> wrote: > > > > > Interoperability must be a priority for us. > > > > > > It was definitely a mistake for us (Qpid) to change the spec file that > > > we were working off in ways which made it incompatible with other 0-8 > > > implementations, even if the intent was good (we were tracking > > > emerging changes to the spec). > > > > > > What I have done in the 0-9 implementation of the Java is to add to > > > the spec in ways which do not break compatibility with generic AMQP > > > compliant 0-9 clients. > > > > > > My view is that we should make it a priority to get Qpid > > > interoperating with the other AMQP implementations, and that therefore > > > strict AMQP compliance is important. I realise that many of us want > > > to move to AMQP 0-10 which is about to be released publicly; however > > > given the products on the market which already use 0-8 or 0-9 I think > > > it would be advantageous to try to provide comprehensive support for > > > this version. > > > > > > Also as Qpid has the widest language choice of client implementations > > > I think it helps everybody if we make available compliant 0-8/0-9 > > > versions of these. > > > > > > Now, in order for our Java client to implement JMS we do need to put > > > in extensions over base AMQP; and if you want to use JMS messaging > > > using AMQP, then Qpid will be the only choice at the moment - until we > > > can get equivalent functionality incorporated into the AMQP spec. > > > > > > As Michael makes clear below - one (possibly compelling) factor > > > influencing people to choose to use an AMQP broker over some other > > > vendor's messaging product is the fact that alternative > > > implementations exist. Therefore we should look to co-operate as well > > > as compete; and in particular work to make sure all AMQP products can > > > exchange messages seamlessly. > > > > > > -- Rob > > > > > > On 11/01/2008, Michael Arnoldus <[EMAIL PROTECTED]> wrote: > > > > Hi Robert, > > > > > > > > On Jan 10, 2008, at 17:14 , Robert Greig wrote: > > > > > > > > > > The only reason for the deviation from the AMQP spec was that the > > > > > official 0-8 spec had limitations that meant we could not achieve > full > > > > > JMS compliance without some changes. We had other users for whom > full > > > > > JMS compliance was critical. > > > > > > > > And I can see why that would make sense from a java perspective. > > > > However that actively discouraged us in trying out QPID as a broker. > > > > > > > > > > > > > > > > > > >> Also - interesting discussion about performance - I'd be > interested > > > > >> in > > > > >> better and less biased comparisons, while I'm still aware that > msg/ > > > > >> sec > > > > >> and latency is not the only interesting kind of performance in a > > > > >> product like this. > > > > > > > > > > What are your performance requirements? What client > implementations do > > > > > you need? Are you interested in road testing Qpid? Our recent M2 > > > > > release incorporates a huge number of changes and improvements. > > > > > > > > Currently my primary performance requirements are stability, ease of > > > > installation and use, scalability and support. If you win in those > > > > areas, I really don't care if I need to buy machines with 4 times as > > > > many cores to achieve the same performance. If I have scalability, > > > > hardware is VERY cheap!!! Using my developers time on stuff that > > > > doesn't work, are difficult to use or to build are far more > expensive. > > > > > > > > Thanks for your offer on road testing, which I have to decline. > We're > > > > fairly busy at the moment, and Rabbit actually works for us right > now. > > > > However it is very important for me in my choice of AMQP that > several > > > > implementations do exist - and I do find QPID interesting and will > > > > definitely try it out in the future. > > > > > > > > Michael > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Regards, > > > > Rajith Attapattu > > Red Hat > > blog: http://rajith.2rlabs.com/ > > > > > > -- > Alexis Richardson > +44 20 7617 7339 (UK) > +44 77 9865 2911 (cell) > +1 650 206 2517 (US) >
