delta/python-packages/qpid-python.git/qpid/cpp/xml/cluster.xml, branch 0.8

Revert experimental cluster code, too close to 0.8 release.

2010-10-27T18:01:27+00:00

Reverts revisions:
r1023966 "Introduce broker::Cluster interface."
r1024275 "Fix compile error: outline set/getCluster fucntions on Broker."
r1027210 "New cluster: core framework and initial implementation of enqueue logic."

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

New cluster: core framework and initial implementation of enqueue logic.

2010-10-25T18:00:34+00:00

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

Fix bug in cluster with authentication: nodes exit with "unauthorized-access"

2010-07-20T19:56:42+00:00

Adding a node to a cluster on which authentication is enabled and on
which there are existing connections authenticated with mechanisms
other than anonymous, may result in nodes exiting the cluster with
inconsistent authorisation errors.


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

Defer delivery of messages in cluster-unsafe context.

2010-07-05T20:12:08+00:00

Messages enqueued in a cluster-safe context are synchronized across
the cluster.  However some messages are delivered in a cluster-unsafe
context, for example raising a link established event occurs the
connection thread of the establishing connection.

This fix deferrs such messages by multicasting them so they can be
re-delived in a cluster safe context.

See https://bugzilla.redhat.com/show_bug.cgi?id=611543


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

Fix regression in r956882, sporadic failures of client_test.cpp:testBadClientData

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

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

Fix cluster broker crashes when management is active.

2010-06-22T13:29:52+00:00

Cluser brokers were exiting with errors "modified cluster state
outside cluster context" and "confirmed < (50+0) but only sent < (49+0)"

Fix was to:
 - delay completion of incoming update till update connection closes.
 - delay addding new connections to managment until connection is announced.


git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk@956882 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

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

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 logging improvements: log config changes in the deliver thread.

2010-03-30T20:57:12+00:00

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