Is a log file being written? If so, it means the JVM came up at least
enough to load Log4J, and the log file should have useful information about
why the broker exited. If not, it means that the JVM is failing to launch
due to some fundamental reason (not enough RAM for the amount of heap
requested
What do you mean by "background verification"?
Also, what exactly fails immediately when you use 'artemis.cmd stop'?
One of the main goals of having a reproducible test-case is to be able to
share that test-case with others so they can reproduce what you are
seeing. Reproducibility is one of the
Please read the red box in the "Setting Expiration on Messages in the DLQ"
section on that page. It seems like that's exactly what you've done, since
you're using a '>' wildcard. Try using a more restrictive wildcard that
doesn't match the DLQ and see if it behaves as you expect.
Tim
On Tue, Jul
If you uncomment the two JDBC-related lines in log4j.properties (enabling
debugging output) and restart the broker, does the resulting output provide
any more information about what's going on?
Tim
On Tue, Jul 10, 2018, 9:18 AM ankit.mittal100
wrote:
> Hi Tim,
>
> Thanks for reply... but right
I have tried to recreate my case with use of provided tooling (ServerUtil) for
orchestrated server start and stop but I received worrying results on Windows
machine.
I'm starting three nodes of the cluster and background threads for produce /
consume (for one minute). After 10 seconds first nod
Thank
--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
