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.
