| Summary: | DailyRollingFileAppender : log4j:ERROR Failed to rename | ||
|---|---|---|---|
| Product: | Log4j - Now in Jira | Reporter: | julien2412 <serval2412> |
| Component: | Appender | Assignee: | log4j-dev <log4j-dev> |
| Status: | RESOLVED FIXED | ||
| Severity: | critical | CC: | emilc77prof, kupci2, ras |
| Priority: | P3 | ||
| Version: | 1.2 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | All | ||
|
Description
julien2412
2004-06-21 19:55:39 UTC
This is definitely a "bug" in the java.io.File.renameTo() method. Sun think they have closed this problem in J2SE 5.0 (4167147) by changing the specification!!! Not much help to those of us in the real world, because they do not provide an alternative method. I've encountered the same symptoms with my webapp running under Tomcat on Win2kServer, WinNT4 and OS2. All 3 have "lazy write" file systems and seem to refuse the rename of the closed file becaase "it is busy". I've not encountered the same symptoms running my other log4j applications that do not use Tomcat, but perhaps I've just been lucky so far? There is a good workaround under the duplicate bug 13021. However, this workaround does not take account of the fact that BOTH DailyRollingFileAppender and RollingFileAppender (and others?) use java.io.renameTo(). We need a more generalised solution. I've coded a new "utility" superclass instance method FileAppender.safeRenameTo(String newName) based on the copy-and-zap-original strategy proposed in bug 13021. I've also coded changes to DailyRollingFileAppender and RollingFileAppender to use the new utility method. However, I don't like the change to RollingFileAppender because it copies every "old" log file to its new name... but at least it is safe! I'm happy to donate my changes, provided the committer for these classes thinks they are worth consideration. Please let me know. *** Bug 13021 has been marked as a duplicate of this bug. *** This seems to be similar or a duplicate of 900 Several suggestions on the proposed fix: Only do the copy/zap if File.renameTo() fails. Renaming is much cheaper when it works, particularly if the log file is large. If both the renaming AND copying fails, the new log file should be opened in append mode. This ensures that the existing log messages are not lost. Be careful about how the copying is done. It's safer and more efficient to do a binary copy using a reasonable buffer size rather than try to do a line-at-a-time text copy. This bug should be fixed in log4j version 1.3. *** Bug 900 has been marked as a duplicate of this bug. *** (In reply to comment #5) > This bug should be fixed in log4j version 1.3. We are currently experiencing this problem with version 1.2.8 on Windows 2000. We are hesitant to move log4j 1.3 alpha into production. What other options are there? Is there a fix for 1.2.x? Ceki, could you please confirm this bug is actually fixed in 1.3 and not in any 1.2.x version? Thx (In reply to comment #5) > This bug should be fixed in log4j version 1.3. Ceki, could you please confirm this bug is actually fixed in 1.3 and not in any 1.2.x version? Thx I checked myself, and found it was solved only in 1.3 for DRFA. For RFA, it has been solved in 1.2.15 too (see bug 41735). On another hand, now 1.3 has been abandoned. But its o.a.l.rolling.RollingFileAppender, that solved the problem, is available in companions / extras, which release 1.0 has been recently released. Please note that, though RFA and DRFA are deprecated in favor or o.a.l.rolling.RFA in 1.3, they are not deprecated in 1.2.15. |