summaryrefslogtreecommitdiff
path: root/qpid/cpp/bindings
diff options
context:
space:
mode:
authorAlan Conway <aconway@apache.org>2014-08-28 21:47:44 +0000
committerAlan Conway <aconway@apache.org>2014-08-28 21:47:44 +0000
commit9ae659723b21d9d1c547cf85bf9aba0019b081d5 (patch)
tree85b5f3312fae5e481c921d92012536fce9fa5fff /qpid/cpp/bindings
parent74fabf0e6bbbb07db6d9ac54af5738a60124b68d (diff)
downloadqpid-python-9ae659723b21d9d1c547cf85bf9aba0019b081d5.tar.gz
QPID-5975: HA extra/missing messages when running qpid-txtest2 in a loop with failover.
This is partly not-a-bug, there is a client error handling issue that has been corrected. qpid-txtest2 initializes a queue with messages at the start and drains the queues at the end. These operations are *not transactional*. Therefore duplicates are expected if there is a failover during initialization or draining. When duplicates were observed, there was indeed a failover at one of these times. Making these operations transactional is not enough to pass, now we see the test fail with "no messages to fetch". This is explained as follows: If there is a failover during a transaction, TransactionAborted is raised. The client assumes the transaction was rolled back and re-plays it. However, if the failover occurs at a critical point *after* the client has sent commit but *before* it has received a response, then the the client *does not know* whether the transaction was committed or rolled-back on the new primary. Re-playing in this case can duplicate the transaction. Each transaction moves messages from one queue to another so as long as transactions are atomic the total number of messages will not change. However, if transactions are duplicated, a transactional session may try to move more messages than exist on the queue, hence "no messages to fetch". For example if thread 1 moves N messages from q1 to q2, and thread 2 tries to move N+M messages back, then thread 2 will fail. This problem has been corrected as follows: C++ and python clients now raise the following exceptions: - TransactionAborted: The transaction has definitely been rolled back due to a connection failure before commit or a broker error (e.g. a store error) during commit. It can safely be replayed. - TransactionUnknown: The transaction outcome is unknown because the connection failed at the critical time. There's no simple automatic way to know what happened without examining the state of the broker queues. Unfortunately With this fix qpid-txtest2 is no longer useful test for TX failover because it regularly raises TransactionUnknown and there's not much we can do with that. A better test of TX atomicity with failover is to run a pair of qpid-send/qpid-receive with fail-over and verify that the number of enqueues/dequeues and message depth are a multiple of the transaction size. See the JIRA for such a test. (Note these test also sometimes raise TransactionUnknown but it doesn't matter since all we are checking is that messages go on and off the queues in multiple of the TX size.) ) Note: the original bug also reported seeing missing messages from qpid-txtest2. I don't have a good explanation for that but since the qpid-send/receive test shows that transactions are atomic I am going to let that go for now. git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk@1621211 13f79535-47bb-0310-9956-ffa450edef68
Diffstat (limited to 'qpid/cpp/bindings')
-rw-r--r--qpid/cpp/bindings/qpid/python/qpid_messaging.i2
-rw-r--r--qpid/cpp/bindings/qpid/ruby/ruby.i4
2 files changed, 6 insertions, 0 deletions
diff --git a/qpid/cpp/bindings/qpid/python/qpid_messaging.i b/qpid/cpp/bindings/qpid/python/qpid_messaging.i
index e728c90334..f31b734efa 100644
--- a/qpid/cpp/bindings/qpid/python/qpid_messaging.i
+++ b/qpid/cpp/bindings/qpid/python/qpid_messaging.i
@@ -86,6 +86,7 @@ QPID_EXCEPTION(SessionError, MessagingError)
/* QPID_EXCEPTION(SessionClosed, SessionError) */
QPID_EXCEPTION(TransactionError, SessionError)
QPID_EXCEPTION(TransactionAborted, TransactionError)
+QPID_EXCEPTION(TransactionUnknown, TransactionError)
QPID_EXCEPTION(UnauthorizedAccess, SessionError)
/* QPID_EXCEPTION(InternalError, MessagingError) */
@@ -122,6 +123,7 @@ QPID_EXCEPTION(UnauthorizedAccess, SessionError)
TRANSLATE_EXCEPTION(qpid::messaging::InvalidOptionString, InvalidOption)
TRANSLATE_EXCEPTION(qpid::messaging::LinkError, LinkError)
TRANSLATE_EXCEPTION(qpid::messaging::TransactionAborted, TransactionAborted)
+ TRANSLATE_EXCEPTION(qpid::messaging::TransactionUnknown, TransactionUnknown)
TRANSLATE_EXCEPTION(qpid::messaging::TransactionError, TransactionError)
TRANSLATE_EXCEPTION(qpid::messaging::UnauthorizedAccess, UnauthorizedAccess)
TRANSLATE_EXCEPTION(qpid::messaging::SessionError, SessionError)
diff --git a/qpid/cpp/bindings/qpid/ruby/ruby.i b/qpid/cpp/bindings/qpid/ruby/ruby.i
index a2f2ffab4c..30384aad9f 100644
--- a/qpid/cpp/bindings/qpid/ruby/ruby.i
+++ b/qpid/cpp/bindings/qpid/ruby/ruby.i
@@ -44,6 +44,10 @@
static VALUE merror = rb_define_class("TransactionAborted", eMessagingError);
rb_raise(merror, "%s", error.what());
}
+ catch(qpid::messaging::TransactionUnknown& error) {
+ static VALUE merror = rb_define_class("TransactionUnknown", eMessagingError);
+ rb_raise(merror, "%s", error.what());
+ }
catch(qpid::messaging::TransactionError& error) {
static VALUE merror = rb_define_class("TransactionError", eMessagingError);
rb_raise(merror, "%s", error.what());