See org.apache.accumulo.gc.replication.CloseWriteAheadLogReferences for
where WALs are currently marked as "closed".
I don't recall the details, but I think there was some issue with trying
to close them in TabletServerLogger.
Yes to your last question: if it were done in TabletServerLogger, it
would be closed more quickly than done by the GC. The issue is whether
or not it's actually safe to mark them as closed there. I just don't
remember the internal WAL lifecycle well enough.
Noe Detore wrote:
Hello,
I trying to influence replication latency with tserver.walog.max.age.
But noticing no difference when setting the value low. Looking in the
code of org.apache.accumulo.tserver.log.TabletServerLogger:
protected void closeForReplication(Collection<CommitSession> sessions) {
// TODO We can close the WAL here for replication purposes
}
This to do is called by :
testLockAndRun(logSetLock, new TestCallWithWriteLock() {
@Override
boolean test() {
return (logSizeEstimate.get() > maxSize) ||
((System.currentTimeMillis() - createTime) > maxAge);
}
@Override
void withWriteLock() throws IOException {
close();
closeForReplication(sessions);
}
});
return seq;
}
I am still trying to understand what is happening here, but could this
TODO be the reason replication status records are not being updated with
'closed: true' sooner ?
Thank you
Noe
