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

Reply via email to