RFR: 8365066: RecordingStream and RemoteRecordingStream do not terminate when the associated Recording is stopped or closed externally

[Erik Gahlin]

On Sat, 9 Aug 2025 01:33:29 GMT, Chihiro Ito <cito at openjdk.org> wrote:

> Fix an issue where RecordingStream and RemoteRecordingStream do not stop when their underlying the local/remote recording stop. 
> 
> Introduce an internal EventSource abstraction to unify control across local (PlatformRecording) and remote (FlightRecorderMXBean) recordings, ensuring consistent propagation of stop/close and stop time to the consumer streams.
> 
> Tests updated to validate lifecycle consistency: 
> Verifies that stopping/closing the underlying recording (local and remote) properly stops/closes the corresponding stream.
> 
> Test: jdk/jdk/jfr

I've looked into the issue, and I'm not sure a RemoteRecordingStream should be closed if the underlying recording is.

- One use case for the RemoteRecordingStream is to replicate the repository on another host. When the monitored application exits (and closes the recording), the data should be available on another machine. If we close the stream, data will be lost (prematurely). I need to think about this some more.

- I don't think we need to do anything when the underlying recording is stopped for RemoteRecordingStream, since a stopped stream should wait until all events in the recording have been consumed. The DownloadThread will end when there is no more data to be read from FlightRecorderMXBean::readStream.

-  For a RecordingStream, I think Recording::stop/close can just delegate to RecordingStream::stop/close and we can get the exact same behavior as if the stream was stopped/closed.

I have implemented the above changes. You can look at it here https://github.com/openjdk/jdk/pull/27025

I noticed that the underlying Recording object may be exposed before the stream has been initialized, so I added synchronization. Now, any other thread trying to get a recording will have to wait for the RecordingStream initialization to complete.

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

PR Comment: https://git.openjdk.org/jdk/pull/26710#issuecomment-3240474514