On 21/09/2022 06:48, Thomas Hoffmann (Speed4Trade GmbH) wrote:
Hallo Mark,
thank you for the explanation.
Could you guide me in this case?
Shall I set all logging options in tomcat to trace (logging.properties)?
Thomas,
The level of logging in your most recent off-list trace was perfect. The
issue was that the logging did not show the problem you described.
The issue you described is that the client resets a single stream and
Tomcat then incorrectly closes the entire connection. That in turns
triggers stack traces in the logs as the application attempts to write
to the other streams in the connection as those streams are now closed.
I could not find any evidence of that in the logging you provided. Every
stack trace associated with a write to a closed stream was preceded by
the client sending a reset frame for that stream.
You need to:
- recreate the case of Tomcat closing an entire connection in response
to the client resetting a single stream
- capture HTTP/2 debug logs when this occurs
- provide those logs
Mark
Thanks! Thomas
-----Ursprüngliche Nachricht-----
Von: Mark Thomas <ma...@apache.org>
Gesendet: Dienstag, 20. September 2022 22:28
An: users@tomcat.apache.org
Betreff: Re: AW: AW: AW: AW: AW: Tomcat 10 with Http2 and compression
sometimes closes connection with Firefox
On 20/09/2022 20:22, Thomas Hoffmann (Speed4Trade GmbH) wrote:
Hello Mark,
-----Ursprüngliche Nachricht-----
Von: Mark Thomas <ma...@apache.org>
Gesendet: Dienstag, 20. September 2022 20:13
An: users@tomcat.apache.org
Betreff: Re: AW: AW: AW: AW: Tomcat 10 with Http2 and compression
sometimes closes connection with Firefox
On 20/09/2022 17:58, Thomas Hoffmann (Speed4Trade GmbH) wrote:
Hello Mark,
I will send you the log and access-log to your email address.
I am not sure whether it contradicts the observation.
For example:
- Browser opens a TCP-connection and requests the HTML page.
- Tomcat sends single packages with HTML via http2-stream no 1.
- Browser requests CSS via http2-stream no 2.
- Tomcat serves HTML via stream 1 and css via stream 2.
- Browser closes stream 2 which triggers tomcat to close the whole
TCP
connection including stream 1.
- Thus the html stream is also cancelled, leading to a partly
visible html
page.
Thomas,
I can find no evidence of the sequence above in the logs you provided.
In all the cases I could find, the client first reset the stream
sending
0x08 (cancel) as the reason.
If you can provide a connection and stream id that exhibits the
behaviour you are describing, I'll be happy to look at it.
Mark
I can record a network trace with wireshark if this helps.
The last time I saw that the browser aborts one stream as you described.
It shouldn’t close the whole TCP connection, just the stream.
I try to get a wireshark dump on weekend.
Thomas,
A wireshark trace is unlikely to help. I need the Tomcat debug logs to see
what is happening internally.
You need to provide the debug log trace for an instance where Tomcat
closes the entire connection after the client resets a single stream.
In all the examples in the previous log, every time there was a stack trace for
a stream, it was preceeded by the client resetting that stream
- and hence was normal behaviour.
Mark
---------------------------------------------------------------------
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
