I think Bookkeeper-833 is irrelevant, no? Even it is Long.MAX, it would still have the roll over problem.
The question is - is this really an issue? When roll over happen, it might cause an entry log file won't be garbage collected or compacted in this lifecycle of the bookie. But it doesn't actually impact correctness, right? - Sijie On Thu, Apr 27, 2017 at 3:27 PM, Charan Reddy G <reddychara...@gmail.com> wrote: > Hey, > > With Bookkeeper-833 Bug (https://github.com/apache/bookkeeper/commit/ > da1a2fa6b19ddcdba68834147bf6afbe5bf90cbf), entryLogId in EntryLogger is > capped at Int.MAX, so preallocatedLogId rolls over to 0 after reaching > Int.MAX. In EntryLogger.flushRotatedLogs we set "leastUnflushedLogId = > flushedLogId + 1;", so it makes leastUnflushedLogId also to roll over. But > this affects the GarbageCollectorThread.extractMetaFromEntryLogs logic. > This method extracts EntryLogMetadata from the newly rotated entrylogs, but > when rollover happens this logic seems to be broken > > in GarbageCollectorThread.java > > protected Map<Long, EntryLogMetadata> extractMetaFromEntryLogs(Map<Long, > EntryLogMetadata> entryLogMetaMap) { > // Extract it for every entry log except for the current one. > // Entry Log ID's are just a long value that starts at 0 and > increments > // by 1 when the log fills up and we roll to a new one. > long curLogId = entryLogger.getLeastUnflushedLogId(); > <------when rollover happens, this will start from 1 > boolean hasExceptionWhenScan = false; > for (long entryLogId = scannedLogId; entryLogId < curLogId; > entryLogId++) { <------- because of "entryLogId < curLogId" condition it > will skip the newly rotated logs > > Thanks, > Charan >
