[jira] [Work logged] (IO-279) Tailer erroneously considers file as new
[
https://issues.apache.org/jira/browse/IO-279?focusedWorklogId=533751=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-533751
]
ASF GitHub Bot logged work on IO-279:
-
Author: ASF GitHub Bot
Created on: 10/Jan/21 04:15
Start Date: 10/Jan/21 04:15
Worklog Time Spent: 10m
Work Description: garydgregory closed pull request #40:
URL: https://github.com/apache/commons-io/pull/40
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 533751)
Time Spent: 1h (was: 50m)
> 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
>Priority: Major
> Attachments: IO-279.patch, disable_resetting.patch, fix-tailer.patch,
> modify-test-fixed.patch, modify-test.patch
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> 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 was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (IO-279) Tailer erroneously considers file as new
[
https://issues.apache.org/jira/browse/IO-279?focusedWorklogId=533681=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-533681
]
ASF GitHub Bot logged work on IO-279:
-
Author: ASF GitHub Bot
Created on: 10/Jan/21 04:08
Start Date: 10/Jan/21 04:08
Worklog Time Spent: 10m
Work Description: garydgregory commented on pull request #40:
URL: https://github.com/apache/commons-io/pull/40#issuecomment-756877640
No activity since 2017, closing.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 533681)
Time Spent: 50m (was: 40m)
> 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
>Priority: Major
> Attachments: IO-279.patch, disable_resetting.patch, fix-tailer.patch,
> modify-test-fixed.patch, modify-test.patch
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> 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 was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (IO-279) Tailer erroneously considers file as new
[
https://issues.apache.org/jira/browse/IO-279?focusedWorklogId=533127=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-533127
]
ASF GitHub Bot logged work on IO-279:
-
Author: ASF GitHub Bot
Created on: 08/Jan/21 17:04
Start Date: 08/Jan/21 17:04
Worklog Time Spent: 10m
Work Description: garydgregory closed pull request #40:
URL: https://github.com/apache/commons-io/pull/40
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 533127)
Time Spent: 40m (was: 0.5h)
> 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
>Priority: Major
> Attachments: IO-279.patch, disable_resetting.patch, fix-tailer.patch,
> modify-test-fixed.patch, modify-test.patch
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> 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 was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (IO-279) Tailer erroneously considers file as new
[
https://issues.apache.org/jira/browse/IO-279?focusedWorklogId=533126=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-533126
]
ASF GitHub Bot logged work on IO-279:
-
Author: ASF GitHub Bot
Created on: 08/Jan/21 17:04
Start Date: 08/Jan/21 17:04
Worklog Time Spent: 10m
Work Description: garydgregory commented on pull request #40:
URL: https://github.com/apache/commons-io/pull/40#issuecomment-756877640
No activity since 2017, closing.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 533126)
Time Spent: 0.5h (was: 20m)
> 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
>Priority: Major
> Attachments: IO-279.patch, disable_resetting.patch, fix-tailer.patch,
> modify-test-fixed.patch, modify-test.patch
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> 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 was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (IO-279) Tailer erroneously considers file as new
[
https://issues.apache.org/jira/browse/IO-279?focusedWorklogId=226080=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-226080
]
ASF GitHub Bot logged work on IO-279:
-
Author: ASF GitHub Bot
Created on: 11/Apr/19 12:14
Start Date: 11/Apr/19 12:14
Worklog Time Spent: 10m
Work Description: garydgregory commented on issue #40: IO-279: Added
ignoreNew parameter on instantiating Tailer.
URL: https://github.com/apache/commons-io/pull/40#issuecomment-482089524
Hi @Misiu,
Thanks for the ping.
I am -1 to this PR because:
- It breaks binary compatibility. You can tell since this build is broken.
See the red "All checks have failed" note on this page and the associated
Travis builds.
- It does not contain a unit test to test the new feature.
Gary
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 226080)
Time Spent: 20m (was: 10m)
> 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
>Priority: Major
> Attachments: IO-279.patch, disable_resetting.patch, fix-tailer.patch,
> modify-test-fixed.patch, modify-test.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> 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 was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Work logged] (IO-279) Tailer erroneously considers file as new
[
https://issues.apache.org/jira/browse/IO-279?focusedWorklogId=226075=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-226075
]
ASF GitHub Bot logged work on IO-279:
-
Author: ASF GitHub Bot
Created on: 11/Apr/19 11:56
Start Date: 11/Apr/19 11:56
Worklog Time Spent: 10m
Work Description: Misiu commented on issue #40: IO-279: Added ignoreNew
parameter on instantiating Tailer.
URL: https://github.com/apache/commons-io/pull/40#issuecomment-482084210
@garydgregory could You take a look at this PR?
We need this for openHAB -
https://github.com/openhab/openhab2-addons/issues/5442
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 226075)
Time Spent: 10m
Remaining Estimate: 0h
> 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
>Priority: Major
> Attachments: IO-279.patch, disable_resetting.patch, fix-tailer.patch,
> modify-test-fixed.patch, modify-test.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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 was sent by Atlassian JIRA
(v7.6.3#76005)
