Yeah.. something like that... not necessarily in there though. but a
similar test.
On Tue, Oct 11, 2022 at 1:44 PM Stephen Baker
wrote:
>
> Ok, I agree based on a cursory reading of that patch. The extra ackReason
> defaults to normal in one direction and isn’t read in the other direction.
> Ki
Ok, I agree based on a cursory reading of that patch. The extra ackReason
defaults to normal in one direction and isn’t read in the other direction.
Killed, replaced, and expired being interpreted as normal just means that the
2.20 bugs will persist until both sides are updated.
I’ll test it ou
In theory it should work.
Only change that might break compatibility is
https://github.com/apache/activemq-artemis/commit/68f6d8263d8c795722805f0e4d6939e7a8b9ed48
which is ARTEMIS-3743 / ARTEMIS-3766 Use ACKReason on Mirror to
determine target operations and fixing Delivering statistics on Mirror
We are planning our production upgrade from 2.20 to 2.25. These upgrades
involve a loss of service in the window between stopping the live and when the
backup instance becomes ready to process messages.
I was wondering if the mirror protocol is expected to be compatible between
those versions.
We are trying to create a scenario which reproduces the issue in a few specific
steps. But we haven't yet.
From: Clebert Suconic
Sent: Thursday, October 6, 2022 1:51 PM
To: users@activemq.apache.org
Subject: Re: Messages getting lost on Artemis 2.25
Do you have
Hi Rafael,
Our testing has shown that multi does use more resources for the same
throughput; more cpu, ram and storage, but not significantly more unless
you are already at the limit.
We have configured one-kaha-per-queue so it does improve the storage
reclaim when for whatever reason the reclaim
