Hi Mark,
Am 12.11.2018 um 10:40 schrieb Mark Thomas:
On 11/11/2018 10:48, Rainer Jung wrote:
Hi Romain,
Am 11.11.2018 um 11:16 schrieb Romain Manni-Bucau:
Hi Rainer,
There is an abstract access valve do providing a log impl (like [1]) can
enable that - plus other standard stuff like pushing on kafka accesses -
without hardcoding an stdout stream which can not work in docker in some
setup (where tomcat is launched by another process and redirects only
configured logs).
I know, that there's the AbstractAccessLogValve, that's why I wrote "Of
course it also extends our base AbstractAccessLogValve", so I am using
it in the STDOUT variant just like the LoggingAccessLogPattern you
mentioned does.
Yes, another way would be to have a variant that writes via JULI and let
people configure that (combining with what log framework they like).
This is why I created the Verbatim Formatter.
This past discussion looks to be relevant here:
https://tomcat.markmail.org/thread/7ve6awm6inud54l3
That would be more flexible, but also less performant. The reason, that
the AccessLogValve doesn't simply use a log framework for the request
protocol is (I think) only performance. If that is correct and still
relevant, then using a less performing approach for a seemingly simpler
STDOUT output would be surprising.
There are performance numbers in the thread above. My reading of that
thread is that the initial figures weren't encouraging but that further
refinement of the code and/or logging configuration may be able to
address that.
Thanks for the discussion pointer actually going back to 2012!
I will do some experiments along the lines of JULI to get current
numbers on overhead (mostly CPU and latency but probably also memory)
using our current default solution versus using JULI with
java.util.logging versus using JULI with something like Log4J2. And also
probably checking the log framework cases with simple file based logging
and with STDOUT logging.
I'll come back here, when I have some numbers.
Regards,
Rainer
[1]
https://github.com/apache/meecrowave/blob/trunk/meecrowave-core/src/main/java/org/apache/meecrowave/tomcat/LoggingAccessLogPattern.java
Le dim. 11 nov. 2018 11:06, Rainer Jung <rainer.j...@kippdata.de> a
écrit :
Hi all,
I don't like it but in managed container environments application
instances tend to get configured to write any log output to STDOUT (than
everything is caught and redirected to a log concentrator).
I could be wrong, but I think there is no appropriate way of doing it
with our standard AccessLogValve. I first thought to add a flag but then
noticed that the biggest part of the code of AccessLogValve is about
file management. Furthermore adding the STDOUT feature to it means we
would either produce lots of warnings for attributes that get ignored
once the feature is used, or risking that people might not understand
what they actually configure when enabling STDOUT but still setting file
and directory attributes.
I did a little experiment by stripping the existing AccessLogValve down
to just use STDOUT but still allow buffer and encoding configuration. I
ended up with 220 lines, less than 100 lines with actual code.
I would like to add it, but don't know whether there is enough demand
for that use case and whether people agree on using a separate class as
the right solution. Of course it also extends our base
AbstractAccessLogValve.
Opinion?
Thanks and regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
