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

[Erik Gahlin]

On Thu, 21 Aug 2025 18:12:46 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Did you look into adding a FlightRecorderListener and implementing recordingStateChanged to check if the RecordingState is CLOSED and then call close() on the stream? Or perhaps it would be better to set a flag and let the thread running the stream close itself after the next flush is complete.
>> 
>> For a RemoteRecordingStream there is a JMX notification that can be listened on.
>
>> @egahlin Could you please review this please? I added a listener-based mechanism that propagates external stop/close to the stream.
> 
> This will take me some time to go through. I'm a little bit worried about the locking, but I need to investigate, before I can comment further.

> @egahlin
> 
> I apologize. I forgot to fix some code I had been using to test the locking behavior and mistakenly committed it. I’ll correct this and push the changes soon.
> 
> I do have one question: is there a general preference between using synchronized and ReentrantLock? Personally, I lean toward ReentrantLock, since it can be safely used with virtual threads and may be easier to backport if needed.

The preference is to not use locks at all when callbacks (listeners) are being invoked as it could potentially lead to dead locks. Best would be if a flag can be set so the stream stops or closes itself at the next flush, but again, I haven't had time to look at it, so it might not be feasible.

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

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