keith-turner commented on code in PR #3083:
URL: https://github.com/apache/accumulo/pull/3083#discussion_r1026334414
##########
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:
> Do we really need this? Why not just always set it, and it be cached
when read?
There could be unforseen negative consequences with always doing dropbehind.
Making it configurable give a an escape hatch for that. However maybe if we do
enough testing prior to releasing 2.1.1 we could always set it and be
comfortable with that from the testing. If it causes problems after release,
then would need a 2.1.2 though.
The following test may be useful.
1. Running concurrent query and compaction on the same table and measuring
the query times
2. Running query on one table and concurrent compactions on another table
and measuring query times.
Run both of the above test w/ and w/o compaction input/output drop behind
and compare the two.
Adding new props in each bug fix release has the potential to cause
confusion for anyone trying to use 2.1.X. For better or worse its something we
have done in many past bug fix releases. Its hard to assess the probability of
the new feature causing problems (and not having the escape hatch) vs the new
property causing confusion over time which causes its own problems. If we do
add a new prop for output, it seems like adding one for input may also be
useful if its not already done.
--
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]
