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
>>>
>>
>>
