qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleksandr Rudyy <oru...@gmail.com>
Subject Re: qpid-broker-j-7.0.0 failover is slow
Date Thu, 08 Feb 2018 14:12:42 GMT
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,

[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 <bryan@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-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

View raw message