You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Bruno Matos <br...@paradigmaxis.pt> on 2013/02/01 12:10:28 UTC
Re: We've got an App for that .... Qpid Web Based GUI - and more -
just released.
Hi Fraser,
I think the default sasl configuration will accept anything as the
username, it only forces the UserID of the message to be the same as the
authentication's username.
Regards.
On Ter, 2013-01-29 at 19:04 +0000, Fraser Adams wrote:
> Hi Bruno,
> are you *sure* that this worked?
>
> So I've literally just tried a basic JMS consumer with a broker fired up
> with qpidd (e.g. authentication enabled) and I used a ConnectionURL
>
> connectionfactory.ConnectionFactory =
> amqp://anonymous:anonymous@clientid/test?brokerlist='tcp://localhost:5672'
>
> and my broker said:
>
> 2013-01-29 18:51:01 warning Failed to retrieve sasl username
>
>
> Similarly if I add a URL of "anonymous/anonymous@localhost:5672" in the
> GUI my broker says the same. This latter case creates a Java
> ConnectionURL the same as my standalone JMS consumer mentioned above.
>
> If I do qpidd --auth no it works fine, but not with authentication enabled.
>
> If you enable log notice in the log4j.xml I think that ConnectionHelper
> (in v1.1 anyway) spits out the Java ConnectionURL it created so it'd be
> interesting to see what that says and if you could also confirm you
> really did use the default this time (you didn't disable auth in config)
>
> What you appear to be seeing all seems a bit odd, especially given
> Pavel's mail about the outstanding bug, and as I say it's inconsistent
> with what I've just seen, so I'm a bit baffled...
>
> Frase
>
> > I changed the default username and password to anonymous in
> > ConnectionHelper.java:569, and it works for now. I don't know the
> > difference between guest/guest and anonymous/anonymous, usually I work
> > with authentication.
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
--
Bruno Matos
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: We've got an App for that .... Qpid Web Based GUI - and more
- just released.
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
Hi Bruno,
Thanks for the logs. It's very weird.
I actually copied and pasted the info from the:
ConnectionHelper.createConnection() amqp://anonymous:anonymous@QpidJMS/vhost?brokerlist='tcp://0.0.0.0:5672'
i.e. the amqp://anon............
stuff
directly into the URL part of Add QMF Console Connection and for the
anonymous-anonymous-auth-yes.txt case I definitely get "warning Failed
to retrieve sasl username" from my broker.
I'm thinking we must have different sasl configurations. If I do "sudo
sasldblistusers2" I get nothing back (I mostly mess around with --auth
no when doing dev stuff). You don't happen to have explicitly added a
user called anonymous do you??
As I say qpid-config works fine for me but I definitely get "warning
Failed to retrieve sasl username" when I try
amqp://anonymous:anonymous@QpidJMS/vhost?brokerlist='tcp://0.0.0.0:5672'
As a connection URL.
Exactly what and where SASL looks for things is Voodoo magic to me :-) I
thought it revolved around the commands sasldblistusers2, saslpasswd2.
Hmm ages back when I did mess around with auth I can vaguely recall some
weirdness I'm using Ubuntu and that doesn't have a /etc/sasl2/ directory
but does have a /etc/sasldb2 file I might have to did back an remind
myself what I did. I'm also currently running a 0.12 broker so some
stuff might have changed. I *vaguely* recall some stuff about sasl_mechs.
I was planning on upgrading to 0.20 so when I've got a moment I'll do
that and try to remember how the heck I got authentication working -
last time I tried I had a bit of a config fight, I think that the
default paths prefer Redhat/Fedora to Ubuntu...
On the other topic
> Usually qpid-tool takes some time to get all information too.
>
Now that's really interesting (AKA a slight relief....), trying
something like qpid-queue-stats would be good too. Clearly what I'm
doing and qpid-tool/qpid-queue-stats are more or less unrelated except
of course that they are both using QMF, but the code base is totally
separate - mine is Java JMS the others are python. If qpid-tool is
taking some time to get all information that would at least "suggest"
that there's something odd at your end (can you sense that's what I'm
hoping :-)). A very heavily loaded/swapping broker or something odd
network wise.
One thing I have noticed when I added a bunch of different connections
is that sometimes when I select between them the reconnection isn't as
reliable as I'd initially thought. It's only occasional, but sometimes
the broker disconnected doesn't go away. If I click back and forward
it'll generally connect and it seems OK at that point responding to real
broker disconnects. It's intermittent and TBH I only noticed it when I
added the connections with the copy'n'paste ConnectionURLs so it's going
to be a pain getting to the bottom of it - I *hate* intermittent bugs :-)
The reconnection stuff is pretty complicated and subtle and switching
the "active" connection between different URLs was one of the most
recent bits I added. It ought to be unrelated to the things you're
describing but it's something to watch out for. It's easy to work around
though by clicking the previous connection and back again.
F.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: We've got an App for that .... Qpid Web Based GUI - and more -
just released.
Posted by Bruno Matos <br...@paradigmaxis.pt>.
I send the logs from both guest/guest and anonymous/anonymous versions
of qmfv2-1.1 with and without authentication.
More inline:
On Sex, 2013-02-01 at 12:16 +0000, Fraser Adams wrote:
> I'm not totally sure what you mean by what you've said below :-/
>
> As I say I've tried with settings that should create a Java
> ConnectionURL with anonymous:anonymous at the start, which ought to be
> the same as you changing the ConnectionHelper username/password Strings
> from guest to anonymous but I'm seeing "warning Failed to retrieve sasl
> username" when I do.
>
> I can't quite reconcile what you reckon you're seeing with what I'm
> seeing. What I'm seeing would seem to align with what Pavel covered in
> the Jira he mentioned.
>
> I don't think this is sasl per se, because if I use plain old
> qpid-config that would connect to localhost:5672 as anonymous and I
> don't get the warning, so it seems to be how Java ConnectionURLs are
> handled.
>
> Were you able to enable logging and pull out the URL ConnectionHelper
> created to give to the underlying ConnectionFactory?
>
>
>
> On a different note I'm still struggling to figure out why your data
> updates might be sluggish/unreliable. You mentioned you're using Chrome
> - that's normally pretty well behaved and supports a decent number of
> HTTP connections. I tried Chrome on a netbook to my REST Server and it
> behaved perfectly.
I've not reached there after my testing reset. Will be my next step.
>
>
> Is there anything unusual about your network/topology etc. At this stage
> it'd be good if you could go back to basics and work out from there.
> Would you be able to try running up a broker on the same host as
> QpidRestAPI with --auth no then working out from there adding auth and
> moving out to the brokers you actually care about?
Yes, I'll start from a simple configuration.
>
> I'm afraid that all the dev on this has been done in my spare time and
> my home network has only got one Linux server, though I've tried a ton
> of browsers and I've got a fairly big WiFi set up with two Access Points
> and haven't seen issues even using avahi so my server has a sensible
> name on my private network. But I've not been able to try QpidRestAPI
> and the broker on different hosts.
>
> I can't think of any *obvious* reasons why there should be any problems
> though because the underlying QMF2 stuff is really just a JMS client, so
> if you have QMF problems between two hosts then I'd expect any other
> Qpid application would behave equally weirdly. As a thought what happens
> if you run qpid-queue-stats on the host you're running QpidRestAPI on
> and pointing that to the broker in question. That's *really* worth
> checking because qpid-queue-stats gets data pushed by the broker
> periodically.
Usually qpid-tool takes some time to get all information too.
>
> I assume you've checked that any network you have between the hosts
> behaves normally for everything else? Probably not relevant, but I once
> had a NIC that was a bit flaky and ended negotiating a half duplex link
> - imagine my surprise :-)
It's my testing broker, even for performance, so it should be fine.
>
> How heavily loaded is the broker that you are talking to when your
> updates are sluggish? The updates are every 10s and pull back more or
> less every QMF statistic serialising to JSON. I've tested with > 500
> connections plus queues and bindings. Bear in mind when you get to this
> sort of number transfers might get to the MB size given the number of
> properties in queues, but unless you're on a really low bandwidth link
> you shouldn't notice that. On my setup top on Firefox was pretty modest
> doing that.
It could be with high load when I tested, I will test again.
>
> However if you are really trashing the broker too you might see quirks I
> set up queues that were far too big and connected slow consumers + fast
> producers and when my broker went in to swap unsurprisingly I'd see
> update glitches - but really the only time I've had anything other than
> regular updates was when I pushed the broker into swap - so I remain
> befuddled :-(
>
>
> You didn't get back to me on this but you really really haven't got
> --mgmt-pub-interval set to anything other than the default have you??
No, it's set to 10 (default).
>
> If you look on the "broker" page on the GUI it'll be down as
> mgmtPubInterval. If you look at the uptime mine increments by 10 seconds
> every 10 seconds are you seeing any sort of periodicity?
I'll look at it in my next test.
>
> Have you taken a look at the graphs for the QMF Queues, the one bound to
> qmf.default.direct and indeed the graph for that exchange ought to be
> quite spiky/noisy. Looking at that graph you should be able to see when
> your statistics updates are arriving.
Not yet, but I will.
>
> I'm afraid I'm struggling to come up with answers on this, I'd be really
> interested to know what others are experiencing.
>
> Frase
Regards.
>
>
> On 01/02/13 11:10, Bruno Matos wrote:
> > Hi Fraser,
> >
> > I think the default sasl configuration will accept anything as the
> > username, it only forces the UserID of the message to be the same as the
> > authentication's username.
> >
> > Regards.
> >
> > On Ter, 2013-01-29 at 19:04 +0000, Fraser Adams wrote:
> >> Hi Bruno,
> >> are you *sure* that this worked?
> >>
> >> So I've literally just tried a basic JMS consumer with a broker fired up
> >> with qpidd (e.g. authentication enabled) and I used a ConnectionURL
> >>
> >> connectionfactory.ConnectionFactory =
> >> amqp://anonymous:anonymous@clientid/test?brokerlist='tcp://localhost:5672'
> >>
> >> and my broker said:
> >>
> >> 2013-01-29 18:51:01 warning Failed to retrieve sasl username
> >>
> >>
> >> Similarly if I add a URL of "anonymous/anonymous@localhost:5672" in the
> >> GUI my broker says the same. This latter case creates a Java
> >> ConnectionURL the same as my standalone JMS consumer mentioned above.
> >>
> >> If I do qpidd --auth no it works fine, but not with authentication enabled.
> >>
> >> If you enable log notice in the log4j.xml I think that ConnectionHelper
> >> (in v1.1 anyway) spits out the Java ConnectionURL it created so it'd be
> >> interesting to see what that says and if you could also confirm you
> >> really did use the default this time (you didn't disable auth in config)
> >>
> >> What you appear to be seeing all seems a bit odd, especially given
> >> Pavel's mail about the outstanding bug, and as I say it's inconsistent
> >> with what I've just seen, so I'm a bit baffled...
> >>
> >> Frase
> >>
> >>> I changed the default username and password to anonymous in
> >>> ConnectionHelper.java:569, and it works for now. I don't know the
> >>> difference between guest/guest and anonymous/anonymous, usually I work
> >>> with authentication.
> >>>
> >> ---------------------------------------------------------------------
> >> 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
>
--
Bruno Matos
Re: We've got an App for that .... Qpid Web Based GUI - and more
- just released.
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
I'm not totally sure what you mean by what you've said below :-/
As I say I've tried with settings that should create a Java
ConnectionURL with anonymous:anonymous at the start, which ought to be
the same as you changing the ConnectionHelper username/password Strings
from guest to anonymous but I'm seeing "warning Failed to retrieve sasl
username" when I do.
I can't quite reconcile what you reckon you're seeing with what I'm
seeing. What I'm seeing would seem to align with what Pavel covered in
the Jira he mentioned.
I don't think this is sasl per se, because if I use plain old
qpid-config that would connect to localhost:5672 as anonymous and I
don't get the warning, so it seems to be how Java ConnectionURLs are
handled.
Were you able to enable logging and pull out the URL ConnectionHelper
created to give to the underlying ConnectionFactory?
On a different note I'm still struggling to figure out why your data
updates might be sluggish/unreliable. You mentioned you're using Chrome
- that's normally pretty well behaved and supports a decent number of
HTTP connections. I tried Chrome on a netbook to my REST Server and it
behaved perfectly.
Is there anything unusual about your network/topology etc. At this stage
it'd be good if you could go back to basics and work out from there.
Would you be able to try running up a broker on the same host as
QpidRestAPI with --auth no then working out from there adding auth and
moving out to the brokers you actually care about?
I'm afraid that all the dev on this has been done in my spare time and
my home network has only got one Linux server, though I've tried a ton
of browsers and I've got a fairly big WiFi set up with two Access Points
and haven't seen issues even using avahi so my server has a sensible
name on my private network. But I've not been able to try QpidRestAPI
and the broker on different hosts.
I can't think of any *obvious* reasons why there should be any problems
though because the underlying QMF2 stuff is really just a JMS client, so
if you have QMF problems between two hosts then I'd expect any other
Qpid application would behave equally weirdly. As a thought what happens
if you run qpid-queue-stats on the host you're running QpidRestAPI on
and pointing that to the broker in question. That's *really* worth
checking because qpid-queue-stats gets data pushed by the broker
periodically.
I assume you've checked that any network you have between the hosts
behaves normally for everything else? Probably not relevant, but I once
had a NIC that was a bit flaky and ended negotiating a half duplex link
- imagine my surprise :-)
How heavily loaded is the broker that you are talking to when your
updates are sluggish? The updates are every 10s and pull back more or
less every QMF statistic serialising to JSON. I've tested with > 500
connections plus queues and bindings. Bear in mind when you get to this
sort of number transfers might get to the MB size given the number of
properties in queues, but unless you're on a really low bandwidth link
you shouldn't notice that. On my setup top on Firefox was pretty modest
doing that.
However if you are really trashing the broker too you might see quirks I
set up queues that were far too big and connected slow consumers + fast
producers and when my broker went in to swap unsurprisingly I'd see
update glitches - but really the only time I've had anything other than
regular updates was when I pushed the broker into swap - so I remain
befuddled :-(
You didn't get back to me on this but you really really haven't got
--mgmt-pub-interval set to anything other than the default have you??
If you look on the "broker" page on the GUI it'll be down as
mgmtPubInterval. If you look at the uptime mine increments by 10 seconds
every 10 seconds are you seeing any sort of periodicity?
Have you taken a look at the graphs for the QMF Queues, the one bound to
qmf.default.direct and indeed the graph for that exchange ought to be
quite spiky/noisy. Looking at that graph you should be able to see when
your statistics updates are arriving.
I'm afraid I'm struggling to come up with answers on this, I'd be really
interested to know what others are experiencing.
Frase
On 01/02/13 11:10, Bruno Matos wrote:
> Hi Fraser,
>
> I think the default sasl configuration will accept anything as the
> username, it only forces the UserID of the message to be the same as the
> authentication's username.
>
> Regards.
>
> On Ter, 2013-01-29 at 19:04 +0000, Fraser Adams wrote:
>> Hi Bruno,
>> are you *sure* that this worked?
>>
>> So I've literally just tried a basic JMS consumer with a broker fired up
>> with qpidd (e.g. authentication enabled) and I used a ConnectionURL
>>
>> connectionfactory.ConnectionFactory =
>> amqp://anonymous:anonymous@clientid/test?brokerlist='tcp://localhost:5672'
>>
>> and my broker said:
>>
>> 2013-01-29 18:51:01 warning Failed to retrieve sasl username
>>
>>
>> Similarly if I add a URL of "anonymous/anonymous@localhost:5672" in the
>> GUI my broker says the same. This latter case creates a Java
>> ConnectionURL the same as my standalone JMS consumer mentioned above.
>>
>> If I do qpidd --auth no it works fine, but not with authentication enabled.
>>
>> If you enable log notice in the log4j.xml I think that ConnectionHelper
>> (in v1.1 anyway) spits out the Java ConnectionURL it created so it'd be
>> interesting to see what that says and if you could also confirm you
>> really did use the default this time (you didn't disable auth in config)
>>
>> What you appear to be seeing all seems a bit odd, especially given
>> Pavel's mail about the outstanding bug, and as I say it's inconsistent
>> with what I've just seen, so I'm a bit baffled...
>>
>> Frase
>>
>>> I changed the default username and password to anonymous in
>>> ConnectionHelper.java:569, and it works for now. I don't know the
>>> difference between guest/guest and anonymous/anonymous, usually I work
>>> with authentication.
>>>
>> ---------------------------------------------------------------------
>> 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