You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The DiagnosticCommands for JFR have a "name" and a "recording" parameter. The "recording" parameter is the id of the recording, which is what should be used in those commands where a recording or name are needed. The code currently uses "name" which works for most JVMs (if the name is not set then name is the recording id), but not all.
Observed on
java version "1.8.0_401"
Java(TM) SE Runtime Environment (build 1.8.0_401-b10)
Java HotSpot(TM) 64-Bit Server VM (build 25.401-b10, mixed mode)
Trying to dump a recording failed to produce a file, but did not produce any exceptions.
Steps to Reproduce
Expected Result
Actual Result
Component version
1.38.0
Log output
No response
Additional context
Observed with Microsoft's Application Insights 3.6.0
The text was updated successfully, but these errors were encountered:
dsgrieve
added a commit
to dsgrieve/opentelemetry-java-contrib
that referenced
this issue
Oct 10, 2024
Component(s)
No response
What happened?
Description
The DiagnosticCommands for JFR have a "name" and a "recording" parameter. The "recording" parameter is the id of the recording, which is what should be used in those commands where a recording or name are needed. The code currently uses "name" which works for most JVMs (if the name is not set then name is the recording id), but not all.
Observed on
Trying to dump a recording failed to produce a file, but did not produce any exceptions.
Steps to Reproduce
Expected Result
Actual Result
Component version
1.38.0
Log output
No response
Additional context
Observed with Microsoft's Application Insights 3.6.0
The text was updated successfully, but these errors were encountered: