6941923: RFE: Handling large log files produced by long runningJava Applications

Rainer Jung rainer.jung at kippdata.de
Thu Sep 22 04:55:19 PDT 2011


On 22.09.2011 13:20, Dmitry Samersoff wrote:
> 
> Yasumasa,
> 
> On 2011-09-22 04:47, Yasumasa Suenaga wrote:
>> If we can think Java on Linux and Solaris only, syslog is best solution.
>> However, Windows usually doesn't have syslog.
>>
>> So, I think that gclog is needed for logging GC stats with platform
>> independent in realtime.
> 
> Windows has it's own logging API as reach as syslog is or ever better
> as well as numerous syslog implementations.
> 
>   Native windows logging API was completely redesigned for Windows 2008
> server and now it allows for developers to send a structured events from
> theirs application.

AFAIK log rotation for loggc is already implemented though not
necessarily yet released. The change discussed here is about supporting
an externally generated rotation trigger, e.g. via a signal, instead of
only rotating by size or time via a startup parameter.

If you want support for syslog or Windows APIs included, it would be
best to start a new discussion.

A GC log for an application under load might easily produce a block of
about 1.5 KB size every few seconds. I seriously doubt, that the need
for log file rotation can be argued away by referring to syslog or
Windows log API as the correct solution.

The messages are not really line formatted, the format can vary a lot
(depending on the excat XX switches), the traffic can be quite high and
AFAIK the JVM writes it synchronously, so there must be absolutely no
risk in writing it out with very little latency. In addition, for
analysis, you wouldn't want to look at each event individually, but
instead process the whole file through a script or tool, which should
not depend on the output specifics of a platform specific log apparatus.

Regards,

Rainer



More information about the hotspot-gc-dev mailing list