Interop and Protocol Version Compatibility

[Tomas Restrepo <to...@devdeo.com>]

One quick question: I know (or at least have an idea) as to the complexity
behind supporting multiple major protocol versions. However, I was a bit
curious as to how interop should be affected by "minor" protocol version
changes.

My question is prompted by something I noticed recently. I started looking
into having the .NET client at least be able to talk to other AMQP brokers
besides the Qpid Java Broker, which is all I've done any interop testing
with (I'm paving my other laptop as I write this so that I can build and
test against the Qpid C++ broker). 

In particular one of the brokers I was hoping to be able to test with was
RabbitMQ (I hope to be able to build OpenAMQP someday as well, but that has
been proving a bit harder than I thought :)). 

The .NET client can open connections to it, but barely. Not much else is
working yet, but I do hope to see what the matter is, as it has already
revealed some funky conditions in our error handling.

The Java client however, doesn't even connect. The problem is that RabbitMQ
says that it implements protocol version 8-1 (no idea why) on the
connection.start command, which apparently the Java client freaks about.

It seems like the protocol version checks during connection setup in the
Java client don't quite work as expected (or maybe my expectations are
different). What currently happens is that the Java client never responds
with a connection.start-ok (suggesting it believes it doesn't support the
specified protocol version), but neither does it actually close the TCP
connection to the broker. Instead, the client retries the connection after a
while, fails again to respond or close the connection, and eventually fails
the connection after the connection timeout expires. 

Doesn't quite make it very easy to diagnose :)


Tomas Restrepo
http://www.winterdom.com/weblog/

Re: Interop and Protocol Version Compatibility

[Gordon Sim <gs...@redhat.com>]

Tomas Restrepo wrote:
> One quick question: I know (or at least have an idea) as to the complexity
> behind supporting multiple major protocol versions. However, I was a bit
> curious as to how interop should be affected by "minor" protocol version
> changes.

After 1-0 I believe the intention of the AMQP working group is that 
minor version changes will be wire compatible. Before 1-0 however minor 
version changes may involve quite significant incompatabilities.

> My question is prompted by something I noticed recently. I started looking
> into having the .NET client at least be able to talk to other AMQP brokers
> besides the Qpid Java Broker, which is all I've done any interop testing
> with (I'm paving my other laptop as I write this so that I can build and
> test against the Qpid C++ broker). 
> 
> In particular one of the brokers I was hoping to be able to test with was
> RabbitMQ (I hope to be able to build OpenAMQP someday as well, but that has
> been proving a bit harder than I thought :)). 

Agreed; interoperability (within and without) has to be a key focus 
going forward.

> The .NET client can open connections to it, but barely. Not much else is
> working yet, but I do hope to see what the matter is, as it has already
> revealed some funky conditions in our error handling.
> 
> The Java client however, doesn't even connect. The problem is that RabbitMQ
> says that it implements protocol version 8-1 (no idea why) on the
> connection.start command, which apparently the Java client freaks about.

I thought 8-1 was actually a valid version representing mainly a few 
clarifications and other errata addressed after the publication of 0-8 
and 0-9. However I can't actually find a published copy of that version 
of the spec... maybe I'm imagining things.

> It seems like the protocol version checks during connection setup in the
> Java client don't quite work as expected (or maybe my expectations are
> different). What currently happens is that the Java client never responds
> with a connection.start-ok (suggesting it believes it doesn't support the
> specified protocol version), but neither does it actually close the TCP
> connection to the broker. Instead, the client retries the connection after a
> while, fails again to respond or close the connection, and eventually fails
> the connection after the connection timeout expires. 

That sounds like something in the failover logic that doesn't detect an 
incompatible protocol version as fatal.