[FLUME-2346] idLogFileMap in Log can lose track of file ids

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 1.4.0
• Fix Version/s: 1.6.0
• Component/s: File Channel
• Assignee: Johny Rufus
• Reporter: Steve Zesch
• Created: 11/Mar/14 19:03
• Updated: 17/Apr/15 01:21
• Resolved: 09/Oct/14 23:11

Description

The following code from Log's writeCheckpoint method can lose track of file ids to Reader mappings which will lead to a NPE being thrown in subsequent calls to writeCheckpoint.

Log#writeCheckpoint

Iterator<Integer> idIterator = logFileRefCountsAll.iterator();
while (idIterator.hasNext()) {
    int id = idIterator.next();
    LogFile.RandomReader reader = idLogFileMap.remove(id);
    File file = reader.getFile();
    reader.close();
    LogFile.MetaDataWriter writer =
            LogFileFactory.getMetaDataWriter(file, id);
    try {
        writer.markCheckpoint(logWriteOrderID);
     } finally {
        writer.close();
    }
    reader = LogFileFactory.getRandomReader(file, encryptionKeyProvider);
    idLogFileMap.put(id, reader);
    LOGGER.debug("Updated checkpoint for file: " + file
            + "logWriteOrderID " + logWriteOrderID);
    idIterator.remove();
}

The problem occurs when writer.markCheckpoint throws an exception and the id -> reader mapping is not added back to idLogFileMap. The next time writeCheckpoint is called logFileRefCountsAll still contains the file id, but idLogFileMap.remove(id) returns null since the id is no longer in the map. Attempting to call reader.getFile() then throws a NPE.

Is there a reason that the initial reader obtained from idLogFileMap is closed and then a new reader for the same file is later created an inserted into the map? If that is not required, then one possible solution would be to remove this logic and not remove the id -> reader mapping in idLogFileMap. If that logic is required, then perhaps the code to insert a new id -> reader mapping into idLogFileMap could be added to the finally block.