Request for review: 6941923: RFE: Handling large logfiles produced by long running Java Applications
jesper.wilhelmsson at oracle.com
Mon May 9 01:40:34 PDT 2011
Appending rather than overwriting would not fix the problem you mention. Since
we are talking about a rotating log file, the old log would be overwritten
Also, if we append, it would be virtually impossible for the average user to
find where the new log starts. As a matter of fact, I'm not sure how that
would work in this new scheme either... One would have to look at the file
creation dates I assume. But at least when overwriting, the content of the log
files would only belong to one JVM run.
There are a few other ways to keep the old log around that I think would make
more sense than opening the log in append mode:
* If the JVM finds an old log file at startup it could warn, possibly even
refuse to start. (... and destroy quite a few customer installations out there
that relies on restarting the JVM instantly if it goes down.)
* If an old logfile is found at startup the JVM could rename the old log by
adding its creation date or something. (... and start filling the disk with
old log files.)
I think all of the above (including appending the log file) could be
interesting features to have behind a flag. But I doubt that any of the
alternatives would be a preferred default behavior for Hotspot.
On 05/07/2011 02:36 PM, Rainer Jung wrote:
> I know this is not directly the topic of this page, but I think it is directly
> related: gc log files are opened for write, but not append. So each time the
> jvm is started, previous log files get overwritten. This is especially bad,
> since often when something goes wrong admins try to fix by restarting, thus
> overwriting the old gc data and making a posteriori analysis impossible.
> Of course more advanced admins have learned, that they should not use a fixed
> file name for the gc log file name, but instead add some startup timestamp to
> the file name chosen for -Xloggc, thus starting the JVM with a new file each
> time (or copying the old file before restart).
> But I expect lots of admins are still not aware of this problem.
> I guess not opening the file for append was either an omission from the
> beginning, or an inadequate measure to cope with large gc logs by at least
> purging them during each JVM restart. The latter - handling large gc log files
> - is the topic of this RFE.
> So I suggest to open the log files for append in order to not have overwritten
> important analytical data on each restart. I know it is an incompatible change
> of behaviour, but that part of the behaviour was never specified and I
> personally expect more users to see a benefit in the change than not.
More information about the hotspot-gc-dev