<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
Hi Erik,<br>
<br>
<font face="monospace"></font>
<blockquote type="cite">
<pre>Sometimes the size of a check point event can be larger than what can
fit in an integer (32-bits). Both the JDK and JMC parser read the size
field as a compressed long, but casts it to an int. In JMC, see
SeekableInputStream:
int CompressedIntsDataInput::readInt() throws IOException {
return (int) readCompressedLong();
}
ChunkLoaderV1::readConstantPoolEvent(...)
Today:
input.readInt(); // size
Should be changed to:
input.readLong(); // size
We are considering bumping the minor version (a non-breaking change) of
the file format, but we are not sure if it is necessary as it was already
treated as a long value by the JMC parser?
It's more of a problem for the JDK parser, it checks that the number of
bytes read matches that of the event size, but since it is already broken
for large check point events, a change will not make it more broken. See
this JDK bug for details:
<a href="https://bugs.openjdk.org/browse/JDK-8298129" class="moz-txt-link-freetext">https://bugs.openjdk.org/browse/JDK-8298129</a>
This change will not impact the size of ordinary events.
</pre>
</blockquote>
<font face="monospace"><br>
</font>I thought you should know that this issue is not purely
theoretical: it actually came up at a customer site, and they
reported that InvalidJfrFileException occurred for "multiple hosts
on production instances". This led to us providing them with a
short-term fix, and opening JDK-8297402. They're using their own jfr
reader, and using the JMC parser classes.<br>
<br>
It's possible that the customer would like to be able to read their
historical collection of JFRs using a single tool, and I believe the
new parser code for command line jfr and the JMC GUI will still fail
for any existing recordings that need more than 28 bits to encode an
integer value. If this doesn't make up your mind to bump the minor
version number, would you mind waiting to make a decision on this
until I've heard back from the customer to see if they need to
continue to read existing JFRs?<br>
<br>
Kind regards,<br>
Jason<br>
</body>
</html>