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

[David Beaumont]

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

>>>Yes, it's certainly something you can deliberately provoke in a way that wasn't possible before.
>> 
>> Setting limit to 1 byte with a large count is a way to make sure each log file contains 0 or 1 log record.  I think this patch breaks that behavior when threads pile up resulting files containing 2 or more log records.  If so that is a breaking incompatibility that should be avoided as some formats only make sense to contain a single record or require post processing to be one record per file.
>> 
>> I'll answer your other questions as soon as I can.
>
> 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.

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

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