[
https://issues.apache.org/jira/browse/FLUME-2950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15369984#comment-15369984
]
ASF subversion and git services commented on FLUME-2950:
--------------------------------------------------------
Commit ba64b12670f7b2c9ce079f8898f4601689a51def in flume's branch
refs/heads/trunk from [~liorze]
[ https://git-wip-us.apache.org/repos/asf?p=flume.git;h=ba64b12 ]
FLUME-2950. ReliableSpoolingFileEventReader.rollCurrentFile is broken
FLUME-2939 introduced a Java 7 API (nio.file) to
ReliableSpoolingFileEventReader. However, the committed patch breaks
rollCurrentFile() on Windows machines. File rename might be not atomic,
in such cases, and under the assumption that the rolled file and the
current file store the same data, Flume only logs a warning and does not
assume that the user broke the contract that the spooling directory
source demands.
In order to determine whether the files store the same data, we used the
com.google.common.io.Files.equal() method. However, FLUME-2939 uses
java.nio.file.Files.isSameFile() which has different semantics.
Consequently, this relaxation does not hold anymore. In addition,
TestSpoolingFileLineReader.testDestinationExistsAndSameFileWindows
fails. This patch brings back the old check using Files.equal().
(Lior Zeno via Mike Percy)
> ReliableSpoolingFileEventReader.rollCurrentFile is broken
> ---------------------------------------------------------
>
> Key: FLUME-2950
> URL: https://issues.apache.org/jira/browse/FLUME-2950
> Project: Flume
> Issue Type: Bug
> Affects Versions: v1.7.0
> Reporter: Lior Zeno
> Assignee: Lior Zeno
> Fix For: v1.7.0
>
> Attachments: FLUME-2950-0.patch
>
>
> FLUME-2939 introduced Java 7 API (nio.file) to
> ReliableSpoolingFileEventReader. However, the committed patch breaks
> rollCurrentFile on Windows machines.
> File rename might be not atomic, in such cases, and under the assumption that
> the rolled file and the current file store the same data, Flume only logs a
> warning and does not assume that the user broke the contract that the
> spooling directory source demands.
> In order to determine whether the files store the same data, we used the
> com.google.common.io.Files.equal method. However, FLUME-2939 uses
> java.nio.file.Files.isSameFile which has different semantics.
> Consequently, this relaxation does not hold anymore. In addition,
> org.apache.flume.client.avro.TestSpoolingFileLineReader.testDestinationExistsAndSameFileWindows
> fails.
> I attach a patch that brings back the old check for Files.equal.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
