Hi Tomas,
We added a system propoerty check to the Java client to allow it to simply
"accept" whatever the broker suggests as the protocol version....
// For the purposes of interop, we can make the client accept the
broker's version string.
// If it does, it then internally records the version as being the
latest one that it understands.
// It needs to do this since frame lookup is done by version.
if (Boolean.getBoolean("qpid.accept.broker.version") &&
!pv.isSupported())
{
pv = ProtocolVersion.getLatestSupportedVersion();
}
So - if you set the property qpid.accept.broker.version to true, it should
interop with Rabbit. I've certainly had success interopping with Rabbit
before.
I've not tried OpenAMQ with anything like a current version of Qpid,
although production instances of OpenAMQ work with very old instances of the
Qpid Java and .NET clients ...
Cheers,
Rob
On 19/04/07, Tomas Restrepo <[EMAIL PROTECTED]> 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.
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/
