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

Jason Mehrens duke at openjdk.org
Wed Feb 12 19:47:14 UTC 2025


On Thu, 6 Feb 2025 12:07:57 GMT, David Beaumont <duke at openjdk.org> wrote:

> 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method.
> 
> 1. Remove synchronization of calls to publish() in Handlers in java.util.logging package.
> 2. Add explanatory comments to various affected methods.
> 3. Add a test to ensure deadlocks no longer occur.
> 
> Note that this change does not address issue in MemoryHandler (see JDK-8349208).

Changes requested by jmehrens at github.com (no known OpenJDK username).

src/java.logging/share/classes/java/util/logging/FileHandler.java line 755:

> 753:         synchronized(this) {
> 754:             flush();
> 755:             if (limit > 0 && (meter.written >= limit || meter.written < 0)) {

I don't think we want to write to meter.written and the re-aquire the monitor to then read meter.written.  Bytes written no longer corresponds to the formatted size of the current record. It could now include sum other records pending a rotate.

Any thought on creating a package private `StreamHandler::postPublish(LogRecord)` that is called from publish while holding monitor? Then FileHandler could just override that method to invoke flush, check, and rotate.

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

PR Review: https://git.openjdk.org/jdk/pull/23491#pullrequestreview-2613025345
PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1953295195


More information about the core-libs-dev mailing list