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

[xpbob]

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

jcmd 14710 JFR.start duration=10s 
14710:
Started recording 2. The result will be written to:

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

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