date:20181112

[Bug 62892] Memory leak when performing client certificate validation with OCSP

2018-11-12 Thread bugzilla

https://bz.apache.org/bugzilla/show_bug.cgi?id=62892

--- Comment #1 from Sander Benschop  ---
I have further isolated the issue by replacing the verify_cb function
'SSL_callback_SSL_verify' (from the Tomcat Native Library) with a no-op
function. When I do this the available memory remains constant, our test server
didn't run out of memory all weekend with the same polling frequency as before.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: AccessLogValve using STDOUT

2018-11-12 Thread 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.

Mark


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


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: AccessLogValve using STDOUT

2018-11-12 Thread Rainer Jung

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

Re: AccessLogValve using STDOUT

2018-11-12 Thread Romain Manni-Bucau

@Rainer: if it helps you can test with this file handler:
https://github.com/apache/tomee/blob/master/tomee/tomee-juli/src/main/java/org/apache/tomee/jul/handler/rotating/LocalFileHandler.java

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le lun. 12 nov. 2018 à 10:51, Rainer Jung  a
écrit :

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

40 matches

Mail list logo