qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexis Richardson" <alexis.richard...@cohesiveft.com>
Subject Re: M2.1plan
Date Fri, 11 Jan 2008 15:31:47 GMT
Rupert

On Jan 11, 2008 3:23 PM, Rupert Smith <rupertlssmith@googlemail.com> wrote:
> 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.

Could you send us a bit more detail please?  We'll take a look.

alexis




>
>
> On 11/01/2008, Alexis Richardson <alexis.richardson@cohesiveft.com> wrote:
> > Rajith
> >
> > On Jan 11, 2008 2:52 PM, Rajith Attapattu <rajith77@gmail.com> 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 < rob.j.godfrey@gmail.com>
> 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 <chime@wiinz.com> 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)
> >
>
>



-- 
Alexis Richardson
+44 20 7617 7339 (UK)
+44 77 9865 2911 (cell)
+1 650 206 2517 (US)

Mime
View raw message