JEP 158: Unified JVM logging

[Kirk Pepperdine]

Hi Dmitry,

Neal Ford talk is call "Abstraction Distraction".. it's downloadable and you can see it here. http://vimeo.com/44235657

-- Kirk

On 2012-08-14, at 12:17 PM, Dmitry Samersoff <Dmitry.Samersoff at oracle.com> wrote:

> 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 ...
> 
> 

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