<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 1/30/25 9:42 AM, Kemper, William
wrote:<br>
</div>
<blockquote type="cite" cite="mid:1343e908588646dba4795a3a0de6be2c@amazon.com">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text -->
<style>.EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; }</style>
<meta content="text/html; charset=UTF-8">
<style type="text/css" style="">p
{margin-top:0;
margin-bottom:0}</style>
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:#000000; font-family:Calibri,Helvetica,sans-serif">
<p>Thank you all for your comments. We've gotten by using the
pid (%p) as a means of grouping log files from a process.
The log messages themselves include the uptime, so having
the start time of the JVM in the file name has not been
useful (and it would be trivial to add in from startup
scripts). I take your points about using the modification
time of the files and will consider this.</p>
</div>
</div>
</blockquote>
<br>
is not also the case that "trivial to add in from startup scripts"
also true for creation time?<br>
<br>
perhaps propose a new substitution variable instead of redefining
the existing one?<br>
<br>
e.g: %c<br>
<br>
- Larry<br>
<br>
<blockquote type="cite" cite="mid:1343e908588646dba4795a3a0de6be2c@amazon.com">
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:#000000; font-family:Calibri,Helvetica,sans-serif">
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> Laurence Cable
<a class="moz-txt-link-rfc2396E" href="mailto:larry.cable@oracle.com"><larry.cable@oracle.com></a><br>
<b>Sent:</b> Thursday, January 30, 2025 9:14:53 AM<br>
<b>To:</b> Kemper, William; serviceability-dev; David
Holmes; <a class="moz-txt-link-abbreviated" href="mailto:hotspot-runtime-dev@openjdk.org">hotspot-runtime-dev@openjdk.org</a><br>
<b>Subject:</b> RE: [EXTERNAL] Proposal to change the
behavior of the timestamp place holder (%t) in log file
paths</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">CAUTION: This email originated from
outside of the organization. Do not click links or open
attachments unless you can confirm the sender and know the
content is safe.<br>
<br>
<br>
<br>
On 1/29/25 5:56 PM, David Holmes wrote:<br>
> Adding back serviceability-dev<br>
><br>
> David<br>
><br>
> On 30/01/2025 11:55 am, David Holmes wrote:<br>
>> Plus one to what Kevin says. The current specified
behaviour seems to<br>
>> me to be what would be generally desired. If there
is a desire for a<br>
>> different kind of timestamp to be used then a
proposal to add that<br>
>> would be more appropriate I think. I seem to recall
something fairly<br>
>> recent about expanding the notion of "timestamp"
that can be used here.<br>
<br>
+2 for Kevin and David's observations; changing the
timestamp from JVM<br>
start time to create time, removes valuable and<br>
otherwise unobtainable (correlation) metadata from the
logfile names,<br>
file creation and modification time is available from the<br>
underlying O.S filesystem if needed.<br>
<br>
Rgds<br>
<br>
- Larry<br>
<br>
>><br>
>> David<br>
>><br>
>> On 29/01/2025 7:24 pm, Kevin Walls wrote:<br>
>>> Hi,<br>
>>><br>
>>> Just checking, but are they sure that's what
they want? 8-)<br>
>>><br>
>>> This relates to files from unified logging,
like java -<br>
>>> Xlog:gc*:file%t.out ...creates:
file2025-01-28_21-43-53.out and -<br>
>>> Xlog:help says, "If the filename contains %p,
%t and/or %hn, they<br>
>>> will expand to the JVM's PID, startup timestamp
and host name,<br>
>>> respectively."<br>
>>><br>
>>> (Administratively, I think unified logging is
under the runtime<br>
>>> group, cc’d.)<br>
>>><br>
>>> Using the JVM start time, across all log files,
identifies the set<br>
>>> of files that come from the same process. They
will generally sort<br>
>>> together when viewing a directory. If a single
file gets copied<br>
>>> around, it can still be traced back in its
group. When there are<br>
>>> multiple sets of logs in the same directory,
the sets should still<br>
>>> sort together. I see the filename purpose as
to identify the log,<br>
>>> or set of logs.<br>
>>><br>
>>> Using a new timestamp for each file, the
filenames do not identify<br>
>>> the files as being part of the same run. They
may sort together,<br>
>>> but may not if another log series is in the
same directory, and once<br>
>>> separated it's hard to regroup them.<br>
>>><br>
>>> Using the pid as well will help, but if we see
a lot of low-numbered<br>
>>> PIDs then this won't be unique. (With the
current startup timestamp,<br>
>>> you will probably use %p for pid in the file as
well, in case JVMs<br>
>>> start at the same moment.)<br>
>>><br>
>>> Thanks<br>
>>><br>
>>> Kevin<br>
>>><br>
>>> *From:*serviceability-dev
<a class="moz-txt-link-rfc2396E" href="mailto:serviceability-dev-retn@openjdk.org"><serviceability-dev-retn@openjdk.org></a> *On<br>
>>> Behalf Of *Kemper, William<br>
>>> *Sent:* Tuesday, January 28, 2025 7:54 PM<br>
>>> *To:* <a class="moz-txt-link-abbreviated" href="mailto:serviceability-dev@openjdk.org">serviceability-dev@openjdk.org</a><br>
>>> *Subject:* Proposal to change the behavior of
the timestamp place<br>
>>> holder (%t) in log file paths<br>
>>><br>
>>> The timestamp place holder in a log filename
currently expands to<br>
>>> the startup time of the JVM. When the log is
rotated, the filename<br>
>>> containing this timestamp is suffixed with a
file number. My<br>
>>> colleagues had expected the placeholder to be
evaluated when the<br>
>>> current log file is rotated. They expected the
name of each rotated<br>
>>> file to indicate the time the file was created.
I think this<br>
>>> expectation is not unreasonable, so I wanted to
discuss the<br>
>>> possibility of changing how/when the timestamp
placeholder is<br>
>>> evaluated. If there is any appetite for a
change like this, I am<br>
>>> willing to do the work. I would prefer to sort
out the details<br>
>>> before coding anything, rather than discussing
them in a surprise<br>
>>> pull request.<br>
>>><br>
>>> Thank you for reading,<br>
>>><br>
>>> William<br>
>>><br>
>><br>
><br>
<br>
</div>
</span></font>
</blockquote>
<br>
</body>
</html>