JEP 158: Unified JVM logging

Tue Aug 14 10:17:20 UTC 2012

Kirk,

> However I do have very serious concerns about this JEP in that it
> doesn't fix the problems that exist in current logging frameworks,
> it only mimics them.

> http://openjdk.java.net/jeps/158

Any comments is much appreciated.

Personally, I think that log rotation is out of scope and responsibility
of JVM.

-Dmitry

On 2012-08-14 13:26, Kirk Pepperdine wrote:
> Hi Yasumasa,
> 
> I'm not sure that log file rotation is a part of this JEP. 
> However I do have very serious concerns about this JEP in that it doesn't fix the problems that exist in current logging frameworks, it only mimics them.
> 
> Regards,
> Kirk
> 
> On 2012-08-14, at 11:20 AM, Yasumasa Suenaga <suenaga.yasumasa at lab.ntt.co.jp> wrote:
> 
>> Hi Staffan,
>>
>> May I ask you 2 questions about this JEP?
>>
>> 1. One of goals of this JEP is defined as following:
>>      "File rotation of log files by size (similar to what is available for GC logs today)"
>>    My patch realizes log rotation by external trigger.
>>    7090324 is included in this JEP?
>>    (Is 7090324 included in "Logging can be configured dynamically at runtime via jcmd or MBeans" ? )
>>
>> 2. I've posted a patch for "6950794: Make the GC log file name parameterized" .
>>      http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2012-July/004758.html
>>    Could you include this RFE in this JEP?
>>    If we use log rotation, I think that name of logs is very important for log management.
>>
>>
>> Thanks,
>>
>> Yasumasa
>>
>>
>> On 2012/08/14 16:50, Staffan Larsen wrote:
>>> 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 <mailto: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
>>>>>>>
>>>>>>
>>>>
>>>
>>
> 

-- 
Dmitry Samersoff
Java Hotspot development team, SPB04
* There will come soft rains ...