Creation of the localFS should not be in a static block. In the past also, we did this and realized it creates a kind of circular initialization of loggers and results in NPE while creating log objects which can be seen in task-logs.
Can you elaborate this? How will static initialization code result into circular initialization of loggers? How will this result into NPE?
Also can't we simply construct a local-filesystem here itself, instead of calling TaskLog.getLocalFileSystem()?
I'm getting the log file system through TaskLog.getLogFileSystem() to make sure that it is the same FileSystem used in TaskLog creation and deletion.
Rename the class to TaskLogsMonitor, so that we are consistent going forward with
The logscleanup thread is not joined/killed in the TaskTracker.close(). So, there will be zombie threads in the system on a re-init and may well interfere with the new thread.
TaskLogMonitor introduced in
MAPREDUCE-1100 is not a daemon thread, but TaskLogCleanupThread needs to be. I don't think we can merge the functionality of TaskLogCleanupThread and TaskLogMonitor into one thread.
TaskLogCleanupThread is not started after every re-init. It is started only once similar to taskCleanupThread, directoryCleanupThread. So, this should not be joined in TaskTracker.close().