Re: SSL certificate makes site dont work
Carles, On 9/22/20 08:57, Carles Franquesa wrote: > Trying to install an SSL certificate on 8.5.57. > > Once created the cert files, and with a jks available, and set in a > connector into server.xml file, cannot connect to the page. > > The connectors code is > > ''' > > protocol="org.apache.coyote.http11.Http11NioProtocol" > maxThreads="150" > SSLEnabled="true" > scheme="https" > secure="true" > clientAuth="false" > sslProtocol="TLS" > keystoreFile="/opt/tomcat/certificat/app.aprenonline.eu.jks" > keystoreType="JKS" keystorePass="***"/> > > > > ''' > > When trying to connect from the browser, the status bar says "trying to > make a secure connection..." but it hangs at this pont. What URL is showing in the browser? Are there any errors or warnings during startup in the log files? -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[ANN] Apache Tomcat 7.0.106 released
The Apache Tomcat team announces the immediate availability of Apache Tomcat 7.0.106. Apache Tomcat is an open source software implementation of the Java Servlet, JavaServer Pages, Java Expression Language and Java WebSocket technologies. This release contains a number of bug fixes and improvements compared to version 7.0.105. The notable changes since 7.0.105 include: - Add support for a read idle timeout and a write idle timeout to the WebSocket session via custom properties in the user properties instance associated with the session. Based on a pull request by sakshamverma. - Update the packaged version of the Tomcat Native Library to 1.2.25 Please refer to the change log for the complete list of changes: http://tomcat.apache.org/tomcat-7.0-doc/changelog.html Apache Tomcat website: http://tomcat.apache.org Downloads: http://tomcat.apache.org/download-70.cgi Migration guides from Apache Tomcat 5.5.x and 6.0.x: http://tomcat.apache.org/migration.html Enjoy The Apache Tomcat team
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 >
Re: Low throughput with HTTP2
On Mon, Sep 21, 2020 at 4:46 PM Rémy Maucherat wrote: > On Mon, Sep 21, 2020 at 2:49 PM Martin Grigorov > wrote: > > > Hi Remy, > > > > On Mon, Sep 21, 2020 at 2:56 PM Rémy Maucherat wrote: > > > > > > > > > > > > 2020-09-21 14:25:04.850 DEBUG 232086 --- > [https-jsse-nio-18080-exec-8] > > > > o.a.coyote.http11.Http11NioProtocol : Found processor [null] for > > > > socket [org.apache.tomcat.util.net.SecureNioChannel@2b435926 > > > > :java.nio.channels.SocketChannel[connected > > > > local=/127.0.0.1:18080 remote=/127.0.0.1:42229]] > > > > 2020-09-21 14:25:04.850 DEBUG 232086 --- > [https-jsse-nio-18080-exec-6] > > > > o.a.coyote.http2.Http2UpgradeHandler : Connection [2] > > > > > > > > java.io.IOException: Unable to unwrap data, invalid status [CLOSED] > > > > at org.apache.tomcat.util.net > > > > .SecureNioChannel.read(SecureNioChannel.java:766) > > > > at org.apache.tomcat.util.net > > > > > > > > > > .NioEndpoint$NioSocketWrapper$NioOperationState.run(NioEndpoint.java:1468) > > > > > > > > > > When I tested HTTP/2, I used h2c (unencrypted) to get a better idea at > > > what's going on. Otherwise you don't really know what proportion of TLS > > or > > > HTTP/2 impacts performance more [and then you have to test more things > > like > > > OpenSSL, be careful that the ciphers used are the same and equally well > > > optimized in each impl, etc]. > > > > > > Then once you feel happy about h2c, you can see how things go with TLS. > > > > > > > Chris also suggested that TLS might be the problem for the low throughput > > but I get good throughput for both HTTP (15-16 K) and HTTPS (12-13 K > > reqs/s). Only when HTTP2 is enabled it drops. The reason is more clear > now > > - it is due to the extra RST packets being sent. > > > > Vegeta does support h2c! So I can give it a try! > > > > How one configures Tomcat to support h2c ? Just remove ? > > I've just tried this but I am not sure how to verify that it works. > > The browsers do not support h2c. curl and httpie neither. > > Quick search suggested me https://github.com/fstab/h2c "h2c connect > > localhost:18080" failed with "Failed to connect to localhost:18080: tls: > > oversized record received with length 20527" > > > > Yes, it depends on the client. h2load works just fine without TLS for > example, and it's actually the reason why I added h2c support in Tomcat. > > As for the configuration, it's a normal non TLS HTTP/1.1 config with the > UpgradeProtocol element added. > The way to use h2c with curl is: curl -i --http2-prior-knowledge http://localhost:18080/... (with my change in reset() to avoid the connection closes): vegeta ... -http2=f -h2c ... gives 13 K reqs/s vegeta ... -http2 ... gives 8.2 K reqs/s so, it seems TLS reduces the throughput with 40% Martin > > Rémy > > > > > > > > > > > > > > Rémy > > > > > > > > > > > > > > >
Re: Low throughput with HTTP2
On 22/09/2020 13:47, Berneburg, Cris J. - US wrote: > Hi Mark > > As with most topics here, I struggle to understand what is being discussed. > :-) So please bear with me. > >> improving how Tomcat handles traffic like this. >> >> Looks like Tomcat could prune the closed streams >> less aggressively. >> >> At the moment it waits until there are >> maxConcurrentStreams + 10% in the map and then: >> - removes all closed streams without children >> - [snip] with children [snip] >> - [snip] closed final streams [snip] >> >> [snip] the size of the map increases to ~110 and >> then drops to ~5, increases to ~110 and repeats. >> >> I'm currently thinking about different pruning >> strategies. The associated memory footprint is >> also part of my thinking. > > TC thinks the stream should be closed when the client thinks the stream is > still open? Basically RST_STREAM is a keep-alive? No. The stream closed cleanly. The client is sending RST_STREAM due to what is suspected to be a client bug. RFC 7540 says the server must ignore such frames and can, if a frame is received a significant period after the stream closed, treat it as a protocol error (and close the connection). Separately, the server should (as per the RFC) retain state for closed streams to support prioritisation. Currently Tomcat uses a single Map to track the state of closed streams for priority and to identify streams have been closed for an *in*significant amount of time. The issues immediately at hand are: - how that Map is pruned (it is currently too aggressive) - that under high load a "significant period" becomes a few milliseconds Also in the mix: - currently memory footprint of a closed stream is much larger than it needs to be - while we have all the plumbing to correctly determine relative priority and use it when allocating window updates in the case where the connection flow control window is smaller than the total data the streams want to send - we don't use it to prioritise streams when flow control windows are not an issue Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
SSL certificate makes site dont work
Hi, Trying to install an SSL certificate on 8.5.57. Once created the cert files, and with a jks available, and set in a connector into server.xml file, cannot connect to the page. The connectors code is ''' ''' When trying to connect from the browser, the status bar says "trying to make a secure connection..." but it hangs at this pont. Any help would be appreciated Carles
RE: Low throughput with HTTP2
Hi Mark As with most topics here, I struggle to understand what is being discussed. :-) So please bear with me. > improving how Tomcat handles traffic like this. > > Looks like Tomcat could prune the closed streams > less aggressively. > > At the moment it waits until there are > maxConcurrentStreams + 10% in the map and then: > - removes all closed streams without children > - [snip] with children [snip] > - [snip] closed final streams [snip] > > [snip] the size of the map increases to ~110 and > then drops to ~5, increases to ~110 and repeats. > > I'm currently thinking about different pruning > strategies. The associated memory footprint is > also part of my thinking. TC thinks the stream should be closed when the client thinks the stream is still open? Basically RST_STREAM is a keep-alive? So a passenger (client) discharges from a taxi and pays the driver (server), but asks the driver to wait (RST_STREAM), so the meter (stream) is still running. How long does the driver wait (timeout) before driving away? Does the driver honk the horn (send a wake-up packet) before looking for a new customer? Is the issue a matter of "how" or "when"? If TC receives RST_STREAM then restart the timeout clock. To prevent abuse allow a limited number of successive keep-alive frames. If a certain number of RST_STREAM's are received, aka threshold is reached, with nothing else occurring, then close the stream. That could be configurable. How about instead of a binary state of open or closed the state is trinary - open, stale, closed? - Open, don't prune. - Closed, prune. - Stale: a. Move to closed after timeout or too many RST_STREAM's. b. Consider open if receive useful traffic. Also, if there are multiple pruning strategies, allow a single method to be selected per connector config or for the whole TC instance. I hope this is helpful. If not, well, maybe at least it's educational. ;-) -- 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.
RE: HTTP2: Tomcat sends GOAWAY when trying to respond over a stream where the client has already sent RST_STREAM:NO ERROR
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 ? 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 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
