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

[David Beaumont]

On Thu, 13 Feb 2025 19:38:47 GMT, Jason Mehrens <duke at openjdk.org> wrote:

>> We could, but I don't think it matters. This issue is the first one pointed out in the CSR, and my current feeling is that since it's stated that the limit is "best effort" and there's always the chance that the final log before rotate was massive anyway, and the risk of this sort of interleaving is low, it's not going to make things qualitatively worse than they are now. If the docs promised that file wouldn't grow beyond the limit, I'd definitely have done things something like you're suggesting.
>
> To be clear I'm with you on your approach and hold much of the same views.
> 
>>We could, but I don't think it matters.
> 
> I'm just focusing on this aspect because it is usually the thing comes back to bite me.
> 
> I think it matters when resources are limited (diskspace) and file size limits are low.
> 
> Write a test with filehander set to 2 files at 1M in size.
> 2. Create a custom Formatter that uses a count down latch set to 10 and returns the log sequence as a string. Install it on the filehander.
> 3. Start 10 threads that log ~1M of data.
> 4. Assert that only 2 log sequences are seen when scanning both files.
> 
> Old code should only allow at most 2 records which helps control the overshoot of file size.
> 
> For context, I've built and have used custom Formatters that would have blocking behavior like the count down latch test.  This is not a strawman test.

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?

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

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