7090324: gclog rotation via external tool

[Staffan Larsen]

Hi Yasumasa,

This work should be done in the context of the Unified Logging JEP [1]. Unfortunately, that work has not yet started due to resource constraints. Comments on the proposal are welcome.

[1] http://openjdk.java.net/jeps/158

/Staffan

On 31 jul 2012, at 12:45, Yasumasa Suenaga <suenaga.yasumasa at lab.ntt.co.jp> wrote:

> Hi,
> 
> I've posted a patch for gc log rotation via jinfo tool last year.
> Then I received an email that essence of my patch will be implemented as
> "subcommands" of jcmd.
> 
> Now, jcmd is provided by OpenJDK. However, current jcmd does not seem to
> implement function of gclog rotation.
> 
> Will this RFE be implemented?
> 
> I need to rotate gclog which is synchronized with signal, cron, etc... on Linux.
> So, if this RFE is not implemented for a while, I would like to contribute
> patch for jcmd.
> 
> 
> Regards,
> 
> Yasumasa
> 
> 
> On 2011/09/29 21:15, James Melvin wrote:
>> Hi Yasumasa,
>> 
>> Thanks very much for your OpenJDK contribution! As part of the effort to
>> port JRockit features to HotSpot, we plan to introduce a consolidated
>> commandline serviceability tool (jcmd) to potentially replace many of
>> the existing tools in the bin directory, such as jmap, jstack, jinfo and
>> others. Over the next few update releases, we plan to add several jcmd
>> *subcommands* instead to accomplish specific tasks or affect the running
>> JVM instance. We'd like to use the essence of your contribution in one
>> of the jcmd subcommands (instead of extending jinfo) to ask the JVM to
>> begin rotating GC logs. We hope you find this attractive and hope you
>> will help review and perfect the change.
>> 
>> Thanks,
>> 
>> Jim Melvin
>> Sr. Engineering Manager
>> Oracle
>> 
>> 
>> 
>> On 9/26/11 6:38 AM, Yasumasa Suenaga wrote:
>>> (I've changed subject of this email to new RFE.)
>>> 
>>> This RFE is enhancement of current gclog implementation.
>>> So, I'd like to discuss about rotating gclog.
>>> 
>>> My customers need gclog rotation which is invoked by external trigger.
>>> So I've requested this RFE and made a patch.
>>> 
>>> 
>>> In many case on Linux, logfile is rotated by signal (e.g. SIGHUP) .
>>> The aim of this RFE is to synchronize gclog and the other logs.
>>> 
>>> 
>>> Thanks,
>>> 
>>> Yasumasa
>>> 
>>> (2011/09/22 20:55), Rainer Jung wrote:
>>>> 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
>>>> 
>>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120814/29f831f1/attachment.html