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