delta/python-packages/qpid-python.git/cpp/bindings, branch QPID-6125-ProtocolRefactoring

QPID-4575: VS2012 - fix cmake to allow in-source build where dirs source == binary

2014-09-14T01:15:53+00:00

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

QPID-4575: C++ Messaging .NET Binding fixes for Visual Studio 2012

2014-09-12T18:23:31+00:00

 Rename msvc10 folders to msvcx as they hold files 2010, 2012, ...
 Change projects/solutions to .in templates and cmake configure them.
 Collapse common example csproj files into common template.
 Add cmake BUILD_BINDING_DOTNET option setting.
 Fix up various scripts to accomodate new studio version.

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

Test commit using git-svn

2014-09-12T15:24:21+00:00

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

QPID-5975: HA extra/missing messages when running qpid-txtest2 in a loop with failover.

2014-08-28T21:47:44+00:00

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

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

2014-08-27T13:23:21+00:00

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

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

2014-08-26T21:22:10+00:00

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

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

2014-08-25T20:10:52+00:00

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

QPID-5893: Perl unit tests now find the utils module.

2014-08-20T17:46:29+00:00

The module's not on the @INC path, and really shouldn't be since it's
only used by the tests. So now the tests programmatically update @INC to
include their directory as a part of the path, and find utils.pm.

Fixed the failing Message.t file as well, which includes tests for
methods that are deprecated.

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

QPID-5964: Add SetContentObject support for list and map.

2014-08-05T19:58:15+00:00

Fix GetContentObject return value warning.

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

NO-JIRA: Perl Receiver returning an unwrapped Message object.

2014-07-31T13:46:29+00:00

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