FineAndDandy commented on code in PR #5726:
URL: https://github.com/apache/accumulo/pull/5726#discussion_r2198259164
##########
server/base/src/main/java/org/apache/accumulo/server/compaction/FileCompactor.java:
##########
@@ -560,9 +582,15 @@ private void compactLocalityGroup(String lgName,
Set<ByteSequence> columnFamilie
SystemIteratorEnvironment iterEnv =
env.createIteratorEnv(context, acuTableConf, getExtent().tableId());
- SortedKeyValueIterator<Key,Value> itr =
iterEnv.getTopLevelIterator(IteratorConfigUtil
- .convertItersAndLoad(env.getIteratorScope(), cfsi, acuTableConf,
iterators, iterEnv));
+ SortedKeyValueIterator<Key,Value> stack = null;
+ try {
+ stack = IteratorConfigUtil.convertItersAndLoad(env.getIteratorScope(),
cfsi, acuTableConf,
Review Comment:
Specifically in the context of compactors, I think we would want bad
configuration to drive the process dieing. This would only be expected at the
start of a compaction with a new configuration. Since the sole responsibility
of the compactor is to compact, it terminating is a very clear message it
cannot do that process. My understanding is that it would not impact existing
compactions in progress. In the absence of something like this we'd need
additional metrics that capture failed compactions so we could monitor that
state in addition to busy/idle. As-is we have to monitor for the impacts of
failing compactions cascading across the cluster, then go back to individual
compactor logs to determine who is healthy and who isn't after the fact. This
is much more complex than just checking which processes are down and pulling
their recent log history.
--
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: notifications-unsubscr...@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
