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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
