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 <mgrigo...@apache.org> Sent: Friday, September 25, 2020 4:37 PM To: Tomcat Users List <users@tomcat.apache.org> 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 <arshiya.shar...@ericsson.com.invalid> 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 <mgrigo...@apache.org> > Sent: Tuesday, September 22, 2020 7:31 PM > To: Tomcat Users List <users@tomcat.apache.org> > 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 <mgrigo...@apache.org> > > Sent: Tuesday, September 22, 2020 1:18 AM > > To: Tomcat Users List <users@tomcat.apache.org> > > 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 >
