RE: [Possible Spam] Re: HTTP/2 Memory Leak
Thanks for your help, and all the help you provide to people on this list. Your replies are always quick, professional, and helpful. A big part of what makes Tomcat so great is the assistance that can be found on this list! Mark Claassen Senior Software Engineer Donnell Systems, Inc. 130 South Main Street Leighton Plaza Suite 375 South Bend, IN 46601 E-mail: mailto:mclaas...@ocie.net Voice: (574)232-3784 Fax: (574)232-4014 Disclaimer: The opinions provided herein do not necessarily state or reflect those of Donnell Systems, Inc.(DSI). DSI makes no warranty for and assumes no legal liability or responsibility for the posting. -Original Message- From: Mark Thomas Sent: Friday, July 9, 2021 1:31 PM To: users@tomcat.apache.org Subject: Re: [Possible Spam] Re: HTTP/2 Memory Leak On 09/07/2021 18:23, Mark A. Claassen wrote: > Thank you so much! This is good to know. > > We may not change anything then (until that server gets upgraded). However, > would switching back to HTTP 1.1 reduce the memory footprint in the mean time? Yes. The issue is the HTTP/2 priority tree. Essentially, Tomcat has to keep some information around about the previous few hundred requests on every HTTP/2 connection. Until .37/.39 Tomcat just kept objects used for the request/response. As of .37/.39 Tomcat replaces these with a much lighter object once the request is completed. > Would the connection be cleaned up when the browser goes away? Should be. Mark > > Mark Claassen > Senior Software Engineer > > Donnell Systems, Inc. > 130 South Main Street > Leighton Plaza Suite 375 > South Bend, IN 46601 > E-mail: mailto:mclaas...@ocie.net > Voice: (574)232-3784 > Fax: (574)232-4014 > > --- > Confidentiality Notice: OCIESERVICE > --- > The contents of this e-mail message and any attachments are intended solely > for the addressee(s) named in this message. This communication is intended to > be and to remain confidential. If you are not the intended recipient of this > message, or if this message has been addressed to you in error, please > immediately alert the sender by reply e-mail and then delete this message and > its attachments. Do not deliver, distribute, copy, disclose the contents or > take any action in reliance upon the information contained in the > communication or any attachments. > > > -Original Message- > From: Mark Thomas > Sent: Friday, July 9, 2021 12:59 PM > To: users@tomcat.apache.org > Subject: Re: [Possible Spam] Re: HTTP/2 Memory Leak > Importance: Low > > On 09/07/2021 16:21, Mark A. Claassen wrote: >> Thanks. I have done more heap analysis and think I have it tracked closer >> to the source. >> >> -- >> I started looking at the heap a different way. The random values I looked >> at before (of the 80,000) may not have be as representative as I thought. >> >> Examining the retained sizes in the heap, I am finding: >> I have two instances of AbstractProtocol$ConnectionHandler. >> >> One of these AbstractProtocol$ConnectionHandler instances has a >> ConcurrentHashMap called "connections" >> This map as 32 elements in its "table". Most of these are null. Some of >> the ones that are not, are huge. >> The entirety of the map retains 112MG. >> >> Two of these ConcurrentHashMap$Node elements take up around 50MG a piece. >> Looking at the "val" variable of a node, there is an >> UpgradeProcessorInternal Inside this is a variable called >> internalHttpUpgradeHandler (of type Http2UpgradeHandler) The one of these I >> am looking at now retains 16MG of memory. >> (Oddly, once I get this far, the retained sizes of its internal >> objects don't really add up.) >> >> Any ideas on how to work around this? Or if this is already fixed in a >> later version of Tomcat? > > That isn't a leak. That is high memory usage. The objects will be GC'd once > the HTTP/2 connection closes. > > The changes in 9.0.37 / 9.0.39 should reduce the memory footprint > considerably. > > Mark > > >> >> Thanks, >> >> Mark Claassen >> Senior Software Engineer >> >> Donnell Systems, Inc. >> 130 South Main Street >> Leighton Plaza Suite 375 >> South Bend, IN 46601 >> E-mail: mailto:mclaas...@ocie.net >> Voice: (574)232-3784 >> Fax: (574)232-4014 >> >> Disclaimer: >> The opinions provided herein do not necessarily state or reflect >> those of Donnell Systems, Inc.(DSI). DSI makes no warranty for and >> assumes no legal liability or responsibility for the posting
RE: [Possible Spam] Re: HTTP/2 Memory Leak
Thank you so much! This is good to know. We may not change anything then (until that server gets upgraded). However, would switching back to HTTP 1.1 reduce the memory footprint in the mean time? Would the connection be cleaned up when the browser goes away? Mark Claassen Senior Software Engineer Donnell Systems, Inc. 130 South Main Street Leighton Plaza Suite 375 South Bend, IN 46601 E-mail: mailto:mclaas...@ocie.net Voice: (574)232-3784 Fax: (574)232-4014 --- Confidentiality Notice: OCIESERVICE --- The contents of this e-mail message and any attachments are intended solely for the addressee(s) named in this message. This communication is intended to be and to remain confidential. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and its attachments. Do not deliver, distribute, copy, disclose the contents or take any action in reliance upon the information contained in the communication or any attachments. -Original Message- From: Mark Thomas Sent: Friday, July 9, 2021 12:59 PM To: users@tomcat.apache.org Subject: Re: [Possible Spam] Re: HTTP/2 Memory Leak Importance: Low On 09/07/2021 16:21, Mark A. Claassen wrote: > Thanks. I have done more heap analysis and think I have it tracked closer to > the source. > > -- > I started looking at the heap a different way. The random values I looked at > before (of the 80,000) may not have be as representative as I thought. > > Examining the retained sizes in the heap, I am finding: > I have two instances of AbstractProtocol$ConnectionHandler. > > One of these AbstractProtocol$ConnectionHandler instances has a > ConcurrentHashMap called "connections" > This map as 32 elements in its "table". Most of these are null. Some of the > ones that are not, are huge. > The entirety of the map retains 112MG. > > Two of these ConcurrentHashMap$Node elements take up around 50MG a piece. > Looking at the "val" variable of a node, there is an > UpgradeProcessorInternal Inside this is a variable called > internalHttpUpgradeHandler (of type Http2UpgradeHandler) The one of these I > am looking at now retains 16MG of memory. > (Oddly, once I get this far, the retained sizes of its internal > objects don't really add up.) > > Any ideas on how to work around this? Or if this is already fixed in a later > version of Tomcat? That isn't a leak. That is high memory usage. The objects will be GC'd once the HTTP/2 connection closes. The changes in 9.0.37 / 9.0.39 should reduce the memory footprint considerably. Mark > > Thanks, > > Mark Claassen > Senior Software Engineer > > Donnell Systems, Inc. > 130 South Main Street > Leighton Plaza Suite 375 > South Bend, IN 46601 > E-mail: mailto:mclaas...@ocie.net > Voice: (574)232-3784 > Fax: (574)232-4014 > > Disclaimer: > The opinions provided herein do not necessarily state or reflect those > of Donnell Systems, Inc.(DSI). DSI makes no warranty for and assumes > no legal liability or responsibility for the posting. > > > > > -Original Message- > From: Rob Sargent > Sent: Thursday, July 8, 2021 6:50 PM > To: users@tomcat.apache.org > Subject: Re: [Possible Spam] Re: HTTP/2 Memory Leak > Importance: Low > > > > On 7/8/21 3:17 PM, Mark A. Claassen wrote: >> Ok. That didn’t seem to work. I will investigate further and try to find a >> way to send that information. >> >> It is not that busy a server, but the memory use increases very quickly. >> Doing a class_histogram shows MessageBytes growing by the thousands every 30 >> minutes. >> >> (We have a temporary monitor script in place that does a GC and then >> prints a class_histogram every half hour to help us pinpoint what is >> happening.) >> >> Thanks, >> Mark >> > Perhaps you've done this already, but > > grep -R 'static HashMap' src > > might locate some potential culprits. > > > - > 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: [Possible Spam] Re: HTTP/2 Memory Leak
Thanks. I have done more heap analysis and think I have it tracked closer to the source. -- I started looking at the heap a different way. The random values I looked at before (of the 80,000) may not have be as representative as I thought. Examining the retained sizes in the heap, I am finding: I have two instances of AbstractProtocol$ConnectionHandler. One of these AbstractProtocol$ConnectionHandler instances has a ConcurrentHashMap called "connections" This map as 32 elements in its "table". Most of these are null. Some of the ones that are not, are huge. The entirety of the map retains 112MG. Two of these ConcurrentHashMap$Node elements take up around 50MG a piece. Looking at the "val" variable of a node, there is an UpgradeProcessorInternal Inside this is a variable called internalHttpUpgradeHandler (of type Http2UpgradeHandler) The one of these I am looking at now retains 16MG of memory. (Oddly, once I get this far, the retained sizes of its internal objects don't really add up.) Any ideas on how to work around this? Or if this is already fixed in a later version of Tomcat? Thanks, Mark Claassen Senior Software Engineer Donnell Systems, Inc. 130 South Main Street Leighton Plaza Suite 375 South Bend, IN 46601 E-mail: mailto:mclaas...@ocie.net Voice: (574)232-3784 Fax: (574)232-4014 Disclaimer: The opinions provided herein do not necessarily state or reflect those of Donnell Systems, Inc.(DSI). DSI makes no warranty for and assumes no legal liability or responsibility for the posting. -Original Message- From: Rob Sargent Sent: Thursday, July 8, 2021 6:50 PM To: users@tomcat.apache.org Subject: Re: [Possible Spam] Re: HTTP/2 Memory Leak Importance: Low On 7/8/21 3:17 PM, Mark A. Claassen wrote: > Ok. That didn’t seem to work. I will investigate further and try to find a > way to send that information. > > It is not that busy a server, but the memory use increases very quickly. > Doing a class_histogram shows MessageBytes growing by the thousands every 30 > minutes. > > (We have a temporary monitor script in place that does a GC and then prints a > class_histogram every half hour to help us pinpoint what is happening.) > > Thanks, > Mark > Perhaps you've done this already, but grep -R 'static HashMap' src might locate some potential culprits.
RE: [Possible Spam] Re: HTTP/2 Memory Leak
Ok. That didn’t seem to work. I will investigate further and try to find a way to send that information. It is not that busy a server, but the memory use increases very quickly. Doing a class_histogram shows MessageBytes growing by the thousands every 30 minutes. (We have a temporary monitor script in place that does a GC and then prints a class_histogram every half hour to help us pinpoint what is happening.) Thanks, Mark From: Mark A. Claassen Sent: Thursday, July 8, 2021 5:07 PM To: Tomcat Users List Subject: RE: [Possible Spam] Re: HTTP/2 Memory Leak Importance: Low Thanks for the prompt reply. The system was not that busy. Having over 80,000 seems wrong. I am going to try to send a picture; I am not sure if this will work. This is from the Netbeans profiler. [cid:image001.png@01D7741B.B7CC7D90] -Original Message- From: Mark Thomas mailto:ma...@apache.org>> Sent: Thursday, July 8, 2021 2:46 PM To: users@tomcat.apache.org<mailto:users@tomcat.apache.org> Subject: [Possible Spam] Re: HTTP/2 Memory Leak Importance: Low Memory leak, high memory usage or high GC churn? The StreamProcessor shouldn't be a GC root. Either something should be retaining a reference to it or it should be eligible for GC. There isn't much in the way of HTTP/2 specific leaks that have been fixed. For HTTP/2, I'd expect you to see much more impact from the changes around 9.0.37 / 9.0.39 that reduced the footprint of closed HTTP/2 streams. Mark On 08/07/2021 19:32, Mark A. Claassen wrote: > Sorry, realized I had a mistyped subject. > > -Original Message----- > From: Mark A. Claassen mailto:mclaas...@ocie.net>> > Sent: Thursday, July 8, 2021 2:30 PM > To: Tomcat Users List > mailto:users@tomcat.apache.org>> > Subject: Http/s Memory Leak > Importance: Low > > We are using 9.0.12 on a server and noticed a pretty big memory leak. The > change log mentions a some fixed leaks in the releases since 9.0.12. > I was wondering if this leak was fixed already. > > The leak is that there are over 80,000 instances of > org.apache.tomcat.util.buf.MessageBytes. Below is the reference path. > Is this one of the things fixed by setting useAsyncIO="false"? Is there a > downside to using this? > (We are using Http11AprProtocol and OpenSSL) > > Thanks, > Mark > > Reference path of the leak: > MessageBytes > MimeHeaderField > MimeHeaderField[] > MimeHeaders > Response > Stream > ConcurrentHashMap$Node > ConcurrentHashMap$Node > ConcurrentHashMap$Node[] > Http2UpgradeHandler > StreamProcessor (Root) > > Mark Claassen > Senior Software Engineer > > Donnell Systems, Inc. > 130 South Main Street > Leighton Plaza Suite 375 > South Bend, IN 46601 > E-mail: mailto:mclaas...@ocie.net > Voice: (574)232-3784 > Fax: (574)232-4014 > > Disclaimer: > The opinions provided herein do not necessarily state or reflect those of > Donnell Systems, Inc.(DSI). DSI makes no warranty for and assumes no legal > liability or responsibility for the posting. > > > - > To unsubscribe, e-mail: > users-unsubscr...@tomcat.apache.org<mailto:users-unsubscr...@tomcat.apache.org> > For additional commands, e-mail: > users-h...@tomcat.apache.org<mailto:users-h...@tomcat.apache.org> > > > - > To unsubscribe, e-mail: > users-unsubscr...@tomcat.apache.org<mailto:users-unsubscr...@tomcat.apache.org> > For additional commands, e-mail: > users-h...@tomcat.apache.org<mailto:users-h...@tomcat.apache.org> > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org<mailto:users-unsubscr...@tomcat.apache.org> For additional commands, e-mail: users-h...@tomcat.apache.org<mailto:users-h...@tomcat.apache.org>
RE: [Possible Spam] Re: HTTP/2 Memory Leak
Thanks for the prompt reply. The system was not that busy. Having over 80,000 seems wrong. I am going to try to send a picture; I am not sure if this will work. This is from the Netbeans profiler. [cid:image001.png@01D7741B.B7CC7D90] -Original Message- From: Mark Thomas Sent: Thursday, July 8, 2021 2:46 PM To: users@tomcat.apache.org Subject: [Possible Spam] Re: HTTP/2 Memory Leak Importance: Low Memory leak, high memory usage or high GC churn? The StreamProcessor shouldn't be a GC root. Either something should be retaining a reference to it or it should be eligible for GC. There isn't much in the way of HTTP/2 specific leaks that have been fixed. For HTTP/2, I'd expect you to see much more impact from the changes around 9.0.37 / 9.0.39 that reduced the footprint of closed HTTP/2 streams. Mark On 08/07/2021 19:32, Mark A. Claassen wrote: > Sorry, realized I had a mistyped subject. > > -Original Message- > From: Mark A. Claassen mailto:mclaas...@ocie.net>> > Sent: Thursday, July 8, 2021 2:30 PM > To: Tomcat Users List > mailto:users@tomcat.apache.org>> > Subject: Http/s Memory Leak > Importance: Low > > We are using 9.0.12 on a server and noticed a pretty big memory leak. The > change log mentions a some fixed leaks in the releases since 9.0.12. > I was wondering if this leak was fixed already. > > The leak is that there are over 80,000 instances of > org.apache.tomcat.util.buf.MessageBytes. Below is the reference path. > Is this one of the things fixed by setting useAsyncIO="false"? Is there a > downside to using this? > (We are using Http11AprProtocol and OpenSSL) > > Thanks, > Mark > > Reference path of the leak: > MessageBytes > MimeHeaderField > MimeHeaderField[] > MimeHeaders > Response > Stream > ConcurrentHashMap$Node > ConcurrentHashMap$Node > ConcurrentHashMap$Node[] > Http2UpgradeHandler > StreamProcessor (Root) > > Mark Claassen > Senior Software Engineer > > Donnell Systems, Inc. > 130 South Main Street > Leighton Plaza Suite 375 > South Bend, IN 46601 > E-mail: mailto:mclaas...@ocie.net > Voice: (574)232-3784 > Fax: (574)232-4014 > > Disclaimer: > The opinions provided herein do not necessarily state or reflect those of > Donnell Systems, Inc.(DSI). DSI makes no warranty for and assumes no legal > liability or responsibility for the posting. > > > - > To unsubscribe, e-mail: > users-unsubscr...@tomcat.apache.org<mailto:users-unsubscr...@tomcat.apache.org> > For additional commands, e-mail: > users-h...@tomcat.apache.org<mailto:users-h...@tomcat.apache.org> > > > - > To unsubscribe, e-mail: > users-unsubscr...@tomcat.apache.org<mailto:users-unsubscr...@tomcat.apache.org> > For additional commands, e-mail: > users-h...@tomcat.apache.org<mailto:users-h...@tomcat.apache.org> > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org<mailto:users-unsubscr...@tomcat.apache.org> For additional commands, e-mail: users-h...@tomcat.apache.org<mailto:users-h...@tomcat.apache.org>
RE: HTTP/2 Memory Leak
Sorry, realized I had a mistyped subject. -Original Message- From: Mark A. Claassen Sent: Thursday, July 8, 2021 2:30 PM To: Tomcat Users List Subject: Http/s Memory Leak Importance: Low We are using 9.0.12 on a server and noticed a pretty big memory leak. The change log mentions a some fixed leaks in the releases since 9.0.12. I was wondering if this leak was fixed already. The leak is that there are over 80,000 instances of org.apache.tomcat.util.buf.MessageBytes. Below is the reference path. Is this one of the things fixed by setting useAsyncIO="false"? Is there a downside to using this? (We are using Http11AprProtocol and OpenSSL) Thanks, Mark Reference path of the leak: MessageBytes MimeHeaderField MimeHeaderField[] MimeHeaders Response Stream ConcurrentHashMap$Node ConcurrentHashMap$Node ConcurrentHashMap$Node[] Http2UpgradeHandler StreamProcessor (Root) Mark Claassen Senior Software Engineer Donnell Systems, Inc. 130 South Main Street Leighton Plaza Suite 375 South Bend, IN 46601 E-mail: mailto:mclaas...@ocie.net Voice: (574)232-3784 Fax: (574)232-4014 Disclaimer: The opinions provided herein do not necessarily state or reflect those of Donnell Systems, Inc.(DSI). DSI makes no warranty for and assumes no legal liability or responsibility for the posting. - 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
Http/s Memory Leak
We are using 9.0.12 on a server and noticed a pretty big memory leak. The change log mentions a some fixed leaks in the releases since 9.0.12. I was wondering if this leak was fixed already. The leak is that there are over 80,000 instances of org.apache.tomcat.util.buf.MessageBytes. Below is the reference path. Is this one of the things fixed by setting useAsyncIO="false"? Is there a downside to using this? (We are using Http11AprProtocol and OpenSSL) Thanks, Mark Reference path of the leak: MessageBytes MimeHeaderField MimeHeaderField[] MimeHeaders Response Stream ConcurrentHashMap$Node ConcurrentHashMap$Node ConcurrentHashMap$Node[] Http2UpgradeHandler StreamProcessor (Root) Mark Claassen Senior Software Engineer Donnell Systems, Inc. 130 South Main Street Leighton Plaza Suite 375 South Bend, IN 46601 E-mail: mailto:mclaas...@ocie.net Voice: (574)232-3784 Fax: (574)232-4014 Disclaimer: The opinions provided herein do not necessarily state or reflect those of Donnell Systems, Inc.(DSI). DSI makes no warranty for and assumes no legal liability or responsibility for the posting. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: TLSv1.3 Support in Tomcat
My guess would be that whatever JRE webstart is using to launch does not support TLS 1.3. We used webstart for a long time, and this type of error looks pretty familiar. As I am sure you have experienced, just because the browser can connect (with its certifications, proxies, protocols, ...) does not mean that the VM can connect. I think support for TLS 1.3 in JDK 8 started in 261 There is this bug too, but I don't think this manifests itself with a nice error (like "protocol_version"): https://stackoverflow.com/questions/57601284/java-11-and-12-ssl-sockets-fail-on-a-handshake-failure-error-with-tlsv1-3-enable Mark Claassen Senior Software Engineer Donnell Systems, Inc. 130 South Main Street Leighton Plaza Suite 375 South Bend, IN 46601 E-mail: mailto:mclaas...@ocie.net Voice: (574)232-3784 Fax: (574)232-4014 Disclaimer: The opinions provided herein do not necessarily state or reflect those of Donnell Systems, Inc.(DSI). DSI makes no warranty for and assumes no legal liability or responsibility for the posting. -Original Message- From: S Abirami Sent: Tuesday, June 29, 2021 6:01 AM To: Tomcat Users List Subject: [Possible Spam] RE: TLSv1.3 Support in Tomcat Importance: Low Hi ALL, Web UI launched successfully. Using a link in the web UI, we will download and launch a Java Web start Launcher (JNLP). JNLP is not opening, it is due to the problem in Tomcat or it is problem in the JDK. Following exception thrown javax.net.ssl.SSLException: Received fatal alert: protocol_version at sun.security.ssl.Alerts.getSSLException(Unknown Source) at sun.security.ssl.Alerts.getSSLException(Unknown Source) at sun.security.ssl.SSLSocketImpl.recvAlert(Unknown Source) at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source) at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source) at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source) at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source) at sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source) at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.access$200(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection$9.run(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection$9.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at java.security.AccessController.doPrivilegedWithCombiner(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source) at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(Unknown Source) at com.sun.deploy.net.HttpUtils.followRedirects(Unknown Source) at com.sun.deploy.net.BasicHttpRequest.doRequest(Unknown Source) at com.sun.deploy.net.BasicHttpRequest.doRequest(Unknown Source) at com.sun.deploy.net.BasicHttpRequest.doGetRequest(Unknown Source) at com.sun.deploy.net.DownloadEngine.actionDownload(Unknown Source) at com.sun.deploy.net.DownloadEngine.downloadResource(Unknown Source) at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source) at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unkn -Original Message- From: Daniel Savard Sent: Tuesday, June 29, 2021 11:33 AM To: Tomcat Users List Subject: Re: TLSv1.3 Support in Tomcat https://wiki.openssl.org/index.php/TLS1.3#Ciphersuites TLSv1.3 supports 5 cipher suites and none is in your list. - Daniel Savard Le mar. 29 juin 2021 à 01:44, S Abirami a écrit : > Hi Christopher, > > Below is my Connector element, sslEnabledProtocols =TLSv1.2 ,TLS 1.3 > it is working fine with TLSv1.2. When sslEnabledProtocols=TLSv1.3, > Tomcat is started but, the browser unable to perform handshake with webapp. > > Is there any dependency with Cipher suites? > > protocol="com.ericsson.http.protocol.Http11Nio2ProtocolDecryptProp" > port="" maxThreads="200" scheme="https" secure="true" > SSLEnabled="true" keystoreFile="/opt/cert/keystore" > keystorePass="" clientAuth="false" > maxHttpHeaderSize="8192" server="" xpoweredBy="false" > ciphers="TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, > TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, > TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384, > TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_S > HA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, > TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, > TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, >
RE: [Possible Spam] Re: TLSv1.3 Support in Tomcat
I am not sure how it is not working for you, so this may not be relevant. However, this caused me a lot of confusion. https://stackoverflow.com/questions/57601284/java-11-and-12-ssl-sockets-fail-on-a-handshake-failure-error-with-tlsv1-3-enable I had to disable TLS 1.3 to get my Java client to connect to Tomcat. (I had a thread "Strange connection error" and "[Possible Spam] Re: Strange connection error" starting on June 10 or so.) Good luck, Mark Claassen Senior Software Engineer Donnell Systems, Inc. 130 South Main Street Leighton Plaza Suite 375 South Bend, IN 46601 E-mail: mailto:mclaas...@ocie.net Voice: (574)232-3784 Fax: (574)232-4014 Disclaimer: The opinions provided herein do not necessarily state or reflect those of Donnell Systems, Inc.(DSI). DSI makes no warranty for and assumes no legal liability or responsibility for the posting. -Original Message- From: Christopher Schultz Sent: Monday, June 28, 2021 9:57 AM To: users@tomcat.apache.org Subject: [Possible Spam] Re: TLSv1.3 Support in Tomcat Importance: Low Abirami, On 6/28/21 07:16, S Abirami wrote: > TLSv1.3 support is available in Tomcat. > > I tried just updating server.xml[sslEnabledProtocols=TLSv1.3] and > restarted tomcat. It doesn't work. > > [We are using Tomcat 9.0.46 and JDK 8u291] > > Please let me know any other configuration also needs to be changed. Can you please post your configuration (minus any secrets)? When you say "it doesn't work", what exactly do you mean? -chris - 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: [Possible Spam] Re: CATALINA_OPTS vs JAVA_OPTS
While on the subject of CATALINA_OPTS. In 9.0.46, the catalina.sh script displays these when it runs. I have several options in the CATALINA_OPTS, which makes this pretty long. I don't remember it being this way in the past. I would imagine that if this was changed to be like this, there was a good reason, but it makes my startup process look broken. Would having this go to the catalina.out file be a good solution? Or it is critical for others that it is output to stdout? If this is critical, should JAVA_OPTS also be displayed to stdout? - ( In the setenv.sh file, we use enough options that we use line continuation to make the file more readable which makes the CATALINA_OPTS line less readable because of the whitespace. -Xms128M \ -Xmx512M \ ... ) Mark Claassen Senior Software Engineer Donnell Systems, Inc. 130 South Main Street Leighton Plaza Suite 375 South Bend, IN 46601 E-mail: mailto:mclaas...@ocie.net Voice: (574)232-3784 Fax: (574)232-4014 Disclaimer: The opinions provided herein do not necessarily state or reflect those of Donnell Systems, Inc.(DSI). DSI makes no warranty for and assumes no legal liability or responsibility for the posting. -Original Message- From: Noelette Stout Sent: Wednesday, June 16, 2021 1:47 PM To: Tomcat Users List Subject: [Possible Spam] Re: CATALINA_OPTS vs JAVA_OPTS Importance: Low Thanks! That clears things up a lot. I think my admins got confused and did both because there are some instructions that say to add these in JAVA_OPTS, but those instructions are specifically for Windows servers (we're on RHEL). Thanks everyone for all the info and help. On Wed, Jun 16, 2021 at 11:42 AM Mark Thomas wrote: > On 16/06/2021 18:31, Noelette Stout wrote: > > ok, one more question for clarification :-) The vendor docs say > > this: > > "Define CATALINA_OPTS to configure the following JVM settings: > > CATALINA_OPTS=-server -Xms2048m -Xmx4g -XX:MaxMetaspaceSize=512m > > Note:If you are deploying multiple [vendor] applications to the same > Tomcat > > server, -Xmx must be increased by 2g and -XX:MaxMetaspaceSize must > > be increased by 128m." > > > > Given that they are (ostensibly, based on the above statement) JVM > > settings, would these settings be better placed under JAVA_OPTS > > instead > of > > CATALINA_OPTS? > > No. CATALINA_OPTS. > > 99 times out of a 100 you want to put any JVM settings in CATALINA_OPTS. > > Mark > > > > > > > On Wed, Jun 16, 2021 at 10:29 AM Noelette Stout > > > > wrote: > > > >> This confirms something that I was thinking originally, which is > >> that we have no good reason to have both in setenv.sh. I'm pretty > >> sure that > these > >> were both mentioned in various pieces of documentation from the > application > >> vendor. Their documentation tends to be less than stellar. Combine > >> bad documentation with app admins that are completely unfamiliar > >> with > tomcat... > >> and you get messy setups. Unfortunately, there are more of them > >> than > me, so > >> I have to have ALL of my facts straight before I go into battle. > >> > >> Thanks for this additional information. It is much appreciated. > >> > >> On Wed, Jun 16, 2021 at 10:14 AM Christopher Schultz < > >> ch...@christopherschultz.net> wrote: > >> > >>> Noelette, > >>> > >>> On 6/16/21 11:29, Noelette Stout wrote: > >>>> Thanks! I was mostly trying to figure out if there was precedence > >>>> or > if > >>> it > >>>> was additive (i.e. 2GB to tomcat itself and another 2GB to the apps). > >>> We're > >>>> having some resource issues on one of our servers, so I wanted to > >>>> make > >>> sure > >>>> I understood how the resources were being allocated. > >>> > >>> No additivity at all: the last one on the command-line wins. There > >>> is > no > >>> heap separation between Tomcat and the applications: it's one(ish) > >>> big, happy heap. :) > >>> > >>> A note about CATALINA_OPTS versus JAVA_OPTS: when you use the > >>> various scripts provided by Tomcat, CATALINA_OPTS is only used > >>> when launching a Tomcat instance. JAVA_OPTS is used when launching *any* > >>> Java process. > >>> There are many Java processes those scripts will launch that > >>> aren't actually launching Tomcat. Examples include: > >>> > >>> 1. catalina.sh configtest > >>> 2. catal
RE: Strange connection error
Thanks for replies. Everything is working for me now, and I have a bit more of an understanding of how this all works. :) Mark Claassen Senior Software Engineer Donnell Systems, Inc. 130 South Main Street Leighton Plaza Suite 375 South Bend, IN 46601 E-mail: mailto:mclaas...@ocie.net Voice: (574)232-3784 Fax: (574)232-4014 Disclaimer: The opinions provided herein do not necessarily state or reflect those of Donnell Systems, Inc.(DSI). DSI makes no warranty for and assumes no legal liability or responsibility for the posting. -Original Message- From: Mark Thomas Sent: Friday, June 11, 2021 5:00 PM To: users@tomcat.apache.org Subject: Re: Strange connection error On 11/06/2021 21:01, Mark A. Claassen wrote: > RESOLVED. (Sort of, I have questions) I had to add a -TLSv1.3 > protocols="all -SSLv3 -TLSv1 -TLSv1.3" > > https://stackoverflow.com/questions/57601284/java-11-and-12-ssl-socket > s-fail-on-a-handshake-failure-error-with-tlsv1-3-enable > > Why does the version of Tomcat matter? I thought OpenSSL was managing all > this. > Where is the line between all them? OpenSSL only does what it is told. From the 9.0.x changelog 9.0.13 ... Add TLS 1.3 support for the APR/Native connector and the NIO/NIO2 connector when using the OpenSSL backed JSSE implementation. ... Mark > > Thanks, > > Mark Claassen > Senior Software Engineer > > Donnell Systems, Inc. > 130 South Main Street > Leighton Plaza Suite 375 > South Bend, IN 46601 > E-mail: mailto:mclaas...@ocie.net > Voice: (574)232-3784 > Fax: (574)232-4014 > > --- > Confidentiality Notice: OCIESERVICE > --- > The contents of this e-mail message and any attachments are intended solely > for the addressee(s) named in this message. This communication is intended to > be and to remain confidential. If you are not the intended recipient of this > message, or if this message has been addressed to you in error, please > immediately alert the sender by reply e-mail and then delete this message and > its attachments. Do not deliver, distribute, copy, disclose the contents or > take any action in reliance upon the information contained in the > communication or any attachments. > > > -Original Message- > From: Mark A. Claassen > Sent: Friday, June 11, 2021 3:42 PM > To: Tomcat Users List > Subject: RE: Strange connection error > > I have tried so many things, I am getting a bit confused. :) > > The exception was probably using the NIO connector. With the APR one I get: > FINER: Destroying socket [140,404,292,849,904] java.lang.Exception > at > org.apache.tomcat.util.net.AprEndpoint.destroySocketInternal(AprEndpoint.java:750) > at > org.apache.tomcat.util.net.AprEndpoint.access$200(AprEndpoint.java:80) > at org.apache.tomcat.util.net.AprEndpoint$P > > Mark Claassen > Senior Software Engineer > > Donnell Systems, Inc. > 130 South Main Street > Leighton Plaza Suite 375 > South Bend, IN 46601 > E-mail: mailto:mclaas...@ocie.net > Voice: (574)232-3784 > Fax: (574)232-4014 > > --- > Confidentiality Notice: OCIESERVICE > --- > The contents of this e-mail message and any attachments are intended solely > for the addressee(s) named in this message. This communication is intended to > be and to remain confidential. If you are not the intended recipient of this > message, or if this message has been addressed to you in error, please > immediately alert the sender by reply e-mail and then delete this message and > its attachments. Do not deliver, distribute, copy, disclose the contents or > take any action in reliance upon the information contained in the > communication or any attachments. > > > -Original Message- > From: Mark A. Claassen > Sent: Friday, June 11, 2021 3:27 PM > To: Tomcat Users List > Subject: Re: Strange connection error > > I turned all the logging to .FINEST, re-enabled the HTTP APR connector (which > produces the odd access log entry) and got this exception. Now, I just need > to figure out what caused this. > > java.io.EOFException > at > org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.fillReadBuffer(NioEndpoint.java:1345) > at > org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.read(NioEndpoint.java:1255) > at > org.apache.coyote.http11.Http11InputBuffer.fill(Http11InputBuffer.java:799) > at > org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:359) > at > org.apache.coyote.http11.Http11P
RE: Strange connection error
RESOLVED. (Sort of, I have questions) I had to add a -TLSv1.3 protocols="all -SSLv3 -TLSv1 -TLSv1.3" https://stackoverflow.com/questions/57601284/java-11-and-12-ssl-sockets-fail-on-a-handshake-failure-error-with-tlsv1-3-enable Why does the version of Tomcat matter? I thought OpenSSL was managing all this. Where is the line between all them? Thanks, Mark Claassen Senior Software Engineer Donnell Systems, Inc. 130 South Main Street Leighton Plaza Suite 375 South Bend, IN 46601 E-mail: mailto:mclaas...@ocie.net Voice: (574)232-3784 Fax: (574)232-4014 --- Confidentiality Notice: OCIESERVICE --- The contents of this e-mail message and any attachments are intended solely for the addressee(s) named in this message. This communication is intended to be and to remain confidential. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and its attachments. Do not deliver, distribute, copy, disclose the contents or take any action in reliance upon the information contained in the communication or any attachments. -Original Message----- From: Mark A. Claassen Sent: Friday, June 11, 2021 3:42 PM To: Tomcat Users List Subject: RE: Strange connection error I have tried so many things, I am getting a bit confused. :) The exception was probably using the NIO connector. With the APR one I get: FINER: Destroying socket [140,404,292,849,904] java.lang.Exception at org.apache.tomcat.util.net.AprEndpoint.destroySocketInternal(AprEndpoint.java:750) at org.apache.tomcat.util.net.AprEndpoint.access$200(AprEndpoint.java:80) at org.apache.tomcat.util.net.AprEndpoint$P Mark Claassen Senior Software Engineer Donnell Systems, Inc. 130 South Main Street Leighton Plaza Suite 375 South Bend, IN 46601 E-mail: mailto:mclaas...@ocie.net Voice: (574)232-3784 Fax: (574)232-4014 --- Confidentiality Notice: OCIESERVICE --- The contents of this e-mail message and any attachments are intended solely for the addressee(s) named in this message. This communication is intended to be and to remain confidential. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and its attachments. Do not deliver, distribute, copy, disclose the contents or take any action in reliance upon the information contained in the communication or any attachments. -Original Message----- From: Mark A. Claassen Sent: Friday, June 11, 2021 3:27 PM To: Tomcat Users List Subject: Re: Strange connection error I turned all the logging to .FINEST, re-enabled the HTTP APR connector (which produces the odd access log entry) and got this exception. Now, I just need to figure out what caused this. java.io.EOFException at org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.fillReadBuffer(NioEndpoint.java:1345) at org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.read(NioEndpoint.java:1255) at org.apache.coyote.http11.Http11InputBuffer.fill(Http11InputBuffer.java:799) at org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:359) at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:261) at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65) at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:893) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1707) at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:748) Also, I am not sure why OpenSSL is complaining about the keys when it did not with the earlier version of Tomcat? Jun 11, 2021 3:13:34 PM org.apache.tomcat.util.net.openssl.OpenSSLEngine getLastError FINE: OpenSSL error: [336462231] message: [error:140E0197:SSL routines:SSL_shutdown:shutdown while in init] Jun 11, 2021 3:13:34 PM org.apache.tomcat.util.net.openssl.OpenSSLEngine getLastError FINE: OpenSSL error: [337604709] message: [error:141F7065:SSL routines:final_key_share:no suitable key share] Mark Claassen Senior Software Engineer Donnell Systems, Inc. 130 South Main Street Leighton Plaza Suite 375 South Bend, IN 46601 E-mail: mailto:mclaas...@ocie.net Voice: (57
RE: Strange connection error
I have tried so many things, I am getting a bit confused. :) The exception was probably using the NIO connector. With the APR one I get: FINER: Destroying socket [140,404,292,849,904] java.lang.Exception at org.apache.tomcat.util.net.AprEndpoint.destroySocketInternal(AprEndpoint.java:750) at org.apache.tomcat.util.net.AprEndpoint.access$200(AprEndpoint.java:80) at org.apache.tomcat.util.net.AprEndpoint$P Mark Claassen Senior Software Engineer Donnell Systems, Inc. 130 South Main Street Leighton Plaza Suite 375 South Bend, IN 46601 E-mail: mailto:mclaas...@ocie.net Voice: (574)232-3784 Fax: (574)232-4014 --- Confidentiality Notice: OCIESERVICE --- The contents of this e-mail message and any attachments are intended solely for the addressee(s) named in this message. This communication is intended to be and to remain confidential. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and its attachments. Do not deliver, distribute, copy, disclose the contents or take any action in reliance upon the information contained in the communication or any attachments. -Original Message- From: Mark A. Claassen Sent: Friday, June 11, 2021 3:27 PM To: Tomcat Users List Subject: Re: Strange connection error I turned all the logging to .FINEST, re-enabled the HTTP APR connector (which produces the odd access log entry) and got this exception. Now, I just need to figure out what caused this. java.io.EOFException at org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.fillReadBuffer(NioEndpoint.java:1345) at org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.read(NioEndpoint.java:1255) at org.apache.coyote.http11.Http11InputBuffer.fill(Http11InputBuffer.java:799) at org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:359) at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:261) at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65) at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:893) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1707) at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:748) Also, I am not sure why OpenSSL is complaining about the keys when it did not with the earlier version of Tomcat? Jun 11, 2021 3:13:34 PM org.apache.tomcat.util.net.openssl.OpenSSLEngine getLastError FINE: OpenSSL error: [336462231] message: [error:140E0197:SSL routines:SSL_shutdown:shutdown while in init] Jun 11, 2021 3:13:34 PM org.apache.tomcat.util.net.openssl.OpenSSLEngine getLastError FINE: OpenSSL error: [337604709] message: [error:141F7065:SSL routines:final_key_share:no suitable key share] Mark Claassen Senior Software Engineer Donnell Systems, Inc. 130 South Main Street Leighton Plaza Suite 375 South Bend, IN 46601 E-mail: mailto:mclaas...@ocie.net Voice: (574)232-3784 Fax: (574)232-4014 --- Confidentiality Notice: OCIESERVICE --- The contents of this e-mail message and any attachments are intended solely for the addressee(s) named in this message. This communication is intended to be and to remain confidential. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and its attachments. Do not deliver, distribute, copy, disclose the contents or take any action in reliance upon the information contained in the communication or any attachments. -Original Message- From: calder Sent: Thursday, June 10, 2021 7:36 PM To: Tomcat Users List Subject: [Possible Spam] Re: Strange connection error Importance: Low On Thu, Jun 10, 2021, 15:11 Mark A. Claassen wrote: > Anyway, I will do some research on the debugging technique mentioned > earlier. > https://support.f5.com/csp/article/K50557518 > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Strange connection error
I turned all the logging to .FINEST, re-enabled the HTTP APR connector (which produces the odd access log entry) and got this exception. Now, I just need to figure out what caused this. java.io.EOFException at org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.fillReadBuffer(NioEndpoint.java:1345) at org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.read(NioEndpoint.java:1255) at org.apache.coyote.http11.Http11InputBuffer.fill(Http11InputBuffer.java:799) at org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:359) at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:261) at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65) at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:893) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1707) at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:748) Also, I am not sure why OpenSSL is complaining about the keys when it did not with the earlier version of Tomcat? Jun 11, 2021 3:13:34 PM org.apache.tomcat.util.net.openssl.OpenSSLEngine getLastError FINE: OpenSSL error: [336462231] message: [error:140E0197:SSL routines:SSL_shutdown:shutdown while in init] Jun 11, 2021 3:13:34 PM org.apache.tomcat.util.net.openssl.OpenSSLEngine getLastError FINE: OpenSSL error: [337604709] message: [error:141F7065:SSL routines:final_key_share:no suitable key share] Mark Claassen Senior Software Engineer Donnell Systems, Inc. 130 South Main Street Leighton Plaza Suite 375 South Bend, IN 46601 E-mail: mailto:mclaas...@ocie.net Voice: (574)232-3784 Fax: (574)232-4014 --- Confidentiality Notice: OCIESERVICE --- The contents of this e-mail message and any attachments are intended solely for the addressee(s) named in this message. This communication is intended to be and to remain confidential. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and its attachments. Do not deliver, distribute, copy, disclose the contents or take any action in reliance upon the information contained in the communication or any attachments. -Original Message- From: calder Sent: Thursday, June 10, 2021 7:36 PM To: Tomcat Users List Subject: [Possible Spam] Re: Strange connection error Importance: Low On Thu, Jun 10, 2021, 15:11 Mark A. Claassen wrote: > Anyway, I will do some research on the debugging technique mentioned > earlier. > https://support.f5.com/csp/article/K50557518 > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Strange connection error
> "useAprConnector [false], useOpenSSL [true]" I looked at an old server and it said the same, so this is probably not related to my problem. Mark Claassen Senior Software Engineer Donnell Systems, Inc. 130 South Main Street Leighton Plaza Suite 375 South Bend, IN 46601 E-mail: mailto:mclaas...@ocie.net Voice: (574)232-3784 Fax: (574)232-4014 --- Confidentiality Notice: OCIESERVICE --- The contents of this e-mail message and any attachments are intended solely for the addressee(s) named in this message. This communication is intended to be and to remain confidential. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and its attachments. Do not deliver, distribute, copy, disclose the contents or take any action in reliance upon the information contained in the communication or any attachments. -Original Message----- From: Mark A. Claassen Sent: Thursday, June 10, 2021 4:46 PM To: Tomcat Users List Subject: RE: Strange connection error I am still trying to figure out the debugging, but I did see that, going through the reverse proxy and direct, it is using TLS1.2. From wireshark (no debugging) Going through the reverse proxy, there is a ClientHello, two ACK, and then a ServerHello Going direct, I get the ClientHello and two ACK, but no ServerHello. The forth message there is the error response. I am still confused as to why any of this is changed since I am using OpenSSL. Unless the problem is from: "useAprConnector [false], useOpenSSL [true]" Mark Claassen Senior Software Engineer Donnell Systems, Inc. 130 South Main Street Leighton Plaza Suite 375 South Bend, IN 46601 E-mail: mailto:mclaas...@ocie.net Voice: (574)232-3784 Fax: (574)232-4014 --- Confidentiality Notice: OCIESERVICE --- The contents of this e-mail message and any attachments are intended solely for the addressee(s) named in this message. This communication is intended to be and to remain confidential. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and its attachments. Do not deliver, distribute, copy, disclose the contents or take any action in reliance upon the information contained in the communication or any attachments. -Original Message- From: Mark A. Claassen Sent: Thursday, June 10, 2021 4:11 PM To: Tomcat Users List Subject: RE: Strange connection error Here is what I get in catalina.out now. Hopefully this is all correct. I am a bit confused by "useAprConnector [false], useOpenSSL [true]" Anyway, I will do some research on the debugging technique mentioned earlier. -- Jun 10, 2021 4:05:42 PM org.apache.catalina.core.AprLifecycleListener lifecycleEvent INFO: Loaded Apache Tomcat Native library [1.2.28] using APR version [1.6.3]. Jun 10, 2021 4:05:42 PM org.apache.catalina.core.AprLifecycleListener lifecycleEvent INFO: APR capabilities: IPv6 [true], sendfile [true], accept filters [false], random [true]. Jun 10, 2021 4:05:42 PM org.apache.catalina.core.AprLifecycleListener lifecycleEvent INFO: APR/OpenSSL configuration: useAprConnector [false], useOpenSSL [true] Jun 10, 2021 4:05:42 PM org.apache.catalina.core.AprLifecycleListener initializeSSL INFO: OpenSSL successfully initialized [OpenSSL 1.1.1 11 Sep 2018] Jun 10, 2021 4:05:42 PM org.apache.coyote.http11.AbstractHttp11Protocol configureUpgradeProtocol INFO: The ["http-apr-127.0.0.1-8608"] connector has been configured to support HTTP upgrade to [h2c] Mark Claassen Senior Software Engineer Donnell Systems, Inc. 130 South Main Street Leighton Plaza Suite 375 South Bend, IN 46601 E-mail: mailto:mclaas...@ocie.net Voice: (574)232-3784 Fax: (574)232-4014 Disclaimer: The opinions provided herein do not necessarily state or reflect those of Donnell Systems, Inc.(DSI). DSI makes no warranty for and assumes no legal liability or responsibility for the posting. -Original Message- From: Mark A. Claassen Sent: Thursday, June 10, 2021 2:41 PM To: Tomcat Users List Subject: Re: Strange connection error Thanks for the tip. To be honest, I am not exactly sure how to set that up, but since it involves the rebuilding of the native libraries, I will start with that. Maybe that alone will solve the issue. If not, I will try to figure out how to debug all this. If I get stuck, I will post another message. I will also post a message when this is solved, in case anyone else encounters similar behavior. Thanks again, - Mark Claassen Senior Software Engineer Donnell Systems, Inc. 130 South Main Street Leigh
RE: Strange connection error
I am still trying to figure out the debugging, but I did see that, going through the reverse proxy and direct, it is using TLS1.2. From wireshark (no debugging) Going through the reverse proxy, there is a ClientHello, two ACK, and then a ServerHello Going direct, I get the ClientHello and two ACK, but no ServerHello. The forth message there is the error response. I am still confused as to why any of this is changed since I am using OpenSSL. Unless the problem is from: "useAprConnector [false], useOpenSSL [true]" Mark Claassen Senior Software Engineer Donnell Systems, Inc. 130 South Main Street Leighton Plaza Suite 375 South Bend, IN 46601 E-mail: mailto:mclaas...@ocie.net Voice: (574)232-3784 Fax: (574)232-4014 --- Confidentiality Notice: OCIESERVICE --- The contents of this e-mail message and any attachments are intended solely for the addressee(s) named in this message. This communication is intended to be and to remain confidential. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and its attachments. Do not deliver, distribute, copy, disclose the contents or take any action in reliance upon the information contained in the communication or any attachments. -Original Message----- From: Mark A. Claassen Sent: Thursday, June 10, 2021 4:11 PM To: Tomcat Users List Subject: RE: Strange connection error Here is what I get in catalina.out now. Hopefully this is all correct. I am a bit confused by "useAprConnector [false], useOpenSSL [true]" Anyway, I will do some research on the debugging technique mentioned earlier. -- Jun 10, 2021 4:05:42 PM org.apache.catalina.core.AprLifecycleListener lifecycleEvent INFO: Loaded Apache Tomcat Native library [1.2.28] using APR version [1.6.3]. Jun 10, 2021 4:05:42 PM org.apache.catalina.core.AprLifecycleListener lifecycleEvent INFO: APR capabilities: IPv6 [true], sendfile [true], accept filters [false], random [true]. Jun 10, 2021 4:05:42 PM org.apache.catalina.core.AprLifecycleListener lifecycleEvent INFO: APR/OpenSSL configuration: useAprConnector [false], useOpenSSL [true] Jun 10, 2021 4:05:42 PM org.apache.catalina.core.AprLifecycleListener initializeSSL INFO: OpenSSL successfully initialized [OpenSSL 1.1.1 11 Sep 2018] Jun 10, 2021 4:05:42 PM org.apache.coyote.http11.AbstractHttp11Protocol configureUpgradeProtocol INFO: The ["http-apr-127.0.0.1-8608"] connector has been configured to support HTTP upgrade to [h2c] Mark Claassen Senior Software Engineer Donnell Systems, Inc. 130 South Main Street Leighton Plaza Suite 375 South Bend, IN 46601 E-mail: mailto:mclaas...@ocie.net Voice: (574)232-3784 Fax: (574)232-4014 Disclaimer: The opinions provided herein do not necessarily state or reflect those of Donnell Systems, Inc.(DSI). DSI makes no warranty for and assumes no legal liability or responsibility for the posting. -----Original Message- From: Mark A. Claassen Sent: Thursday, June 10, 2021 2:41 PM To: Tomcat Users List Subject: Re: Strange connection error Thanks for the tip. To be honest, I am not exactly sure how to set that up, but since it involves the rebuilding of the native libraries, I will start with that. Maybe that alone will solve the issue. If not, I will try to figure out how to debug all this. If I get stuck, I will post another message. I will also post a message when this is solved, in case anyone else encounters similar behavior. Thanks again, - Mark Claassen Senior Software Engineer Donnell Systems, Inc. 130 South Main Street Leighton Plaza Suite 375 South Bend, IN 46601 E-mail: mailto:mclaas...@ocie.net Voice: (574)232-3784 Fax: (574)232-4014 --- Confidentiality Notice: OCIESERVICE --- The contents of this e-mail message and any attachments are intended solely for the addressee(s) named in this message. This communication is intended to be and to remain confidential. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and its attachments. Do not deliver, distribute, copy, disclose the contents or take any action in reliance upon the information contained in the communication or any attachments. -Original Message- From: Mark Thomas Sent: Thursday, June 10, 2021 2:01 PM To: users@tomcat.apache.org Subject: [Possible Spam] Re: Strange connection error Importance: Low On 10/06/2021 18:11, Mark A. Claassen wrote: > Thanks for the reply. > > Is doesn't seem like OpenSSL is rejecting the connection. I would have > thought that if OpenSSL would have rejected th
RE: Strange connection error
Here is what I get in catalina.out now. Hopefully this is all correct. I am a bit confused by "useAprConnector [false], useOpenSSL [true]" Anyway, I will do some research on the debugging technique mentioned earlier. -- Jun 10, 2021 4:05:42 PM org.apache.catalina.core.AprLifecycleListener lifecycleEvent INFO: Loaded Apache Tomcat Native library [1.2.28] using APR version [1.6.3]. Jun 10, 2021 4:05:42 PM org.apache.catalina.core.AprLifecycleListener lifecycleEvent INFO: APR capabilities: IPv6 [true], sendfile [true], accept filters [false], random [true]. Jun 10, 2021 4:05:42 PM org.apache.catalina.core.AprLifecycleListener lifecycleEvent INFO: APR/OpenSSL configuration: useAprConnector [false], useOpenSSL [true] Jun 10, 2021 4:05:42 PM org.apache.catalina.core.AprLifecycleListener initializeSSL INFO: OpenSSL successfully initialized [OpenSSL 1.1.1 11 Sep 2018] Jun 10, 2021 4:05:42 PM org.apache.coyote.http11.AbstractHttp11Protocol configureUpgradeProtocol INFO: The ["http-apr-127.0.0.1-8608"] connector has been configured to support HTTP upgrade to [h2c] Mark Claassen Senior Software Engineer Donnell Systems, Inc. 130 South Main Street Leighton Plaza Suite 375 South Bend, IN 46601 E-mail: mailto:mclaas...@ocie.net Voice: (574)232-3784 Fax: (574)232-4014 Disclaimer: The opinions provided herein do not necessarily state or reflect those of Donnell Systems, Inc.(DSI). DSI makes no warranty for and assumes no legal liability or responsibility for the posting. -Original Message- From: Mark A. Claassen Sent: Thursday, June 10, 2021 2:41 PM To: Tomcat Users List Subject: Re: Strange connection error Thanks for the tip. To be honest, I am not exactly sure how to set that up, but since it involves the rebuilding of the native libraries, I will start with that. Maybe that alone will solve the issue. If not, I will try to figure out how to debug all this. If I get stuck, I will post another message. I will also post a message when this is solved, in case anyone else encounters similar behavior. Thanks again, - Mark Claassen Senior Software Engineer Donnell Systems, Inc. 130 South Main Street Leighton Plaza Suite 375 South Bend, IN 46601 E-mail: mailto:mclaas...@ocie.net Voice: (574)232-3784 Fax: (574)232-4014 --- Confidentiality Notice: OCIESERVICE --- The contents of this e-mail message and any attachments are intended solely for the addressee(s) named in this message. This communication is intended to be and to remain confidential. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and its attachments. Do not deliver, distribute, copy, disclose the contents or take any action in reliance upon the information contained in the communication or any attachments. -Original Message- From: Mark Thomas Sent: Thursday, June 10, 2021 2:01 PM To: users@tomcat.apache.org Subject: [Possible Spam] Re: Strange connection error Importance: Low On 10/06/2021 18:11, Mark A. Claassen wrote: > Thanks for the reply. > > Is doesn't seem like OpenSSL is rejecting the connection. I would have > thought that if OpenSSL would have rejected the connection, it would not hit > even hit the access log. Maybe that is not the case. > > But, to answer your question, we did not upgrade the version of Java. We are > using 1.8.0_265 on the server. The Java client did not change either. Try using Wireshark with SSLKEYLOGFILE to look at the decrypted version. You'll get a lot more info about what is going on. I think you'll need to update Tomcat Native to do that though. I don't think Java supports that env variable. Mark > > > > Mark Claassen > Senior Software Engineer > > Donnell Systems, Inc. > 130 South Main Street > Leighton Plaza Suite 375 > South Bend, IN 46601 > E-mail: mailto:mclaas...@ocie.net > Voice: (574)232-3784 > Fax: (574)232-4014 > > Disclaimer: > The opinions provided herein do not necessarily state or reflect those > of Donnell Systems, Inc.(DSI). DSI makes no warranty for and assumes > no legal liability or responsibility for the posting. > > > -Original Message- > From: jonmcalexan...@wellsfargo.com.INVALID > > Sent: Thursday, June 10, 2021 12:02 PM > To: users@tomcat.apache.org > Subject: [Possible Spam] RE: Strange connection error > Importance: Low > > Is it a cypher issue? (noting the handshake issue). Did you also upgrade the > Java at the same time? > > Dream * Excel * Explore * Inspire > Jon McAlexander > Infrastructure Engineer > Asst Vice President > > Middleware Product Engineering > Enterprise CIO | Platf
Re: Strange connection error
Thanks for the tip. To be honest, I am not exactly sure how to set that up,
but since it involves the rebuilding of the native libraries, I will start with
that. Maybe that alone will solve the issue.
If not, I will try to figure out how to debug all this. If I get stuck, I will
post another message. I will also post a message when this is solved, in case
anyone else encounters similar behavior.
Thanks again,
-
Mark Claassen
Senior Software Engineer
Donnell Systems, Inc.
130 South Main Street
Leighton Plaza Suite 375
South Bend, IN 46601
E-mail: mailto:mclaas...@ocie.net
Voice: (574)232-3784
Fax: (574)232-4014
---
Confidentiality Notice: OCIESERVICE
---
The contents of this e-mail message and any attachments are intended solely for
the addressee(s) named in this message. This communication is intended to be
and to remain confidential. If you are not the intended recipient of this
message, or if this message has been addressed to you in error, please
immediately alert the sender by reply e-mail and then delete this message and
its attachments. Do not deliver, distribute, copy, disclose the contents or
take any action in reliance upon the information contained in the communication
or any attachments.
-Original Message-
From: Mark Thomas
Sent: Thursday, June 10, 2021 2:01 PM
To: users@tomcat.apache.org
Subject: [Possible Spam] Re: Strange connection error
Importance: Low
On 10/06/2021 18:11, Mark A. Claassen wrote:
> Thanks for the reply.
>
> Is doesn't seem like OpenSSL is rejecting the connection. I would have
> thought that if OpenSSL would have rejected the connection, it would not hit
> even hit the access log. Maybe that is not the case.
>
> But, to answer your question, we did not upgrade the version of Java. We are
> using 1.8.0_265 on the server. The Java client did not change either.
Try using Wireshark with SSLKEYLOGFILE to look at the decrypted version.
You'll get a lot more info about what is going on. I think you'll need to
update Tomcat Native to do that though. I don't think Java supports that env
variable.
Mark
>
> ----
>
> Mark Claassen
> Senior Software Engineer
>
> Donnell Systems, Inc.
> 130 South Main Street
> Leighton Plaza Suite 375
> South Bend, IN 46601
> E-mail: mailto:mclaas...@ocie.net
> Voice: (574)232-3784
> Fax: (574)232-4014
>
> Disclaimer:
> The opinions provided herein do not necessarily state or reflect those
> of Donnell Systems, Inc.(DSI). DSI makes no warranty for and assumes
> no legal liability or responsibility for the posting.
>
>
> -Original Message-
> From: jonmcalexan...@wellsfargo.com.INVALID
>
> Sent: Thursday, June 10, 2021 12:02 PM
> To: users@tomcat.apache.org
> Subject: [Possible Spam] RE: Strange connection error
> Importance: Low
>
> Is it a cypher issue? (noting the handshake issue). Did you also upgrade the
> Java at the same time?
>
> Dream * Excel * Explore * Inspire
> Jon McAlexander
> Infrastructure Engineer
> Asst Vice President
>
> Middleware Product Engineering
> Enterprise CIO | Platform Services | Middleware | Infrastructure
> Solutions
>
> 8080 Cobblestone Rd | Urbandale, IA 50322
> MAC: F4469-010
> Tel 515-988-2508 | Cell 515-988-2508
>
> jonmcalexan...@wellsfargo.com
>
> Upcoming PTO: 10/30/2020, 11/6/2020, 11/13/2020, 11/20/2020, 11/27/2020,
> 12/2/2020, 12/4/2020, 12/11/2020, 12/18/2020, 12/28/2020, 12/29/2020,
> 12/30/2020, 12/31/2020 This message may contain confidential and/or
> privileged information. If you are not the addressee or authorized to receive
> this for the addressee, you must not use, copy, disclose, or take any action
> based on this message or any information herein. If you have received this
> message in error, please advise the sender immediately by reply e-mail and
> delete this message. Thank you for your cooperation.
>
>
>> -Original Message-
>> From: Mark A. Claassen
>> Sent: Thursday, June 10, 2021 10:38 AM
>> To: users@tomcat.apache.org
>> Subject: Strange connection error
>>
>> I just upgraded from 9.0.12 to 9.0.46. Everything seemed to go
>> pretty smoothly, but I am getting a strange connection error from
>> certain connections
>>
>> We have several different things that connect to the webserver.
>> Browsers connect fine. We have a monitoring script in Perl that
>> works fine. However, a Java program, which worked fine under the old
>> version of tomcat, can no longer connect.
>>
>> The access log prints out very odd information. Right now it is configured
>> as:
>> pattern="%{-MM-dd HH:mm:ss}t %H %h %m
RE: Strange connection error
Thanks for the reply.
Is doesn't seem like OpenSSL is rejecting the connection. I would have thought
that if OpenSSL would have rejected the connection, it would not hit even hit
the access log. Maybe that is not the case.
But, to answer your question, we did not upgrade the version of Java. We are
using 1.8.0_265 on the server. The Java client did not change either.
Mark Claassen
Senior Software Engineer
Donnell Systems, Inc.
130 South Main Street
Leighton Plaza Suite 375
South Bend, IN 46601
E-mail: mailto:mclaas...@ocie.net
Voice: (574)232-3784
Fax: (574)232-4014
Disclaimer:
The opinions provided herein do not necessarily state or reflect
those of Donnell Systems, Inc.(DSI). DSI makes no warranty for and
assumes no legal liability or responsibility for the posting.
-Original Message-
From: jonmcalexan...@wellsfargo.com.INVALID
Sent: Thursday, June 10, 2021 12:02 PM
To: users@tomcat.apache.org
Subject: [Possible Spam] RE: Strange connection error
Importance: Low
Is it a cypher issue? (noting the handshake issue). Did you also upgrade the
Java at the same time?
Dream * Excel * Explore * Inspire
Jon McAlexander
Infrastructure Engineer
Asst Vice President
Middleware Product Engineering
Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions
8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508
jonmcalexan...@wellsfargo.com
Upcoming PTO: 10/30/2020, 11/6/2020, 11/13/2020, 11/20/2020, 11/27/2020,
12/2/2020, 12/4/2020, 12/11/2020, 12/18/2020, 12/28/2020, 12/29/2020,
12/30/2020, 12/31/2020 This message may contain confidential and/or privileged
information. If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based on this
message or any information herein. If you have received this message in error,
please advise the sender immediately by reply e-mail and delete this message.
Thank you for your cooperation.
> -Original Message-
> From: Mark A. Claassen
> Sent: Thursday, June 10, 2021 10:38 AM
> To: users@tomcat.apache.org
> Subject: Strange connection error
>
> I just upgraded from 9.0.12 to 9.0.46. Everything seemed to go pretty
> smoothly, but I am getting a strange connection error from certain
> connections
>
> We have several different things that connect to the webserver.
> Browsers connect fine. We have a monitoring script in Perl that works
> fine. However, a Java program, which worked fine under the old
> version of tomcat, can no longer connect.
>
> The access log prints out very odd information. Right now it is configured
> as:
> pattern="%{-MM-dd HH:mm:ss}t %H %h %m %U
> %q STATUS(%s) BYTES(%b) %{User-Agent}i
> %{Referer}i& quot; %I"/>
>
> However the output for this failed connection is:
> 2021-06-10 11:21:19 null [[Actual IP address]] null "null" ""
> STATUS(400) BYTES(-) "-" "-" null All other connections show in the
> access log as I would expect.
>
> Does anyone have any idea what is going on here?
> -
> Extra Information:
> - I am using the APR connector and OpenSSL.
> - I did not recompile any of the native libraries; they are still
> using the ones from 9.0.12.
> - We have an Apache webserver we use as a reverse proxy. When
> connecting through that, things work.
>
> - Wireshark has this to say about the failure:
>
> TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Handshake
> Failure)
> Content Type: Alert (21)
> Length: 2
> Alert Message
> Level: Fatal (2)
> Description: Handshake Failure (40) Thanks for your
> time, Mark
>
> ---
> Mark Claassen
> Senior Software Engineer
>
> Donnell Systems, Inc.
> 130 South Main Street
> Leighton Plaza Suite 375
> South Bend, IN 46601
> E-mail: mailto:mclaas...@ocie.net
> Voice: (574)232-3784
> Fax: (574)232-4014
>
> Disclaimer:
> The opinions provided herein do not necessarily state or reflect those
> of Donnell Systems, Inc.(DSI). DSI makes no warranty for and assumes
> no legal liability or responsibility for the posting.
>
>
>
> -
> 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
Strange connection error
I just upgraded from 9.0.12 to 9.0.46. Everything seemed to go pretty
smoothly, but I am getting a strange connection error from certain connections
We have several different things that connect to the webserver. Browsers
connect fine. We have a monitoring script in Perl that works fine. However, a
Java program, which worked fine under the old version of tomcat, can no longer
connect.
The access log prints out very odd information. Right now it is configured as:
pattern="%{-MM-dd HH:mm:ss}t %H %h %m %U %q
STATUS(%s) BYTES(%b) %{User-Agent}i %{Referer}i&
quot; %I"/>
However the output for this failed connection is:
2021-06-10 11:21:19 null [[Actual IP address]] null "null" ""
STATUS(400) BYTES(-) "-" "-" null
All other connections show in the access log as I would expect.
Does anyone have any idea what is going on here?
-
Extra Information:
- I am using the APR connector and OpenSSL.
- I did not recompile any of the native libraries; they are still using the
ones from 9.0.12.
- We have an Apache webserver we use as a reverse proxy. When connecting
through that, things work.
- Wireshark has this to say about the failure:
TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Handshake
Failure)
Content Type: Alert (21)
Length: 2
Alert Message
Level: Fatal (2)
Description: Handshake Failure (40)
Thanks for your time,
Mark
---
Mark Claassen
Senior Software Engineer
Donnell Systems, Inc.
130 South Main Street
Leighton Plaza Suite 375
South Bend, IN 46601
E-mail: mailto:mclaas...@ocie.net
Voice: (574)232-3784
Fax: (574)232-4014
Disclaimer:
The opinions provided herein do not necessarily state or reflect
those of Donnell Systems, Inc.(DSI). DSI makes no warranty for and
assumes no legal liability or responsibility for the posting.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: NullPointerException in CoyoteOutputStream
Thanks for the reply, and sorry for the confusion. I catch the error in my
code and format it in a custom way, which is why it may look a bit different
than what you expect.
That was not the complete stack, but the top is the top, which implies that
'ob' is null
After the ByteCounterOutputStream line, there is more of my code until I
eventually get to:
HttpServlet.service(HttpServlet.java:660)
The ByteCounterOutputStream wraps the HttpServletResponse.getOutputStream() and
the error occurs when it is trying to write to the stream.
My code has been relatively unchanged for years. Additionally, this load test
has succeeded using this version of tomcat of 10,000s of iterations.
However, maybe some once-in-a-million occurrence happened and corrupted at
least of one instance of the CoyoteOutputStream?
And then whenever one of these gets reused, I can't write to the output stream.
CoyoteOutputStream.checkNonBlockingWrite(CoyoteOutputStream.java:134)
CoyoteOutputStream.write(CoyoteOutputStream.java:95)
CoyoteOutputStream.write(CoyoteOutputStream.java:89)
ByteCounterOutputStream.write(ByteCounterOutputStream.java:37) <-- My code
doing a write()
private boolean checkNonBlockingWrite() {
boolean nonBlocking = !ob.isBlocking(); <-- 134 (NPE here implies ob is
null)
if (nonBlocking && !ob.isReady()) {
throw new
IllegalStateException(sm.getString("coyoteOutputStream.nbNotready"));
}
return nonBlocking;
}
public void write(byte[] b, int off, int len) throws IOException {
boolean nonBlocking = checkNonBlockingWrite(); <-- 95
ob.write(b, off, len);
if (nonBlocking) {
checkRegisterForWrite();
}
}
public void write(byte[] b) throws IOException {
write(b, 0, b.length); <-- 89
}
-Original Message-
From: calder
Sent: Friday, June 12, 2020 12:31 PM
To: Tomcat Users List
Subject: Re: NullPointerException in CoyoteOutputStream
On Fri, Jun 12, 2020, 10:36 Mark A. Claassen wrote:
> We were doing some load testing and we started getting a
> NullPointerException at the stack trace below. We don't get the NPE
> all the time, so I am guessing some of these objects got corrupted somehow.
> One place the clear() method is called from is the recycle() method in
> the Response object from the same package.
>
> Has anyone seen this before? My Internet searches did not reveal any
> other reports of this. Is this something that has already been fixed
> in the course of other changes?
>
> The version of Tomcat is 9.0.12 and we are using the openSSL
> underneath all this.
>
> ---
> at
> org.apache.catalina.connector.CoyoteOutputStream.checkNonBlockingWrite
> (CoyoteOutputStream.java:134)
> at
> org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStr
> eam.java:95)
> at
> org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStr
> eam.java:89)
> at dsi.core.io
> .ByteCounterOutputStream.write(ByteCounterOutputStream.java:37)
>
Apologies ... but this doesn't look like a complete stack trace, to include any
"caused by" statements (and the originating statement)
CoyoteOutputStream
> private boolean checkNonBlockingWrite() {
> boolean nonBlocking = !ob.isBlocking(); <-- Line 134
> if (nonBlocking && !ob.isReady()) {
> throw new
> IllegalStateException(sm.getString("coyoteOutputStream.nbNotready"));
> }
> return nonBlocking;
> }
> --- CoyoteOutputStream
> /**
> * Clear facade.
> */
> void clear() {
> ob = null;
> }
> --- CoyoteOutputStream
> @Override
> public void close() throws IOException {
> ob.close();
> }
> ---
NullPointerException in CoyoteOutputStream
We were doing some load testing and we started getting a NullPointerException
at the stack trace below. We don't get the NPE all the time, so I am guessing
some of these objects got corrupted somehow.
One place the clear() method is called from is the recycle() method in the
Response object from the same package.
Has anyone seen this before? My Internet searches did not reveal any other
reports of this. Is this something that has already been fixed in the course
of other changes?
The version of Tomcat is 9.0.12 and we are using the openSSL underneath all
this.
Thanks,
Mark
---
at
org.apache.catalina.connector.CoyoteOutputStream.checkNonBlockingWrite(CoyoteOutputStream.java:134)
at
org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.java:95)
at
org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.java:89)
at dsi.core.io.ByteCounterOutputStream.write(ByteCounterOutputStream.java:37)
--- CoyoteOutputStream
private boolean checkNonBlockingWrite() {
boolean nonBlocking = !ob.isBlocking(); <-- Line 134
if (nonBlocking && !ob.isReady()) {
throw new
IllegalStateException(sm.getString("coyoteOutputStream.nbNotready"));
}
return nonBlocking;
}
--- CoyoteOutputStream
/**
* Clear facade.
*/
void clear() {
ob = null;
}
--- CoyoteOutputStream
@Override
public void close() throws IOException {
ob.close();
}
---
Mark Claassen
Senior Software Engineer
Donnell Systems, Inc.
130 South Main Street
Leighton Plaza Suite 375
South Bend, IN 46601
E-mail: mailto:mclaas...@ocie.net
Voice: (574)232-3784
Fax: (574)232-4014
Disclaimer:
The opinions provided herein do not necessarily state or reflect
those of Donnell Systems, Inc.(DSI). DSI makes no warranty for and
assumes no legal liability or responsibility for the posting.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Which native package should I use
Thanks. I compiled Tomcat myself and saw that the Native libraries are a part of that and so I built the Java part. However, I see in the binary distribution, these are not included. I guess I was being a bit too eager. Mark Claassen Senior Software Engineer Donnell Systems, Inc. 130 South Main Street Leighton Plaza Suite 375 South Bend, IN 46601 E-mail: mailto:mclaas...@ocie.net Voice: (574)232-3784 Fax: (574)232-4014 --- Confidentiality Notice: OCIESERVICE --- The contents of this e-mail message and any attachments are intended solely for the addressee(s) named in this message. This communication is intended to be and to remain confidential. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and its attachments. Do not deliver, distribute, copy, disclose the contents or take any action in reliance upon the information contained in the communication or any attachments. -Original Message- From: Mark Thomas Sent: Tuesday, June 25, 2019 12:43 PM To: users@tomcat.apache.org Subject: Re: Which native package should I use On 25/06/2019 16:11, Mark A. Claassen wrote: > I recently noticed that my tomcat-native library was in the wrong location > and not accessible to Tomcat. However, I was very surprised that this seems > to be not matter. Then I noticed that the tomcat-jni.jar looks like the same > thing. > > Do I need to use the tomcat-native JAR file (tomcat-native-1.2.16.jar)? Or > can I just bundled tomcat-jni.jar? > There is a org.apache.tomcat.jni package in the tomcat source. Is this the > same thing as the tomcat-native libraries at the time the distribution is > built? There are two parts to the native code. The native binary and the Java interface. It does look like those two JARs are just different packagings of the same Java interface. As long as the Java interface is the same major version and at least the same minor version as the native library you should be OK. Mark > > > Thanks, > Mark > > Mark Claassen > Senior Software Engineer > > Donnell Systems, Inc. > 130 South Main Street > Leighton Plaza Suite 375 > South Bend, IN 46601 > E-mail: mailto:mclaas...@ocie.net > Voice: (574)232-3784 > Fax: (574)232-4014 > > --- > Confidentiality Notice: OCIESERVICE > --- > The contents of this e-mail message and any attachments are intended solely > for the addressee(s) named in this message. This communication is intended to > be and to remain confidential. If you are not the intended recipient of this > message, or if this message has been addressed to you in error, please > immediately alert the sender by reply e-mail and then delete this message and > its attachments. Do not deliver, distribute, copy, disclose the contents or > take any action in reliance upon the information contained in the > communication or any attachments. > > > > - > 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
Which native package should I use
I recently noticed that my tomcat-native library was in the wrong location and not accessible to Tomcat. However, I was very surprised that this seems to be not matter. Then I noticed that the tomcat-jni.jar looks like the same thing. Do I need to use the tomcat-native JAR file (tomcat-native-1.2.16.jar)? Or can I just bundled tomcat-jni.jar? There is a org.apache.tomcat.jni package in the tomcat source. Is this the same thing as the tomcat-native libraries at the time the distribution is built? Thanks, Mark Mark Claassen Senior Software Engineer Donnell Systems, Inc. 130 South Main Street Leighton Plaza Suite 375 South Bend, IN 46601 E-mail: mailto:mclaas...@ocie.net Voice: (574)232-3784 Fax: (574)232-4014 --- Confidentiality Notice: OCIESERVICE --- The contents of this e-mail message and any attachments are intended solely for the addressee(s) named in this message. This communication is intended to be and to remain confidential. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and its attachments. Do not deliver, distribute, copy, disclose the contents or take any action in reliance upon the information contained in the communication or any attachments. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Overriding MultiPartConfig
Thanks for the reply! I have been working this for a while and having been failing. There is so much going on here that I don't understand that I feel like such a newby. First, when the multi-part config is in my local web.xml, everything works. However, if I remove that whole servlet from my web.xml, I see that Jersey initializes my servlet on its own first, and then my context listener tries to add it again and the registration object I get back from addServlet is null. I assume that Jersey is doing this auto-configuration based on the annotations I use, but if this is true, why does it work when the configuration is in my web.xml? The org.apache.catalina.Wrapper created in the Application has an Overridable property, but it is false here. Any help would be appreciated. Is this more of a Jersey question? Mark Claassen Senior Software Engineer Donnell Systems, Inc. 130 South Main Street Leighton Plaza Suite 375 South Bend, IN 46601 E-mail: mailto:mclaas...@ocie.net Voice: (574)232-3784 Fax: (574)232-4014 --- Confidentiality Notice: OCIESERVICE --- The contents of this e-mail message and any attachments are intended solely for the addressee(s) named in this message. This communication is intended to be and to remain confidential. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and its attachments. Do not deliver, distribute, copy, disclose the contents or take any action in reliance upon the information contained in the communication or any attachments. -Original Message- From: Mark Thomas Sent: Monday, November 26, 2018 12:42 PM To: Tomcat Users List Subject: Re: Overriding MultiPartConfig On 26/11/2018 17:11, Mark A. Claassen wrote: > I am having trouble finding a way to override my MultiPart config. I have a > servlet with a configuration in the web.xml. > > ... > > ... > > > > However, I would like to be able to be able to configure this outside of the > web.xml file so it can be changed outside of the webapp directory. Is there > a way to do this from the "context" in the conf/Catalina/localhost directory? No. > Doing it programmatically would be ok for me as well, but I can't find anyway > to access the multi-part config through the standard APIs. You can only do this if you remove the entry from web.xml. You'd need to register the servlet in a ServletContextListener and then use ServletContext#addServlet() and then ServletRegistration.Dynamic# setMultipartConfig() (along with ading any other configuration / mapping required by the servlet) > I don't think I can use the annotation @MultipartConfig since I am writing > something that extends javax.ws.rs.core.Application and I need to be able to > configure this at startup time. @MultipartConfig has to be added to a Servlet class and can only be changed by recompilation - which is more work than changing web.xml. > I am just using Jersey, running inside of Tomcat. > > Thanks! > > Mark Claassen > Senior Software Engineer > > Donnell Systems, Inc. > 130 South Main Street > Leighton Plaza Suite 375 > South Bend, IN 46601 > E-mail: mailto:mclaas...@ocie.net > Voice: (574)232-3784 > Fax: (574)232-4014 > > Disclaimer: > The opinions provided herein do not necessarily state or reflect those > of Donnell Systems, Inc.(DSI). DSI makes no warranty for and assumes > no legal liability or responsibility for the posting. > > - 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
Overriding MultiPartConfig
I am having trouble finding a way to override my MultiPart config. I have a servlet with a configuration in the web.xml. ... ... However, I would like to be able to be able to configure this outside of the web.xml file so it can be changed outside of the webapp directory. Is there a way to do this from the "context" in the conf/Catalina/localhost directory? Doing it programmatically would be ok for me as well, but I can't find anyway to access the multi-part config through the standard APIs. I don't think I can use the annotation @MultipartConfig since I am writing something that extends javax.ws.rs.core.Application and I need to be able to configure this at startup time. I am just using Jersey, running inside of Tomcat. Thanks! Mark Claassen Senior Software Engineer Donnell Systems, Inc. 130 South Main Street Leighton Plaza Suite 375 South Bend, IN 46601 E-mail: mailto:mclaas...@ocie.net Voice: (574)232-3784 Fax: (574)232-4014 Disclaimer: The opinions provided herein do not necessarily state or reflect those of Donnell Systems, Inc.(DSI). DSI makes no warranty for and assumes no legal liability or responsibility for the posting.
RE: Debugging tomcat native connector
Wow, thanks a lot. That was exactly what it was. Something else, just in the event that someone references this email thread in the future, I also realized I could put this in my logging.properties file: org.apache.coyote.level = FINE I didn't think to add that until after the entropy thing was figured out, but it is something that may come in handy in similar situations. Mark Claassen Senior Software Engineer Donnell Systems, Inc. 130 South Main Street Leighton Plaza Suite 375 South Bend, IN 46601 E-mail: mailto:mclaas...@ocie.net Voice: (574)232-3784 Fax: (574)232-4014 Disclaimer: The opinions provided herein do not necessarily state or reflect those of Donnell Systems, Inc.(DSI). DSI makes no warranty for and assumes no legal liability or responsibility for the posting. -Original Message- From: Christopher Schultz Sent: Thursday, November 1, 2018 1:19 PM To: users@tomcat.apache.org Subject: Re: Debugging tomcat native connector -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 11/1/18 11:51, Mark A. Claassen wrote: > Thanks for the reply. I am using > "org.apache.coyote.http11.Http11AprProtocol" in Tomcat 9. > > The NIO connectors worked fine when we tried them, but the native ones > seem to start up, but then don’t work. > > Interestingly, we found out that these connectors do eventually start > working! We tried to connect a few hours later and they were working > fine. We are now trying to determine exactly how long it takes for > them to accept connections in hopes that this will help us figure out > what is going on. > > Having a way to debug this better would be helpful. Are you getting log entries in catalina.out similar to these? INFO: Starting ProtocolHandler ["ajp-nio-8215"] Oct 10, 2018 4:23:38 PM org.apache.coyote.AbstractProtocol start INFO: Starting ProtocolHandler ["http-nio-127.0.0.1-8217"] Oct 10, 2018 4:23:38 PM org.apache.catalina.startup.Catalina start INFO: Server startup in 6819 ms ?? If so, there should also be some timing information for initializing certain things. For example, if the server doesn't have much entropy in the entropy pool, then you can get a slow-startup while the crypto engine starts. This may be worse with the APR connector than for the NIO connectors as the source of randomness may be different by default (e.g. /dev/urandom for Java, /dev/random for APR). That may not actually be *true*, but it's a possibility. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvbNXYACgkQHPApP6U8 pFhXkBAAny/RjuglPB38vMd1HZ45+9ifW4zRVgGY+2VjtJLSCJKf8+bouMdr6ZWY 5MbE9ru4WYNnIE7J01gYK7vjGfrotjxNLVAsY52qiCAf9u6Q+hsZb00T5B9Fog+z 9lFm2J4alHUMTe758vBJDtuuCqiB3I3SaY2f5rp5TiCWYVExrbNDQUe50ClbqFmB +/e0XIybWXMCPsgylfyqQIZLwJ3t/Q+1eocQUIst86+tMrJdv2PWu+b7+J2y752Y 8dy3LqUjLQ218nDaXe1DXnWajunhuwAunK0/y1fL4pqlwJYDf6GTuWbW+AVDkBZh 3Q1o74QmM230FVyBhll2HSh9wi+rOON7MnjQD8Buks8LeTzyHRdGPRnFXoZm4H99 Re5uDXHLsJ0pweucVc4hqfE+2BxW33GT36FHUjGVAijMO6V3NX4CYhiOD7XkSlaz uvoC+3ibhZZrgmc1AkM122u0YciSLDLb5iqGoVP/cOGJ0JVEwlEPMrpwSSe0ZTXz BB6mTRu9WzN9j4YboTNmuiYnBx6wDAEWu+f9CjFptw7qGcwrzqrFyLp+/QuYzf4l 3iEVDlXPjF0bFsuJOvTChxfVm7s5NrxUBf2hJfMxmuKjeKKPZElgnWYtyoKokCHW GNUD+HIGvJmc5bICo+WRzyf7zu1bsVoATcNvzM+K9WF1TBsrS+I= =7fqB -END PGP SIGNATURE- - 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: Debugging tomcat native connector
Thanks for the reply. I am using "org.apache.coyote.http11.Http11AprProtocol" in Tomcat 9. The NIO connectors worked fine when we tried them, but the native ones seem to start up, but then don’t work. Interestingly, we found out that these connectors do eventually start working! We tried to connect a few hours later and they were working fine. We are now trying to determine exactly how long it takes for them to accept connections in hopes that this will help us figure out what is going on. Having a way to debug this better would be helpful. Mark Claassen Senior Software Engineer Donnell Systems, Inc. 130 South Main Street Leighton Plaza Suite 375 South Bend, IN 46601 E-mail: mailto:mclaas...@ocie.net Voice: (574)232-3784 Fax: (574)232-4014 Disclaimer: The opinions provided herein do not necessarily state or reflect those of Donnell Systems, Inc.(DSI). DSI makes no warranty for and assumes no legal liability or responsibility for the posting. -Original Message- From: Roger Brechbühl Sent: Wednesday, October 31, 2018 5:25 PM To: Tomcat Users List Subject: Re: Debugging tomcat native connector with which connector do you have problems? nio, nio2 or apr? I ask because we have problems with nio2-openssl when ssl session is reused e.g. when a request is proxied with nginx. kind regards, Roger Mark A. Claassen schrieb am Mi. 31. Okt. 2018 um 15:32: > Is there a way to debug the native connectors? Specifically, we are > having some problems getting the native openssl connector working on Ubuntu. > Doing an strace on the process shows a lot of FUTEX_WAIT_PRIVATE, but > we don't know why. We were hoping that there was some way to get more > information. > > Thanks, > > Mark Claassen > Senior Software Engineer > > Donnell Systems, Inc. > 130 South Main Street > Leighton Plaza Suite 375 > South Bend, IN 46601 > E-mail: mailto:mclaas...@ocie.net > Voice: (574)232-3784 > Fax: (574)232-4014 > > Disclaimer: > The opinions provided herein do not necessarily state or reflect those > of Donnell Systems, Inc.(DSI). DSI makes no warranty for and assumes > no legal liability or responsibility for the posting. > >
Debugging tomcat native connector
Is there a way to debug the native connectors? Specifically, we are having some problems getting the native openssl connector working on Ubuntu. Doing an strace on the process shows a lot of FUTEX_WAIT_PRIVATE, but we don't know why. We were hoping that there was some way to get more information. Thanks, Mark Claassen Senior Software Engineer Donnell Systems, Inc. 130 South Main Street Leighton Plaza Suite 375 South Bend, IN 46601 E-mail: mailto:mclaas...@ocie.net Voice: (574)232-3784 Fax: (574)232-4014 Disclaimer: The opinions provided herein do not necessarily state or reflect those of Donnell Systems, Inc.(DSI). DSI makes no warranty for and assumes no legal liability or responsibility for the posting.
Request attributes
I recently discovered some request attributes that I was curious about. Are these accurate across all connectors? Or are these the defaults for using something like the NIO connector? Specifically in my case, I am using the APR connector and openSSL. Example: Attribute 'org.apache.tomcat.util.net.secure_protocol_version' = 'TLSv1.2' Attribute 'javax.servlet.request.key_size' = '256' Attribute 'javax.servlet.request.cipher_suite' = 'ECDHE-RSA-AES256-GCM-SHA384' Thanks, Mark Claassen Senior Software Engineer Donnell Systems, Inc. 130 South Main Street Leighton Plaza Suite 375 South Bend, IN 46601 E-mail: mailto:mclaas...@ocie.net Voice: (574)232-3784 Fax: (574)232-4014 Disclaimer: The opinions provided herein do not necessarily state or reflect those of Donnell Systems, Inc.(DSI). DSI makes no warranty for and assumes no legal liability or responsibility for the posting. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Running Tomcat 9 using OpenJDK 10
Thanks for the reply and the heads up. I am controlling the apps that will be running under it, so that shouldn't be a problem. I am also using the APR connectors, so I don't think the certs will be an issue for me either. Now I just need to compile it. Thanks again! Mark Claassen Senior Software Engineer Donnell Systems, Inc. 130 South Main Street Leighton Plaza Suite 375 South Bend, IN 46601 E-mail: mailto:mclaas...@ocie.net Voice: (574)232-3784 Fax: (574)232-4014 Disclaimer: The opinions provided herein do not necessarily state or reflect those of Donnell Systems, Inc.(DSI). DSI makes no warranty for and assumes no legal liability or responsibility for the posting. -Original Message- From: Cheltenham, Chris [mailto:ccheltenham-...@philasd.org] Sent: Friday, March 2, 2018 11:20 AM To: Tomcat Users List <users@tomcat.apache.org> Subject: RE: Running Tomcat 9 using OpenJDK 10 Yes , I was able to start up tomcat 9.0.4 with the corresponding java. One thing that was annoying was that $JAVA_HOME/jre/lib/security dorectory has changes to $JAVA_HOME/lib/security. Not a big deal but if you are using certs it is. Now, the applications is used did not like java 9 , so I pulled back to java 8_161. But that's been my brief experiences with TCAT 9 and Java 9 === Thank You; Chris Cheltenham Technology Services The School District of Philadelphia Work # 215-400-5025 Cell # 215-301-6571 -Original Message- From: Mark A. Claassen [mailto:mclaas...@ocie.net] Sent: Friday, March 2, 2018 11:03 AM To: Tomcat Users List <users@tomcat.apache.org> Subject: Running Tomcat 9 using OpenJDK 10 Has anyone tried running Tomcat 9 using OpenJDK 9 or 10? I know the OpenJDK releases don't have all the modules (like JavaFX) that the Oracle JDK does and I was wondering if the libraries that Tomcat needs are part of the standard OpenJDK distribution? Thanks, Mark Claassen Senior Software Engineer Donnell Systems, Inc. 130 South Main Street Leighton Plaza Suite 375 South Bend, IN 46601 E-mail: mailto:mclaas...@ocie.net Voice: (574)232-3784 Fax: (574)232-4014 Disclaimer: The opinions provided herein do not necessarily state or reflect those of Donnell Systems, Inc.(DSI). DSI makes no warranty for and assumes no legal liability or responsibility for the posting. - 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
Running Tomcat 9 using OpenJDK 10
Has anyone tried running Tomcat 9 using OpenJDK 9 or 10? I know the OpenJDK releases don't have all the modules (like JavaFX) that the Oracle JDK does and I was wondering if the libraries that Tomcat needs are part of the standard OpenJDK distribution? Thanks, Mark Claassen Senior Software Engineer Donnell Systems, Inc. 130 South Main Street Leighton Plaza Suite 375 South Bend, IN 46601 E-mail: mailto:mclaas...@ocie.net Voice: (574)232-3784 Fax: (574)232-4014 Disclaimer: The opinions provided herein do not necessarily state or reflect those of Donnell Systems, Inc.(DSI). DSI makes no warranty for and assumes no legal liability or responsibility for the posting.
RE: Security of AJP
Chris, I was planning on working on a patch for this as a smooth way to get more involved. :) My work computer is somewhat locked down, so I was planning to get my home computer setup and then give it a go. The patch instructions I found looked fairly clear. If I have any questions, I will post them to the dev list. In the meantime, I wanted to get the right wording so that the statement was acceptable. Thanks for the encouragement! Mark Claassen Senior Software Engineer Donnell Systems, Inc. 130 South Main Street Leighton Plaza Suite 375 South Bend, IN 46601 E-mail: mailto:mclaas...@ocie.net Voice: (574)232-3784 Fax: (574)232-4014 Disclaimer: The opinions provided herein do not necessarily state or reflect those of Donnell Systems, Inc.(DSI). DSI makes no warranty for and assumes no legal liability or responsibility for the posting. -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Thursday, March 1, 2018 11:54 AM To: users@tomcat.apache.org Subject: Re: Security of AJP -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark(s) and Terence, On 3/1/18 11:20 AM, Mark A. Claassen wrote: > Thanks everyone for your feedback. I am the one who unknowingly > opened this can of worms. :) > > It seems like there is a bit of momentum for altering the > documentation, so I thought I would offer something that incorporated > some of these suggestions. I left out the part about "why" one would > use a reverse proxy. Maybe it should be referenced here, but that is > seems like something a higher level topic that might be more > appropriate somewhere else. (If it doesn't fit anywhere else either, > I can add it back.) Would anyone care to prepare an actual documentation patch? I can help guide you through the process if necessary. I know this one is basically just a copy-paste job, but if you know how to make docs patches in general, maybe you'd be more likely to submit more :) - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlqYMCkACgkQHPApP6U8 pFjn7A//TOlILyK+b3wG3BjkBcpOZf3s1sY1INSB+bx1k84FfjSHVQRBHYhlIW4/ LjmQGdKxNF8UNUUq8zfMUV/l70fXM8QSJzQrcma449QsZqHvwbZACQWpR/hzixL/ 9X7Ob/ex9Vd937CUsZOrONK1r9JhZuiaoCcDj1p5XAD6A9YS/PGlJVF5AnLFKiUu UBQUbMdkCestF0cNB9nSYsj5N2C6CuA+TAhb0PzBq/zh2fKVsuBZsW6TgFZwHw4d wf5TxT0Q+/VPMhLTbagqL5eanSIU0k0dTjSvKy9JKpejZFiaMOXUvC61A0uw+Qpj Y/K8tAhl6IM4zFGHv8dbQCrFn3bSg14ULykKdhggclyFsZbr70lNZzY4OuSZnQvL FRnxNIT6iqArDNuDs4BSTbUI7oZVbnq6ngQOgifjAaKpKZcYvsJ7Zkrk/J+xxtGq 1TmMEQqqmqqKtyrSKOkBhDnRS1QbvgiRncgma0iuEDwGV6lCkIQNIMK5vvz0/zPy RdtZKpidDOYrV7C53xVO3NI2et98bm90FIlP93yuzr3Pk09M4QqQVJ7OwwEkkMfQ EiCWny8/j+nnYt7J6CgDtd8By5TmRoKi9eRUeGoC2Kw/2/JriTNShpniEW107sNk RH9oVhAGaksAjjGc6FFttmGDNvCMSj2ppIuCQIA5ppL2j45raFo= =ZH9u -END PGP SIGNATURE- - 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: Security of AJP
Thanks everyone for your feedback. I am the one who unknowingly opened this can of worms. :) It seems like there is a bit of momentum for altering the documentation, so I thought I would offer something that incorporated some of these suggestions. I left out the part about "why" one would use a reverse proxy. Maybe it should be referenced here, but that is seems like something a higher level topic that might be more appropriate somewhere else. (If it doesn't fit anywhere else either, I can add it back.) --- The AJP Connector element represents a Connector component that communicates with a HTTP server via the AJP protocol. This is an unencrypted protocol and is therefore recommended for use on a protected network or encrypted by some other means, like SSH tunneling. The most common configuration for this is when an HTTP server acts as a reverse proxy in front of one or more Tomcat servers. Besides being a more efficient protocol that HTTP, there are several configuration options in this connector designed to allow Tomcat to operate as it would if it were not running behind a reverse proxy. --- Mark Claassen Senior Software Engineer Donnell Systems, Inc. 130 South Main Street Leighton Plaza Suite 375 South Bend, IN 46601 E-mail: mailto:mclaas...@ocie.net Voice: (574)232-3784 Fax: (574)232-4014 Disclaimer: The opinions provided herein do not necessarily state or reflect those of Donnell Systems, Inc.(DSI). DSI makes no warranty for and assumes no legal liability or responsibility for the posting. -Original Message- From: Terence M. Bandoian [mailto:tere...@tmbsw.com] Sent: Thursday, March 1, 2018 8:34 AM To: Tomcat Users List <users@tomcat.apache.org> Subject: Re: Security of AJP On 2/28/2018 10:16 AM, Mark H. Wood wrote: > On Wed, Feb 28, 2018 at 09:25:53AM -0500, Christopher Schultz wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA256 >> >> Chris, >> >> On 2/28/18 8:40 AM, Cheltenham, Chris wrote: >>> Since AJP is not really needed by Tomcat; If I comment out the AJP >>> startup line in server.xml will that affect anything. >>> >>> I still don't even understand what its for. I have read the apache >>> docs but it doesn't mean anything to me.. Apache's description >>> doesn't tell me anything. >>> >>> >>> The AJP Connector element represents a Connector component that >>> communicates with a web connector via the AJP protocol. This is used >>> for cases where you wish to invisibly integrate Tomcat into an >>> existing (or new) Apache installation, and you want Apache to handle >>> the static content contained in the web application, and/or utilize >>> Apache's SSL processing. >>> >>> That is mumbo jumbo. >> Is it? > Well, it could be improved. For example, by using the > widely-understood word "proxy" somewhere, or defining "web connector". > Also by recalling that "Apache" is a huge array of various projects > (including Tomcat!), while "Apache HTTP Server" refers to a specific > web server daemon that can front-end Tomcat. One could even link > "Apache HTTP Server" to 'http://httpd.apache.org/'. > +1. Maybe "...communicates with an HTTP server via..." in the first sentence? Also, the second sentence could be greatly simplified. -Terence Bandoian - 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
Security of AJP
>From what I have read, it seems that the AJP connector is not secure, and is >meant to be used in a protective environment. There are lots of things that >imply this, like no SSL settings and such, but I cannot find it directly >stated anywhere. I am pretty confident in my read of this, but it is, of >course, difficult to say that "all options have been explored and it is not >possible". First of all, am I correct in my assertion that it cannot be made secure? And, if so, I would invite you (or us, the community!) to consider modifying the documentation to state this. Maybe something like: https://tomcat.apache.org/tomcat-9.0-doc/config/ajp.html The AJP Connector element represents a Connector component that communicates with a web connector via the AJP protocol. [This is an unencrypted connector, intended for use in protected enviroments.] This is used for cases where you wish to invisibly integrate Tomcat into an existing (or new) Apache installation, and you want Apache to handle the static content contained in the web application, and/or utilize Apache's SSL processing. Mark Claassen Senior Software Engineer Donnell Systems, Inc. 130 South Main Street Leighton Plaza Suite 375 South Bend, IN 46601 E-mail: mailto:mclaas...@ocie.net Voice: (574)232-3784 Fax: (574)232-4014 Disclaimer: The opinions provided herein do not necessarily state or reflect those of Donnell Systems, Inc.(DSI). DSI makes no warranty for and assumes no legal liability or responsibility for the posting.
RE: Possible incompatibility from Tomcat 8 to Tomcat 9 on HTTP 302
> Best guess you were using an older version of Tomcat 7 where the feature did > not exist. It was added for 7.0.67 onwards. Yes, I was. > No problem. Happy to help. Thanks to you writing a good question :) Mark Claassen Senior Software Engineer Donnell Systems, Inc. 130 South Main Street Leighton Plaza Suite 375 South Bend, IN 46601 E-mail: mailto:mclaas...@ocie.net Voice: (574)232-3784 Fax: (574)232-4014 --- Confidentiality Notice: OCIESERVICE --- The contents of this e-mail message and any attachments are intended solely for the addressee(s) named in this message. This communication is intended to be and to remain confidential. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and its attachments. Do not deliver, distribute, copy, disclose the contents or take any action in reliance upon the information contained in the communication or any attachments. -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Monday, February 26, 2018 4:41 PM To: Tomcat Users List <users@tomcat.apache.org> Subject: Re: Possible incompatibility from Tomcat 8 to Tomcat 9 on HTTP 302 On 26/02/18 20:19, Mark A. Claassen wrote: > Thanks! That was the configuration setting I needed, but didn't know to look > for. Adding that attribute and setting it to "false" did the trick. > > Upon looking, I see that the Tomcat I was testing against was Tomcat 7 and > not 8. (Sorry about that.) I did some searching and don't see that attribute > being set to false anywhere or the > "org.apache.catalina.STRICT_SERVLET_COMPLIANCE" property being set. > > I see the docs all say that useRelativeRedirects defaults to true, so I can't > explain why things worked in my old installation. Best guess you were using an older version of Tomcat 7 where the feature did not exist. It was added for 7.0.67 onwards. > Regardless of this, I am very thankful to know about this attribute. Thanks > again for your time. No problem. Happy to help. Thanks to you writing a good question, it was easy to answer quickly. Mark > > Mark Claassen > Senior Software Engineer > > Donnell Systems, Inc. > 130 South Main Street > Leighton Plaza Suite 375 > South Bend, IN 46601 > E-mail: mailto:mclaas...@ocie.net > Voice: (574)232-3784 > Fax: (574)232-4014 > > --- > Confidentiality Notice: OCIESERVICE > --- > The contents of this e-mail message and any attachments are intended solely > for the addressee(s) named in this message. This communication is intended to > be and to remain confidential. If you are not the intended recipient of this > message, or if this message has been addressed to you in error, please > immediately alert the sender by reply e-mail and then delete this message and > its attachments. Do not deliver, distribute, copy, disclose the contents or > take any action in reliance upon the information contained in the > communication or any attachments. > > > -Original Message- > From: Mark Thomas [mailto:ma...@apache.org] > Sent: Monday, February 26, 2018 2:06 PM > To: Tomcat Users List <users@tomcat.apache.org> > Subject: Re: Possible incompatibility from Tomcat 8 to Tomcat 9 on > HTTP 302 > > On 26/02/18 17:38, Mark A. Claassen wrote: >> Hi. I am working on migrating from Tomcat 8 (not 8.5) to Tomcat 9. >> Everything worked great, except that when we run Tomcat 9 behind a reverse >> proxy, our redirects don't work anymore. I am able to run the same webapp >> under both and am doing so. The one running under Tomcat 8 works, the one >> running under Tomcat 9 does not. >> >> I put my webapp on a non-https port and used wireshark. The 302 responses >> are different. Notice the "Location" is absolute in 8 and relative in 9. >> >> Tomcat 8: HTTP/1.1 302 Moved Temporarily\r\n >> Tomcat 8: Location: >> http://x86test.dev.donnell.com:8502/OcieWS/index.jsp\r\n >> >> Tomcat 9: HTTP/1.1 302 \r\n >> Tomcat 9: Location: /OcieWS/index.jsp\r\n >> >> The Apache reverse proxy must be able to substitute the proxied full path >> using the location is Tomcat 8, but is unable to in Tomcat 9. >> Anyone know what is going on here? Is this a bug, or a specification >> change, or a bug fix, ...? > > Looks like you have useRelativeRedirects="false" on 8.0.x but "true" on > 9.0.x. That is a Context configuration setting. > > Mark > >
RE: Possible incompatibility from Tomcat 8 to Tomcat 9 on HTTP 302
Thanks! That was the configuration setting I needed, but didn't know to look for. Adding that attribute and setting it to "false" did the trick. Upon looking, I see that the Tomcat I was testing against was Tomcat 7 and not 8. (Sorry about that.) I did some searching and don't see that attribute being set to false anywhere or the "org.apache.catalina.STRICT_SERVLET_COMPLIANCE" property being set. I see the docs all say that useRelativeRedirects defaults to true, so I can't explain why things worked in my old installation. Regardless of this, I am very thankful to know about this attribute. Thanks again for your time. Mark Claassen Senior Software Engineer Donnell Systems, Inc. 130 South Main Street Leighton Plaza Suite 375 South Bend, IN 46601 E-mail: mailto:mclaas...@ocie.net Voice: (574)232-3784 Fax: (574)232-4014 --- Confidentiality Notice: OCIESERVICE --- The contents of this e-mail message and any attachments are intended solely for the addressee(s) named in this message. This communication is intended to be and to remain confidential. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and its attachments. Do not deliver, distribute, copy, disclose the contents or take any action in reliance upon the information contained in the communication or any attachments. -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Monday, February 26, 2018 2:06 PM To: Tomcat Users List <users@tomcat.apache.org> Subject: Re: Possible incompatibility from Tomcat 8 to Tomcat 9 on HTTP 302 On 26/02/18 17:38, Mark A. Claassen wrote: > Hi. I am working on migrating from Tomcat 8 (not 8.5) to Tomcat 9. > Everything worked great, except that when we run Tomcat 9 behind a reverse > proxy, our redirects don't work anymore. I am able to run the same webapp > under both and am doing so. The one running under Tomcat 8 works, the one > running under Tomcat 9 does not. > > I put my webapp on a non-https port and used wireshark. The 302 responses > are different. Notice the "Location" is absolute in 8 and relative in 9. > > Tomcat 8: HTTP/1.1 302 Moved Temporarily\r\n > Tomcat 8: Location: http://x86test.dev.donnell.com:8502/OcieWS/index.jsp\r\n > > Tomcat 9: HTTP/1.1 302 \r\n > Tomcat 9: Location: /OcieWS/index.jsp\r\n > > The Apache reverse proxy must be able to substitute the proxied full path > using the location is Tomcat 8, but is unable to in Tomcat 9. > Anyone know what is going on here? Is this a bug, or a specification change, > or a bug fix, ...? Looks like you have useRelativeRedirects="false" on 8.0.x but "true" on 9.0.x. That is a Context configuration setting. Mark > > Thanks, > > Mark Claassen > Senior Software Engineer > > Donnell Systems, Inc. > 130 South Main Street > Leighton Plaza Suite 375 > South Bend, IN 46601 > E-mail: mailto:mclaas...@ocie.net > Voice: (574)232-3784 > Fax: (574)232-4014 > > Disclaimer: > The opinions provided herein do not necessarily state or reflect those > of Donnell Systems, Inc.(DSI). DSI makes no warranty for and assumes > no legal liability or responsibility for the posting. > > > - > 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
Possible incompatibility from Tomcat 8 to Tomcat 9 on HTTP 302
Hi. I am working on migrating from Tomcat 8 (not 8.5) to Tomcat 9. Everything worked great, except that when we run Tomcat 9 behind a reverse proxy, our redirects don't work anymore. I am able to run the same webapp under both and am doing so. The one running under Tomcat 8 works, the one running under Tomcat 9 does not. I put my webapp on a non-https port and used wireshark. The 302 responses are different. Notice the "Location" is absolute in 8 and relative in 9. Tomcat 8: HTTP/1.1 302 Moved Temporarily\r\n Tomcat 8: Location: http://x86test.dev.donnell.com:8502/OcieWS/index.jsp\r\n Tomcat 9: HTTP/1.1 302 \r\n Tomcat 9: Location: /OcieWS/index.jsp\r\n The Apache reverse proxy must be able to substitute the proxied full path using the location is Tomcat 8, but is unable to in Tomcat 9. Anyone know what is going on here? Is this a bug, or a specification change, or a bug fix, ...? Thanks, Mark Claassen Senior Software Engineer Donnell Systems, Inc. 130 South Main Street Leighton Plaza Suite 375 South Bend, IN 46601 E-mail: mailto:mclaas...@ocie.net Voice: (574)232-3784 Fax: (574)232-4014 Disclaimer: The opinions provided herein do not necessarily state or reflect those of Donnell Systems, Inc.(DSI). DSI makes no warranty for and assumes no legal liability or responsibility for the posting. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
