Mailing-List: contact commits-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: svn commit: r1367552 -
 /activemq/trunk/activemq-core/src/test/java/org/apache/activemq/broker/ft/DbRestartJDBCQueueMasterSlaveTest.java
Date: Tue, 31 Jul 2012 13:53:38 -0000
To: commits@activemq.apache.org
From: gtully@apache.org
Message-Id: <20120731135338.53E2023888CD@eris.apache.org>

Author: gtully
Date: Tue Jul 31 13:53:37 2012
New Revision: 1367552

URL: http://svn.apache.org/viewvc?rev=1367552&view=rev
Log:
add some context to the intermittent failure, issue is ioexception from store being treated as transport failure, if the error ocurrs on a ack commit we can expect a redelivery that won't come and fail the test

Modified:
    activemq/trunk/activemq-core/src/test/java/org/apache/activemq/broker/ft/DbRestartJDBCQueueMasterSlaveTest.java

Modified: activemq/trunk/activemq-core/src/test/java/org/apache/activemq/broker/ft/DbRestartJDBCQueueMasterSlaveTest.java
URL: http://svn.apache.org/viewvc/activemq/trunk/activemq-core/src/test/java/org/apache/activemq/broker/ft/DbRestartJDBCQueueMasterSlaveTest.java?rev=1367552&r1=1367551&r2=1367552&view=diff
==============================================================================
--- activemq/trunk/activemq-core/src/test/java/org/apache/activemq/broker/ft/DbRestartJDBCQueueMasterSlaveTest.java (original)
+++ activemq/trunk/activemq-core/src/test/java/org/apache/activemq/broker/ft/DbRestartJDBCQueueMasterSlaveTest.java Tue Jul 31 13:53:37 2012
@@ -23,6 +23,7 @@ import javax.jms.JMSException;
 import javax.jms.Message;
 import javax.jms.MessageProducer;
 import javax.jms.Session;
+import javax.jms.TransactionRolledBackException;
 import org.apache.activemq.ActiveMQConnection;
 import org.apache.derby.jdbc.EmbeddedDataSource;
 import org.slf4j.Logger;
@@ -96,10 +97,28 @@ public class DbRestartJDBCQueueMasterSla
             receiveSession.commit();
             super.consumeMessage(message, messageList);
         } catch (JMSException e) {
-            LOG.info("Faild to commit message receipt: " + message, e);
+            LOG.info("Failed to commit message receipt: " + message, e);
             try {
                 receiveSession.rollback();
             } catch (JMSException ignored) {}
+
+            if (e.getCause() instanceof TransactionRolledBackException) {
+                TransactionRolledBackException transactionRolledBackException = (TransactionRolledBackException)e.getCause();
+                if (transactionRolledBackException.getMessage().indexOf("in doubt") != -1) {
+                    // failover chucked bc there is a missing reply to a commit. the ack may have got there and the reply
+                    // was lost or the ack may be lost.
+                    // so we may not get a resend.
+                    //
+                    // REVISIT: A JDBC store IO exception should not cause the connection to drop, so it needs to be wrapped
+                    // possibly by the IOExceptionHandler
+                    // The commit/close wrappers in jdbc TransactionContext need to delegate to the IOExceptionHandler
+
+                    // this would leave the application aware of the store failure, and possible aware of whether the commit
+                    // was a success, rather than going into failover-retries as it does now.
+
+                }
+
+            }
         }
     }
 }