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 <fraser.ad...@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 <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
>>>
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
