Re: CurrentThreads not increasing in Apache Tomcat/9.0.37
> 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.AbstractProtocol.start Starting ProtocolHandler ... What is the full text of that line? Also, what version of the Tomcat Native Connector are you using? Look in the logs for a line that contains: org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Loaded Apache Tomcat Native library [???] using APR version [???] What is the full text of that line? > Please let me know if you need more information about the configuration/environment. I ran some simple tests with ab and I cannot repeat the problem you describe. As I increase the concurrency with ab, currentThreadCount increases. I even reduced minSpareThreads to 0 and I still could not reproduce the behaviour. To investigate this further you'll need to provide the steps to reproduce this from a clean install of the latest stable 9.0.x release (9.0.38 as I type this) and the latest stable Tomcat Native (1.2.25). Ideally the test case would involve nothing more than a clean Tomcat install and ab to generate the load. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Hi Mark, Thanks again. >Look in the logs for a line that contains: 24-Sep-2020 17:00:13.744 INFO [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler ["http-nio-8080"] 24-Sep-2020 17:00:13.407 INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent The Apache Tomcat Native library which allows using OpenSSL was not found on the java.library.path: [/usr/java/packages/lib:/usr/lib/x86_64-linux-gnu/jni:/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu:/usr/lib/jni:/lib:/usr/lib] This is the whole startup log before loading web apps. NOTE: Picked up JDK_JAVA_OPTIONS: --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.io=ALL-UNNAMED --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED 24-Sep-2020 17:00:13.393 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server version name: Apache Tomcat/9.0.37 24-Sep-2020 17:00:13.395 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server built: Jun 30 2020 20:09:49 UTC 24-Sep-2020 17:00:13.395 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server version number: 9.0.37.0 24-Sep-2020 17:00:13.396 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log OS Name: Linux 24-Sep-2020 17:00:13.396 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log OS Version: 4.15.0-109-generic 24-Sep-2020 17:00:13.396 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Architecture: amd64 24-Sep-2020 17:00:13.396 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Java Home: /usr/lib/jvm/java-11-openjdk-amd64 24-Sep-2020 17:00:13.397 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log JVM Version: 11.0.7+10-post-Ubuntu-2ubuntu218.04 24-Sep-2020 17:00:13.397 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log JVM Vendor: Ubuntu 24-Sep-2020 17:00:13.397 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log CATALINA_BASE: /srv/tomcat9/apache-tomcat-9.0.37 24-Sep-2020 17:00:13.397 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log CATALINA_HOME: /srv/tomcat9/apache-tomcat-9.0.37 24-Sep-2020 17:00:13.401 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: --add-opens=java.base/java.lang=ALL-UNNAMED 24-Sep-2020 17:00:13.401 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: --add-opens=java.base/java.io=ALL-UNNAMED 24-Sep-2020 17:00:13.401 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED 24-Sep-2020 17:00:13.402 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.util.logging.config.file=/srv/tomcat9/apache-tomcat-9.0.37/conf/logging.properties 24-Sep-2020 17:00:13.402 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager 24-Sep-2020 17:00:13.402 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.security.egd=file:///dev/urandom 24-Sep-2020 17:00:13.402 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.awt.
Re: CurrentThreads not increasing in Apache Tomcat/9.0.37
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.coyote.AbstractProtocol.start Starting ProtocolHandler ... What is the full text of that line? Also, what version of the Tomcat Native Connector are you using? Look in the logs for a line that contains: org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Loaded Apache Tomcat Native library [???] using APR version [???] What is the full text of that line? > Please let me know if you need more information about the > configuration/environment. I ran some simple tests with ab and I cannot repeat the problem you describe. As I increase the concurrency with ab, currentThreadCount increases. I even reduced minSpareThreads to 0 and I still could not reproduce the behaviour. To investigate this further you'll need to provide the steps to reproduce this from a clean install of the latest stable 9.0.x release (9.0.38 as I type this) and the latest stable Tomcat Native (1.2.25). Ideally the test case would involve nothing more than a clean Tomcat install and ab to generate the load. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: CurrentThreads not increasing in Apache Tomcat/9.0.37
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 you mean the APR/Native connector here. > connectionTimeout="2" >redirectPort="8443" maxThreads="400" /> > > We have the next behavior: > Tomcat does not process any new request with currentThreadCount = X and currentThreadBusy = X, but with X=30 or 50. ConnectionCount is increasing. > > A far as I understood, the number of threads should increase if currentThreadBusy is increasing. Correct. > We prevent this behavior by setting minSpareThreads to 100. > > * Is this behavior correct? Doesn't look right. > * How the Connector should be configured in order to increase the currentThreadCount when currentThreadBusy is equal to currentThreadCount? This looks like a potential bug that needs further investigation. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Thank you for the answer. Yes. It is APR/Native Connector. Please let me know if you need more information about the configuration/environment. Regards Vicente
Re: CurrentThreads not increasing in Apache Tomcat/9.0.37
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. > connectionTimeout="2" >redirectPort="8443" maxThreads="400" /> > > We have the next behavior: > Tomcat does not process any new request with currentThreadCount = X and > currentThreadBusy = X, but with X=30 or 50. ConnectionCount is increasing. > > A far as I understood, the number of threads should increase if > currentThreadBusy is increasing. Correct. > We prevent this behavior by setting minSpareThreads to 100. > > * Is this behavior correct? Doesn't look right. > * How the Connector should be configured in order to increase the > currentThreadCount when currentThreadBusy is equal to currentThreadCount? This looks like a potential bug that needs further investigation. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: HTTP2: Tomcat sends GOAWAY when trying to respond over a stream where the client has already sent RST_STREAM:NO ERROR
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:Calling > [asyncComplete()] is not valid for a request with Async state [MUST_ERROR] That suggests issues with error handling. Either errors not being handled or some sort of threading issue. If you attempt to write to a closed stream Tomcat should simply swallow the data and not send it to the client. The only reason Tomcat will send a GOAWAY frame in normal usage if there is a connection level error. Mark > > Thanks and Regards > Arshiya Shariff > > -Original Message- > From: Martin Grigorov > Sent: Friday, September 25, 2020 4:37 PM > To: Tomcat Users List > Subject: Re: HTTP2: Tomcat sends GOAWAY when trying to respond over a stream > where the client has already sent RST_STREAM:NO ERROR > > 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 send response after 2secs asynchronously over a stream that >> is closed) as the other streams during the same time are processing data >> fine . >> >> Additional info for GOAWAY: Connection [], Stream[],An error occurred >> during processing that was fatal to the connection . >> > > I guess some other error happened and that led to the GOAWAY. But I cannot be > sure. > Any errors in the logs ? > > >> >> Thanks and Regards >> Arshiya Shariff >> >> -Original Message- >> From: Martin Grigorov >> Sent: Tuesday, September 22, 2020 7:31 PM >> To: Tomcat Users List >> Subject: Re: HTTP2: Tomcat sends GOAWAY when trying to respond over a >> stream where the client has already sent RST_STREAM:NO ERROR >> >> Hi, >> >> On Tue, Sep 22, 2020 at 1:47 PM Arshiya Shariff < >> arshiya.shar...@ericsson.com.invalid> wrote: >> >>> Thank you so much Martin for the response. >>> Yes , 9.0.38 testing is on going . >>> >>> As we don’t get this clear with the RFC , please help us with the >>> below two cases : >> >> * If a client sends RST_STREAM with NO_ERROR, then while sending >> async >>> response is it expected behavior to close connection with GOAWAY ? >>> * If a client sends RST_STREAM with CANCEL , then while sending >>> async response will tomcat send RST_STREAM or GOAWAY , from http2 >>> protocol perspective ? >>> >> >> As per https://tools.ietf.org/html/rfc7540#section-6.4 and >> https://tools.ietf.org/html/rfc7540#section-5.1 if "send R" or "recv R" >> are processed then the stream is moved to CLOSED state. >> GOAWAY should be sent to the client only if the connection will be >> closed ( https://tools.ietf.org/html/rfc7540#section-6.8). The server >> should close the connection only if some serious problem has happened, >> e.g. an IOException. >> >> Tell us more about your use case. What do you want to do when 1.5secs >> pass ? What do you expect to happen ? >> >> >>> >>> Thanks and Regards >>> Arshiya Sharif >>> >>> -Original Message- >>> From: Martin Grigorov >>> Sent: Tuesday, September 22, 2020 1:18 AM >>> To: Tomcat Users List >>> Subject: Re: HTTP2: Tomcat sends GOAWAY when trying to respond over >>> a stream where the client has already sent RST_STREAM:NO ERROR >>> >>> Hi, >>> >>> On Mon, Sep 21, 2020 at 7:56 PM Arshiya Shariff < >>> arshiya.shar...@ericsson.com.invalid> wrote: >>> Hi All, The client has configured a response timeout of 1.5 seconds. In a case when our application tries to respond over a http2 stream asynchronously after 2 seconds where the client has already sent RST_STREAM with NO ERROR in 1.5 seconds >>> >>> >>> Why does the client send NO_ERROR to the server ? I think it should >>> send a CANCEL instead. >>> https://tools.ietf.org/html/rfc7540 mentions NO_ERROR only for >>> "Graceful shutdown of the server". >>> >>> (due to no response) , then tomcat sends GOAWAY and closes the HTTP2 connection . Is this behavior of GOAWAY and connection closure >> expected ? We have planned to upgrade to Embedded tomcat version 9.0.38 . These are the behaviors we see in production with version 9.0.22 , so we need some help with analyzing / validating the existing behavior before >>> the upgrade . Please let us know. >>> >>> Friendly advice: >>> Please setup 9.0.38 locally and test on it. >>> 9.0.22 is way too old. It is up to you to use it for your production >>> but for reporting bugs it is recommended to use the latest available >> version. >>> I, personally, prefer to spend my spare time with my family and >>> friends than to debug old versions just because
Re: Low throughput with HTTP2
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 usage patterns is a problem that > mt> needs some thought. > > Sounds a bit like garbage collection. Is aging part of the process - a > map/queue combo? Yes, but only very simplisticly. Streams with lower IDs are removed first. > cjb> How could the closed stream footprint be reduced? > cjb> Could the structure holding a closed stream: > cjb> a. Be replaced with a smaller one? > cjb> c. Or did you already have something in mind? > > mt> A form of a). I'm looking at this now. I committed this earlier today. See dev@ for details. > cjb> b. De-reference other objects no longer needed? > cjb> Hmm... that might lead to NPE's and thus unnecessary > cjb> null checking. > > mt> Tried that. Lots of NPE regressions to the point that > mt> I reverted the change to look for a better solution. > > Hey great, I'm beginning to understand! :-D > > mt> we have all the plumbing to correctly determine > mt> relative priority [...] we don't use it to prioritise > mt> streams when flow control windows are not an issue > > mt> I started to look at this a while ago but it gets very > mt> complex quite quickly. It would be simpler if we were > mt> just serving static content. > > Ha ha, httpd! Hang on, does httpd handle a similar situation too? I don't know. I imagine so. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: HTTP2: Tomcat sends GOAWAY when trying to respond over a stream where the client has already sent RST_STREAM:NO ERROR
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 with Async state [MUST_ERROR] Thanks and Regards Arshiya Shariff -Original Message- From: Martin Grigorov Sent: Friday, September 25, 2020 4:37 PM To: Tomcat Users List Subject: Re: HTTP2: Tomcat sends GOAWAY when trying to respond over a stream where the client has already sent RST_STREAM:NO ERROR 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 send response after 2secs asynchronously over a stream that > is closed) as the other streams during the same time are processing data fine > . > > Additional info for GOAWAY: Connection [], Stream[],An error occurred > during processing that was fatal to the connection . > I guess some other error happened and that led to the GOAWAY. But I cannot be sure. Any errors in the logs ? > > Thanks and Regards > Arshiya Shariff > > -Original Message- > From: Martin Grigorov > Sent: Tuesday, September 22, 2020 7:31 PM > To: Tomcat Users List > Subject: Re: HTTP2: Tomcat sends GOAWAY when trying to respond over a > stream where the client has already sent RST_STREAM:NO ERROR > > Hi, > > On Tue, Sep 22, 2020 at 1:47 PM Arshiya Shariff < > arshiya.shar...@ericsson.com.invalid> wrote: > > > Thank you so much Martin for the response. > > Yes , 9.0.38 testing is on going . > > > > As we don’t get this clear with the RFC , please help us with the > > below two cases : > > * If a client sends RST_STREAM with NO_ERROR, then while sending > async > > response is it expected behavior to close connection with GOAWAY ? > > * If a client sends RST_STREAM with CANCEL , then while sending > > async response will tomcat send RST_STREAM or GOAWAY , from http2 > > protocol perspective ? > > > > As per https://tools.ietf.org/html/rfc7540#section-6.4 and > https://tools.ietf.org/html/rfc7540#section-5.1 if "send R" or "recv R" > are processed then the stream is moved to CLOSED state. > GOAWAY should be sent to the client only if the connection will be > closed ( https://tools.ietf.org/html/rfc7540#section-6.8). The server > should close the connection only if some serious problem has happened, > e.g. an IOException. > > Tell us more about your use case. What do you want to do when 1.5secs > pass ? What do you expect to happen ? > > > > > > Thanks and Regards > > Arshiya Sharif > > > > -Original Message- > > From: Martin Grigorov > > Sent: Tuesday, September 22, 2020 1:18 AM > > To: Tomcat Users List > > Subject: Re: HTTP2: Tomcat sends GOAWAY when trying to respond over > > a stream where the client has already sent RST_STREAM:NO ERROR > > > > Hi, > > > > On Mon, Sep 21, 2020 at 7:56 PM Arshiya Shariff < > > arshiya.shar...@ericsson.com.invalid> wrote: > > > > > Hi All, > > > > > > The client has configured a response timeout of 1.5 seconds. In a > > > case when our application tries to respond over a http2 stream > > > asynchronously after 2 seconds where the client has already sent > > > RST_STREAM with NO ERROR in 1.5 seconds > > > > > > Why does the client send NO_ERROR to the server ? I think it should > > send a CANCEL instead. > > https://tools.ietf.org/html/rfc7540 mentions NO_ERROR only for > > "Graceful shutdown of the server". > > > > > > > (due to no response) , then tomcat sends GOAWAY and closes the > > > HTTP2 connection . Is this behavior of GOAWAY and connection > > > closure > expected ? > > > We have planned to upgrade to Embedded tomcat version 9.0.38 . > > > These are the behaviors we see in production with version 9.0.22 , > > > so we need some help with analyzing / validating the existing > > > behavior before > > the upgrade . > > > Please let us know. > > > > > > > Friendly advice: > > Please setup 9.0.38 locally and test on it. > > 9.0.22 is way too old. It is up to you to use it for your production > > but for reporting bugs it is recommended to use the latest available > version. > > I, personally, prefer to spend my spare time with my family and > > friends than to debug old versions just because the user doesn't > > bother to test on a newer version. > > > > > > > > > > Thanks and Regards > > > Arshiya Shariff > > > > > > > > > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > - > To unsubscribe, e-mail: users-unsubscr...@tom
CurrentThreads not increasing in Apache Tomcat/9.0.37
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 = X, but with X=30 or 50. ConnectionCount is increasing. A far as I understood, the number of threads should increase if currentThreadBusy is increasing. We prevent this behavior by setting minSpareThreads to 100. * Is this behavior correct? * How the Connector should be configured in order to increase the currentThreadCount when currentThreadBusy is equal to currentThreadCount? Best regards Vicente Pérez
RE: Low throughput with HTTP2
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 bit like garbage collection. Is aging part of the process - a map/queue combo? cjb> How could the closed stream footprint be reduced? cjb> Could the structure holding a closed stream: cjb> a. Be replaced with a smaller one? cjb> c. Or did you already have something in mind? mt> A form of a). I'm looking at this now. cjb> b. De-reference other objects no longer needed? cjb> Hmm... that might lead to NPE's and thus unnecessary cjb> null checking. mt> Tried that. Lots of NPE regressions to the point that mt> I reverted the change to look for a better solution. Hey great, I'm beginning to understand! :-D mt> we have all the plumbing to correctly determine mt> relative priority [...] we don't use it to prioritise mt> streams when flow control windows are not an issue mt> I started to look at this a while ago but it gets very mt> complex quite quickly. It would be simpler if we were mt> just serving static content. Ha ha, httpd! Hang on, does httpd handle a similar situation too? -- Cris Berneburg CACI Senior Software Engineer This electronic message contains information from CACI International Inc or subsidiary companies, which may be company sensitive, proprietary, privileged or otherwise protected from disclosure. The information is intended to be used solely by the recipient(s) named above. If you are not an intended recipient, be aware that any review, disclosure, copying, distribution or use of this transmission or its contents is prohibited. If you have received this transmission in error, please notify the sender immediately. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: HTTP2: Tomcat sends GOAWAY when trying to respond over a stream where the client has already sent RST_STREAM:NO ERROR
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 > send response after 2secs asynchronously over a stream that is closed) as > the other streams during the same time are processing data fine . > > Additional info for GOAWAY: Connection [], Stream[],An error occurred > during processing that was fatal to the connection . > I guess some other error happened and that led to the GOAWAY. But I cannot be sure. Any errors in the logs ? > > Thanks and Regards > Arshiya Shariff > > -Original Message- > From: Martin Grigorov > Sent: Tuesday, September 22, 2020 7:31 PM > To: Tomcat Users List > Subject: Re: HTTP2: Tomcat sends GOAWAY when trying to respond over a > stream where the client has already sent RST_STREAM:NO ERROR > > Hi, > > On Tue, Sep 22, 2020 at 1:47 PM Arshiya Shariff < > arshiya.shar...@ericsson.com.invalid> wrote: > > > Thank you so much Martin for the response. > > Yes , 9.0.38 testing is on going . > > > > As we don’t get this clear with the RFC , please help us with the > > below two cases : > > * If a client sends RST_STREAM with NO_ERROR, then while sending async > > response is it expected behavior to close connection with GOAWAY ? > > * If a client sends RST_STREAM with CANCEL , then while sending > > async response will tomcat send RST_STREAM or GOAWAY , from http2 > > protocol perspective ? > > > > As per https://tools.ietf.org/html/rfc7540#section-6.4 and > https://tools.ietf.org/html/rfc7540#section-5.1 if "send R" or "recv R" > are processed then the stream is moved to CLOSED state. > GOAWAY should be sent to the client only if the connection will be closed > ( https://tools.ietf.org/html/rfc7540#section-6.8). The server should > close the connection only if some serious problem has happened, e.g. an > IOException. > > Tell us more about your use case. What do you want to do when 1.5secs pass > ? What do you expect to happen ? > > > > > > Thanks and Regards > > Arshiya Sharif > > > > -Original Message- > > From: Martin Grigorov > > Sent: Tuesday, September 22, 2020 1:18 AM > > To: Tomcat Users List > > Subject: Re: HTTP2: Tomcat sends GOAWAY when trying to respond over a > > stream where the client has already sent RST_STREAM:NO ERROR > > > > Hi, > > > > On Mon, Sep 21, 2020 at 7:56 PM Arshiya Shariff < > > arshiya.shar...@ericsson.com.invalid> wrote: > > > > > Hi All, > > > > > > The client has configured a response timeout of 1.5 seconds. In a > > > case when our application tries to respond over a http2 stream > > > asynchronously after 2 seconds where the client has already sent > > > RST_STREAM with NO ERROR in 1.5 seconds > > > > > > Why does the client send NO_ERROR to the server ? I think it should > > send a CANCEL instead. > > https://tools.ietf.org/html/rfc7540 mentions NO_ERROR only for > > "Graceful shutdown of the server". > > > > > > > (due to no response) , then tomcat sends GOAWAY and closes the HTTP2 > > > connection . Is this behavior of GOAWAY and connection closure > expected ? > > > We have planned to upgrade to Embedded tomcat version 9.0.38 . These > > > are the behaviors we see in production with version 9.0.22 , so we > > > need some help with analyzing / validating the existing behavior > > > before > > the upgrade . > > > Please let us know. > > > > > > > Friendly advice: > > Please setup 9.0.38 locally and test on it. > > 9.0.22 is way too old. It is up to you to use it for your production > > but for reporting bugs it is recommended to use the latest available > version. > > I, personally, prefer to spend my spare time with my family and > > friends than to debug old versions just because the user doesn't > > bother to test on a newer version. > > > > > > > > > > Thanks and Regards > > > Arshiya Shariff > > > > > > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org >
RE: HTTP2: Tomcat sends GOAWAY when trying to respond over a stream where the client has already sent RST_STREAM:NO ERROR
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 closed) as the other streams during the same time are processing data fine . Additional info for GOAWAY: Connection [], Stream[],An error occurred during processing that was fatal to the connection . Thanks and Regards Arshiya Shariff -Original Message- From: Martin Grigorov Sent: Tuesday, September 22, 2020 7:31 PM To: Tomcat Users List Subject: Re: HTTP2: Tomcat sends GOAWAY when trying to respond over a stream where the client has already sent RST_STREAM:NO ERROR Hi, On Tue, Sep 22, 2020 at 1:47 PM Arshiya Shariff wrote: > Thank you so much Martin for the response. > Yes , 9.0.38 testing is on going . > > As we don’t get this clear with the RFC , please help us with the > below two cases : * If a client sends RST_STREAM with NO_ERROR, then while sending async > response is it expected behavior to close connection with GOAWAY ? > * If a client sends RST_STREAM with CANCEL , then while sending > async response will tomcat send RST_STREAM or GOAWAY , from http2 > protocol perspective ? > As per https://tools.ietf.org/html/rfc7540#section-6.4 and https://tools.ietf.org/html/rfc7540#section-5.1 if "send R" or "recv R" are processed then the stream is moved to CLOSED state. GOAWAY should be sent to the client only if the connection will be closed ( https://tools.ietf.org/html/rfc7540#section-6.8). The server should close the connection only if some serious problem has happened, e.g. an IOException. Tell us more about your use case. What do you want to do when 1.5secs pass ? What do you expect to happen ? > > Thanks and Regards > Arshiya Sharif > > -Original Message- > From: Martin Grigorov > Sent: Tuesday, September 22, 2020 1:18 AM > To: Tomcat Users List > Subject: Re: HTTP2: Tomcat sends GOAWAY when trying to respond over a > stream where the client has already sent RST_STREAM:NO ERROR > > Hi, > > On Mon, Sep 21, 2020 at 7:56 PM Arshiya Shariff < > arshiya.shar...@ericsson.com.invalid> wrote: > > > Hi All, > > > > The client has configured a response timeout of 1.5 seconds. In a > > case when our application tries to respond over a http2 stream > > asynchronously after 2 seconds where the client has already sent > > RST_STREAM with NO ERROR in 1.5 seconds > > > Why does the client send NO_ERROR to the server ? I think it should > send a CANCEL instead. > https://tools.ietf.org/html/rfc7540 mentions NO_ERROR only for > "Graceful shutdown of the server". > > > > (due to no response) , then tomcat sends GOAWAY and closes the HTTP2 > > connection . Is this behavior of GOAWAY and connection closure expected ? > > We have planned to upgrade to Embedded tomcat version 9.0.38 . These > > are the behaviors we see in production with version 9.0.22 , so we > > need some help with analyzing / validating the existing behavior > > before > the upgrade . > > Please let us know. > > > > Friendly advice: > Please setup 9.0.38 locally and test on it. > 9.0.22 is way too old. It is up to you to use it for your production > but for reporting bugs it is recommended to use the latest available version. > I, personally, prefer to spend my spare time with my family and > friends than to debug old versions just because the user doesn't > bother to test on a newer version. > > > > > > Thanks and Regards > > Arshiya Shariff > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
