ddanielr commented on code in PR #5399:
URL: https://github.com/apache/accumulo/pull/5399#discussion_r1991777365
##########
server/gc/src/main/java/org/apache/accumulo/gc/GarbageCollectWriteAheadLogs.java:
##########
@@ -266,37 +271,62 @@ private long
removeTabletServerMarkers(Map<UUID,TServerInstance> uidMap,
return result;
}
- private long removeFile(Path path) {
- try {
- if (!useTrash || !fs.moveToTrash(path)) {
- fs.deleteRecursively(path);
+ private void removeFile(ExecutorService deleteThreadPool, Path path,
AtomicLong counter,
+ String msg) {
+ deleteThreadPool.execute(() -> {
+ try {
+ log.debug(msg);
+ if (!useTrash || !fs.moveToTrash(path)) {
+ fs.deleteRecursively(path);
+ }
+ counter.incrementAndGet();
+ } catch (FileNotFoundException ex) {
+ // ignored
+ } catch (IOException ex) {
+ log.error("Unable to delete wal {}", path, ex);
}
- return 1;
- } catch (FileNotFoundException ex) {
- // ignored
- } catch (IOException ex) {
- log.error("Unable to delete wal {}", path, ex);
- }
-
- return 0;
+ });
}
private long removeFiles(Collection<Pair<WalState,Path>> collection, final
GCStatus status) {
+
+ final ExecutorService deleteThreadPool = ThreadPools.getServerThreadPools()
Review Comment:
Started looking at the WALStateManager code and realized my understanding of
the WAL log process was incorrect. While the GC does look at recovery directory
locations, the rest of the WAL information is stored in ZK.
After the WALs are processed, the WALStateManager is used to update ZK
references to the WAL files.
So the existing threadpool start/shutdown pattern makes sense here.
--
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
