| Author |
Message |
|
| Guest |
 Posted: Tue Aug 14, 2007 6:13 am |
 |
|
|
Guest
|
|
| Back to top |
|
| 0x6e6562 |
| Posted: Tue Aug 14, 2007 6:22 am |
|
|
|
User
Joined: 12 Jul 2007
Posts: 250
|
|
| Back to top |
 
|
| Guest |
| Posted: Tue Aug 14, 2007 8:08 am |
|
|
|
Guest
|
On 14/08/07, Ben Hood <0x6e6562@gmail.com (0x6e6562@gmail.com)> wrote:Quote: Max,
> I'm more concerned about Python. I'm aware of QPid's Python code but
> obviously this code is meant to break thinks and not to be simple |
|
|
| Back to top |
|
| Guest |
| Posted: Tue Aug 14, 2007 8:42 am |
|
|
|
Guest
|
"Robert Godfrey" <rob.j.godfrey@gmail.com> writes:
> The AMQP v0-8 Python client should work with any compliant AMQP v0-8
> broker (e.g. RabbitMQ or Qpid) similarly you should be able to choose
> between any 0-8 complaint Java client library (this rather being the
> point of AMQP).
FWIW, we run QPid's Python-client-based 0-8 tests against our RabbitMQ
server as part of our automated tests. Definitely works.
Matthias.
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Tue Aug 14, 2007 12:44 pm |
|
|
|
Guest
|
Hi Max, all,
We like to use the Qpid clients for unit testing and feel strongly
that AMQP needs a standard set of unit tests and a behaviourally
complete TCK. As Rob points out, the Python libs could be a key part
of a unit test suite in the future, but the Working Group will not
look at this issue until after AMQP 0-10 is out (soon).
In the RabbitMQ team, we also distribute some specially written
clients to work with. Our intent is that unless these are marked
'experimental' these are released to the same quality standard as the
RabbitMQ broker. Currently our Java client is not optimised for
performance, for example. Also, we have released experimental code
for AMQP over HTTP. More clients are coming and please let us know
what you want to work on, or see, via this list. Thanks are due to
Ben Hood for his recent Erlang work.
BUT - modulo the spec version, any client should interoperate with any broker.
Max - I have looked at your blog. Please tell us more about what you
want to achieve since then we can help you.
alexis
On 8/14/07, Robert Godfrey <rob.j.godfrey@gmail.com> wrote:
>
>
> On 14/08/07, Ben Hood <0x6e6562@gmail.com> wrote:
> > Max,
> >
> > > I'm more concerned about Python. I'm aware of QPid's Python code but
> > > obviously this code is meant to break thinks and not to be simple and
> > > reliable.
> >
> > In what way is QPid's python lib meant to break things?
>
>
> Speaking for Qpid here  it's certainly not meant to break things -
> although we do use the library to write our cross-platform system test
> cases. I can't really speak to simplicity - the API is certainly closer to
> the AMQP spec than a high level JMS style API... If anyone has suggestions
> for improvement then we would certainly welcome them over on the Qpid
> mailing list.
>
> The AMQP v0-8 Python client should work with any compliant AMQP v0-8 broker
> (e.g. RabbitMQ or Qpid) similarly you should be able to choose between any
> 0-8 complaint Java client library (this rather being the point of AMQP).
>
> -- Rob Godfrey
>
>
>
> > Ben
> >
> > _______________________________________________
> > rabbitmq-discuss mailing list
> > rabbitmq-discuss@lists.rabbitmq.com
> >
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
> >
>
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss@lists.rabbitmq.com
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
>
--
Alexis Richardson
+44 20 7617 7339 (UK)
+44 77 9865 2911 (cell)
+1 650 206 2517 (US)
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Aug 15, 2007 10:35 am |
|
|
|
Guest
|
[probably I was to confident in Nabble (http://www.nabble.com/
RabbitMQ-f25704.html#) to use it to post to this list - seems the
message never got through. So I repost it - please excuse if this
becomes a dupe -md]
Robert Godfrey wrote:
On 14/08/07, Ben Hood <0x6e6562@gmail.com> wrote:
> > I'm more concerned about Python. I'm aware of QPid's Python code
but
> > obviously this code is meant to break thinks and not to be
simple and
> > reliable.
>
> In what way is QPid's python lib meant to break things?
I assume in as many ways as the authors come up with. Isn't that the
purpose of compliance suites? Try all the corner cases until you a)
break something or b) are satisfied that the test subject is fully
compliant. Compare that to a client coded with reliability in mind:
such a client would be carefully crafted to avoid corner cases, be
well documented and well tested.
Then again, perhaps we just have a different understanding of
"breaking things".
Robert Godfrey wrote:
Speaking for Qpid here it's certainly not meant to break things -
although we do use the library to write our cross-platform system
test cases.
I can't really speak to simplicity - the API is certainly closer to
the AMQP spec than a high level JMS style API... If anyone has
suggestions for improvement then we would certainly welcome them over
on the Qpid mailing list.
That said, I now understand that https://svn.apache.org/repos/asf/
incubator/qpid/trunk/qpid/python/qpid is not only meant to be a
testing vehicle but also a stand alone AMQP client library. It also
seems so far to be the only AMQP implementation in Python so it is
way to go for me.
Regards
Maximillian
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Aug 15, 2007 3:19 pm |
|
|
|
Guest
|
Max
I was hoping that was what you meant by 'break'
It would be great if you could try out the Python clients with
RabbitMQ and let the list know how you get on. As I have mentioned
previously we are very committed to interop since it is both
technically and commercially important to our users. We want RabbitMQ
to work really well with any AMQP client.
alexis
On 8/15/07, Maximillian Dornseif <md@hudora.de> wrote:
> [probably I was to confident in Nabble (http://www.nabble.com/
> RabbitMQ-f25704.html#) to use it to post to this list - seems the
> message never got through. So I repost it - please excuse if this
> becomes a dupe -md]
>
> Robert Godfrey wrote:
> On 14/08/07, Ben Hood <0x6e6562@gmail.com> wrote:
> > > I'm more concerned about Python. I'm aware of QPid's Python code
> but
> > > obviously this code is meant to break thinks and not to be
> simple and
> > > reliable.
> >
> > In what way is QPid's python lib meant to break things?
> I assume in as many ways as the authors come up with. Isn't that the
> purpose of compliance suites? Try all the corner cases until you a)
> break something or b) are satisfied that the test subject is fully
> compliant. Compare that to a client coded with reliability in mind:
> such a client would be carefully crafted to avoid corner cases, be
> well documented and well tested.
>
> Then again, perhaps we just have a different understanding of
> "breaking things".
>
> Robert Godfrey wrote:
> Speaking for Qpid here it's certainly not meant to break things -
> although we do use the library to write our cross-platform system
> test cases.
>
> I can't really speak to simplicity - the API is certainly closer to
> the AMQP spec than a high level JMS style API... If anyone has
> suggestions for improvement then we would certainly welcome them over
> on the Qpid mailing list.
> That said, I now understand that https://svn.apache.org/repos/asf/
> incubator/qpid/trunk/qpid/python/qpid is not only meant to be a
> testing vehicle but also a stand alone AMQP client library. It also
> seems so far to be the only AMQP implementation in Python so it is
> way to go for me.
>
> Regards
>
> Maximillian
>
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss@lists.rabbitmq.com
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
--
Alexis Richardson
+44 20 7617 7339 (UK)
+44 77 9865 2911 (cell)
+1 650 206 2517 (US)
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Thu Aug 23, 2007 5:35 pm |
|
|
|
Guest
|
Alexis Richardson wrote:
> BUT - modulo the spec version, any client should interoperate with any broker.
I'm not sure if it is the differences in spec version or just
incompletely or differently implemented servers but my limited
experience has not borne this out. I was working on a tcl client and
ran into a number of small but annoying differences in how rabbitmq and
OpenAMQ deal with things. For example, rabbitmq requires an
access.request call before accessing anything while openamq doesn't
implement access.request at all and gives you a channel error if you
even make the call. On the side of rabbitmq doing things wrong, the
authentication is completely screwy - the server response says that it
only supports PLAIN authentication but the server only implements AMQPLAIN.
Maybe this just points out a need for multiple independent clients to
test against; particularly in the case of the authentication rabbitmq
seems to be making specific allowances for qpid even tho it appears qpid
is not following the spec exactly.
-J
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Thu Aug 23, 2007 5:38 pm |
|
|
|
Guest
|
Jeff
We want to fix this. Do you have any other examples of mismatch
between OpenAMQ and RabbitMQ?
I think we've managed to nail down the ones for Qpid -- Matthias any comments?
alexis
On 8/23/07, Jeff Rogers <dvrsn@diphi.com> wrote:
> Alexis Richardson wrote:
>
> > BUT - modulo the spec version, any client should interoperate with any broker.
>
> I'm not sure if it is the differences in spec version or just
> incompletely or differently implemented servers but my limited
> experience has not borne this out. I was working on a tcl client and
> ran into a number of small but annoying differences in how rabbitmq and
> OpenAMQ deal with things. For example, rabbitmq requires an
> access.request call before accessing anything while openamq doesn't
> implement access.request at all and gives you a channel error if you
> even make the call. On the side of rabbitmq doing things wrong, the
> authentication is completely screwy - the server response says that it
> only supports PLAIN authentication but the server only implements AMQPLAIN.
>
> Maybe this just points out a need for multiple independent clients to
> test against; particularly in the case of the authentication rabbitmq
> seems to be making specific allowances for qpid even tho it appears qpid
> is not following the spec exactly.
>
> -J
>
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss@lists.rabbitmq.com
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
--
Alexis Richardson
+44 20 7617 7339 (UK)
+44 77 9865 2911 (cell)
+1 650 206 2517 (US)
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Thu Aug 23, 2007 6:08 pm |
|
|
|
Guest
|
Alexis Richardson wrote:
> Jeff
>
> We want to fix this. Do you have any other examples of mismatch
> between OpenAMQ and RabbitMQ?
I don't recall any others off the top of my head. I think OpemAMQ
doesn't implement persistence across broker restarts but that is a
design decision and doesn't affect what clients need to do.
For the client at least, most of the differences between 8.0 (0.8 has
the major/minor version swapped in the xml file) and 0.9 are handled by
just swapping the automatically generated framing definitions file.
-J
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Thu Aug 23, 2007 6:09 pm |
|
|
|
Guest
|
Alexis Richardson wrote:
> We want to fix this. Do you have any other examples of mismatch
> between OpenAMQ and RabbitMQ?
I thought OpenAMQ implements 0-9.
> I think we've managed to nail down the ones for Qpid -- Matthias any comments?
Interop with the Java client and server of Qpid's M1 release is working
now. It required a few tweaks, which will be in the next RabbitMQ release.
>> For example, rabbitmq requires an
>> access.request call before accessing anything while openamq doesn't
>> implement access.request at all and gives you a channel error if you
>> even make the call.
Looks like OpenAMQ behaves the same as Qpid in this regard, so the hacks
we put in place to work with the latter should also work for OpenAMQ.
>> On the side of rabbitmq doing things wrong, the
>> authentication is completely screwy - the server response says that
>> it only supports PLAIN authentication but the server only implements
>> AMQPLAIN.
>> [...]
>> particularly in the case of the authentication rabbitmq
>> seems to be making specific allowances for qpid even tho it appears
>> qpid is not following the spec exactly.
We have hacked the PLAIN authentication to match Qpids. Our AMQPLAIN
authentication is what the spec defines as PLAIN authentication.
Is OpenAMQ doing PLAIN authentication in conformance with the spec?
If so, the only way I can think of addressing the discrepancy at our end
is to check what client is trying to connect to the RabbitMQ server and
make PLAIN auth behave accordingly. Same in our client code. That's
rather gross and brittle though.
Does anybody know how things are looking on the OpenAMQ <-> Qpid interop
front?
matthias.
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Thu Aug 23, 2007 6:57 pm |
|
|
|
Guest
|
Matthias Radestock wrote:
> Alexis Richardson wrote:
>
>> We want to fix this. Do you have any other examples of mismatch
>> between OpenAMQ and RabbitMQ?
>
> I thought OpenAMQ implements 0-9.
>
> >> On the side of rabbitmq doing things wrong, the
> >> authentication is completely screwy - the server response says that
> >> it only supports PLAIN authentication but the server only implements
> >> AMQPLAIN.
> >> [...]
> >> particularly in the case of the authentication rabbitmq
> >> seems to be making specific allowances for qpid even tho it appears
> >> qpid is not following the spec exactly.
>
> We have hacked the PLAIN authentication to match Qpids. Our AMQPLAIN
> authentication is what the spec defines as PLAIN authentication.
>
> Is OpenAMQ doing PLAIN authentication in conformance with the spec?
>
> If so, the only way I can think of addressing the discrepancy at our end
> is to check what client is trying to connect to the RabbitMQ server and
> make PLAIN auth behave accordingly. Same in our client code. That's
> rather gross and brittle though.
I think part of the problem is that the 0.8 spec is confusing on this
point. It says:
"The contents of this data are defined by the SASL security
mechanism.For the PLAIN security mechanism this is defined as a field
table holding two fields,LOGIN and PASSWORD."
However, SASL also defines a mechanism called PLAIN in rfc4616 which is
message = [authzid] UTF8NUL authcid UTF8NUL passwd
This is what OpenAMQ implements as PLAIN and probably what qpid is doing
also (I have a vague recollection that qpid incorrectly leaves off the
initial null but that may be bad memory on my part).
So which PLAIN is PLAIN? Considering that the security is specified in
several places as using SASL mechanisms and that language about a
LOGIN/PASSWORD field table has been dropped in the 0.9 spec, I think the
SASL PLAIN mechanism is the right one to follow.
Confusion in the spec notwithstanding, my bigger gripe about how
rabbitmq is handling it is that the AMQPLAIN method is not advertised at
all in the connection.start call, so any use of it is going to be well,
gross and brittle as you say.
ejabberd appears to have implementations of SASL-PLAIN and
SASL-DIGEST-MD5 - I wonder if it would be worth adapting their code.
-J
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Thu Aug 23, 2007 7:14 pm |
|
|
|
Guest
|
Jeff,
Jeff Rogers wrote:
> I think part of the problem is that the 0.8 spec is confusing on this
> point. It says:
> "The contents of this data are defined by the SASL security
> mechanism.For the PLAIN security mechanism this is defined as a field
> table holding two fields,LOGIN and PASSWORD."
>
> However, SASL also defines a mechanism called PLAIN in rfc4616 which is
> message = [authzid] UTF8NUL authcid UTF8NUL passwd
> This is what OpenAMQ implements as PLAIN and probably what qpid is doing
> also (I have a vague recollection that qpid incorrectly leaves off the
> initial null but that may be bad memory on my part).
So it looks like OpenAMQ, Qpid, and RabbitMQ all use the SASL
definition, in which case there should be no interop problems in this
particular area, right?
> So which PLAIN is PLAIN? Considering that the security is specified in
> several places as using SASL mechanisms and that language about a
> LOGIN/PASSWORD field table has been dropped in the 0.9 spec, I think the
> SASL PLAIN mechanism is the right one to follow.
Agreed.
> Confusion in the spec notwithstanding, my bigger gripe about how
> rabbitmq is handling it is that the AMQPLAIN method is not advertised at
> all in the connection.start call, so any use of it is going to be well,
> gross and brittle as you say.
Given the above, I am tempted to simply remove AMQPLAIN.
Matthias.
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Thu Aug 23, 2007 7:29 pm |
|
|
|
Guest
|
> I don't recall any others off the top of my head. I think OpemAMQ
> doesn't implement persistence across broker restarts but that is a
> design decision and doesn't affect what clients need to do.
>
> For the client at least, most of the differences between 8.0 (0.8 has
> the major/minor version swapped in the xml file) and 0.9 are handled by
> just swapping the automatically generated framing definitions file.
This 0.8/0.9 thing is quite annoying... We would even revert to 0.8 to
get compatibility with RabbitMQ and Qpid, but we desperately need
Queue.Unbind which was added only in 0.9. Without Queue.Unbind we would
face severe performance problems in production 
Sorry about that.
Martin (OpenAMQ team)
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Thu Aug 23, 2007 7:59 pm |
|
|
|
Guest
|
| I was thinking that I could probably get the Java Qpid broker to support AMQP 0-9 (non-WIP) if there is demand. |
|
|
| Back to top |
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
