- Fix un-necessary re-sends in amqp0_10::SenderImpl::replay.
- Throw NotFound and UnauthorizedAccess correctly from amqp0_10::SessionImpl and ConnectionImpl
- Fix ha_test wait_address and valid_address re-using a session after it is closed by NotFound.

git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk/qpid@1622592 13f79535-47bb-0310-9956-ffa450edef68

The original fix for this introduced a regression, running the qpid-txttest2
test against a cluster with the linear store failed. This fixes the fix.

- Run transaction commit logic when the commit completes. Report completion to the user only when
  all prior commands have completed (sync point)
- Fix missing initializer in client/amqp0_10/SessionImpl.cpp for transaction committing flag.
- Remove annoying log messages from IdSetter.h
- Skip transactional messages in prepare, don't wait till commit.
- Added fetch-timeout option to qpid-txtest2

git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk/qpid@1621368 13f79535-47bb-0310-9956-ffa450edef68

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/qpid@1621211 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk/qpid@1620948 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk/qpid@1619745 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk/qpid@1617924 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk/qpid@1617256 13f79535-47bb-0310-9956-ffa450edef68

C++ and python clients were attempting to continue the transation transparently
after failover which is in correct. They were re-sending messages in the
transaction but there is no way to re-do transactional receives. The transaction
must be aborted.

The C++ and python clients have been modified to kill a transactional session
with a TransactionAborted exception if there is a failover.

Note the Java client already behaves correctly but not identically.
It defers raising an exception until commit rather than failing
immediately on failover, and the session can still be used.

The following commits are involved:

r1611349 QPID-5887: revised approach to implict abort
r1610959 QPID-5887: allow qpid-txtest2 to be run by make test
r1610958 QPID-5887: fix to new txtest2, acknowledge messages in the check phase to ensure queues remain drained for any subsequent runs
r1609748 QPID-5887: abort transactional session on failover; added equivalent of txtest using messaging API

This commit does the following:

- Update ha_tests.py tx_simpler_failover test to expect transaction aborted.
- Minor improvements to qpid-txtest2
- Fix native (non-swig) python client.

git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk/qpid@1611748 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk/qpid@1611349 13f79535-47bb-0310-9956-ffa450edef68

qpid-txtest2.cpp requires new EXTERN

git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk/qpid@1609763 13f79535-47bb-0310-9956-ffa450edef68