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/
