You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@qpid.apache.org by ac...@apache.org on 2010/10/27 17:30:49 UTC

svn commit: r1028006 - in /qpid/trunk/qpid/cpp/src/qpid/cluster: new-cluster-active-passive.txt new-cluster-design.txt new-cluster-plan.txt

Author: aconway
Date: Wed Oct 27 15:30:49 2010
New Revision: 1028006

URL: http://svn.apache.org/viewvc?rev=1028006&view=rev
Log:
Updates to new cluster design.

Modified:
    qpid/trunk/qpid/cpp/src/qpid/cluster/new-cluster-active-passive.txt
    qpid/trunk/qpid/cpp/src/qpid/cluster/new-cluster-design.txt
    qpid/trunk/qpid/cpp/src/qpid/cluster/new-cluster-plan.txt

Modified: qpid/trunk/qpid/cpp/src/qpid/cluster/new-cluster-active-passive.txt
URL: http://svn.apache.org/viewvc/qpid/trunk/qpid/cpp/src/qpid/cluster/new-cluster-active-passive.txt?rev=1028006&r1=1028005&r2=1028006&view=diff
==============================================================================
--- qpid/trunk/qpid/cpp/src/qpid/cluster/new-cluster-active-passive.txt (original)
+++ qpid/trunk/qpid/cpp/src/qpid/cluster/new-cluster-active-passive.txt Wed Oct 27 15:30:49 2010
@@ -37,8 +37,8 @@ Simpler implementation of broker::Cluste
 - can use smaller message IDs: just sequence number. Can be implicit.
 
 Extra requirements:
+- Exactly one broker hast to take over if primary fails. 
 - Passive members refuse client connections and redirect to active member.
-- Choose new active member when the active dies.
 - On failover, clients keep trying till they find the active member.
 
 ** Active/active vs. active passive
@@ -47,6 +47,7 @@ Active/active benefits:
 - Total # connections: practical 60k limit per node.
 - Handle client losing connectivity to one cluster node - can fail over to any.
 - Some load sharing: reading from client + multicast only done on direct node.
+- Clients can switch to any broker
   
 Active/active drawbacks:
 - Co-ordinating message allocation impacts performance.
@@ -57,3 +58,4 @@ Active/passive benefits:
 Active/passive drawbacks:
 - Can't help clients with no connectivity to the active member.
 - Clients must find the single active node in failover.
+- May have gaps where no broker is active for some period of time.

Modified: qpid/trunk/qpid/cpp/src/qpid/cluster/new-cluster-design.txt
URL: http://svn.apache.org/viewvc/qpid/trunk/qpid/cpp/src/qpid/cluster/new-cluster-design.txt?rev=1028006&r1=1028005&r2=1028006&view=diff
==============================================================================
--- qpid/trunk/qpid/cpp/src/qpid/cluster/new-cluster-design.txt (original)
+++ qpid/trunk/qpid/cpp/src/qpid/cluster/new-cluster-design.txt Wed Oct 27 15:30:49 2010
@@ -349,6 +349,18 @@ can get better performance because we do
 or information about acquisition. We need to optimize this case to
 perform like an active-passive mode of replication.
 
+** Increasing Concurrency and load sharing
+The current cluster is bottlenecked by processing everything in the
+CPG deliver thread. By removing the need for identical operation on
+each broker, we open up the possiblility of greater concurrency.
+
+Handling multicast enqueue, acquire, accpet, release etc: concurrency per queue.
+Operatons on different queues can be done in different threads.
+
+The new design does not force each broker to do all the work in the
+CPG thread so spreading load across cluster members should give some
+scale-up.
+
 ** Misc outstanding issues & notes
 
 Replicating wiring

Modified: qpid/trunk/qpid/cpp/src/qpid/cluster/new-cluster-plan.txt
URL: http://svn.apache.org/viewvc/qpid/trunk/qpid/cpp/src/qpid/cluster/new-cluster-plan.txt?rev=1028006&r1=1028005&r2=1028006&view=diff
==============================================================================
--- qpid/trunk/qpid/cpp/src/qpid/cluster/new-cluster-plan.txt (original)
+++ qpid/trunk/qpid/cpp/src/qpid/cluster/new-cluster-plan.txt Wed Oct 27 15:30:49 2010
@@ -398,6 +398,10 @@ No integration with DTX transactions.
 ** TODO [#B] Make new cluster work with replication exchange.
 Possibly re-use some common logic. Replication exchange is like clustering
 except over TCP.
+** TODO [#B] Better concurrency, scalabiility on multi-cores.
+Introduce PollableQueue of operations per broker queue. Queue up mcast
+operations (enqueue, acquire, accept etc.) to be handled concurrently
+on different queue. Performance testing to verify improved scalability.
 ** TODO [#C] Async completion for declare, bind, destroy queues and exchanges.
 Cluster needs to complete these asynchronously to guarantee resources
 exist across the cluster when the command completes.



---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:commits-subscribe@qpid.apache.org