Re: Tomcat losing request parameters
2015-06-04 18:40 GMT+03:00 Ravi Kiran ravikiran...@gmail.com: Hi, I am writing to get some pointers on a strange issue which are facing in tomcat in one of our client environments. Setup: 4 Webservers connecting to 2 tomcat using mod_jk (load balanced) Issue: Request parameters GET/POST are coming as null to the application intermittently i.e, filter in web app dumps the request parameters and finds everything empty. TCP dumps are inspected and packets are reaching tomcat even during the failure cases. Parameters are available in tcpdump but lost in between before it reaches application. This happens only on one specific client environment which makes it even difficult to isolate the problem. Tomcat Version: 7.0.54 Please suggest some pointers to debug and resolve this issue. I can provide more info if needed. The Servlet API has no way to report errors (such as IOException) from request.getParameter() family of methods. There is a Tomcat-specific request attribute that is set to a non-null value when parsing of parameters fails. See org.apache.catalina.filters.FailedRequestFilter [1] as a sample of code. [1] http://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#Failed_Request_Filter - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat losing request parameters
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Konstantin, On 6/9/15 5:04 AM, Konstantin Kolinko wrote: 2015-06-04 18:40 GMT+03:00 Ravi Kiran ravikiran...@gmail.com: Hi, I am writing to get some pointers on a strange issue which are facing in tomcat in one of our client environments. Setup: 4 Webservers connecting to 2 tomcat using mod_jk (load balanced) Issue: Request parameters GET/POST are coming as null to the application intermittently i.e, filter in web app dumps the request parameters and finds everything empty. TCP dumps are inspected and packets are reaching tomcat even during the failure cases. Parameters are available in tcpdump but lost in between before it reaches application. This happens only on one specific client environment which makes it even difficult to isolate the problem. Tomcat Version: 7.0.54 Please suggest some pointers to debug and resolve this issue. I can provide more info if needed. The Servlet API has no way to report errors (such as IOException) from request.getParameter() family of methods. There is a Tomcat-specific request attribute that is set to a non-null value when parsing of parameters fails. See org.apache.catalina.filters.FailedRequestFilter [1] as a sample of code. [1] http://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#Failed_Requ est_Filter +1 I re-read the OP and I was under the impression that the Filter was reading the request parameters properly, but that the servlet was then re-reading the parameters and getting nulls. Having re-read that, I suspect Konstantin's analysis is correct, and that the parameter values were probably broken in some way. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVdxD4AAoJEBzwKT+lPKRYc6sP/RDSV9IeARJXJIo4f6VeRwJv S/RcHDq8tmUmT1Z/gvX6nzTeEiHclIXoXMY3AJ0wg0LJHHQHMw+Z5waX1j76/hoQ TDmO/qNewqyWnI3oCsg6h7yrjtugs9hsqK77LJCUY0954qrSP/+McKUNQTLW3sGP Ik7ImDNaFHGZZvwgaq1DAzL9Sa+QM2XiTZqnM5yxykW2tmy1kOv4/47Pb97NUJyz 2C2WjZqgQBIRVOh7L5Wg8tp9SLtZ548oUSJopadoLaqsdvlva8H9v7Lz/ESOS8V8 3voPz9owNDn+5E641piv9ykHh86emltFE1uVRaV3ryX1LW11mGi0Qhqhn9DC2U2b WeR5VZ0iiSiS/BdnNN+8hnT1o32GquLkJPx4aGco3kjeLV2ADBpTNaAupwYfRl9Y NVbM9CZlLR97CPic4qmV1yECgv1UDaSp4sRE5G6SFc1UnxPDUIi2EVAPYthKF66Z mtVHBOgwWARGohqlbtjuIugPAOu3RYnV4qg7ZqWfxPrnvXTWjGOETOzeidEdn9hb EcXYcTRTShk609vWXA5BvPK/H8eJ3Mg84a0wRex8NdlsuZZaQFd/WfVXvklk5ndl ge0siyVLSynHXdjDCnPm5sKyHREyCOUjgYtOQky0b7sHS36i2CPdKH0srQ9DngkY +crYqQ+kzEH61VTadc1r =JPLZ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat losing request parameters
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ravi, On 6/9/15 1:48 PM, Ravi Kiran wrote: Few things we tried: - Changed mod_jk to mod_proxy where requests are passed to tomcat as http:8080 instead of AJP but we still get the same issue intermittently. - Enabled failed request filter and it doesn't report anything nor stop the requests stating bad requests unfortunately, running out of options Have you checked to make sure that the request parameters aren't illegally-formatted as Konstantin suggested might be the case? It might help if you provided an example packet capture of a request whose parameters have been ignored. Also, are you testing against Tomcat 7.0.latest, or still 7.0.54? - -chris On Tue, Jun 9, 2015 at 9:14 AM, Christopher Schultz ch...@christopherschultz.net wrote: Konstantin, On 6/9/15 5:04 AM, Konstantin Kolinko wrote: 2015-06-04 18:40 GMT+03:00 Ravi Kiran ravikiran...@gmail.com: Hi, I am writing to get some pointers on a strange issue which are facing in tomcat in one of our client environments. Setup: 4 Webservers connecting to 2 tomcat using mod_jk (load balanced) Issue: Request parameters GET/POST are coming as null to the application intermittently i.e, filter in web app dumps the request parameters and finds everything empty. TCP dumps are inspected and packets are reaching tomcat even during the failure cases. Parameters are available in tcpdump but lost in between before it reaches application. This happens only on one specific client environment which makes it even difficult to isolate the problem. Tomcat Version: 7.0.54 Please suggest some pointers to debug and resolve this issue. I can provide more info if needed. The Servlet API has no way to report errors (such as IOException) from request.getParameter() family of methods. There is a Tomcat-specific request attribute that is set to a non-null value when parsing of parameters fails. See org.apache.catalina.filters.FailedRequestFilter [1] as a sample of code. [1] http://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#Failed_R equ est_Filter +1 I re-read the OP and I was under the impression that the Filter was reading the request parameters properly, but that the servlet was then re-reading the parameters and getting nulls. Having re-read that, I suspect Konstantin's analysis is correct, and that the parameter values were probably broken in some way. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVdyqEAAoJEBzwKT+lPKRYsYgP/0wtTEUpiod6rCofO5xAxomT gye06hD+0DUNB4L9LwIxni+KSiW/0T85eMkKmD01SSY3wHYVlY792jkptFgB65DA +UNATRZoiRgclWB1kIXW6IpeAfltFSfDyizj2UrEHX885xuBm4NZ4L4laBuY4aYN QXmnMmLZQwXw352+GaLB/o8Wwy5l2ehsN80udIHIazbtGiL+KkRYLVAbrrrD0pbW bt77BShW2spyVog6hGRDC0zDEwD18A7PIMu1ANk1MZC3QJbTUFrHPvVyp/1zz8JK sgte5pstRawDOVoh135oIVLDs77wCcC+i6LOBils0g65sPEOHTFTkC8E7eALabX4 seIG+UDdLS84S/ZewMUZP2TSBBthMmrxMBsEt5rtlcsy00/VO+0IBct8m0cO20vq hLEHxm/hFw72ogzs0a65P0HsRt8ay/tBnzE3ERQ3n1iljyWSqWbyFzH27voyWLbm BhifTML7hVZjDsLK9QScsHCrMYnTJuL/6p1bxeVf5CsdnixC8/u6zpxMlkvjhmW6 NKX+3Jopmjvq7lOSnR6JqZWVHqh3pi1XvLoIHroLOpYT9dQDUtKOqjv0Og6Qt3zv B08u6y5Q2xlFMtev2vscTKTnObdk6b3e21DHl3x66NP/1iDk6Zl8joE1HuSztNm+ 37H0DeidwcwHkf2QdzdZ =Kxwn -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat losing request parameters
Few things we tried: - Changed mod_jk to mod_proxy where requests are passed to tomcat as http:8080 instead of AJP but we still get the same issue intermittently. - Enabled failed request filter and it doesn't report anything nor stop the requests stating bad requests unfortunately, running out of options On Tue, Jun 9, 2015 at 9:14 AM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Konstantin, On 6/9/15 5:04 AM, Konstantin Kolinko wrote: 2015-06-04 18:40 GMT+03:00 Ravi Kiran ravikiran...@gmail.com: Hi, I am writing to get some pointers on a strange issue which are facing in tomcat in one of our client environments. Setup: 4 Webservers connecting to 2 tomcat using mod_jk (load balanced) Issue: Request parameters GET/POST are coming as null to the application intermittently i.e, filter in web app dumps the request parameters and finds everything empty. TCP dumps are inspected and packets are reaching tomcat even during the failure cases. Parameters are available in tcpdump but lost in between before it reaches application. This happens only on one specific client environment which makes it even difficult to isolate the problem. Tomcat Version: 7.0.54 Please suggest some pointers to debug and resolve this issue. I can provide more info if needed. The Servlet API has no way to report errors (such as IOException) from request.getParameter() family of methods. There is a Tomcat-specific request attribute that is set to a non-null value when parsing of parameters fails. See org.apache.catalina.filters.FailedRequestFilter [1] as a sample of code. [1] http://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#Failed_Requ est_Filter +1 I re-read the OP and I was under the impression that the Filter was reading the request parameters properly, but that the servlet was then re-reading the parameters and getting nulls. Having re-read that, I suspect Konstantin's analysis is correct, and that the parameter values were probably broken in some way. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVdxD4AAoJEBzwKT+lPKRYc6sP/RDSV9IeARJXJIo4f6VeRwJv S/RcHDq8tmUmT1Z/gvX6nzTeEiHclIXoXMY3AJ0wg0LJHHQHMw+Z5waX1j76/hoQ TDmO/qNewqyWnI3oCsg6h7yrjtugs9hsqK77LJCUY0954qrSP/+McKUNQTLW3sGP Ik7ImDNaFHGZZvwgaq1DAzL9Sa+QM2XiTZqnM5yxykW2tmy1kOv4/47Pb97NUJyz 2C2WjZqgQBIRVOh7L5Wg8tp9SLtZ548oUSJopadoLaqsdvlva8H9v7Lz/ESOS8V8 3voPz9owNDn+5E641piv9ykHh86emltFE1uVRaV3ryX1LW11mGi0Qhqhn9DC2U2b WeR5VZ0iiSiS/BdnNN+8hnT1o32GquLkJPx4aGco3kjeLV2ADBpTNaAupwYfRl9Y NVbM9CZlLR97CPic4qmV1yECgv1UDaSp4sRE5G6SFc1UnxPDUIi2EVAPYthKF66Z mtVHBOgwWARGohqlbtjuIugPAOu3RYnV4qg7ZqWfxPrnvXTWjGOETOzeidEdn9hb EcXYcTRTShk609vWXA5BvPK/H8eJ3Mg84a0wRex8NdlsuZZaQFd/WfVXvklk5ndl ge0siyVLSynHXdjDCnPm5sKyHREyCOUjgYtOQky0b7sHS36i2CPdKH0srQ9DngkY +crYqQ+kzEH61VTadc1r =JPLZ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Choosing a Connector Protocol
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 6/9/15 9:47 AM, Mark Thomas wrote: On 09/06/2015 14:38, Kevin Hale Boyes wrote: I'm having trouble figuring out what protocol to use for a Connector. I'm using Tomcat 8 and Java 8. The production system that Tomcat will be running on is Solaris 11 and I'm not yet sure if I'll be able to build the tomcat native library. So, I'm choosing between the Http11NioProtocol and Http11Nio2Protocol but I can't figure out what the difference is. I'll have two connectors defined - one SSL and the other non-SSL. The non-SSL connector services user traffic in my web application with the SSL session being terminated at the coyote load balancer. The SSL connector services B2B traffic and it's set up for client authentication. I've seen the Connector Comparison chart but that doesn't really help. The only difference seems to be that Nio uses simulated blocking. A bit of searching seems to compare it against the blocking connector only. So, I'm asking for help in understanding what the difference is between the two connector protocols and how to choose the best one for my application. There is very little to choose between them. Implementing an NIO2 connector was the only way to find out if there were any noticeable performance benefits or not (there weren't). Very long term (maybe Tomcat 10 onwards) one of NIO and NIO2 may get dropped but I think we are several years away from even thinking about that. Right now, I'd say go with NIO. It has been around longer and should - in theory at least - be a little more stable. +1 If you are going to use a LOT of TLS, I would recommend looking into the native library. OpenSSL absolutely annihilates all of the JSSE-based connectors for crypto performance. If you will have light traffic, it doesn't matter which one you choose. If you will have heavy traffic, it's worth it to get the native connector working. The native connector is known to build and work properly on Solaris. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVdysoAAoJEBzwKT+lPKRYBvIP/0/xjkgbPn9RIrxg1uofBpYX lNzRWTQZ08SrZ97J/3lL+nMqNAwx2/gv0y4raJ/+Pb+LrLakU4UUvpB56/Kgczl2 Dn/QH5JYRq9iqYSvxzEx6WLubHx6GMGbYjBabCToDmlCDRyN+RahFRiKp2kym4VI 4JpsXQTkOi0hukk8sc3PntrPbNddK/pTmRmY+oFyReoGktT+cLOXlA6MrEbN8fyc NibZAlJmNwu4INJzXwjM1BVv34uYJgjSUFhXvA1kIAyrT09N3djbx4TbFClk5D5I STbAjMtUjHWAk0xa+dXwtgzJ9gl0jyVZhmNU6ta6B28fjv1i96mnNK2opnQxD3wJ Fbtp1tDV+s2+gM97rdAdYHoXRApil5zpqQnvFR2B6NXhGq18SEPzP4Y7LklaopON MMncadzIBSqfQIbPxaOjv5/ShQsw/8U4Vdt7ueWVGiabpMO8mPNBFP8DtZ1gMDHs PLlDi5f28kXP/47caswTfhlc0u+xVw8pjPHCHj/1e2OQmdMAkuMmZVuh7WpfwjXC b34YbxYsVmMWYFPEHrWSJpaX4qovqV4VbTNOXI6EDlrgaM/cljcxoJ+hD7yMn72h xe2yCYjJxh8mjtl5uFla8CbAXu7Zj+sYE+8xhaLzItnXAPwtSpwbwoM/R0x2iZUg m0GYEkifY8WeRxCP415W =+L/c -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Fwd: Embedded Tomcat could not find keystone file
Hello there My tomcat dependency is dependency groupIdorg.apache.tomcat.embed/groupId artifactIdtomcat-embed-core/artifactId version7.0.57/version /dependency In my code, I set the connector properties as LOGGER.debug(ksPath= + ksPath); httpsConnector.setAttribute(keystoreFile,ksPath); httpsConnector.setAttribute(keystorePass, keyStorePass); httpsConnector.setAttribute(clientAuth, false); httpsConnector.setAttribute(sslProtocol, TLS); httpsConnector.setAttribute(sslEnabledProtocols, tlsProtocols); httpsConnector.setAttribute(SSLEnabled, true); Connector defaultConnector = tomcat.getConnector(); defaultConnector.setRedirectPort(port); When I server deployed, I see ksPath=jar:file:/shn/lp/main-1.0-SNAPSHOT-jar-with-dependencies.jar!/my.keystore and then failure as SEVERE: Failed to load keystore type JKS with path /shn/lp/jar:file:/shn/lp/main-1.0-SNAPSHOT-jar-with-dependencies.jar!/my.keystore due to /shn/lp/jar:file:/shn/lp/main-1.0-SNAPSHOT-jar-with-dependencies.jar!/my.keystore (No such file or directory) java.io.FileNotFoundException: /shn/lp/jar:file:/shn/lp/main-1.0-SNAPSHOT-jar-with-dependencies.jar!/my.keystore (No such file or directory) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(FileInputStream.java:146) at org.apache.tomcat.util.net.jsse.JSSESocketFactory.getStore(JSSESocketFactory.java:413) at org.apache.tomcat.util.net.jsse.JSSESocketFactory.getKeystore(JSSESocketFactory.java:319) at org.apache.tomcat.util.net.jsse.JSSESocketFactory.getKeyManagers(JSSESocketFactory.java:577) at org.apache.tomcat.util.net.jsse.JSSESocketFactory.getKeyManagers(JSSESocketFactory.java:517) at org.apache.tomcat.util.net.jsse.JSSESocketFactory.init(JSSESocketFactory.java:462) at org.apache.tomcat.util.net.jsse.JSSESocketFactory.createSocket(JSSESocketFactory.java:209) Now, Observed that there are differences in ksPath and path tomcat looks for ksPath=jar:file:/shn/lp/main-1.0-SNAPSHOT-jar-with-dependencies.jar!/my.keystore and java.io.FileNotFoundException: /shn/lp/jar:file:/shn/lp/main-1.0-SNAPSHOT-jar-with-dependencies.jar!/my.keystore (No such file or directory) the tomcat path looks inside /shn/lp (which is current directory) I also see that the keystone file is in fact present jar -tvf /shn/lp/main-1.0-SNAPSHOT-jar-with-dependencies.jar | grep my.keystore 4704 Tue Jun 09 09:29:26 PDT 2015 my.keystore What is the issue and how do I resolve it? Thank you very much in advance + Harit Himanshu
Re: Fwd: Embedded Tomcat could not find keystone file
This is interesting, one of our project I work with has this keystore inside jar file, just curious how that works On Tue, Jun 9, 2015 at 12:44 PM, Mark Thomas ma...@apache.org wrote: On 09/06/2015 20:18, Harit Himanshu wrote: Hello there My tomcat dependency is dependency groupIdorg.apache.tomcat.embed/groupId artifactIdtomcat-embed-core/artifactId version7.0.57/version /dependency In my code, I set the connector properties as LOGGER.debug(ksPath= + ksPath); httpsConnector.setAttribute(keystoreFile,ksPath); httpsConnector.setAttribute(keystorePass, keyStorePass); httpsConnector.setAttribute(clientAuth, false); httpsConnector.setAttribute(sslProtocol, TLS); httpsConnector.setAttribute(sslEnabledProtocols, tlsProtocols); httpsConnector.setAttribute(SSLEnabled, true); Connector defaultConnector = tomcat.getConnector(); defaultConnector.setRedirectPort(port); When I server deployed, I see ksPath=jar:file:/shn/lp/main-1.0-SNAPSHOT-jar-with-dependencies.jar!/my.keystore and then failure as SEVERE: Failed to load keystore type JKS with path /shn/lp/jar:file:/shn/lp/main-1.0-SNAPSHOT-jar-with-dependencies.jar!/my.keystore due to /shn/lp/jar:file:/shn/lp/main-1.0-SNAPSHOT-jar-with-dependencies.jar!/my.keystore (No such file or directory) java.io.FileNotFoundException: /shn/lp/jar:file:/shn/lp/main-1.0-SNAPSHOT-jar-with-dependencies.jar!/my.keystore (No such file or directory) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(FileInputStream.java:146) at org.apache.tomcat.util.net.jsse.JSSESocketFactory.getStore(JSSESocketFactory.java:413) at org.apache.tomcat.util.net.jsse.JSSESocketFactory.getKeystore(JSSESocketFactory.java:319) at org.apache.tomcat.util.net.jsse.JSSESocketFactory.getKeyManagers(JSSESocketFactory.java:577) at org.apache.tomcat.util.net.jsse.JSSESocketFactory.getKeyManagers(JSSESocketFactory.java:517) at org.apache.tomcat.util.net.jsse.JSSESocketFactory.init(JSSESocketFactory.java:462) at org.apache.tomcat.util.net.jsse.JSSESocketFactory.createSocket(JSSESocketFactory.java:209) Now, Observed that there are differences in ksPath and path tomcat looks for ksPath=jar:file:/shn/lp/main-1.0-SNAPSHOT-jar-with-dependencies.jar!/my.keystore and java.io.FileNotFoundException: /shn/lp/jar:file:/shn/lp/main-1.0-SNAPSHOT-jar-with-dependencies.jar!/my.keystore (No such file or directory) the tomcat path looks inside /shn/lp (which is current directory) I also see that the keystone file is in fact present jar -tvf /shn/lp/main-1.0-SNAPSHOT-jar-with-dependencies.jar | grep my.keystore 4704 Tue Jun 09 09:29:26 PDT 2015 my.keystore What is the issue and how do I resolve it? keystore files have to be on the file system. Embedding them in a JAR is not currently supported. https://bz.apache.org/bugzilla/show_bug.cgi?id=56777 Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Fwd: Embedded Tomcat could not find keystone file
On 09/06/2015 20:18, Harit Himanshu wrote: Hello there My tomcat dependency is dependency groupIdorg.apache.tomcat.embed/groupId artifactIdtomcat-embed-core/artifactId version7.0.57/version /dependency In my code, I set the connector properties as LOGGER.debug(ksPath= + ksPath); httpsConnector.setAttribute(keystoreFile,ksPath); httpsConnector.setAttribute(keystorePass, keyStorePass); httpsConnector.setAttribute(clientAuth, false); httpsConnector.setAttribute(sslProtocol, TLS); httpsConnector.setAttribute(sslEnabledProtocols, tlsProtocols); httpsConnector.setAttribute(SSLEnabled, true); Connector defaultConnector = tomcat.getConnector(); defaultConnector.setRedirectPort(port); When I server deployed, I see ksPath=jar:file:/shn/lp/main-1.0-SNAPSHOT-jar-with-dependencies.jar!/my.keystore and then failure as SEVERE: Failed to load keystore type JKS with path /shn/lp/jar:file:/shn/lp/main-1.0-SNAPSHOT-jar-with-dependencies.jar!/my.keystore due to /shn/lp/jar:file:/shn/lp/main-1.0-SNAPSHOT-jar-with-dependencies.jar!/my.keystore (No such file or directory) java.io.FileNotFoundException: /shn/lp/jar:file:/shn/lp/main-1.0-SNAPSHOT-jar-with-dependencies.jar!/my.keystore (No such file or directory) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(FileInputStream.java:146) at org.apache.tomcat.util.net.jsse.JSSESocketFactory.getStore(JSSESocketFactory.java:413) at org.apache.tomcat.util.net.jsse.JSSESocketFactory.getKeystore(JSSESocketFactory.java:319) at org.apache.tomcat.util.net.jsse.JSSESocketFactory.getKeyManagers(JSSESocketFactory.java:577) at org.apache.tomcat.util.net.jsse.JSSESocketFactory.getKeyManagers(JSSESocketFactory.java:517) at org.apache.tomcat.util.net.jsse.JSSESocketFactory.init(JSSESocketFactory.java:462) at org.apache.tomcat.util.net.jsse.JSSESocketFactory.createSocket(JSSESocketFactory.java:209) Now, Observed that there are differences in ksPath and path tomcat looks for ksPath=jar:file:/shn/lp/main-1.0-SNAPSHOT-jar-with-dependencies.jar!/my.keystore and java.io.FileNotFoundException: /shn/lp/jar:file:/shn/lp/main-1.0-SNAPSHOT-jar-with-dependencies.jar!/my.keystore (No such file or directory) the tomcat path looks inside /shn/lp (which is current directory) I also see that the keystone file is in fact present jar -tvf /shn/lp/main-1.0-SNAPSHOT-jar-with-dependencies.jar | grep my.keystore 4704 Tue Jun 09 09:29:26 PDT 2015 my.keystore What is the issue and how do I resolve it? keystore files have to be on the file system. Embedding them in a JAR is not currently supported. https://bz.apache.org/bugzilla/show_bug.cgi?id=56777 Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Fwd: Embedded Tomcat could not find keystone file
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Harit, On 6/9/15 5:08 PM, Harit Himanshu wrote: This is interesting, one of our project I work with has this keystore inside jar file, just curious how that works Conceptually, it's quite simple: just use the ClassLoader to grab the file from the CL's class path. In reality, the Connector was written to load directly off the filesystem instead of using URLs or whatever. It should be a somewhat easy fix -- at least for keystore/truststore - -- but the BZ enhancement has quite a wide scope, saying that configuration resources should be loadable via resources instead of directly off the filesystem. That's a much wider net to cast, and likely why it hasn't been addressed, yet. If all you need is the keystore (and maybe truststore), then a patch would be fairly trivial to write. I'm not sure if the full resources are available to the Connector during configuration, but the container ClassLoader certainly is available... - -chris On Tue, Jun 9, 2015 at 12:44 PM, Mark Thomas ma...@apache.org wrote: On 09/06/2015 20:18, Harit Himanshu wrote: Hello there My tomcat dependency is dependency groupIdorg.apache.tomcat.embed/groupId artifactIdtomcat-embed-core/artifactId version7.0.57/version /dependency In my code, I set the connector properties as LOGGER.debug(ksPath= + ksPath); httpsConnector.setAttribute(keystoreFile,ksPath); httpsConnector.setAttribute(keystorePass, keyStorePass); httpsConnector.setAttribute(clientAuth, false); httpsConnector.setAttribute(sslProtocol, TLS); httpsConnector.setAttribute(sslEnabledProtocols, tlsProtocols); httpsConnector.setAttribute(SSLEnabled, true); Connector defaultConnector = tomcat.getConnector(); defaultConnector.setRedirectPort(port); When I server deployed, I see ksPath=jar:file:/shn/lp/main-1.0-SNAPSHOT-jar-with-dependencies.jar! /my.keystore and then failure as SEVERE: Failed to load keystore type JKS with path /shn/lp/jar:file:/shn/lp/main-1.0-SNAPSHOT-jar-with-dependencies.jar! /my.keystore due to /shn/lp/jar:file:/shn/lp/main-1.0-SNAPSHOT-jar-with-dependencies.jar! /my.keystore (No such file or directory) java.io.FileNotFoundException: /shn/lp/jar:file:/shn/lp/main-1.0-SNAPSHOT-jar-with-dependencies.jar! /my.keystore (No such file or directory) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(FileInputStream.java:146) at org.apache.tomcat.util.net.jsse.JSSESocketFactory.getStore(JSSESocket Factory.java:413) at org.apache.tomcat.util.net.jsse.JSSESocketFactory.getKeystore(JSSESoc ketFactory.java:319) at org.apache.tomcat.util.net.jsse.JSSESocketFactory.getKeyManagers(JSSE SocketFactory.java:577) at org.apache.tomcat.util.net.jsse.JSSESocketFactory.getKeyManagers(JSSE SocketFactory.java:517) at org.apache.tomcat.util.net.jsse.JSSESocketFactory.init(JSSESocketFact ory.java:462) at org.apache.tomcat.util.net.jsse.JSSESocketFactory.createSocket(JSSESo cketFactory.java:209) Now, Observed that there are differences in ksPath and path tomcat looks for ksPath=jar:file:/shn/lp/main-1.0-SNAPSHOT-jar-with-dependencies.jar! /my.keystore and java.io.FileNotFoundException: /shn/lp/jar:file:/shn/lp/main-1.0-SNAPSHOT-jar-with-dependencies.jar! /my.keystore (No such file or directory) the tomcat path looks inside /shn/lp (which is current directory) I also see that the keystone file is in fact present jar -tvf /shn/lp/main-1.0-SNAPSHOT-jar-with-dependencies.jar | grep my.keystore 4704 Tue Jun 09 09:29:26 PDT 2015 my.keystore What is the issue and how do I resolve it? keystore files have to be on the file system. Embedding them in a JAR is not currently supported. https://bz.apache.org/bugzilla/show_bug.cgi?id=56777 Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVd41PAAoJEBzwKT+lPKRYXjwP/1yVlWYLXgSVrIxyPGLCz08a Ujvl4A/n2oN+4TyXRUoK9eQKbhPsJuZzckNv2VuzMJXviVvlknJx/Qvy8DDUjLNQ ron9zWeGUT32meiuXdWzjk0A8nwHh1XC/1mlnaocifh71gw5VbkpSGv/TxFXAigo aKVw/PaioPngDqQ2r2o4l74k2zWXHAFDLla8mu1WuiFGdop1x9oQi5L+PGz3HrNA LC64yU3R73v7iLrDUoKtOH72PRJd0uGKviRZ9fIKzZ8pc1VYQfPHvFfD1Kj3iqmQ s3yvlEVIph/3bX1viXgIlqP1z6DZ4ERVnKGklhktbtuvpx/w0Q8w39SUwl7lT21w SywhI8JNrY5kFQty/svYbISfHmCbSYBdcTZgYZIQegttkCalxVheMhtumsZLzalh KMx5SFpLhvBtuxYuBm25dnQ70ZTfjq8iTRgkV1HxU6uJ+3gzCSMzh2EGEum2oYEs qGlZR9W3H1nsn4b9n/EmNRuQC/uNlpqOkM1ERzPfEuTZtuumLoAojiMy/D7dzLNi +9FhItaJpUwoSMBSsZ4sXGItH+GWLtkQaXIE0XA1NaCn+5ZtNmqgWsHGg/dfCzYe 6Ja9U7z21R+nIALcCDczUWbSZZvy2IyFu1QB5Z1BEY9+wVvOyQlEwLo3XiHDG/A/ t4WA/ZlXC13JbkcwXk6A =9Zcq -END PGP SIGNATURE- - To unsubscribe, e-mail:
Re: Choosing a Connector Protocol
On 09/06/2015 14:38, Kevin Hale Boyes wrote: I'm having trouble figuring out what protocol to use for a Connector. I'm using Tomcat 8 and Java 8. The production system that Tomcat will be running on is Solaris 11 and I'm not yet sure if I'll be able to build the tomcat native library. So, I'm choosing between the Http11NioProtocol and Http11Nio2Protocol but I can't figure out what the difference is. I'll have two connectors defined - one SSL and the other non-SSL. The non-SSL connector services user traffic in my web application with the SSL session being terminated at the coyote load balancer. The SSL connector services B2B traffic and it's set up for client authentication. I've seen the Connector Comparison chart but that doesn't really help. The only difference seems to be that Nio uses simulated blocking. A bit of searching seems to compare it against the blocking connector only. So, I'm asking for help in understanding what the difference is between the two connector protocols and how to choose the best one for my application. There is very little to choose between them. Implementing an NIO2 connector was the only way to find out if there were any noticeable performance benefits or not (there weren't). Very long term (maybe Tomcat 10 onwards) one of NIO and NIO2 may get dropped but I think we are several years away from even thinking about that. Right now, I'd say go with NIO. It has been around longer and should - in theory at least - be a little more stable. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Choosing a Connector Protocol
Thanks for you help! On 9 June 2015 at 07:47, Mark Thomas ma...@apache.org wrote: On 09/06/2015 14:38, Kevin Hale Boyes wrote: I'm having trouble figuring out what protocol to use for a Connector. I'm using Tomcat 8 and Java 8. The production system that Tomcat will be running on is Solaris 11 and I'm not yet sure if I'll be able to build the tomcat native library. So, I'm choosing between the Http11NioProtocol and Http11Nio2Protocol but I can't figure out what the difference is. I'll have two connectors defined - one SSL and the other non-SSL. The non-SSL connector services user traffic in my web application with the SSL session being terminated at the coyote load balancer. The SSL connector services B2B traffic and it's set up for client authentication. I've seen the Connector Comparison chart but that doesn't really help. The only difference seems to be that Nio uses simulated blocking. A bit of searching seems to compare it against the blocking connector only. So, I'm asking for help in understanding what the difference is between the two connector protocols and how to choose the best one for my application. There is very little to choose between them. Implementing an NIO2 connector was the only way to find out if there were any noticeable performance benefits or not (there weren't). Very long term (maybe Tomcat 10 onwards) one of NIO and NIO2 may get dropped but I think we are several years away from even thinking about that. Right now, I'd say go with NIO. It has been around longer and should - in theory at least - be a little more stable. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Choosing a Connector Protocol
I'm having trouble figuring out what protocol to use for a Connector. I'm using Tomcat 8 and Java 8. The production system that Tomcat will be running on is Solaris 11 and I'm not yet sure if I'll be able to build the tomcat native library. So, I'm choosing between the Http11NioProtocol and Http11Nio2Protocol but I can't figure out what the difference is. I'll have two connectors defined - one SSL and the other non-SSL. The non-SSL connector services user traffic in my web application with the SSL session being terminated at the coyote load balancer. The SSL connector services B2B traffic and it's set up for client authentication. I've seen the Connector Comparison chart but that doesn't really help. The only difference seems to be that Nio uses simulated blocking. A bit of searching seems to compare it against the blocking connector only. So, I'm asking for help in understanding what the difference is between the two connector protocols and how to choose the best one for my application. Thanks, Kevin.
