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

[Jason Mehrens]

On Fri, 14 Feb 2025 10:46:08 GMT, David Beaumont <duke at openjdk.org> wrote:

>> I've looked through a lot of github logging properties files and see no evidence that the pattern of use you're suggesting is ever actually done, and any such attempt to force one-log-per-file is entirely unsupported by the existing specification already. Can you give me an example of a real-world case where there's a debug log format which "only makes sense to contain a single record"?
>> I'm not doubting that you've seen this, but if we're going to complicate the code somewhat over this issue, I need to be able to explain that it's actually likely to affect real-world users, rather than purely hypothetical ones.
>
> The reason I'm pushing back a little here is that the idea of making a "secret handshake" method between StreamHandler and FileHandler isn't a solution for anyone who made their own handler (e.g. an "EncryptedLogFileHandler" that's not a sub-class of FileHandler). The shape of the existing public API makes the additional promise that "post-processing" occurs synchronously with the last log written hard/impossible, and having it so only JDK classes can do this feels a bit wrong to me.
> 
> In other words, if you can convince me it's worth doing something to make FileHandler "more synchronized" in this way, I think we should change the API or find another way to allow any third-party sub-classes to also solve the issue. This is why I'm seeking real world examples of actual code that appear to rely on the invariant we're discussing.

>I've looked through a lot of github logging properties files and see no evidence that the pattern of use...

Closed source GOTS/COTS products that require troubleshooting require using all of the logging API features when other solutions are forbidden for non-tech reasons.

To the point though, limit one with a count makes FileHandler work like the MemoryHandler in that at the end of say a batch run you have exactly the last N records in the form of N files.  That is a feature.

>The reason I'm pushing back a little here is that the idea of making a "secret handshake"

The behavior is what i care about not the implementation.  I would rather focus on fitting your change and retain old behavior. Behaviorly, i think deadlock can be fixed with retaining existing log rollover behavior. Secret handshake off the table then. Done and dead.

New idea. All JDK subclass of StreamHandler call flush.

1. Put rotate check in FileHandler::flush
2. Make StreamHandler call flush while holding lock.
3. Remove explicit flush call in subclasses.
4. Add auto flush property to StreamHandler, default false.
5. Set auto flush true in subclass.


>..."EncryptedLogFileHandler" that's not a sub-class of FileHandler.

That example does apply because if it is not a FileHandler there is no check to call rotate method.  What am I missing?

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

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