On Fri, 14 Feb 2025 06:04:09 GMT, Jason Mehrens <d...@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
