RFR: 8298526: The detection state allows records in the stopped state to be closed when JFR.stop [v3]

[Erik Gahlin]

On Sun, 11 Dec 2022 13:46:22 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> xpbob has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use stop cmd to check
>
> The reason this happens is because no filename was specified when using a duration. Without a filename, JFR could not dump the recording, so it decided to keep the data.
> 
> The error message is correct, but I understand what you want to achieve. There should be a away to remove/close a stopped recording. I'm not sure JFR.stop is the best way. Perhaps it is, but I can think of other ways as well:
> 
> 1. Require the user to specify filename when using duration (could potentially break scripts, but perhaps fine)
> 2. Generate a filename when using a duration without a filename
> 3. Close the recording after a JFR.dump to a stopped recording
> 4. Introduce JFR.close command
> 5. Close the recording when duration has happened, even if data was not dumped
> 
> More? 
> 
> Here is break-down of pros and cons of the six known ways (today) to approach this. 
> 
> **1. Require the user to specify filename when using duration**
> Pro:  This is likely what the user wants 
> Con: Can break existing scripts
> Con: Can't handle the generic case when a stopped recording is left behind
> Con: Prevents extraction of multiple dump files for a recording
> 
> **2. Generate a filename when using a duration without a filename**
> Pro: This is similar behavior as JFR.start dumponexit=true without a filename.
> Con: User may not find the file
> Con: Can't handle the generic case when a stopped recording is left behind
> Con: Prevents extraction of multiple dump files for a recording
> 
> **3. Close the recording after a JFR.dump to a stopped recording**
> Pro: Can handle the generic case when a stopped recording is left behind
> Pro: This is likely what user wants
> Con: Unintuitive if a recording is left behind. Why must I dump a recording to close it?
> Con: Prevents extraction of multiple dump files for a recording
> 
> **4. Introduce a JFR.close command**
> Pro: Can handle the generic case when a stopped recording is left behind
> Con: Makes JFR harder to use with more JFR commands. Close is not a very common scenario. 
> 
> **5. Close the recording when duration has happened, even if data was not dumped**
> Con: Confusing. Where is the recording data?
> Con: Can't handle the generic case when a stopped recording is left behind
> Con: Prevents extraction of multiple dump files for a recording
> 
> **6. Close a stopped recording with JFR.stop**
> Pro: Can handle the generic case when a stopped recording is left behind
> Con: Unintuitive. Why stop an already stopped recording?
> 
> It could be we need a combination.
> 
> One way to avoid users falling into the trap (1 or 2) and then some means to solve the generic case (3, 4 and 6).

> @egahlin Sorry for the late. Thanks for the detailed analysis I'm trying to use 2 and 6 Generate a file name and return it to the user

I discussed this with Markus and we also think 2 would be best, but not in combination with 6, but 5, perhaps if the recording is only closed if it has been started by jcmd. 

For now, it's perhaps sufficient stick with 2? And give it some more thought?

Alternative 2 alone will solve at least 9 out of 10 cases that users run into.

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

PR: https://git.openjdk.org/jdk/pull/11625