RFR: 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method
David Beaumont
duke at openjdk.org
Fri Feb 14 10:42:10 UTC 2025
On Fri, 14 Feb 2025 06:04:09 GMT, Jason Mehrens <duke at openjdk.org> wrote:
>> Yes, it's certainly something you can deliberately provoke in a way that wasn't possible before.
>> However I'm not sure that the statement "Old code should only allow at most 2 records ...", while true of the code itself was ever something the docs/specification implied would be true, so I'm doubtful of the validity of asserting anything about it too strongly.
>>
>> However, the general possibility of having blocking behavior in formatters is interesting. Can you explain more concretely why you did this and what problem it solved, so I can build a better model of the likelihood of this causing issues? Was the blocking just something like "acquire cached localized formatter", where several threads might contend over the cache entry when a new locale is seen? Or was it something more complex?
>
>>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.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1955931154
More information about the core-libs-dev
mailing list