commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sebb (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (IO-279) Tailer erroneously considers file as new
Date Sat, 20 Apr 2013 18:41:17 GMT

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

Sebb commented on IO-279:
-------------------------

The test seems wrong to me.
Only one line is written to the file, yet the check says:

{code}
assertEquals("1 line count", 2, lines.size());
{code}

Also, I'm not sure that changing the file modification date should be ignored.
How can one tell the difference between a file that has been touched from one that has been
re-written to the same length? 

Potentially it may even be the same data - that would be an unusual use-case, but not impossible.
For example, a rotating logger that records events but does not include a timestamp. The same
event sequence could recur.

A further problem with the test case in the patch is that it does not check the data, only
the line count.
                
> 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.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

Mime
View raw message