You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Aidan Skinner <ai...@apache.org> on 2008/01/09 17:32:27 UTC
M2.1plan
Hello all, hope you had a good break. :)
We talked about finishing the M2.1 release at the F2F and doing
quaterly releases, so I'm proposing that we aim to get M2.1 out on
Wednesday 2008-04-02, with a code freeze (ie. important bug fixes
only, no new features) on that branch from Friday 2008-02-22 so we
have some time for testing. I'll act as release manager for this now I
(nearly) have the right bits unless there are objections from other
volunteers. ;)
In parallel to this, I'll start doing the merge of M2 with trunk on a
branch (taken from and tracking trunk), I'm currently beating git with
a stick so I can use it's better merge capabilities.
- Aidan
--
aim/y!:aidans42 g:aidan.skinner@gmail.com
http://aidan.skinner.me.uk/
"When the going gets weird, the weird turn pro."
-- Hunter S. Thompson
Re: M2.1plan
Posted by Aidan Skinner <ai...@apache.org>.
On Jan 9, 2008 5:24 PM, Carl Trieloff <cc...@redhat.com> wrote:
> are you using month day, or day month?
Sorry, those are ISO format dates, year-month-day. :)
- Aidan
--
aim/y!:aidans42 g:aidan.skinner@gmail.com
http://aidan.skinner.me.uk/
"When the going gets weird, the weird turn pro."
-- Hunter S. Thompson
Re: M2.1plan
Posted by Martin Ritchie <ri...@apache.org>.
I believe that those are ISO-8601 dates so in the format YYYY-MM-DD
http://www.iso.org/iso/support/faqs/faqs_widely_used_standards/widely_used_standards_other/date_and_time_format.htm
I would highly recommend anyone writing dates to utilise this format.
The sooner the YY-DD-MM madness ends the better.
Seriously when is 08-04-02?
On 09/01/2008, Carl Trieloff <cc...@redhat.com> wrote:
>
> Aidan,
>
> are you using month day, or day month?
>
> Carl.
>
>
> Aidan Skinner wrote:
> > Hello all, hope you had a good break. :)
> >
> > We talked about finishing the M2.1 release at the F2F and doing
> > quaterly releases, so I'm proposing that we aim to get M2.1 out on
> > Wednesday 2008-04-02, with a code freeze (ie. important bug fixes
> > only, no new features) on that branch from Friday 2008-02-22 so we
> > have some time for testing. I'll act as release manager for this now I
> > (nearly) have the right bits unless there are objections from other
> > volunteers. ;)
> >
> > In parallel to this, I'll start doing the merge of M2 with trunk on a
> > branch (taken from and tracking trunk), I'm currently beating git with
> > a stick so I can use it's better merge capabilities.
> >
> > - Aidan
> >
>
>
--
Martin Ritchie
Re: M2.1plan
Posted by Carl Trieloff <cc...@redhat.com>.
Aidan,
are you using month day, or day month?
Carl.
Aidan Skinner wrote:
> Hello all, hope you had a good break. :)
>
> We talked about finishing the M2.1 release at the F2F and doing
> quaterly releases, so I'm proposing that we aim to get M2.1 out on
> Wednesday 2008-04-02, with a code freeze (ie. important bug fixes
> only, no new features) on that branch from Friday 2008-02-22 so we
> have some time for testing. I'll act as release manager for this now I
> (nearly) have the right bits unless there are objections from other
> volunteers. ;)
>
> In parallel to this, I'll start doing the merge of M2 with trunk on a
> branch (taken from and tracking trunk), I'm currently beating git with
> a stick so I can use it's better merge capabilities.
>
> - Aidan
>
Re: M2.1plan
Posted by Aidan Skinner <ai...@apache.org>.
On Jan 11, 2008 3:40 PM, Robert Greig <ro...@gmail.com> wrote:
> On 11/01/2008, Carl Trieloff <cc...@redhat.com> wrote:
>
> > Might it make more sense to put M2.1 and M3 out at the same time? That
> > way we can provide
> > best interop between then.
>
> It seems to me - and correct me if I am wrong - that M2.1 is much more
> of a "known quantity" than M3 which implements the 0-10 protocol.
>
> I think it is important to get this "interop release" out as quickly
> as possible so from that perspective it would make sense not to tie it
> to another release.
I don't see much reason to tie the two together, 0-8 and 0-9 are fixed
targets which M3 needs to support as well and it will need to support
them in the form of existing M2 (ie. 0-8) deployments so any fixes
need to be done there.
- Aidan
--
aim/y!:aidans42 g:aidan.skinner@gmail.com
http://aidan.skinner.me.uk/
"It is no weakness for the wisest man to learn when he is wrong." - Sophocles
Re: M2.1plan
Posted by Robert Greig <ro...@gmail.com>.
On 11/01/2008, Carl Trieloff <cc...@redhat.com> wrote:
> Might it make more sense to put M2.1 and M3 out at the same time? That
> way we can provide
> best interop between then.
It seems to me - and correct me if I am wrong - that M2.1 is much more
of a "known quantity" than M3 which implements the 0-10 protocol.
I think it is important to get this "interop release" out as quickly
as possible so from that perspective it would make sense not to tie it
to another release.
If M3 is all done and dusted at the point of the proposed M2.1 code
freeze then fine, but otherwise I would suggest we keep the releases
separate.
RG
Re: M2.1plan
Posted by Carl Trieloff <cc...@redhat.com>.
Aidan Skinner wrote:
> On Jan 11, 2008 2:46 PM, Rajith Attapattu <ra...@gmail.com> wrote:
>
>
>> Just to clarify, looking at the dates given for M2.1, it looks like we are
>> releasing early April.
>> I thought we agreed to finish M2.1 soon and plan M3 for March time frame? Or
>> did I misunderstand the dates?
>>
>
> Nope, that's the plan. It gives us 6 weeks to hack and 6 weeks to
> test, which doesn't seem unreasonable given prior experience. M3 work
> can happen in parallel, as it has traditonally done, as I get the
> merge under way on a seperate branch (taken from trunk and tracking
> changes there and pulling stuff in from M2x).
>
> - Aidan
>
Might it make more sense to put M2.1 and M3 out at the same time? That
way we can provide
best interop between then.
Carl.
Re: M2.1plan
Posted by Rajith Attapattu <ra...@gmail.com>.
Thanks Aidan, yes 6 weeks for hacking and testing seems reasonable.
Doing a release in parallel is fine. But I assume certain fixes in trunk may
need to be done in the branch and most certainly most of the fixes done on
the branch may end up in the trunk.
So we may need to have a good strategy in cordinating all these issues.
Rajith
On Jan 11, 2008 10:15 AM, Aidan Skinner <ai...@apache.org> wrote:
> On Jan 11, 2008 2:46 PM, Rajith Attapattu <ra...@gmail.com> wrote:
>
> > Just to clarify, looking at the dates given for M2.1, it looks like we
> are
> > releasing early April.
> > I thought we agreed to finish M2.1 soon and plan M3 for March time
> frame? Or
> > did I misunderstand the dates?
>
> Nope, that's the plan. It gives us 6 weeks to hack and 6 weeks to
> test, which doesn't seem unreasonable given prior experience. M3 work
> can happen in parallel, as it has traditonally done, as I get the
> merge under way on a seperate branch (taken from trunk and tracking
> changes there and pulling stuff in from M2x).
>
> - Aidan
> --
> aim/y!:aidans42 g:aidan.skinner@gmail.com
> http://aidan.skinner.me.uk/
> "It is no weakness for the wisest man to learn when he is wrong." -
> Sophocles
>
--
Regards,
Rajith Attapattu
Red Hat
blog: http://rajith.2rlabs.com/
Re: M2.1plan
Posted by Aidan Skinner <ai...@apache.org>.
On Jan 11, 2008 2:46 PM, Rajith Attapattu <ra...@gmail.com> wrote:
> Just to clarify, looking at the dates given for M2.1, it looks like we are
> releasing early April.
> I thought we agreed to finish M2.1 soon and plan M3 for March time frame? Or
> did I misunderstand the dates?
Nope, that's the plan. It gives us 6 weeks to hack and 6 weeks to
test, which doesn't seem unreasonable given prior experience. M3 work
can happen in parallel, as it has traditonally done, as I get the
merge under way on a seperate branch (taken from trunk and tracking
changes there and pulling stuff in from M2x).
- Aidan
--
aim/y!:aidans42 g:aidan.skinner@gmail.com
http://aidan.skinner.me.uk/
"It is no weakness for the wisest man to learn when he is wrong." - Sophocles
Re: M2.1plan
Posted by Rajith Attapattu <ra...@gmail.com>.
Aidan,
Just to clarify, looking at the dates given for M2.1, it looks like we are
releasing early April.
I thought we agreed to finish M2.1 soon and plan M3 for March time frame? Or
did I misunderstand the dates?
Rajith
On Jan 11, 2008 6:36 AM, Aidan Skinner <ai...@apache.org> wrote:
> On Jan 11, 2008 1:45 AM, Carl Trieloff <cc...@redhat.com> wrote:
>
> > back to the release schedule, I think the schedule is fine, can we also
> > set the date for M3 March, week 11 to pick a date. I would expect that
> to be
> >
> > C++ Broker & client 0-10
> > Java Client 0-10 & 0-8/9?
> > Python Client 0-10 (speaks all versions)
> > .NET 0-10 will M2 be 0-8/9 and M2 0-10 only in the client.
> > Ruby 0-10.
>
> I'm not sure I really have a good sense of where the various bits of
> this are, particularly the .Net, Python and Ruby clients. Do you know
> what state they are in (particularly wrt 0-10 support)?
>
> > I believe we would have a Java broker with merged M2.1 and ready for
> > 0-10, but most like not supporting 0-10 fully yet.
>
> I definately can't see us having a full on 0-10 java broker by that point,
> no.
>
> - Aidan
> --
> aim/y!:aidans42 g:aidan.skinner@gmail.com
> http://aidan.skinner.me.uk/
> "It is no weakness for the wisest man to learn when he is wrong." -
> Sophocles
>
--
Regards,
Rajith Attapattu
Red Hat
blog: http://rajith.2rlabs.com/
Re: M2.1plan
Posted by Aidan Skinner <ai...@apache.org>.
On Jan 11, 2008 1:45 AM, Carl Trieloff <cc...@redhat.com> wrote:
> back to the release schedule, I think the schedule is fine, can we also
> set the date for M3 March, week 11 to pick a date. I would expect that to be
>
> C++ Broker & client 0-10
> Java Client 0-10 & 0-8/9?
> Python Client 0-10 (speaks all versions)
> .NET 0-10 will M2 be 0-8/9 and M2 0-10 only in the client.
> Ruby 0-10.
I'm not sure I really have a good sense of where the various bits of
this are, particularly the .Net, Python and Ruby clients. Do you know
what state they are in (particularly wrt 0-10 support)?
> I believe we would have a Java broker with merged M2.1 and ready for
> 0-10, but most like not supporting 0-10 fully yet.
I definately can't see us having a full on 0-10 java broker by that point, no.
- Aidan
--
aim/y!:aidans42 g:aidan.skinner@gmail.com
http://aidan.skinner.me.uk/
"It is no weakness for the wisest man to learn when he is wrong." - Sophocles
Re: M2.1plan
Posted by Carl Trieloff <cc...@redhat.com>.
Aidan,
back to the release schedule, I think the schedule is fine, can we also
set the date for M3 March, week 11 to pick a date. I would expect that to be
C++ Broker & client 0-10
Java Client 0-10 & 0-8/9?
Python Client 0-10 (speaks all versions)
.NET 0-10 will M2 be 0-8/9 and M2 0-10 only in the client.
Ruby 0-10.
I believe we would have a Java broker with merged M2.1 and ready for
0-10, but most like not supporting 0-10 fully yet.
Carl.
Aidan Skinner wrote:
> Hello all, hope you had a good break. :)
>
> We talked about finishing the M2.1 release at the F2F and doing
> quaterly releases, so I'm proposing that we aim to get M2.1 out on
> Wednesday 2008-04-02, with a code freeze (ie. important bug fixes
> only, no new features) on that branch from Friday 2008-02-22 so we
> have some time for testing. I'll act as release manager for this now I
> (nearly) have the right bits unless there are objections from other
> volunteers. ;)
>
> In parallel to this, I'll start doing the merge of M2 with trunk on a
> branch (taken from and tracking trunk), I'm currently beating git with
> a stick so I can use it's better merge capabilities.
>
> - Aidan
>
Re: M2.1plan
Posted by Martin Ritchie <ri...@apache.org>.
I have updated the JIRAs to reflect the listed IDs.
On 10/01/2008, Arnaud Simon <as...@redhat.com> wrote:
> Aidan,
>
> Should we schedule a call for sharing the workload?
> Cheers
>
> Arnaud
>
>
> On Wed, 2008-01-09 at 23:29 +0000, Aidan Skinner wrote:
> > On Jan 9, 2008 10:47 PM, Robert Greig <ro...@gmail.com> wrote:
> >
> > > Is it accurate to say that all issues with the "fix for" field set to
> > > M2.1 must be done for this release or is the plan just to see what is
> > > done on 22 Feb? I see from Jira that there are 65 issues, a good
> > > number of which have not yet been marked as "resolved".
> >
> > It *will* be accurate to say this, once we've fixed up the bugs a
> > little. The list we agreed previously was:
> >
> > QPID-9, QPID-43, QPID-107, QPID-251, QPID-261, QPID-413, QPID-531,
> > QPID-543, QPID-551, QPID-553, QPID-558, QPID-560, QPID-564, QPID-567,
> > QPID-574, QPID-576, QPID-588, QPID-592, QPID-594, QPID-42
> >
> > > A while back one of the "themes" for the M2.1 release was going to be
> > > interop. How are we doing on that? Do we have out of the box interop
> > > with Rabbit or OpenAMQ (subject to its limited feature set)? Do our
> > > performance tests run unmodified against those brokers?
> >
> > I think the interop stuff is better in M2.1, partly because of the
> > multi-version support. I don't have anything solid to back that up
> > though.
> >
> > - Aidan
>
>
--
Martin Ritchie
Re: M2.1plan
Posted by Arnaud Simon <as...@redhat.com>.
Aidan,
Should we schedule a call for sharing the workload?
Cheers
Arnaud
On Wed, 2008-01-09 at 23:29 +0000, Aidan Skinner wrote:
> On Jan 9, 2008 10:47 PM, Robert Greig <ro...@gmail.com> wrote:
>
> > Is it accurate to say that all issues with the "fix for" field set to
> > M2.1 must be done for this release or is the plan just to see what is
> > done on 22 Feb? I see from Jira that there are 65 issues, a good
> > number of which have not yet been marked as "resolved".
>
> It *will* be accurate to say this, once we've fixed up the bugs a
> little. The list we agreed previously was:
>
> QPID-9, QPID-43, QPID-107, QPID-251, QPID-261, QPID-413, QPID-531,
> QPID-543, QPID-551, QPID-553, QPID-558, QPID-560, QPID-564, QPID-567,
> QPID-574, QPID-576, QPID-588, QPID-592, QPID-594, QPID-42
>
> > A while back one of the "themes" for the M2.1 release was going to be
> > interop. How are we doing on that? Do we have out of the box interop
> > with Rabbit or OpenAMQ (subject to its limited feature set)? Do our
> > performance tests run unmodified against those brokers?
>
> I think the interop stuff is better in M2.1, partly because of the
> multi-version support. I don't have anything solid to back that up
> though.
>
> - Aidan
Re: M2.1plan
Posted by Aidan Skinner <ai...@apache.org>.
On Jan 9, 2008 10:47 PM, Robert Greig <ro...@gmail.com> wrote:
> Is it accurate to say that all issues with the "fix for" field set to
> M2.1 must be done for this release or is the plan just to see what is
> done on 22 Feb? I see from Jira that there are 65 issues, a good
> number of which have not yet been marked as "resolved".
It *will* be accurate to say this, once we've fixed up the bugs a
little. The list we agreed previously was:
QPID-9, QPID-43, QPID-107, QPID-251, QPID-261, QPID-413, QPID-531,
QPID-543, QPID-551, QPID-553, QPID-558, QPID-560, QPID-564, QPID-567,
QPID-574, QPID-576, QPID-588, QPID-592, QPID-594, QPID-42
> A while back one of the "themes" for the M2.1 release was going to be
> interop. How are we doing on that? Do we have out of the box interop
> with Rabbit or OpenAMQ (subject to its limited feature set)? Do our
> performance tests run unmodified against those brokers?
I think the interop stuff is better in M2.1, partly because of the
multi-version support. I don't have anything solid to back that up
though.
- Aidan
--
aim/y!:aidans42 g:aidan.skinner@gmail.com
http://aidan.skinner.me.uk/
"When the going gets weird, the weird turn pro."
-- Hunter S. Thompson
Re: M2.1plan
Posted by Carl Trieloff <cc...@redhat.com>.
missed the 'k' on the 80.. both 80k :-)
Carl Trieloff wrote:
>
> ack, there are good cases to batch - but just need to comp that same
> thing. i.e.
> Rabbit 80k/sec on 16 CPU at 4k
> Qpid 80/sec on 2 CPU at 4k
>
> so direct comp (1.2M batched, qpid uses 8x less CPU for the same 1.2M
> statement)
> Carl.
>
> Rupert Smith wrote:
>> Thanks for that Carl. I suspected the same thing.
>>
>> Batching multiple application level messages into one transport level
>> message, seems like a valid strategy for small messages which are all
>> going to the same destination, where higher than normal throughput is
>> required. Those unqualified numbers kind of give the impression that
>> you could set up a selector, or topic matching, or series of
>> different queues on a 1.3M message stream to filter out just a subset
>> of of events that you are interested in (which sounds like the sort
>> of thing someone would actually want to do with that event stream).
>> With batching you can no longer route each individual application
>> level event individually.
>>
>> Also they don't claim that Rabbit does 1.3M per second, but try and
>> make the reader falsely infer that from the claim that they do make.
>>
>> Rupert
>>
>> On 10/01/2008, * Carl Trieloff* <cctrieloff@redhat.com
>> <ma...@redhat.com>> wrote:
>>
>>
>> > I especially wanted to run perf tests against Rabbit after
>> reading
>> > their 1.3M msgs/sec claims.
>> >
>> >
>>
>> Yea, that is why I played with it ... the number they put out are
>> bogus.
>> From their list " /each datagram contained 16 OPRA messages, and was
>> sent as one 256 byte AMQP message.... Ingress of 80,000 AMQP
>> messages
>> per second"
>>
>> /That is only not very impressive given they used a 16 core box to
>> do it
>> and 4k messages. I did some comp runs when the numbers first came
>> out
>> and Rabbit is a hog compared to qpid, and a lot slower for the
>> same CPU.
>> From my test 16x slower at equivalent CPU. If you used batched
>> numbers
>> it is easier to fill the pipe the larger the message. I would
>> ignore the
>> 1.2M number... it is more like the best rate for Rabbit on a 16 way
>> state of the art box is 80k msg/sec with no ack on publish at 4k.
>>
>> For comp, I have seen trunk break 250k msg/sec using full ack on
>> publish
>> using <4 cores.
>>
>> Once I got that far I stopped investing time into issues that
>> came up.
>> Carl.
>>
>>
>
>
Re: M2.1plan
Posted by Carl Trieloff <cc...@redhat.com>.
ack, there are good cases to batch - but just need to comp that same
thing. i.e.
Rabbit 80k/sec on 16 CPU at 4k
Qpid 80/sec on 2 CPU at 4k
so direct comp (1.2M batched, qpid uses 8x less CPU for the same 1.2M
statement)
Carl.
Rupert Smith wrote:
> Thanks for that Carl. I suspected the same thing.
>
> Batching multiple application level messages into one transport level
> message, seems like a valid strategy for small messages which are all
> going to the same destination, where higher than normal throughput is
> required. Those unqualified numbers kind of give the impression that
> you could set up a selector, or topic matching, or series of different
> queues on a 1.3M message stream to filter out just a subset of of
> events that you are interested in (which sounds like the sort of thing
> someone would actually want to do with that event stream). With
> batching you can no longer route each individual application level
> event individually.
>
> Also they don't claim that Rabbit does 1.3M per second, but try and
> make the reader falsely infer that from the claim that they do make.
>
> Rupert
>
> On 10/01/2008, * Carl Trieloff* <cctrieloff@redhat.com
> <ma...@redhat.com>> wrote:
>
>
> > I especially wanted to run perf tests against Rabbit after reading
> > their 1.3M msgs/sec claims.
> >
> >
>
> Yea, that is why I played with it ... the number they put out are
> bogus.
> From their list " /each datagram contained 16 OPRA messages, and was
> sent as one 256 byte AMQP message.... Ingress of 80,000 AMQP messages
> per second"
>
> /That is only not very impressive given they used a 16 core box to
> do it
> and 4k messages. I did some comp runs when the numbers first came out
> and Rabbit is a hog compared to qpid, and a lot slower for the
> same CPU.
> From my test 16x slower at equivalent CPU. If you used batched numbers
> it is easier to fill the pipe the larger the message. I would
> ignore the
> 1.2M number... it is more like the best rate for Rabbit on a 16 way
> state of the art box is 80k msg/sec with no ack on publish at 4k.
>
> For comp, I have seen trunk break 250k msg/sec using full ack on
> publish
> using <4 cores.
>
> Once I got that far I stopped investing time into issues that came up.
> Carl.
>
>
Re: M2.1plan
Posted by Rupert Smith <ru...@googlemail.com>.
Thanks for that Carl. I suspected the same thing.
Batching multiple application level messages into one transport level
message, seems like a valid strategy for small messages which are all going
to the same destination, where higher than normal throughput is required.
Those unqualified numbers kind of give the impression that you could set up
a selector, or topic matching, or series of different queues on a
1.3Mmessage stream to filter out just a subset of of events that you
are
interested in (which sounds like the sort of thing someone would actually
want to do with that event stream). With batching you can no longer route
each individual application level event individually.
Also they don't claim that Rabbit does 1.3M per second, but try and make the
reader falsely infer that from the claim that they do make.
Rupert
On 10/01/2008, Carl Trieloff <cc...@redhat.com> wrote:
>
>
> > I especially wanted to run perf tests against Rabbit after reading
> > their 1.3M msgs/sec claims.
> >
> >
>
> Yea, that is why I played with it ... the number they put out are bogus.
> From their list " /each datagram contained 16 OPRA messages, and was
> sent as one 256 byte AMQP message.... Ingress of 80,000 AMQP messages
> per second"
>
> /That is only not very impressive given they used a 16 core box to do it
> and 4k messages. I did some comp runs when the numbers first came out
> and Rabbit is a hog compared to qpid, and a lot slower for the same CPU.
> From my test 16x slower at equivalent CPU. If you used batched numbers
> it is easier to fill the pipe the larger the message. I would ignore the
> 1.2M number... it is more like the best rate for Rabbit on a 16 way
> state of the art box is 80k msg/sec with no ack on publish at 4k.
>
> For comp, I have seen trunk break 250k msg/sec using full ack on publish
> using <4 cores.
>
> Once I got that far I stopped investing time into issues that came up.
> Carl.
>
Re: M2.1plan
Posted by Carl Trieloff <cc...@redhat.com>.
I am fine getting more things that are in the spec to interop, but I am
against re-inventing stuff taken care of in latter versions of the spec
and investing in stuff like RBAC interop etc between projects is a waste
of time on earlier versions of the spec or classes that have been
removed in 0-10 like access for example as that will just be an exercise
in throw away code. Being able to connect and exchange messages between
impls is good, however this does require other impl's to also fix issues.
In terms of that I think we agree.
Carl.
Martin Ritchie wrote:
> On 11/01/2008, Rajith Attapattu <ra...@gmail.com> wrote:
>
>> On Jan 10, 2008 6:45 PM, Martin Ritchie <ri...@apache.org> wrote:
>>
>>
>>> On 10/01/2008, Carl Trieloff <cc...@redhat.com> wrote:
>>>
>>>> Michael Arnoldus wrote:
>>>>
>>>>> From my point of view interop is the highest priority - why would I
>>>>> choose AMQP if it's not AMQP?
>>>>>
>>>>>
>>>> yes, that is the point. but AMQP is still under development so with each
>>>> release we should be able to get better interop as the specification
>>>> gets more complete. so 0-10 makes it possible to not have hacks for JMS
>>>> needed in earlier versions. 0-11 should fill in security etc. So we
>>>> should get basic interop, but there is not much point in trying to deal
>>>> with all the gray areas in a previous versions of the spec, but rather
>>>> go to the latest where the issues have been debated out and specified.
>>>>
>>>> thanks for the comments.
>>>> Carl.
>>>>
>>> As I see it 0-9 is a suitable starting point for interop. as it has
>>> all the features required to support JMS.
>>>
>> Not really, selectors are still an issue and there are few other issues as
>> well.
>>
>
> But this wouldn't break interop. The non Qpid-Java broker would most
> likely ignore the arguments but connection would still occur. The
> client would just get more messages that expected. Which I would say
> is way better than the current situation of not having any
> functionality at all. A few other issues? I remember taking the Java
> client to to 100% compliance and I don't remember any other framing
> changes. True the Qpid java client uses more extensions to the
> protocol but for many simple JMS use cases it can work with a spec
> compliant 0-9 broker. Perhaps it is too late for me to remember the
> other issues.
>
>
>>> As the JMS over AMQP guide hasn't been released there is still issues with
>>> JMS interop over AMQP
>>> but that is a different story.
>>>
>> This is scoped for 0-11.
>>
>
> And this will address the full selector & queue browsing situation.
>
> But for now having all the brokers and clients supporting 09 (non-wip)
> seems like a great way of pushing acceptance of AMQP. People need to
> start seeing the benefit of AMQP and if they can't swap brokers or
> inter mix clients from one project with another then they won't _get_
> the benefit that AMQP has to offer.
>
>
>>> --
>>> Martin Ritchie
>>>
>>>
>>
>> --
>> Regards,
>>
>> Rajith Attapattu
>> Red Hat
>> blog: http://rajith.2rlabs.com/
>>
>>
>
>
>
Re: M2.1plan
Posted by Martin Ritchie <ri...@apache.org>.
On 11/01/2008, Rajith Attapattu <ra...@gmail.com> wrote:
> On Jan 10, 2008 6:45 PM, Martin Ritchie <ri...@apache.org> wrote:
>
> > On 10/01/2008, Carl Trieloff <cc...@redhat.com> wrote:
> > > Michael Arnoldus wrote:
> > > > From my point of view interop is the highest priority - why would I
> > > > choose AMQP if it's not AMQP?
> > > >
> > >
> > > yes, that is the point. but AMQP is still under development so with each
> > > release we should be able to get better interop as the specification
> > > gets more complete. so 0-10 makes it possible to not have hacks for JMS
> > > needed in earlier versions. 0-11 should fill in security etc. So we
> > > should get basic interop, but there is not much point in trying to deal
> > > with all the gray areas in a previous versions of the spec, but rather
> > > go to the latest where the issues have been debated out and specified.
> > >
> > > thanks for the comments.
> > > Carl.
> >
> > As I see it 0-9 is a suitable starting point for interop. as it has
> > all the features required to support JMS.
>
> Not really, selectors are still an issue and there are few other issues as
> well.
But this wouldn't break interop. The non Qpid-Java broker would most
likely ignore the arguments but connection would still occur. The
client would just get more messages that expected. Which I would say
is way better than the current situation of not having any
functionality at all. A few other issues? I remember taking the Java
client to to 100% compliance and I don't remember any other framing
changes. True the Qpid java client uses more extensions to the
protocol but for many simple JMS use cases it can work with a spec
compliant 0-9 broker. Perhaps it is too late for me to remember the
other issues.
> > As the JMS over AMQP guide hasn't been released there is still issues with
> > JMS interop over AMQP
> > but that is a different story.
>
> This is scoped for 0-11.
And this will address the full selector & queue browsing situation.
But for now having all the brokers and clients supporting 09 (non-wip)
seems like a great way of pushing acceptance of AMQP. People need to
start seeing the benefit of AMQP and if they can't swap brokers or
inter mix clients from one project with another then they won't _get_
the benefit that AMQP has to offer.
> >
> >
> > --
> > Martin Ritchie
> >
>
>
>
> --
> Regards,
>
> Rajith Attapattu
> Red Hat
> blog: http://rajith.2rlabs.com/
>
--
Martin Ritchie
Re: M2.1plan
Posted by Rajith Attapattu <ra...@gmail.com>.
On Jan 10, 2008 6:45 PM, Martin Ritchie <ri...@apache.org> wrote:
> On 10/01/2008, Carl Trieloff <cc...@redhat.com> wrote:
> > Michael Arnoldus wrote:
> > > From my point of view interop is the highest priority - why would I
> > > choose AMQP if it's not AMQP?
> > >
> >
> > yes, that is the point. but AMQP is still under development so with each
> > release we should be able to get better interop as the specification
> > gets more complete. so 0-10 makes it possible to not have hacks for JMS
> > needed in earlier versions. 0-11 should fill in security etc. So we
> > should get basic interop, but there is not much point in trying to deal
> > with all the gray areas in a previous versions of the spec, but rather
> > go to the latest where the issues have been debated out and specified.
> >
> > thanks for the comments.
> > Carl.
>
> As I see it 0-9 is a suitable starting point for interop. as it has
> all the features required to support JMS.
Not really, selectors are still an issue and there are few other issues as
well.
> As the JMS over AMQP guide hasn't been released there is still issues with
> JMS interop over AMQP
> but that is a different story.
This is scoped for 0-11.
>
>
> --
> Martin Ritchie
>
--
Regards,
Rajith Attapattu
Red Hat
blog: http://rajith.2rlabs.com/
Re: M2.1plan
Posted by Martin Ritchie <ri...@apache.org>.
On 10/01/2008, Carl Trieloff <cc...@redhat.com> wrote:
> Michael Arnoldus wrote:
> > From my point of view interop is the highest priority - why would I
> > choose AMQP if it's not AMQP?
> >
>
> yes, that is the point. but AMQP is still under development so with each
> release we should be able to get better interop as the specification
> gets more complete. so 0-10 makes it possible to not have hacks for JMS
> needed in earlier versions. 0-11 should fill in security etc. So we
> should get basic interop, but there is not much point in trying to deal
> with all the gray areas in a previous versions of the spec, but rather
> go to the latest where the issues have been debated out and specified.
>
> thanks for the comments.
> Carl.
As I see it 0-9 is a suitable starting point for interop. as it has
all the features required to support JMS. As the JMS over AMQP guide
hasn't been released there is still issues with JMS interop over AMQP
but that is a different story.
--
Martin Ritchie
Re: M2.1plan
Posted by Carl Trieloff <cc...@redhat.com>.
Michael Arnoldus wrote:
> From my point of view interop is the highest priority - why would I
> choose AMQP if it's not AMQP?
>
yes, that is the point. but AMQP is still under development so with each
release we should be able to get better interop as the specification
gets more complete. so 0-10 makes it possible to not have hacks for JMS
needed in earlier versions. 0-11 should fill in security etc. So we
should get basic interop, but there is not much point in trying to deal
with all the gray areas in a previous versions of the spec, but rather
go to the latest where the issues have been debated out and specified.
thanks for the comments.
Carl.
Re: M2.1plan
Posted by Alexis Richardson <al...@cohesiveft.com>.
Rupert
On Jan 11, 2008 3:23 PM, Rupert Smith <ru...@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 <al...@cohesiveft.com> wrote:
> > Rajith
> >
> > On Jan 11, 2008 2:52 PM, Rajith Attapattu <ra...@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 <ch...@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)
Re: M2.1plan
Posted by Rupert Smith <ru...@googlemail.com>.
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 <al...@cohesiveft.com> wrote:
>
> Rajith
>
> On Jan 11, 2008 2:52 PM, Rajith Attapattu <ra...@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 <ro...@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 <ch...@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)
>
Re: M2.1plan
Posted by Alexis Richardson <al...@cohesiveft.com>.
Rajith
On Jan 11, 2008 2:52 PM, Rajith Attapattu <ra...@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 <ro...@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 <ch...@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)
Re: M2.1plan
Posted by Rajith Attapattu <ra...@gmail.com>.
Michael,
Thanks for the feedback. I have a few questions/comments inline.
On Jan 11, 2008 5:12 AM, Michael Arnoldus <ch...@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.
>
Is this the only issue that prevented you guys from using Qpid?
>
> >
> >
> >> 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.
I know you are pressed for time, but if you can elaborate a bit more on
these areas it will help us improve.
What are your thoughts on ease of installation and use?
Dare I ask you about documentation?
Also some feedback on scalability and stability would help us a lot.
> 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/
Re: M2.1plan
Posted by Rajith Attapattu <ra...@gmail.com>.
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?
But as Carl points out do we have time and resources to do this? On other
hand if you think you can do it without much effort then by all means you
can do that for M2.1.
Regards,
Rajith
On Jan 11, 2008 9:37 AM, Robert Godfrey <ro...@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 <ch...@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/
Re: M2.1plan
Posted by Robert Godfrey <ro...@gmail.com>.
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 <ch...@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
>
>
>
Re: M2.1plan
Posted by Michael Arnoldus <ch...@wiinz.com>.
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
Re: M2.1plan
Posted by Robert Greig <ro...@gmail.com>.
On 10/01/2008, Robert Godfrey <ro...@gmail.com> wrote:
> While trying to claim the title of the "fastest AMQP broker in the
> West" may be appealing to our egos; we mustn't lose sight of the fact
> that providing a reliable, well documented, and well supported
> solution at fairly low message volumes is probably higher on most
> peoples wish list. Certainly none of the deployments of Qpid that I
> have been involved in have stretched in any way its performance.
I think it is true that people don't generally need what someone we
know calls "extreme performance" but I think message brokers are a bit
like washing machines. People *say* they want outstanding performance
and scalability even if in reality when they get it home they just use
the same two programmes all the time.
RG
Re: M2.1plan
Posted by Rajith Attapattu <ra...@gmail.com>.
On Jan 10, 2008 11:19 AM, Robert Godfrey <ro...@gmail.com> wrote:
> While trying to claim the title of the "fastest AMQP broker in the
> West" may be appealing to our egos; we mustn't lose sight of the fact
> that providing a reliable, well documented, and well supported
> solution at fairly low message volumes is probably higher on most
> peoples wish list. Certainly none of the deployments of Qpid that I
> have been involved in have stretched in any way its performance.
>
> Scalability, and resiliance under load, however, are things that we
> should definitely look at,
That is a very good point. No point having a broker that spews millions of
msg per sec and then die in a couple of hours or is unpredictable under
different situations.
In a production environment, what customers are looking is for "predictable
behaviour", not nessacerily the fastest.
If somebody throws our broker into production and then have to cross their
fingers then we will soon be forgotten.
We need to ensure that our broker has consistent behaviour under increased
loads, scalable and reliable.
Rajith
>
> Rob
>
> On 10/01/2008, Robert Greig <ro...@gmail.com> wrote:
> > Hi Michael,
> >
> > > I agree. I am a an AMQP user currently using Rabbit, since the thing
> > > just works, it complies with AMPQ 0.8 and we get very nice support.
> > > From my point of view interop is the highest priority - why would I
> > > choose AMQP if it's not AMQP?
> >
> > 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.
> >
> > > 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.
> >
> > RG
> >
>
--
Regards,
Rajith Attapattu
Red Hat
blog: http://rajith.2rlabs.com/
Re: M2.1plan
Posted by Robert Godfrey <ro...@gmail.com>.
While trying to claim the title of the "fastest AMQP broker in the
West" may be appealing to our egos; we mustn't lose sight of the fact
that providing a reliable, well documented, and well supported
solution at fairly low message volumes is probably higher on most
peoples wish list. Certainly none of the deployments of Qpid that I
have been involved in have stretched in any way its performance.
Scalability, and resiliance under load, however, are things that we
should definitely look at,
Rob
On 10/01/2008, Robert Greig <ro...@gmail.com> wrote:
> Hi Michael,
>
> > I agree. I am a an AMQP user currently using Rabbit, since the thing
> > just works, it complies with AMPQ 0.8 and we get very nice support.
> > From my point of view interop is the highest priority - why would I
> > choose AMQP if it's not AMQP?
>
> 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.
>
> > 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.
>
> RG
>
Re: M2.1plan
Posted by Robert Greig <ro...@gmail.com>.
Hi Michael,
> I agree. I am a an AMQP user currently using Rabbit, since the thing
> just works, it complies with AMPQ 0.8 and we get very nice support.
> From my point of view interop is the highest priority - why would I
> choose AMQP if it's not AMQP?
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.
> 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.
RG
Re: M2.1plan
Posted by Michael Arnoldus <ch...@wiinz.com>.
I agree. I am a an AMQP user currently using Rabbit, since the thing
just works, it complies with AMPQ 0.8 and we get very nice support.
From my point of view interop is the highest priority - why would I
choose AMQP if it's not AMQP?
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.
Keep the good work going :-)
Kind regards,
Michael Aroldus
On Jan 10, 2008, at 16:38 , Robert Greig wrote:
> On 10/01/2008, Carl Trieloff <cc...@redhat.com> wrote:
>
>> /That is only not very impressive given they used a 16 core box to
>> do it
>> and 4k messages. I did some comp runs when the numbers first came out
>> and Rabbit is a hog compared to qpid, and a lot slower for the same
>> CPU.
>
> Yes I ran our topic test against it and it used lots of CPU compared
> with Qpid and ground to a halt with about 4 consumers.
>
> Enabling all prospective users to run tests easily against any broker
> would help users make choices between different implementations. This
> was why I was so keen to have interop.
>
> RG
Re: M2.1plan
Posted by Robert Greig <ro...@gmail.com>.
On 10/01/2008, Carl Trieloff <cc...@redhat.com> wrote:
> /That is only not very impressive given they used a 16 core box to do it
> and 4k messages. I did some comp runs when the numbers first came out
> and Rabbit is a hog compared to qpid, and a lot slower for the same CPU.
Yes I ran our topic test against it and it used lots of CPU compared
with Qpid and ground to a halt with about 4 consumers.
Enabling all prospective users to run tests easily against any broker
would help users make choices between different implementations. This
was why I was so keen to have interop.
RG
Re: M2.1plan
Posted by Carl Trieloff <cc...@redhat.com>.
> I especially wanted to run perf tests against Rabbit after reading
> their 1.3M msgs/sec claims.
>
>
Yea, that is why I played with it ... the number they put out are bogus.
>From their list " /each datagram contained 16 OPRA messages, and was
sent as one 256 byte AMQP message.... Ingress of 80,000 AMQP messages
per second"
/That is only not very impressive given they used a 16 core box to do it
and 4k messages. I did some comp runs when the numbers first came out
and Rabbit is a hog compared to qpid, and a lot slower for the same CPU.
>From my test 16x slower at equivalent CPU. If you used batched numbers
it is easier to fill the pipe the larger the message. I would ignore the
1.2M number... it is more like the best rate for Rabbit on a 16 way
state of the art box is 80k msg/sec with no ack on publish at 4k.
For comp, I have seen trunk break 250k msg/sec using full ack on publish
using <4 cores.
Once I got that far I stopped investing time into issues that came up.
Carl.
Re: M2.1plan
Posted by Rupert Smith <ru...@googlemail.com>.
Yes, I wanted to compare with OpenAMQ and Rabbit. I think the 0.9 support
added by Robert Godfrey is aimed at getting the client to talk to OpenAMQ?
Could not get interop with Rabbit to work, despite making a few changes to
the Java. I especially wanted to run perf tests against Rabbit after reading
their 1.3M msgs/sec claims.
Issues that I know of with Rabbit are:
Qpids lack of support for access tickets but Rabbit website says they use a
Qpid compatible mode for that by default.
Extra arguments on consume method. I removed those from the Java but it
still would not work.
Rupert
On 10/01/2008, Robert Greig <ro...@gmail.com> wrote:
>
> On 09/01/2008, Carl Trieloff <cc...@redhat.com> wrote:
> >
> > > Do we have out of the box interop
> > > with Rabbit or OpenAMQ (subject to its limited feature set)? Do our
> > > performance tests run unmodified against those brokers?
> > >
> > >
> > no, lot of our test use JMS and both Rabbit and OpenAMQ are not rich
> > enough to support that, can
> > only get basics going before I gave up last time tried. Not even all the
> > python test passed on them
> > last I looked.
>
> OK they don't support full JMS but I should have thought that a lot
> will work. We should certainly be able to do, for example, some
> pub/sub tests.
>
> Did you try with M2.1 Carl?
>
> Rupert - do you have a feel for how much of your performance test
> suite will run? It would be interesting to get comparative numbers
> across AMQP implementations.
>
> RG
>
Re: M2.1plan
Posted by Gordon Sim <gs...@redhat.com>.
Robert Godfrey wrote:
> On a separate note... what change do you think there is of getting 0-9
> *and* 0-8 support in the C++ client / broker for M2.1 ?
I think it would only happen if there was a clear and specific need from
users, to be honest.
Re: M2.1plan
Posted by Robert Godfrey <ro...@gmail.com>.
> When anyone has the time, we could probably use the contents of the
> client properties map. It comes after the negotiation of the protocol
> version so would probably cause a wrinkle in the multi-version support
> mechanism, but would be doable if needed I think.
>
Yes - this was what I was planning to use - just hadn;t had the time
to look into the C++ / Python / Ruby clients to see what they send so
that I can differentiate them from an OpenAMQ or Rabbit client.
On a separate note... what change do you think there is of getting 0-9
*and* 0-8 support in the C++ client / broker for M2.1 ? I know you
guys are mostly concentrating on the 0-10pre stuff on trunk...
-- Rob
Re: M2.1plan
Posted by Gordon Sim <gs...@redhat.com>.
Robert Godfrey wrote:
> What I wanted to do for the (Java) broker was to find some way of
> differentiating between 0-8 clients which speak "pure" 0-8 (without
> the arguments field) and those that speak with the arguments field.
> Since there are already many clients "in the wild" which we would want
> to be able to connect succesfully to our broker it needs to be based
> off of information already present (ie we can't go change the client
> to use a different version number or something).
>
> Since I haven't yet had the time, the broker on M2.1 speaks "pure" 0-9
> but "impure" 0-8
When anyone has the time, we could probably use the contents of the
client properties map. It comes after the negotiation of the protocol
version so would probably cause a wrinkle in the multi-version support
mechanism, but would be doable if needed I think.
Re: M2.1plan
Posted by Gordon Sim <gs...@redhat.com>.
Rupert Smith wrote:
> So is the plan to move JMS support onto pure 0-9, then revert 0-8 support to
> be pure too for interop with other 0-8 brokers? Or will JMS continue to run
> over impure 0-8, with purity restored through the STRICT_AMQP flag?
I haven't kept up with the M2.1 branch and the multi-version support,
but previously the STRICT_AMQP flag has not itself restored 'purity', it
has merely prevented some additional methods etc being used. In
particular it never restored the correct definition of the basic.consume
method.
Note that the modifications to the specification file mean that the c++
client and broker are also 'impure'. If we revert to a clean spec file
the c++ code will need minor adjustments before it will compile.
Re: M2.1plan
Posted by Rupert Smith <ru...@googlemail.com>.
Also on the subject of interop. The interop spec has been implemented for a
number of test cases, and I will soon be adding test cases for all field
table types too. Currently it passes on C++, Java and .Net with Java broker
for M2.
There were also requirements in that spec for automated testing. In outline,
this meant having builds output a broker executable and a test client
executable to standardized locations, with start/stop scripts. There would
then be a master test scripts that launch all the possible combinations of
brokers/test clients in sequence based on what is available at the end of a
build and interop test them all and collate the results in a format that
automated build systems understand (XML output from JUnit). This has not
been attempted yet because so far I have only looked at client interop over
the Java broker and am launching the broker and test clients by hand every
time.
In addition to Rabbit and OpenAMQ I would be interested to run the perftests
and interop tests through the Qpid C++ broker.
Rupert
On 10/01/2008, Rupert Smith <ru...@googlemail.com> wrote:
>
> So is the plan to move JMS support onto pure 0-9, then revert 0-8 support
> to be pure too for interop with other 0-8 brokers? Or will JMS continue to
> run over impure 0-8, with purity restored through the STRICT_AMQP flag?
>
> Rupert
>
> On 10/01/2008, Robert Godfrey <ro...@gmail.com> wrote:
> >
> > Presume that all the Qpid M2 artifacts do (since they interoperate)
> >
> > -- Rob
> >
> > On 10/01/2008, Robert Greig <ro...@gmail.com> wrote:
> > > On 10/01/2008, Robert Godfrey < rob.j.godfrey@gmail.com> wrote:
> > >
> > > > Since I haven't yet had the time, the broker on M2.1 speaks "pure"
> > 0-9
> > > > but "impure" 0-8
> > >
> > > How many speak "impure" 0-8? Is that just Qpid java?
> > >
> > > RG
> > >
> >
>
>
Re: M2.1plan
Posted by Robert Godfrey <ro...@gmail.com>.
on the M2.1 java codebase, everything defaults to using 0-9... if it
connects to a broker that refuses 0-9 it tries "impure" 0-8...
-- Rob
On 10/01/2008, Rupert Smith <ru...@googlemail.com> wrote:
> So is the plan to move JMS support onto pure 0-9, then revert 0-8 support to
> be pure too for interop with other 0-8 brokers? Or will JMS continue to run
> over impure 0-8, with purity restored through the STRICT_AMQP flag?
>
> Rupert
>
> On 10/01/2008, Robert Godfrey <ro...@gmail.com> wrote:
> >
> > Presume that all the Qpid M2 artifacts do (since they interoperate)
> >
> > -- Rob
> >
> > On 10/01/2008, Robert Greig <ro...@gmail.com> wrote:
> > > On 10/01/2008, Robert Godfrey <ro...@gmail.com> wrote:
> > >
> > > > Since I haven't yet had the time, the broker on M2.1 speaks "pure" 0-9
> > > > but "impure" 0-8
> > >
> > > How many speak "impure" 0-8? Is that just Qpid java?
> > >
> > > RG
> > >
> >
>
Re: M2.1plan
Posted by Rupert Smith <ru...@googlemail.com>.
So is the plan to move JMS support onto pure 0-9, then revert 0-8 support to
be pure too for interop with other 0-8 brokers? Or will JMS continue to run
over impure 0-8, with purity restored through the STRICT_AMQP flag?
Rupert
On 10/01/2008, Robert Godfrey <ro...@gmail.com> wrote:
>
> Presume that all the Qpid M2 artifacts do (since they interoperate)
>
> -- Rob
>
> On 10/01/2008, Robert Greig <ro...@gmail.com> wrote:
> > On 10/01/2008, Robert Godfrey <ro...@gmail.com> wrote:
> >
> > > Since I haven't yet had the time, the broker on M2.1 speaks "pure" 0-9
> > > but "impure" 0-8
> >
> > How many speak "impure" 0-8? Is that just Qpid java?
> >
> > RG
> >
>
Re: M2.1plan
Posted by Robert Godfrey <ro...@gmail.com>.
Presume that all the Qpid M2 artifacts do (since they interoperate)
-- Rob
On 10/01/2008, Robert Greig <ro...@gmail.com> wrote:
> On 10/01/2008, Robert Godfrey <ro...@gmail.com> wrote:
>
> > Since I haven't yet had the time, the broker on M2.1 speaks "pure" 0-9
> > but "impure" 0-8
>
> How many speak "impure" 0-8? Is that just Qpid java?
>
> RG
>
Re: M2.1plan
Posted by Robert Greig <ro...@gmail.com>.
On 10/01/2008, Robert Godfrey <ro...@gmail.com> wrote:
> Since I haven't yet had the time, the broker on M2.1 speaks "pure" 0-9
> but "impure" 0-8
How many speak "impure" 0-8? Is that just Qpid java?
RG
Re: M2.1plan
Posted by Robert Godfrey <ro...@gmail.com>.
What I wanted to do for the (Java) broker was to find some way of
differentiating between 0-8 clients which speak "pure" 0-8 (without
the arguments field) and those that speak with the arguments field.
Since there are already many clients "in the wild" which we would want
to be able to connect succesfully to our broker it needs to be based
off of information already present (ie we can't go change the client
to use a different version number or something).
Since I haven't yet had the time, the broker on M2.1 speaks "pure" 0-9
but "impure" 0-8
-- Rob
On 10/01/2008, Aidan Skinner <ai...@apache.org> wrote:
> On Jan 10, 2008 10:19 AM, Martin Ritchie <ri...@apache.org> wrote:
> > On 10/01/2008, Aidan Skinner <ai...@apache.org> wrote:
>
> > > I think all (but perhaps only most) of our JMS-compliance is in the
> > > client, so from my PoV we should be able to run our stuff against
> > > another broker using our client and have it work. That is, however,
> > > should in the "I would like this to be true" sense rather than the "I
> > > strongly believe this to be fact" sense.
> >
> > There is a fair bit on the broker though and only with a 09 broker
> > will we be able to attempt to use them as 08 doesn't have an arguments
> > field on Basic.Consume which is how we communicate selector and queue
> > browsing functionality.
>
> That's kinda lame, I guess selectors and queue browsing can really
> only be implemented sanely that way in 0-8/0-9 though. :/
>
> - Aidan
>
> --
> aim/y!:aidans42 g:aidan.skinner@gmail.com
> http://aidan.skinner.me.uk/
> "When the going gets weird, the weird turn pro."
> -- Hunter S. Thompson
>
Re: M2.1plan
Posted by Aidan Skinner <ai...@apache.org>.
On Jan 10, 2008 10:19 AM, Martin Ritchie <ri...@apache.org> wrote:
> On 10/01/2008, Aidan Skinner <ai...@apache.org> wrote:
> > I think all (but perhaps only most) of our JMS-compliance is in the
> > client, so from my PoV we should be able to run our stuff against
> > another broker using our client and have it work. That is, however,
> > should in the "I would like this to be true" sense rather than the "I
> > strongly believe this to be fact" sense.
>
> There is a fair bit on the broker though and only with a 09 broker
> will we be able to attempt to use them as 08 doesn't have an arguments
> field on Basic.Consume which is how we communicate selector and queue
> browsing functionality.
That's kinda lame, I guess selectors and queue browsing can really
only be implemented sanely that way in 0-8/0-9 though. :/
- Aidan
--
aim/y!:aidans42 g:aidan.skinner@gmail.com
http://aidan.skinner.me.uk/
"When the going gets weird, the weird turn pro."
-- Hunter S. Thompson
Re: M2.1plan
Posted by Martin Ritchie <ri...@apache.org>.
On 10/01/2008, Aidan Skinner <ai...@apache.org> wrote:
> On Jan 10, 2008 9:25 AM, Robert Greig <ro...@gmail.com> wrote:
>
> > OK they don't support full JMS but I should have thought that a lot
> > will work. We should certainly be able to do, for example, some
> > pub/sub tests.
>
> I think all (but perhaps only most) of our JMS-compliance is in the
> client, so from my PoV we should be able to run our stuff against
> another broker using our client and have it work. That is, however,
> should in the "I would like this to be true" sense rather than the "I
> strongly believe this to be fact" sense.
There is a fair bit on the broker though and only with a 09 broker
will we be able to attempt to use them as 08 doesn't have an arguments
field on Basic.Consume which is how we communicate selector and queue
browsing functionality.
> - Aidan
>
> --
> aim/y!:aidans42 g:aidan.skinner@gmail.com
> http://aidan.skinner.me.uk/
> "When the going gets weird, the weird turn pro."
> -- Hunter S. Thompson
>
--
Martin Ritchie
Re: M2.1plan
Posted by Aidan Skinner <ai...@apache.org>.
On Jan 10, 2008 9:25 AM, Robert Greig <ro...@gmail.com> wrote:
> OK they don't support full JMS but I should have thought that a lot
> will work. We should certainly be able to do, for example, some
> pub/sub tests.
I think all (but perhaps only most) of our JMS-compliance is in the
client, so from my PoV we should be able to run our stuff against
another broker using our client and have it work. That is, however,
should in the "I would like this to be true" sense rather than the "I
strongly believe this to be fact" sense.
- Aidan
--
aim/y!:aidans42 g:aidan.skinner@gmail.com
http://aidan.skinner.me.uk/
"When the going gets weird, the weird turn pro."
-- Hunter S. Thompson
Re: M2.1plan
Posted by Robert Greig <ro...@gmail.com>.
On 09/01/2008, Carl Trieloff <cc...@redhat.com> wrote:
>
> > Do we have out of the box interop
> > with Rabbit or OpenAMQ (subject to its limited feature set)? Do our
> > performance tests run unmodified against those brokers?
> >
> >
> no, lot of our test use JMS and both Rabbit and OpenAMQ are not rich
> enough to support that, can
> only get basics going before I gave up last time tried. Not even all the
> python test passed on them
> last I looked.
OK they don't support full JMS but I should have thought that a lot
will work. We should certainly be able to do, for example, some
pub/sub tests.
Did you try with M2.1 Carl?
Rupert - do you have a feel for how much of your performance test
suite will run? It would be interesting to get comparative numbers
across AMQP implementations.
RG
Re: M2.1plan
Posted by Carl Trieloff <cc...@redhat.com>.
> Do we have out of the box interop
> with Rabbit or OpenAMQ (subject to its limited feature set)? Do our
> performance tests run unmodified against those brokers?
>
>
no, lot of our test use JMS and both Rabbit and OpenAMQ are not rich
enough to support that, can
only get basics going before I gave up last time tried. Not even all the
python test passed on them
last I looked.
Best we can do is aim for the basics I would say until they have more
features, or impl 0-10 when out
Carl.
Re: M2.1plan
Posted by Robert Greig <ro...@gmail.com>.
On 09/01/2008, Aidan Skinner <ai...@apache.org> wrote:
> We talked about finishing the M2.1 release at the F2F and doing
> quaterly releases, so I'm proposing that we aim to get M2.1 out on
> Wednesday 2008-04-02, with a code freeze (ie. important bug fixes
> only, no new features) on that branch from Friday 2008-02-22 so we
> have some time for testing. I'll act as release manager for this now I
> (nearly) have the right bits unless there are objections from other
> volunteers. ;)
Is it accurate to say that all issues with the "fix for" field set to
M2.1 must be done for this release or is the plan just to see what is
done on 22 Feb? I see from Jira that there are 65 issues, a good
number of which have not yet been marked as "resolved".
A while back one of the "themes" for the M2.1 release was going to be
interop. How are we doing on that? Do we have out of the box interop
with Rabbit or OpenAMQ (subject to its limited feature set)? Do our
performance tests run unmodified against those brokers?
RG