ISPN-3140 only mentions suspending state transfer. The partial
cluster shutdown scenario is part of ISPN-1394. Doesn't it make sense to merge them?
ISPN-3140 (manually suppressing state transfer) is regardless of partial or complete
shutdown. My example only detailed a full shutdown scenario, but applies in the case of a
partial shutdown as well.
ISPN-1394 is much bigger - it covers not just suppressing state transfer but also
initiating state transfer, which is much more complex IMO.
Cheers
Adi
On 05/31/2013 03:52 PM, Dan Berindei wrote:
> If we only want to deal with full cluster shutdown, then I think stopping all
application requests, calling Cache.clear() on one node, and then shutting down all the
nodes should be simpler. On start, assuming no cache store, the caches will start empty,
so starting all the nodes at once and only allowing application requests when they've
all joined should also work without extra work.
>
> If we only want to stop a part of the cluster, suppressing rebalancing would be
better, because we wouldn't lose all the data. But we'd still lose the keys whose
owners are all among the nodes we want to stop. I've discussed this with Adrian, and
we think if we want to stop a part of the cluster without losing data we need a JMX
operation on the coordinator that will "atomically" remove a set of nodes from
the CH. After the operation completes, the user will know it's safe to stop those
nodes without losing data.
>
> When it comes to starting a part of the cluster, a "pause rebalancing"
option would probably be better - but again, on the coordinator, not on each joining node.
And clearly, if more than numOwner nodes leave while rebalancing is suspended, data will
be lost.
>
> Cheers
> Dan
>
>
>
> On Fri, May 31, 2013 at 12:17 PM, Manik Surtani <msurtani(a)redhat.com> wrote:
> Guys
>
> We've discussed ISPN-3140 elsewhere before, I'm brining it to this forum
now.
>
>
https://issues.jboss.org/browse/ISPN-3140
>
> Any thoughts/concerns? Particularly looking to hear from Dan or Adrian about
viability, complexity, ease of implementation.
>
> Thanks
> Manik
> --
> Manik Surtani
> manik(a)jboss.org
>
twitter.com/maniksurtani
>
> Platform Architect, JBoss Data Grid
>
http://red.ht/data-grid
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev