You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Fraser Adams <fr...@blueyonder.co.uk> on 2014/01/12 15:03:57 UTC
messenger to qpidd barfs with: ERROR[-2] SASL header mismatch: 'AMQP\x01\x01\x00\x0a'
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://0.0.0.0/test
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://127.0.0.1/test
./send -a amqp://localhost/test
./send -a amqp://127.0.0.1
All fail with the same error.
When I stand up the recv program instead of qpidd it happily prints out
Address: amqp://127.0.0.1
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@0.0.0.0/test
"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://127.0.0.1/my-queue or
> amqp://127.0.0.1/amq.fanout). 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
Re: Java Broker WebSocket support - now talks directly to JavaScript
client!!
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
Hey all,
An update - mainly for Rob & Robbie, but Rafael and others might be
interested too.
Adding:
{
"authenticationProvider" : "passwordFile",
"id" : "37b451cc-f4fb-4964-b352-21f5a474df73",
"name" : "AMQP-WS",
"port" : "5673",
"transports" : [ "WS" ]
}
To my Java Broker config.json enabled the WebSocket support to the Java
Broker nicely and I've now been able to *directly* send messages to the
Java Broker from my JavaScript port of Proton's "send" program by doing:
node send-async.js -a amqp://guest:guest@localhost:5673/test
I've now got to make things rather more idiomatically JavaScript via
some binding code (what I've currently got is completely compiled via
emscripten from my send-async.c/recv-async.c C programs).
The only tweak that I had to make was make sure that emscripten set the
subprotocol to "AMQPWSB10" that was harder than it should have been for
node because it uses the "ws" WebSocket library so needs
new WebSocket(url, {'protocol': 'AMQPWSB10'});
rather than just
new WebSocket(url, 'AMQPWSB10');
As a browser would need - and it took me ages to figure out the syntax :-D
I'll need to add a patch to emscripten to make the WebSocket subprotocol
setup more configurable, but that's no bigee.
I guess that one thing to mention comes from a conversation between Rob
and myself the other day. As it happens Rob's WebSocket server is quite
"lenient" with respect to the draft AMQP/WS spec. and as it seems what
I'm doing is not quite "compliant" :-)
What I'm doing is literally a compilation of proton-c and the posix
driver.c writes out an AMQP byte stream in a buffer to a socket - and
it's that buffer that gets written to the WebSocket. According to the
conversations that I've had with Rob it seems that the AMQP/WS spec
looks to make use of WebSocket framing. As I say I'm simply treating the
byte buffers from proton-c as an opaque octet array.
In order to make things more compliant apparently proton-c will need to
have a way to expose the *frame* transport. I guess that's worth a
discussion at some point, but for now it seems pretty cool that Rob's
"lenient" server copes with my "non-compliant" client :-D yay!!
Regards,
Frase
On 12/01/14 17:51, Robbie Gemmell wrote:
> I think that would give you an exception due to two ports with the same
> name, but change the name and essentially yes. The broker will assign the
> ID if you start it up without one, yes, which is probably the best thing to
> do generally if adding things under its feet :).
>
> Sidenote: the easiest thing would probably have been to create the port via
> the UI, pick TCP or SSL explicitly, and then flip the transport to WS.
>
> Robbie
>
> On 12 January 2014 17:44, Fraser Adams <fr...@blueyonder.co.uk>wrote:
>
>> Hi Robbie,
>> Just trying to digest your comments below with respect to enabling Rob's
>> magical new WS support.
>> At the moment my config.json has:
>>
>> "ports" : [ {
>> "authenticationProvider" : "passwordFile",
>> "id" : "9e2707d9-10b4-4c3e-8439-cd6135419f19",
>> "name" : "AMQP",
>> "port" : "5672"
>> }, {
>> ..........
>>
>> If I'm reading you correctly if I do something like:
>>
>> "ports" : [ {
>> "authenticationProvider" : "passwordFile",
>> "id" : "9e2707d9-10b4-4c3e-8439-cd6135419f19",
>> "name" : "AMQP",
>> "transports" : [ "TCP" ],
>> "port" : "5672"
>> }, {
>> "authenticationProvider" : "passwordFile",
>> "id" : "9e2707d9-10b4-4c3e-8439-cd6135419f1a",
>> "name" : "AMQP",
>> "transports" : [ "WS" ],
>> "port" : "5673"
>> }
>>
>> that would give me AMQP over a TCP transport on port 5672 and AMQP over a
>> WebSocket transport on port 5673, is that correct - presumably if I omit
>> the "id" I'll get a proper one allocated too?
>>
>> Frase
>>
>> On 12/01/14 17:31, Robbie Gemmell wrote:
>>
>>> Despite what my last mail said, to do that I think youll probably have to
>>> edit the broker config by hand, as the support is there but isnt really
>>> exposed.
>>>
>>> Ports default to TCP if the transports attribute isnt explicitly
>>> specified,
>>> which it isnt by default, but if it was it would look like: "transports" :
>>> [ "TCP" ]
>>>
>>> To use WebSockets, change the TCP to WS.
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> 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
Re: Java Broker WebSocket support - was Re: messenger to qpidd barfs
with: ERROR[-2] SASL header mismatch: 'AMQP\x01\x01\x00\x0a'
Posted by Robbie Gemmell <ro...@gmail.com>.
I think that would give you an exception due to two ports with the same
name, but change the name and essentially yes. The broker will assign the
ID if you start it up without one, yes, which is probably the best thing to
do generally if adding things under its feet :).
Sidenote: the easiest thing would probably have been to create the port via
the UI, pick TCP or SSL explicitly, and then flip the transport to WS.
Robbie
On 12 January 2014 17:44, Fraser Adams <fr...@blueyonder.co.uk>wrote:
> Hi Robbie,
> Just trying to digest your comments below with respect to enabling Rob's
> magical new WS support.
> At the moment my config.json has:
>
> "ports" : [ {
> "authenticationProvider" : "passwordFile",
> "id" : "9e2707d9-10b4-4c3e-8439-cd6135419f19",
> "name" : "AMQP",
> "port" : "5672"
> }, {
> ..........
>
> If I'm reading you correctly if I do something like:
>
> "ports" : [ {
> "authenticationProvider" : "passwordFile",
> "id" : "9e2707d9-10b4-4c3e-8439-cd6135419f19",
> "name" : "AMQP",
> "transports" : [ "TCP" ],
> "port" : "5672"
> }, {
> "authenticationProvider" : "passwordFile",
> "id" : "9e2707d9-10b4-4c3e-8439-cd6135419f1a",
> "name" : "AMQP",
> "transports" : [ "WS" ],
> "port" : "5673"
> }
>
> that would give me AMQP over a TCP transport on port 5672 and AMQP over a
> WebSocket transport on port 5673, is that correct - presumably if I omit
> the "id" I'll get a proper one allocated too?
>
> Frase
>
> On 12/01/14 17:31, Robbie Gemmell wrote:
>
>>
>> Despite what my last mail said, to do that I think youll probably have to
>> edit the broker config by hand, as the support is there but isnt really
>> exposed.
>>
>> Ports default to TCP if the transports attribute isnt explicitly
>> specified,
>> which it isnt by default, but if it was it would look like: "transports" :
>> [ "TCP" ]
>>
>> To use WebSockets, change the TCP to WS.
>>
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Java Broker WebSocket support - was Re: messenger to qpidd barfs
with: ERROR[-2] SASL header mismatch: 'AMQP\x01\x01\x00\x0a'
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
Hi Robbie,
Just trying to digest your comments below with respect to enabling Rob's
magical new WS support.
At the moment my config.json has:
"ports" : [ {
"authenticationProvider" : "passwordFile",
"id" : "9e2707d9-10b4-4c3e-8439-cd6135419f19",
"name" : "AMQP",
"port" : "5672"
}, {
..........
If I'm reading you correctly if I do something like:
"ports" : [ {
"authenticationProvider" : "passwordFile",
"id" : "9e2707d9-10b4-4c3e-8439-cd6135419f19",
"name" : "AMQP",
"transports" : [ "TCP" ],
"port" : "5672"
}, {
"authenticationProvider" : "passwordFile",
"id" : "9e2707d9-10b4-4c3e-8439-cd6135419f1a",
"name" : "AMQP",
"transports" : [ "WS" ],
"port" : "5673"
}
that would give me AMQP over a TCP transport on port 5672 and AMQP over
a WebSocket transport on port 5673, is that correct - presumably if I
omit the "id" I'll get a proper one allocated too?
Frase
On 12/01/14 17:31, Robbie Gemmell wrote:
>
> Despite what my last mail said, to do that I think youll probably have to
> edit the broker config by hand, as the support is there but isnt really
> exposed.
>
> Ports default to TCP if the transports attribute isnt explicitly specified,
> which it isnt by default, but if it was it would look like: "transports" :
> [ "TCP" ]
>
> To use WebSockets, change the TCP to WS.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: messenger to qpidd barfs with: ERROR[-2] SASL header mismatch: 'AMQP\x01\x01\x00\x0a'
Posted by Robbie Gemmell <ro...@gmail.com>.
On 12 January 2014 17:02, Fraser Adams <fr...@blueyonder.co.uk>wrote:
> Cheers Robbie, you're a *star*, you were indeed correct and it was that
> flipping "--no-module-dir"
>
> I manually deleted legacystore.so and fired up
> qpidd --auth no
>
> and
> ./send -a amqp://localhost/test
>
> Successfully adds things to my test queue (I've not tried reading them off
> yet, but so far so good)
>
> What's *even cooler* is that the following also works:
>
> node send-async.js -a amqp://localhost:5673/test
>
> I've stood up a noddy little WebSocket<->TCP Socket proxy that listens on
> a configurable WebSocket port (in this case 5673) and spits the data out on
> a target port (defaults to <listen port> - 1)
>
> So what I've successfully done is to send AMQP 1.0 data out from a
> WebSocket from my JavaScript port of Proton, proxied it to a TCP socket
> (just copies the byte buffer off the WebSocket and onto the TCP Socket and
> vice versa) which in turn sent the data to qpidd. I've got it working from
> Node.js and Firefox.
>
> I'm feeling pretty pleased now :-) I'll have a play around with Rob's
> WebSocket support on the Java Broker now, it'll be neat to go direct to a
> Broker without needing a proxy.
>
>
Despite what my last mail said, to do that I think youll probably have to
edit the broker config by hand, as the support is there but isnt really
exposed.
Ports default to TCP if the transports attribute isnt explicitly specified,
which it isnt by default, but if it was it would look like: "transports" :
[ "TCP" ]
To use WebSockets, change the TCP to WS.
> and my send-async.js is working fully asynchronously now thanks to some
> modifications to emscripten I've been working on - it's all starting to
> come together now :-)
>
> Thanks muchly for helping me out of that annoying little hole - feel like
> I'm making a bit of decent progress now.
>
> 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://0.0.0.0/test
>>>
>>> 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://127.0.0.1/test
>>> ./send -a amqp://localhost/test
>>> ./send -a amqp://127.0.0.1
>>>
>>> All fail with the same error.
>>>
>>> When I stand up the recv program instead of qpidd it happily prints out
>>>
>>> Address: amqp://127.0.0.1
>>> 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@0.0.0.0/test
>>>
>>> "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://127.0.0.1/my-queue or amqp://127.0.0.1/amq.fanout). 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
>
>
Re: messenger to qpidd barfs with: ERROR[-2] SASL header mismatch:
'AMQP\x01\x01\x00\x0a'
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
Cheers Robbie, you're a *star*, you were indeed correct and it was that
flipping "--no-module-dir"
I manually deleted legacystore.so and fired up
qpidd --auth no
and
./send -a amqp://localhost/test
Successfully adds things to my test queue (I've not tried reading them
off yet, but so far so good)
What's *even cooler* is that the following also works:
node send-async.js -a amqp://localhost:5673/test
I've stood up a noddy little WebSocket<->TCP Socket proxy that listens
on a configurable WebSocket port (in this case 5673) and spits the data
out on a target port (defaults to <listen port> - 1)
So what I've successfully done is to send AMQP 1.0 data out from a
WebSocket from my JavaScript port of Proton, proxied it to a TCP socket
(just copies the byte buffer off the WebSocket and onto the TCP Socket
and vice versa) which in turn sent the data to qpidd. I've got it
working from Node.js and Firefox.
I'm feeling pretty pleased now :-) I'll have a play around with Rob's
WebSocket support on the Java Broker now, it'll be neat to go direct to
a Broker without needing a proxy.
and my send-async.js is working fully asynchronously now thanks to some
modifications to emscripten I've been working on - it's all starting to
come together now :-)
Thanks muchly for helping me out of that annoying little hole - feel
like I'm making a bit of decent progress now.
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 <fr...@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://0.0.0.0/test
>>
>> 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://127.0.0.1/test
>> ./send -a amqp://localhost/test
>> ./send -a amqp://127.0.0.1
>>
>> All fail with the same error.
>>
>> When I stand up the recv program instead of qpidd it happily prints out
>>
>> Address: amqp://127.0.0.1
>> 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@0.0.0.0/test
>>
>> "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://127.0.0.1/my-queue or amqp://127.0.0.1/amq.fanout). 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
Re: messenger to qpidd barfs with: ERROR[-2] SASL header mismatch: 'AMQP\x01\x01\x00\x0a'
Posted by Rob Godfrey <ro...@gmail.com>.
Sorry - yes my next observation was going to be that the form for the 1-0
tools is user:pass@ (the username/password was and unfortunate abbreviation
rather than implying syntax) however at that time my flight was called so I
didn't have time to finish my mail :-)
I'll be adding the GUI necessary to configure websockets through the API
later this week/early next week... just struggling with implements WSS and
client certificate auth at the moment, so - as Robbie says - creating an
TCP port then just editing the config file is the easiest way to do it
right now :-)
Cheers,
Rob
On 12 January 2014 18:52, Fraser Adams <fr...@blueyonder.co.uk>wrote:
> Re; "I would say user:pass is consistent with most URL usages, user/pass
> is the odd one out, so I for one am glad that has been changed."
>
> I'd tend to agree with you there, though as I say the "/" is used by all
> the Python tools (and possibly elsewhere) as I mentioned in my mail I think
> it's probably worth at least a discussion on the feasibility of making
> things consistent.
>
> TBH the user/pass has tended to be the one I've "typed" because of things
> like qpid-config etc. the user:pass form has tended to sit in JNDI not
> needing touched terribly often, which is likely why the user/pass form
> stuck in my head :-/
>
> Frase
>
>
>
> On 12/01/14 17:37, Robbie Gemmell wrote:
>
>> On 12 January 2014 17:28, Fraser Adams <fraser.adams@blueyonder.co.uk
>> >wrote:
>>
>> Hi again guys,
>>> I've just tried again with the Java Broker
>>>
>>> What I've discovered is that:
>>> ./send -a amqp://guest/guest@localhost/test
>>> [0x19cde50]:ERROR[0] (null)
>>>
>>> CONNECTION ERROR connection aborted
>>>
>>>
>>> However with:
>>> ./send -a amqp://guest:guest@localhost/test
>>>
>>> *bingo* message arrives on the test queue. Aaarrgghhh :-D
>>> I guess that form is consistent with "traditional" Java ConnectionURLs,
>>> though the Address syntax for the Python tools tends to be of the
>>> "<user>/<pass>@<host>:<port>"
>>>
>>> I would say user:pass is consistent with most URL usages, user/pass is
>> the
>> odd one out, so I for one am glad that has been changed.
>>
>> I'm not actually sure Rob meant use user/pass in the URL (though he might
>> have), thats just how a lot of people including myself shorten 'username
>> and apssword' during a sentence :)
>>
>>
>> e.g. from qpid-config
>>> -b <address>, --broker=<address>
>>> Address of qpidd broker with syntax:
>>> [username/password@] hostname | ip-address
>>> [:<port>]
>>>
>>>
>>> I guess there's *plenty* of scope for confusion :-/
>>> To be fair I've just looked at the DOxygen doc for pn_messenger_route and
>>> the examples there mention "amqp://user:password@foo.com".
>>>
>>> It might be worth a conversation about the Python tools addressing
>>> convention, perhaps the "/" separator should be deprecated in favour of
>>> the
>>> ":" to make things consistent (ducks to avoid the rain of missiles at
>>> such
>>> a suggestion ;->)
>>>
>>> Thanks again both of you for your help, I'm feeling pretty pleased today!
>>> Frase
>>>
>>>
>>>
>>>
>>> On 12/01/14 16:50, Rob Godfrey wrote:
>>>
>>> With the Java broker are you using a username/password (guest/guest
>>>> should
>>>> work)?
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>> 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
>
>
Re: messenger to qpidd barfs with: ERROR[-2] SASL header mismatch:
'AMQP\x01\x01\x00\x0a'
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
Re; "I would say user:pass is consistent with most URL usages, user/pass
is the odd one out, so I for one am glad that has been changed."
I'd tend to agree with you there, though as I say the "/" is used by all
the Python tools (and possibly elsewhere) as I mentioned in my mail I
think it's probably worth at least a discussion on the feasibility of
making things consistent.
TBH the user/pass has tended to be the one I've "typed" because of
things like qpid-config etc. the user:pass form has tended to sit in
JNDI not needing touched terribly often, which is likely why the
user/pass form stuck in my head :-/
Frase
On 12/01/14 17:37, Robbie Gemmell wrote:
> On 12 January 2014 17:28, Fraser Adams <fr...@blueyonder.co.uk>wrote:
>
>> Hi again guys,
>> I've just tried again with the Java Broker
>>
>> What I've discovered is that:
>> ./send -a amqp://guest/guest@localhost/test
>> [0x19cde50]:ERROR[0] (null)
>>
>> CONNECTION ERROR connection aborted
>>
>>
>> However with:
>> ./send -a amqp://guest:guest@localhost/test
>>
>> *bingo* message arrives on the test queue. Aaarrgghhh :-D
>> I guess that form is consistent with "traditional" Java ConnectionURLs,
>> though the Address syntax for the Python tools tends to be of the
>> "<user>/<pass>@<host>:<port>"
>>
> I would say user:pass is consistent with most URL usages, user/pass is the
> odd one out, so I for one am glad that has been changed.
>
> I'm not actually sure Rob meant use user/pass in the URL (though he might
> have), thats just how a lot of people including myself shorten 'username
> and apssword' during a sentence :)
>
>
>> e.g. from qpid-config
>> -b <address>, --broker=<address>
>> Address of qpidd broker with syntax:
>> [username/password@] hostname | ip-address
>> [:<port>]
>>
>>
>> I guess there's *plenty* of scope for confusion :-/
>> To be fair I've just looked at the DOxygen doc for pn_messenger_route and
>> the examples there mention "amqp://user:password@foo.com".
>>
>> It might be worth a conversation about the Python tools addressing
>> convention, perhaps the "/" separator should be deprecated in favour of the
>> ":" to make things consistent (ducks to avoid the rain of missiles at such
>> a suggestion ;->)
>>
>> Thanks again both of you for your help, I'm feeling pretty pleased today!
>> Frase
>>
>>
>>
>>
>> On 12/01/14 16:50, Rob Godfrey wrote:
>>
>>> With the Java broker are you using a username/password (guest/guest should
>>> work)?
>>>
>>>
>> ---------------------------------------------------------------------
>> 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
Re: messenger to qpidd barfs with: ERROR[-2] SASL header mismatch: 'AMQP\x01\x01\x00\x0a'
Posted by Robbie Gemmell <ro...@gmail.com>.
On 12 January 2014 17:28, Fraser Adams <fr...@blueyonder.co.uk>wrote:
> Hi again guys,
> I've just tried again with the Java Broker
>
> What I've discovered is that:
> ./send -a amqp://guest/guest@localhost/test
> [0x19cde50]:ERROR[0] (null)
>
> CONNECTION ERROR connection aborted
>
>
> However with:
> ./send -a amqp://guest:guest@localhost/test
>
> *bingo* message arrives on the test queue. Aaarrgghhh :-D
> I guess that form is consistent with "traditional" Java ConnectionURLs,
> though the Address syntax for the Python tools tends to be of the
> "<user>/<pass>@<host>:<port>"
>
I would say user:pass is consistent with most URL usages, user/pass is the
odd one out, so I for one am glad that has been changed.
I'm not actually sure Rob meant use user/pass in the URL (though he might
have), thats just how a lot of people including myself shorten 'username
and apssword' during a sentence :)
>
> e.g. from qpid-config
> -b <address>, --broker=<address>
> Address of qpidd broker with syntax:
> [username/password@] hostname | ip-address
> [:<port>]
>
>
> I guess there's *plenty* of scope for confusion :-/
> To be fair I've just looked at the DOxygen doc for pn_messenger_route and
> the examples there mention "amqp://user:password@foo.com".
>
> It might be worth a conversation about the Python tools addressing
> convention, perhaps the "/" separator should be deprecated in favour of the
> ":" to make things consistent (ducks to avoid the rain of missiles at such
> a suggestion ;->)
>
> Thanks again both of you for your help, I'm feeling pretty pleased today!
> Frase
>
>
>
>
> On 12/01/14 16:50, Rob Godfrey wrote:
>
>> With the Java broker are you using a username/password (guest/guest should
>> work)?
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: messenger to qpidd barfs with: ERROR[-2] SASL header mismatch:
'AMQP\x01\x01\x00\x0a'
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
Hi again guys,
I've just tried again with the Java Broker
What I've discovered is that:
./send -a amqp://guest/guest@localhost/test
[0x19cde50]:ERROR[0] (null)
CONNECTION ERROR connection aborted
However with:
./send -a amqp://guest:guest@localhost/test
*bingo* message arrives on the test queue. Aaarrgghhh :-D
I guess that form is consistent with "traditional" Java ConnectionURLs,
though the Address syntax for the Python tools tends to be of the
"<user>/<pass>@<host>:<port>"
e.g. from qpid-config
-b <address>, --broker=<address>
Address of qpidd broker with syntax:
[username/password@] hostname | ip-address
[:<port>]
I guess there's *plenty* of scope for confusion :-/
To be fair I've just looked at the DOxygen doc for pn_messenger_route
and the examples there mention "amqp://user:password@foo.com".
It might be worth a conversation about the Python tools addressing
convention, perhaps the "/" separator should be deprecated in favour of
the ":" to make things consistent (ducks to avoid the rain of missiles
at such a suggestion ;->)
Thanks again both of you for your help, I'm feeling pretty pleased today!
Frase
On 12/01/14 16:50, Rob Godfrey wrote:
> With the Java broker are you using a username/password (guest/guest should
> work)?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: messenger to qpidd barfs with: ERROR[-2] SASL header mismatch: 'AMQP\x01\x01\x00\x0a'
Posted by Rob Godfrey <ro...@gmail.com>.
With the Java broker are you using a username/password (guest/guest should
work)?
-- Rob
On 12 Jan 2014 17:33, "Fraser Adams" <fr...@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-Store but 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://0.0.0.0/test
>>>
>>> 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://127.0.0.1/test
>>> ./send -a amqp://localhost/test
>>> ./send -a amqp://127.0.0.1
>>>
>>> All fail with the same error.
>>>
>>> When I stand up the recv program instead of qpidd it happily prints out
>>>
>>> Address: amqp://127.0.0.1
>>> 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@0.0.0.0/test
>>>
>>> "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://127.0.0.1/my-queue or amqp://127.0.0.1/amq.fanout). 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
>
>
Re: messenger to qpidd barfs with: ERROR[-2] SASL header mismatch: 'AMQP\x01\x01\x00\x0a'
Posted by Robbie Gemmell <ro...@gmail.com>.
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:
http://qpid.apache.org/releases/qpid-0.24/java-broker/book/Java-Broker-Security.html#Java-Broker-Security-Authentication-Providers
).
Robbie
On 12 January 2014 16:32, Fraser Adams <fr...@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://0.0.0.0/test
>>>
>>> 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://127.0.0.1/test
>>> ./send -a amqp://localhost/test
>>> ./send -a amqp://127.0.0.1
>>>
>>> All fail with the same error.
>>>
>>> When I stand up the recv program instead of qpidd it happily prints out
>>>
>>> Address: amqp://127.0.0.1
>>> 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@0.0.0.0/test
>>>
>>> "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://127.0.0.1/my-queue or amqp://127.0.0.1/amq.fanout). 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
>
>
Re: messenger to qpidd barfs with: ERROR[-2] SASL header mismatch:
'AMQP\x01\x01\x00\x0a'
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
Hi Rafael,
yeah, you probably missed my earlier updates, my problem was that
because of a quirk on trunk that's causing both legacystore.so and
linearstore.so to be installed when I fired up "qpidd --auth no" the
broker failed to start at all, so what I had done was do:
qpidd --auth no --no-module-dir
just to get it started.
Robbie suggested that the "--no-module-dir" might be the problem. I
manually deleted legacystore.so and did
qpidd --auth no
and all is fine, so I didn't need to do "--load-module src/amqp.so " and
explicitly load the module, but explicitly disabling all modules is
clearly bad :-)
So from what I can see 1.0 support does seem to be in a module (it's
installed in /usr/local/lib/qpid/daemon in my system rather than
/usr/local/lib) but that module seems to be loaded by default (at least
when qpidd has been installed via make install) unless explicitly
disabled (well at least that's what I'm inferring from what I'm seeing).
Frase
On 12/01/14 18:16, Rafael Schloming wrote:
> It works for me when I run qpidd from the build directory with the
> following options:
>
> src/qpidd --load-module src/amqp.so
>
> I'm guessing that means 1.0 support is still in a module and you need to
> make sure it is loaded.
>
> --Rafael
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: messenger to qpidd barfs with: ERROR[-2] SASL header mismatch: 'AMQP\x01\x01\x00\x0a'
Posted by Rafael Schloming <rh...@alum.mit.edu>.
It works for me when I run qpidd from the build directory with the
following options:
src/qpidd --load-module src/amqp.so
I'm guessing that means 1.0 support is still in a module and you need to
make sure it is loaded.
--Rafael
On Sun, Jan 12, 2014 at 11:32 AM, 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-Store but 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://0.0.0.0/test
>>>
>>> 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://127.0.0.1/test
>>> ./send -a amqp://localhost/test
>>> ./send -a amqp://127.0.0.1
>>>
>>> All fail with the same error.
>>>
>>> When I stand up the recv program instead of qpidd it happily prints out
>>>
>>> Address: amqp://127.0.0.1
>>> 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@0.0.0.0/test
>>>
>>> "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://127.0.0.1/my-queue or amqp://127.0.0.1/amq.fanout). 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
>
>
Re: messenger to qpidd barfs with: ERROR[-2] SASL header mismatch:
'AMQP\x01\x01\x00\x0a'
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
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-Store
but 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 <fr...@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://0.0.0.0/test
>>
>> 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://127.0.0.1/test
>> ./send -a amqp://localhost/test
>> ./send -a amqp://127.0.0.1
>>
>> All fail with the same error.
>>
>> When I stand up the recv program instead of qpidd it happily prints out
>>
>> Address: amqp://127.0.0.1
>> 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@0.0.0.0/test
>>
>> "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://127.0.0.1/my-queue or amqp://127.0.0.1/amq.fanout). 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
Re: messenger to qpidd barfs with: ERROR[-2] SASL header mismatch: 'AMQP\x01\x01\x00\x0a'
Posted by Robbie Gemmell <ro...@gmail.com>.
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 <fr...@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://0.0.0.0/test
>
> 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://127.0.0.1/test
> ./send -a amqp://localhost/test
> ./send -a amqp://127.0.0.1
>
> All fail with the same error.
>
> When I stand up the recv program instead of qpidd it happily prints out
>
> Address: amqp://127.0.0.1
> 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@0.0.0.0/test
>
> "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://127.0.0.1/my-queue or amqp://127.0.0.1/amq.fanout). 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
>
>