Re: CurrentThreads not increasing in Apache Tomcat/9.0.37

2020-09-25 Thread Vicente Perez
> Thank you for the answer. > > Yes. It is APR/Native Connector. Are you sure? It isn't impossible that you are using the APR/Native connector given your configuration but it would be unusual. Look in the logs for a line that contains: org.apache.coyote.Abstra

Re: CurrentThreads not increasing in Apache Tomcat/9.0.37

2020-09-25 Thread Mark Thomas
On 25/09/2020 18:07, Vicente Perez wrote: > Thank you for the answer. > > Yes. It is APR/Native Connector. Are you sure? It isn't impossible that you are using the APR/Native connector given your configuration but it would be unusual. Look in the logs for a line that contains: org.apache.coy

Re: CurrentThreads not increasing in Apache Tomcat/9.0.37

2020-09-25 Thread Vicente Perez
On 25-09-20 13:58, "Mark Thomas" wrote: On 25/09/2020 14:02, Vicente Perez wrote: > Hello, > > We have a server with Apache Tomcat/9.0.37 which is dedicated for less than 100 concurrent users. We are using the ARP Connector with the parameter “maxThreads=400”. I assume y

Re: CurrentThreads not increasing in Apache Tomcat/9.0.37

2020-09-25 Thread Mark Thomas
On 25/09/2020 14:02, Vicente Perez wrote: > Hello, > > We have a server with Apache Tomcat/9.0.37 which is dedicated for less than > 100 concurrent users. We are using the ARP Connector with the parameter > “maxThreads=400”. I assume you mean the APR/Native connector here. > c

Re: HTTP2: Tomcat sends GOAWAY when trying to respond over a stream where the client has already sent RST_STREAM:NO ERROR

2020-09-25 Thread Mark Thomas
On 25/09/2020 15:47, Arshiya Shariff wrote: > Thanks for the response Martin. > > Below is the only exception we are getting in the logs while sending response > to a closed stream , few times with MUST_COMPLETE instead of MUST_ERROR : > Exception occurred while sending response. ExceptionMessage

Re: Low throughput with HTTP2

2020-09-25 Thread Mark Thomas
On 25/09/2020 12:18, Berneburg, Cris J. - US wrote: > Thanks again Mark :-) > > mt> how that Map is pruned (it is currently too aggressive) > > mt> if Tomcat is processing 10k req/s just keeping track of > mt> the last 30s is potentially 300k streams. How to do that > mt> efficiently for all usa

RE: HTTP2: Tomcat sends GOAWAY when trying to respond over a stream where the client has already sent RST_STREAM:NO ERROR

2020-09-25 Thread Arshiya Shariff
Thanks for the response Martin. Below is the only exception we are getting in the logs while sending response to a closed stream , few times with MUST_COMPLETE instead of MUST_ERROR : Exception occurred while sending response. ExceptionMessage:Calling [asyncComplete()] is not valid for a request

CurrentThreads not increasing in Apache Tomcat/9.0.37

2020-09-25 Thread Vicente Perez
Hello, We have a server with Apache Tomcat/9.0.37 which is dedicated for less than 100 concurrent users. We are using the ARP Connector with the parameter “maxThreads=400”. We have the next behavior: Tomcat does not process any new request with currentThreadCount = X and currentThreadBusy =

RE: Low throughput with HTTP2

2020-09-25 Thread Berneburg, Cris J. - US
Thanks again Mark :-) mt> how that Map is pruned (it is currently too aggressive) mt> if Tomcat is processing 10k req/s just keeping track of mt> the last 30s is potentially 300k streams. How to do that mt> efficiently for all usage patterns is a problem that mt> needs some thought. Sounds a bi

Re: HTTP2: Tomcat sends GOAWAY when trying to respond over a stream where the client has already sent RST_STREAM:NO ERROR

2020-09-25 Thread Martin Grigorov
On Fri, Sep 25, 2020 at 1:18 PM Arshiya Shariff wrote: > Thanks Martin . > > Our expectation Is that , on receiving a RST_STREAM with CANCEL or > NO_ERROR from the client after 1.5 secs for a particular stream , we don’t > want the connection to be closed with a GOAWAY:NO_ERROR (while trying to

RE: HTTP2: Tomcat sends GOAWAY when trying to respond over a stream where the client has already sent RST_STREAM:NO ERROR

2020-09-25 Thread Arshiya Shariff
Thanks Martin . Our expectation Is that , on receiving a RST_STREAM with CANCEL or NO_ERROR from the client after 1.5 secs for a particular stream , we don’t want the connection to be closed with a GOAWAY:NO_ERROR (while trying to send response after 2secs asynchronously over a stream that is