commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Baron (Commented) (JIRA)" <>
Subject [jira] [Commented] (IO-279) Tailer erroneously consider file as new
Date Thu, 17 Nov 2011 23:57:54 GMT


Chris Baron commented on IO-279:

There are at least two additional causes that I've identified:

(1) "last" time stamp does not include time spent reading or listener handling.

last = System.currentTimeMillis();
position = readLines(reader);

readLines(...) continues to read and handle lines from the log until it reaches the EOF.

An erroneous truncation can be detected ff (a) content is added to the file between the recording
of the "last" timestamp and (b) before readLine encounters EOF and (c) no content is added
during the delay time.

The fix is to reverse the two lines such that the timestamp is recorded after the call to

(2) On very highly loaded system content could be written between the point the file length
is saved and the timestamp is compared.

The fix is to compare the file date to the "last" timestamp prior to checking its length and
to use that boolean result in the nested else if.

> Tailer erroneously consider file as new
> ---------------------------------------
>                 Key: IO-279
>                 URL:
>             Project: Commons IO
>          Issue Type: Bug
>    Affects Versions: 2.0.1
>            Reporter: Sergio Bossa
> Tailer sometimes erroneously consider 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:
> // 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;
>; // cannot be null here
>     // Now we can read new lines
>     last = System.currentTimeMillis();
>     position = readLines(reader);
> }
> 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:!default.jspa
For more information on JIRA, see:


View raw message