On Fri, 14 Feb 2025 10:39:54 GMT, David Beaumont <d...@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
