Github user aweisberg commented on a diff in the pull request:
https://github.com/apache/cassandra/pull/191#discussion_r168302781
--- Diff: src/java/org/apache/cassandra/net/MessagingService.java ---
@@ -1664,4 +1676,113 @@ public static boolean
isEncryptedConnection(InetAddressAndPort address)
}
return true;
}
+
+ public void blockForPeers()
+ {
+ // TODO make these yaml props?
+ int alivePercent = Integer.getInteger(Config.PROPERTY_PREFIX +
"blockForPeers.percent", 70);
+ if (alivePercent < 0)
--- End diff --
Well I think it really sucks when you think you are getting the benefit
from some config option and your not and you don't know or don't know why. Out
of scope arguments aren't really applicable because this is the ticket adding
the feature driven by these config options.
I am not sure what you mean by order of magnitude. The zero clamp means
someone tried to enable this feature, but didn't and so their stuff is silently
unreliable.
The 100 clamp is they meant to set a value < 100 but had an extra digit and
didn't and it's silently being slower to start. I doubt they are going to care
as much about that in production use cases.
I don't think you'll find many operators that complain about being informed
via a clear error message their config is not sane. This is also an option that
people have to request explicitly in order to get an invalid value to clamp in
the first place so I really do think they want to know.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: pr-unsubscr...@cassandra.apache.org
For additional commands, e-mail: pr-h...@cassandra.apache.org
