On 5 March 2015 at 10:55, Gordon Sim <[email protected]> wrote: > On 03/04/2015 09:38 PM, Rob Godfrey wrote: > >> That's odd... The out of the box config should have a virtualhost. Were >> you running a completely fresh install, or were you running with an >> existing config/work directory? >> > > It was a completely fresh install and I set QPID_WORK to the new install > directory. Perhaps that wasn't correct anymore? > > Can you give the exact steps you used to install / start... The broker starts up with an initial config which has a parameterized initial virtual host. I admit I normally just start from within my IDE, so I may be doing something different somehow. If you could also provide the config json file that the broker writes on first startup (indeed a tar of the whole work directory) prior to you adding a virtual host that would be very useful.
> The management console showed no virtual hosts, theough the 'default' for > the broker was still listed as 'default' in the broker section above this. > I create a virtual host named default and everything worked. (Whats a > virtual host node btw? I seem to need to create one of those along side my > virtual host?) > > The VirtualHostNode was something we added to support HA replication... The VirtualHostNode represents the Broker's knowledge of the Virtual Host (i.e. enough configuration to go find the virtual host and its configuration), for a non HA virtual host that might be something like the type of configuration store (JSON, Derby, BDB, etc) and a path. For the BDB HA virtual host node it includes the connection information so the virtual host node can join the replication group. Where a different broker is currently the master for a virtual host, the virtual host node will not have an active virtual host underneath it, but will show the state of the other nodes in the group (which are on other brokers) so you can see where the master is currently residing. > In terms of authentication, by default PLAIN is no longer enabled over >> non-TLS connections. >> > > I can see the logic. The python 0-10 client by default (i.e. without the > cyrus sasl integration installed) only has ANONYMOUS and PLAIN, so was > unable to connect. Next time I'll try ssl. > > Yes - my thinking is really that the default install of the broker should either add ANONYMOUS support, or we should have some sort of initial configuration questionnaire to guide people through the first run of the broker. Having an initial password file with "guest", "guest" in it is just a horrible thing to do. > There *seems* to be something odd happening when trying to consume >>> messages from a queue. Over 0-10 I only get the messages if I issue a >>> message-flush. Over 1.0 I sometimes can't get any messages out at all. >>> Not >>> sure if this is only when queue was created over 0-10. Even for a queue >>> created through management, I was not getting messages at times after >>> having sent them and had them accepted (switching back to 0-10 and >>> flushing, I could see them all as expected). If the receiver is active >>> before messages are sent (whether through exchanges or direct through >>> queues), receiving seems to work ok. >>> >>> Got a deadlock trying to stop the (java) broker, see attached. On >>> restarting, my virtual host was there but somehow things were corrupted >>> and >>> could not connect again until I deleted and recreated it. >>> >> >> >> So, the deadlock actually happened before the close, it occurred when a >> flow arrived at the broker at the same time as a message was being sent >> from the broker to a consumer... I'll fix that now on trunk (I don't think >> that looks like a new issue, but we should fix it anyway). The effect of >> the deadlock would be that that queue would no longer be distributing >> messages. >> > > I only noticed the deadlock when trying to stop the broker - it just > hangs. I can see on my current process I have two deadlocks (before > shutting down). Probably the same ones, but just in case its of use, > another stackdump attached. > > This does indeed sound like part of the problem at least with the receive. > The queue wasn't completely jammed however, as I could get messages by > rerunning the receiver over 0-10 without flushing. > > There'll be potential (depending on whether all the messages in the queue are acquired) for independent flows to get through... Basically once it's deadlocked there's no guarantees as to how the thing will behave, so I'm not going to try to reason about the message sending stuff until/unless we can replicate it with the deadlock fixed. -- Rob > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
