qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Matos <bruno.ma...@paradigmaxis.pt>
Subject Re: We've got an App for that .... Qpid Web Based GUI - and more - just released.
Date Fri, 01 Feb 2013 14:02:36 GMT
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

Mime
View raw message