Hi Bryan, I suspect, that it is a virtual host recovery what is causing the delay. By default, the messages on the Virtual Host queues are recovered one by one in sequence as part of VH activation. The more messages you have, the slower recovery would be. The VH becames ready to connect only when all messages and VH configured objects are recovered. You can try to switch to asynchronous message store recovery [2] by setting Virtual Host context variable 'use_async_message_store_recovery' to 'true'. You can set set it on Master VH (via Web Management Console or REST API), and, the change will be replicated to Replicas. With asynchronous message store recovery, the messages on different queues are recovered in parallel and VH does not wait for recovery to complete. The VH will became ready immediately after recovery of its children and will accept connections before the message recovery is complete. The producer should be able to publish even when queue recovery has not finished yet. Though, synchronous publishing or message transaction commits would be delayed until queue recovery is complete.
Kind Regards, Alex [1] http://qpid.apache.org/releases/qpid-broker-j-7.0.0/book/Java-Broker-Runtime-Background-Recovery.html On 8 February 2018 at 13:04, bryand <br...@bldixon.net> wrote: > I have HA setup for our qpid-broker-j-7.0.0 Development environment. The > setup is this: > - 2 Windows 2012R2 servers > - on one Windows server I have 1 qpid-broker-j-7.0.0 instance > - on the other Windows server I have 2 qpid-broker-j-7.0.0 instances > (listening on different ports) > - all qpid-broker-j-7.0.0 instances are using jdk-8u162-windows-x64 > > To test failover I simply stop the ACTIVE Virtual Host Node. Failover is > always solid (always works successfully). However, it is now consistently > taking around 1 minute and 45 seconds to failover to another Virtual Host > Node - takes that long for another Node to become ACTIVE and actually start > processing client requests. When I first starting testing this it was > taking around 45 seconds. > > I do have 33 durable queues defined (about half are dead letter queues). > We will actually have more queues in our Test and Production environments. > > Is that amount of time normal? It seems pretty long. During that time if a > client is trying to publish a message it is blocked until failover completes > so if the client request is coming from an end user's action from an > application's user interface the end user is just stuck sitting there > waiting for almost 2 minutes. We're trying to move away from ActiveMQ to > this Apache message broker and ActiveMQ failover (we are using Master/Slave > with a SAN for shared storage) is much much quicker than broker-j. > > Also, I've noticed on the Windows server that I have the 2 broker-j > instances running that the 1st instance never becomes the ACTIVE Node in the > group unless I give it a higher priority than the other Nodes or I start it > up first before the other 2 broker instances are started. > > > > -- > Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
