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 <rob.j.godf...@gmail.com> wrote:
>
>
>
> On 26 August 2014 12:28, Fraser Adams <fraser.ad...@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-unsubscr...@qpid.apache.org
>> For additional commands, e-mail: users-h...@qpid.apache.org
>>
>>
>
