Comment 4 for bug 1484598

I disagree with the priority of this bug. This is a low priority for me.

IMHO there is no way to code up a *reasonable* probe tests to demonstrate the described availability failure. Without a plausible scenario in context it's hard to really decide on the priority.

In reality - at worst you would expect only a single node to end up holding two fragments because of a rebalance [1]. It's only in this temporary period during a rebalance where one less than normal node availability failure could potentially impact the ability to service reads.

But that's the same as replicated today.

If you normally have two primaries that can service a read, during a rebalance you only have one - if that one is down - you have none.

More over, the situation where a rebalance results in a primary node holding two frags is the extremely uncommon case! Generally speaking you would expect the extra frag to be floating around on some old handoff node in the cluster with *no* chance of being found! We're optimizing in the wrong place! Bigger Fish!

1. unless you're rebalancing faster than your reconstructor cycle time