Uploaded image for project: 'Flume'
  1. Flume
  2. FLUME-2346

idLogFileMap in Log can lose track of file ids

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 1.4.0
    • Fix Version/s: 1.6.0
    • Component/s: File Channel
    • Labels:
      None

      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.

        Attachments

          Activity

            People

            • Assignee:
              jrufus Johny Rufus
              Reporter:
              szesch Steve Zesch
            • Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: