AW: AW: AW: AW: AW: AW: Tomcat 10 with Http2 and compression sometimes closes connection with Firefox
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)? Thanks! Thomas > -Ursprüngliche Nachricht- > Von: Mark Thomas > 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 > >> 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
Re: HOW TO ENABLE LDAPS ON TOMCAT 8.5
Hi Thomas, Really Thank you so much for the response. I will just ask the my AD team to provide the CA certificate which is already installed on the AD domain controller and then place it in client (tomcat web server) trust store if it is not official. Apart from this, i have done some much R in this concern but found mixed answers. By if you have an idea, can you please share any insights. While generating keystore/csr for SSL/TLS using keytool, I used RSA and my CA Team wants me to use 4096 as keysize. And when i configured. I recieve certificate is invalid in browser. Then the first question raised is does keytool RSA support 4096 or only 2048 keysize encryption. Java 1.8 I really appreciate your help and Thanks much once again. Regards Meka Rakesh. On Mon, Sep 19, 2022, 12:09 PM Thomas Hoffmann (Speed4Trade GmbH) wrote: > Hello, > > > -Ursprüngliche Nachricht- > > Von: rakesh meka > > Gesendet: Sonntag, 18. September 2022 22:57 > > An: Tomcat Users List > > Betreff: Re: HOW TO ENABLE LDAPS ON TOMCAT 8.5 > > > > Hi Thomas, > > > > Thanks your so much for the quick response and help. > > > > Having read all the response clearly once again.Not sure if I'm being > foolish. > > > > First question: > > > > So here in general, I would like to just summarize that client will be > the > > application server where I have tomcat installed & application is > deployed. > > Server will the domain controller server(LDAPs certificate to be > installed as > > per the below Microsoft article). > > > > Please correct me if the understanding is correct ? > > Yes, private key (e.g. pfx) is installed on the server side, the AD domain > controller, let's call it AD > > > Second Question: > > > > LDAPs certificate is to be installed domain controller. So that all the > other > > apps on different app servers can query by having connection to domain > > controller (in other terms LDAPs server). > > > > The server needs the pfx-file (private key) and also the certificates > (end-certificate and intermediates if not already present). > The private key is stored secretly and the certificate + intermediates are > sent to the client during initial handshake. > > > > > Third Question: > > > > Domain controller does already have the required certificates installed > for > > LDAP authentication already because previously when I tried with port > > no:389. I could see successful LDAP Connection established & user could > > login successfully. > > > > So now inorder to change from LDAP to LDAPS. Can now please let me know > > the how could I proceed further > > > > IF LDAPS certificate to installed on the APPLICATION SERVER: > > - > > 1. generate the certificate request using keytool. Following the same > process > > as per article 2. Csr 3. Get it signed by CA. > > 4. Keep CA's certificate in Java truststore. > > 5. Then make the port changes & host(domain/LDAP server name). > > 6. Restart the tomcat so that webapp is deployed automatically. > > The client only needs the CA certificate. Certificate requests are not > needed, this is only done once for the server part. > If an official CA was used (e.g. verisign), then the java client normally > already has the CA certificate in the truststure. > If not, you have to import the CAs certificate. The URL hast to change to > https and the LDAPS-port 636. > > The client needs to be able to validate the certificate. For this > validation, the certificates which are sent by the server are used > (end-certificate, intermediates) > and last but not least the CA certificate is used. This builds up a > validation chain from the root-CA, intermediates up to the end-certificate. > As the client trusts the root-CA, it also can trust the servers > certificate (end-certificate). > > > Thanks & Regards, > > Meka Rakesh. > > > > > > > > On Sun, Sep 18, 2022, 4:46 PM Thomas Hoffmann (Speed4Trade GmbH) > > wrote: > > > > > Hello, > > > > > > > -Ursprüngliche Nachricht- > > > > Von: rakesh meka > > > > Gesendet: Sonntag, 18. September 2022 11:53 > > > > An: Tomcat Users List > > > > Betreff: Re: HOW TO ENABLE LDAPS ON TOMCAT 8.5 > > > > > > > > Hi Thomas, > > > > > > > > Good day > > > > > > > > Thanks for the Response. > > > > > > > > I'm not using self signed certificate. I have given the csr file to > > > > our organization certificate admin team. And they got it signed by > > > > some third party vendor and gave me root& intermediate > > > > certificate where I already installed them using keytool on server > > > > side. However, I didn't > > > kept > > > > those in Java truststore. > > > > > > > > So I confirm that domain certificate is not self signed. > > > > > > > > I got to know from one of my colleague that for LDAPs also we need > > > > to generate certificate similarly like domain certificate. Is it > > > > true? If > > > yes can you > > > > let me how to generate the certificate for LDAPs. > > > > > > > > Application: used
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 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
AW: AW: AW: AW: AW: Tomcat 10 with Http2 and compression sometimes closes connection with Firefox
Hello Mark, > -Ursprüngliche Nachricht- > Von: Mark Thomas > 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. > > > > I hope the logs will provide more information. > > > > > > Thanks! Thomas > > > > > > > > Von: Mark Thomas > > Gesendet: Dienstag, 20. September 2022 09:04 > > An: users@tomcat.apache.org > > Betreff: Re: AW: AW: AW: Tomcat 10 with Http2 and compression > > sometimes closes connection with Firefox > > > > On 19/09/2022 19:19, Thomas Hoffmann (Speed4Trade GmbH) wrote: > >> Hello Mark, > >> > >> thanks for the update. > >> > >> The commit looked promising. I tried with Tomcat 10.1 M17 but > unfortunately it didn't help. > >> > >> The partly loaded website is still occuring. > >> > >> > >> Setting http2 logging to fine, I can see the following stack: > > > > That looks like the client reset the stream but that doesn't match > > what you are observing which sounds like Tomcat is truncating the > response. > > > >> 19-Sep-2022 20:07:16.651 FEIN [https-openssl-nio-443-exec-9] > >> org.apache.coyote.AbstractProcessor.setErrorState Error state > >> [CLOSE_NOW] reported while processing request > >> org.apache.coyote.CloseNowException: Connection [1], Stream [23], > >> This stream is not writable > > > > That this is happening with connection 1 is good. It means it should > > be easy to reproduce. Please can you: > > - enable debug logging for HTTP/2 > > - restart Tomcat > > - trigger this problem > > - provide the full debug logs > > > > I want to trace what is happening on the HTTP/2 connection leading up > > to the truncation occurring. > > > > Thanks, > > > > Mark > > > > > >> at org.apache.coyote.http2.Stream.doStreamCancel(Stream.java:258) > >> at > >> > org.apache.coyote.http2.Http2UpgradeHandler.reserveWindowSize(Http2U > p > >> gradeHandler.java:919) at > >> > org.apache.coyote.http2.Stream$StreamOutputBuffer.flush(Stream.java:9 > >> 45) at > >> > org.apache.coyote.http2.Stream$StreamOutputBuffer.flush(Stream.java:8 > >> 91) at > >> > org.apache.coyote.http2.Stream$StreamOutputBuffer.end(Stream.java:990 > >> ) at > >> org.apache.coyote.http11.filters.GzipOutputFilter.end(GzipOutputFilte > >> r.java:128) at > >> org.apache.coyote.http2.Http2OutputBuffer.end(Http2OutputBuffer.java: > >> 71) at > >> > org.apache.coyote.http2.StreamProcessor.finishResponse(StreamProcesso > >> r.java:230) at > >> org.apache.coyote.AbstractProcessor.action(AbstractProcessor.java:391 > >> ) at org.apache.coyote.Response.action(Response.java:210) > >> at > >> org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:25 > >> 8) at > >> org.apache.catalina.connector.Response.finishResponse(Response.java:4 > >> 18) at > >> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav > >> a:388) at > >> org.apache.coyote.http2.StreamProcessor.service(StreamProcessor.java: > >> 426) at > >> org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLig > >> ht.java:65) at > >> > org.apache.coyote.http2.StreamProcessor.process(StreamProcessor.java: > >> 87) at > >> org.apache.coyote.http2.StreamRunnable.run(StreamRunnable.java:35) > >> at > >> > org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoo > >> lExecutor.java:1191) at > >> > org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPo > >> olExecutor.java:659) at > >> > org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskTh > >> read.java:61) at java.base/java.lang.Thread.run(Thread.java:833) > >> Caused by: org.apache.coyote.http2.StreamException: Connection
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 hope the logs will provide more information.
Thanks! Thomas
Von: Mark Thomas
Gesendet: Dienstag, 20. September 2022 09:04
An: users@tomcat.apache.org
Betreff: Re: AW: AW: AW: Tomcat 10 with Http2 and compression sometimes closes
connection with Firefox
On 19/09/2022 19:19, Thomas Hoffmann (Speed4Trade GmbH) wrote:
Hello Mark,
thanks for the update.
The commit looked promising. I tried with Tomcat 10.1 M17 but unfortunately it
didn't help.
The partly loaded website is still occuring.
Setting http2 logging to fine, I can see the following stack:
That looks like the client reset the stream but that doesn't match what
you are observing which sounds like Tomcat is truncating the response.
19-Sep-2022 20:07:16.651 FEIN [https-openssl-nio-443-exec-9]
org.apache.coyote.AbstractProcessor.setErrorState Error state [CLOSE_NOW]
reported while processing request
org.apache.coyote.CloseNowException: Connection [1], Stream [23], This stream
is not writable
That this is happening with connection 1 is good. It means it should be
easy to reproduce. Please can you:
- enable debug logging for HTTP/2
- restart Tomcat
- trigger this problem
- provide the full debug logs
I want to trace what is happening on the HTTP/2 connection leading up to
the truncation occurring.
Thanks,
Mark
at org.apache.coyote.http2.Stream.doStreamCancel(Stream.java:258)
at
org.apache.coyote.http2.Http2UpgradeHandler.reserveWindowSize(Http2UpgradeHandler.java:919)
at org.apache.coyote.http2.Stream$StreamOutputBuffer.flush(Stream.java:945)
at org.apache.coyote.http2.Stream$StreamOutputBuffer.flush(Stream.java:891)
at org.apache.coyote.http2.Stream$StreamOutputBuffer.end(Stream.java:990)
at
org.apache.coyote.http11.filters.GzipOutputFilter.end(GzipOutputFilter.java:128)
at org.apache.coyote.http2.Http2OutputBuffer.end(Http2OutputBuffer.java:71)
at
org.apache.coyote.http2.StreamProcessor.finishResponse(StreamProcessor.java:230)
at org.apache.coyote.AbstractProcessor.action(AbstractProcessor.java:391)
at org.apache.coyote.Response.action(Response.java:210)
at org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:258)
at org.apache.catalina.connector.Response.finishResponse(Response.java:418)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:388)
at org.apache.coyote.http2.StreamProcessor.service(StreamProcessor.java:426)
at
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
at org.apache.coyote.http2.StreamProcessor.process(StreamProcessor.java:87)
at org.apache.coyote.http2.StreamRunnable.run(StreamRunnable.java:35)
at
org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
at
org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: org.apache.coyote.http2.StreamException: Connection [1], Stream
[23], This stream is not writable
at org.apache.coyote.http2.Stream.doStreamCancel(Stream.java:250)
... 20 more
Looks like the Exception bubbles up from the last line of tthis method:
void doStreamCancel(String msg, Http2Error error) throws
CloseNowException {
StreamException se = new StreamException(msg, error, getIdAsInt());
// Prevent the application making further writes
streamOutputBuffer.closed = true;
// Prevent Tomcat's error handling trying to write
coyoteResponse.setError();
coyoteResponse.setErrorReported();
// Trigger a reset once control returns to Tomcat
streamOutputBuffer.reset = se;
throw new CloseNowException(msg, se);
}
The CloseNowException() bubbles up without being caught maybe (?)
Stream.write(...) is not contained here.
Greetings, Thoas
Von: Mark Thomas
Gesendet: Montag, 19. September 2022 19:22
An:
AW: AW: AW: AW: Tomcat 10 with Http2 and compression sometimes closes connection with Firefox
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.
I hope the logs will provide more information.
Thanks! Thomas
Von: Mark Thomas
Gesendet: Dienstag, 20. September 2022 09:04
An: users@tomcat.apache.org
Betreff: Re: AW: AW: AW: Tomcat 10 with Http2 and compression sometimes closes
connection with Firefox
On 19/09/2022 19:19, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> Hello Mark,
>
> thanks for the update.
>
> The commit looked promising. I tried with Tomcat 10.1 M17 but unfortunately
> it didn't help.
>
> The partly loaded website is still occuring.
>
>
> Setting http2 logging to fine, I can see the following stack:
That looks like the client reset the stream but that doesn't match what
you are observing which sounds like Tomcat is truncating the response.
> 19-Sep-2022 20:07:16.651 FEIN [https-openssl-nio-443-exec-9]
> org.apache.coyote.AbstractProcessor.setErrorState Error state [CLOSE_NOW]
> reported while processing request
> org.apache.coyote.CloseNowException: Connection [1], Stream [23], This stream
> is not writable
That this is happening with connection 1 is good. It means it should be
easy to reproduce. Please can you:
- enable debug logging for HTTP/2
- restart Tomcat
- trigger this problem
- provide the full debug logs
I want to trace what is happening on the HTTP/2 connection leading up to
the truncation occurring.
Thanks,
Mark
> at org.apache.coyote.http2.Stream.doStreamCancel(Stream.java:258)
> at
> org.apache.coyote.http2.Http2UpgradeHandler.reserveWindowSize(Http2UpgradeHandler.java:919)
> at org.apache.coyote.http2.Stream$StreamOutputBuffer.flush(Stream.java:945)
> at org.apache.coyote.http2.Stream$StreamOutputBuffer.flush(Stream.java:891)
> at org.apache.coyote.http2.Stream$StreamOutputBuffer.end(Stream.java:990)
> at
> org.apache.coyote.http11.filters.GzipOutputFilter.end(GzipOutputFilter.java:128)
> at org.apache.coyote.http2.Http2OutputBuffer.end(Http2OutputBuffer.java:71)
> at
> org.apache.coyote.http2.StreamProcessor.finishResponse(StreamProcessor.java:230)
> at org.apache.coyote.AbstractProcessor.action(AbstractProcessor.java:391)
> at org.apache.coyote.Response.action(Response.java:210)
> at org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:258)
> at org.apache.catalina.connector.Response.finishResponse(Response.java:418)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:388)
> at org.apache.coyote.http2.StreamProcessor.service(StreamProcessor.java:426)
> at
> org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
> at org.apache.coyote.http2.StreamProcessor.process(StreamProcessor.java:87)
> at org.apache.coyote.http2.StreamRunnable.run(StreamRunnable.java:35)
> at
> org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
> at
> org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
> at
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by: org.apache.coyote.http2.StreamException: Connection [1], Stream
> [23], This stream is not writable
> at org.apache.coyote.http2.Stream.doStreamCancel(Stream.java:250)
> ... 20 more
>
>
>
> Looks like the Exception bubbles up from the last line of tthis method:
>
> void doStreamCancel(String msg, Http2Error error) throws
> CloseNowException {
> StreamException se = new StreamException(msg, error, getIdAsInt());
> // Prevent the application making further writes
> streamOutputBuffer.closed = true;
> // Prevent Tomcat's error handling trying to write
> coyoteResponse.setError();
> coyoteResponse.setErrorReported();
> // Trigger a reset once control returns to Tomcat
> streamOutputBuffer.reset = se;
> throw new CloseNowException(msg, se);
> }
>
> The CloseNowException() bubbles up without being caught maybe (?)
> Stream.write(...) is not contained here.
>
> Greetings, Thoas
>
>
> Von: Mark Thomas
> Gesendet: Montag, 19. September 2022 19:22
> An: users@tomcat.apache.org
> Betreff: Re: AW: AW: Tomcat 10 with Http2 and compression sometimes closes
> connection with Firefox
>
> Thomas,
>
> Please update to the latest 10.1.x release and re-test. There is what
> looks like a fix for this issue in 10.1.0-M12:
>
>
[ANN] Apache Tomcat Migration tool for Jakarta EE 1.0.4
The Apache Tomcat team announces the immediate availability of Apache Tomcat Migration Tool for Jakarta EE 1.0.4 Apache Tomcat Migration Tool for Jakarta EE is an open source software tool for migrating binary web applications (WAR files) and other binary artefacts from Java EE 8 to Jakarta EE 9. The notable changes since 1.0.3 include: - Improve the fix converting web applications that include JARs that store one or more entries in uncompressed form - Add a new conversion profile that converts from Jakarta EE 9 to Java EE 8 Please refer to the change log for the complete list of changes: https://github.com/apache/tomcat-jakartaee-migration/blob/master/CHANGES.md Downloads: http://tomcat.apache.org/download-migration.cgi Enjoy! - The Apache Tomcat team - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: AW: AW: Tomcat 10 with Http2 and compression sometimes closes connection with Firefox
On 19/09/2022 19:19, Thomas Hoffmann (Speed4Trade GmbH) wrote:
Hello Mark,
thanks for the update.
The commit looked promising. I tried with Tomcat 10.1 M17 but unfortunately it
didn't help.
The partly loaded website is still occuring.
Setting http2 logging to fine, I can see the following stack:
That looks like the client reset the stream but that doesn't match what
you are observing which sounds like Tomcat is truncating the response.
19-Sep-2022 20:07:16.651 FEIN [https-openssl-nio-443-exec-9]
org.apache.coyote.AbstractProcessor.setErrorState Error state [CLOSE_NOW]
reported while processing request
org.apache.coyote.CloseNowException: Connection [1], Stream [23], This stream
is not writable
That this is happening with connection 1 is good. It means it should be
easy to reproduce. Please can you:
- enable debug logging for HTTP/2
- restart Tomcat
- trigger this problem
- provide the full debug logs
I want to trace what is happening on the HTTP/2 connection leading up to
the truncation occurring.
Thanks,
Mark
at org.apache.coyote.http2.Stream.doStreamCancel(Stream.java:258)
at
org.apache.coyote.http2.Http2UpgradeHandler.reserveWindowSize(Http2UpgradeHandler.java:919)
at org.apache.coyote.http2.Stream$StreamOutputBuffer.flush(Stream.java:945)
at org.apache.coyote.http2.Stream$StreamOutputBuffer.flush(Stream.java:891)
at org.apache.coyote.http2.Stream$StreamOutputBuffer.end(Stream.java:990)
at
org.apache.coyote.http11.filters.GzipOutputFilter.end(GzipOutputFilter.java:128)
at org.apache.coyote.http2.Http2OutputBuffer.end(Http2OutputBuffer.java:71)
at
org.apache.coyote.http2.StreamProcessor.finishResponse(StreamProcessor.java:230)
at org.apache.coyote.AbstractProcessor.action(AbstractProcessor.java:391)
at org.apache.coyote.Response.action(Response.java:210)
at org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:258)
at org.apache.catalina.connector.Response.finishResponse(Response.java:418)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:388)
at org.apache.coyote.http2.StreamProcessor.service(StreamProcessor.java:426)
at
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
at org.apache.coyote.http2.StreamProcessor.process(StreamProcessor.java:87)
at org.apache.coyote.http2.StreamRunnable.run(StreamRunnable.java:35)
at
org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
at
org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: org.apache.coyote.http2.StreamException: Connection [1], Stream
[23], This stream is not writable
at org.apache.coyote.http2.Stream.doStreamCancel(Stream.java:250)
... 20 more
Looks like the Exception bubbles up from the last line of tthis method:
void doStreamCancel(String msg, Http2Error error) throws CloseNowException
{
StreamException se = new StreamException(msg, error, getIdAsInt());
// Prevent the application making further writes
streamOutputBuffer.closed = true;
// Prevent Tomcat's error handling trying to write
coyoteResponse.setError();
coyoteResponse.setErrorReported();
// Trigger a reset once control returns to Tomcat
streamOutputBuffer.reset = se;
throw new CloseNowException(msg, se);
}
The CloseNowException() bubbles up without being caught maybe (?)
Stream.write(...) is not contained here.
Greetings, Thoas
Von: Mark Thomas
Gesendet: Montag, 19. September 2022 19:22
An: users@tomcat.apache.org
Betreff: Re: AW: AW: Tomcat 10 with Http2 and compression sometimes closes
connection with Firefox
Thomas,
Please update to the latest 10.1.x release and re-test. There is what
looks like a fix for this issue in 10.1.0-M12:
https://github.com/apache/tomcat/commit/b738fa6ee0e6789b104e652d95c982827e9753dd
Mark
On 01/08/2022 21:46, Thomas Hoffmann (Speed4Trade GmbH) wrote:
Hello,
I would create a ticket and sum up all the collected information about this
issue, if there are no further suggestions.
Closing a single stream in http2 causes an internal exception in
StreamProcessor which bubbles up in different ways, depending whether
http-compression is active or not.
In the first case it leads to closing the complete TCP connection.
Thanks! Thomas
-Ursprüngliche Nachricht-
Von: Thomas Hoffmann (Speed4Trade GmbH)
Gesendet: Donnerstag, 28. Juli 2022 22:25
An: Tomcat Users List
Betreff: AW: AW: Tomcat 10 with Http2 and compression sometimes closes
connection with Firefox
Hello Mark,
I got a stack trace which also shows the involvement of the gzip filter. I set
the loglevel for the http2-StreamProcessor to get the details.
The stack trace was written when the problem with FF occurred.
FF closed one single
Re: tomcats starting with 200 threads
hi Christopher, Configuration follows: On Mon, Sep 19, 2022 at 7:45 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > Jon, > > On 9/19/22 10:46, Jonathan Yom-Tov wrote: > > Sometimes one of our production Tomcats will start with the maximum (200) > > number of threads in the https pool. That is, it doesn't start with some > > minimum and works its way up to the maximum, it immediately starts with > the > > maximum. There's no reason for it since most of the threads stay idle > > through the lifetime of the Tomcat. The issue is that this takes up > memory > > and eventually something pushes the Tomcat over the edge and it dies with > > an out of memory error. Any ideas on how to debug or solve this? > > > > The Tomcat version is 9.0.64.0, running on Amazon Linux 2 (amd64) and > Java > > Corretto 1.8.0_312-b07. > > Can you post your configuration? > > -chris > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
