<div dir="ltr">Erik, I think in your case you'd be better served by a ConsistentHashFactory that always assigns at most one owner from each machine for each segment. <br><br>I guess the fix for ISPN-3140 should work as well, but it wouldn't be very straightforward: you'd have to keep the rebalancingEnabled attribute set to false by default, and you'd have to enable it temporarily every time you have a topology change that you do want to process. It's certainly possible to do this automatically from your app or from a monitoring daemon, but I'm pretty sure an enhanced topology-aware CHF would be a better fit.<br>
<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jun 7, 2013 at 1:45 PM, Erik Salter <span dir="ltr"><<a href="mailto:an1310@hotmail.com" target="_blank">an1310@hotmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'd like something similar. If I have equal keys on two machines (given an<br>
orthogonal setup and a TACH), I'd like to suppress state transfer and run<br>
with only one copy until I can recover my machines. The business case is<br>
that in a degraded scenario, additional replicas aren't going to buy me<br>
anything, as a failure will most likely be at the machine level and will<br>
cause me to lose data. Once I've recovered the other machine, I can turn<br>
back on state transfer to get my data redundancy.<br>
<span class="HOEnZb"><font color="#888888"><br>
Erik<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
-----Original Message-----<br>
From: <a href="mailto:infinispan-dev-bounces@lists.jboss.org">infinispan-dev-bounces@lists.jboss.org</a><br>
[mailto:<a href="mailto:infinispan-dev-bounces@lists.jboss.org">infinispan-dev-bounces@lists.jboss.org</a>] On Behalf Of Mircea Markus<br>
Sent: Tuesday, June 04, 2013 5:44 AM<br>
To: infinispan -Dev List<br>
Subject: Re: [infinispan-dev] Suppressing state transfer via JMX<br>
<br>
Manik, what's wrong with Dan's suggestion with clearing the cache before<br>
shutdown?<br>
<br>
On 31 May 2013, at 14:20, Manik Surtani <<a href="mailto:msurtani@redhat.com">msurtani@redhat.com</a>> wrote:<br>
<br>
>><br>
>> If we only want to deal with full cluster shutdown, then I think stopping<br>
all application requests, calling Cache.clear() on one node, and then<br>
shutting down all the nodes should be simpler. On start, assuming no cache<br>
store, the caches will start empty, so starting all the nodes at once and<br>
only allowing application requests when they've all joined should also work<br>
without extra work.<br>
>><br>
>> If we only want to stop a part of the cluster, suppressing rebalancing<br>
would be better, because we wouldn't lose all the data. But we'd still lose<br>
the keys whose owners are all among the nodes we want to stop. I've<br>
discussed this with Adrian, and we think if we want to stop a part of the<br>
cluster without losing data we need a JMX operation on the coordinator that<br>
will "atomically" remove a set of nodes from the CH. After the operation<br>
completes, the user will know it's safe to stop those nodes without losing<br>
data.<br>
><br>
> I think the no-data-loss option is bigger scope, perhaps part of<br>
ISPN-1394. And that's not what I am asking about.<br>
><br>
>> When it comes to starting a part of the cluster, a "pause rebalancing"<br>
option would probably be better - but again, on the coordinator, not on each<br>
joining node. And clearly, if more than numOwner nodes leave while<br>
rebalancing is suspended, data will be lost.<br>
><br>
> Yup. This sort of option would only be used where data loss isn't an<br>
issue (such as a distributed cache). Where data loss is an issue, we'd need<br>
more control - ISPN-1394.<br>
><br>
<br>
Cheers,<br>
--<br>
Mircea Markus<br>
Infinispan lead (<a href="http://www.infinispan.org" target="_blank">www.infinispan.org</a>)<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
<br>
_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
</div></div></blockquote></div><br></div>