[jira] [Commented] (IO-279) Tailer erroneously considers file as new

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[jira] [Commented] (IO-279) Tailer erroneously considers file as new

Phil Steitz (Jira)

    [ https://issues.apache.org/jira/browse/IO-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13637882#comment-13637882 ]

Herman Meerlo commented on IO-279:
----------------------------------

I totally agree, it is very hard to discriminate between the different use cases. It might only be possible with Java 7. What do you mean with (cf. backup) by the way?

My case occurs on Linux (Debian) where I wrote a tool to tail GlassFish log files and out put them to Kafka. Every now and then it spits out the entire log file again, which makes the Tailer useless for me. I have a suspicion that the problem might be related to the fact that the 'last' is set to System.currentTimeMillis() instead of to file.lastModified(). Maybe there is a granularity difference between the two, where the FS rounds the last modified upwards? If I stat the file then it always has a 1 sec precision. That would explain it I guess. I will patch it here and run a test today.
               

> 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
>             Fix For: 2.4
>
>         Attachments: 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