If someone familiar with the cluster code can review it first then I will
consider it for inclusion.
Robbie.
On 7 Aug 2012 15:22, "mick" <mgoul...@redhat.com> wrote:
> 0.18 request
> QPID-4194
>
>
> Very low risk 2-line change to Cluster.cpp, to enable queue events in
> CATCHUP mode.
>
> Otherwise a clustered broker, if it is a newbie that is in CATCHUP mode,
> and if it gets a message, and if there is a replication queue from this
> broker to somewhere else -- the newbie broker will fail to replicate the
> message. ( Which will cause it to get out of sync with the other
> broker(s) and kill itself. )
>
>
> Jira is not letting me in right now -- so I will show the diff here, and
> then put it in the Jira as soon as I can edit it.
>
>
>
> Index: qpid/cpp/src/qpid/cluster/Cluster.cpp
> ===================================================================
> --- qpid/cpp/src/qpid/cluster/Cluster.cpp (revision 1369959)
> +++ qpid/cpp/src/qpid/cluster/Cluster.cpp (revision 1369960)
> @@ -615,7 +615,6 @@
> void Cluster::setReady(Lock&) {
> state = READY;
> mcast.setReady();
> - broker.getQueueEvents().enable();
> enableClusterSafe(); // Enable cluster-safe assertions.
> }
>
> @@ -979,6 +978,13 @@
> map = *updatedMap;
> mcast.mcastControl(ClusterReadyBody(ProtocolVersion(),
> myUrl.str()), self);
> state = CATCHUP;
> + /* In CATCHUP mode the update has finished, and we are
> consuming
> + ** whatever backlog of messages has built up during the
> update.
> + ** We should enable queue events here, or messages that are
> received
> + ** during this phase will not be replicated properly. ( If
> there are
> + ** relevant replication queues. )
> + */
> + broker.getQueueEvents().enable();
> memberUpdate(l);
> // Must be called *after* memberUpdate() to avoid sending an
> extra update.
> failoverExchange->setReady();
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
> For additional commands, e-mail: dev-h...@qpid.apache.org
>
>
