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/08/25 18:37:29 UTC
Java Broker AMQP 1.0 support - is it by default?
Hello,
I've just tried using proton's send example with the Java Broker:
./send -a amqp://guest:guest@localhost/amq.fanout
and I get the helpful response:
[0x21ff810]:ERROR[0] (null)
[0x21ff810]:ERROR[0] (null)
CONNECTION ERROR connection aborted (remote)
I'm pretty sure that I've previously had this working with the Java
Broker but I can't think what I'm doing wrong. I can't remember if
there's something I need to add to the broker config JSON to make it
work with AMQP 1.0, if so what's the incantation I need, if not what am
I doing wrong with send?
Cheers.
Frase
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Java Broker AMQP 1.0 support - is it by default?
Posted by Rob Godfrey <ro...@gmail.com>.
I've raised QPID-6044 and put a change onto trunk which will mean that if
you use an address that resolves to the local machine it will (eventually -
there are lots of DNS lookups involved) decide that you want to connect to
the default virtual host.
I might make a further change to cache the results of this query for the
sake of speeding things up a little... but I'm off to grab some lunch now
:-)
-- Rob
On 26 August 2014 12:37, Rob Godfrey <ro...@gmail.com> wrote:
>
>
>
> On 26 August 2014 12:28, Fraser Adams <fr...@blueyonder.co.uk>
> wrote:
>
>> On 26/08/14 09:50, Rob Godfrey wrote:
>>
>>> So, I ran last night with a virtualhost called localhost and the address
>>> amqp://guest:guest@localhost:5672/amq.fanout and it worked fine...
>>>
>> So *has* this stuff changed then, as I say I'm pretty convinced that I
>> tried the Java broker with Messenger a few months ago and it worked and I'm
>> certainly likely to have had a basic config with a default virtual host
>> named default. I've never needed a "localhost" vhost for anything else -
>> for example with the QMF plugin enabled and I do:
>>
>> qpid-config -b guest/guest@localhost
>> Total Exchanges: 6
>> topic: 2
>> headers: 1
>> fanout: 1
>> direct: 2
>>
>> Total Queues: 1
>> durable: 0
>> non-durable: 1
>>
>> so for AMQP 0.10 from a python client I don't have to have any other
>> config in place (same for the Java QpidConfig) so this only seems to be an
>> issue from AMQP 1.0 (or possibly just from Messenger?)
>>
>>
>>
> AMQP 1.0 defines the open performative as having a hostname field - which
> indicates the "host" the connecting party wishes to attach to. If that
> field is left blank (null or the empty string) then the Java Broker will
> use the default host. Messenger is setting this field to the name of the
> hostname in the address string. This means that when the Java Broker sees
> the open frame it sees a request to use host "localhost", so it looks
> amongst its virtual hosts for said name. I think at some previous point
> the 1.0 implementation could *only* connect to the default virtual host and
> the hostname on the open field was ignored...
>
>
>>
>>
>>> I would suggest creating a virtualhost called localhost
>>>
>>
>> What's the syntax for that? I've tried the following (the second object
>> was what I added - I copied the first object, removed the id and changed
>> the name to localhost), but it doesn't seem to work, though the Broker
>> didn't complain either:
>>
>>
>> "virtualhostnodes" : [ {
>> "context" : {
>> "virtualhostBlueprint" : "{ \"type\" : \"DERBY\", \"storePath\" :
>> \"${qpid.work_dir}/default/messages\" }",
>> "virtualhostBlueprintUtilised" : "true"
>> },
>> "createdBy" : null,
>> "createdTime" : 0,
>> "id" : "13fe911a-2dbb-493e-b652-d3b70013e8d9",
>> "lastUpdatedBy" : null,
>> "lastUpdatedTime" : 1404484979134,
>> "name" : "default",
>> "storePath" : "${qpid.work_dir}/default/config",
>> "type" : "JSON"
>> },
>>
>> {
>> "context" : {
>> "virtualhostBlueprint" : "{ \"type\" : \"DERBY\", \"storePath\" :
>> \"${qpid.work_dir}/default/messages\" }",
>> "virtualhostBlueprintUtilised" : "true"
>> },
>> "createdBy" : null,
>> "createdTime" : 0,
>> "lastUpdatedBy" : null,
>> "lastUpdatedTime" : 1404484979134,
>> "name" : "localhost",
>>
>> "storePath" : "${qpid.work_dir}/default/config",
>> "type" : "JSON"
>> } ]
>>
>>
> So the issue with that (and this really should cause an error) is that
> you've got two virtual host nodes pointing at the same configuration
> file... bad things should really be happening... anyway, if you change the
> instance of ${qpid.work_dir}/default to ${qpid.work_dir}/localhost in the
> localhost section that should work for you.
>
>
>
>> (or just editing
>>> your config file to replace default with localhost if you like).
>>>
>>> For the next release I'm looking to add aliasing to virtualhosts to make
>>> this a little easier, and have the default virtual host initially also
>>> have
>>> aliases of "localhost", "127.0.0.1", etc
>>>
>> That'd be good, but like I say i really am pretty sure that this stuff
>> was actually working a few months ago when I last played with Messenger and
>> the Java Broker
>>
>>
>>
> That may have been back when you could *only* connect to the default
> virtualhost with AMQP 1.0. The issue now is that Messenger is putting the
> DNS / IP host into the host field of open, and unless you have set up the
> Java Broker that way, then that is not really what you want.
>
> -- Rob
>
>
>> Frase
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>>
>
Re: Java Broker AMQP 1.0 support - is it by default?
Posted by Rob Godfrey <ro...@gmail.com>.
On 26 August 2014 16:57, Gordon Sim <gs...@redhat.com> wrote:
> On 08/26/2014 03:41 PM, Rob Godfrey wrote:
>
>> I think the issue here is that the Java Broker doesn't really understand
>> properly what you want to do with the address "amq.fanout" I think it is
>> looking for a binding key for the exchnage... for instance if you tried to
>> receive from the address "amq.fanout/foo" I think it would work.
>> Obviously
>> for the fanout exchange this seems a little odd as the binding key is
>> pretty meaningless - but for other exchange types it is more important.
>>
>
> Does the java broker still support the filter extensions "apache.org:
> legacy-amqp-direct-binding:string" and "apache.org:legacy-amqp-topic-
> binding:string"?
>
>
>
Yes, I believe it does - though these wouldn't apply at a fanout exchange
-- Rob
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: Java Broker AMQP 1.0 support - is it by default?
Posted by Gordon Sim <gs...@redhat.com>.
On 08/26/2014 03:41 PM, Rob Godfrey wrote:
> I think the issue here is that the Java Broker doesn't really understand
> properly what you want to do with the address "amq.fanout" I think it is
> looking for a binding key for the exchnage... for instance if you tried to
> receive from the address "amq.fanout/foo" I think it would work. Obviously
> for the fanout exchange this seems a little odd as the binding key is
> pretty meaningless - but for other exchange types it is more important.
Does the java broker still support the filter extensions
"apache.org:legacy-amqp-direct-binding:string" and
"apache.org:legacy-amqp-topic-binding:string"?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Java Broker AMQP 1.0 support - is it by default?
Posted by Gordon Sim <gs...@redhat.com>.
On 08/26/2014 04:09 PM, Fraser Adams wrote:
> On 26/08/14 15:41, Rob Godfrey wrote:
>> Hi Fraser,
>>
>> I think the issue here is that the Java Broker doesn't really understand
>> properly what you want to do with the address "amq.fanout" I think it is
>> looking for a binding key for the exchnage... for instance if you
>> tried to
>> receive from the address "amq.fanout/foo" I think it would work.
>> Obviously
>> for the fanout exchange this seems a little odd as the binding key is
>> pretty meaningless - but for other exchange types it is more important.
>>
>> I'll raise a JIRA to deal with this case however.
>>
>> -- Rob
>>
>>
> Thanks again for your help so far Rob.
>
> For info
>
> ./recv amqp://guest:guest@localhost/amq.fanout/dummy
>
> with
>
> ./send -a amqp://guest:guest@localhost/amq.fanout
>
>
> seems to work. Yay little victories :-)
>
>
> Next question (and this might be more in Gordon's space) any idea how to
> get spit and drain to play ball? So I try
>
> ./drain --connection-options {protocol:amqp1.0} -b guest/guest@localhost
> -f "amq.fanout"
>
> and I guess unsurprisingly that creates a queue (with no binding) on the
> default vhost
>
> With drain following the previous "pattern" doesn't work either e.g.
>
> ./drain --connection-options {protocol:amqp1.0} -b guest/guest@localhost
> -f "amq.fanout/dummy"
You need to put extra quotes around the node name to prevent the client
trying to interpret the address. E.g.
./drain --connection-options {protocol:amqp1.0} -b guest/guest@localhost
-f "'amq.fanout/dummy'"
> Doesn't create a binding.
>
>
> So not sure for the case of spout/drain with the Java Broker
> a) how to specify a virtual host in the address
qpid::messaging does not at present set the hostname on the open
> b) how to get a binding to amq.fanout created.
>
> Frase
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> 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 AMQP 1.0 support - is it by default?
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
On 26/08/14 17:50, Rob Godfrey wrote:
> Doh - yeah - that was my fault... fixed now I hope,
>
> -- Rob
>
Just updated, seems to be behaving now, I also got
node recv.js amqp://guest:guest@localhost:5673/amq.fanout
node send.js -a amqp://guest:guest@localhost:5673/amq.fanout
working so the JavaScript/WebSocket send and recv behave the same as the
C ones
more little victories, thanks!
Getting the qpid-config.js might be a bit of effort to figure out what's
playing up. I changed the connection URL in the QMF plugin to:
"connectionURL" :
"amqp://guest:guest@/localhost?brokerlist='tcp://0.0.0.0:5672'",
and used the same connectionURL in the QMF GUI and that seems to be
playing nicely with the QMF plugin bound to the "localhost" vhost
but qpid-config.js is currently just hanging :-(
Or rather on the plus side it *is* sending messages to
vhost:localhost/qmf.default.direct and it is creating a subscription
queue on the localhost vhost too, I'll need to dig a bit further to see
what's breaking - I can't see a binding for the subscription queue, but
that might just be because it should be bound to the localhost vhost's
default direct exchange which won't show up in the bindings.
today has made me sad, so I'll probably sleep on it.
Frase
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Java Broker AMQP 1.0 support - is it by default?
Posted by Rob Godfrey <ro...@gmail.com>.
Doh - yeah - that was my fault... fixed now I hope,
-- Rob
On 26 August 2014 17:49, Fraser Adams <fr...@blueyonder.co.uk> wrote:
> On 26/08/14 16:19, Rob Godfrey wrote:
>
>> As an aside, I've just made a change on trunk for QPID-6046 which should
>> allow the address "amqp://guest:guest@localhost/amq.fanout" to work
>>
>> -- Rob
>>
>> I Rob,
> I've just updated to revision 1620634 and rebuild and restarted my broker
> and
> ./recv amqp://guest:guest@localhost/amq.fanout
>
> still doesn't seem to create a binding for me
>
>
> Frase
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: Java Broker AMQP 1.0 support - is it by default?
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
On 26/08/14 16:19, Rob Godfrey wrote:
> As an aside, I've just made a change on trunk for QPID-6046 which should
> allow the address "amqp://guest:guest@localhost/amq.fanout" to work
>
> -- Rob
>
I Rob,
I've just updated to revision 1620634 and rebuild and restarted my
broker and
./recv amqp://guest:guest@localhost/amq.fanout
still doesn't seem to create a binding for me
Frase
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Java Broker AMQP 1.0 support - is it by default?
Posted by Rob Godfrey <ro...@gmail.com>.
As an aside, I've just made a change on trunk for QPID-6046 which should
allow the address "amqp://guest:guest@localhost/amq.fanout" to work
-- Rob
On 26 August 2014 17:09, Fraser Adams <fr...@blueyonder.co.uk> wrote:
> On 26/08/14 15:41, Rob Godfrey wrote:
>
>> Hi Fraser,
>>
>> I think the issue here is that the Java Broker doesn't really understand
>> properly what you want to do with the address "amq.fanout" I think it is
>> looking for a binding key for the exchnage... for instance if you tried to
>> receive from the address "amq.fanout/foo" I think it would work.
>> Obviously
>> for the fanout exchange this seems a little odd as the binding key is
>> pretty meaningless - but for other exchange types it is more important.
>>
>> I'll raise a JIRA to deal with this case however.
>>
>> -- Rob
>>
>>
>> Thanks again for your help so far Rob.
>
> For info
>
> ./recv amqp://guest:guest@localhost/amq.fanout/dummy
>
> with
>
>
> ./send -a amqp://guest:guest@localhost/amq.fanout
>
>
> seems to work. Yay little victories :-)
>
>
> Next question (and this might be more in Gordon's space) any idea how to
> get spit and drain to play ball? So I try
>
> ./drain --connection-options {protocol:amqp1.0} -b guest/guest@localhost
> -f "amq.fanout"
>
> and I guess unsurprisingly that creates a queue (with no binding) on the
> default vhost
>
> With drain following the previous "pattern" doesn't work either e.g.
>
> ./drain --connection-options {protocol:amqp1.0} -b guest/guest@localhost
> -f "amq.fanout/dummy"
>
> Doesn't create a binding.
>
>
> So not sure for the case of spout/drain with the Java Broker
> a) how to specify a virtual host in the address
> b) how to get a binding to amq.fanout created.
>
>
> Frase
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: Java Broker AMQP 1.0 support - is it by default?
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
On 26/08/14 15:41, Rob Godfrey wrote:
> Hi Fraser,
>
> I think the issue here is that the Java Broker doesn't really understand
> properly what you want to do with the address "amq.fanout" I think it is
> looking for a binding key for the exchnage... for instance if you tried to
> receive from the address "amq.fanout/foo" I think it would work. Obviously
> for the fanout exchange this seems a little odd as the binding key is
> pretty meaningless - but for other exchange types it is more important.
>
> I'll raise a JIRA to deal with this case however.
>
> -- Rob
>
>
Thanks again for your help so far Rob.
For info
./recv amqp://guest:guest@localhost/amq.fanout/dummy
with
./send -a amqp://guest:guest@localhost/amq.fanout
seems to work. Yay little victories :-)
Next question (and this might be more in Gordon's space) any idea how to
get spit and drain to play ball? So I try
./drain --connection-options {protocol:amqp1.0} -b guest/guest@localhost
-f "amq.fanout"
and I guess unsurprisingly that creates a queue (with no binding) on the
default vhost
With drain following the previous "pattern" doesn't work either e.g.
./drain --connection-options {protocol:amqp1.0} -b guest/guest@localhost
-f "amq.fanout/dummy"
Doesn't create a binding.
So not sure for the case of spout/drain with the Java Broker
a) how to specify a virtual host in the address
b) how to get a binding to amq.fanout created.
Frase
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Java Broker AMQP 1.0 support - is it by default?
Posted by Rob Godfrey <ro...@gmail.com>.
Hi Fraser,
I think the issue here is that the Java Broker doesn't really understand
properly what you want to do with the address "amq.fanout" I think it is
looking for a binding key for the exchnage... for instance if you tried to
receive from the address "amq.fanout/foo" I think it would work. Obviously
for the fanout exchange this seems a little odd as the binding key is
pretty meaningless - but for other exchange types it is more important.
I'll raise a JIRA to deal with this case however.
-- Rob
On 26 August 2014 15:40, Fraser Adams <fr...@blueyonder.co.uk> wrote:
> On 26/08/14 13:46, Rob Godfrey wrote:
>
>> To be honest rather than messing around in the config file, it's much
>> easier just to open up the built in web management console and add the
>> virtual host from there...
>>
>> I did begin to wonder that, but I figured I was *trying* to do something
> that should be pretty simple really and slowly losing my marbles in the
> process :-(
>
> I surely can't be the only person who has tried to get Messenger to talk
> to the Java Broker???
>
>
> Good news is that I appear to be making a little progress, so thanks for
> the help so far.
>
> ./send -a amqp://guest:guest@localhost/amq.fanout
>
> Now appears to work and I've fired up the QMF GUI and can see an exchange
> labelled vhost:localhost/amq.fanout and that has msgReceives incrementing
> each time I do send (BTW in case you are wondering the vhost:localhost/ bit
> is added by the QMF plugin I took the approach of prefixing the name so
> that basic CLI tools like qpid-config that aren't vhost aware could see
> different vhost info without requiring changes) e.g.
> qpid-config -b guest/guest@localhost exchanges
> Type Exchange Name Attributes
> =================================================================
> direct amq.direct --durable
> fanout amq.fanout --durable
> headers amq.match --durable
> topic amq.topic --durable
> direct qmf.default.direct --durable
> topic qmf.default.topic --durable
> direct vhost:localhost/amq.direct --durable
> fanout vhost:localhost/amq.fanout --durable
> headers vhost:localhost/amq.match --durable
> topic vhost:localhost/amq.topic --durable
> direct vhost:localhost/qmf.default.direct --durable
> topic vhost:localhost/qmf.default.topic --durable
>
>
> My next issue is that I can't actually seem to receive the messages I've
> just added :o) I tried:
> ./recv amqp://guest:guest@localhost/amq.fanout
>
> But I'm not getting any messages. That call does successfully connect and
> moreover it actually creates a subscription queue (shown in the QMF GUI -
> and qpid-config - as vhost:localhost/d905aa40-eb45-4f5a-a949-54f5652dd279)
> but there are no bindings being created.
>
>
>
> Definitely much fun to be had between Messenger, Java Broker and vhosts :->
>
> I've go a bad feeling this is only the tip of the iceberg, why I'm
> actually trying all this is 'cause I want to try my JavaScript port of
> qpid-config that uses my JavaScript port of Messenger (I'm not at all
> ambitious :-D) it actually works perfectly with the C++ broker (via my
> WebSocket->TCP Socket proxy) so figured it might be good to try it using
> the Java Broker's WebSocket transport. I'm going to run into more trouble
> 'cause the QMF plugin uses the default vhost.
>
>
> The aliasing stuff you talked about should make all this a lot less
> mind-melting, but in a funny sort of way it's probably good to be noting
> these issues.
>
>
> Frase
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: Java Broker AMQP 1.0 support - is it by default?
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
On 26/08/14 13:46, Rob Godfrey wrote:
> To be honest rather than messing around in the config file, it's much
> easier just to open up the built in web management console and add the
> virtual host from there...
>
I did begin to wonder that, but I figured I was *trying* to do something
that should be pretty simple really and slowly losing my marbles in the
process :-(
I surely can't be the only person who has tried to get Messenger to talk
to the Java Broker???
Good news is that I appear to be making a little progress, so thanks for
the help so far.
./send -a amqp://guest:guest@localhost/amq.fanout
Now appears to work and I've fired up the QMF GUI and can see an
exchange labelled vhost:localhost/amq.fanout and that has msgReceives
incrementing each time I do send (BTW in case you are wondering the
vhost:localhost/ bit is added by the QMF plugin I took the approach of
prefixing the name so that basic CLI tools like qpid-config that aren't
vhost aware could see different vhost info without requiring changes) e.g.
qpid-config -b guest/guest@localhost exchanges
Type Exchange Name Attributes
=================================================================
direct amq.direct --durable
fanout amq.fanout --durable
headers amq.match --durable
topic amq.topic --durable
direct qmf.default.direct --durable
topic qmf.default.topic --durable
direct vhost:localhost/amq.direct --durable
fanout vhost:localhost/amq.fanout --durable
headers vhost:localhost/amq.match --durable
topic vhost:localhost/amq.topic --durable
direct vhost:localhost/qmf.default.direct --durable
topic vhost:localhost/qmf.default.topic --durable
My next issue is that I can't actually seem to receive the messages I've
just added :o) I tried:
./recv amqp://guest:guest@localhost/amq.fanout
But I'm not getting any messages. That call does successfully connect
and moreover it actually creates a subscription queue (shown in the QMF
GUI - and qpid-config - as
vhost:localhost/d905aa40-eb45-4f5a-a949-54f5652dd279) but there are no
bindings being created.
Definitely much fun to be had between Messenger, Java Broker and vhosts :->
I've go a bad feeling this is only the tip of the iceberg, why I'm
actually trying all this is 'cause I want to try my JavaScript port of
qpid-config that uses my JavaScript port of Messenger (I'm not at all
ambitious :-D) it actually works perfectly with the C++ broker (via my
WebSocket->TCP Socket proxy) so figured it might be good to try it using
the Java Broker's WebSocket transport. I'm going to run into more
trouble 'cause the QMF plugin uses the default vhost.
The aliasing stuff you talked about should make all this a lot less
mind-melting, but in a funny sort of way it's probably good to be noting
these issues.
Frase
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Java Broker AMQP 1.0 support - is it by default?
Posted by Rob Godfrey <ro...@gmail.com>.
So why you didn't get the default exchange created is probably this part:
"context" : {
"virtualhostBlueprint" : "{ \"type\" : \"DERBY\" }",
"virtualhostBlueprintUtilised" : "true"
},
Without going into ridiculous levels of detail, basically that second
context variable being set to true means "I've set up all the configuration
for this virtual host - you don't need to do it again".
To be honest rather than messing around in the config file, it's much
easier just to open up the built in web management console and add the
virtual host from there...
(Alternatively if you are using trunk you could follow the instructions
given on this Jira: https://issues.apache.org/jira/browse/QPID-6036 about
using curl to extract and replay config (note that you'll either need to
use ssl, or enable basic authentication over non SSL connections - which
again can be done through the UI) (also not that if doing this you'd need
to update the name before uploading the config)).
-- Rob
On 26 August 2014 14:38, Fraser Adams <fr...@blueyonder.co.uk> wrote:
> Hi again Rob,
> Sorry for yet another post .....
>
> Firstly thanks very much for the answer around "
>
>
> I think at some previous point
> the 1.0 implementation could *only* connect to the default virtual host and
> the hostname on the open field was ignored...
>
> "
>
> That makes sense, TBH I was starting to question my sanity there, and I
> was already on pretty thin ground :o) .........
>
>
> Secondly on the point: "
>
>
> you've got two virtual host nodes pointing at the same configuration
> file... bad things should really be happening
>
> "
> Yeah I spotted that one myself and replaced the "default" with "localhost"
> in the second vhost object, however I'm afraid that I still had no joy with:
>
> ./send -a amqp://guest:guest@localhost/amq.fanout
>
> CONNECTION ERROR (amqp:not-found) Unknown hostname localhost
>
>
>
> There always seems to be some tweaks of config.json between versions, so I
> ended up going back to basics and deleted my config.json letting the Broker
> create a fresh one and then added my QMF/WebSocket/etc. config. to that
>
> However when I added a new "localhost" vhost to that I still get the same
> error :-(
>
> ./send -a amqp://guest:guest@localhost/amq.fanout
> CONNECTION ERROR (amqp:not-found) Unknown hostname localhost
>
>
> I've attached my most recent config.json, I don't suppose you could take a
> look and let me know what I've messed up.
>
> I am seeing a "localhost" subdirectory appearing in my qpid-work
>
>
> probably unrelated at the start of my qpid.log I see
> 2014-08-26 13:15:19,289 WARN [main] (model.ConfiguredObjectTypeRegistry)
> - A class definition could not be found while processing the model for
> 'org.apache.qpid.server.virtualhostnode.berkeleydb.BDBHAVirtualHostNodeImpl':
> com/sleepycat/je/rep/StateChangeListener
> 2014-08-26 13:15:19,369 WARN [main] (model.ConfiguredObjectTypeRegistry)
> - A class definition could not be found while processing the model for
> 'org.apache.qpid.server.virtualhost.berkeleydb.BDBHAVirtualHostImpl':
> com/sleepycat/je/rep/StateChangeListener
>
> Which suggests that something isn't being included in the packaged broker
> assembly, I'm just using the tar.gz from the main Maven build so I doubt
> it's anything I've failed to set up.
>
>
>
> Stop Press....
> Another thing, when I looked at qpid-work/default/config/default.json it
> contains a bunch of exchanges, whereas qpid-work/localhost/config/localhost.json
> is empty
>
> When I copied default.json to localhost.json and changed the name inside
> to "localhost" I *finally* got
>
> ./send -a amqp://guest:guest@localhost/amq.fanout
>
> to run without the error, so I may be making progress, but when I added
> the "localhost" vhost shouldn't that localhost.json be automatically
> populated with exchanges in the same way that the default.json was?
>
>
> Ta!
> Frase
>
>
>
> On 26/08/14 11:37, Rob Godfrey wrote:
>
>> On 26 August 2014 12:28, Fraser Adams <fr...@blueyonder.co.uk>
>> wrote:
>>
>> On 26/08/14 09:50, Rob Godfrey wrote:
>>>
>>> So, I ran last night with a virtualhost called localhost and the address
>>>> amqp://guest:guest@localhost:5672/amq.fanout and it worked fine...
>>>>
>>>> So *has* this stuff changed then, as I say I'm pretty convinced that I
>>> tried the Java broker with Messenger a few months ago and it worked and
>>> I'm
>>> certainly likely to have had a basic config with a default virtual host
>>> named default. I've never needed a "localhost" vhost for anything else -
>>> for example with the QMF plugin enabled and I do:
>>>
>>> qpid-config -b guest/guest@localhost
>>> Total Exchanges: 6
>>> topic: 2
>>> headers: 1
>>> fanout: 1
>>> direct: 2
>>>
>>> Total Queues: 1
>>> durable: 0
>>> non-durable: 1
>>>
>>> so for AMQP 0.10 from a python client I don't have to have any other
>>> config in place (same for the Java QpidConfig) so this only seems to be
>>> an
>>> issue from AMQP 1.0 (or possibly just from Messenger?)
>>>
>>>
>>>
>>> AMQP 1.0 defines the open performative as having a hostname field -
>> which
>> indicates the "host" the connecting party wishes to attach to. If that
>> field is left blank (null or the empty string) then the Java Broker will
>> use the default host. Messenger is setting this field to the name of the
>> hostname in the address string. This means that when the Java Broker sees
>> the open frame it sees a request to use host "localhost", so it looks
>> amongst its virtual hosts for said name. I think at some previous point
>> the 1.0 implementation could *only* connect to the default virtual host
>> and
>> the hostname on the open field was ignored...
>>
>>
>>
>>> I would suggest creating a virtualhost called localhost
>>>>
>>>> What's the syntax for that? I've tried the following (the second object
>>> was what I added - I copied the first object, removed the id and changed
>>> the name to localhost), but it doesn't seem to work, though the Broker
>>> didn't complain either:
>>>
>>>
>>> "virtualhostnodes" : [ {
>>> "context" : {
>>> "virtualhostBlueprint" : "{ \"type\" : \"DERBY\", \"storePath\" :
>>> \"${qpid.work_dir}/default/messages\" }",
>>> "virtualhostBlueprintUtilised" : "true"
>>> },
>>> "createdBy" : null,
>>> "createdTime" : 0,
>>> "id" : "13fe911a-2dbb-493e-b652-d3b70013e8d9",
>>> "lastUpdatedBy" : null,
>>> "lastUpdatedTime" : 1404484979134,
>>> "name" : "default",
>>> "storePath" : "${qpid.work_dir}/default/config",
>>> "type" : "JSON"
>>> },
>>>
>>> {
>>> "context" : {
>>> "virtualhostBlueprint" : "{ \"type\" : \"DERBY\", \"storePath\" :
>>> \"${qpid.work_dir}/default/messages\" }",
>>> "virtualhostBlueprintUtilised" : "true"
>>> },
>>> "createdBy" : null,
>>> "createdTime" : 0,
>>> "lastUpdatedBy" : null,
>>> "lastUpdatedTime" : 1404484979134,
>>> "name" : "localhost",
>>>
>>> "storePath" : "${qpid.work_dir}/default/config",
>>> "type" : "JSON"
>>> } ]
>>>
>>>
>>> So the issue with that (and this really should cause an error) is that
>> you've got two virtual host nodes pointing at the same configuration
>> file... bad things should really be happening... anyway, if you change the
>> instance of ${qpid.work_dir}/default to ${qpid.work_dir}/localhost in the
>> localhost section that should work for you.
>>
>>
>>
>> (or just editing
>>>
>>>> your config file to replace default with localhost if you like).
>>>>
>>>> For the next release I'm looking to add aliasing to virtualhosts to make
>>>> this a little easier, and have the default virtual host initially also
>>>> have
>>>> aliases of "localhost", "127.0.0.1", etc
>>>>
>>>> That'd be good, but like I say i really am pretty sure that this stuff
>>> was
>>> actually working a few months ago when I last played with Messenger and
>>> the
>>> Java Broker
>>>
>>>
>>>
>>> That may have been back when you could *only* connect to the default
>> virtualhost with AMQP 1.0. The issue now is that Messenger is putting the
>> DNS / IP host into the host field of open, and unless you have set up the
>> Java Broker that way, then that is not really what you want.
>>
>> -- Rob
>>
>>
>> Frase
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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 AMQP 1.0 support - is it by default?
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
Hi again Rob,
Sorry for yet another post .....
Firstly thanks very much for the answer around "
I think at some previous point
the 1.0 implementation could *only* connect to the default virtual host and
the hostname on the open field was ignored...
"
That makes sense, TBH I was starting to question my sanity there, and I
was already on pretty thin ground :o) .........
Secondly on the point: "
you've got two virtual host nodes pointing at the same configuration
file... bad things should really be happening
"
Yeah I spotted that one myself and replaced the "default" with
"localhost" in the second vhost object, however I'm afraid that I still
had no joy with:
./send -a amqp://guest:guest@localhost/amq.fanout
CONNECTION ERROR (amqp:not-found) Unknown hostname localhost
There always seems to be some tweaks of config.json between versions, so
I ended up going back to basics and deleted my config.json letting the
Broker create a fresh one and then added my QMF/WebSocket/etc. config.
to that
However when I added a new "localhost" vhost to that I still get the
same error :-(
./send -a amqp://guest:guest@localhost/amq.fanout
CONNECTION ERROR (amqp:not-found) Unknown hostname localhost
I've attached my most recent config.json, I don't suppose you could take
a look and let me know what I've messed up.
I am seeing a "localhost" subdirectory appearing in my qpid-work
probably unrelated at the start of my qpid.log I see
2014-08-26 13:15:19,289 WARN [main]
(model.ConfiguredObjectTypeRegistry) - A class definition could not be
found while processing the model for
'org.apache.qpid.server.virtualhostnode.berkeleydb.BDBHAVirtualHostNodeImpl':
com/sleepycat/je/rep/StateChangeListener
2014-08-26 13:15:19,369 WARN [main]
(model.ConfiguredObjectTypeRegistry) - A class definition could not be
found while processing the model for
'org.apache.qpid.server.virtualhost.berkeleydb.BDBHAVirtualHostImpl':
com/sleepycat/je/rep/StateChangeListener
Which suggests that something isn't being included in the packaged
broker assembly, I'm just using the tar.gz from the main Maven build so
I doubt it's anything I've failed to set up.
Stop Press....
Another thing, when I looked at qpid-work/default/config/default.json it
contains a bunch of exchanges, whereas
qpid-work/localhost/config/localhost.json is empty
When I copied default.json to localhost.json and changed the name inside
to "localhost" I *finally* got
./send -a amqp://guest:guest@localhost/amq.fanout
to run without the error, so I may be making progress, but when I added
the "localhost" vhost shouldn't that localhost.json be automatically
populated with exchanges in the same way that the default.json was?
Ta!
Frase
On 26/08/14 11:37, Rob Godfrey wrote:
> On 26 August 2014 12:28, Fraser Adams <fr...@blueyonder.co.uk> wrote:
>
>> On 26/08/14 09:50, Rob Godfrey wrote:
>>
>>> So, I ran last night with a virtualhost called localhost and the address
>>> amqp://guest:guest@localhost:5672/amq.fanout and it worked fine...
>>>
>> So *has* this stuff changed then, as I say I'm pretty convinced that I
>> tried the Java broker with Messenger a few months ago and it worked and I'm
>> certainly likely to have had a basic config with a default virtual host
>> named default. I've never needed a "localhost" vhost for anything else -
>> for example with the QMF plugin enabled and I do:
>>
>> qpid-config -b guest/guest@localhost
>> Total Exchanges: 6
>> topic: 2
>> headers: 1
>> fanout: 1
>> direct: 2
>>
>> Total Queues: 1
>> durable: 0
>> non-durable: 1
>>
>> so for AMQP 0.10 from a python client I don't have to have any other
>> config in place (same for the Java QpidConfig) so this only seems to be an
>> issue from AMQP 1.0 (or possibly just from Messenger?)
>>
>>
>>
> AMQP 1.0 defines the open performative as having a hostname field - which
> indicates the "host" the connecting party wishes to attach to. If that
> field is left blank (null or the empty string) then the Java Broker will
> use the default host. Messenger is setting this field to the name of the
> hostname in the address string. This means that when the Java Broker sees
> the open frame it sees a request to use host "localhost", so it looks
> amongst its virtual hosts for said name. I think at some previous point
> the 1.0 implementation could *only* connect to the default virtual host and
> the hostname on the open field was ignored...
>
>
>>
>>> I would suggest creating a virtualhost called localhost
>>>
>> What's the syntax for that? I've tried the following (the second object
>> was what I added - I copied the first object, removed the id and changed
>> the name to localhost), but it doesn't seem to work, though the Broker
>> didn't complain either:
>>
>>
>> "virtualhostnodes" : [ {
>> "context" : {
>> "virtualhostBlueprint" : "{ \"type\" : \"DERBY\", \"storePath\" :
>> \"${qpid.work_dir}/default/messages\" }",
>> "virtualhostBlueprintUtilised" : "true"
>> },
>> "createdBy" : null,
>> "createdTime" : 0,
>> "id" : "13fe911a-2dbb-493e-b652-d3b70013e8d9",
>> "lastUpdatedBy" : null,
>> "lastUpdatedTime" : 1404484979134,
>> "name" : "default",
>> "storePath" : "${qpid.work_dir}/default/config",
>> "type" : "JSON"
>> },
>>
>> {
>> "context" : {
>> "virtualhostBlueprint" : "{ \"type\" : \"DERBY\", \"storePath\" :
>> \"${qpid.work_dir}/default/messages\" }",
>> "virtualhostBlueprintUtilised" : "true"
>> },
>> "createdBy" : null,
>> "createdTime" : 0,
>> "lastUpdatedBy" : null,
>> "lastUpdatedTime" : 1404484979134,
>> "name" : "localhost",
>>
>> "storePath" : "${qpid.work_dir}/default/config",
>> "type" : "JSON"
>> } ]
>>
>>
> So the issue with that (and this really should cause an error) is that
> you've got two virtual host nodes pointing at the same configuration
> file... bad things should really be happening... anyway, if you change the
> instance of ${qpid.work_dir}/default to ${qpid.work_dir}/localhost in the
> localhost section that should work for you.
>
>
>
>> (or just editing
>>> your config file to replace default with localhost if you like).
>>>
>>> For the next release I'm looking to add aliasing to virtualhosts to make
>>> this a little easier, and have the default virtual host initially also
>>> have
>>> aliases of "localhost", "127.0.0.1", etc
>>>
>> That'd be good, but like I say i really am pretty sure that this stuff was
>> actually working a few months ago when I last played with Messenger and the
>> Java Broker
>>
>>
>>
> That may have been back when you could *only* connect to the default
> virtualhost with AMQP 1.0. The issue now is that Messenger is putting the
> DNS / IP host into the host field of open, and unless you have set up the
> Java Broker that way, then that is not really what you want.
>
> -- Rob
>
>
>> Frase
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>>
Re: Java Broker AMQP 1.0 support - is it by default?
Posted by Rob Godfrey <ro...@gmail.com>.
On 26 August 2014 12:28, Fraser Adams <fr...@blueyonder.co.uk> wrote:
> On 26/08/14 09:50, Rob Godfrey wrote:
>
>> So, I ran last night with a virtualhost called localhost and the address
>> amqp://guest:guest@localhost:5672/amq.fanout and it worked fine...
>>
> So *has* this stuff changed then, as I say I'm pretty convinced that I
> tried the Java broker with Messenger a few months ago and it worked and I'm
> certainly likely to have had a basic config with a default virtual host
> named default. I've never needed a "localhost" vhost for anything else -
> for example with the QMF plugin enabled and I do:
>
> qpid-config -b guest/guest@localhost
> Total Exchanges: 6
> topic: 2
> headers: 1
> fanout: 1
> direct: 2
>
> Total Queues: 1
> durable: 0
> non-durable: 1
>
> so for AMQP 0.10 from a python client I don't have to have any other
> config in place (same for the Java QpidConfig) so this only seems to be an
> issue from AMQP 1.0 (or possibly just from Messenger?)
>
>
>
AMQP 1.0 defines the open performative as having a hostname field - which
indicates the "host" the connecting party wishes to attach to. If that
field is left blank (null or the empty string) then the Java Broker will
use the default host. Messenger is setting this field to the name of the
hostname in the address string. This means that when the Java Broker sees
the open frame it sees a request to use host "localhost", so it looks
amongst its virtual hosts for said name. I think at some previous point
the 1.0 implementation could *only* connect to the default virtual host and
the hostname on the open field was ignored...
>
>
>> I would suggest creating a virtualhost called localhost
>>
>
> What's the syntax for that? I've tried the following (the second object
> was what I added - I copied the first object, removed the id and changed
> the name to localhost), but it doesn't seem to work, though the Broker
> didn't complain either:
>
>
> "virtualhostnodes" : [ {
> "context" : {
> "virtualhostBlueprint" : "{ \"type\" : \"DERBY\", \"storePath\" :
> \"${qpid.work_dir}/default/messages\" }",
> "virtualhostBlueprintUtilised" : "true"
> },
> "createdBy" : null,
> "createdTime" : 0,
> "id" : "13fe911a-2dbb-493e-b652-d3b70013e8d9",
> "lastUpdatedBy" : null,
> "lastUpdatedTime" : 1404484979134,
> "name" : "default",
> "storePath" : "${qpid.work_dir}/default/config",
> "type" : "JSON"
> },
>
> {
> "context" : {
> "virtualhostBlueprint" : "{ \"type\" : \"DERBY\", \"storePath\" :
> \"${qpid.work_dir}/default/messages\" }",
> "virtualhostBlueprintUtilised" : "true"
> },
> "createdBy" : null,
> "createdTime" : 0,
> "lastUpdatedBy" : null,
> "lastUpdatedTime" : 1404484979134,
> "name" : "localhost",
>
> "storePath" : "${qpid.work_dir}/default/config",
> "type" : "JSON"
> } ]
>
>
So the issue with that (and this really should cause an error) is that
you've got two virtual host nodes pointing at the same configuration
file... bad things should really be happening... anyway, if you change the
instance of ${qpid.work_dir}/default to ${qpid.work_dir}/localhost in the
localhost section that should work for you.
> (or just editing
>> your config file to replace default with localhost if you like).
>>
>> For the next release I'm looking to add aliasing to virtualhosts to make
>> this a little easier, and have the default virtual host initially also
>> have
>> aliases of "localhost", "127.0.0.1", etc
>>
> That'd be good, but like I say i really am pretty sure that this stuff was
> actually working a few months ago when I last played with Messenger and the
> Java Broker
>
>
>
That may have been back when you could *only* connect to the default
virtualhost with AMQP 1.0. The issue now is that Messenger is putting the
DNS / IP host into the host field of open, and unless you have set up the
Java Broker that way, then that is not really what you want.
-- Rob
> Frase
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: Java Broker AMQP 1.0 support - is it by default?
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
On 26/08/14 09:50, Rob Godfrey wrote:
> So, I ran last night with a virtualhost called localhost and the address
> amqp://guest:guest@localhost:5672/amq.fanout and it worked fine...
So *has* this stuff changed then, as I say I'm pretty convinced that I
tried the Java broker with Messenger a few months ago and it worked and
I'm certainly likely to have had a basic config with a default virtual
host named default. I've never needed a "localhost" vhost for anything
else - for example with the QMF plugin enabled and I do:
qpid-config -b guest/guest@localhost
Total Exchanges: 6
topic: 2
headers: 1
fanout: 1
direct: 2
Total Queues: 1
durable: 0
non-durable: 1
so for AMQP 0.10 from a python client I don't have to have any other
config in place (same for the Java QpidConfig) so this only seems to be
an issue from AMQP 1.0 (or possibly just from Messenger?)
>
> I would suggest creating a virtualhost called localhost
What's the syntax for that? I've tried the following (the second object
was what I added - I copied the first object, removed the id and changed
the name to localhost), but it doesn't seem to work, though the Broker
didn't complain either:
"virtualhostnodes" : [ {
"context" : {
"virtualhostBlueprint" : "{ \"type\" : \"DERBY\", \"storePath\" :
\"${qpid.work_dir}/default/messages\" }",
"virtualhostBlueprintUtilised" : "true"
},
"createdBy" : null,
"createdTime" : 0,
"id" : "13fe911a-2dbb-493e-b652-d3b70013e8d9",
"lastUpdatedBy" : null,
"lastUpdatedTime" : 1404484979134,
"name" : "default",
"storePath" : "${qpid.work_dir}/default/config",
"type" : "JSON"
},
{
"context" : {
"virtualhostBlueprint" : "{ \"type\" : \"DERBY\", \"storePath\" :
\"${qpid.work_dir}/default/messages\" }",
"virtualhostBlueprintUtilised" : "true"
},
"createdBy" : null,
"createdTime" : 0,
"lastUpdatedBy" : null,
"lastUpdatedTime" : 1404484979134,
"name" : "localhost",
"storePath" : "${qpid.work_dir}/default/config",
"type" : "JSON"
} ]
> (or just editing
> your config file to replace default with localhost if you like).
>
> For the next release I'm looking to add aliasing to virtualhosts to make
> this a little easier, and have the default virtual host initially also have
> aliases of "localhost", "127.0.0.1", etc
That'd be good, but like I say i really am pretty sure that this stuff
was actually working a few months ago when I last played with Messenger
and the Java Broker
Frase
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Java Broker AMQP 1.0 support - is it by default?
Posted by Rob Godfrey <ro...@gmail.com>.
Ah - the NPE is because Proton sends stuff without waiting for a reply, and
the Java Broker is not ignoring data that has been sent after it has
already decided to close the connection (because the vhost doesn't exist).
Your underlying problem is the vhost one, when I send without the vhost
"localhost" being set up I see:
./send -a amqp://guest:guest@localhost/amq.fanout
CONNECTION ERROR (amqp:not-found) Unknown hostname localhost
And then the NPE in the broker logs. The broker error can be ignored,
though I'll raise a JIRA to fix the underlying issue.
-- Rob
On 26 August 2014 10:50, Rob Godfrey <ro...@gmail.com> wrote:
> So, I ran last night with a virtualhost called localhost and the address
> amqp://guest:guest@localhost:5672/amq.fanout and it worked fine... (I
> also got it working with SSL - I think my mistake previously was forgetting
> that messenger would try to connect to port 5671 for amqps)
>
> Unfortunately that line in Session_1_0 is a horrible compound statement
>
> linkRegistry =
> getVirtualHost().getLinkRegistry(endpoint.getSession().getConnection().getRemoteContainerId());
>
> so it's a little hard to guess which particular thing is null - but it's
> probably the virtual host.
>
> I would suggest creating a virtualhost called localhost (or just editing
> your config file to replace default with localhost if you like).
>
> For the next release I'm looking to add aliasing to virtualhosts to make
> this a little easier, and have the default virtual host initially also have
> aliases of "localhost", "127.0.0.1", etc
>
> -- Rob
>
>
>
>
>
> On 26 August 2014 10:27, Fraser Adams <fr...@blueyonder.co.uk>
> wrote:
>
>> Hey Rob,
>> Thanks for the responses, some more info. I added: "secureOnlyMechanisms"
>> : [],
>>
>> so my password file authentication provider section looks like this:
>>
>>
>> "authenticationproviders" : [ {
>> "id" : "cf7bd327-ec0f-4917-bd27-d033e49a23fb",
>>
>> "name" : "passwordFile",
>> "secureOnlyMechanisms" : [],
>> "path" : "${qpid.home_dir}/etc/passwd",
>> "preferencesproviders" : [ {
>> "id" : "50b2fd82-d002-462d-9e65-4230328b8b63",
>>
>> "name" : "fileSystemPreferences",
>> "path" : "${qpid.work_dir}/user.preferences.json",
>> "type" : "FileSystemPreferences"
>> } ],
>> "type" : "PlainPasswordFile"
>> } ],
>>
>>
>> I tried again with:
>> ./send -a amqp://guest:guest@localhost:5672/amq.fanout
>>
>> and the error is now saying:
>> CONNECTION ERROR (amqp:not-found) Unknown hostname localhost (which
>> probably points to your virtualhost comment), however when I did that the
>> Broker errored with an NPE:
>>
>>
>>
>>
>> 00 53 12 d0 00 00 00 5f 00 00 00 0a a1 0a 73 65 6e
>> 64 65 72 2d 78 78 78 52 00 42 50 02 50 00 00 53 28
>> d0 00 00 00 1c 00 00 00 0b a1 0a 61 6d 71 2e 66 61
>> 6e 6f 75 74 52 00 40 52 00 42 40 40 40 40 40 40 00
>> 53 29 d0 00 00 00 18 00 00 00 07 a1 0a 61 6d 71 2e
>> 66 61 6e 6f 75 74 52 00 40 52 00 42 40 40 40 40 52
>> 00
>> java.lang.NullPointerException
>> at org.apache.qpid.server.protocol.v1_0.Session_1_0.
>> remoteLinkCreation(Session_1_0.java:134)
>> at org.apache.qpid.server.protocol.v1_0.Connection_1_0$
>> 2$1.run(Connection_1_0.java:172)
>> at java.security.AccessController.doPrivileged(Native Method)
>> at javax.security.auth.Subject.doAs(Subject.java:356)
>> at org.apache.qpid.server.protocol.v1_0.Connection_1_0$
>> 2.remoteLinkCreation(Connection_1_0.java:167)
>> at org.apache.qpid.amqp_1_0.transport.SessionEndpoint.
>> receiveAttach(SessionEndpoint.java:300)
>> at org.apache.qpid.amqp_1_0.transport.ConnectionEndpoint.
>> receiveAttach(ConnectionEndpoint.java:633)
>> at org.apache.qpid.amqp_1_0.type.transport.Attach.invoke(
>> Attach.java:352)
>> at org.apache.qpid.amqp_1_0.transport.ConnectionEndpoint.
>> receive(ConnectionEndpoint.java:802)
>> at org.apache.qpid.amqp_1_0.framing.FrameHandler.parse(
>> FrameHandler.java:242)
>> at org.apache.qpid.amqp_1_0.framing.AMQPProtocolHeaderHandler.parse(
>> AMQPProtocolHeaderHandler.java:72)
>> at org.apache.qpid.amqp_1_0.codec.ProtocolHeaderHandler.
>> parse(ProtocolHeaderHandler.java:107)
>> at org.apache.qpid.server.protocol.v1_0.ProtocolEngine_
>> 1_0_0_SASL$4.run(ProtocolEngine_1_0_0_SASL.java:383)
>> at org.apache.qpid.server.protocol.v1_0.ProtocolEngine_
>> 1_0_0_SASL$4.run(ProtocolEngine_1_0_0_SASL.java:379)
>> at java.security.AccessController.doPrivileged(Native Method)
>> at javax.security.auth.Subject.doAs(Subject.java:356)
>> at org.apache.qpid.server.protocol.v1_0.ProtocolEngine_
>> 1_0_0_SASL.received(ProtocolEngine_1_0_0_SASL.java:378)
>> at org.apache.qpid.server.protocol.v1_0.ProtocolEngine_
>> 1_0_0_SASL.received(ProtocolEngine_1_0_0_SASL.java:65)
>> at org.apache.qpid.server.protocol.MultiVersionProtocolEngine.
>> received(MultiVersionProtocolEngine.java:133)
>> at org.apache.qpid.server.protocol.MultiVersionProtocolEngine.
>> received(MultiVersionProtocolEngine.java:49)
>> at org.apache.qpid.transport.network.io.IoReceiver.run(
>> IoReceiver.java:161)
>> at java.lang.Thread.run(Thread.java:722)
>>
>>
>>
>> following up on the virtualhost train of thought I tried:
>>
>> ./send -a amqp://guest:guest@/localhost:5672/amq.fanout
>>
>> and
>>
>> ./send -a amqp://guest:guest@default/localhost:5672/amq.fanout
>>
>>
>> My default virtual host is default:
>>
>> "defaultVirtualHost" : "default",
>>
>> .....
>> and
>>
>> "virtualhostnodes" : [ {
>> "context" : {
>> "virtualhostBlueprint" : "{ \"type\" : \"DERBY\", \"storePath\" :
>> \"${qpid.work_dir}/default/messages\" }",
>> "virtualhostBlueprintUtilised" : "true"
>> },
>> "createdBy" : null,
>> "createdTime" : 0,
>> "id" : "13fe911a-2dbb-493e-b652-d3b70013e8d9",
>> "lastUpdatedBy" : null,
>> "lastUpdatedTime" : 1404484979134,
>> "name" : "default",
>> "storePath" : "${qpid.work_dir}/default/config",
>> "type" : "JSON"
>> } ]
>>
>>
>>
>> Has this stuff changed recently, clearly the disabling plain
>> authentication has, but not so sure about any virtual host stuff. I really
>> am pretty sure that I tried the basic
>> ./send -a amqp://guest:guest@localhost:5672/amq.fanout
>>
>> a couple of months ago and it worked fine???
>>
>> Frase
>>
>>
>>
>>
>>
>>
>> On 25/08/14 20:22, Rob Godfrey wrote:
>>
>>> OK - there's that issue... and then there is an authentication problem.
>>> Namely that on trunk the Java Broker does not offer PLAIN
>>> authentication
>>> over non-SSL ports by default. It offers CRAM-MD5, SCRAM-SHA1 and
>>> SCRAM-SHA256... but I'm presuming the messenger client doesn't yet
>>> implement any of these.
>>>
>>> Connecting over SSL should work... but I wan't having any success with
>>> that
>>> either - which warrants investigation.
>>>
>>> However, to reenable PLAIN authentication on non-secure connections add
>>> the
>>> attribute/value pair
>>>
>>> "secureOnlyMechanisms" : [],
>>>
>>> into the configuration for you authentication provider in your
>>> config.json.
>>>
>>> As an example, my password file authentication provider section looks
>>> like
>>> this:
>>>
>>> {
>>>
>>> "id" : "ef78d9a3-7011-459f-8a53-2e91d3bf30da",
>>>
>>> "name" : "passwordFile",
>>>
>>> "secureOnlyMechanisms" : [],
>>>
>>> "path" : "${qpid.home_dir}/etc/passwd",
>>>
>>> "type" : "PlainPasswordFile",
>>>
>>> "preferencesproviders" : [ {
>>>
>>> "id" : "db265e14-c9d2-4fca-8f77-ae4c2bcf9203",
>>>
>>> "name" : "fileSystemPreferences",
>>>
>>> "path" : "${qpid.work_dir}/user.preferences.json",
>>>
>>> "type" : "FileSystemPreferences"
>>>
>>> }
>>>
>>>
>>> -- Rob
>>>
>>>
>>> On 25 August 2014 20:47, Rob Godfrey <ro...@gmail.com> wrote:
>>>
>>> Hi Fraser,
>>>>
>>>> the 1-0 support is on by default... The issue may be related to virtual
>>>> hosts... IIRC proton is telling the broker that the host it wants to
>>>> open
>>>> is "localhost" so if you don't have a localhost virtualhost inside the
>>>> broker then it may fail... The error could obviously do with some work,
>>>> whatever the cause.
>>>>
>>>> I'll try to fire up a fresh broker and clean proton install and see
>>>> what I
>>>> can see,
>>>>
>>>> Cheers,
>>>> Rob
>>>>
>>>>
>>>> On 25 August 2014 18:37, Fraser Adams <fr...@blueyonder.co.uk>
>>>> wrote:
>>>>
>>>> Hello,
>>>>> I've just tried using proton's send example with the Java Broker:
>>>>>
>>>>> ./send -a amqp://guest:guest@localhost/amq.fanout
>>>>>
>>>>> and I get the helpful response:
>>>>> [0x21ff810]:ERROR[0] (null)
>>>>>
>>>>> [0x21ff810]:ERROR[0] (null)
>>>>>
>>>>> CONNECTION ERROR connection aborted (remote)
>>>>>
>>>>>
>>>>>
>>>>> I'm pretty sure that I've previously had this working with the Java
>>>>> Broker but I can't think what I'm doing wrong. I can't remember if
>>>>> there's
>>>>> something I need to add to the broker config JSON to make it work with
>>>>> AMQP
>>>>> 1.0, if so what's the incantation I need, if not what am I doing wrong
>>>>> with
>>>>> send?
>>>>>
>>>>> Cheers.
>>>>> Frase
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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 AMQP 1.0 support - is it by default?
Posted by Rob Godfrey <ro...@gmail.com>.
So, I ran last night with a virtualhost called localhost and the address
amqp://guest:guest@localhost:5672/amq.fanout and it worked fine... (I also
got it working with SSL - I think my mistake previously was forgetting that
messenger would try to connect to port 5671 for amqps)
Unfortunately that line in Session_1_0 is a horrible compound statement
linkRegistry =
getVirtualHost().getLinkRegistry(endpoint.getSession().getConnection().getRemoteContainerId());
so it's a little hard to guess which particular thing is null - but it's
probably the virtual host.
I would suggest creating a virtualhost called localhost (or just editing
your config file to replace default with localhost if you like).
For the next release I'm looking to add aliasing to virtualhosts to make
this a little easier, and have the default virtual host initially also have
aliases of "localhost", "127.0.0.1", etc
-- Rob
On 26 August 2014 10:27, Fraser Adams <fr...@blueyonder.co.uk> wrote:
> Hey Rob,
> Thanks for the responses, some more info. I added: "secureOnlyMechanisms"
> : [],
>
> so my password file authentication provider section looks like this:
>
>
> "authenticationproviders" : [ {
> "id" : "cf7bd327-ec0f-4917-bd27-d033e49a23fb",
>
> "name" : "passwordFile",
> "secureOnlyMechanisms" : [],
> "path" : "${qpid.home_dir}/etc/passwd",
> "preferencesproviders" : [ {
> "id" : "50b2fd82-d002-462d-9e65-4230328b8b63",
>
> "name" : "fileSystemPreferences",
> "path" : "${qpid.work_dir}/user.preferences.json",
> "type" : "FileSystemPreferences"
> } ],
> "type" : "PlainPasswordFile"
> } ],
>
>
> I tried again with:
> ./send -a amqp://guest:guest@localhost:5672/amq.fanout
>
> and the error is now saying:
> CONNECTION ERROR (amqp:not-found) Unknown hostname localhost (which
> probably points to your virtualhost comment), however when I did that the
> Broker errored with an NPE:
>
>
>
>
> 00 53 12 d0 00 00 00 5f 00 00 00 0a a1 0a 73 65 6e
> 64 65 72 2d 78 78 78 52 00 42 50 02 50 00 00 53 28
> d0 00 00 00 1c 00 00 00 0b a1 0a 61 6d 71 2e 66 61
> 6e 6f 75 74 52 00 40 52 00 42 40 40 40 40 40 40 00
> 53 29 d0 00 00 00 18 00 00 00 07 a1 0a 61 6d 71 2e
> 66 61 6e 6f 75 74 52 00 40 52 00 42 40 40 40 40 52
> 00
> java.lang.NullPointerException
> at org.apache.qpid.server.protocol.v1_0.Session_1_0.
> remoteLinkCreation(Session_1_0.java:134)
> at org.apache.qpid.server.protocol.v1_0.Connection_1_0$
> 2$1.run(Connection_1_0.java:172)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:356)
> at org.apache.qpid.server.protocol.v1_0.Connection_1_0$
> 2.remoteLinkCreation(Connection_1_0.java:167)
> at org.apache.qpid.amqp_1_0.transport.SessionEndpoint.
> receiveAttach(SessionEndpoint.java:300)
> at org.apache.qpid.amqp_1_0.transport.ConnectionEndpoint.
> receiveAttach(ConnectionEndpoint.java:633)
> at org.apache.qpid.amqp_1_0.type.transport.Attach.invoke(
> Attach.java:352)
> at org.apache.qpid.amqp_1_0.transport.ConnectionEndpoint.
> receive(ConnectionEndpoint.java:802)
> at org.apache.qpid.amqp_1_0.framing.FrameHandler.parse(
> FrameHandler.java:242)
> at org.apache.qpid.amqp_1_0.framing.AMQPProtocolHeaderHandler.parse(
> AMQPProtocolHeaderHandler.java:72)
> at org.apache.qpid.amqp_1_0.codec.ProtocolHeaderHandler.
> parse(ProtocolHeaderHandler.java:107)
> at org.apache.qpid.server.protocol.v1_0.ProtocolEngine_
> 1_0_0_SASL$4.run(ProtocolEngine_1_0_0_SASL.java:383)
> at org.apache.qpid.server.protocol.v1_0.ProtocolEngine_
> 1_0_0_SASL$4.run(ProtocolEngine_1_0_0_SASL.java:379)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:356)
> at org.apache.qpid.server.protocol.v1_0.ProtocolEngine_
> 1_0_0_SASL.received(ProtocolEngine_1_0_0_SASL.java:378)
> at org.apache.qpid.server.protocol.v1_0.ProtocolEngine_
> 1_0_0_SASL.received(ProtocolEngine_1_0_0_SASL.java:65)
> at org.apache.qpid.server.protocol.MultiVersionProtocolEngine.
> received(MultiVersionProtocolEngine.java:133)
> at org.apache.qpid.server.protocol.MultiVersionProtocolEngine.
> received(MultiVersionProtocolEngine.java:49)
> at org.apache.qpid.transport.network.io.IoReceiver.run(
> IoReceiver.java:161)
> at java.lang.Thread.run(Thread.java:722)
>
>
>
> following up on the virtualhost train of thought I tried:
>
> ./send -a amqp://guest:guest@/localhost:5672/amq.fanout
>
> and
>
> ./send -a amqp://guest:guest@default/localhost:5672/amq.fanout
>
>
> My default virtual host is default:
>
> "defaultVirtualHost" : "default",
>
> .....
> and
>
> "virtualhostnodes" : [ {
> "context" : {
> "virtualhostBlueprint" : "{ \"type\" : \"DERBY\", \"storePath\" :
> \"${qpid.work_dir}/default/messages\" }",
> "virtualhostBlueprintUtilised" : "true"
> },
> "createdBy" : null,
> "createdTime" : 0,
> "id" : "13fe911a-2dbb-493e-b652-d3b70013e8d9",
> "lastUpdatedBy" : null,
> "lastUpdatedTime" : 1404484979134,
> "name" : "default",
> "storePath" : "${qpid.work_dir}/default/config",
> "type" : "JSON"
> } ]
>
>
>
> Has this stuff changed recently, clearly the disabling plain
> authentication has, but not so sure about any virtual host stuff. I really
> am pretty sure that I tried the basic
> ./send -a amqp://guest:guest@localhost:5672/amq.fanout
>
> a couple of months ago and it worked fine???
>
> Frase
>
>
>
>
>
>
> On 25/08/14 20:22, Rob Godfrey wrote:
>
>> OK - there's that issue... and then there is an authentication problem.
>> Namely that on trunk the Java Broker does not offer PLAIN authentication
>> over non-SSL ports by default. It offers CRAM-MD5, SCRAM-SHA1 and
>> SCRAM-SHA256... but I'm presuming the messenger client doesn't yet
>> implement any of these.
>>
>> Connecting over SSL should work... but I wan't having any success with
>> that
>> either - which warrants investigation.
>>
>> However, to reenable PLAIN authentication on non-secure connections add
>> the
>> attribute/value pair
>>
>> "secureOnlyMechanisms" : [],
>>
>> into the configuration for you authentication provider in your
>> config.json.
>>
>> As an example, my password file authentication provider section looks like
>> this:
>>
>> {
>>
>> "id" : "ef78d9a3-7011-459f-8a53-2e91d3bf30da",
>>
>> "name" : "passwordFile",
>>
>> "secureOnlyMechanisms" : [],
>>
>> "path" : "${qpid.home_dir}/etc/passwd",
>>
>> "type" : "PlainPasswordFile",
>>
>> "preferencesproviders" : [ {
>>
>> "id" : "db265e14-c9d2-4fca-8f77-ae4c2bcf9203",
>>
>> "name" : "fileSystemPreferences",
>>
>> "path" : "${qpid.work_dir}/user.preferences.json",
>>
>> "type" : "FileSystemPreferences"
>>
>> }
>>
>>
>> -- Rob
>>
>>
>> On 25 August 2014 20:47, Rob Godfrey <ro...@gmail.com> wrote:
>>
>> Hi Fraser,
>>>
>>> the 1-0 support is on by default... The issue may be related to virtual
>>> hosts... IIRC proton is telling the broker that the host it wants to
>>> open
>>> is "localhost" so if you don't have a localhost virtualhost inside the
>>> broker then it may fail... The error could obviously do with some work,
>>> whatever the cause.
>>>
>>> I'll try to fire up a fresh broker and clean proton install and see what
>>> I
>>> can see,
>>>
>>> Cheers,
>>> Rob
>>>
>>>
>>> On 25 August 2014 18:37, Fraser Adams <fr...@blueyonder.co.uk>
>>> wrote:
>>>
>>> Hello,
>>>> I've just tried using proton's send example with the Java Broker:
>>>>
>>>> ./send -a amqp://guest:guest@localhost/amq.fanout
>>>>
>>>> and I get the helpful response:
>>>> [0x21ff810]:ERROR[0] (null)
>>>>
>>>> [0x21ff810]:ERROR[0] (null)
>>>>
>>>> CONNECTION ERROR connection aborted (remote)
>>>>
>>>>
>>>>
>>>> I'm pretty sure that I've previously had this working with the Java
>>>> Broker but I can't think what I'm doing wrong. I can't remember if
>>>> there's
>>>> something I need to add to the broker config JSON to make it work with
>>>> AMQP
>>>> 1.0, if so what's the incantation I need, if not what am I doing wrong
>>>> with
>>>> send?
>>>>
>>>> Cheers.
>>>> Frase
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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 AMQP 1.0 support - is it by default?
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
Hey Rob,
Thanks for the responses, some more info. I added:
"secureOnlyMechanisms" : [],
so my password file authentication provider section looks like this:
"authenticationproviders" : [ {
"id" : "cf7bd327-ec0f-4917-bd27-d033e49a23fb",
"name" : "passwordFile",
"secureOnlyMechanisms" : [],
"path" : "${qpid.home_dir}/etc/passwd",
"preferencesproviders" : [ {
"id" : "50b2fd82-d002-462d-9e65-4230328b8b63",
"name" : "fileSystemPreferences",
"path" : "${qpid.work_dir}/user.preferences.json",
"type" : "FileSystemPreferences"
} ],
"type" : "PlainPasswordFile"
} ],
I tried again with:
./send -a amqp://guest:guest@localhost:5672/amq.fanout
and the error is now saying:
CONNECTION ERROR (amqp:not-found) Unknown hostname localhost (which
probably points to your virtualhost comment), however when I did that
the Broker errored with an NPE:
00 53 12 d0 00 00 00 5f 00 00 00 0a a1 0a 73 65 6e
64 65 72 2d 78 78 78 52 00 42 50 02 50 00 00 53 28
d0 00 00 00 1c 00 00 00 0b a1 0a 61 6d 71 2e 66 61
6e 6f 75 74 52 00 40 52 00 42 40 40 40 40 40 40 00
53 29 d0 00 00 00 18 00 00 00 07 a1 0a 61 6d 71 2e
66 61 6e 6f 75 74 52 00 40 52 00 42 40 40 40 40 52
00
java.lang.NullPointerException
at
org.apache.qpid.server.protocol.v1_0.Session_1_0.remoteLinkCreation(Session_1_0.java:134)
at
org.apache.qpid.server.protocol.v1_0.Connection_1_0$2$1.run(Connection_1_0.java:172)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at
org.apache.qpid.server.protocol.v1_0.Connection_1_0$2.remoteLinkCreation(Connection_1_0.java:167)
at
org.apache.qpid.amqp_1_0.transport.SessionEndpoint.receiveAttach(SessionEndpoint.java:300)
at
org.apache.qpid.amqp_1_0.transport.ConnectionEndpoint.receiveAttach(ConnectionEndpoint.java:633)
at
org.apache.qpid.amqp_1_0.type.transport.Attach.invoke(Attach.java:352)
at
org.apache.qpid.amqp_1_0.transport.ConnectionEndpoint.receive(ConnectionEndpoint.java:802)
at
org.apache.qpid.amqp_1_0.framing.FrameHandler.parse(FrameHandler.java:242)
at
org.apache.qpid.amqp_1_0.framing.AMQPProtocolHeaderHandler.parse(AMQPProtocolHeaderHandler.java:72)
at
org.apache.qpid.amqp_1_0.codec.ProtocolHeaderHandler.parse(ProtocolHeaderHandler.java:107)
at
org.apache.qpid.server.protocol.v1_0.ProtocolEngine_1_0_0_SASL$4.run(ProtocolEngine_1_0_0_SASL.java:383)
at
org.apache.qpid.server.protocol.v1_0.ProtocolEngine_1_0_0_SASL$4.run(ProtocolEngine_1_0_0_SASL.java:379)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at
org.apache.qpid.server.protocol.v1_0.ProtocolEngine_1_0_0_SASL.received(ProtocolEngine_1_0_0_SASL.java:378)
at
org.apache.qpid.server.protocol.v1_0.ProtocolEngine_1_0_0_SASL.received(ProtocolEngine_1_0_0_SASL.java:65)
at
org.apache.qpid.server.protocol.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:133)
at
org.apache.qpid.server.protocol.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:49)
at
org.apache.qpid.transport.network.io.IoReceiver.run(IoReceiver.java:161)
at java.lang.Thread.run(Thread.java:722)
following up on the virtualhost train of thought I tried:
./send -a amqp://guest:guest@/localhost:5672/amq.fanout
and
./send -a amqp://guest:guest@default/localhost:5672/amq.fanout
My default virtual host is default:
"defaultVirtualHost" : "default",
.....
and
"virtualhostnodes" : [ {
"context" : {
"virtualhostBlueprint" : "{ \"type\" : \"DERBY\", \"storePath\" :
\"${qpid.work_dir}/default/messages\" }",
"virtualhostBlueprintUtilised" : "true"
},
"createdBy" : null,
"createdTime" : 0,
"id" : "13fe911a-2dbb-493e-b652-d3b70013e8d9",
"lastUpdatedBy" : null,
"lastUpdatedTime" : 1404484979134,
"name" : "default",
"storePath" : "${qpid.work_dir}/default/config",
"type" : "JSON"
} ]
Has this stuff changed recently, clearly the disabling plain
authentication has, but not so sure about any virtual host stuff. I
really am pretty sure that I tried the basic
./send -a amqp://guest:guest@localhost:5672/amq.fanout
a couple of months ago and it worked fine???
Frase
On 25/08/14 20:22, Rob Godfrey wrote:
> OK - there's that issue... and then there is an authentication problem.
> Namely that on trunk the Java Broker does not offer PLAIN authentication
> over non-SSL ports by default. It offers CRAM-MD5, SCRAM-SHA1 and
> SCRAM-SHA256... but I'm presuming the messenger client doesn't yet
> implement any of these.
>
> Connecting over SSL should work... but I wan't having any success with that
> either - which warrants investigation.
>
> However, to reenable PLAIN authentication on non-secure connections add the
> attribute/value pair
>
> "secureOnlyMechanisms" : [],
>
> into the configuration for you authentication provider in your config.json.
>
> As an example, my password file authentication provider section looks like
> this:
>
> {
>
> "id" : "ef78d9a3-7011-459f-8a53-2e91d3bf30da",
>
> "name" : "passwordFile",
>
> "secureOnlyMechanisms" : [],
>
> "path" : "${qpid.home_dir}/etc/passwd",
>
> "type" : "PlainPasswordFile",
>
> "preferencesproviders" : [ {
>
> "id" : "db265e14-c9d2-4fca-8f77-ae4c2bcf9203",
>
> "name" : "fileSystemPreferences",
>
> "path" : "${qpid.work_dir}/user.preferences.json",
>
> "type" : "FileSystemPreferences"
>
> }
>
>
> -- Rob
>
>
> On 25 August 2014 20:47, Rob Godfrey <ro...@gmail.com> wrote:
>
>> Hi Fraser,
>>
>> the 1-0 support is on by default... The issue may be related to virtual
>> hosts... IIRC proton is telling the broker that the host it wants to open
>> is "localhost" so if you don't have a localhost virtualhost inside the
>> broker then it may fail... The error could obviously do with some work,
>> whatever the cause.
>>
>> I'll try to fire up a fresh broker and clean proton install and see what I
>> can see,
>>
>> Cheers,
>> Rob
>>
>>
>> On 25 August 2014 18:37, Fraser Adams <fr...@blueyonder.co.uk>
>> wrote:
>>
>>> Hello,
>>> I've just tried using proton's send example with the Java Broker:
>>>
>>> ./send -a amqp://guest:guest@localhost/amq.fanout
>>>
>>> and I get the helpful response:
>>> [0x21ff810]:ERROR[0] (null)
>>>
>>> [0x21ff810]:ERROR[0] (null)
>>>
>>> CONNECTION ERROR connection aborted (remote)
>>>
>>>
>>>
>>> I'm pretty sure that I've previously had this working with the Java
>>> Broker but I can't think what I'm doing wrong. I can't remember if there's
>>> something I need to add to the broker config JSON to make it work with AMQP
>>> 1.0, if so what's the incantation I need, if not what am I doing wrong with
>>> send?
>>>
>>> Cheers.
>>> Frase
>>>
>>> ---------------------------------------------------------------------
>>> 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 AMQP 1.0 support - is it by default?
Posted by Rob Godfrey <ro...@gmail.com>.
OK - there's that issue... and then there is an authentication problem.
Namely that on trunk the Java Broker does not offer PLAIN authentication
over non-SSL ports by default. It offers CRAM-MD5, SCRAM-SHA1 and
SCRAM-SHA256... but I'm presuming the messenger client doesn't yet
implement any of these.
Connecting over SSL should work... but I wan't having any success with that
either - which warrants investigation.
However, to reenable PLAIN authentication on non-secure connections add the
attribute/value pair
"secureOnlyMechanisms" : [],
into the configuration for you authentication provider in your config.json.
As an example, my password file authentication provider section looks like
this:
{
"id" : "ef78d9a3-7011-459f-8a53-2e91d3bf30da",
"name" : "passwordFile",
"secureOnlyMechanisms" : [],
"path" : "${qpid.home_dir}/etc/passwd",
"type" : "PlainPasswordFile",
"preferencesproviders" : [ {
"id" : "db265e14-c9d2-4fca-8f77-ae4c2bcf9203",
"name" : "fileSystemPreferences",
"path" : "${qpid.work_dir}/user.preferences.json",
"type" : "FileSystemPreferences"
}
-- Rob
On 25 August 2014 20:47, Rob Godfrey <ro...@gmail.com> wrote:
> Hi Fraser,
>
> the 1-0 support is on by default... The issue may be related to virtual
> hosts... IIRC proton is telling the broker that the host it wants to open
> is "localhost" so if you don't have a localhost virtualhost inside the
> broker then it may fail... The error could obviously do with some work,
> whatever the cause.
>
> I'll try to fire up a fresh broker and clean proton install and see what I
> can see,
>
> Cheers,
> Rob
>
>
> On 25 August 2014 18:37, Fraser Adams <fr...@blueyonder.co.uk>
> wrote:
>
>> Hello,
>> I've just tried using proton's send example with the Java Broker:
>>
>> ./send -a amqp://guest:guest@localhost/amq.fanout
>>
>> and I get the helpful response:
>> [0x21ff810]:ERROR[0] (null)
>>
>> [0x21ff810]:ERROR[0] (null)
>>
>> CONNECTION ERROR connection aborted (remote)
>>
>>
>>
>> I'm pretty sure that I've previously had this working with the Java
>> Broker but I can't think what I'm doing wrong. I can't remember if there's
>> something I need to add to the broker config JSON to make it work with AMQP
>> 1.0, if so what's the incantation I need, if not what am I doing wrong with
>> send?
>>
>> Cheers.
>> Frase
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>>
>
Re: Java Broker AMQP 1.0 support - is it by default?
Posted by Rob Godfrey <ro...@gmail.com>.
Hi Fraser,
the 1-0 support is on by default... The issue may be related to virtual
hosts... IIRC proton is telling the broker that the host it wants to open
is "localhost" so if you don't have a localhost virtualhost inside the
broker then it may fail... The error could obviously do with some work,
whatever the cause.
I'll try to fire up a fresh broker and clean proton install and see what I
can see,
Cheers,
Rob
On 25 August 2014 18:37, Fraser Adams <fr...@blueyonder.co.uk> wrote:
> Hello,
> I've just tried using proton's send example with the Java Broker:
>
> ./send -a amqp://guest:guest@localhost/amq.fanout
>
> and I get the helpful response:
> [0x21ff810]:ERROR[0] (null)
>
> [0x21ff810]:ERROR[0] (null)
>
> CONNECTION ERROR connection aborted (remote)
>
>
>
> I'm pretty sure that I've previously had this working with the Java Broker
> but I can't think what I'm doing wrong. I can't remember if there's
> something I need to add to the broker config JSON to make it work with AMQP
> 1.0, if so what's the incantation I need, if not what am I doing wrong with
> send?
>
> Cheers.
> Frase
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>