Thank you! This is exactly what I wanted to know.
--
Vilius
-Original Message-
From: Justin Bertram
Sent: Monday, January 6, 2025 9:07 PM
To: users@activemq.apache.org
Subject: Re: backup not activated after OOM on primary
I'm not aware of any broker-specific dangers of a
gt; -Original Message-
> From: Justin Bertram
> Sent: Thursday, January 2, 2025 3:42 AM
> To: users@activemq.apache.org
> Subject: Re: backup not activated after OOM on primary
>
> The caveat with adding +ExitOnOutOfMemoryError is that the JVM will now
> exit when an OO
: Justin Bertram
Sent: Thursday, January 2, 2025 3:42 AM
To: users@activemq.apache.org
Subject: Re: backup not activated after OOM on primary
The caveat with adding +ExitOnOutOfMemoryError is that the JVM will now exit
when an OOME occurs now rather than simply carrying on. Keep in mind that an
OOME
any caveats adding +ExitOnOutOfMemoryError? Just wondering why
> it's not in the default JAVA_ARGS in "artemis.profile".
>
> --
> Vilius
>
> -Original Message-
> From: Justin Bertram
> Sent: Wednesday, January 1, 2025 11:01 PM
> To: users@activemq
Re: backup not activated after OOM on primary
I think what you're seeing is expected. An OOME usually isn't enough to trigger
the broker to fail completely and trigger a failover. As you can see, the
broker continued to run after the OOME which means it was still holding the
lock on the s
I think what you're seeing is expected. An OOME usually isn't enough to
trigger the broker to fail completely and trigger a failover. As you can
see, the broker continued to run after the OOME which means it was still
holding the lock on the shared journal (preventing the backup from
activating). I
