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 : [],
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
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
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
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
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
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
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
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
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.
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
On 26 August 2014 16:57, Gordon Sim g...@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...
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
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
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 fraser.ad...@blueyonder.co.uk wrote:
On 26/08/14 15:41, Rob Godfrey wrote:
Hi Fraser,
I think the issue
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
Doh - yeah - that was my fault... fixed now I hope,
-- Rob
On 26 August 2014 17:49, Fraser Adams fraser.ad...@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
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
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
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
20 matches
Mail list logo
