delta/python-packages/qpid-python.git/qpid/cpp/src/tests/cluster_test.cpp, branch qpid-2935

QPID-2935: sync with latest trunk

2011-02-17T14:08:14+00:00

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

Fix test bug causing occasional failure of cluster_test.

2010-06-24T17:19:24+00:00

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

Cluster handle connection-negotiation phase in local broker.

2010-06-08T15:31:31+00:00

The connection negotiation phase up to the "open" or "open-ok" frame
establishes whether/what encryption to use for the rest of the
connection.

With this patch a cluster broker completes the initial negotiation
with its local clients and only then begins multicasting to other
brokers. The local broker decrypts if necessary and multicasts in the
clear.

This replaces a problematic locking scheme that was formerly in place
which caused deadlocks.


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

QPID-2631: For blocking Bounds::expand() calls, only increase the current count when there is space. In SessionImpl::send() expand bounds before queueing frame. Expand bounds for all frames sent (including connection frames and cluster specific frames).

2010-05-27T18:09:13+00:00

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

Cluster + Security

2010-05-14T08:56:45+00:00

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

* initial observation of a problem was a 2% failure rate in perftests
of 20,000 messages against a cluster with security enabled.
Problem was occasional receit of encrypted frames before the
security codec had been enabled. This is fixed with locking in
cluster code (no new locks in broker code) and a callback that is
fired by broker::ConnectionHandler::Handler to tell the cluster
code when the opening handshake has finished.
This was never a problem in the non-clustered broker before because
everything happened in a single thread.

* the brokers that "shadow" the connection must not have null
authenticators rather than real ones, so that they go through all
the motions but don't do anythig. Only the directly-connected
broker can perform the security handshake.

* once the directly-connected broker receives the real user ID
from its callback, it mcasts that ID to all other brokers.
Otherwise the shadowing brokers will al think that the user ID
is "anonymous".
Check this by doing a substantial perftest, and using
qpid-stat -c localhost:PORT
to confirm that the brokers all have the same userID for the
same connection.

* the user ID, negotiated during the Sasl security startup, is
communicated from the directly connected broker to all other
cluster brokers.

* If security is *not* being used, then this code should *not* tell
the brokers anything about the userID -- or it will step on the value
that is being set by other code pathways.

* test program at cpp/src/tests/cluster_authentication_soak is not yet
fully automated -- run it with something like
"sudo ./cluster_authentication_soak 500"

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

Use UnauthorizedAccessException for ACL violations rather than NotAllowedException

2010-05-06T09:49:45+00:00

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

Cluster: remove un-necessary code for config-seq.

2010-03-31T16:52:50+00:00

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

Cluster: fix update of failover exchange.

2010-02-02T15:47:41+00:00

During update the cluster was sending an extra update to the failover exchange.


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

Fix intermittent test error: cluster_test.cpp(1108): error in "testRelease": check browse(c3, "q", 5) == expected failed [ != m_1 m_2 m_3 m_4 m_5 ]

2010-01-19T16:13:06+00:00

This was a test issue, not a broker issue. What seems to have been happening:
 - start broker b0 & send messages.
 - fork broker b1
 - line 1103 (lqSub.release(...)); executes against b0 _before_ b1 connects for update         lqSub.release(lqSub.getUnaccepted());
 - line 1108 browse() executes during the update.
 - update takes > 0.5 secs for some reason, browse times out.

The fix is a synchronous flush in browse() which will wait for the broker to be responsive before trying to get the messages.


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

QPID-2296: Cluster errors when using acquire-mode-not-acquired

2009-12-22T14:22:17+00:00

Replicate consumer's queue position to new cluster nodes.


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