ctubbsii commented on code in PR #3083:
URL: https://github.com/apache/accumulo/pull/3083#discussion_r1026570442
##########
core/src/main/java/org/apache/accumulo/core/conf/Property.java:
##########
@@ -964,6 +964,11 @@ public enum Property {
"1.3.5"),
TABLE_ARBITRARY_PROP_PREFIX("table.custom.", null, PropertyType.PREFIX,
"Prefix to be used for user defined arbitrary properties.", "1.7.0"),
+ TABLE_MAJC_OUTPUT_DROP_CACHE("table.compaction.major.output.drop.cache",
"false",
+ PropertyType.BOOLEAN,
+ "Setting this property to true will call"
+ + "FSDataOutputStream.setDropBehind(true) on the major compaction
output stream.",
+ "2.1.1"),
Review Comment:
> I'm not sure we need to. There are plenty of examples of properties being
added in a patch release, including 4 of them added in version 1.9.3.
We should think about it and try to provide a strong justification for it.
Just because we've done it before doesn't mean it's a good idea in every case
(FWIW, I pushed back on at least 2 of those in 1.9.3). I'm not saying we can't
do it. I'm just suggesting that we give it due consideration first. The main
things to consider is risk of destabilizing changes in a patch release due to
newer features, and forward-compatibility expectations when rolling back (for
example, what is a reasonable user expectation when rolling back and the
property configured for 2.1.1 isn't recognized under 2.1.0).
In this case, a reasonable strong justification might be measurable
performance impact. If the performance impact is negligible or merely
hypothetical, or could be worse as easily as it could be better, then those are
reasons to hold off. But, if it's a clear benefit, and is safe to rollback to
2.1.0, minimal low-risk code changes, then that could add up to be a good
justification to include it in a patch release. For me, the question about the
measurable impact remains an unanswered one, which leaves me with reservations
for including it.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]