RFR: 8307526: [JFR] Better handling of tampered JFR repository [v2]

[Joakim Nordström]

On Wed, 14 Jun 2023 12:21:58 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Joakim Nordström has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
>> 
>>  - Merge
>>  - 8307526: [JFR] Better handling of tampered JFR repository
>>  - 8307526: [JFR] Better handling of tampered JFR repository
>>  - 8307526: [JFR] Better handling of tampered JFR repository
>>  - 8307526: [JFR] Better handling of tampered JFR repository
>>  - 8307526: [JFR] Better handling of tampered JFR repository
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/RepositoryChunk.java line 202:
> 
>> 200:         String message = "Chunkfile \""+ chunkFile.toString() + "\" is missing.";
>> 201:         Logger.log(LogTag.JFR, LogLevel.ERROR, message + " Data loss might occur from " + startTime.toString() + (endTime != null ? " to " + endTime.toString() : ""));
>> 202:         ErrorThrownEvent.commit(startTime.getNano(), endTime != null ? Duration.between(startTime, endTime).toNanos() : 0L, message, MissingChunkFileError.class);
> 
> The event timing is in ticks, not nanos, so the time would not be correct.. I think it would be best to skip the MissingChunkFileError event completely and rely on the log.

I've skipped the MissingChunkFileError event when finding missing files during dumping (it would've only shown up in subsequent recordings anyways, so of little use). I instead throw the error when finding missing files in-flight; I think it's important to have something that hints to user that a recording might be missing data, and the error will show up in the recording that might be missing some data.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14360#discussion_r1230952579