[
https://issues.apache.org/jira/browse/IO-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504637#comment-13504637
]
Grzegorz Molenda commented on IO-279:
-------------------------------------
I am tailing with the fixed Tailer (commons-io 2.4.0) a log4j log file and I
still see the issue. Despite the fact that the log file was neither rotated nor
new data was added, the position is being reset to 0, causing the Tailer
re-reading the monitored file from the begining.
Since log4j's asynchronous logger is used to log into the monitored file, it
might happen, that the modifiedDate is set before the content is actually
flushed to the file.
I assume reseting position was added to cover the case, when the monitored file
is overriden. I think it is imposiilble for the Tailer to determine this. The
current implementation covers only the case, when the file length is equal to
the last read position. If the file legth after being overriden is higher than
the last read position, then the Tailer will assume data was normally appended
and process the file from the last read position.
Assuming the data is only appended to the file, I'd just get rid of the
reseting position feature from Tailer to resolve the issue finally.
> Tailer erroneously considers file as new
> ----------------------------------------
>
> Key: IO-279
> URL: https://issues.apache.org/jira/browse/IO-279
> Project: Commons IO
> Issue Type: Bug
> Affects Versions: 2.0.1
> Reporter: Sergio Bossa
> Fix For: 2.4
>
> Attachments: IO-279.patch
>
>
> Tailer sometimes erroneously considers the tailed file as new, forcing a
> repositioning at the start of the file: I'm still unable to reproduce this in
> a test case, because it only happens to me with huge log files during Apache
> Tomcat startup.
> This is the piece of code causing the problem:
> {code}
> // See if the file needs to be read again
> if (length > position) {
> // The file has more content than it did last time
> last = System.currentTimeMillis();
> position = readLines(reader);
> } else if (FileUtils.isFileNewer(file, last)) {
> /* This can happen if the file is truncated or overwritten
> * with the exact same length of information. In cases like
> * this, the file position needs to be reset
> */
> position = 0;
> reader.seek(position); // cannot be null here
> // Now we can read new lines
> last = System.currentTimeMillis();
> position = readLines(reader);
> }
> {code}
> What probably happens is that the new file content is about to be written on
> disk, the date is already updated but content is still not flushed, so actual
> length is untouched and there you go.
> In other words, I think there should be some better method to verify the
> condition above, rather than relying only on dates: keeping and comparing the
> hash code of the latest line may be a solution, but may hurt performances ...
> other ideas?
--
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
