Thanks, eactly what we need. I will look into it, but it might take two
or three days. Anyone who can do it more quickly is welcome. I suspect
these log lines point to the root cause:
> [Mon Sep 30 15:04:03 2019][3906:140148297873536] [debug]
> jk_servlet_normalize::jk_util.c (2184): URI on
Thanks! Setting overheadDataThreshold="0" does fix the issue.
Without overheadDataThreshold the issue is very inconsistent:
Firefox 69.0.1 (64-Bit) on LNX and on other OS does result in the
described error below.
Very strange: Chrome on LNX mostly works, which means I got
intermittently once
That sounds like the client has tripped the overhead threshold protection.
As a short term fix you probably want to see a lower value for:
overheadDataThreshold
see: http://tomcat.apache.org/tomcat-8.5-doc/config/http2.html
possibly as low as zero.
Longer term you should ideally look into why
I stumbled over a new problem which very likely appeared after
apache-tomcat-8.5.43 and between apache-tomcat-8.5.46
Using Apache Commons FileUpload gives for some kind of PDF files:
[https-openssl-apr-443-exec-15]
org.apache.struts.upload.CommonsMultipartRequestHandler.handleRequest
Failed to
Apologies as this is a long e-mail. I tried to include all the information
to help troubleshoot the issue.
I have a lab setup with a vagrant box to test.: CentOS Linux release
7.7.1908 (Core)
httpd-2.4.6-90.el7
tomcat-connectors-1.2.44-src
The only changes I made to the config from default
On Sat, Sep 28, 2019 at 9:05 PM Mark Thomas wrote:
> On 27/09/2019 22:39, Chen Levy wrote:
> > -Original Message-
> > From: Mark Thomas
> > Sent: Friday, September 27, 2019 15:34
> > To: users@tomcat.apache.org
> > Subject: Re: Tomcat 9.0.24/9.0.26 suspected memory leak
> >
> > On
