[
https://issues.apache.org/jira/browse/IO-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13720991#comment-13720991
]
Casey Doerschuk commented on IO-279:
------------------------------------
Just wanted to confirm to anyone who cares, commons-io 2.4 tag with the April
patch attached to this JIRA, still has the issue in the scenerio we are using
it. We have a daemon network listener process written in C++ that opens a log
file, appends new data, closes the file, repeatedly, for which we are trying to
use the Tailer classes to pump the log through Kafka, similar to Herman in the
above thread. Using commons-io 2.4 prebuilt jar we were getting the
intermittent reatart on almost all hosts more than once a day. Using the
patched jar it happened less, but still happens. I am trying the forked version
in github published by Sergio. I will respond with my findings.
> 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, 2.4
> Reporter: Sergio Bossa
> Attachments: fix-tailer.patch, IO-279.patch, modify-test-fixed.patch,
> modify-test.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
