[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ActiveMQ and Artemis reliability - Messages lost

I'm the author of JmsTools. I don't have the time to deep-dive into this
issue now, I just want to point out a few things.

The tool simulates an application, so it ignores whatever is in
ActiveMQ/Artemis. So will a real application. If a message is lost to the
tool it is also lost to the real application and then it is lost.

All sent messages are stamped with unique ids. The log analyzer verifies
that all sent messages are received. That is better than using counters. One
duplicate and one lost message will even out with a counter, but will be
detected with unique ids.

The tool does handle disconnects and reconnects in the same way as a real
application and the errors are logged. There are some places where they are
race conditions that are not detected by the log analyzer. One would need to
read the tool's detailed logs and investigate, possibly also in the broker
logs. However, with very few exceptions it is just as stable (or more) as a
real JMS application would be. If it detects an issue a real application
would also have an issue.

The tool will recover XA transactions if allowed to run long enough and it
will log heuristic transactions as such (? instead of C or R). If the tool
is stopped before recovery has completed (which is likely in a short test)
then the prepared transactions may remain in the broker, of course. That
only applies when using XA, I don't think this test did that? With normal
transactions the messages should remain in the queue, in a DLQ or they
should have been delivered.

I've worked with and detected issues with standard ActiveMQ before. Some of
them can be worked around with configuration (both on client and broker),
others are harder and can also be difficult to reproduce as they happen due
to race conditions. If they only happen in corner cases under high load it
is very hard to write an isolated unit test.

I don't mean to say that the tool is perfect and this is not "fire and
forget", a significant amount of analysis work is needed to find out where
the problems are. However, if the tool gets in trouble most if not all
real-world JMS applications would get in trouble too and then something
should be done. Usually tweaking the configuration or investigating and
filing a detailed bug report.


Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html