P3
JFR allow users to specify a directory where the disk repository should be located, for example:
-XX:FlightRecorderOptions:repository=/repository.
The JVM will create a directory in the specified directory by concatenating the current time and the pid, for example /repository/2021_03_03_01_55_24_7961
This works well with scripts, since each new JVM process will get its own directory.
JDK 14 introduced JEP 349: JFR: Event Streaming, which makes it possible to stream from a disk repository, for example:
public static void main(String[] args) {
Path path = args[0];
try (EventStream es = EventStream,openRepository(path)) {
es.onEvent( e-> { });.
es.start(),
}
}
Since the directory name is generated at runtime, it's not possible to pass the directory to the above Java program.
There exists two ways around this today. A user can do EventStream::openRespoitory() if the user wants to open a stream in the current process. For other processes, It's possible to use the Attach API to read the system property jdk.jfr.repository. The attach mechanism is cumbersome to use and may not work in container environments.
It's not possible to change -XX:FlightRecorderOption:repository=<path> so it points to a fixed directory due to existing applications expecting a directory per JVM process.
What we can do is to introduce another command-line option where users can set the directory.
Problem is to determine what it should be named (to not confuse users), perhaps fixed-repository, and decide what should happen if the repository already exists, or another JVM is using it.
Two alternatives:
1) Prevent the JVM to start, which may upset people, for example if the JVM crashes and the directory is left behind, and the script restarting the application will not work.
2) Use the directory and hope for the best. If another process is using the directory at the same time subtle issues may occur. For example, an emergency dump would dump all files in the repository regardless of which JVM that created the file.
None of the solutions are great and the reason the problem was not fixed when the JEP was integrated.
One idea is to allow EventStream.openRepository(Path) to use the latest created subdirectory by looking at file timestamp provided by the OS. If the current directory doesn't contain any .jfr files, but has a subdirectory on the form yyyy_MM_dd_HH_mm_ss_pid, use that instead.
More discussion is needed, feedback is welcomed.
-XX:FlightRecorderOptions:repository=/repository.
The JVM will create a directory in the specified directory by concatenating the current time and the pid, for example /repository/2021_03_03_01_55_24_7961
This works well with scripts, since each new JVM process will get its own directory.
JDK 14 introduced JEP 349: JFR: Event Streaming, which makes it possible to stream from a disk repository, for example:
public static void main(String[] args) {
Path path = args[0];
try (EventStream es = EventStream,openRepository(path)) {
es.onEvent( e-> { });.
es.start(),
}
}
Since the directory name is generated at runtime, it's not possible to pass the directory to the above Java program.
There exists two ways around this today. A user can do EventStream::openRespoitory() if the user wants to open a stream in the current process. For other processes, It's possible to use the Attach API to read the system property jdk.jfr.repository. The attach mechanism is cumbersome to use and may not work in container environments.
It's not possible to change -XX:FlightRecorderOption:repository=<path> so it points to a fixed directory due to existing applications expecting a directory per JVM process.
What we can do is to introduce another command-line option where users can set the directory.
Problem is to determine what it should be named (to not confuse users), perhaps fixed-repository, and decide what should happen if the repository already exists, or another JVM is using it.
Two alternatives:
1) Prevent the JVM to start, which may upset people, for example if the JVM crashes and the directory is left behind, and the script restarting the application will not work.
2) Use the directory and hope for the best. If another process is using the directory at the same time subtle issues may occur. For example, an emergency dump would dump all files in the repository regardless of which JVM that created the file.
None of the solutions are great and the reason the problem was not fixed when the JEP was integrated.
One idea is to allow EventStream.openRepository(Path) to use the latest created subdirectory by looking at file timestamp provided by the OS. If the current directory doesn't contain any .jfr files, but has a subdirectory on the form yyyy_MM_dd_HH_mm_ss_pid, use that instead.
More discussion is needed, feedback is welcomed.
