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.samers...@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.yasum...@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.yasum...@lab.ntt.co.jp >>>> <mailto:suenaga.yasum...@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 ... > >
