activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stan Lewis (JIRA)" <>
Subject [jira] Created: (AMQ-2880) Exception thrown during commit leads to message loss
Date Thu, 26 Aug 2010 12:38:40 GMT
Exception thrown during commit leads to message loss

                 Key: AMQ-2880
             Project: ActiveMQ
          Issue Type: Bug
          Components: Broker
    Affects Versions: 5.4.0
            Reporter: Stan Lewis
         Attachments: test-case.txt

In cases where JDBC persistence is used and the database server is under a fair bit of load
it's sometimes possible for table/row locks to time out, which means you'll see exceptions
such as:

java.sql.BatchUpdateException: Lock wait timeout exceeded; try restarting transaction
at com.mysql.jdbc.PreparedStatement.executeBatchSerially(
at com.mysql.jdbc.PreparedStatement.executeBatch(
at org.apache.commons.dbcp.DelegatingStatement.executeBatch(
at org.apache.commons.dbcp.DelegatingStatement.executeBatch(
at org.apache.activemq.transaction.XATransaction.commit(
at org.apache.activemq.command.TransactionInfo.visit(
at org.apache.activemq.transport.TransportFilter.onCommand(
at org.apache.activemq.transport.WireFormatNegotiator.onCommand(
at org.apache.activemq.transport.InactivityMonitor.onCommand(
at org.apache.activemq.transport.TransportSupport.doConsume(
at org.apache.activemq.transport.tcp.TcpTransport.doRun(

In this case the connection to the database is fine and what we should do is retry the transaction
as it's a temporary failure condition.  Instead what happens is the broker moves to the next
message in the queue, leaving the current message in the database.  The message won't show
up in the web console and cannot be consumed by any consumers until the broker is restarted.

Attached is a test case that simulates the error condition in a controlled fashion by using
a subclassed JDBCPersistenceAdapter that will throw an exception in commitTransaction as necessary.
 So the producer sends 10 messages and then the consumer tries to consume them, during this
time the persistence adapter will throw an exception during commitTransaction.  Then the condition
is cleared and the consumer can consume all 10 messages, however the consumer only consumes
9 messages, the 1st message in the sequence is still in the database.  Hopefully the logging
makes this clear.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message