RFR: 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method [v3]

[Jason Mehrens]

On Tue, 18 Feb 2025 09:56:21 GMT, David Beaumont <duke at openjdk.org> wrote:

>I'm afraid I don't see how the double-check idea would work...

Yep. I missed that case.

>The other option is to just allow the lock to be dropped.

The other options are many.  Leader-follower pattern would allow FileHandler to not hold the lock during format and retain existing rotate/limit behavior.

Getting back to your earlier question on blocking behavior in Formatter.  Here are some examples I use:
1. ProcessBuilderFormatter. Subclasses include tasklist, netstat, sysinfo, so on which dumps output of those commands to string. Bursts of LogRecords can share a recent result to keep process creation under control.
2. ScreenshotFormatter. Uses java.awt.Robot to grab a screenshot. Then base64 encode the result. This Formatter requires one record per log file. This does the similar burst handling by sharing a recent result. I used this to reopen https://bugs.openjdk.org/browse/JDK-6219960
3. GraphicsFormatter. Paints all frames to an image and base64 encode it.
4. FileFormatter. Returns the contents of a file as a string.  Useful on Linux systems.

All of those formatters I pair with a filter and or attach to a specific logger as I'm listening for a trigger log record.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1960972400