Bryan
Thanks for reporting the problem. This is a defect in Broker-J 7.0.0
and 7.0.1. The defect will cause startup to be delayed as you have
observed (5 seconds (cumulative) per queue or exchange using an
alternate binding). The synchronous/asynchronous recoverer and
existence or not of
Answers to your questions..
Could you please clarify whether you have seen "Gave up waiting"
warnings with synchronous or asynchronous recoverer?
- definitely when using synchronous but also pretty sure it was after I made
the context change to use asynchronous recovery also. I've been making
Hi Bryan,
Could you please clarify whether you have seen "Gave up waiting"
warnings with synchronous or asynchronous recoverer?
Do you have full broker log with the warnings? Can you share it?
Did you connect consumers to DLQs whilst the VH messages were
asynchronously recovered?
Kind Regards,
I was utilizing DLQs (Alternate Binding) for most of my queues and I think
that is why the Virtual Host Node startup time was so slow (1 minute 45
seconds). After I deleted all those DLQs, the startup time was down to 11
seconds - a huge difference especially when dealing with a failover
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
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
