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