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