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 <garydgreg...@gmail.com> wrote:
>
> 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 result and have the wrapper return the shorter string in its
> toString(), I still would have toString()'d the original...
>
> Gary
>
>> On Thu, Jan 25, 2024, 11:33 PM Ralph Goers <ralph.go...@dslextreme.com>
>> wrote:
>>
>> 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 <garydgreg...@gmail.com>
>> wrote:
>>>
>>> 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 <ralph.go...@dslextreme.com>
>> wrote:
>>>>
>>>> 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 substring() is
>> still going to operate on the whole String. He would really need a method
>> that accepts the max number of characters to read from the file.
>>>>
>>>> Ralph
>>>>
>>>>> On Jan 25, 2024, at 2:49 PM, Volkan Yazıcı <vol...@yazi.ci> wrote:
>>>>>
>>>>> *[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 <m...@musigma.org> wrote:
>>>>>
>>>>>> 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 <ggreg...@apache.org>
>> wrote:
>>>>>>>
>>>>>>> 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 once per build,
>>>>>> somewhere in a logging call. But it usually fails with a call that
>> looks
>>>>>> like this:
>>>>>>>
>>>>>>> logger.debug("This is fun" + myFunObject);
>>>>>>>
>>>>>>> To simplify things, let's say that it turns out that after an
>> underlying
>>>>>> third party jar file version upgrade the call to
>> myFunObject#toString() no
>>>>>> longer returns Object#toString() but rather (again to simplify) the
>>>>>> contents of the file that was parsed to create myFunObject. This
>> toString()
>>>>>> can be megabytes. The solution is obvious:
>>>>>>>
>>>>>>> logger.debug("This is fun", myFunObject::toString)
>>>>>>>
>>>>>>> And our CI builds no longer randomly fail since our default logging
>> does
>>>>>> not log at the debug level.
>>>>>>>
>>>>>>> A better solution could be:
>>>>>>>
>>>>>>> logger.debug("This is fun", () -> myFunObject.toString().substring(0,
>>>>>> 100))
>>>>>>>
>>>>>>> where I still want _some_ information better than making my own
>>>>>> toString() with System#identityHashCode(Object) or somesuch. Sure,
>>>>>> .toString() is still called but it does not make it down into
>> logging. In
>>>>>> my case the OOME happened in myFunObject::toString so the substring()
>>>>>> example would not have worked.
>>>>>>>
>>>>>>> My question is: Should we document some general advice on this
>> pattern
>>>>>> and what should the advice be? Would it make sense to have some
>> features
>>>>>> where we truncate/reject Strings above a threshold. And yes, calling
>>>>>> myFunObject.toString() can still still get me in trouble.
>>>>>>>
>>>>>>> Gary
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>
>>
