Python Client for RabbitMQ/AMQP?

[Maximillian Dornseif]

Since being somewhat dissatisfied with ActiveMQ I'm shopping for other messaging solutions with a focus on correctness and reliability.  (See http://blogs.23.nu/c0re/?day=20070813# for some background.)

I'm looking for a simple (just send_bytes_to_queue() and receive_bytes_from_queue(), no transactions, fancy routing etc.) way to use the broker in Python and Java. RabbitMQ comes wit Java client libraries, so this is no issue.

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. Has anybody suggestions of how to send and receive messages from Python other than re-implementing (and testing) AMQP from the ground up?

Regards

Maximillian Dornseif

_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

[Ben Hood]

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?

Ben

_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

[Rob Godfrey]

On 14/08/07, Ben Hood <[hidden email]> 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
[hidden email]
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

[Alexis Richardson-2]

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 <[hidden email]> wrote:

>
>
> On 14/08/07, Ben Hood <[hidden email]> 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
> > [hidden email]
> >
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
> >
>
>
> _______________________________________________
> rabbitmq-discuss mailing list
> [hidden email]
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
>

--
Alexis Richardson
[phone] (UK)
[phone] (cell)
[phone] (US)

_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

[Matthias Radestock-2]

"Robert Godfrey" <[hidden email]> 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
[hidden email]
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

[Maximillian Dornseif]

Alexis Richardson-2 wrote

Max - I have looked at your blog.  Please tell us more about what you
want to achieve since then we can help you.

Allow me to give a somewhat long-winded introduction of our use of Messaging.
Maybe we are exemplary for a new kind of less enterprisy user of this class of
software. If you are bored, skip to the bottom.

I'm CIO at HUDORA, an SME being Germany's biggest supplier of Inline-Skates
and quite big in some other sportive product ranges. Our main challenge are
increasingly complex processes with our customers in the hyper competitive
European retail market (WalMart gave up in germany a year ago!). We are
determined to meet the future with custom developed, agile, highly adaptive
software. So much for the Buzzword Bingo.

In our IT landscape we are relatively legacy free (basically only the
telephone System and a big hulking AS/400 left). All new developments are done
in Python. Sometimes we write some Java if we can't resist the use of
libraries like XSLF-FO/FOP or JasperReports. We are considering Erlang to
implement a new Warehouse Managment System (WMS) since Warehouse Management has
some interesting concurrency issues. The Python programs have to run on
FreeBSD (our preferred Platform) but also on Linux and Windows to access
specialized Libraries and Interfaces like ODBC drivers etc.

We started to use messaging (without the label "messaging") and RPC to bind
systems and platforms together. In that course we have implemented UDP unicast
and multicast based solutions, used the Spread Toolkit, used PyRO RPC and a
PostgreSQL based Queue approach. By the Apache podcast I got introduced to
ApacheMQ and the world of JMS and learned that the JMS (or AMQP or whatever)
crowd solved most of the problems we were tackling with our home grown
solutions. So we stared using ActiveMQ for new projects and to replace the
home grown protocols.

We are not the financial service industry and so we have much lower
requirements for messaging :-) I estimate the highest cost for a lost message
would be 250E usually much lower. And the latency is also not that relevant: a
few seconds are fine for most of our queues. Also the volume is low: at the
moment we are well below 50.000 messages a day. Queues and topics are all we
need (for now) and we are happy the have a single message type along the lines
of BytesMessage. But we like to send big messages. So for example we would
like to use the message system to distribute scanned bitmaps for OCRing.

We build a lot of software ourselves and being a family owned business for the
last 90 years we intend to use a pice of software for some decades (at least
we try to design it that way). Therefore especially for the software where
other software builds upon we are extremely fond of the concept of reliability.
For us this does not necessarily means, 99.9999999% uptime but being "solid"
in the sense of: works deterministic and according to specification; can be
understood, fixed and tested easily. This is mainly to effectively use our
sparse coding and administration resources: if we can rely of all parts
holding up to their specification it is much more easy to integrate them and
to concentrate on the part you are developing.

It is important that "works according to specification" does not mean a huge
documentation. On the contrary - the lighter the specification, the easier it
is to implement and to test that it is implemented correctly (you probably see
my issues with AMQP there). So we generally build with a "less is more"
attitude and use agile methods.

It turned out out that our attitude towards software didn't work well with
ActiveMQ. I was not able to get my own python based client code work reliable
with ActiveMQ and it's Stomp implementation. I also was not able to get other
Python-Stomp libraries to work reliable. In fact the unit tests failed for
about 1 in 1000 messages - but not always in the same place. Maybe ActiveMQ's
Stomp implementation is broken maybe Stomp is just extremely hard to implement
right. I toyed with the idea of implementing ActiveMQ's OpenWire Protocol but
I found the documentation lacking to start an implementation from scratch -
also the protocol is more complex than necessary for our needs.

Shopping for an other message broker than ActiveMQ turns out the be a thorny
way: Most are imbedded within a bigger software stack (e.g JBoss). Seemingly
everything is meant for people with a Java background and often it is only
usable by from Java. For example see RabbitMQ which is written in Erlang but
has no Way to send and receive messages from Erlang. (Or at least had not
until the work by Ben Hood.)

Just as a side note: while we are are perfectly willing to pay for software
related services, we wary with what Stallman calls "proprietary software": we
found that systems with a "free" code base work better for us. On the other
hand proprietary software puts upon us burdens which are not in our own best
interest: E.g. windows XP "activation" or other licensing and registration
schemes.


What we are looking for

* reliable & stable broker, client libs, protocol.
* JMS Queue and Topic like behavior. In addition RPC. No transactions needed.
* Clients in Python and Java with a strong probability that in the next
  24 months there will be additional clients in Ruby, C, Perl and PHP.
* Clients with a well documented, stable interface. Something along the lines
  of send_bytemsg('/queue/TEST', databytes, headers),
  receive_send_bytemsg('/queue/TEST'), rpc('/queue/TEST', params)
  * Alternatively to already implemented clients a protocol simple enough
    to enable us to implement well tested and documented clients ourself in
    reasonable time.


Regards

Maximillian

[Maximillian Dornseif]

[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 <[hidden email]> 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
[hidden email]
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

[Alexis Richardson-2]

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 <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>

--
Alexis Richardson
[phone] (UK)
[phone] (cell)
[phone] (US)

_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

[Jeff Rogers-2]

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
[hidden email]
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

[Alexis Richardson-2]

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 <[hidden email]> 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
> [hidden email]
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>

--
Alexis Richardson
[phone] (UK)
[phone] (cell)
[phone] (US)

_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

[Jeff Rogers-2]

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
[hidden email]
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

[Matthias Radestock-2]

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
[hidden email]
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

[Jeff Rogers-2]

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
[hidden email]
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

[Matthias Radestock-2]

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
[hidden email]
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

[Martin Sustrik]

> 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
[hidden email]
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

[Rob Godfrey]

I was thinking that I could probably get the Java Qpid broker to support AMQP 0-9 (non-WIP) if there is demand.  For the production uses of Qpid that I know about 0-8 is all that will be used however.

Martin - does OpenAMQ still accept clients wanting to talk 0-8 to it?  I can't remember any changes off the top of my head between 0-8 and 0-9 (non-WIP) that would prevent a 0-9 broker from accepting communication from a 0-8 client [sorry for hijacking a Rabbit-MQ list for a Qpid / OpenAMQ question].

Thanks,
Rob

On 23/08/07, Martin Sustrik <[hidden email]> wrote:

> 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
[hidden email]
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

[Martin Ritchie-2]

Alexis,

I'd be very interested in your list of mismatches with Qpid. I know
the Qpid Java client deviates from the AMQP spec to fully be JMS
compliant but I did add a property AMQP_STRICT which should turn all
that off so you can use the JMS client that will fit on the standard
0_8 AMQP. If there is somthing I have missed then I will gladly fix
it.

Our long over due M2 release will be available with the next week or
so. If you have been working with M1 then this is a major leap
forward.

I think it is great that our different groups can write clients and
brokers and use each others clients/test suites to validate our own
work.

Cheers

On 23/08/07, Alexis Richardson <[hidden email]> wrote:

> 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 <[hidden email]> 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
> > [hidden email]
> > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
> >
>
>
> --
> Alexis Richardson
> [phone] (UK)
> [phone] (cell)
> [phone] (US)
>
> _______________________________________________
> rabbitmq-discuss mailing list
> [hidden email]
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>

--
Martin Ritchie

_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

[Alexis Richardson-2]

Martin

Let's checkpoint a list of mismatches once M2 comes out, running it in
strict mode.

I agree it is very good we can cross check clients and servers, and
appreciate everyone's efforts!

alexis



On 8/23/07, Martin Ritchie <[hidden email]> wrote:

> Alexis,
>
> I'd be very interested in your list of mismatches with Qpid. I know
> the Qpid Java client deviates from the AMQP spec to fully be JMS
> compliant but I did add a property AMQP_STRICT which should turn all
> that off so you can use the JMS client that will fit on the standard
> 0_8 AMQP. If there is somthing I have missed then I will gladly fix
> it.
>
> Our long over due M2 release will be available with the next week or
> so. If you have been working with M1 then this is a major leap
> forward.
>
> I think it is great that our different groups can write clients and
> brokers and use each others clients/test suites to validate our own
> work.
>
> Cheers
>
> On 23/08/07, Alexis Richardson <[hidden email]> wrote:
> > 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 <[hidden email]> 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
> > > [hidden email]
> > > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
> > >
> >
> >
> > --
> > Alexis Richardson
> > [phone] (UK)
> > [phone] (cell)
> > [phone] (US)
> >
> > _______________________________________________
> > rabbitmq-discuss mailing list
> > [hidden email]
> > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
> >
>
>
> --
> Martin Ritchie
>
> _______________________________________________
> rabbitmq-discuss mailing list
> [hidden email]
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>

--
Alexis Richardson
[phone] (UK)
[phone] (cell)
[phone] (US)

_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

[Matthias Radestock-2]

Jeff,

Matthias Radestock wrote:
> Jeff Rogers wrote:
>> 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.

It turns out that AMQPLAIN is used by the Qpid python test suite. So
instead of removing it I've added it to the list of security mechanisms
advertised by the RabbitMQ broker.

Matthias

_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss