On 1/29/25 5:56 PM, David Holmes wrote:
Adding back serviceability-dev
David
On 30/01/2025 11:55 am, David Holmes wrote:
Plus one to what Kevin says. The current specified behaviour seems to
me to be what would be generally desired. If there is a desire for a
different kind of timestamp to be used then a proposal to add that
would be more appropriate I think. I seem to recall something fairly
recent about expanding the notion of "timestamp" that can be used here.
+2 for Kevin and David's observations; changing the timestamp from JVM
start time to create time, removes valuable and
otherwise unobtainable (correlation) metadata from the logfile names,
file creation and modification time is available from the
underlying O.S filesystem if needed.
Rgds
- Larry
David
On 29/01/2025 7:24 pm, Kevin Walls wrote:
Hi,
Just checking, but are they sure that's what they want? 8-)
This relates to files from unified logging, like java -
Xlog:gc*:file%t.out ...creates: file2025-01-28_21-43-53.out and -
Xlog:help says, "If the filename contains %p, %t and/or %hn, they
will expand to the JVM's PID, startup timestamp and host name,
respectively."
(Administratively, I think unified logging is under the runtime
group, cc’d.)
Using the JVM start time, across all log files, identifies the set
of files that come from the same process. They will generally sort
together when viewing a directory. If a single file gets copied
around, it can still be traced back in its group. When there are
multiple sets of logs in the same directory, the sets should still
sort together. I see the filename purpose as to identify the log,
or set of logs.
Using a new timestamp for each file, the filenames do not identify
the files as being part of the same run. They may sort together,
but may not if another log series is in the same directory, and once
separated it's hard to regroup them.
Using the pid as well will help, but if we see a lot of low-numbered
PIDs then this won't be unique. (With the current startup timestamp,
you will probably use %p for pid in the file as well, in case JVMs
start at the same moment.)
Thanks
Kevin
*From:*serviceability-dev <serviceability-dev-r...@openjdk.org> *On
Behalf Of *Kemper, William
*Sent:* Tuesday, January 28, 2025 7:54 PM
*To:* serviceability-dev@openjdk.org
*Subject:* Proposal to change the behavior of the timestamp place
holder (%t) in log file paths
The timestamp place holder in a log filename currently expands to
the startup time of the JVM. When the log is rotated, the filename
containing this timestamp is suffixed with a file number. My
colleagues had expected the placeholder to be evaluated when the
current log file is rotated. They expected the name of each rotated
file to indicate the time the file was created. I think this
expectation is not unreasonable, so I wanted to discuss the
possibility of changing how/when the timestamp placeholder is
evaluated. If there is any appetite for a change like this, I am
willing to do the work. I would prefer to sort out the details
before coding anything, rather than discussing them in a surprise
pull request.
Thank you for reading,
William
