On Wed, Apr 2, 2025 at 9:49 PM Rainer Jung <rainer.j...@kippdata.de> wrote:
>
> Am 02.04.25 um 21:04 schrieb Rainer Jung:
> > Am 02.04.25 um 15:07 schrieb Rainer Jung:
> >> I get sporadic failures in test[62: Name[pct-t-begin:umlaut_time_S],
> >> Type[text]] and in test[63: Name[pct-t-begin:umlaut_time_S], Type[json]]
> >>
> >> It seems it has to do with malformed SSS:
> >>
> >> JSON:
> >>
> >> '{"time-begin:'Ä'HH 'ä' mm 'ö' ss 'ü' SSS'Ü'":"0\u00c414 \u00e4 18
> >> \u00f6 48 \u00fc 08\u00dc"}'
> >> '\{"time-begin:'Ä'HH 'ä' mm 'ö' ss 'ü' SSS'Ü'":"\\u00c4\d\d \\u00e4
> >> \d\d \\u00f6 \d\d \\u00fc \d\d\d\\u00dc"\}'
> >>
> >> Text:
> >>
> >> '0\u00c411 \u00e4 20 \u00f6 36 \u00fc 70\u00dc'
> >> '\\u00c4\d\d \\u00e4 \d\d \\u00f6 \d\d \\u00fc \d\d\d\\u00dc'
> >>
> >> we can see double digit "08" resp. "70" at the SSS position, but an
> >> additional leading "0" at the start of the line.
> >>
> >> Observed for TC 9.0.103 and 10.1.40, tests for TC 11 not started yet.
> >
> > Unfortunately this seems to be a real regression. Using
> >
> > pattern="%{begin:'X' SSS'Y'}t"
> >
> > for the org.apache.catalina.valves.AccessLogValve in server.xml I can
> > reproduce output like
> >
> > 0X 62Y
> >
> > in the written access log file with version 10.1.40. With 10.1.39 output
> > seems fine, so eg.
> >
> > X 062Y
> >
> > I think the problem always occurs, when leading zeros are needed to fill
> > the three requested digits. The prefix seems to applied at the wrong
> > position.
> >
> > I will have a look at the AccessLogValve and/or timestamp formatting
> > changes.
> >
> > The problem would only occur, when the timestamp has a leading zero in
> > the milliseconds, so 1/10th of the times.
>
> Found it, fixed it (hopefully). Was a copy and paste typo in backporting
> cleanups from main (code OK), to 10.1 and 9.0 (both broken).
>
> > Although SSS is not used in the default config, I tend to vote this as a
> > -1 as it breaks access log parsing especially under high load with
> > explicit milliseconds output defined as it might be normal in enterprise
> > use. Any other views on how bad this is?
>
> Still interested in any opinion.Although it turns out I am responsible for the bad merge that caused this (sorry), I do not see it as a meaningful regression worth redoing the build (sorry). Unless I don't get enough votes for it, obviously. Rémy --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
