qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fraser Adams <fraser.ad...@blueyonder.co.uk>
Subject Re: We've got an App for that .... Qpid Web Based GUI - and more - just released.
Date Fri, 01 Feb 2013 12:16:05 GMT
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


Mime
View raw message