Re: [Log4j] If and how to document potential OOME

2024-01-26 Thread Matt Sicker
Perhaps mention of StringBuilderFormattable? It helps work around the “load the string all at once” problem. > On Jan 26, 2024, at 06:36, Gary Gregory wrote: > > Oh, I don't want to suggest this is a Lo4j issue at all. I am wondering if > there is a pattern we should document aside from "know y

Re: [Log4j] If and how to document potential OOME

2024-01-26 Thread Gary Gregory
Oh, I don't want to suggest this is a Lo4j issue at all. I am wondering if there is a pattern we should document aside from "know your third party objects" which is not helpful for us to say. It sounds like there is nothing for us to do. Gary On Fri, Jan 26, 2024, 7:16 AM Apache wrote: > That i

Re: [Log4j] If and how to document potential OOME

2024-01-26 Thread Apache
That is kind of my point. Anyone who logs an object that behaves this way is asking for trouble. It really sounds like an esoteric edge case to me. I don’t view this as a Log4J problem as the error wouldn’t even have Log4J in the stack trace. Ralph > On Jan 25, 2024, at 9:52 PM, Gary Gregory

Re: [Log4j] If and how to document potential OOME

2024-01-25 Thread Gary Gregory
I have no control over this. I think this is a general problem with third party objects and toString(). There is no toString(fromHereToThere) or toStringReader() so I can't see a general way to deal with it. Even if I created a wrapper for the Object and called toString(), truncated and cached the

Re: [Log4j] If and how to document potential OOME

2024-01-25 Thread Ralph Goers
OK. The only good way to handle that is to parse the YAML/JSON file while streaming it and extract just the fields you want to include in the logs. Ralph > On Jan 25, 2024, at 6:40 PM, Gary Gregory wrote: > > Well, it's worse than that because the object is an object created by > parsing a YAM

Re: [Log4j] If and how to document potential OOME

2024-01-25 Thread Gary Gregory
Well, it's worse than that because the object is an object created by parsing a YAML (or JSON) file, then the toString() of that object renders a String in some other format. Gary On Thu, Jan 25, 2024 at 7:45 PM Ralph Goers wrote: > > Volkan & Matt, > > Neither of those is going to help. The iss

Re: [Log4j] If and how to document potential OOME

2024-01-25 Thread Ralph Goers
Volkan & Matt, Neither of those is going to help. The issue is that when the toString method is called it reads a whole file in and stores it as a String. This could cause the OOM error. Truncating it in a layout simply limits how much of the String is printed. Even Gary’s proposal of calling s

Re: [Log4j] If and how to document potential OOME

2024-01-25 Thread Volkan Yazıcı
*[Just responding to Matt. I don't have an answer for Gary.]* `JsonTemplateLayout` has `maxStringLength`, and related with it, `truncatedStringSuffix`. On Thu, Jan 25, 2024 at 9:45 PM Matt Sicker wrote: > You can use the %maxLength{…}{N} pattern converter with PatternLayout at > least. Unfortun

Re: [Log4j] If and how to document potential OOME

2024-01-25 Thread Matt Sicker
You can use the %maxLength{…}{N} pattern converter with PatternLayout at least. Unfortunately, I don’t think any other layouts support a similar option. > On Jan 25, 2024, at 10:55, Gary D. Gregory wrote: > > Hi All, > > I'd like to ask how to if we can devise advice around an issue I ran into

Re: [Log4j] If and how to document potential OOME

2024-01-25 Thread Gary Gregory
Obvious mistake: logger.debug("This is fun", myFunObject::toString) -> logger.debug("This is fun {}", myFunObject::toString) Gary On Thu, Jan 25, 2024, 11:55 AM Gary D. Gregory wrote: > Hi All, > > I'd like to ask how to if we can devise advice around an issue I ran into > this week. > > One

[Log4j] If and how to document potential OOME

2024-01-25 Thread Gary D. Gregory
Hi All, I'd like to ask how to if we can devise advice around an issue I ran into this week. One of our test suites processes about 40K files of test fixtures. These inputs are parsed, processed, and asserted. This randomly fails on a call to Logger#debug(), randomly in that it happens usually