qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robbie Gemmell <robbie.gemm...@gmail.com>
Subject Re: messenger to qpidd barfs with: ERROR[-2] SASL header mismatch: 'AMQP\x01\x01\x00\x0a'
Date Sun, 12 Jan 2014 16:58:17 GMT
You look to be seeing the AMQP 0-10 handshake returned from the qpidd,
which would appear to be the broker is saying 'I dont support 1.0, try
using 0-10'.

Just because something was built doesnt mean it is actually in use. The
info at http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/AMQP_1.0 could
be out of date, but it says:
"To enable 1.0 support in qpidd, the amqp module must be loaded. This
allows the broker to recognise the 1.0 protocol header alongside the 0-10
one. If installed, the module directory should be configured such that this
happens automatically. If not, use the --load-module option and point to
the amqp.so module."

1.0 support is enabled by default on the Java broker; not configuring any
specific supported protocols mean that they are all supported (0-8 / 0-9 /
0-9-1 / 0-10 / 1.0). The docs mostly talk about the UI because it the
primary means of configuring the broker, though obviosuly nothing is
stopping you hand editing the config if you like. Connection refused sounds
like it might be something other than just the protocol version not being
enabled though, if it wasnt the Java broker should really behave much like
qpidd did and respond with a supported protocol version.

As Rob has juat beaten me to syaing, you will need to authenticate against
the Java broker (or perhaps change the broker configuration to support
anonymous by creating an anonymous auth providerand setting the port to use
it, noting the requirement to restart the broker:


On 12 January 2014 16:32, Fraser Adams <fraser.adams@blueyonder.co.uk>wrote:

> Hi Robbie,
> Re "The AMQP 1.0 handshakes are AMQP 3 1 0 0 and AMQP 0 1 0 0", yeah
> that's what I'd have guessed too looking at the couple of #defines I found
> in the Proton code.
> TBH I've no real idea how to figure out if qpidd *definitely* has AMQP 1.0
> support enabled, though as I say when I look at the output of "cmake .."
> it's definitely finding the installed proton library (and when I uninstall
> Proton the cmake output then says no AMQP 1.0 support, so it looks like
> it's including it). Also as I mentioned qpidd -h includes:
> AMQP 1.0 Options:
>   --domain DOMAIN           Domain of this broker
>   --queue-patterns PATTERN  Pattern for on-demand queues
>   --topic-patterns PATTERN  Pattern for on-demand topics
> I'd have thought that wouldn't be listed if AMQP 1.0 support wasn't
> enabled, but who knows :-D and as you say, if it's a module issue....
> Re "but is it not in its own module ", I thought that AMQP 1.0 support
> *used* to be in a module, but I *thought* that it was included by default
> in more recent versions (and as I say I'm building off trunk) but you might
> be on to something with your
> "--no-module-dir " I only added that because qpidd failed to start at all
> after my build yesterday because it tries to include both linearstore and
> legacystore - I think there's a rogue install bug floating around :-(
> I'll play around with the startup options and see if I get anywhere -
> hopefully someone who knows about the AMQP 1.0 support on qpidd can chip in.
> BTW when I fired up the Java Broker I didn't even get that far :-D
> I got a Connection Refused from "send". I'm "guessing" that I need to
> add/modify some JSON magic to config.json to enable AMQP 1.0 support on the
> Java Broker? Do I need to do something to the AMQP in the "ports" section -
> at a guess add a "protocols" section? (the protocols section is empty for
> that, which I guess means default to 0.10 presumably I need a list? 'fraid
> I don't know too much about the config. I had a quick look through
> http://qpid.apache.org/releases/qpid-0.24/java-broker/book/Java-Broker-Configuring-And-Managing.html#Java-Broker-Configuring-And-Managing-Configuration-Storebut
is seems to mainly talk about setting this from the UI rather than the
> JSON file).
> Thanks for the thoughts,
> Cheers,
> Frase
> On 12/01/14 14:24, Robbie Gemmell wrote:
>> Hi Fraser,
>> I'm not sure your assumption about 1.0 being enabled is correct, that
>> looks
>> like the AMQP 0-10 handshake to me: AMQP 1 1 0 10.
>> The AMQP 1.0 handshakes are AMQP 3 1 0 0 and AMQP 0 1 0 0.
>> I must admit to having not used the 1.0 support in qpidd, but is it not in
>> its own module? In which case perhaps your --no-module-dir option could be
>> in play.
>> Robbie
>> On 12 January 2014 14:03, Fraser Adams <fraser.adams@blueyonder.co.uk
>> >wrote:
>>  Hey all,
>>> I thought I'd have a go at trying to send an AMQP 1.0 message between
>>> Proton messenger and qpidd.
>>> I've tried to keep things as simple as possible, but unfortunately it
>>> still barfed, so I'd be grateful for some pointers.
>>> I built qpidd 0.27 off trunk yesterday and fired it up with:
>>> qpidd --auth no --no-module-dir
>>> (The --no-module-dir is there 'cause there's a bug on trunk due to both
>>> stores getting deployed).
>>> I added a queue imaginatively called "test" :-)
>>> Using the simple "send" program in proton-c/examples/messenger/c I tried:
>>> ./send -a amqp://
>>> Which should, I think, send "Hello World!" to the test queue - it
>>> certainly seems to follow the pattern suggested by Gordon below.
>>> But it fails with:
>>> ERROR[-2] SASL header mismatch: 'AMQP\x01\x01\x00\x0a'
>>> I've also tried:
>>> ./send -a amqp://
>>> ./send -a amqp://localhost/test
>>> ./send -a amqp://
>>> All fail with the same error.
>>> When I stand up the recv program instead of qpidd it happily prints out
>>> Address: amqp://
>>> Subject: (no subject)
>>> Content: "Hello World!"
>>> With the last example, which is what I'd expect.
>>> I don't believe that there's too much wrong with my qpidd build, cmake
>>> picked up my proton install and running qpidd -h prints out:
>>> AMQP 1.0 Options:
>>>    --domain DOMAIN           Domain of this broker
>>>    --queue-patterns PATTERN  Pattern for on-demand queues
>>>    --topic-patterns PATTERN  Pattern for on-demand topics
>>> Which both suggest that it's correctly build with AMQP 1.0 support.
>>> Any thoughts as to what I've done wrong? BTW I also tried doing:
>>> ./send -a amqp://guest/guest@
>>> "just to see", but I get the same SASL header mismatch error.
>>> Failing on such a trivial use case doesn't fill me with a great deal of
>>> confidence for trying something more exciting :-(
>>> Any thoughts on what I'm doing wrong.
>>> BTW when talking between "send" and "receive" the first block of data
>>> that
>>> send sends is:
>>> 65,77,81,80,3,1,0,0,0,0,0,33,2,1,0,0,0,83,65,208,0,0,0,17,
>>> 0,0,0,2,163,9,65,78,79,78,89,77,79,85,83,160,0
>>> I "think" the 65,77,81,80,3,1,0,0 bit is the AMQP SASL header given the
>>> #define SASL_HEADER ("AMQP\x03\x01\x00\x00")
>>> in proton-c/src/sasl/sasl.c
>>> So not sure if there's something I need to do with qpidd?
>>> I also tried firing up qpidd with:
>>> qpidd --no-module-dir
>>> With no more joy :-(
>>> BTW there's a similar issue mentioned on the proton list on the thread:
>>> pn_messenger_send return code albeit that Sergey is trying to talk to the
>>>   SwiftMQ Broker.
>>> Cheers,
>>> Frase
>>> On 10/01/14 13:01, Gordon Sim wrote:
>>>  At present messenger only sets the address of the source for receiving
>>>> links and of the target for sending links. For sending/receiving to an
>>>> existing queue or to a fanout exchange, this is all you need (just
>>>> specify
>>>> the queue or exchange name as the path in the url of the address used,
>>>> e.g.
>>>> amqp:// or amqp:// That gives
>>>> you the basic queue and topic patterns of JMS.
>>>>  ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>> For additional commands, e-mail: users-help@qpid.apache.org
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message