Hi,
Other softwares (e.g. syslog, apache) are implemented log rotation support.
When these software receives SIGHUP, they close current log and reopen it.
I think that JVM should be supported same level of log management at least.
Current implementation, JVM open logs at start, and never close it.
So we can't have timing of moving and archiving logs.
JVM have to run on Windows. However, Windows is not implemented signal trigger.
(BREAK is reserved for Thread-Dump)
Thus I think that JVM should have function of log rotation in multi-platform.
Thanks,
Yasumasa
On 2012/08/14 19:17, Dmitry Samersoff 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
