[
https://issues.apache.org/jira/browse/FLUME-2068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13675245#comment-13675245
]
Roshan Naik commented on FLUME-2068:
------------------------------------
It seems we could ..
a) switch to a new checkpoint file_name instead of reusing the same name in the
case of a bad checkpoint. (if auto-recovery IS enabled)
b) grind to a halt (if auto-recovery is not enabled)
This will get the same code path + tests on both windows and unix. In option A,
attempt to delete old checkpoint file will be made (to avoid accumulation of
bad checkpoint files), but in ability to delete it will not be considered an
error.
> File Channel issue - recovering from BadCheckpoint exception on Windows
> -----------------------------------------------------------------------
>
> Key: FLUME-2068
> URL: https://issues.apache.org/jira/browse/FLUME-2068
> Project: Flume
> Issue Type: Bug
> Components: Channel, File Channel, Windows
> Affects Versions: v1.3.1
> Reporter: Roshan Naik
> Assignee: Roshan Naik
> Fix For: v1.4.0
>
>
> In EventQueueBackingStoreFileV3 constructor, if it detects that the
> checkpoint and meta files have differing logWriteOrderIds, it throws a
> BadCheckpointException. Controls goes back to the exception handler in
> Log.replay() which attempts to delete all the files in checkpoint directory
> and start fresh. The same file names are reused when starting fresh.
> Unfortunately this does not work on Windows since the deletion of the
> checkpoint file in the checkpointDir fails. The failure is due to the fact
> that the checkpoint file is memory mapped. Unless it is unmapped the deletion
> will not succeed... and unfortunately Java does not have unmap support.
> Windows does not permit deletion (or renaming) of files in use.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
