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 isn't necessarily a death sentence in and of itself. It is
technically possible (although unlikely) for the broker to recover.
I believe it
I will rephrase my question. Are the any exact dangers by adding
+ExitOnOutOfMemoryError? For example, message/journal corruption if JVM shuts
down abruptly because of OOME in one broker part of the broker, but another
part is still working?
--
Vilius
-Original Message-
From: Just
Hi,
we had an incident where our applications sent too much traffic to Artemis
broker and the broker got Java Heap Out Of Memory errors. I’m trying to
understand why backup broker never became primary after this happened.
We run Artemis static cluster with two nodes (primary and backup) under Sh
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
Are there 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.apache.org
Subject: Re: backup not activa
