QPID-6046 : [Java Broker] [AMQP 1.0] when creating an outgoing link from the address amq.fanout (or any fanout exchange) bind the temporary queue to the exchange witht the queue name

git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk@1620657 13f79535-47bb-0310-9956-ffa450edef68
QPID-6040 : [Java Broker] [Java Client] add the ability to create a single consumer that is consuming across a collection of queues

git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk@1620659 13f79535-47bb-0310-9956-ffa450edef68
Revert "NO-JIRA: Work-around bug in older cmake, finds static python library instead of shared."

This patch seems to cause various build problems, will put it back when I figure
out what is going wrong.

------------------------------------------------------------------------
r1620424 | aconway | 2014-08-25 16:10:52 -0400 (Mon, 25 Aug 2014) | 13 lines

NO-JIRA: Work-around bug in older cmake, finds static python library instead of shared.

FindPythonLibs on older versions of cmake (observed on cmake-2.6.4-5.el5.4)
sometimes finds the static archive library (.a) before the shared object
library (.so) This is almost never what you want. Newer
versions (e.g. cmake-2.8.12.2-2.fc20.x86_64) explicitly look for the .so first
and look for the .a library second.

This workaround fixes the problem as follows:
- It is a no-op except on Unix platforms that use the .so prefix.
- On those platforms it does a search for .so only first.
- Finally we do a default search for other platforms (or if .so was not found)

------------------------------------------------------------------------

git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk@1620738 13f79535-47bb-0310-9956-ffa450edef68
QPID-5813: fix up LICENSE + NOTICE etc files

git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk@1620850 13f79535-47bb-0310-9956-ffa450edef68
QPID-6047 : [Java Broker] Improve Message conversion between 1.0 and 0.x protocols - add mapping from application property qpid.subject to the 1.0 subject property

git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk@1620858 13f79535-47bb-0310-9956-ffa450edef68
QPID-6048: Move permitted nodes attribute into BDB HA VH in order to be able to identify the intruder node on node start-up

git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk@1620882 13f79535-47bb-0310-9956-ffa450edef68
NO-JIRA: Work-around bug in older cmake, finds static python library instead of shared.

FindPythonLibs on older versions of cmake (observed on cmake-2.6.4-5.el5.4)
sometimes finds the static archive library (.a) before the shared object
library (.so) This is almost never what you want. Newer
versions (e.g. cmake-2.8.12.2-2.fc20.x86_64) explicitly look for the .so first
and look for the .a library second.

This workaround fixes the problem as follows:
- It is a no-op except on Unix platforms that use the .so prefix.
- On those platforms it does a search for .so only first.
- Finally we do a default search for other platforms (or if .so was not found)

git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk@1620888 13f79535-47bb-0310-9956-ffa450edef68
QPID-6049: ensure nss is initialised (and shutdown) for 1.0 connections; add 1.0 based ssl test

git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk@1620948 13f79535-47bb-0310-9956-ffa450edef68
QPID-6050 : [JMS AMQP 1.0 client] Setting system property qpid.sync_publish does not have the intended effect

git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk@1621076 13f79535-47bb-0310-9956-ffa450edef68
QPID-6050 : [JMS AMQP 1.0 client] Setting system property qpid.sync_publish does not have the intended effect

git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk@1621083 13f79535-47bb-0310-9956-ffa450edef68
QPID-6050 : [JMS AMQP 1.0 client] Allow system property for sync publish to be overridden at the connection level to restore "default" behaviour at the connection

git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk@1621084 13f79535-47bb-0310-9956-ffa450edef68
QPID-6050 : [JMS AMQP 1.0 client] Do not set the property in the ConnectionOptions object unless the System Property is actually present

git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk@1621105 13f79535-47bb-0310-9956-ffa450edef68
QPID-6051: Fix handling of exceptions thrown from post commit or deferred actions on transaction commit

git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk@1621106 13f79535-47bb-0310-9956-ffa450edef68
QPID-6052 : Use ADDR addresses for JMSDestination on incoming messages in 0-9-1 when the address mode is ADDR

git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk@1621143 13f79535-47bb-0310-9956-ffa450edef68
QPID-6051: Allow exceptions from post commit actions to be handled in the callers

git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk@1621146 13f79535-47bb-0310-9956-ffa450edef68
QPID-6052 : Use ADDR addresses for JMSDestination on incoming messages in 0-9-1 when the address mode is ADDR

git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk@1621148 13f79535-47bb-0310-9956-ffa450edef68
QPID-6052 : Use ADDR addresses for JMSDestination on incoming messages in 0-9-1 when the address mode is ADDR

git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk@1621149 13f79535-47bb-0310-9956-ffa450edef68
QPID-6052 : Use ADDR addresses for JMSDestination on incoming messages in 0-9-1 when the address mode is ADDR

git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk@1621150 13f79535-47bb-0310-9956-ffa450edef68
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
NO-JIRA: brokertest.py: don't use AMQP 1.0 if not available, ignore connection close teardown errors.

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