Re: [ Tomcat8 ] [ SingleSignOn ] 2 Webapplications
Hello! I tried 8.0.17 (previously I had 8.0.15) and we still have the same problem with same possible workaround. I'll go through your examples, try them and compare what's the difference. On Tue, Jan 20, 2015 at 11:52 AM, Mark Thomas ma...@apache.org wrote: On 20/01/2015 08:10, Leonid Rozenblyum wrote: Thank you, Mark! I spent some time stepping through the code using a default Tomcat install with the following changes: - SSO Valve uncommented in server.xml - test.jsp added to ROOT app that shows request.getUserPrincipal - uncomment user definitions in tomcat-users.xml Note that the examples app ships with a protected page that requires authentication. I see the following: - request ROOT/test.jsp - no authenticated user - request examples/jsp/security/protected - FORM login prompt, login, see index.jsp - request ROOT/test.jsp - shows user authenticated above. SSO cookie has a path of / so gets returned with all requests. This exposes the UserPrincipal to all apps - request examples/jsp/security/protected - see index.jsp - click logout - see FORM login page - request ROOT/test.jsp - no authenticated user. As expected. Logout above has destroyed SSO session and removed SSO cookie So, in short, I am seeing the behaviour you expect to see. I'm doing this with 9.0.x (trunk) but that should be the same as the latest 80.x release. A couple of things to check: - are you using the latest 8.0.x release (8.0.17 - I need to send out the announcement) - Turn on debug logging for the Host where you added the SSO valve - you should see debug messages from the SSO valve which will show when sessions get created, destroyed etc. Mark On Tue, Jan 20, 2015 at 12:18 AM, Mark Thomas ma...@apache.org wrote: On 16/01/2015 14:05, Leonid Rozenblyum wrote: Hello Mark. We do explicit forced expiration of http session in one of SSO enabled apps (Application1 : session.invalidate() ) and it didn't cause session expiration in other Apps (only workaround with adding security-constraint to other apps that I mentioned above helped). Tomcat version is 8.0.15. OS tested was both linux windows Probably I need to prepare minimal test case since it looks like a bug, right? Yes to the possible bug. Thanks but no need at this point for the test case. I'll take a look at what is going on. Mark On Fri, Jan 16, 2015 at 2:53 PM, Mark Thomas ma...@apache.org wrote: On 15/01/2015 15:46, Leonid Rozenblyum wrote: Hello. I have 2 web-applications which are running on the same host. The Valve SingleSignOn is enabled. Application1 has security-constraint and login-config elements in web.xml Application2, 3 etc has no such definitions Technically Application1 is acting as a security gate. All other applications are redirected to it if userPrincipal is not found. In this scenario Single Sign ON works fine - after authenticating in Application1, all other applications have correction userPrincipal. However Single Sign OFF doesn't work in this configuration. If I logout in App1, other sessions are not invalidated. How can this be overcomed? Is it a bug or works-as-intended? Explicit, forced expiration of the HTTP session in any SSO enabled web application should destroy the SSO session and in turn trigger the expiration of the HTTP session for every other SSO enabled web application. Session expiration due to timeout in an SSO enabled web application only terminates the HTTP session for that web application. The SSO session is unaffected (unless this was the last HTTP session associated with the SSO session in which case the SSO session is removed). Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - 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
Re: Android 5.0 SSL handshake failure
On 01/21/2015 11:26 AM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Matt, On 1/21/15 11:13 AM, Matthew Mah wrote: On 01/20/2015 10:08 AM, Christopher Schultz wrote: Matthew, On 1/18/15 1:54 PM, Matthew Mah wrote: I have setup a Tomcat server using spring-boot with SSL/TLS for secure websockets. Tomcat version? JVM version? Any relevant configuration? Tomcat 8.0.15. multiple JVM: java version 1.7.0_55 OpenJDK Runtime Environment java version 1.7.0_65 OpenJDK Runtime Environment java version 1.7.0_71 OpenJDK Runtime Environment I have tried the default ciphers, as well as: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA is listed as both supported and enabled for Android API 11+ http://developer.android.com/reference/javax/net/ssl/SSLSocket.html I would prefer a stronger cipher suite (not SHA1), but right now I am looking for anything that works. This works for Android 4.4, iOS, Firefox, and Chrome clients. Android 5.0 clients (Nexus 5) fail the SSL handshake. What protocol and ciphers are those working browsers using? Chrome: TLS 1.2 ECDHE RSA AES 128 CBC SHA1 Firefox: TLS v? ECDHE RSA AES 128 CBC SHA1 Check the archives for a somewhat recent post by me including code to scan an SSL server for the protocols and ciphers it supports. That's a great tool you've written. Using the shortlist of cipher suites on Tomcat above, this is supported: AcceptedTLSv1 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA AcceptedTLSv1 TLS_RSA_WITH_AES_128_CBC_SHA AcceptedTLSv1 TLS_DHE_RSA_WITH_AES_128_CBC_SHA Accepted TLSv1.1 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA Accepted TLSv1.1 TLS_RSA_WITH_AES_128_CBC_SHA Accepted TLSv1.1 TLS_DHE_RSA_WITH_AES_128_CBC_SHA Accepted TLSv1.2 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA Accepted TLSv1.2 TLS_RSA_WITH_AES_128_CBC_SHA Accepted TLSv1.2 TLS_DHE_RSA_WITH_AES_128_CBC_SHA Cool. Is that the whole list? It's not many: just 3 different ciphers for each of 3 protocols. It's possible there simply isn't any match between what Android 5.0 can do and what you have available. Yes, that's currently the whole list. I tried the default cipher suites first and when they did not work, I tried to slim down the list so that the openssl s_client would negotiate a cipher suite on the supported Android list. - From your SO posting, I can see you claim that TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA is documented to be available in Android's SSL/TLS API, so I'd be surprised if it didn't connect. I wonder if this is a problem with the handshake only? I suspect there is a problem with Android 5's handshake. I've opened an Android bug report: https://code.google.com/p/android/issues/detail?id=103251 If someone on the list had responded that they do have Android 5 connecting a websocket to Tomcat, it would probably be a configuration problem on my Tomcat server. What does your Connector configuration look like? I am using spring-boot 1.2.1, and I don't have that set explicitly. The configuration I do have is the spring boot application.properties: server.ssl.key-store = mind7.cs.umd.edu.chained.p12 server.ssl.key-store-password = secret server.ssl.key-store-type = PKCS12 Otherwise the configuration is the default for spring-boot. Perhaps you have to re-enable the SSLv2hello protocol. (Note that this does not allow SSLv2 or SSLv3 to be used as the protocol... only to start the handshake using the old protocol). I will look into this for spring boot. Thanks. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUv9NEAAoJEBzwKT+lPKRY7QwQAJOJUhBJT4F7jzuT44+vp3oF 2qd+cJLcNtF0Q6u+eyjrWLtvih+AlkxkXvEl9ezOqD5KEwnv0OHk+UDXO6NNu9ha f+X/dXWIr6+WBX9+GAF83b3G4+ZT6VqyYLjj1ydUkx5LIW6JHDbDbXbtt0OGCzN+ q98e0NKOFs2jcw0fudWWtQj1pg7VIMH5eviTdjMWSQursK1MC5n6Byreq0a1KqaP uxbmFI9NgnD9YFm+FCZeDz2Bwj76oHBYdB01TvqDFvvkihepz7SlqsuSLqBOO3Ev s3yIuq6WFIcZUjmqBmrX4aR35DsOzDTS6XRXLuS2vxKn8/WEoclezRmPlqU++f7I qy7EBZEe6wkCTxGtd13/3YbXHhfixvjwplh6127gmLQtfYRF40N++7ZTIAUejLBK bLoeB12NGbFOsPjrSXXcYb0Bj9oz9OKYYCFLL7tgLfBFgtZfh8g8xQuu8DTBs+Ue 4qXDvYDuEq1o4xlgTtQClUq2YG8dKq30U4LMW3K8e7bZFZw7yof2GW2IatWHaljj RcIM9kUxXYrUC3ak4oLJ03xRCqpu6xoouAGr/WVfT182el+CVIJM93llvxA3ULRb AeyF8J+svDiEBeZ4TNmuIp4LVbjBBYlOy7rG3SswHYHUw5KWjzQNNUlN63S1IvL5 gEfezVm/77xilOEMPp9+ =5tO3 -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
DisableExplicitGC
Is it advisable to have the following JVM option set in Tomcat 7 (with Java 7)? -XX:+DisableExplicitGC Or will this prevent Tomcat itself from calling System.gc() when it needs to? Mike - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Android 5.0 SSL handshake failure
On 01/20/2015 10:08 AM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Matthew, On 1/18/15 1:54 PM, Matthew Mah wrote: I have setup a Tomcat server using spring-boot with SSL/TLS for secure websockets. Tomcat version? JVM version? Any relevant configuration? Tomcat 8.0.15. multiple JVM: java version 1.7.0_55 OpenJDK Runtime Environment java version 1.7.0_65 OpenJDK Runtime Environment java version 1.7.0_71 OpenJDK Runtime Environment I have tried the default ciphers, as well as: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA is listed as both supported and enabled for Android API 11+ http://developer.android.com/reference/javax/net/ssl/SSLSocket.html I would prefer a stronger cipher suite (not SHA1), but right now I am looking for anything that works. This works for Android 4.4, iOS, Firefox, and Chrome clients. Android 5.0 clients (Nexus 5) fail the SSL handshake. What protocol and ciphers are those working browsers using? Chrome: TLS 1.2 ECDHE RSA AES 128 CBC SHA1 Firefox: TLS v? ECDHE RSA AES 128 CBC SHA1 Check the archives for a somewhat recent post by me including code to scan an SSL server for the protocols and ciphers it supports. That's a great tool you've written. Using the shortlist of cipher suites on Tomcat above, this is supported: AcceptedTLSv1 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA AcceptedTLSv1 TLS_RSA_WITH_AES_128_CBC_SHA AcceptedTLSv1 TLS_DHE_RSA_WITH_AES_128_CBC_SHA Accepted TLSv1.1 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA Accepted TLSv1.1 TLS_RSA_WITH_AES_128_CBC_SHA Accepted TLSv1.1 TLS_DHE_RSA_WITH_AES_128_CBC_SHA Accepted TLSv1.2 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA Accepted TLSv1.2 TLS_RSA_WITH_AES_128_CBC_SHA Accepted TLSv1.2 TLS_DHE_RSA_WITH_AES_128_CBC_SHA Has anyone successfully setup secure websockets with Android 5? I know there are SSL/TLS changes in Android 5, and so far I am unable to find any combination of configurations on the server and client to successfully connect. If someone else has gotten this to work, at least I will know I am making an error somewhere. I have details posted on stack overflow: http://stackoverflow.com/questions/28011581/android-5-0-lollipop-websocket-ssl-handshake-failure It looks like you might have to re-enable the SSL2hello pseudo-protocol, which is weird because Android 5 should definitely speak TLS. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUvm93AAoJEBzwKT+lPKRYawkQAIaON8MmU0bTw0RYmzuvcL1X uPP23ARjgfNpL04skX/+Rmy6fuHF5zmwhSeABDaHnhx/Uuyobpz+5W9/nXF1IyCq eb6wuGIrQfjHBvvA3vUHN46hNOCrN1hT/ky5oGaXcKShepNB5psl+3/l2zWSIosv 535YYYb59LLykMPEC99LNKjwHszPTciFlbiBJqkbGDWu3AxZ5iaQw8T+UlxtgHsc Mh5UlsC72hi9lkeQ9fpwV74dqpitJsVz336D2gXjtz6MeIgBc0BWYrzHCTtL4Ra7 ISk/T5wHNZTYD4iINTCrWQ4uBGazIs3x91Y8MpKHA9kiBJPZMNqX0UiED+ZuAD0x wT/9MTVyzz1YK9e8i1crcCb3EKEC4aYD6QRLoxqet9i5Bkp2ZGbUoSzw70CmEhz+ w/jHzWJ/pVVIPsxBduFRdj4R+wlYNK/wp6Qyr6EX2Fgm3ZE0MJuAH8OirnYgizrj p/vu17S/P6e8xf1q+3rcWj1ar4/1C73CVOzs1G71dAlx3KaT+DIW2CkZrySYQP29 BpEFjYy08pUUIaG36V5Jeylmz1PeF78CpSV/MD0/XdP8Ar8ayoEfFngkPKCm2e4q KF87qDZ9ylAX97Qn2hmXZKnW2AhXsi3BTf/Z/Z6eDKywhSFuWL4yO2gDrwBHZ+rb ye41SxCVoaxzodEO62Bw =yZdl -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [ANN] Apache Tomcat 8.0.17 available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Leo, On 1/21/15 10:51 AM, Leo Donahue wrote: On Wed, Jan 21, 2015 at 9:03 AM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Leo, On 1/20/15 10:29 PM, Leo Donahue wrote: On Tue, Jan 20, 2015 at 9:24 PM, Leo Donahue donahu...@gmail.com wrote: On Tue, Jan 20, 2015 at 5:09 PM, Mark Thomas ma...@apache.org wrote: The Apache Tomcat team announces the immediate availability of Apache Tomcat 8.0.17. - The RemoteAddrValve and RemoteHostValve can now optionally include the port when filtering along with a new option to trigger authentication rather than denying access And if they are Valves, why do the docs still use the word Filter? Remote Address Filter? Both flavors exist: Valve and Filter. - -chris Right... but.. Everything on this page is called a Filter. http://tomcat.apache.org/tomcat-8.0-doc/config/filter.html Everything on this page is called a Valve, except for the two under Access Control. http://tomcat.apache.org/tomcat-8.0-doc/config/valve.html Patches are always welcome! ;) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUv9H6AAoJEBzwKT+lPKRY8XIP/imkAPDZDKzyb3X3il3l+MoB DdZl7wX6pix01xaIccUEcqhB+SwTXUMsHpdoxVeHb8gg+KkkZKPigX+Rx9V/Bght wc97D1XxGeGWeL7/mxaG8VrpzxpkdBUDmlgu+pdVKkHwfhlEXf+VVk8ETyXUV8Wo KHfc9DWoB5MUrqOsu40IEYaBm+mPf0nx1hTnuZtPvKmv4DnBp+7uIrLpZQVa47rC bA/w5njJPTFLzw2fTKml7cZs2m/1r8VEX5/jFLnY4p9qWez4tRv9S4j56ZUujsZm 2Z8Ms4nb1pqZMxiON9/l16uZMUSWMMJ+LAI4bWN2jMWSB7TzM4HDbI21X0mef+34 IwA2sqE7Ca+2B+bPD18jHPVmbGoS+iOEDi5EBA64OY3mWaaxRuPn7BQXIXuk7VCr ZKjtWPXLXGKqE/mxOR37sx/L/ZpcXu2CbyaVV56sEMCSqZ4ln1Zbn7+5D/jyTNXY ljaN+p9azuw14C5brQdrnbVl5X+GKukXeT2r466QCNDBMM096kYmWwbLbhWRxf9T BesjTYAF9Ej/veNevtLpEKVX6W45+2hP5iX6C2yTFOXCUxiKLnuZNrYUDQpAYvGB 3ISDh3OOxfZODjFNkVG47/BgZKdtgC+bsvurZijqusS3q69qqlje6+cHUfAFOuBv XMNmFsb5Mvr73Po1Sca/ =sMeF -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [ANN] Apache Tomcat 8.0.17 available
On Wed, Jan 21, 2015 at 9:03 AM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Leo, On 1/20/15 10:29 PM, Leo Donahue wrote: On Tue, Jan 20, 2015 at 9:24 PM, Leo Donahue donahu...@gmail.com wrote: On Tue, Jan 20, 2015 at 5:09 PM, Mark Thomas ma...@apache.org wrote: The Apache Tomcat team announces the immediate availability of Apache Tomcat 8.0.17. - The RemoteAddrValve and RemoteHostValve can now optionally include the port when filtering along with a new option to trigger authentication rather than denying access And if they are Valves, why do the docs still use the word Filter? Remote Address Filter? Both flavors exist: Valve and Filter. - -chris Right... but.. Everything on this page is called a Filter. http://tomcat.apache.org/tomcat-8.0-doc/config/filter.html Everything on this page is called a Valve, except for the two under Access Control. http://tomcat.apache.org/tomcat-8.0-doc/config/valve.html
Re: SSL issue in tomcat
You mean here maxThreads=150? But is no respective log message for this. And, I didn't find much request to the service. Currently there are no changed settings(firewall/network, etc.). On Wed, Jan 21, 2015 at 11:28 PM, Jeffrey Janner jeffrey.jan...@polydyne.com wrote: -Original Message- From: Jason Y [mailto:day...@gmail.com] Sent: Wednesday, January 21, 2015 12:44 AM To: Tomcat Users List Subject: Re: SSL issue in tomcat Got another issue...Tomcat is working fine after restart but it cannot last long. Now I cannot access https pages with any browsers. I didn't find anything useful in logs. After a restart, it works well again. Connector executor=tomcatThreadPool port=8080 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=8443 / Connector port=8443 protocol=org.apache.coyote.http11.Http11Protocol maxThreads=150 SSLEnabled=true scheme=https secure=true clientAuth=false sslProtocol=TLS sslEnabledProtocols=TLSv1.2,TLSv1.1,TLSv1 keystoreFile=lib/cert/.keystore keystorePass= / !-- Define an AJP 1.3 Connector on port 8009 -- Connector port=8009 protocol=AJP/1.3 redirectPort=8443 / Just a thought, but since it works for a while and then stops responding, could it be that the OP is running out of processing threads, i.e. a thread or connection pool leak? On Wed, Jan 21, 2015 at 10:01 AM, Sanaullah sanaulla...@gmail.com wrote: its not necessary to have ciphers properties but if you want to restrict the ciphers then you can use this property. On Wed, Jan 21, 2015 at 6:53 AM, Jason Y day...@gmail.com wrote: Thank you all. Now it is working fine. Connector port=8443 protocol=org.apache.coyote.http11.Http11Protocol maxThreads=150 SSLEnabled=true scheme=https secure=true clientAuth=false sslProtocol=TLS sslEnabledProtocols=TLSv1.2,TLSv1.1,TLSv1 keystoreFile=lib/cert/.keystore keystorePass= ciphers=TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA / By the way, do I need ciphers properties here? On Tue, Jan 20, 2015 at 11:22 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jason, On 1/20/15 4:17 AM, Jason Y wrote: Recently my application cannot be accessible in browser with https version. I think it is due to vulnerability in ssl 3.0 issue. I checked my tomcat configuration and replaced sslProtocol=TLS with sslEnabledProtocols=TLSv1,TLSv1.1,TLSv1.2 to disable SSL 3.0. Connector port=8080 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=8443 / Connector port=8443 protocol=org.apache.coyote.http11.Http11Protocol maxThreads=150 SSLEnabled=true scheme=https secure=true clientAuth=false sslEnabledProtocols=TLSv1,TLSv1.1,TLSv1.2 keystoreFile=xxx keystorePass=xxx / Connector port=8009 protocol=AJP/1.3 redirectPort=8443 / None of the responses you have gotten thus far are useful in any way. Your configuration looks fine to me: sslEnabledProtocols is the way to go, although in recent versions of Tomcat the default is NOT to include any SSL protocols and only use the TLS ones, so if you are running something recent, you should be okay. Then I can open my application https link in browser. BUT, good time never lasts too long, after several hours, I failed to access my https link again. What kinds of errors do you get? What do the logs say? What are the URLs you are using? Anyone has any ideas about this? please share your suggestions...My tomcat version is 7.0.55 Those SSL/TLS defaults I mentioned above were done in 7.0.57, so you should definitely keep your above configuration. There is no need to add a trust store or cipher specification to that. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUvnKiAAoJEBzwKT+lPKRYQtsP/00rm7rdKVUID9YVQ4WJk3ty JVQa/g0Kg4prYC+w5AFvZaiDK6EC014GKoTz4ktUzY4Ubnyd3vxsRTV+6/JOig0J C9HcXKEZf63KS2uro71ymXNH0glDGJWtkCeTLR60elBUnyoOIat6ifQ9DqbH9BGT nxJLRq4GZg8aaqKqToJNREY/6nX09+qmPYgpvzrdNlhDgxdb97o9hEPPQA85DMmG mDMyP/TdnIcOdYa8n94/yFjaLQBqCAMl7li2VugbVMkSZMriz/NXnr52xTvZsFtH 8x4D5z5AzU+8+3P+vULmogW6418igLLWZHf03FAh2Wh5RKmvqKjaMzhC9qACYooJ T7F1QfCZVqsEd5edzP17sUPjG62A1awwfMHB3/qmMpWz+Fde4taz2t+Pz652fugw HrfhERRjkdpogfHmrAhBgZ/r89GpYlqEvMguW2PW6zL/ku51wx+aMfujrXO63+ZM 9psUeSvsR823foOYa6C3UV3MFbGWE7awUWuIBQi1bOxsP/ldKvEESGtdu9GpLHw7 A/5fyZ2a6+99HC56lvraGvPi+5ZI52Ej1mR0Ckk9RHRWqoCApTYsCzAPWd5Fntuq
Re: Android 5.0 SSL handshake failure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Matt, On 1/21/15 11:13 AM, Matthew Mah wrote: On 01/20/2015 10:08 AM, Christopher Schultz wrote: Matthew, On 1/18/15 1:54 PM, Matthew Mah wrote: I have setup a Tomcat server using spring-boot with SSL/TLS for secure websockets. Tomcat version? JVM version? Any relevant configuration? Tomcat 8.0.15. multiple JVM: java version 1.7.0_55 OpenJDK Runtime Environment java version 1.7.0_65 OpenJDK Runtime Environment java version 1.7.0_71 OpenJDK Runtime Environment I have tried the default ciphers, as well as: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA is listed as both supported and enabled for Android API 11+ http://developer.android.com/reference/javax/net/ssl/SSLSocket.html I would prefer a stronger cipher suite (not SHA1), but right now I am looking for anything that works. This works for Android 4.4, iOS, Firefox, and Chrome clients. Android 5.0 clients (Nexus 5) fail the SSL handshake. What protocol and ciphers are those working browsers using? Chrome: TLS 1.2 ECDHE RSA AES 128 CBC SHA1 Firefox: TLS v? ECDHE RSA AES 128 CBC SHA1 Check the archives for a somewhat recent post by me including code to scan an SSL server for the protocols and ciphers it supports. That's a great tool you've written. Using the shortlist of cipher suites on Tomcat above, this is supported: AcceptedTLSv1 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA AcceptedTLSv1 TLS_RSA_WITH_AES_128_CBC_SHA AcceptedTLSv1 TLS_DHE_RSA_WITH_AES_128_CBC_SHA Accepted TLSv1.1 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA Accepted TLSv1.1 TLS_RSA_WITH_AES_128_CBC_SHA Accepted TLSv1.1 TLS_DHE_RSA_WITH_AES_128_CBC_SHA Accepted TLSv1.2 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA Accepted TLSv1.2 TLS_RSA_WITH_AES_128_CBC_SHA Accepted TLSv1.2 TLS_DHE_RSA_WITH_AES_128_CBC_SHA Cool. Is that the whole list? It's not many: just 3 different ciphers for each of 3 protocols. It's possible there simply isn't any match between what Android 5.0 can do and what you have available. - From your SO posting, I can see you claim that TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA is documented to be available in Android's SSL/TLS API, so I'd be surprised if it didn't connect. I wonder if this is a problem with the handshake only? What does your Connector configuration look like? Perhaps you have to re-enable the SSLv2hello protocol. (Note that this does not allow SSLv2 or SSLv3 to be used as the protocol... only to start the handshake using the old protocol). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUv9NEAAoJEBzwKT+lPKRY7QwQAJOJUhBJT4F7jzuT44+vp3oF 2qd+cJLcNtF0Q6u+eyjrWLtvih+AlkxkXvEl9ezOqD5KEwnv0OHk+UDXO6NNu9ha f+X/dXWIr6+WBX9+GAF83b3G4+ZT6VqyYLjj1ydUkx5LIW6JHDbDbXbtt0OGCzN+ q98e0NKOFs2jcw0fudWWtQj1pg7VIMH5eviTdjMWSQursK1MC5n6Byreq0a1KqaP uxbmFI9NgnD9YFm+FCZeDz2Bwj76oHBYdB01TvqDFvvkihepz7SlqsuSLqBOO3Ev s3yIuq6WFIcZUjmqBmrX4aR35DsOzDTS6XRXLuS2vxKn8/WEoclezRmPlqU++f7I qy7EBZEe6wkCTxGtd13/3YbXHhfixvjwplh6127gmLQtfYRF40N++7ZTIAUejLBK bLoeB12NGbFOsPjrSXXcYb0Bj9oz9OKYYCFLL7tgLfBFgtZfh8g8xQuu8DTBs+Ue 4qXDvYDuEq1o4xlgTtQClUq2YG8dKq30U4LMW3K8e7bZFZw7yof2GW2IatWHaljj RcIM9kUxXYrUC3ak4oLJ03xRCqpu6xoouAGr/WVfT182el+CVIJM93llvxA3ULRb AeyF8J+svDiEBeZ4TNmuIp4LVbjBBYlOy7rG3SswHYHUw5KWjzQNNUlN63S1IvL5 gEfezVm/77xilOEMPp9+ =5tO3 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: SSL issue in tomcat
-Original Message- From: Jason Y [mailto:day...@gmail.com] Sent: Wednesday, January 21, 2015 12:44 AM To: Tomcat Users List Subject: Re: SSL issue in tomcat Got another issue...Tomcat is working fine after restart but it cannot last long. Now I cannot access https pages with any browsers. I didn't find anything useful in logs. After a restart, it works well again. Connector executor=tomcatThreadPool port=8080 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=8443 / Connector port=8443 protocol=org.apache.coyote.http11.Http11Protocol maxThreads=150 SSLEnabled=true scheme=https secure=true clientAuth=false sslProtocol=TLS sslEnabledProtocols=TLSv1.2,TLSv1.1,TLSv1 keystoreFile=lib/cert/.keystore keystorePass= / !-- Define an AJP 1.3 Connector on port 8009 -- Connector port=8009 protocol=AJP/1.3 redirectPort=8443 / Just a thought, but since it works for a while and then stops responding, could it be that the OP is running out of processing threads, i.e. a thread or connection pool leak? On Wed, Jan 21, 2015 at 10:01 AM, Sanaullah sanaulla...@gmail.com wrote: its not necessary to have ciphers properties but if you want to restrict the ciphers then you can use this property. On Wed, Jan 21, 2015 at 6:53 AM, Jason Y day...@gmail.com wrote: Thank you all. Now it is working fine. Connector port=8443 protocol=org.apache.coyote.http11.Http11Protocol maxThreads=150 SSLEnabled=true scheme=https secure=true clientAuth=false sslProtocol=TLS sslEnabledProtocols=TLSv1.2,TLSv1.1,TLSv1 keystoreFile=lib/cert/.keystore keystorePass= ciphers=TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA / By the way, do I need ciphers properties here? On Tue, Jan 20, 2015 at 11:22 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jason, On 1/20/15 4:17 AM, Jason Y wrote: Recently my application cannot be accessible in browser with https version. I think it is due to vulnerability in ssl 3.0 issue. I checked my tomcat configuration and replaced sslProtocol=TLS with sslEnabledProtocols=TLSv1,TLSv1.1,TLSv1.2 to disable SSL 3.0. Connector port=8080 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=8443 / Connector port=8443 protocol=org.apache.coyote.http11.Http11Protocol maxThreads=150 SSLEnabled=true scheme=https secure=true clientAuth=false sslEnabledProtocols=TLSv1,TLSv1.1,TLSv1.2 keystoreFile=xxx keystorePass=xxx / Connector port=8009 protocol=AJP/1.3 redirectPort=8443 / None of the responses you have gotten thus far are useful in any way. Your configuration looks fine to me: sslEnabledProtocols is the way to go, although in recent versions of Tomcat the default is NOT to include any SSL protocols and only use the TLS ones, so if you are running something recent, you should be okay. Then I can open my application https link in browser. BUT, good time never lasts too long, after several hours, I failed to access my https link again. What kinds of errors do you get? What do the logs say? What are the URLs you are using? Anyone has any ideas about this? please share your suggestions...My tomcat version is 7.0.55 Those SSL/TLS defaults I mentioned above were done in 7.0.57, so you should definitely keep your above configuration. There is no need to add a trust store or cipher specification to that. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUvnKiAAoJEBzwKT+lPKRYQtsP/00rm7rdKVUID9YVQ4WJk3ty JVQa/g0Kg4prYC+w5AFvZaiDK6EC014GKoTz4ktUzY4Ubnyd3vxsRTV+6/JOig0J C9HcXKEZf63KS2uro71ymXNH0glDGJWtkCeTLR60elBUnyoOIat6ifQ9DqbH9BGT nxJLRq4GZg8aaqKqToJNREY/6nX09+qmPYgpvzrdNlhDgxdb97o9hEPPQA85DMmG mDMyP/TdnIcOdYa8n94/yFjaLQBqCAMl7li2VugbVMkSZMriz/NXnr52xTvZsFtH 8x4D5z5AzU+8+3P+vULmogW6418igLLWZHf03FAh2Wh5RKmvqKjaMzhC9qACYooJ T7F1QfCZVqsEd5edzP17sUPjG62A1awwfMHB3/qmMpWz+Fde4taz2t+Pz652fugw HrfhERRjkdpogfHmrAhBgZ/r89GpYlqEvMguW2PW6zL/ku51wx+aMfujrXO63+ZM 9psUeSvsR823foOYa6C3UV3MFbGWE7awUWuIBQi1bOxsP/ldKvEESGtdu9GpLHw7 A/5fyZ2a6+99HC56lvraGvPi+5ZI52Ej1mR0Ckk9RHRWqoCApTYsCzAPWd5Fntuq zuNoyI6onNFKNDZ+17Nm55rywgHR/5hh5CLbf1PwSJRw2mJXbEnoXXUo1XoCS+Oo G5/ksEFNFSc9+yQSSC1H =PVop -END PGP SIGNATURE- -- --- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: DisableExplicitGC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 1/21/15 3:13 PM, André Warnier wrote: Mike Seda wrote: Is it advisable to have the following JVM option set in Tomcat 7 (with Java 7)? -XX:+DisableExplicitGC Or will this prevent Tomcat itself from calling System.gc() when it needs to? Tomcat is probably not doing that anyway (I'll let someone else answer that part), but there might be some monitoring/control application running, which could be using that. The reason I am thinking of this, is that I have a couple of installations where because of an unruly webapp leaving tons of connections open in CLOSE_WAIT state, I am using a jmxsh script regularly, to provoke such GC's to clean them up. If I set the option above, that script would probably fail, and the system would slowly get to an inoperative state. I'm interested... if you add -XX:+DisableExplicitGC and try your JMX-based gc-caller, does it still invoke the gc? I know that sounds stupid, but I wonder if the JMX bean's gc method just calls System.gc() or if it uses something under the covers that will still work. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUwAt5AAoJEBzwKT+lPKRY6oUP/jSwhawcq18sOid3ESIODrEO DLOCxw+EOTbiuxcpYfc0F0Wy4wokMeSpB4Yst/vhi/fli8li9458XqmL/X6AqpHA BMQL2vq0ZFxZokgk/9sZ2CuARmmKUjQwNZl86Dl3sbSV7o/uPoM/FJ5s7MmZkefC dWESL8UgkKyywAVmHnh9bNwQeQtv762U82aEECQZewo2zx7rx7xWDnMDGmmLGgqe QwHlBMw7Mwh9GLbQJ9F4tUA4OhMAqJivXVpb2YN+m1CBURJywLYYzye0ayUORfyt Wyk5iw/g048tykmyotTucDuEF8L87vd2xBEBjgL8w1gFWU4jhg8II0/MBmYgafrz p6qcE3jl6bH2Qmaf4Wt0+nLNLwWat4J4LhDjqCbY0Q4QeBeEC0Iw7PPFGPYnZKyR xJtLxMMq5XMq1JupKfdh/2qInPxqv3h3PkKOCCJVDy/Zo2PT5fViN5mktNEBuBQa 17lITWm9IwpR41xHFvz21fWGMTSx8/EhWj7qsNWz4CiephrHpPXr1p3HV+jG9EnK vV06cgDnBi9UprvbtbF+qVRabMBGq2Idr4JnTY8muG+QShC7UYDeRWrlSXm/4rU7 oBPuCh1PfI0qiz7saOaAn1Dyq8ZsW3sfG7vRfPYVNBM/ow20X8p5oFhMopYYYxYn ScJqskl/HxOdD2nUiq65 =wqJr -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: DisableExplicitGC
On 21/01/2015 19:59, Mike Seda wrote: Is it advisable to have the following JVM option set in Tomcat 7 (with Java 7)? -XX:+DisableExplicitGC That should be fine. Apps really should not be calling that. Or will this prevent Tomcat itself from calling System.gc() when it needs to? Tomcat only calls it in two places - both diagnostic tools. It will never get called in normal operation. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 8.0.17 output buffer issues
Sorry no, it happens on both connectors, 8080(HTTP) and 8443(HTTPS).
The 8080 connector is the default out of the installation. I try to stick to
defaults for trouble shooting purposes.
Shaun Morton
Legal Files Software
217-726-6000 Ext. 341
sh...@legalfiles.com
www.legalfiles.com
-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Wednesday, January 21, 2015 3:45 PM
To: Tomcat Users List
Subject: Re: Tomcat 8.0.17 output buffer issues
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Shaun,
On 1/21/15 4:23 PM, Shaun Morton wrote:
After upgrading from Tomcat 8.0.15 to Tomcat 8.017 our web software
was not loading completely in the end users web browser. The server
side was processing everything but never fully getting to end user.
We see that the response is not complete via Developer mode in IE.
Does it look at all like this:
https://issues.apache.org/bugzilla/show_bug.cgi?id=57476 ?
- -chris
After much research through the Tomcat 8.0.17/8.016 Change Log we
could not find anything specific on this nor anything on the web.
After some trial and error we came up with a solution, but not an
acceptable solution for all our customers.
If I add the following to either our web.xml or Tomcats default
web.xml for the
servlet-classorg.apache.catalina.servlets.DefaultServlet/servlet-cl
ass
we are working again:
init-param param-nameoutput/param-name
param-value64000/param-value /init-param
Basically we are looking for why we have to increase the output buffer
for 8.0.17 and if there is something else we can do to not specify the
output buffer size. Why the default output buffer size is no longer
working with Tomcat 8.0.17. This is the first time we have ran into
this issue with Tomcat.
80% of our customers use Tomcat and it is what we recommend from a
business standpoint.
We also think but can't be 100% that this is causing the issue when
the .java is getting complied: } catch (java.lang.Throwable t) { if
(!(t instanceof javax.servlet.jsp.SkipPageException)){ out =
_jspx_out; if (out != null out.getBufferSize() != 0) try { if
(response.isCommitted()) { out.flush(); } else { out.clearBuffer(); }
} catch (java.io.IOException e) {} if (_jspx_page_context != null)
_jspx_page_context.handlePageException(t); else throw new
ServletException(t); } } finally {
_jspxFactory.releasePageContext(_jspx_page_context); } } }
If we add this to our .jsp it fixes it: out.flush();
OS: Windows 2008R2, Windows 2012, Windows 2012R2, Windows 8.1 (all
64Bit) Java: JDK 8u25, JDK 8u5, JDK 7u17, JDK 7u11 Browser: IE 10 and
IE11 (only browser we support) Tomcat: 8.0.17 (Tomcat 8.0.15 was
completely uninstalled and directory deleted before install of
8.0.17)
I apologize up front as I am new to this support email group.
Shaun Morton
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJUwB3EAAoJEBzwKT+lPKRYDZIQAJsAI/xCbrppKazK3ixEYjJG
YuaTrH5K2nwe/85t3L27PSAEfBsSSi9E2CobCfAwvLIYVTV82RNS8yYvaHGSz6Ej
cwzo2qWEHJNTCwcRSNS3TldRTQf9NDto5hf+It1e4qImNNqL8HaW/viU2SCsXMLc
racJkLFsVSh6Zo8BrJ8xv1x3D/IkkIgZVvV8zamGSst6X2Nz003BJm7yy9pb3imy
fJloTDtWfC43vF562RT/k3VpG2JX5Qvx4JjD2m41nwUFqHZUGGseOILePY0u7sNw
UsXFUcY87OyXBtvYtTcNLm9QGZqRtip4SMMZV7WaE/fs8B5RviAsmSgu1OiJeaKB
yN74nIC+BZQQsjmJifDLELn06pBqFtUe5kbMY8haOkpRG0tpu5x4GoD8ZIUtFB+T
CB1HF37YqwXVDmprlj9uPZQ1ZvG1PeqhZNOCTxLmnFTZzn53tEyV460xv3TCHwqG
M6NR4eRFHIBcP8ehusab8zV72aqTg6+v3erHJcpJ0JDXhNcDcu5w7cAhNec4uJHS
A3+6L0/f4S6vVigOXMKlluhJXECuapXsKcfAvF/sngN0Ww/PJ+X2xQ4zcD3JZMuM
aHf6NzSkfQzYyDTio3xAYwRHtIHB4vykrcxJEvZvW/rurkVw/9x9lClZ3sbDMiCI
wf/mWzCCGV6rhVKGRhME
=3wE/
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: DisableExplicitGC
Mike Seda wrote: Is it advisable to have the following JVM option set in Tomcat 7 (with Java 7)? -XX:+DisableExplicitGC Or will this prevent Tomcat itself from calling System.gc() when it needs to? Tomcat is probably not doing that anyway (I'll let someone else answer that part), but there might be some monitoring/control application running, which could be using that. The reason I am thinking of this, is that I have a couple of installations where because of an unruly webapp leaving tons of connections open in CLOSE_WAIT state, I am using a jmxsh script regularly, to provoke such GC's to clean them up. If I set the option above, that script would probably fail, and the system would slowly get to an inoperative state. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Android 5.0 SSL handshake failure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Matt, On 1/21/15 2:16 PM, Matthew Mah wrote: On 01/21/2015 11:26 AM, Christopher Schultz wrote: Matt, On 1/21/15 11:13 AM, Matthew Mah wrote: On 01/20/2015 10:08 AM, Christopher Schultz wrote: Matthew, On 1/18/15 1:54 PM, Matthew Mah wrote: I have setup a Tomcat server using spring-boot with SSL/TLS for secure websockets. Tomcat version? JVM version? Any relevant configuration? Tomcat 8.0.15. multiple JVM: java version 1.7.0_55 OpenJDK Runtime Environment java version 1.7.0_65 OpenJDK Runtime Environment java version 1.7.0_71 OpenJDK Runtime Environment I have tried the default ciphers, as well as: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA is listed as both supported and enabled for Android API 11+ http://developer.android.com/reference/javax/net/ssl/SSLSocket.html I would prefer a stronger cipher suite (not SHA1), but right now I am looking for anything that works. This works for Android 4.4, iOS, Firefox, and Chrome clients. Android 5.0 clients (Nexus 5) fail the SSL handshake. What protocol and ciphers are those working browsers using? Chrome: TLS 1.2 ECDHE RSA AES 128 CBC SHA1 Firefox: TLS v? ECDHE RSA AES 128 CBC SHA1 Check the archives for a somewhat recent post by me including code to scan an SSL server for the protocols and ciphers it supports. That's a great tool you've written. Using the shortlist of cipher suites on Tomcat above, this is supported: Accepted TLSv1 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA AcceptedTLSv1 TLS_RSA_WITH_AES_128_CBC_SHA AcceptedTLSv1 TLS_DHE_RSA_WITH_AES_128_CBC_SHA Accepted TLSv1.1 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA Accepted TLSv1.1 TLS_RSA_WITH_AES_128_CBC_SHA Accepted TLSv1.1 TLS_DHE_RSA_WITH_AES_128_CBC_SHA Accepted TLSv1.2 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA Accepted TLSv1.2 TLS_RSA_WITH_AES_128_CBC_SHA Accepted TLSv1.2 TLS_DHE_RSA_WITH_AES_128_CBC_SHA Cool. Is that the whole list? It's not many: just 3 different ciphers for each of 3 protocols. It's possible there simply isn't any match between what Android 5.0 can do and what you have available. Yes, that's currently the whole list. I tried the default cipher suites first and when they did not work, I tried to slim down the list so that the openssl s_client would negotiate a cipher suite on the supported Android list. - From your SO posting, I can see you claim that TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA is documented to be available in Android's SSL/TLS API, so I'd be surprised if it didn't connect. I wonder if this is a problem with the handshake only? I suspect there is a problem with Android 5's handshake. I've opened an Android bug report: https://code.google.com/p/android/issues/detail?id=103251 If someone on the list had responded that they do have Android 5 connecting a websocket to Tomcat, it would probably be a configuration problem on my Tomcat server. Have you tried a plain-old HTTPS connection? No Websocket? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUwAsOAAoJEBzwKT+lPKRYoVgP/i+UvdtYuNWdWGbu9q4+p2Sm cNgqAuXiZOZxUP90dfylCMb/cDFqLsGKDiXnNAIuQhH+NLuZmsvN9ZrtCcnRpkaa KBaZK48znvljmOjGL0Hcgfqu4HpMaF3x9OxiS2wLKf7Q6nWkzzolxQKTl2dVwd++ CDh/Ip2Jd6JRKG8VLnVOBSjtnCcOKAtsD5RQTRCXux2ZuOFAT7dWD1W946C9I1bu 8RY7gyJSmz9K5V6XemBEVfCBnDxNZeWRIBx5NxO5BqFUvfA0z5q2q5I1aITNPyjO wf78S5XQCz01WaCZGQThhPlJd0cDPT7K7xGSxqoKCAz2rYRiQvg8EWsRlwEqo25m g+w6iLqBsu3RoBwrkjrPf9FDbdXUsx+a19cMHjUTx+8WMzCPVS8uypzNj2CioTX6 Ywjy9KNrzoa5qh2UAWkvvBhDZOkJHnM0+pKbPgUfV+GaPcw7H8ZYGCkIPGHtcR3T ryNsckNmaQhB7xq1lQVZK2eVdsLuXn4Rrl3RFPztWdylq2vp6d5tQh4o4rVtFb2M vFUTdMtqPo2q29qznFzkBh608CwRapNxZ8sHfaQOBpgqNkbs7dFuvz0r0DYgUQ9D 3ZbohAZ7aE7EUx+I0aGrPmh9r9fKpLtemfwKZOnMnkQiXgN3EXKidWpIi3IIfkv6 zG7c34Nf0TAz/3EWL56H =X7Oz -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: DisableExplicitGC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Daniel, On 1/21/15 3:16 PM, Daniel Mikusa wrote: On Wed, Jan 21, 2015 at 2:59 PM, Mike Seda mike.s...@lillegroup.com wrote: Is it advisable to have the following JVM option set in Tomcat 7 (with Java 7)? -XX:+DisableExplicitGC It may or may not make a difference. Some questions like these come to mind... - How would you feel if one of the applications you deployed called System.gc()? - How about if it called it a lot? or at a really inconvenient time? - How much do you trust your apps or their developers? - Does one of your apps rely on that functionality for some reason? Our application does not call System.gc automatically, but we have that ability through an admin screen where we can say do GC now, and we call it. Sometimes when we have a heap that's been high for a while - -- say, tripping our monitoring software a lot -- we go in there and hit the GC button to see what happens. Usually, heap usage goes down to 25% of what it had been before... it's just that the JVM hadn't done a full GC in a while because it didn't need to. Or will this prevent Tomcat itself from calling System.gc() when it needs to? I really doubt Tomcat would call that. Tomcat calls System.gc() in only one place -- StandardHost.findReloadedContextMemoryLeaks -- which is mostly a debugging tool. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUwBFtAAoJEBzwKT+lPKRYiVMP/RAaAjPpKJWio+0I2Zrwnvu1 xryvw4Ua7DiVzh9ZVFy2NWvw92ReSUWxw6Uf2sKUVOwuC0X5HhnKh7VKtS1fy3h0 6zt/o3StQfugEx/lPA7L1uREJOedM1GOHcKeHNKhC3JQUVH2VKELraO+TMYkCiDU iiMr7pxoPC/TvCYFKQNgVom5TSEcYi18RL//UU/gBZPk+2ZHV8DbyW0wbLG65Lu2 FDEZw01tEqrRpIZrRndECL+9NbGEv6vLte1bPEk+2pImcaIKYME+z20ztsa8KfA1 kbQO6yLvhW4tREH/3SZqfacway4qOxjKQFWqDmkosm7HJXXKlEqsDT+Mi19mTD26 QvD8aQ6tCp5m6SPG89MN5dk6zHtnjVXrjaVMVx75e0IwSN35aJcUm3g5fTdXLwR6 vB4U3T958jt5/uD/k9QxJVB15R8+YdU29iBdxKKQ2C86eGa6jUdizaexNPPnaGPi R9xrSpHo9JjR/5uC1fIcSgwC6JfVH+j8y5j5Yx87vDllD70IkIgh6wtqxdBmL5as 7poC/h8D3TmZwKVtXoAf+DaFIZye9tqxyD8x56XLjVLfBSt9eta0ppunPtqY61KT feHBshR7IXvkP29h2rHnP0Yo5abFgQgz8+jFJSmhKpX9CuKtscToCE9Wbgf5ejST HZSKRwOUMcCVomv4hTwq =WE8p -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.0.17 output buffer issues
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Shaun,
On 1/21/15 4:23 PM, Shaun Morton wrote:
After upgrading from Tomcat 8.0.15 to Tomcat 8.017 our web software
was not loading completely in the end users web browser. The
server side was processing everything but never fully getting to
end user. We see that the response is not complete via Developer
mode in IE.
Does it look at all like this:
https://issues.apache.org/bugzilla/show_bug.cgi?id=57476 ?
- -chris
After much research through the Tomcat 8.0.17/8.016 Change Log we
could not find anything specific on this nor anything on the web.
After some trial and error we came up with a solution, but not an
acceptable solution for all our customers.
If I add the following to either our web.xml or Tomcats default
web.xml for the
servlet-classorg.apache.catalina.servlets.DefaultServlet/servlet-class
we are working again:
init-param param-nameoutput/param-name
param-value64000/param-value /init-param
Basically we are looking for why we have to increase the output
buffer for 8.0.17 and if there is something else we can do to not
specify the output buffer size. Why the default output buffer size
is no longer working with Tomcat 8.0.17. This is the first time we
have ran into this issue with Tomcat.
80% of our customers use Tomcat and it is what we recommend from a
business standpoint.
We also think but can't be 100% that this is causing the issue when
the .java is getting complied: } catch (java.lang.Throwable t) { if
(!(t instanceof javax.servlet.jsp.SkipPageException)){ out =
_jspx_out; if (out != null out.getBufferSize() != 0) try { if
(response.isCommitted()) { out.flush(); } else {
out.clearBuffer(); } } catch (java.io.IOException e) {} if
(_jspx_page_context != null)
_jspx_page_context.handlePageException(t); else throw new
ServletException(t); } } finally {
_jspxFactory.releasePageContext(_jspx_page_context); } } }
If we add this to our .jsp it fixes it: out.flush();
OS: Windows 2008R2, Windows 2012, Windows 2012R2, Windows 8.1 (all
64Bit) Java: JDK 8u25, JDK 8u5, JDK 7u17, JDK 7u11 Browser: IE 10
and IE11 (only browser we support) Tomcat: 8.0.17 (Tomcat 8.0.15
was completely uninstalled and directory deleted before install of
8.0.17)
I apologize up front as I am new to this support email group.
Shaun Morton
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJUwB3EAAoJEBzwKT+lPKRYDZIQAJsAI/xCbrppKazK3ixEYjJG
YuaTrH5K2nwe/85t3L27PSAEfBsSSi9E2CobCfAwvLIYVTV82RNS8yYvaHGSz6Ej
cwzo2qWEHJNTCwcRSNS3TldRTQf9NDto5hf+It1e4qImNNqL8HaW/viU2SCsXMLc
racJkLFsVSh6Zo8BrJ8xv1x3D/IkkIgZVvV8zamGSst6X2Nz003BJm7yy9pb3imy
fJloTDtWfC43vF562RT/k3VpG2JX5Qvx4JjD2m41nwUFqHZUGGseOILePY0u7sNw
UsXFUcY87OyXBtvYtTcNLm9QGZqRtip4SMMZV7WaE/fs8B5RviAsmSgu1OiJeaKB
yN74nIC+BZQQsjmJifDLELn06pBqFtUe5kbMY8haOkpRG0tpu5x4GoD8ZIUtFB+T
CB1HF37YqwXVDmprlj9uPZQ1ZvG1PeqhZNOCTxLmnFTZzn53tEyV460xv3TCHwqG
M6NR4eRFHIBcP8ehusab8zV72aqTg6+v3erHJcpJ0JDXhNcDcu5w7cAhNec4uJHS
A3+6L0/f4S6vVigOXMKlluhJXECuapXsKcfAvF/sngN0Ww/PJ+X2xQ4zcD3JZMuM
aHf6NzSkfQzYyDTio3xAYwRHtIHB4vykrcxJEvZvW/rurkVw/9x9lClZ3sbDMiCI
wf/mWzCCGV6rhVKGRhME
=3wE/
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 8.0.17 output buffer issues
Just so you know we are only using class Http11Protocol not Http11NioProtocol or Http11AprProtocol. This is our connector port which is also the default: Connector port=8080 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=8443 / Shaun Morton Legal Files Software 217-726-6000 Ext. 341 sh...@legalfiles.com www.legalfiles.com -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Wednesday, January 21, 2015 4:11 PM To: Tomcat Users List Subject: Re: Tomcat 8.0.17 output buffer issues -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 1/21/15 4:59 PM, Mark Thomas wrote: On 21/01/2015 21:51, Shaun Morton wrote: Sorry no, it happens on both connectors, 8080(HTTP) and 8443(HTTPS). The 8080 connector is the default out of the installation. I try to stick to defaults for trouble shooting purposes. I must confess I suspected the two were related as well when I read your mail. Since you are being far more responsive that the OP that filed that bug, my current plan is to fix the issue you are seeing and then evaluate BZ 57476 in light of what we discover the root cause of this issue is. I will say that 8.0.18 is likely to appear fairly soon after we track this one down. So, my question to you is this. With a clean 8.0.17 install, that is the easiest way to reproduce this bug? Ideally, if you could provide the simplest possible JSP that triggers this that would be great. (Since we are assuming the reports are linked, just attach it to that BZ report.) FWIW, I'm using 8.0.17 in development with no ill effects. Environment: Oracle Java 1.7.0_67 Tomcat 8.0.17 (release candidate, identical to released version) Debian Linux 7.0, 2.6.32 kernel Connector configuration: Connector port=8215 redirectPort=443 protocol=org.apache.coyote.ajp.AjpNioProtocol URIEncoding=UTF-8 executor=tomcatThreadPool / Connector port=8217 protocol=org.apache.coyote.http11.Http11NioProtocol address=127.0.0.1 secure=false URIEncoding=UTF-8 executor=tomcatThreadPool / The AJP connector is the one getting primary use through Apache httpd and mod_jk. The HTTP connector is used for loopback requests from another service also running under a similar configuration. We are using almost no JSP resources at all. I quickly tested one of our JSPs and it seems to work file. The response size is 39,777 bytes, content type is application/xhtml+xml, and there is no explicit buffer size set in the .jsp source. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUwCPbAAoJEBzwKT+lPKRYTi0P/3sNB10wkEg4tNhMCQpDPnGK 3lDgFZUpNDkSVWv3Y+RUkpeez3KIlFaztbLfpUxDJrLyQ5xrzmZUIR0h8RanAlhh ZrAgqCCbeeloZO0OoLt5QyOD5AFXG2qrAN6f6Ia3nfZT6aLCWg146kHEggHL0c4f 4KoO6J5qgD/dX8N1XcXoxOjzrMF3oI4tgqWRpXF+TQzO7w4RBl+4cU6IC9TTEa6b 6TyrctEdVG8Mzbx/N43j95efd9eb7ByqBBaonMEMoCMZXIzNibX1e918DDOrAmnl jWmxiygCnsTa+Lim3HKBOcB7EMgfOtk1tTEx7eXYvWPIvvfWfAqnw14nU9nmjdZ5 dhbUYk0Qhny5R6urH54oMYw8vKekt5dLz4k5XVp+jMJWkPgXGORpQJrOMmLtRzoA +No5BcjkRwdDswH5ShIa0S8RJ+yyshP0T3vFiHfhlDBjAhZgqCU0EfLRpSigg4r7 9RoStJvS1hFemX2o+Rm+2kjXgSR5lyeKAUtBWyFY4a+pqGnek0P9E0HSCnmBgFZv 7wwulvjjsbCxBYp6wELFyAgfPwS8gLxcusQy4AaatMxnYsU14ohXdoMz2m86u9Fi iR27ETVR5MJ84qG1sbVylt6Xo3msVzSTtSZkAnE+ZruMZlHNfcHNqzDVLKvfDF9e bTacKbRkPEDtfoUs4b+y =jDSl -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: DisableExplicitGC
On Wed, Jan 21, 2015 at 2:59 PM, Mike Seda mike.s...@lillegroup.com wrote: Is it advisable to have the following JVM option set in Tomcat 7 (with Java 7)? -XX:+DisableExplicitGC It may or may not make a difference. Some questions like these come to mind... - How would you feel if one of the applications you deployed called System.gc()? - How about if it called it a lot? or at a really inconvenient time? - How much do you trust your apps or their developers? - Does one of your apps rely on that functionality for some reason? Or will this prevent Tomcat itself from calling System.gc() when it needs to? I really doubt Tomcat would call that. Dan
Re: Log4j with Apache Tomcat 8.0.17
Thank you. That worked. Should i open a ticket in bugzilla to fix the doc? On 1/21/2015 1:43 PM, Mark Thomas wrote: On 21/01/2015 20:27, George Sexton wrote: I'm having a problem configuring log4j with Apache Tomcat 8.0.17. I'm using OpenSUSE 13.2 with OpenJDK 8.0: linux:java -version openjdk version 1.8.0_40 OpenJDK Runtime Environment (build 1.8.0_40-b10) OpenJDK 64-Bit Server VM (build 25.40-b14, mixed mode) I'm following the instructions in the log4j section of the Logging in Tomcat section of the Tomcat documentation. The steps do not appear to work, and there is no information in the log file that I can see that would assist me in troubleshooting this. Referencing the steps: 1) I have created log4j.properties in $CATALINA_BASE/lib. The file is readable by the tomcat user. linux:/srv/tomcat/lib # ls -al log4j.properties -rw-r--r-- 1 root root 2343 Jan 21 12:57 log4j.properties 2) I have downloaded log4j 1.2 or later (version 2.1) Try with the latest 1.x release. I'm fairly sure the API changes between 1.x and 2.x mean code changes are required on Tomcat's side to support 2.x. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- George Sexton *MH Software, Inc.* Voice: 303 438 9585 http://www.mhsoftware.com
Re: DisableExplicitGC
On Wed, Jan 21, 2015 at 3:51 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Daniel, On 1/21/15 3:16 PM, Daniel Mikusa wrote: On Wed, Jan 21, 2015 at 2:59 PM, Mike Seda mike.s...@lillegroup.com wrote: Is it advisable to have the following JVM option set in Tomcat 7 (with Java 7)? -XX:+DisableExplicitGC It may or may not make a difference. Some questions like these come to mind... - How would you feel if one of the applications you deployed called System.gc()? - How about if it called it a lot? or at a really inconvenient time? - How much do you trust your apps or their developers? - Does one of your apps rely on that functionality for some reason? Our application does not call System.gc automatically, but we have that ability through an admin screen where we can say do GC now, and we call it. Sometimes when we have a heap that's been high for a while - -- say, tripping our monitoring software a lot -- we go in there and hit the GC button to see what happens. Usually, heap usage goes down to 25% of what it had been before... it's just that the JVM hadn't done a full GC in a while because it didn't need to. I've done that too, but initiated the GC through jvisualvm. I was wondering if DisableExplicitGC would prevent that as well, so I did a quick test and it seemed to prevent it. Guess that's something to consider too. Dan Or will this prevent Tomcat itself from calling System.gc() when it needs to? I really doubt Tomcat would call that. Tomcat calls System.gc() in only one place -- StandardHost.findReloadedContextMemoryLeaks -- which is mostly a debugging tool. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUwBFtAAoJEBzwKT+lPKRYiVMP/RAaAjPpKJWio+0I2Zrwnvu1 xryvw4Ua7DiVzh9ZVFy2NWvw92ReSUWxw6Uf2sKUVOwuC0X5HhnKh7VKtS1fy3h0 6zt/o3StQfugEx/lPA7L1uREJOedM1GOHcKeHNKhC3JQUVH2VKELraO+TMYkCiDU iiMr7pxoPC/TvCYFKQNgVom5TSEcYi18RL//UU/gBZPk+2ZHV8DbyW0wbLG65Lu2 FDEZw01tEqrRpIZrRndECL+9NbGEv6vLte1bPEk+2pImcaIKYME+z20ztsa8KfA1 kbQO6yLvhW4tREH/3SZqfacway4qOxjKQFWqDmkosm7HJXXKlEqsDT+Mi19mTD26 QvD8aQ6tCp5m6SPG89MN5dk6zHtnjVXrjaVMVx75e0IwSN35aJcUm3g5fTdXLwR6 vB4U3T958jt5/uD/k9QxJVB15R8+YdU29iBdxKKQ2C86eGa6jUdizaexNPPnaGPi R9xrSpHo9JjR/5uC1fIcSgwC6JfVH+j8y5j5Yx87vDllD70IkIgh6wtqxdBmL5as 7poC/h8D3TmZwKVtXoAf+DaFIZye9tqxyD8x56XLjVLfBSt9eta0ppunPtqY61KT feHBshR7IXvkP29h2rHnP0Yo5abFgQgz8+jFJSmhKpX9CuKtscToCE9Wbgf5ejST HZSKRwOUMcCVomv4hTwq =WE8p -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Log4j with Apache Tomcat 8.0.17
On 21/01/2015 21:04, George Sexton wrote: Thank you. That worked. Should i open a ticket in bugzilla to fix the doc? Please. Mark On 1/21/2015 1:43 PM, Mark Thomas wrote: On 21/01/2015 20:27, George Sexton wrote: I'm having a problem configuring log4j with Apache Tomcat 8.0.17. I'm using OpenSUSE 13.2 with OpenJDK 8.0: linux:java -version openjdk version 1.8.0_40 OpenJDK Runtime Environment (build 1.8.0_40-b10) OpenJDK 64-Bit Server VM (build 25.40-b14, mixed mode) I'm following the instructions in the log4j section of the Logging in Tomcat section of the Tomcat documentation. The steps do not appear to work, and there is no information in the log file that I can see that would assist me in troubleshooting this. Referencing the steps: 1) I have created log4j.properties in $CATALINA_BASE/lib. The file is readable by the tomcat user. linux:/srv/tomcat/lib # ls -al log4j.properties -rw-r--r-- 1 root root 2343 Jan 21 12:57 log4j.properties 2) I have downloaded log4j 1.2 or later (version 2.1) Try with the latest 1.x release. I'm fairly sure the API changes between 1.x and 2.x mean code changes are required on Tomcat's side to support 2.x. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Log4j with Apache Tomcat 8.0.17
On 21/01/2015 20:27, George Sexton wrote: I'm having a problem configuring log4j with Apache Tomcat 8.0.17. I'm using OpenSUSE 13.2 with OpenJDK 8.0: linux:java -version openjdk version 1.8.0_40 OpenJDK Runtime Environment (build 1.8.0_40-b10) OpenJDK 64-Bit Server VM (build 25.40-b14, mixed mode) I'm following the instructions in the log4j section of the Logging in Tomcat section of the Tomcat documentation. The steps do not appear to work, and there is no information in the log file that I can see that would assist me in troubleshooting this. Referencing the steps: 1) I have created log4j.properties in $CATALINA_BASE/lib. The file is readable by the tomcat user. linux:/srv/tomcat/lib # ls -al log4j.properties -rw-r--r-- 1 root root 2343 Jan 21 12:57 log4j.properties 2) I have downloaded log4j 1.2 or later (version 2.1) Try with the latest 1.x release. I'm fairly sure the API changes between 1.x and 2.x mean code changes are required on Tomcat's side to support 2.x. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 8.0.17 output buffer issues
After upgrading from Tomcat 8.0.15 to Tomcat 8.017 our web software was not
loading completely in the end users web browser. The server side was
processing everything but never fully getting to end user. We see that the
response is not complete via Developer mode in IE.
After much research through the Tomcat 8.0.17/8.016 Change Log we could not
find anything specific on this nor anything on the web.
After some trial and error we came up with a solution, but not an acceptable
solution for all our customers.
If I add the following to either our web.xml or Tomcats default web.xml for the
servlet-classorg.apache.catalina.servlets.DefaultServlet/servlet-class we
are working again:
init-param
param-nameoutput/param-name
param-value64000/param-value
/init-param
Basically we are looking for why we have to increase the output buffer for
8.0.17 and if there is something else we can do to not specify the output
buffer size. Why the default output buffer size is no longer working with
Tomcat 8.0.17.
This is the first time we have ran into this issue with Tomcat.
80% of our customers use Tomcat and it is what we recommend from a business
standpoint.
We also think but can't be 100% that this is causing the issue when the .java
is getting complied:
} catch (java.lang.Throwable t) {
if (!(t instanceof javax.servlet.jsp.SkipPageException)){
out = _jspx_out;
if (out != null out.getBufferSize() != 0)
try {
if (response.isCommitted()) {
out.flush();
} else {
out.clearBuffer();
}
} catch (java.io.IOException e) {}
if (_jspx_page_context != null)
_jspx_page_context.handlePageException(t);
else throw new ServletException(t);
}
} finally {
_jspxFactory.releasePageContext(_jspx_page_context);
}
}
}
If we add this to our .jsp it fixes it:
out.flush();
OS: Windows 2008R2, Windows 2012, Windows 2012R2, Windows 8.1 (all 64Bit)
Java: JDK 8u25, JDK 8u5, JDK 7u17, JDK 7u11
Browser: IE 10 and IE11 (only browser we support)
Tomcat: 8.0.17 (Tomcat 8.0.15 was completely uninstalled and directory deleted
before install of 8.0.17)
I apologize up front as I am new to this support email group.
Shaun Morton
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.0.17 output buffer issues
On 21/01/2015 21:51, Shaun Morton wrote:
Sorry no, it happens on both connectors, 8080(HTTP) and 8443(HTTPS).
The 8080 connector is the default out of the installation. I try to stick to
defaults for trouble shooting purposes.
I must confess I suspected the two were related as well when I read your
mail. Since you are being far more responsive that the OP that filed
that bug, my current plan is to fix the issue you are seeing and then
evaluate BZ 57476 in light of what we discover the root cause of this
issue is.
I will say that 8.0.18 is likely to appear fairly soon after we track
this one down.
So, my question to you is this. With a clean 8.0.17 install, that is the
easiest way to reproduce this bug? Ideally, if you could provide the
simplest possible JSP that triggers this that would be great. (Since we
are assuming the reports are linked, just attach it to that BZ report.)
Cheers,
Mark
Shaun Morton
Legal Files Software
217-726-6000 Ext. 341
sh...@legalfiles.com
www.legalfiles.com
-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Wednesday, January 21, 2015 3:45 PM
To: Tomcat Users List
Subject: Re: Tomcat 8.0.17 output buffer issues
Shaun,
On 1/21/15 4:23 PM, Shaun Morton wrote:
After upgrading from Tomcat 8.0.15 to Tomcat 8.017 our web software
was not loading completely in the end users web browser. The server
side was processing everything but never fully getting to end user.
We see that the response is not complete via Developer mode in IE.
Does it look at all like this:
https://issues.apache.org/bugzilla/show_bug.cgi?id=57476 ?
-chris
After much research through the Tomcat 8.0.17/8.016 Change Log we
could not find anything specific on this nor anything on the web.
After some trial and error we came up with a solution, but not an
acceptable solution for all our customers.
If I add the following to either our web.xml or Tomcats default
web.xml for the
servlet-classorg.apache.catalina.servlets.DefaultServlet/servlet-cl
ass
we are working again:
init-param param-nameoutput/param-name
param-value64000/param-value /init-param
Basically we are looking for why we have to increase the output buffer
for 8.0.17 and if there is something else we can do to not specify the
output buffer size. Why the default output buffer size is no longer
working with Tomcat 8.0.17. This is the first time we have ran into
this issue with Tomcat.
80% of our customers use Tomcat and it is what we recommend from a
business standpoint.
We also think but can't be 100% that this is causing the issue when
the .java is getting complied: } catch (java.lang.Throwable t) { if
(!(t instanceof javax.servlet.jsp.SkipPageException)){ out =
_jspx_out; if (out != null out.getBufferSize() != 0) try { if
(response.isCommitted()) { out.flush(); } else { out.clearBuffer(); }
} catch (java.io.IOException e) {} if (_jspx_page_context != null)
_jspx_page_context.handlePageException(t); else throw new
ServletException(t); } } finally {
_jspxFactory.releasePageContext(_jspx_page_context); } } }
If we add this to our .jsp it fixes it: out.flush();
OS: Windows 2008R2, Windows 2012, Windows 2012R2, Windows 8.1 (all
64Bit) Java: JDK 8u25, JDK 8u5, JDK 7u17, JDK 7u11 Browser: IE 10 and
IE11 (only browser we support) Tomcat: 8.0.17 (Tomcat 8.0.15 was
completely uninstalled and directory deleted before install of
8.0.17)
I apologize up front as I am new to this support email group.
Shaun Morton
-
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
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.0.17 output buffer issues
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 1/21/15 4:59 PM, Mark Thomas wrote: On 21/01/2015 21:51, Shaun Morton wrote: Sorry no, it happens on both connectors, 8080(HTTP) and 8443(HTTPS). The 8080 connector is the default out of the installation. I try to stick to defaults for trouble shooting purposes. I must confess I suspected the two were related as well when I read your mail. Since you are being far more responsive that the OP that filed that bug, my current plan is to fix the issue you are seeing and then evaluate BZ 57476 in light of what we discover the root cause of this issue is. I will say that 8.0.18 is likely to appear fairly soon after we track this one down. So, my question to you is this. With a clean 8.0.17 install, that is the easiest way to reproduce this bug? Ideally, if you could provide the simplest possible JSP that triggers this that would be great. (Since we are assuming the reports are linked, just attach it to that BZ report.) FWIW, I'm using 8.0.17 in development with no ill effects. Environment: Oracle Java 1.7.0_67 Tomcat 8.0.17 (release candidate, identical to released version) Debian Linux 7.0, 2.6.32 kernel Connector configuration: Connector port=8215 redirectPort=443 protocol=org.apache.coyote.ajp.AjpNioProtocol URIEncoding=UTF-8 executor=tomcatThreadPool / Connector port=8217 protocol=org.apache.coyote.http11.Http11NioProtocol address=127.0.0.1 secure=false URIEncoding=UTF-8 executor=tomcatThreadPool / The AJP connector is the one getting primary use through Apache httpd and mod_jk. The HTTP connector is used for loopback requests from another service also running under a similar configuration. We are using almost no JSP resources at all. I quickly tested one of our JSPs and it seems to work file. The response size is 39,777 bytes, content type is application/xhtml+xml, and there is no explicit buffer size set in the .jsp source. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUwCPbAAoJEBzwKT+lPKRYTi0P/3sNB10wkEg4tNhMCQpDPnGK 3lDgFZUpNDkSVWv3Y+RUkpeez3KIlFaztbLfpUxDJrLyQ5xrzmZUIR0h8RanAlhh ZrAgqCCbeeloZO0OoLt5QyOD5AFXG2qrAN6f6Ia3nfZT6aLCWg146kHEggHL0c4f 4KoO6J5qgD/dX8N1XcXoxOjzrMF3oI4tgqWRpXF+TQzO7w4RBl+4cU6IC9TTEa6b 6TyrctEdVG8Mzbx/N43j95efd9eb7ByqBBaonMEMoCMZXIzNibX1e918DDOrAmnl jWmxiygCnsTa+Lim3HKBOcB7EMgfOtk1tTEx7eXYvWPIvvfWfAqnw14nU9nmjdZ5 dhbUYk0Qhny5R6urH54oMYw8vKekt5dLz4k5XVp+jMJWkPgXGORpQJrOMmLtRzoA +No5BcjkRwdDswH5ShIa0S8RJ+yyshP0T3vFiHfhlDBjAhZgqCU0EfLRpSigg4r7 9RoStJvS1hFemX2o+Rm+2kjXgSR5lyeKAUtBWyFY4a+pqGnek0P9E0HSCnmBgFZv 7wwulvjjsbCxBYp6wELFyAgfPwS8gLxcusQy4AaatMxnYsU14ohXdoMz2m86u9Fi iR27ETVR5MJ84qG1sbVylt6Xo3msVzSTtSZkAnE+ZruMZlHNfcHNqzDVLKvfDF9e bTacKbRkPEDtfoUs4b+y =jDSl -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 8.0.17 output buffer issues
We will be creating a .jsp and putting it in a .war for you. Should be
tomorrow.
Shaun Morton
Legal Files Software
217-726-6000 Ext. 341
sh...@legalfiles.com
www.legalfiles.com
-Original Message-
From: Mark Thomas [mailto:ma...@apache.org]
Sent: Wednesday, January 21, 2015 4:00 PM
To: users@tomcat.apache.org
Subject: Re: Tomcat 8.0.17 output buffer issues
On 21/01/2015 21:51, Shaun Morton wrote:
Sorry no, it happens on both connectors, 8080(HTTP) and 8443(HTTPS).
The 8080 connector is the default out of the installation. I try to stick to
defaults for trouble shooting purposes.
I must confess I suspected the two were related as well when I read your mail.
Since you are being far more responsive that the OP that filed that bug, my
current plan is to fix the issue you are seeing and then evaluate BZ 57476 in
light of what we discover the root cause of this issue is.
I will say that 8.0.18 is likely to appear fairly soon after we track this one
down.
So, my question to you is this. With a clean 8.0.17 install, that is the
easiest way to reproduce this bug? Ideally, if you could provide the simplest
possible JSP that triggers this that would be great. (Since we are assuming the
reports are linked, just attach it to that BZ report.)
Cheers,
Mark
Shaun Morton
Legal Files Software
217-726-6000 Ext. 341
sh...@legalfiles.com
www.legalfiles.com
-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Wednesday, January 21, 2015 3:45 PM
To: Tomcat Users List
Subject: Re: Tomcat 8.0.17 output buffer issues
Shaun,
On 1/21/15 4:23 PM, Shaun Morton wrote:
After upgrading from Tomcat 8.0.15 to Tomcat 8.017 our web software
was not loading completely in the end users web browser. The server
side was processing everything but never fully getting to end user.
We see that the response is not complete via Developer mode in IE.
Does it look at all like this:
https://issues.apache.org/bugzilla/show_bug.cgi?id=57476 ?
-chris
After much research through the Tomcat 8.0.17/8.016 Change Log we
could not find anything specific on this nor anything on the web.
After some trial and error we came up with a solution, but not an
acceptable solution for all our customers.
If I add the following to either our web.xml or Tomcats default
web.xml for the
servlet-classorg.apache.catalina.servlets.DefaultServlet/servlet-c
l
ass
we are working again:
init-param param-nameoutput/param-name
param-value64000/param-value /init-param
Basically we are looking for why we have to increase the output
buffer for 8.0.17 and if there is something else we can do to not
specify the output buffer size. Why the default output buffer size
is no longer working with Tomcat 8.0.17. This is the first time we
have ran into this issue with Tomcat.
80% of our customers use Tomcat and it is what we recommend from a
business standpoint.
We also think but can't be 100% that this is causing the issue when
the .java is getting complied: } catch (java.lang.Throwable t) { if
(!(t instanceof javax.servlet.jsp.SkipPageException)){ out =
_jspx_out; if (out != null out.getBufferSize() != 0) try { if
(response.isCommitted()) { out.flush(); } else { out.clearBuffer(); }
} catch (java.io.IOException e) {} if (_jspx_page_context != null)
_jspx_page_context.handlePageException(t); else throw new
ServletException(t); } } finally {
_jspxFactory.releasePageContext(_jspx_page_context); } } }
If we add this to our .jsp it fixes it: out.flush();
OS: Windows 2008R2, Windows 2012, Windows 2012R2, Windows 8.1 (all
64Bit) Java: JDK 8u25, JDK 8u5, JDK 7u17, JDK 7u11 Browser: IE 10 and
IE11 (only browser we support) Tomcat: 8.0.17 (Tomcat 8.0.15 was
completely uninstalled and directory deleted before install of
8.0.17)
I apologize up front as I am new to this support email group.
Shaun Morton
-
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
-
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: Tomcat 8.0.17 output buffer issues
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Shaun, On 1/21/15 5:27 PM, Shaun Morton wrote: Just so you know we are only using class Http11Protocol not Http11NioProtocol or Http11AprProtocol. This is our connector port which is also the default: Connector port=8080 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=8443 / This will auto-select between the NIO and APR connectors. If you have the Tomcat native library available to Tomcat, then it will default to using the APR connector. If not, the default is the NIO connector. Can you tell us which one you are using? You can confirm this by looking at the startup log messages. For instance, when I start my Tomcat, I get messages about the connectors like this: Jan 12, 2015 3:52:08 PM org.apache.coyote.AbstractProtocol start INFO: Starting ProtocolHandler [ajp-nio-8215] Jan 12, 2015 3:52:08 PM org.apache.coyote.AbstractProtocol start INFO: Starting ProtocolHandler [http-nio-127.0.0.1-8217] That indicates that I'm running one AJP-NIO connector and one HTTP-NIO handler. Your startup logs will tell you which is being effectively auto-selected. Thanks, - -chris -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Wednesday, January 21, 2015 4:11 PM To: Tomcat Users List Subject: Re: Tomcat 8.0.17 output buffer issues Mark, On 1/21/15 4:59 PM, Mark Thomas wrote: On 21/01/2015 21:51, Shaun Morton wrote: Sorry no, it happens on both connectors, 8080(HTTP) and 8443(HTTPS). The 8080 connector is the default out of the installation. I try to stick to defaults for trouble shooting purposes. I must confess I suspected the two were related as well when I read your mail. Since you are being far more responsive that the OP that filed that bug, my current plan is to fix the issue you are seeing and then evaluate BZ 57476 in light of what we discover the root cause of this issue is. I will say that 8.0.18 is likely to appear fairly soon after we track this one down. So, my question to you is this. With a clean 8.0.17 install, that is the easiest way to reproduce this bug? Ideally, if you could provide the simplest possible JSP that triggers this that would be great. (Since we are assuming the reports are linked, just attach it to that BZ report.) FWIW, I'm using 8.0.17 in development with no ill effects. Environment: Oracle Java 1.7.0_67 Tomcat 8.0.17 (release candidate, identical to released version) Debian Linux 7.0, 2.6.32 kernel Connector configuration: Connector port=8215 redirectPort=443 protocol=org.apache.coyote.ajp.AjpNioProtocol URIEncoding=UTF-8 executor=tomcatThreadPool / Connector port=8217 protocol=org.apache.coyote.http11.Http11NioProtocol address=127.0.0.1 secure=false URIEncoding=UTF-8 executor=tomcatThreadPool / The AJP connector is the one getting primary use through Apache httpd and mod_jk. The HTTP connector is used for loopback requests from another service also running under a similar configuration. We are using almost no JSP resources at all. I quickly tested one of our JSPs and it seems to work file. The response size is 39,777 bytes, content type is application/xhtml+xml, and there is no explicit buffer size set in the .jsp source. -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 -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUwC4DAAoJEBzwKT+lPKRYOv4P/jeUTWEvRL70rVbTY+1THsnI EpUxc3zO+EiHzqlDUuyy/2MwK6bndgecMZHsVSHq/Zd9bC8xfpbsy4m7EzgP8wTT KSCCfm2jIGBBF62e67qGkKddejEqUZ6oDXDP0XBz7ERfsYcneDcUEYTAjIC8fCOi 19/n2uyjRlmnK62SHBLC0U6AqYt0joAv/LR/YK4qHh2caGh+Y8geNIq7oBjfrMJe LgiZm+I+ZvLn9Hsdv5tRywajDFWKR8PWNgiye/tXjhdidlW+nTPrac4JIWTgU4AQ pKals71fJZh5Z3oCtVFoHY/Yz9RtWNwaJSNkv/ZEaByykgq9aHI3SzP1udShz+Be qxXzM8jWl9rd3lC8c/uSivTRtgv6/wRc6zia353Hl3ZSNqa8sO4qYnwVbZOtx1Q9 VKXmSzJbWmeNEl67ber2zeGr9zyoeajyQiO/laQeEv4JGciR2ysmKI+W8GbQ3zpv YMpqHzl8SvcKwpZons72MmjQZOSKtB3uPopzY7XYr6y5GCebUaNhXF0EtXoM8CDk tGjHTq5i/H+Oq35ZArsmGQx6oVPmATW0xCu0uUj54UlbB655YaHuQGZaRwgfpHOk VjH4qpJI/lpmnrVb3Ey0rLXGsgHFzWG7qEnotYlbeew788JgmcdVCecF39q+fBkG ijV29Rmofivmxib3vBE4 =iuNt -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Mod_jk Configuration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Chris, On 1/21/15 5:56 PM, Chris Arnold wrote: When i look at the apache log for that request, i dont see where the request is even making it to apache or tomcat. Try to request a static file from DocumentRoot directory. If you cannot, then your HTTPS is not configured correctly. Get that working first. Yeah, I overlooked that in my first response. As long as you don't see the request in the Apache access log, you'll not make progress. So i got all the connections worked out and now apache and tomcat are accepting connections. However, i still can not get mod_jk working correctly. Here is the mod_jk debug log: [Wed Jan 21 12:31:04 2015] [2345:139798017603520] [error] extension_fix::jk_uri_worker_map.c (578): Could not find worker with name 'ajp13' in uri map post processing. You must have changed something since your original configuration. Do you have JkMount ajp13 somewhere? You need to use the worker name and not the protocol name. Can you post your updated workers.properties file, and related httpd.conf configurations? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUwDHrAAoJEBzwKT+lPKRYeHoP/1DkXe8lNduURqqGUgPIdBKX mpBhi0QbcSMUHX55gy0GHOitm12wr/JqeHRj3XNrZu6HR9IsCOR+ybuI6xObbAWs miwwYHBe9XrD52GTfLiXfUXfE3JzNMXC6u0TjInGZOLSwG6N5/wK2ng2tzRcoqdR m+xA1Rc0/iTPjQ0hp4z0TemxrdqXbYuPVF/BahkVAsl205ciADkBYAQQ8d1A6h/Q SY3G2p3XlD0SMYVO/4MCUgyhyEEO0+TUZ0KaaLpMSzhTTpYnsBFP4/6kdXei0xsL 8ak94TeySlpLdjDqxofYN3YobUnrXdLQipjMM/KlMRnbKl/aLVVe6yct0sq+tTr3 mTQY1UB1hzbmmps6GdRasTjxp2Ik0DHS6IDgAa0ATBI3+3gVVD9vpVAVCMbdhevH Oz/yhZoRAO5uTgQxbg8Srv6daMstJ8Ei6lw6M9gYUK32yvPDU49WxEOFhUnLv7Gd TsMVUnAZ1uXIwhY2LpVycA8gerilQjziyLBZfL1kved9PzExWrBv14yPc+yyXRxB Mcgdxu3/11AqjENv9HBG3UE3aYoIx8YybHz6wNPISRxhbF/RcvC2TmTEG9BK93gh mH5BcRsx800NdDfa/txoXiOP405BaNMbaU/RWkiCJdPCGNOs4dYbonQPYXxzKnog 0fUPXjd6DG4CHqgPRWsc =XIb6 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Mod_jk Configuration
+1 And also, could you specify again what URL you are requesting in the browser, which you would expect to be proxied to Tomcat ? https://share2.domain.tld Looking at the log you just showed, it seemed that the only requests ever passed through mod_jk for evaluation, where things like /error/* and mod_jk (rightly so) decides that they are not for Tomcat, declines to process them, and returns the request to Apache, to tell it to find another victim to handle that URL. Agreed! Which is why i need some guidance. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.0.17 output buffer issues
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Shaun, On 1/21/15 6:04 PM, Shaun Morton wrote: Chris, I apologize, I thought I had to specify the other classes. I do not have the Tomcat native library installed and it looks to be http-nio, here are the log entries: 21-Jan-2015 15:44:17.118 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler [http-nio-8080] 21-Jan-2015 15:44:17.118 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler [http-bio-8443] 21-Jan-2015 15:44:17.118 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler [ajp-nio-8009] 21-Jan-2015 15:44:17.118 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in 2547 ms Okay, and HTTP versus HTTPS doesn't matter? Both are exhibiting this problem? - -chris -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Wednesday, January 21, 2015 4:54 PM To: Tomcat Users List Subject: Re: Tomcat 8.0.17 output buffer issues Shaun, On 1/21/15 5:27 PM, Shaun Morton wrote: Just so you know we are only using class Http11Protocol not Http11NioProtocol or Http11AprProtocol. This is our connector port which is also the default: Connector port=8080 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=8443 / This will auto-select between the NIO and APR connectors. If you have the Tomcat native library available to Tomcat, then it will default to using the APR connector. If not, the default is the NIO connector. Can you tell us which one you are using? You can confirm this by looking at the startup log messages. For instance, when I start my Tomcat, I get messages about the connectors like this: Jan 12, 2015 3:52:08 PM org.apache.coyote.AbstractProtocol start INFO: Starting ProtocolHandler [ajp-nio-8215] Jan 12, 2015 3:52:08 PM org.apache.coyote.AbstractProtocol start INFO: Starting ProtocolHandler [http-nio-127.0.0.1-8217] That indicates that I'm running one AJP-NIO connector and one HTTP-NIO handler. Your startup logs will tell you which is being effectively auto-selected. Thanks, -chris -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Wednesday, January 21, 2015 4:11 PM To: Tomcat Users List Subject: Re: Tomcat 8.0.17 output buffer issues Mark, On 1/21/15 4:59 PM, Mark Thomas wrote: On 21/01/2015 21:51, Shaun Morton wrote: Sorry no, it happens on both connectors, 8080(HTTP) and 8443(HTTPS). The 8080 connector is the default out of the installation. I try to stick to defaults for trouble shooting purposes. I must confess I suspected the two were related as well when I read your mail. Since you are being far more responsive that the OP that filed that bug, my current plan is to fix the issue you are seeing and then evaluate BZ 57476 in light of what we discover the root cause of this issue is. I will say that 8.0.18 is likely to appear fairly soon after we track this one down. So, my question to you is this. With a clean 8.0.17 install, that is the easiest way to reproduce this bug? Ideally, if you could provide the simplest possible JSP that triggers this that would be great. (Since we are assuming the reports are linked, just attach it to that BZ report.) FWIW, I'm using 8.0.17 in development with no ill effects. Environment: Oracle Java 1.7.0_67 Tomcat 8.0.17 (release candidate, identical to released version) Debian Linux 7.0, 2.6.32 kernel Connector configuration: Connector port=8215 redirectPort=443 protocol=org.apache.coyote.ajp.AjpNioProtocol URIEncoding=UTF-8 executor=tomcatThreadPool / Connector port=8217 protocol=org.apache.coyote.http11.Http11NioProtocol address=127.0.0.1 secure=false URIEncoding=UTF-8 executor=tomcatThreadPool / The AJP connector is the one getting primary use through Apache httpd and mod_jk. The HTTP connector is used for loopback requests from another service also running under a similar configuration. We are using almost no JSP resources at all. I quickly tested one of our JSPs and it seems to work file. The response size is 39,777 bytes, content type is application/xhtml+xml, and there is no explicit buffer size set in the .jsp source. -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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Mod_jk Configuration
Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Chris, On 1/21/15 5:56 PM, Chris Arnold wrote: When i look at the apache log for that request, i dont see where the request is even making it to apache or tomcat. Try to request a static file from DocumentRoot directory. If you cannot, then your HTTPS is not configured correctly. Get that working first. Yeah, I overlooked that in my first response. As long as you don't see the request in the Apache access log, you'll not make progress. So i got all the connections worked out and now apache and tomcat are accepting connections. However, i still can not get mod_jk working correctly. Here is the mod_jk debug log: [Wed Jan 21 12:31:04 2015] [2345:139798017603520] [error] extension_fix::jk_uri_worker_map.c (578): Could not find worker with name 'ajp13' in uri map post processing. You must have changed something since your original configuration. Do you have JkMount ajp13 somewhere? You need to use the worker name and not the protocol name. Can you post your updated workers.properties file, and related httpd.conf configurations? +1 And also, could you specify again what URL you are requesting in the browser, which you would expect to be proxied to Tomcat ? With the previous configuration that you showed here, that should be a URL like http://yourhost.etc/share/(something) or http://yourhost.etc/share2/(something) Looking at the log you just showed, it seemed that the only requests ever passed through mod_jk for evaluation, where things like /error/* and mod_jk (rightly so) decides that they are not for Tomcat, declines to process them, and returns the request to Apache, to tell it to find another victim to handle that URL. Example from your previous log : ... map_uri_to_worker_ext::jk_uri_worker_map.c (1170): Attempting to map URI '/error/include/bottom.html' from 1 maps [Wed Jan 21 12:34:46 2015] [2507:139894823892928] [debug] find_match::jk_uri_worker_map.c (984): Attempting to map context URI '/share2/*=worker1' source 'JkMount' [Wed Jan 21 12:34:46 2015] [2507:139894823892928] [debug] jk_map_to_storage::mod_jk.c (3816): no match for /error/include/bottom.html found ... - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 8.0.17 output buffer issues
Chris, I apologize, I thought I had to specify the other classes. I do not have the Tomcat native library installed and it looks to be http-nio, here are the log entries: 21-Jan-2015 15:44:17.118 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler [http-nio-8080] 21-Jan-2015 15:44:17.118 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler [http-bio-8443] 21-Jan-2015 15:44:17.118 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler [ajp-nio-8009] 21-Jan-2015 15:44:17.118 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in 2547 ms Shaun Morton Legal Files Software 217-726-6000 Ext. 341 sh...@legalfiles.com www.legalfiles.com -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Wednesday, January 21, 2015 4:54 PM To: Tomcat Users List Subject: Re: Tomcat 8.0.17 output buffer issues -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Shaun, On 1/21/15 5:27 PM, Shaun Morton wrote: Just so you know we are only using class Http11Protocol not Http11NioProtocol or Http11AprProtocol. This is our connector port which is also the default: Connector port=8080 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=8443 / This will auto-select between the NIO and APR connectors. If you have the Tomcat native library available to Tomcat, then it will default to using the APR connector. If not, the default is the NIO connector. Can you tell us which one you are using? You can confirm this by looking at the startup log messages. For instance, when I start my Tomcat, I get messages about the connectors like this: Jan 12, 2015 3:52:08 PM org.apache.coyote.AbstractProtocol start INFO: Starting ProtocolHandler [ajp-nio-8215] Jan 12, 2015 3:52:08 PM org.apache.coyote.AbstractProtocol start INFO: Starting ProtocolHandler [http-nio-127.0.0.1-8217] That indicates that I'm running one AJP-NIO connector and one HTTP-NIO handler. Your startup logs will tell you which is being effectively auto-selected. Thanks, - -chris -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Wednesday, January 21, 2015 4:11 PM To: Tomcat Users List Subject: Re: Tomcat 8.0.17 output buffer issues Mark, On 1/21/15 4:59 PM, Mark Thomas wrote: On 21/01/2015 21:51, Shaun Morton wrote: Sorry no, it happens on both connectors, 8080(HTTP) and 8443(HTTPS). The 8080 connector is the default out of the installation. I try to stick to defaults for trouble shooting purposes. I must confess I suspected the two were related as well when I read your mail. Since you are being far more responsive that the OP that filed that bug, my current plan is to fix the issue you are seeing and then evaluate BZ 57476 in light of what we discover the root cause of this issue is. I will say that 8.0.18 is likely to appear fairly soon after we track this one down. So, my question to you is this. With a clean 8.0.17 install, that is the easiest way to reproduce this bug? Ideally, if you could provide the simplest possible JSP that triggers this that would be great. (Since we are assuming the reports are linked, just attach it to that BZ report.) FWIW, I'm using 8.0.17 in development with no ill effects. Environment: Oracle Java 1.7.0_67 Tomcat 8.0.17 (release candidate, identical to released version) Debian Linux 7.0, 2.6.32 kernel Connector configuration: Connector port=8215 redirectPort=443 protocol=org.apache.coyote.ajp.AjpNioProtocol URIEncoding=UTF-8 executor=tomcatThreadPool / Connector port=8217 protocol=org.apache.coyote.http11.Http11NioProtocol address=127.0.0.1 secure=false URIEncoding=UTF-8 executor=tomcatThreadPool / The AJP connector is the one getting primary use through Apache httpd and mod_jk. The HTTP connector is used for loopback requests from another service also running under a similar configuration. We are using almost no JSP resources at all. I quickly tested one of our JSPs and it seems to work file. The response size is 39,777 bytes, content type is application/xhtml+xml, and there is no explicit buffer size set in the .jsp source. -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 -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUwC4DAAoJEBzwKT+lPKRYOv4P/jeUTWEvRL70rVbTY+1THsnI EpUxc3zO+EiHzqlDUuyy/2MwK6bndgecMZHsVSHq/Zd9bC8xfpbsy4m7EzgP8wTT KSCCfm2jIGBBF62e67qGkKddejEqUZ6oDXDP0XBz7ERfsYcneDcUEYTAjIC8fCOi
Re: Android 5.0 SSL handshake failure
On 01/21/2015 03:24 PM, Christopher Schultz wrote:
Have you tried a plain-old HTTPS connection? No Websocket?
I just tried HTTPS using
HttpsURLConnection urlConnection = (HttpsURLConnection)
url.openConnection();
try {
try {
InputStream in = new
BufferedInputStream(urlConnection.getInputStream());
byte [] buffer = new byte[1024];
in.read(buffer);
Log.i(TAG, new String(buffer));
}
catch(Exception e){
}
String cipherSuite = urlConnection.getCipherSuite();
Log.i(TAG, connected? + cipherSuite);
}
There is currently no content being served (only the websocket), but the
network trace shows a successful TLSv1.2 handshake. This should mean the
certificates and cipher suites are fine, but there is a problem with
some interaction between Android 5.0 and the Tyrus websocket
implementation. I think the most logical next step is to try a different
websocket implementation.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.0.17 output buffer issues
Both have the same problem. Shaun Morton On Jan 21, 2015, at 5:09 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Shaun, On 1/21/15 6:04 PM, Shaun Morton wrote: Chris, I apologize, I thought I had to specify the other classes. I do not have the Tomcat native library installed and it looks to be http-nio, here are the log entries: 21-Jan-2015 15:44:17.118 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler [http-nio-8080] 21-Jan-2015 15:44:17.118 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler [http-bio-8443] 21-Jan-2015 15:44:17.118 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler [ajp-nio-8009] 21-Jan-2015 15:44:17.118 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in 2547 ms Okay, and HTTP versus HTTPS doesn't matter? Both are exhibiting this problem? - -chris -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Wednesday, January 21, 2015 4:54 PM To: Tomcat Users List Subject: Re: Tomcat 8.0.17 output buffer issues Shaun, On 1/21/15 5:27 PM, Shaun Morton wrote: Just so you know we are only using class Http11Protocol not Http11NioProtocol or Http11AprProtocol. This is our connector port which is also the default: Connector port=8080 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=8443 / This will auto-select between the NIO and APR connectors. If you have the Tomcat native library available to Tomcat, then it will default to using the APR connector. If not, the default is the NIO connector. Can you tell us which one you are using? You can confirm this by looking at the startup log messages. For instance, when I start my Tomcat, I get messages about the connectors like this: Jan 12, 2015 3:52:08 PM org.apache.coyote.AbstractProtocol start INFO: Starting ProtocolHandler [ajp-nio-8215] Jan 12, 2015 3:52:08 PM org.apache.coyote.AbstractProtocol start INFO: Starting ProtocolHandler [http-nio-127.0.0.1-8217] That indicates that I'm running one AJP-NIO connector and one HTTP-NIO handler. Your startup logs will tell you which is being effectively auto-selected. Thanks, -chris -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Wednesday, January 21, 2015 4:11 PM To: Tomcat Users List Subject: Re: Tomcat 8.0.17 output buffer issues Mark, On 1/21/15 4:59 PM, Mark Thomas wrote: On 21/01/2015 21:51, Shaun Morton wrote: Sorry no, it happens on both connectors, 8080(HTTP) and 8443(HTTPS). The 8080 connector is the default out of the installation. I try to stick to defaults for trouble shooting purposes. I must confess I suspected the two were related as well when I read your mail. Since you are being far more responsive that the OP that filed that bug, my current plan is to fix the issue you are seeing and then evaluate BZ 57476 in light of what we discover the root cause of this issue is. I will say that 8.0.18 is likely to appear fairly soon after we track this one down. So, my question to you is this. With a clean 8.0.17 install, that is the easiest way to reproduce this bug? Ideally, if you could provide the simplest possible JSP that triggers this that would be great. (Since we are assuming the reports are linked, just attach it to that BZ report.) FWIW, I'm using 8.0.17 in development with no ill effects. Environment: Oracle Java 1.7.0_67 Tomcat 8.0.17 (release candidate, identical to released version) Debian Linux 7.0, 2.6.32 kernel Connector configuration: Connector port=8215 redirectPort=443 protocol=org.apache.coyote.ajp.AjpNioProtocol URIEncoding=UTF-8 executor=tomcatThreadPool / Connector port=8217 protocol=org.apache.coyote.http11.Http11NioProtocol address=127.0.0.1 secure=false URIEncoding=UTF-8 executor=tomcatThreadPool / The AJP connector is the one getting primary use through Apache httpd and mod_jk. The HTTP connector is used for loopback requests from another service also running under a similar configuration. We are using almost no JSP resources at all. I quickly tested one of our JSPs and it seems to work file. The response size is 39,777 bytes, content type is application/xhtml+xml, and there is no explicit buffer size set in the .jsp source. -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 - To unsubscribe, e-mail:
org.apache.catalina.startup.Catalina.process(args)... method in Tomcat 6 but not 7 nor 8
Greetings,I have inherited code that calls: org.apache.catalina.startup.Catalina.process(args). I now need to upgrade this code to Tomcat 8. Currently, we are using Tomcat 6. I have previously upgraded with no problems, but both Tomcat 7 and 8 do not have the .process method. I can not find any documentation as to what should be used in place of .process(args). I have tried: - Catalina.load(args) - Catalina.start() For both, the application failed with an error stating that the server could not be contacted. I'm sorry that I can not give more detail than that. I am counting on the idea that there must be some replacement for the .process() method that I am just not comprehending. If you know the replacement for org.apache.catalina.startup.Catalina.process(args) and could share it with me, I would be very grateful. Thank You, Terry Medearis
RE: Mod_jk Configuration
Chris,
On 1/21/15 5:56 PM, Chris wrote:
You must have changed something since your original configuration. Do
you have JkMount ajp13 somewhere? You need to use the worker name
and not the protocol name.
Can you post your updated workers.properties file, and related
httpd.conf configurations?
workers.properties:
worker.list=jk-status
worker.jk-status.type=status
worker.jk-status.read_only=true
worker.list=jk-manager
worker.list=worker1
worker.jk-manager.type=status
worker.list=balancer
worker.balancer.type=lb
worker.balancer.max_reply_timeouts=10
worker.balancer.balance_workers=worker1
worker.worker1.reference=worker.template
worker.worker1.host=localhost
worker.worker1.port=8009
worker.worker1.activation=A
worker.template.type=ajp13
worker.template.socket_keepalive=true
version of mod_jk running 1.2.26
worker.template.connection_pool_minsize=0
worker.template.connection_pool_timeout=600
worker.template.reply_timeout=30
worker.template.recovery_options=3
Httpd.conf:
Include /opt/alfresco/tomcat/conf/jk.conf
apache vhost:
IfDefine SSL
IfDefine !NOSSL
##
## SSL Virtual Host Context
##
VirtualHost 192.168.123.200:443
# General setup for the virtual host
DocumentRoot /opt/alfresco/tomcat/webapps/share
ServerName share2.domain.tld:443
ServerAlias mail.* ifolder.* share.* apps.*
ErrorLog /var/log/apache2/ssl-error_log
TransferLog /var/log/apache2/ssl-access_log
LogLevel Debug
LogLevel rewrite:trace8
# SSL Engine Switch:
# Enable/Disable SSL for this virtual host.
SSLEngine on
#This rewrites https://share.anydomain.tld to our share server
#RewriteEngine On
#RewriteCond %{HTTP_HOST} ^share2\.
#RewriteCond %{HTTPS} on
#RewriteCond %{REQUEST_URI} !^/share2/
#RewriteRule ^/(.*) https://share2.teknerds.net:8443/share/ [P]
JkMount /share2/* worker1
Found it! IT was in the jk.conf file:
JkMount /share2/*.* ajp13
I have removed ajp13 so now that line looks like:
JkMount /share2/*.*
Restart apache and got this error:
Jan 21 18:38:02 labweb start_apache2[3042]: AH00526: Syntax error on line 32 of
/opt/alfresco/tomcat/conf/jk
Jan 21 18:38:02 labweb start_apache2[3042]: JkMount needs a path when not
defined in a location
So i commented it out (it was like this originally).
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Mod_jk Configuration
When i look at the apache log for that request, i dont see where the request is even making it to apache or tomcat. Try to request a static file from DocumentRoot directory. If you cannot, then your HTTPS is not configured correctly. Get that working first. Yeah, I overlooked that in my first response. As long as you don't see the request in the Apache access log, you'll not make progress. So i got all the connections worked out and now apache and tomcat are accepting connections. However, i still can not get mod_jk working correctly. Here is the mod_jk debug log: [Wed Jan 21 12:31:04 2015] [2345:139798017603520] [error] extension_fix::jk_uri_worker_map.c (578): Could not find worker with name 'ajp13' in uri map post processing. [Wed Jan 21 12:31:04 2015] [2345:139798017603520] [error] extension_fix::jk_uri_worker_map.c (578): Could not find worker with name 'ajp13' in uri map post processing. [Wed Jan 21 12:33:29 2015] [2430:140672245532608] [error] extension_fix::jk_uri_worker_map.c (578): Could not find worker with name 'ajp13' in uri map post processing. [Wed Jan 21 12:33:29 2015] [2430:140672245532608] [error] extension_fix::jk_uri_worker_map.c (578): Could not find worker with name 'ajp13' in uri map post processing. [Wed Jan 21 12:34:35 2015] [2490:139894823892928] [debug] jk_set_time_fmt::jk_util.c (480): Pre-processed log time stamp format is '[%a %b %d %H:%M:%S %Y] ' [Wed Jan 21 12:34:35 2015] [2490:139894823892928] [debug] uri_worker_map_open::jk_uri_worker_map.c (904): rule map size is 1 [Wed Jan 21 12:34:35 2015] [2490:139894823892928] [debug] uri_worker_map_add::jk_uri_worker_map.c (854): wildchar rule '/share2/*.*=ajp13' source 'JkMount' was added [Wed Jan 21 12:34:35 2015] [2490:139894823892928] [debug] uri_worker_map_dump::jk_uri_worker_map.c (178): uri map dump after map open: id=0, index=0 file='(null)' reject_unsafe=0 reload=60 modified=0 checked=0 [Wed Jan 21 12:34:35 2015] [2490:139894823892928] [debug] uri_worker_map_dump::jk_uri_worker_map.c (184): generation 0: size=0 nosize=0 capacity=0 [Wed Jan 21 12:34:35 2015] [2490:139894823892928] [debug] uri_worker_map_dump::jk_uri_worker_map.c (184): generation 1: size=1 nosize=0 capacity=4 [Wed Jan 21 12:34:35 2015] [2490:139894823892928] [debug] uri_worker_map_dump::jk_uri_worker_map.c (197): NEXT (1) map #0: uri=/share2/*.* worker=ajp13 context=/share2/*.* source=JkMount type=Wildchar len=11 [Wed Jan 21 12:34:35 2015] [2490:139894823892928] [debug] jk_set_time_fmt::jk_util.c (480): Pre-processed log time stamp format is '[%a %b %d %H:%M:%S %Y] ' [Wed Jan 21 12:34:35 2015] [2490:139894823892928] [debug] uri_worker_map_open::jk_uri_worker_map.c (904): rule map size is 1 [Wed Jan 21 12:34:35 2015] [2490:139894823892928] [debug] uri_worker_map_add::jk_uri_worker_map.c (863): exact rule '/share2=worker1' source 'JkMount' was added [Wed Jan 21 12:34:35 2015] [2490:139894823892928] [debug] uri_worker_map_add::jk_uri_worker_map.c (854): wildchar rule '/share2/*=worker1' source 'JkMount' was added [Wed Jan 21 12:34:35 2015] [2490:139894823892928] [debug] uri_worker_map_dump::jk_uri_worker_map.c (178): uri map dump after map open: id=0, index=0 file='(null)' reject_unsafe=0 reload=60 modified=0 checked=0 [Wed Jan 21 12:34:35 2015] [2490:139894823892928] [debug] uri_worker_map_dump::jk_uri_worker_map.c (184): generation 0: size=0 nosize=0 capacity=0 [Wed Jan 21 12:34:35 2015] [2490:139894823892928] [debug] uri_worker_map_dump::jk_uri_worker_map.c (184): generation 1: size=2 nosize=0 capacity=4 [Wed Jan 21 12:34:35 2015] [2490:139894823892928] [debug] uri_worker_map_dump::jk_uri_worker_map.c (197): NEXT (1) map #0: uri=/share2/* worker=worker1 context=/share2/* source=JkMount type=Wildchar len=9 [Wed Jan 21 12:34:35 2015] [2490:139894823892928] [debug] uri_worker_map_dump::jk_uri_worker_map.c (197): NEXT (1) map #1: uri=/share2 worker=worker1 context=/share2 source=JkMount type=Exact len=7 [Wed Jan 21 12:34:35 2015] [2490:139894823892928] [debug] jk_set_time_fmt::jk_util.c (480): Pre-processed log time stamp format is '[%a %b %d %H:%M:%S %Y] ' [Wed Jan 21 12:34:35 2015] [2490:139894823892928] [debug] uri_worker_map_open::jk_uri_worker_map.c (904): rule map size is 1 [Wed Jan 21 12:34:35 2015] [2490:139894823892928] [debug] uri_worker_map_add::jk_uri_worker_map.c (854): wildchar rule '/share2/*=worker1' source 'JkMount' was added [Wed Jan 21 12:34:35 2015] [2490:139894823892928] [debug] uri_worker_map_dump::jk_uri_worker_map.c (178): uri map dump after map open: id=0, index=0 file='(null)' reject_unsafe=0 reload=60 modified=0 checked=0 [Wed Jan 21 12:34:35 2015] [2490:139894823892928] [debug] uri_worker_map_dump::jk_uri_worker_map.c (184): generation 0: size=0 nosize=0 capacity=0 [Wed Jan 21 12:34:35 2015] [2490:139894823892928] [debug] uri_worker_map_dump::jk_uri_worker_map.c (184): generation 1: size=1 nosize=0 capacity=4 [Wed Jan 21 12:34:35 2015] [2490:139894823892928] [debug]
Re: Tomcat 8.0.17 output buffer issues
2015-01-22 0:23 GMT+03:00 Shaun Morton sh...@legalfiles.com: After upgrading from Tomcat 8.0.15 to Tomcat 8.017 our web software was not loading completely in the end users web browser. The server side was processing everything but never fully getting to end user. We see that the response is not complete via Developer mode in IE. After much research through the Tomcat 8.0.17/8.016 Change Log we could not find anything specific on this nor anything on the web. After some trial and error we came up with a solution, but not an acceptable solution for all our customers. If I add the following to either our web.xml or Tomcats default web.xml for the servlet-classorg.apache.catalina.servlets.DefaultServlet/servlet-class we are working again: init-param param-nameoutput/param-name param-value64000/param-value /init-param Basically we are looking for why we have to increase the output buffer for 8.0.17 and if there is something else we can do to not specify the output buffer size. Why the default output buffer size is no longer working with Tomcat 8.0.17. This is the first time we have ran into this issue with Tomcat. [...] A simple test for delivery of files with DefaultServlet - I see no issues. My test: 1) Remove all files from ROOT webapp and put the following into ROOT/WEB-INF/web.xml to enable listings in DefaultServlet: [[[ ?xml version=1.0 encoding=ISO-8859-1? !-- Licensed to the Apache Software Foundation (ASF) under one or more -- web-app xmlns=http://xmlns.jcp.org/xml/ns/javaee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd; version=3.1 metadata-complete=true display-nameWelcome to Tomcat/display-name description Welcome to Tomcat /description servlet servlet-namedefault/servlet-name servlet-classorg.apache.catalina.servlets.DefaultServlet/servlet-class init-param param-namedebug/param-name param-value0/param-value /init-param init-param param-namelistings/param-name param-valuetrue/param-value /init-param load-on-startup1/load-on-startup /servlet /web-app ]]] 2) Copy Tomcat v8.0.17 files into the ROOT webapp to use them as payload for the test. (It was an svn checkout of v8.0.17 directory from dist.a.o) 3) Configure connectors in conf/server.xml Uncomment HTTPS connector, create server certificate with Java. Set protocol attribute on Connectors to select their implementations. I had to add the following attribute to HTTPS connecor: sslEnabledProtocols=TLSv1,SSLv2Hello My wget version is old and won't connect unless SSLv2Hello is enabled. 4) wget -r --no-parent -e robots=off --level inf http://localhost:8080/ wget -r --no-parent -e robots=off --level inf --no-check-certificate https://localhost:8443/ 5) Check *.md5 checksums for downloaded files. Result: all downloads are OK. I am using 32-bit JDK 7u72 on Windows 7. I tested HTTP+(BIO,NIO,APR), HTTPS+(BIO,NIO). I have not tested HTTPS+APR and AJP+anything. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SSL issue in tomcat
What I changed in server.xml is adding sslEnabledProtocols=TLSv1.2,TLSv1.1,TLSv1. BUT I noticed that I am using JSSE instead of APR, so I remoeved the listener Listener className=org.apache.catalina.core.AprLifecycleListener SSLEngine=on / is this causing my error? On Wed, Jan 21, 2015 at 11:39 PM, Jason Y day...@gmail.com wrote: You mean here maxThreads=150? But is no respective log message for this. And, I didn't find much request to the service. Currently there are no changed settings(firewall/network, etc.). On Wed, Jan 21, 2015 at 11:28 PM, Jeffrey Janner jeffrey.jan...@polydyne.com wrote: -Original Message- From: Jason Y [mailto:day...@gmail.com] Sent: Wednesday, January 21, 2015 12:44 AM To: Tomcat Users List Subject: Re: SSL issue in tomcat Got another issue...Tomcat is working fine after restart but it cannot last long. Now I cannot access https pages with any browsers. I didn't find anything useful in logs. After a restart, it works well again. Connector executor=tomcatThreadPool port=8080 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=8443 / Connector port=8443 protocol=org.apache.coyote.http11.Http11Protocol maxThreads=150 SSLEnabled=true scheme=https secure=true clientAuth=false sslProtocol=TLS sslEnabledProtocols=TLSv1.2,TLSv1.1,TLSv1 keystoreFile=lib/cert/.keystore keystorePass= / !-- Define an AJP 1.3 Connector on port 8009 -- Connector port=8009 protocol=AJP/1.3 redirectPort=8443 / Just a thought, but since it works for a while and then stops responding, could it be that the OP is running out of processing threads, i.e. a thread or connection pool leak? On Wed, Jan 21, 2015 at 10:01 AM, Sanaullah sanaulla...@gmail.com wrote: its not necessary to have ciphers properties but if you want to restrict the ciphers then you can use this property. On Wed, Jan 21, 2015 at 6:53 AM, Jason Y day...@gmail.com wrote: Thank you all. Now it is working fine. Connector port=8443 protocol=org.apache.coyote.http11.Http11Protocol maxThreads=150 SSLEnabled=true scheme=https secure=true clientAuth=false sslProtocol=TLS sslEnabledProtocols=TLSv1.2,TLSv1.1,TLSv1 keystoreFile=lib/cert/.keystore keystorePass= ciphers=TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA / By the way, do I need ciphers properties here? On Tue, Jan 20, 2015 at 11:22 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jason, On 1/20/15 4:17 AM, Jason Y wrote: Recently my application cannot be accessible in browser with https version. I think it is due to vulnerability in ssl 3.0 issue. I checked my tomcat configuration and replaced sslProtocol=TLS with sslEnabledProtocols=TLSv1,TLSv1.1,TLSv1.2 to disable SSL 3.0. Connector port=8080 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=8443 / Connector port=8443 protocol=org.apache.coyote.http11.Http11Protocol maxThreads=150 SSLEnabled=true scheme=https secure=true clientAuth=false sslEnabledProtocols=TLSv1,TLSv1.1,TLSv1.2 keystoreFile=xxx keystorePass=xxx / Connector port=8009 protocol=AJP/1.3 redirectPort=8443 / None of the responses you have gotten thus far are useful in any way. Your configuration looks fine to me: sslEnabledProtocols is the way to go, although in recent versions of Tomcat the default is NOT to include any SSL protocols and only use the TLS ones, so if you are running something recent, you should be okay. Then I can open my application https link in browser. BUT, good time never lasts too long, after several hours, I failed to access my https link again. What kinds of errors do you get? What do the logs say? What are the URLs you are using? Anyone has any ideas about this? please share your suggestions...My tomcat version is 7.0.55 Those SSL/TLS defaults I mentioned above were done in 7.0.57, so you should definitely keep your above configuration. There is no need to add a trust store or cipher specification to that. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUvnKiAAoJEBzwKT+lPKRYQtsP/00rm7rdKVUID9YVQ4WJk3ty JVQa/g0Kg4prYC+w5AFvZaiDK6EC014GKoTz4ktUzY4Ubnyd3vxsRTV+6/JOig0J C9HcXKEZf63KS2uro71ymXNH0glDGJWtkCeTLR60elBUnyoOIat6ifQ9DqbH9BGT nxJLRq4GZg8aaqKqToJNREY/6nX09+qmPYgpvzrdNlhDgxdb97o9hEPPQA85DMmG mDMyP/TdnIcOdYa8n94/yFjaLQBqCAMl7li2VugbVMkSZMriz/NXnr52xTvZsFtH
Re: Mod_jk Configuration
Am 22.01.2015 um 01:03 schrieb Chris Arnold: +1 And also, could you specify again what URL you are requesting in the browser, which you would expect to be proxied to Tomcat ? https://share2.domain.tld Looking at the log you just showed, it seemed that the only requests ever passed through mod_jk for evaluation, where things like /error/* and mod_jk (rightly so) decides that they are not for Tomcat, declines to process them, and returns the request to Apache, to tell it to find another victim to handle that URL. Agreed! Which is why i need some guidance. You have set JkMount /share2/* worker1 which means: forward any request that hits the VirtualHost in which you have put that JkMount and where the request has a URI starting with /share2/ via the worker worker1. Then you test with the request http://share2.domain.tld/ which has URI /. This URI does not start with /share2/ so it does not match the JkMount and the request is not being forwarded. Attempting to map URI '/' from 1 maps Attempting to map context URI '/share2/*=worker1' source 'JkMount' no match for / found Instead Apache tries to produce an error page using a new interal request with an URI starting with /error/ etc. So either you test with the request http://share2.domain.tld/share2/what-ever-makes-sense-here or - if your really need to forward anything under http://share2.domain.tld/ you need to use JkMount /* worker1 instead of the JkMount you are currently using. Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Log4j with Apache Tomcat 8.0.17
I'm having a problem configuring log4j with Apache Tomcat 8.0.17. I'm using OpenSUSE 13.2 with OpenJDK 8.0: linux:java -version openjdk version 1.8.0_40 OpenJDK Runtime Environment (build 1.8.0_40-b10) OpenJDK 64-Bit Server VM (build 25.40-b14, mixed mode) I'm following the instructions in the log4j section of the Logging in Tomcat section of the Tomcat documentation. The steps do not appear to work, and there is no information in the log file that I can see that would assist me in troubleshooting this. Referencing the steps: 1) I have created log4j.properties in $CATALINA_BASE/lib. The file is readable by the tomcat user. linux:/srv/tomcat/lib # ls -al log4j.properties -rw-r--r-- 1 root root 2343 Jan 21 12:57 log4j.properties 2) I have downloaded log4j 1.2 or later (version 2.1) 3) I have downloaded tomcat-juli-adapters.jar and tomcat-juli.jar 4) I have placed log4j.jar and tomcat-juli-adapters in $CATALINA_HOME/lib linux:/usr/local/apache-tomcat-8.0.17/lib # ls -alh log4j-core-2.1.jar tomcat-juli-adapters.jar -rw-r--r-- 1 root root 806K Jan 21 12:26 log4j-core-2.1.jar -rw-r--r-- 1 root root 32K Jan 21 11:54 tomcat-juli-adapters.jar I have replaced the tomcat-juli.jar in $CATALINA_HOME/bin with the one from the extras directory. linux:/usr/local/apache-tomcat-8.0.17/bin # ls -al tomcat-juli.jar -rw-r--r-- 1 root root 78644 Jan 21 11:55 tomcat-juli.jar 5) N/A 6) I have deleted logging.properties from $CATALINA_BASE/conf 7) I have started tomcat using JSVC with the command: JSVC=/usr/local/bin/jsvc $JSVC \ -cp $CATALINA_HOME/bin/bootstrap.jar:$CATALINA_HOME/bin/tomcat-juli.jar \ -home $JDK_HOME \ -user $TC_USER \ -outfile $CATALINA_BASE/logs/catalina.out \ -errfile $CATALINA_BASE/logs/catalina.err \ -pidfile $PIDFILE \ -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager \ -Dorg.apache.juli.ClassLoaderLogManager.debug=true \ -Dcatalina.base=$CATALINA_BASE \ -Dcatalina.home=$CATALINA_HOME \ -Djava.io.tmpdir=$CATALINA_BASE/temp \ -Djava.awt.headless=true \ -Dcatalina.port=$CATALINA_PORT \ -Dmail.smtp.localhost=$FQDNHOSTNAME \ $JAVA_MEM_OPTIONS \ org.apache.catalina.startup.Bootstrap start Examination of the $CATALINA_BASE/logs directory shows: linux:/srv/tomcat/logs # ls -al total 12 drwxrws--- 1 root tomcat 186 Jan 21 12:57 . drwxr-x--- 1 root tomcat90 Jan 21 12:56 .. -rw--- 1 root tomcat 11912 Jan 21 12:57 catalina.err -rw--- 1 root tomcat 0 Jan 21 12:57 catalina.out -rw-r--r-- 1 tomcat tomcat 0 Jan 21 12:57 localhost_access_log.2015-01-21.txt There are no mentions of log4j in catalina.err. If someone could point me in the right direction, I would appreciate it. Thanks in advance. -- George Sexton *MH Software, Inc.* Voice: 303 438 9585 http://www.mhsoftware.com
Re: FarmWarDeployer not checking watchDir
On 2015-01-21 00:15, Christopher Schultz wrote: Can you build with an updated patch[1], re-break your directory permissions and re-run Tomcat? Let me know if the log output you get would have led you to a solution more quickly. - -chris I did. Here is the warning I obtained: 21-Jan-2015 12:48:26.160 WARNING [ContainerBackgroundProcessor[StandardEngine[Catalina]]] org.apache.catalina.ha.deploy.WarWatcher.check /my/watch/dir/ROOT.war was detected in /my/watch/dir but does not exist. Check directory permissions on /my/watch/dir? I probably would have found the problem faster with this message, yes. I'll open Can you log a Bugzilla enhancement for this? I'll add some checking to WarWatcher as well as improved logging. I will open it right now. Théo - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: performance (classloader?) problems with signed jars in WEB-INF/lib
That sounds possible. (I haven't looked at the code to check the theory though.) Please open a Bugzilla issue for this so it doesn't get lost. thanks for your reply. I filed a bug for Tomcat 8: https://issues.apache.org/bugzilla/show_bug.cgi?id=57472 I assume your web application is loading a lot of classes from that signed JAR when it starts? Yes. We instantiate (use) only two single classes from that signed jar at startup but that causes many depending classes from that signed jar to be loaded. Best regards, Ole +++ ?ber 5.000 Ausgaben t?glich +++ Mehr als 100 Medienh?user weltweit produzieren t?glich Zeitungen und digitale Angebote mit ppi Media L?sungen +++ Over 5,000 editions daily +++ More than 100 media companies worldwide produce newspapers and digital products with ppi Media's solutions. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SSL issue in tomcat
then may be its not the issue of tomcat.you can check you firewall? may be your firewall dropping the correction after some time. try to connect the server from localhost using openssl s_client -connect hostname:8443 -debug may be you will found something use full. On Wed, Jan 21, 2015 at 11:43 AM, Jason Y day...@gmail.com wrote: Got another issue...Tomcat is working fine after restart but it cannot last long. Now I cannot access https pages with any browsers. I didn't find anything useful in logs. After a restart, it works well again. Connector executor=tomcatThreadPool port=8080 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=8443 / Connector port=8443 protocol=org.apache.coyote.http11.Http11Protocol maxThreads=150 SSLEnabled=true scheme=https secure=true clientAuth=false sslProtocol=TLS sslEnabledProtocols=TLSv1.2,TLSv1.1,TLSv1 keystoreFile=lib/cert/.keystore keystorePass= / !-- Define an AJP 1.3 Connector on port 8009 -- Connector port=8009 protocol=AJP/1.3 redirectPort=8443 / On Wed, Jan 21, 2015 at 10:01 AM, Sanaullah sanaulla...@gmail.com wrote: its not necessary to have ciphers properties but if you want to restrict the ciphers then you can use this property. On Wed, Jan 21, 2015 at 6:53 AM, Jason Y day...@gmail.com wrote: Thank you all. Now it is working fine. Connector port=8443 protocol=org.apache.coyote.http11.Http11Protocol maxThreads=150 SSLEnabled=true scheme=https secure=true clientAuth=false sslProtocol=TLS sslEnabledProtocols=TLSv1.2,TLSv1.1,TLSv1 keystoreFile=lib/cert/.keystore keystorePass= ciphers=TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA / By the way, do I need ciphers properties here? On Tue, Jan 20, 2015 at 11:22 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jason, On 1/20/15 4:17 AM, Jason Y wrote: Recently my application cannot be accessible in browser with https version. I think it is due to vulnerability in ssl 3.0 issue. I checked my tomcat configuration and replaced sslProtocol=TLS with sslEnabledProtocols=TLSv1,TLSv1.1,TLSv1.2 to disable SSL 3.0. Connector port=8080 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=8443 / Connector port=8443 protocol=org.apache.coyote.http11.Http11Protocol maxThreads=150 SSLEnabled=true scheme=https secure=true clientAuth=false sslEnabledProtocols=TLSv1,TLSv1.1,TLSv1.2 keystoreFile=xxx keystorePass=xxx / Connector port=8009 protocol=AJP/1.3 redirectPort=8443 / None of the responses you have gotten thus far are useful in any way. Your configuration looks fine to me: sslEnabledProtocols is the way to go, although in recent versions of Tomcat the default is NOT to include any SSL protocols and only use the TLS ones, so if you are running something recent, you should be okay. Then I can open my application https link in browser. BUT, good time never lasts too long, after several hours, I failed to access my https link again. What kinds of errors do you get? What do the logs say? What are the URLs you are using? Anyone has any ideas about this? please share your suggestions...My tomcat version is 7.0.55 Those SSL/TLS defaults I mentioned above were done in 7.0.57, so you should definitely keep your above configuration. There is no need to add a trust store or cipher specification to that. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUvnKiAAoJEBzwKT+lPKRYQtsP/00rm7rdKVUID9YVQ4WJk3ty JVQa/g0Kg4prYC+w5AFvZaiDK6EC014GKoTz4ktUzY4Ubnyd3vxsRTV+6/JOig0J C9HcXKEZf63KS2uro71ymXNH0glDGJWtkCeTLR60elBUnyoOIat6ifQ9DqbH9BGT nxJLRq4GZg8aaqKqToJNREY/6nX09+qmPYgpvzrdNlhDgxdb97o9hEPPQA85DMmG mDMyP/TdnIcOdYa8n94/yFjaLQBqCAMl7li2VugbVMkSZMriz/NXnr52xTvZsFtH 8x4D5z5AzU+8+3P+vULmogW6418igLLWZHf03FAh2Wh5RKmvqKjaMzhC9qACYooJ T7F1QfCZVqsEd5edzP17sUPjG62A1awwfMHB3/qmMpWz+Fde4taz2t+Pz652fugw HrfhERRjkdpogfHmrAhBgZ/r89GpYlqEvMguW2PW6zL/ku51wx+aMfujrXO63+ZM 9psUeSvsR823foOYa6C3UV3MFbGWE7awUWuIBQi1bOxsP/ldKvEESGtdu9GpLHw7 A/5fyZ2a6+99HC56lvraGvPi+5ZI52Ej1mR0Ckk9RHRWqoCApTYsCzAPWd5Fntuq zuNoyI6onNFKNDZ+17Nm55rywgHR/5hh5CLbf1PwSJRw2mJXbEnoXXUo1XoCS+Oo G5/ksEFNFSc9+yQSSC1H =PVop -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SSL issue in tomcat
Here is what I get with openssl s_client command: Loading 'screen' into random state - done CONNECTED(01E8) write to 0x2103650 [0x2103698] (124 bytes = 124 (0x7C)) - 80 7a 01 03 01 00 51 00-00 00 20 00 00 39 00 00 .zQ... ..9.. 0010 - 38 00 00 35 00 00 16 00-00 13 00 00 0a 07 00 c0 8..5 0020 - 00 00 33 00 00 32 00 00-2f 00 00 07 05 00 80 03 ..3..2../... 0030 - 00 80 00 00 05 00 00 04-01 00 80 00 00 15 00 00 0040 - 12 00 00 09 06 00 40 00-00 14 00 00 11 00 00 08 ..@. 0050 - 00 00 06 04 00 80 00 00-03 02 00 80 2b 20 ff a2 + .. 0060 - dc 75 81 67 91 ff 8a 7e-8e 37 ed ac f6 97 0e 83 .u.g...~.7.. 0070 - 66 46 8c 87 b8 1c b3 0a-7e 46 72 30 fF..~Fr0 read from 0x2103650 [0x2108bf8] (7 bytes = 7 (0x7)) - 15 03 01 00 02 02 28 ..( 13756:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:.\ssl\s23_clnt.c:596: On Wed, Jan 21, 2015 at 4:49 PM, Sanaullah sanaulla...@gmail.com wrote: then may be its not the issue of tomcat.you can check you firewall? may be your firewall dropping the correction after some time. try to connect the server from localhost using openssl s_client -connect hostname:8443 -debug may be you will found something use full. On Wed, Jan 21, 2015 at 11:43 AM, Jason Y day...@gmail.com wrote: Got another issue...Tomcat is working fine after restart but it cannot last long. Now I cannot access https pages with any browsers. I didn't find anything useful in logs. After a restart, it works well again. Connector executor=tomcatThreadPool port=8080 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=8443 / Connector port=8443 protocol=org.apache.coyote.http11.Http11Protocol maxThreads=150 SSLEnabled=true scheme=https secure=true clientAuth=false sslProtocol=TLS sslEnabledProtocols=TLSv1.2,TLSv1.1,TLSv1 keystoreFile=lib/cert/.keystore keystorePass= / !-- Define an AJP 1.3 Connector on port 8009 -- Connector port=8009 protocol=AJP/1.3 redirectPort=8443 / On Wed, Jan 21, 2015 at 10:01 AM, Sanaullah sanaulla...@gmail.com wrote: its not necessary to have ciphers properties but if you want to restrict the ciphers then you can use this property. On Wed, Jan 21, 2015 at 6:53 AM, Jason Y day...@gmail.com wrote: Thank you all. Now it is working fine. Connector port=8443 protocol=org.apache.coyote.http11.Http11Protocol maxThreads=150 SSLEnabled=true scheme=https secure=true clientAuth=false sslProtocol=TLS sslEnabledProtocols=TLSv1.2,TLSv1.1,TLSv1 keystoreFile=lib/cert/.keystore keystorePass= ciphers=TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA / By the way, do I need ciphers properties here? On Tue, Jan 20, 2015 at 11:22 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jason, On 1/20/15 4:17 AM, Jason Y wrote: Recently my application cannot be accessible in browser with https version. I think it is due to vulnerability in ssl 3.0 issue. I checked my tomcat configuration and replaced sslProtocol=TLS with sslEnabledProtocols=TLSv1,TLSv1.1,TLSv1.2 to disable SSL 3.0. Connector port=8080 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=8443 / Connector port=8443 protocol=org.apache.coyote.http11.Http11Protocol maxThreads=150 SSLEnabled=true scheme=https secure=true clientAuth=false sslEnabledProtocols=TLSv1,TLSv1.1,TLSv1.2 keystoreFile=xxx keystorePass=xxx / Connector port=8009 protocol=AJP/1.3 redirectPort=8443 / None of the responses you have gotten thus far are useful in any way. Your configuration looks fine to me: sslEnabledProtocols is the way to go, although in recent versions of Tomcat the default is NOT to include any SSL protocols and only use the TLS ones, so if you are running something recent, you should be okay. Then I can open my application https link in browser. BUT, good time never lasts too long, after several hours, I failed to access my https link again. What kinds of errors do you get? What do the logs say? What are the URLs you are using? Anyone has any ideas about this? please share your suggestions...My tomcat version is 7.0.55 Those SSL/TLS defaults I mentioned above were done in 7.0.57, so you should definitely keep your above configuration. There is no need to add a trust store or cipher specification to that. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools -
Re: SSL issue in tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jason, On 1/20/15 8:53 PM, Jason Y wrote: Thank you all. Now it is working fine. Connector port=8443 protocol=org.apache.coyote.http11.Http11Protocol maxThreads=150 SSLEnabled=true scheme=https secure=true clientAuth=false sslProtocol=TLS sslEnabledProtocols=TLSv1.2,TLSv1.1,TLSv1 keystoreFile=lib/cert/.keystore keystorePass= ciphers=TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA / By the way, do I need ciphers properties here? Usually, no. Your JRE has a set of supported ciphers and a subset of those are enabled by default. Tomcat will remove a subset of ciphers known to always be a bad idea (e.g. NULL). Tomcat 8 and trunk since about 6 months ago have had support for OpenSSL-style ciphers definitions, where you don't have to specify the exact set of ciphers you want. Instead, you can describe those ciphers which you do and do not want, and let those filters run against the ciphers supported by the JVM. - -chris On Tue, Jan 20, 2015 at 11:22 PM, Christopher Schultz ch...@christopherschultz.net wrote: Jason, On 1/20/15 4:17 AM, Jason Y wrote: Recently my application cannot be accessible in browser with https version. I think it is due to vulnerability in ssl 3.0 issue. I checked my tomcat configuration and replaced sslProtocol=TLS with sslEnabledProtocols=TLSv1,TLSv1.1,TLSv1.2 to disable SSL 3.0. Connector port=8080 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=8443 / Connector port=8443 protocol=org.apache.coyote.http11.Http11Protocol maxThreads=150 SSLEnabled=true scheme=https secure=true clientAuth=false sslEnabledProtocols=TLSv1,TLSv1.1,TLSv1.2 keystoreFile=xxx keystorePass=xxx / Connector port=8009 protocol=AJP/1.3 redirectPort=8443 / None of the responses you have gotten thus far are useful in any way. Your configuration looks fine to me: sslEnabledProtocols is the way to go, although in recent versions of Tomcat the default is NOT to include any SSL protocols and only use the TLS ones, so if you are running something recent, you should be okay. Then I can open my application https link in browser. BUT, good time never lasts too long, after several hours, I failed to access my https link again. What kinds of errors do you get? What do the logs say? What are the URLs you are using? Anyone has any ideas about this? please share your suggestions...My tomcat version is 7.0.55 Those SSL/TLS defaults I mentioned above were done in 7.0.57, so you should definitely keep your above configuration. There is no need to add a trust store or cipher specification to that. -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 v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUv74eAAoJEBzwKT+lPKRYxj8QAKyYHwuggY3NwO9HYmxPBFva kMH5c0DC8VzN+XiIaCvHr16OdwKFHKMtWyP4JI8J3PkPOhxreRhM31vz8hiK2TfE hyVOJxMAwqUSAMeuDuacSQG933ORc184iLgNbgOr15zGmfwyS5EHMFQjEO5m/HtI nJ54IWv0PPBJfYegNljd+qAai/At9iWBwmi5woO8evMaQK9WnokjcLZNAmKhKyX7 hvAbcBQFpNoPoI1dvOn/00Ke/GRu/KGVed1pikTVA8D5u75esxG6ZGf2ZX3GpbMk oSXwVxXLXY9yb6zcSxSKLdEjIO/kNFRHF6PYO7oxFtK9VH/NLpzPJWFszq53lxRt L5x03FkOqjX11tTgNedMSTKA9KrWiFhqXaa+0CPtaFfUKKaqnEIrlcN7mzrNaICo s7zpBHr19nLjMcEdbxIEWHMlWi1eA9S7yQihZIk7cilCuGQ5cwaHkSFjKcZl575D wwhuNLiRRbhXBqQeOoqEqsP4cX2IkV1SsOuCarLtQkdetDmFP/kicef125H1IIER ejFAaazbb+Ucz6/y1XuD19Q5hcKzvGxnwGo0hp1vqoq5PmZOUiG3tzX6KflfpFIt VLBrxsXWyJcsKWigixtxCIZ9oyQHB+4B17DkZjfC75a9y8rkh2e8nYpCXEBqYj4K /CrvXq2r1sQRtM7LN5vM =Luq1 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SSL issue in tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jason, On 1/21/15 4:29 AM, Jason Y wrote: Here is what I get with openssl s_client command: Loading 'screen' into random state - done CONNECTED(01E8) write to 0x2103650 [0x2103698] (124 bytes = 124 (0x7C)) - 80 7a 01 03 01 00 51 00-00 00 20 00 00 39 00 00 .zQ... ..9.. 0010 - 38 00 00 35 00 00 16 00-00 13 00 00 0a 07 00 c0 8..5 0020 - 00 00 33 00 00 32 00 00-2f 00 00 07 05 00 80 03 ..3..2../... 0030 - 00 80 00 00 05 00 00 04-01 00 80 00 00 15 00 00 0040 - 12 00 00 09 06 00 40 00-00 14 00 00 11 00 00 08 ..@. 0050 - 00 00 06 04 00 80 00 00-03 02 00 80 2b 20 ff a2 + .. 0060 - dc 75 81 67 91 ff 8a 7e-8e 37 ed ac f6 97 0e 83 .u.g...~.7.. 0070 - 66 46 8c 87 b8 1c b3 0a-7e 46 72 30 fF..~Fr0 read from 0x2103650 [0x2108bf8] (7 bytes = 7 (0x7)) - 15 03 01 00 02 02 28 ..( 13756:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:.\ssl\s23_clnt.c:596: Use this: $ openssl s_client -tls1 -connect host:port If you want to be able to handle SSL2/3 handshakes, then you will want to enable SSLv2hello using the sslProtocolsEnabled attribute, like this: Connector [...] sslProtocol=TLS sslEnabledProtocols=TLSv1.2,TLSv1.1,TLSv1,SSLv2hello / - -chris On Wed, Jan 21, 2015 at 4:49 PM, Sanaullah sanaulla...@gmail.com wrote: then may be its not the issue of tomcat.you can check you firewall? may be your firewall dropping the correction after some time. try to connect the server from localhost using openssl s_client -connect hostname:8443 -debug may be you will found something use full. On Wed, Jan 21, 2015 at 11:43 AM, Jason Y day...@gmail.com wrote: Got another issue...Tomcat is working fine after restart but it cannot last long. Now I cannot access https pages with any browsers. I didn't find anything useful in logs. After a restart, it works well again. Connector executor=tomcatThreadPool port=8080 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=8443 / Connector port=8443 protocol=org.apache.coyote.http11.Http11Protocol maxThreads=150 SSLEnabled=true scheme=https secure=true clientAuth=false sslProtocol=TLS sslEnabledProtocols=TLSv1.2,TLSv1.1,TLSv1 keystoreFile=lib/cert/.keystore keystorePass= / !-- Define an AJP 1.3 Connector on port 8009 -- Connector port=8009 protocol=AJP/1.3 redirectPort=8443 / On Wed, Jan 21, 2015 at 10:01 AM, Sanaullah sanaulla...@gmail.com wrote: its not necessary to have ciphers properties but if you want to restrict the ciphers then you can use this property. On Wed, Jan 21, 2015 at 6:53 AM, Jason Y day...@gmail.com wrote: Thank you all. Now it is working fine. Connector port=8443 protocol=org.apache.coyote.http11.Http11Protocol maxThreads=150 SSLEnabled=true scheme=https secure=true clientAuth=false sslProtocol=TLS sslEnabledProtocols=TLSv1.2,TLSv1.1,TLSv1 keystoreFile=lib/cert/.keystore keystorePass= ciphers=TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA / By the way, do I need ciphers properties here? On Tue, Jan 20, 2015 at 11:22 PM, Christopher Schultz ch...@christopherschultz.net wrote: Jason, On 1/20/15 4:17 AM, Jason Y wrote: Recently my application cannot be accessible in browser with https version. I think it is due to vulnerability in ssl 3.0 issue. I checked my tomcat configuration and replaced sslProtocol=TLS with sslEnabledProtocols=TLSv1,TLSv1.1,TLSv1.2 to disable SSL 3.0. Connector port=8080 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=8443 / Connector port=8443 protocol=org.apache.coyote.http11.Http11Protocol maxThreads=150 SSLEnabled=true scheme=https secure=true clientAuth=false sslEnabledProtocols=TLSv1,TLSv1.1,TLSv1.2 keystoreFile=xxx keystorePass=xxx / Connector port=8009 protocol=AJP/1.3 redirectPort=8443 / None of the responses you have gotten thus far are useful in any way. Your configuration looks fine to me: sslEnabledProtocols is the way to go, although in recent versions of Tomcat the default is NOT to include any SSL protocols and only use the TLS ones, so if you are running something recent, you should be okay. Then I can open my application https link in browser. BUT, good time never lasts too long, after several hours, I failed to access my https link again. What kinds of errors do you get? What do the logs say? What are the URLs you are using? Anyone has any ideas about this? please share your suggestions...My tomcat version is 7.0.55 Those SSL/TLS defaults I mentioned above were done in 7.0.57, so you should definitely keep your above configuration. There is no need to add a trust store or cipher specification to that. -chris - To
Re: [ANN] Apache Tomcat 8.0.17 available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Leo, On 1/20/15 10:29 PM, Leo Donahue wrote: On Tue, Jan 20, 2015 at 9:24 PM, Leo Donahue donahu...@gmail.com wrote: On Tue, Jan 20, 2015 at 5:09 PM, Mark Thomas ma...@apache.org wrote: The Apache Tomcat team announces the immediate availability of Apache Tomcat 8.0.17. - The RemoteAddrValve and RemoteHostValve can now optionally include the port when filtering along with a new option to trigger authentication rather than denying access And if they are Valves, why do the docs still use the word Filter? Remote Address Filter? Both flavors exist: Valve and Filter. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUv7/bAAoJEBzwKT+lPKRY4ksQAI9AkOUmSPjr3xiuQTC9KkC7 qdRzIk8K068OMq/FFMHHDv3wcFpyzvPDnUYqiUG6WXHAUFxkKbijALDYyaO4kWpj h9ZTCQS7KvUpfYYpyhjkeByYTbDy11MxED7HZdgMS8mE+8FJCvPkgxvhfkDqLtmX TWABaIThKAbWLQ5wzC/igywfTq4FxQu83jKZhZOz/KO0p/IzsaeFGiUwu2rfjMu7 dVtQIxaMURu5Jurk7nQ84J7cndO96LoFfXRmAHRqsw+7HpwWs+r2ZfdjBOay//O2 ptcvEcFMgDrVvg3Q2GH22RGxw2QYzmPq6V4pFxQwbgwmtbt0868qFhubM5ITAnE7 2K0/x7UqKMqRTNZn3v9FA3eTChJlBl6VhhstBfAq5TaCJYQvJPX1rmJzSsUWSFwt BFbPepgxP00SXMa0pDVIHrUxHViX2d4VZEK7bXUDhyoJPFhseCunmlnoCfovGZDY C2IGs8LRgn+NM3q8MZHRv/OIThimZ6zqVG6cpEQx/I4vYISr2t8TlW6LIjj6+ARN GRne/U1cpRpZdVuLCnNKIRz88wZsbOs14mKlYI1/f4tvtd6nzVIi+L5OXOumtik2 7BWZrmW4GNVmJbMcAzpVNCaLz/kkt7fw+hmEodcDnXBpVKQxOPRDMXJrDKBUzepH 22GINdxfw6szFyKmqQr2 =Wnjb -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
