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]

Reply via email to