Re: JDBC Fails to connect to SQL Server
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Aniket, On 1/30/15 10:01 AM, Aniket Bhoi wrote: I have Apache Solr hosted on Tomcat 6. There have been no changes to the code on Tomcat whatsoever.However for the last few days I now see this error in the Log files: SEVERE: Full Import failed Throwable occurred: org.apache.solr.handler.dataimport.DataImportHandlerException: Unable to execute query: SELECT ID, ENTRY_TYPE_REF, PROFILE_REF, ITEM_REF, TITLE, ABSTRACT, SOLUTION, SOLUTION_HTML, FREE_TEXT, DATE_UPDATED, ENTRY_TYPE, PROFILE_TYPE, SERVICE_TYPE FROM INFRA_KO_V Processing Document # 1 [snip] *Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: The driver could not establish a secure connection to SQL Server by using Secure Sockets Layer (SSL) encryption. Error: SQL Server did not return a response. The connection has been closed..* at com.microsoft.sqlserver.jdbc.SQLServerConnection.terminate(SQLServerConnection.java:1368) at com.microsoft.sqlserver.jdbc.TDSChannel.enableSSL(IOBuffer.java:1412) What does your Resource definition look like in either server.xml or (better) context.xml? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUy7o3AAoJEBzwKT+lPKRYYuIP/jxc0viCEoNKl+rXg5i7FrnZ 1LSYOevInM8aWB8Fm5gnzTJ0zv/VFAcNGUaqwrAcVNNy2P2o5J+Jb2RrODF3JvXP HuCdwyOkSQLfEtFN4jtkhcjPL+54NVDFybVsDDY1/030X4wHgI7vB2upsdeAD5/H Sa73iHE5K3sM6aUmoxrzQLcB3riokCDzuA1tqxcYDEugcJ+wcmvULd8oc2DNKh0V hAa4S9vVR4Uy+x+C81gUVFYr62jghpHPajOdbF88Yryko8lhfASSvawMk0qKWLQ4 Tf0FY72Hcp7aW/bgVD44CUtvhjpY6j70QJCWE4rHq9/5T04fFPkYOZgxExj0GInX 6NfNb6JUDW88AkbpS3NXlxa6YZuyquQu42yyFZsze/jbpUrUfBXOjWD0JRQ9kHpe XfjTNMOeeMmYLDLR86nMKuamUukwexFgpTLvdr/iCf0qtJUViBitVL5U8ALoAJdb b0u/Wq93TXKP8TKh8gP1vWN0Sa29d7e/8W88cGWnHerugJRamGSGmFcbClOL/S77 +CMpzLsPo6w9lBMNp8i0nUkJYc+4VkkrVziS0rv6etUsCfaZw6k9W6hFW6QIq3vo FcWpa5r5zFaTG+7NhIyvJmBykPUSBycHE5tDqGIMRHzNRsSWXCyRkTb9DMr0JJSy IdXis+j60OPCTlFbBCkC =+aqL -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat-jdbc PoolCleaner deadlock
Am 30.01.2015 um 18:19 schrieb Robert Anderson: Every day we are getting deadlocks like that: Found one Java-level deadlock: = ajp-apr-8009-exec-13 ^ 30/01/2015 - 09:39:58 - DB:DATASOURCE(java:/comp/env/jdbc/cacheapp): waiting to lock monitor 0x1504e6d8 (object 0x00071ba001d0, a com.intersys.jdbc.CacheConnection), which is held by PoolCleaner[1070846187:1422601344160] PoolCleaner[1070846187:1422601344160]: waiting to lock monitor 0x12ce77e8 (object 0x00071ba007f0, a com.intersys.jdbc.CacheConnection$MessageCount), which is held by ajp-apr-8009-exec-13 ^ 30/01/2015 - 09:39:58 - DB:DATASOURCE(java:/comp/env/jdbc/cacheapp) Could you post a full stacktrace, or threaddump? Are there any exceptions logged before? Regards Felix Are there anything that we can do to avoid it? Server version: Apache Tomcat/7.0.57 Server built: Nov 3 2014 08:39:16 UTC Server number: 7.0.57.0 OS Name:Linux OS Version: 2.6.18-194.17.1.el5 Architecture: amd64 JVM Version:1.7.0_71-b14 JVM Vendor: Oracle Corporation Datasource definition: Resource name=jdbc/cacheapp auth=Container type=javax.sql.DataSource removeAbandoned=true removeAbandonedTimeout=300 maxActive=120 maxIdle=20 minIdle=1 maxWait=1 validationQuery=select 1 testOnBorrow=true validationInterval=0 fairQueue=false factory=org.apache.tomcat.jdbc.pool.DataSourceFactory alternateUsernameAllowed=true username=user password=password driverClassName=com.intersys.jdbc.CacheDriver url=jdbc:Cache://myserver:1972/Namespace/ Thanks in advance. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: org.apache.catalina.startup.Catalina.process(args)... method in Tomcat 6 but not 7 nor 8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Terry, On 1/22/15 11:52 PM, Terry Medearis wrote: So, I understand that the Tomat class has been introduced, but is there anything in the Catalina class that remains that can be utilized in place of the .process method? Sorry, I'm not en expert in embedded use of Tomcat. Maybe my reply will get this back on someone else's radar? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUy703AAoJEBzwKT+lPKRYqa4QAI3PePCGnPVEUDOgsHP/Bo6x Tkwmezdq3+XyZM8+Y+oIty+NH7MOMy6NrLsgla436yf6+zrkHXzY2x8y2iIZ7e0L MdHeVyZ+0Blf8lcPI8t4FGjrD7ZROADG3TIqVFIRawLUb9eWeG+be1A6cGqSK3Cd WKl2i7uoD5kMruuTnXvlrR+aays2H090Horg+XHCexqsD+o56kYy//fzj6w+uuqC YT/SHVv5Qv/WnCt/A4BH1QAJh/9N05qt/Yew6hvFXfGpl+l+nZOCjxwXksjqgMtD t5yiZQQzO3F/8HJkTU+OZUv2wBYVamhzeWOofLxStdze3791jT+KaO+Dyiq5qB98 Qu7pL8z86V8p0JF5Lv60N+9hDMiLbioWNeypsQ72DWP5kfmjucbjCNXSDKpso/Cn HDiRcBcVMKiKAPnUcCl1o7b02vO0H7LXZ+cHgcMsgp8fuKQ/tfMKeVfShZhq9GJS rciCZyvbjadgTtsixol8qZcllDyk0p/zZjuLGdHOKKe71B3ePjAuCPXriLHEsKBV cQusvcD47fjN4H7ul1iJPgI+GU6+jw7ccXaoW5WOjKo9DLBQXpXmLMswA+XNIMtE FGE9GBIG/SFsKBmGp3X06Bep5E73alBxVfLzEzTMGFdM/mSdobYCGvuGdWdlVkqC nvNbPzdjmcB8/FsInCMJ =qHoW -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Session being dropped in Virtual Host in 8.0.9
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Rory, On 1/30/15 11:01 AM, Rory Kelly wrote: I apologise in advance if the formatting is absolutely terrible. Actually, it was totally readable ;) Are you using cookies for session-tracking? Can you watch the HTTP conversation to see what's being sent back and forth during that workflow? LiveHttpHeaders is great for Firefox, and these days Chrome, Firefox, and IE have something similar built-into them. From the looks of it, the cookie is storing the session ID. Server - nginx/1.6.2 (Ubuntu) Date - Fri, 30 Jan 2015 15:52:35 GMT Content-Type - text/html;charset=utf-8 Transfer-Encoding - chunked Connection - keep-alive Cache-Control - no-cache, no-store, must-revalidate, max-age=0 X-XSS-Protection - 1; mode=block x-content-type-options - nosniff x-frame-options - SAMEORIGIN Set-Cookie - ib=da7f36e0f53827383a262940d2f75fcef8bbb32b57bd3fced7149ae6a8bf4e3a; path=/; expires=Fri, 30 Jan 2015 15:57:35 -; HttpOnly Content-Encoding - gzip Everything in the HTTP requests seem fine, except the response from my POST at the Challenge point, where, instead of a 200, I'm receiving a 302. This is what tipped me off that it was the session that was causing the issue. This is only one response from the server, and it's not clear what the request was. Can you post: 1. Request to protected resource (and response) 2. Request to login page (and response) 3. Request which is the submission of the login form (and response) ... and it sounds like here is where the session is lost 4. The next request, which evidently has lost the session (and response) field... or at least whatever your clients DNS will resolve to your server. That may actually be virtual1 but I just thought I'd mention it. It shouldn't have any bearing on the session-handling, unless your web application switches hostnames by telling a client requesting virtual1 that it should redirect to testsitex.site.io or vice-versa. I went ahead and changed this as well, as it does seem like a good practice to use. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUy7ysAAoJEBzwKT+lPKRYvhIQAKyd2NgVsXPYh83RfvEGneW2 jKvc1BwRZMntweaFFX8mJ8jih+eLncTZlYo2OyqyUGYfiZS54us+yjUh11UmAVZx Qpb9nGDL2YRnM5yTyyYxW2FRXzzwexIvIkGj9w/DoBbiNh8PMWhZxTKXX/X9xsqL pPJrRxufz7bIzwLmfk3zxwwRXLtip5nhU+EHOOPn0rIs3w6kt7C87D/oLnLp/MOc sfLTcNy/espidpAs2O4KNtrCYZ4Ou8+EoW+KKBYyAtlmd4kQgPG5tPfSR/2FM0Ji mk+mfnJ3eoYcjeIapmLajvZ10zrNWSsrlmxdo0KTnxss9cnZ7C/lKmdy2HsS3bYF Hm1i30GTtvZRLgEZjpinGRck+4QDZSuSLwNdirbex7oSzyxC88UviRvPjMq+bvcR wfbFYuE6GplSKKmWWj3a4slcdEsXEguvtVPCHdSBmn5/lWxbTRmw68khKV8yhzbQ hO5eQoErK0ZoijmwxNSjZRcxJMPpgPzN+JtH8Rq/4L19JAdEqJCvWOPU86/iqr1i uebkQCDYYXyAtrTClcB8vJ5kiBHfcYuy11O8uPQvv097QFEMHXbimYTmgDlPBYDz vtRHAdirjm7393Lp8ko9cn4yeFlsyVHJocbMWADWIB+1cpDfGfDPA0dFwqE2HU4b IMuJLhaHW22aHIn5OIHu =KoLf -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
tomcat-jdbc PoolCleaner deadlock
Every day we are getting deadlocks like that: Found one Java-level deadlock: = ajp-apr-8009-exec-13 ^ 30/01/2015 - 09:39:58 - DB:DATASOURCE(java:/comp/env/jdbc/cacheapp): waiting to lock monitor 0x1504e6d8 (object 0x00071ba001d0, a com.intersys.jdbc.CacheConnection), which is held by PoolCleaner[1070846187:1422601344160] PoolCleaner[1070846187:1422601344160]: waiting to lock monitor 0x12ce77e8 (object 0x00071ba007f0, a com.intersys.jdbc.CacheConnection$MessageCount), which is held by ajp-apr-8009-exec-13 ^ 30/01/2015 - 09:39:58 - DB:DATASOURCE(java:/comp/env/jdbc/cacheapp) Are there anything that we can do to avoid it? Server version: Apache Tomcat/7.0.57 Server built: Nov 3 2014 08:39:16 UTC Server number: 7.0.57.0 OS Name:Linux OS Version: 2.6.18-194.17.1.el5 Architecture: amd64 JVM Version:1.7.0_71-b14 JVM Vendor: Oracle Corporation Datasource definition: Resource name=jdbc/cacheapp auth=Container type=javax.sql.DataSource removeAbandoned=true removeAbandonedTimeout=300 maxActive=120 maxIdle=20 minIdle=1 maxWait=1 validationQuery=select 1 testOnBorrow=true validationInterval=0 fairQueue=false factory=org.apache.tomcat.jdbc.pool.DataSourceFactory alternateUsernameAllowed=true username=user password=password driverClassName=com.intersys.jdbc.CacheDriver url=jdbc:Cache://myserver:1972/Namespace/ Thanks in advance.
Re: tomcat-jdbc PoolCleaner deadlock
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Robert, On 1/30/15 12:19 PM, Robert Anderson wrote: Every day we are getting deadlocks like that: Found one Java-level deadlock: = ajp-apr-8009-exec-13 ^ 30/01/2015 - 09:39:58 - DB:DATASOURCE(java:/comp/env/jdbc/cacheapp): waiting to lock monitor 0x1504e6d8 (object 0x00071ba001d0, a com.intersys.jdbc.CacheConnection), which is held by PoolCleaner[1070846187:1422601344160] PoolCleaner[1070846187:1422601344160]: waiting to lock monitor 0x12ce77e8 (object 0x00071ba007f0, a com.intersys.jdbc.CacheConnection$MessageCount), which is held by ajp-apr-8009-exec-13 ^ 30/01/2015 - 09:39:58 - DB:DATASOURCE(java:/comp/env/jdbc/cacheapp) D'oh. Are there anything that we can do to avoid it? Server version: Apache Tomcat/7.0.57 Server built: Nov 3 2014 08:39:16 UTC Server number: 7.0.57.0 OS Name:Linux OS Version: 2.6.18-194.17.1.el5 Architecture: amd64 JVM Version: 1.7.0_71-b14 JVM Vendor: Oracle Corporation Datasource definition: Resource name=jdbc/cacheapp auth=Container type=javax.sql.DataSource removeAbandoned=true removeAbandonedTimeout=300 maxActive=120 maxIdle=20 minIdle=1 maxWait=1 validationQuery=select 1 testOnBorrow=true validationInterval=0 In general, I would expect validationInterval=0 to disable validation, but the documentation does not say anything about a zero value. Is it possible that you are /constantly/ validating? If you change that number to something higher (in ms: maybe 1 for 10s) you will reduce the chance for this deadlock? I suspect this is a bug (deadlock should not occur), but you can maybe avoid it by changing your configuration. fairQueue=false There is a flaw in the documentation surrounding this setting on Linux, but it's only when fairQueue=true, so it shouldn't matter for you. But you might want to consider leaving the queue fair. It's not clear from the documentation whether enabling queue fairness /decreases/ performance or the opposite (but it seems reasonable that enforcing queue fairness would probably decrease performance). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUy7/vAAoJEBzwKT+lPKRYCGwP/ijUIjnHQ39rE6qzZ9GIGwad ZkGQTFZlZw03yxkcu9Dzqb7LdN/RWHaHzi5jZyWkJnz7SO6EIe9gyUya2kvojF4x 9u3+TrDT/+fTQd17UvEuKAzRqV56PGFdfWGMNlQmk1ndOQYFRwD6B3vFF0SCMbw0 q0Z5qIHw5YqgVg+xfsA/ubsrOX8prI0c0AzgN8yFd5Jv+Ts80rD4PNr1kfN+K6oE N2komJkEEn3PpSSFdhut3FPcZZingm5xiV/2u5hwOOvHhAZIG7qpP0RwEDN2fPRd MEC1j0dO2k+JZW8PC5RWPGyqEg9F+213sw8Qc8idOf2zHNXYwzxtZcD8i+iokYLS 8Tn5ByYRgX5ZEdTA1e1DUIM6BTRgA+HX30T5lRBOBFC9/baKcrRVR9tS9gn9zQBj HV1Xfoy6V/efL7AHAOd1nPL+SswzVYs2U0HtOOA4MjYLguhuRNPx3ofWufESXJ1T 5n6h7ipN1mda8LcMtK3bVSrBfL+SnU5p7bwmQvtRX33xeKMOgv8XnWWaFc1eWLHg yrS6KZSVUhIHlLwy2tBJasWB2VtxcEOoSjOWJfHBgPIsAp3TcwyNbNZ3JVDAMW1D 8kjmDJnBguuHbz+tn4qabPB8TmcO/78GrcOr+qY42IjIJQM4kX0otXzngh+nI21z Fm3UQnSzGs29jQCwe5Ho =v9Pk -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: FIPS Mode enabling on Tomcat 7.00.057
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Geet, On 1/30/15 1:22 AM, Geett Chanddra Singha wrote: Steps followed to build FIPS tar zxf openssl-1.0.1l.tar.gz cd openssl-1.0.1l ./config --prefix=/usr/local --with-fipsdir=/usr/local/ssl/fips-2.0 make make install Note: I have installed the FIPS module in /usr/local/ssl/fips-2.0 You have to do ./config fips --with--fipsdir=[...]. You are missing the fips argument to config. After I did the config, it told me that I needed to first make depend. Then I did a regular make and got a FIPS-capable module (as tested by doing: $ cd test $ sh ./testfipsssl (Note that this test fails part way through because it's missing some kind of fake certificate... it looks like a problem with the test itself). I ran the test without building with FIPS and it died right away, so I'm confident I ended up with a FIPS-capable module: $ sh ./testfipsssl WARNING: can't open config file: /usr/local/ssl/openssl.cnf test ssl3 is forbidden in FIPS mode *** IN FIPS MODE *** Available compression methods: NONE 140652183557800:error:140A9129:SSL routines:SSL_CTX_new:only tls allowed in fips mode:ssl_lib.c:1715: 140652183557800:error:140A9129:SSL routines:SSL_CTX_new:only tls allowed in fips mode:ssl_lib.c:1715: test ssl2 is forbidden in FIPS mode *** IN FIPS MODE *** Available compression methods: NONE 139882949523112:error:140A9129:SSL routines:SSL_CTX_new:only tls allowed in fips mode:ssl_lib.c:1715: 139882949523112:error:140A9129:SSL routines:SSL_CTX_new:only tls allowed in fips mode:ssl_lib.c:1715: test tls1 *** IN FIPS MODE *** Available compression methods: NONE TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA 1 handshakes of 256 bytes done test tls1 with server authentication *** IN FIPS MODE *** Available compression methods: NONE server authentication depth=0 error=20 /C=UK/O=OpenSSL Group/OU=FOR TESTING PURPOSES ONLY/CN=Test Server Cert Error string: unable to get local issuer certificate ERROR in CLIENT 140515612989096:error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed:s3_clnt.c:1162: TLSv1, cipher (NONE) (NONE) 1 handshakes of 256 bytes done $ cd .. $ ./apps/openssl version WARNING: can't open config file: /usr/local/ssl/openssl.cnf OpenSSL 1.0.1l-fips 15 Jan 2015 (Man... OpenSSL really is a big ball of crap: you have to be in the exact right directory for everything to work. It's amazing that these guys don't fix stuff like that. I like scripting everything, and having to do a cd in a script usually means that it's going to be hard to do things properly.) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUy7PaAAoJEBzwKT+lPKRYAqcQAI+So5gWQYfh166f1V30jrR4 IqWHGvwxUYjIRPeuwu6V0tTVgAkwcspRiMapLWOIpSojrr+9jysj2N85EOVSpg+r yIkc7dJmDgvaQ025u6bhnCby8YwupVmoyQKuiR4CzQb+ZjZIaDgp0l4XEyP/DxTy UDD/CnXvJE/Fgp6lwnOcLygOYuPwGq0cDMcJEW5RT9TMfp8T0yLgOoC8NOuYp4q5 Buywt9adAjNYZR1xREIKgRzEXEalFuI2dA4XyIV55Pye00dsAufsBj/uLhv4xAva XU3qbHnHSnycfiipGjW60ZM0zJqLtszx3Q26luElCbv9QqOAyf68+QV4cYVhI2rY 6SefnQZ2mCQKDs15+aYyB093zveQxKLkVIHyYsbHLpe0oPBUp0f8cy5UVRZnmtE+ H8IXxG3jaz6mG15DYF6IXyg/GVlHMS+RQdoD2c0sNN+WtY0g+7kbcNLcrjwvsei0 nKm6lnWXDUT4u8ggp5h+XDSbf1RzyxMyl6B9EwFW39rgmOnTtYIJjW7N8TxvcxvI 5LBEUJUcVSi2kb3tiWNHdcEeT5cnk8Woy3Tyoi+OrdcDoawz7x8o8sroXHgXogxN Zm5k6gAB+4xCv8LUVnkRV2qu+MBk6hmX5vEOp8NYf0xKzEuOhYGyxSL4b/5U+6c2 bbYfRCbqLI/ySkifw55o =o/7E -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: JDBC Fails to connect to SQL Server
On Fri, Jan 30, 2015 at 9:01 AM, Aniket Bhoi aniket.b...@gmail.com wrote: Hi, I have Apache Solr hosted on Tomcat 6. There have been no changes to the code on Tomcat whatsoever.However for the last few days I now see this error in the Log files: SEVERE: Full Import failed Throwable occurred: org.apache.solr.handler.dataimport.DataImportHandlerException: Unable to execute query: SELECT ID, ENTRY_TYPE_REF, PROFILE_REF, ITEM_REF, TITLE, ABSTRACT, SOLUTION, SOLUTION_HTML, FREE_TEXT, DATE_UPDATED, ENTRY_TYPE, PROFILE_TYPE, SERVICE_TYPE FROM INFRA_KO_V Processing Document # 1 at org.apache.solr.handler.dataimport.DataImportHandlerException.wrapAndThrow(DataImportHandlerException.java:72) at org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator.init(JdbcDataSource.java:251) at org.apache.solr.handler.dataimport.JdbcDataSource.getData(JdbcDataSource.java:208) at org.apache.solr.handler.dataimport.JdbcDataSource.getData(JdbcDataSource.java:39) at org.apache.solr.handler.dataimport.SqlEntityProcessor.initQuery(SqlEntityProcessor.java:58) at org.apache.solr.handler.dataimport.SqlEntityProcessor.nextRow(SqlEntityProcessor.java:71) at org.apache.solr.handler.dataimport.EntityProcessorWrapper.nextRow(EntityProcessorWrapper.java:233) at org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:579) at org.apache.solr.handler.dataimport.DocBuilder.doFullDump(DocBuilder.java:260) at org.apache.solr.handler.dataimport.DocBuilder.execute(DocBuilder.java:184) at org.apache.solr.handler.dataimport.DataImporter.doFullImport(DataImporter.java:334) at org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:392) at org.apache.solr.handler.dataimport.DataImporter$1.run(DataImporter.java:373) *Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: The driver could not establish a secure connection to SQL Server by using Secure Sockets Layer (SSL) encryption. Error: SQL Server did not return a response. The connection has been closed..* at com.microsoft.sqlserver.jdbc.SQLServerConnection.terminate(SQLServerConnection.java:1368) at com.microsoft.sqlserver.jdbc.TDSChannel.enableSSL(IOBuffer.java:1412) at com.microsoft.sqlserver.jdbc.SQLServerConnection.connectHelper(SQLServerConnection.java:1058) at com.microsoft.sqlserver.jdbc.SQLServerConnection.login(SQLServerConnection.java:833) at com.microsoft.sqlserver.jdbc.SQLServerConnection.connect(SQLServerConnection.java:716) at com.microsoft.sqlserver.jdbc.SQLServerDriver.connect(SQLServerDriver.java:841) at org.apache.solr.handler.dataimport.JdbcDataSource$1.call(JdbcDataSource.java:160) at org.apache.solr.handler.dataimport.JdbcDataSource$1.call(JdbcDataSource.java:127) at org.apache.solr.handler.dataimport.JdbcDataSource.getConnection(JdbcDataSource.java:361) at org.apache.solr.handler.dataimport.JdbcDataSource.access$200(JdbcDataSource.java:39) at org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator.init(JdbcDataSource.java:238) ... 11 more *Caused by: java.io.IOException: SQL Server did not return a response. The connection has been closed.* at com.microsoft.sqlserver.jdbc.TDSChannel$SSLHandshakeInputStream.ensureSSLPayload(IOBuffer.java:513) at com.microsoft.sqlserver.jdbc.TDSChannel$SSLHandshakeInputStream.readInternal(IOBuffer.java:570) at com.microsoft.sqlserver.jdbc.TDSChannel$SSLHandshakeInputStream.read(IOBuffer.java:562) at com.microsoft.sqlserver.jdbc.TDSChannel$ProxyInputStream.readInternal(IOBuffer.java:757) at com.microsoft.sqlserver.jdbc.TDSChannel$ProxyInputStream.read(IOBuffer.java:745) at com.ibm.jsse2.b.a(b.java:286) at com.ibm.jsse2.b.a(b.java:67) at com.ibm.jsse2.SSLSocketImpl.a(SSLSocketImpl.java:313) at com.ibm.jsse2.SSLSocketImpl.h(SSLSocketImpl.java:63) at com.ibm.jsse2.SSLSocketImpl.a(SSLSocketImpl.java:316) at com.ibm.jsse2.SSLSocketImpl.startHandshake(SSLSocketImpl.java:220) at com.microsoft.sqlserver.jdbc.TDSChannel.enableSSL(IOBuffer.java:1379) ... 20 more I can confirmthat there has been no change to firewall settings etc . Need help on this. Regards Aniket Assuming no changes on the calling side (Application/OS), is it possible that the Windows MS SQL server has been recently patched and restarted. There are periodic OS, security updates to Windows and sometimes they involve Certificates (i.e. SSL). It could be that a previously allowed Certificate is no longer working due to expiration, encryption length no longer being sufficient, etc...
RE: Session being dropped in Virtual Host in 8.0.9
Hi Chris, I apologise in advance if the formatting is absolutely terrible. Are you using cookies for session-tracking? Can you watch the HTTP conversation to see what's being sent back and forth during that workflow? LiveHttpHeaders is great for Firefox, and these days Chrome, Firefox, and IE have something similar built-into them. From the looks of it, the cookie is storing the session ID. Server - nginx/1.6.2 (Ubuntu) Date - Fri, 30 Jan 2015 15:52:35 GMT Content-Type - text/html;charset=utf-8 Transfer-Encoding - chunked Connection - keep-alive Cache-Control - no-cache, no-store, must-revalidate, max-age=0 X-XSS-Protection - 1; mode=block x-content-type-options - nosniff x-frame-options - SAMEORIGIN Set-Cookie - ib=da7f36e0f53827383a262940d2f75fcef8bbb32b57bd3fced7149ae6a8bf4e3a; path=/; expires=Fri, 30 Jan 2015 15:57:35 -; HttpOnly Content-Encoding - gzip Everything in the HTTP requests seem fine, except the response from my POST at the Challenge point, where, instead of a 200, I'm receiving a 302. This is what tipped me off that it was the session that was causing the issue. You might want a fully-qualified host name in the host's name field... or at least whatever your clients DNS will resolve to your server. That may actually be virtual1 but I just thought I'd mention it. It shouldn't have any bearing on the session-handling, unless your web application switches hostnames by telling a client requesting virtual1 that it should redirect to testsitex.site.io or vice-versa. I went ahead and changed this as well, as it does seem like a good practice to use. Kind Regards, Rory - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat-jdbc PoolCleaner deadlock
Thanks, Chris. In general, I would expect validationInterval=0 to disable validation, but the documentation does not say anything about a zero value. Is it possible that you are /constantly/ validating? If you change that number to something higher (in ms: maybe 1 for 10s) you will reduce the chance for this deadlock? 0 means validate on every connection request. I need this setting because the apps has some annoying bugs (zn - change namespaces in Caché and there are many legacy apps that do not catch expceptions very well) There is a flaw in the documentation surrounding this setting on Linux, but it's only when fairQueue=true, so it shouldn't matter for you. But you might want to consider leaving the queue fair. It's not clear from the documentation whether enabling queue fairness /decreases/ performance or the opposite (but it seems reasonable that enforcing queue fairness would probably decrease performance). The same problem happens with fairQueue=true. :( 2015-01-30 14:31 GMT-03:00 Christopher Schultz ch...@christopherschultz.net : -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Robert, On 1/30/15 12:19 PM, Robert Anderson wrote: Every day we are getting deadlocks like that: Found one Java-level deadlock: = ajp-apr-8009-exec-13 ^ 30/01/2015 - 09:39:58 - DB:DATASOURCE(java:/comp/env/jdbc/cacheapp): waiting to lock monitor 0x1504e6d8 (object 0x00071ba001d0, a com.intersys.jdbc.CacheConnection), which is held by PoolCleaner[1070846187:1422601344160] PoolCleaner[1070846187:1422601344160]: waiting to lock monitor 0x12ce77e8 (object 0x00071ba007f0, a com.intersys.jdbc.CacheConnection$MessageCount), which is held by ajp-apr-8009-exec-13 ^ 30/01/2015 - 09:39:58 - DB:DATASOURCE(java:/comp/env/jdbc/cacheapp) D'oh. Are there anything that we can do to avoid it? Server version: Apache Tomcat/7.0.57 Server built: Nov 3 2014 08:39:16 UTC Server number: 7.0.57.0 OS Name:Linux OS Version: 2.6.18-194.17.1.el5 Architecture: amd64 JVM Version: 1.7.0_71-b14 JVM Vendor: Oracle Corporation Datasource definition: Resource name=jdbc/cacheapp auth=Container type=javax.sql.DataSource removeAbandoned=true removeAbandonedTimeout=300 maxActive=120 maxIdle=20 minIdle=1 maxWait=1 validationQuery=select 1 testOnBorrow=true validationInterval=0 In general, I would expect validationInterval=0 to disable validation, but the documentation does not say anything about a zero value. Is it possible that you are /constantly/ validating? If you change that number to something higher (in ms: maybe 1 for 10s) you will reduce the chance for this deadlock? I suspect this is a bug (deadlock should not occur), but you can maybe avoid it by changing your configuration. fairQueue=false There is a flaw in the documentation surrounding this setting on Linux, but it's only when fairQueue=true, so it shouldn't matter for you. But you might want to consider leaving the queue fair. It's not clear from the documentation whether enabling queue fairness /decreases/ performance or the opposite (but it seems reasonable that enforcing queue fairness would probably decrease performance). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUy7/vAAoJEBzwKT+lPKRYCGwP/ijUIjnHQ39rE6qzZ9GIGwad ZkGQTFZlZw03yxkcu9Dzqb7LdN/RWHaHzi5jZyWkJnz7SO6EIe9gyUya2kvojF4x 9u3+TrDT/+fTQd17UvEuKAzRqV56PGFdfWGMNlQmk1ndOQYFRwD6B3vFF0SCMbw0 q0Z5qIHw5YqgVg+xfsA/ubsrOX8prI0c0AzgN8yFd5Jv+Ts80rD4PNr1kfN+K6oE N2komJkEEn3PpSSFdhut3FPcZZingm5xiV/2u5hwOOvHhAZIG7qpP0RwEDN2fPRd MEC1j0dO2k+JZW8PC5RWPGyqEg9F+213sw8Qc8idOf2zHNXYwzxtZcD8i+iokYLS 8Tn5ByYRgX5ZEdTA1e1DUIM6BTRgA+HX30T5lRBOBFC9/baKcrRVR9tS9gn9zQBj HV1Xfoy6V/efL7AHAOd1nPL+SswzVYs2U0HtOOA4MjYLguhuRNPx3ofWufESXJ1T 5n6h7ipN1mda8LcMtK3bVSrBfL+SnU5p7bwmQvtRX33xeKMOgv8XnWWaFc1eWLHg yrS6KZSVUhIHlLwy2tBJasWB2VtxcEOoSjOWJfHBgPIsAp3TcwyNbNZ3JVDAMW1D 8kjmDJnBguuHbz+tn4qabPB8TmcO/78GrcOr+qY42IjIJQM4kX0otXzngh+nI21z Fm3UQnSzGs29jQCwe5Ho =v9Pk -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat-jdbc PoolCleaner deadlock
Sorry, [1] https://people.apache.org/~fhanik/jdbc-pool/jdbc-pool.html 2015-01-30 15:15 GMT-03:00 Robert Anderson ranom...@gmail.com: Filip, however, disabling the pool cleaner it should yield better results. The documention[1] says: This value should not be set under 1 second Isn't true? 2015-01-30 15:07 GMT-03:00 Filip Hanik fi...@hanik.com: Looking at the locks that are involved in the dead lock, it's all in the intersys traces. Furthermore, it seems as intersys may already be doing pooling inside the driver. If that is the case, you have two options 1. disable pooling in intersys OR 2. don't use tomcat's jdbc pool since intersys already does pooling however, disabling the pool cleaner it should yield better results. On Fri, Jan 30, 2015 at 11:02 AM, Filip Hanik fi...@hanik.com wrote: Disable the pool cleaner timeBetweenEvictionRunsMillis=0
Re: tomcat-jdbc PoolCleaner deadlock
Am 30.01.2015 um 18:44 schrieb Robert Anderson: Could you post a full stacktrace, or threaddump? ajp-apr-8009-exec-13 ^ 30/01/2015 - 09:39:58 - DB:DATASOURCE(java:/comp/env/jdbc/cacheapp) daemon prio=10 tid=0x13bb nid=0x7a6d waiting for monitor entry [0x5125b000] java.lang.Thread.State: BLOCKED (on object monitor) at com.intersys.jdbc.CacheConnection.close(CacheConnection.java:552) - waiting to lock 0x00071ba001d0 (a com.intersys.jdbc.CacheConnection) at com.intersys.jdbc.InStream.invalidMessageReceived(InStream.java:234) - locked 0x00071ba094c0 (a com.intersys.jdbc.InStream) at com.intersys.jdbc.InStream.checkHeader(InStream.java:104) - eliminated 0x00071ba094c0 (a com.intersys.jdbc.InStream) at com.intersys.jdbc.InStream.readHeader(InStream.java:148) - locked 0x00071ba094c0 (a com.intersys.jdbc.InStream) at com.intersys.jdbc.CacheStatement.sendDirectQueryRequest(CacheStatement.java:551) - locked 0x00071ba007f0 (a com.intersys.jdbc.CacheConnection$MessageCount) - locked 0x00071ba00150 (a com.intersys.jdbc.CacheStatement) at com.intersys.jdbc.CacheStatement.Query(CacheStatement.java:486) - locked 0x00071ba00150 (a com.intersys.jdbc.CacheStatement) at com.intersys.jdbc.CacheStatement.executeQuery(CacheStatement.java:418) - locked 0x00071ba00150 (a com.intersys.jdbc.CacheStatement) at br.com.itx.database.impl.ConnectionSql.execute(ConnectionSql.java:246) at br.com.itx.integration.DatabaseHandler.execute(DatabaseHandler.java:274) at br.com.itx.integration.DatabaseHandler.execute(DatabaseHandler.java:163) at br.com.itx.engine.CoreObjectElement.execute(CoreObjectElement.java:88) at br.com.itx.component.taglib.ExecuteCore.doStartTag(ExecuteCore.java:98) at org.apache.jsp.portaladv.main_005fpre_jsp._jspx_meth_w_005fexecuteCore_005f41(main_005fpre_jsp.java:2858) at org.apache.jsp.portaladv.main_005fpre_jsp._jspService(main_005fpre_jsp.java:718) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:727) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:432) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:395) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:339) at javax.servlet.http.HttpServlet.service(HttpServlet.java:727) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:748) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:604) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:543) at br.com.itx.engine.Execute.doJsp(Execute.java:476) at br.com.itx.engine.Execute.doPost(Execute.java:425) - locked 0x00071ba34398 (a java.lang.Object) at br.com.itx.engine.Execute.doGet(Execute.java:98) at javax.servlet.http.HttpServlet.service(HttpServlet.java:620) at javax.servlet.http.HttpServlet.service(HttpServlet.java:727) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:503) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:170) at com.googlecode.psiprobe.Tomcat70AgentValve.invoke(Tomcat70AgentValve.java:38) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103) at org.apache.catalina.valves.StuckThreadDetectionValve.invoke(StuckThreadDetectionValve.java:221) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:421) at org.apache.coyote.ajp.AjpAprProcessor.process(AjpAprProcessor.java:188) at
Re: tomcat-jdbc PoolCleaner deadlock
Looking at the locks that are involved in the dead lock, it's all in the intersys traces. Furthermore, it seems as intersys may already be doing pooling inside the driver. If that is the case, you have two options 1. disable pooling in intersys OR 2. don't use tomcat's jdbc pool since intersys already does pooling however, disabling the pool cleaner it should yield better results. On Fri, Jan 30, 2015 at 11:02 AM, Filip Hanik fi...@hanik.com wrote: Disable the pool cleaner timeBetweenEvictionRunsMillis=0
Re: tomcat-jdbc PoolCleaner deadlock
Great, Filip!
Returns true if the pool sweeper is enabled for the connection pool. The
pool sweeper is enabled if any settings that require async intervention in
the pool are turned on boolean result =
getTimeBetweenEvictionRunsMillis()0; result = result
(isRemoveAbandoned() getRemoveAbandonedTimeout()0); result = result ||
(isTestWhileIdle() getValidationQuery()!=null); return result; [1]
Best regards.
[1]
https://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/tomcat/jdbc/pool/PoolConfiguration.html#isPoolSweeperEnabled()
2015-01-30 16:13 GMT-03:00 Filip Hanik fi...@hanik.com:
Are you seeing that message, cause it seems to be a defensive check, but
wouldn't happen due to
509 public void initializePoolCleaner(PoolConfiguration properties) { 510
//if
the evictor thread is supposed to run, start it now 511 if (properties.
isPoolSweeperEnabled()) { 512 poolCleaner = new PoolCleaner(this,
properties
.getTimeBetweenEvictionRunsMillis()); 513 poolCleaner.start(); 514 } //end
if 515 }
On Fri, Jan 30, 2015 at 12:05 PM, Robert Anderson ranom...@gmail.com
wrote:
Filip,
timeBetweenEvictionRunsMillis=0 does not disable PoolCleaner [1].
if (sleepTime = 0) {
log.warn(Database connection pool evicter thread
interval is set to 0, defaulting to 30 seconds);
this.sleepTime = 1000 * 30;
} else if (sleepTime 1000) {
log.warn(Database connection pool evicter thread
interval is set to lower than 1 second.);
}
[1]
http://svn.apache.org/repos/asf/tomcat/tc7.0.x/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/ConnectionPool.java
2015-01-30 15:17 GMT-03:00 Robert Anderson ranom...@gmail.com:
Sorry,
[1] https://people.apache.org/~fhanik/jdbc-pool/jdbc-pool.html
2015-01-30 15:15 GMT-03:00 Robert Anderson ranom...@gmail.com:
Filip,
however, disabling the pool cleaner it should yield better results.
The documention[1] says:
This value should not be set under 1 second
Isn't true?
2015-01-30 15:07 GMT-03:00 Filip Hanik fi...@hanik.com:
Looking at the locks that are involved in the dead lock, it's all in
the
intersys traces. Furthermore, it seems as intersys may already be
doing
pooling inside the driver. If that is the case, you have two options
1. disable pooling in intersys OR
2. don't use tomcat's jdbc pool since intersys already does pooling
however, disabling the pool cleaner it should yield better results.
On Fri, Jan 30, 2015 at 11:02 AM, Filip Hanik fi...@hanik.com
wrote:
Disable the pool cleaner
timeBetweenEvictionRunsMillis=0
Re: tomcat-jdbc PoolCleaner deadlock
Filip, however, disabling the pool cleaner it should yield better results. The documention[1] says: This value should not be set under 1 second Isn't true? 2015-01-30 15:07 GMT-03:00 Filip Hanik fi...@hanik.com: Looking at the locks that are involved in the dead lock, it's all in the intersys traces. Furthermore, it seems as intersys may already be doing pooling inside the driver. If that is the case, you have two options 1. disable pooling in intersys OR 2. don't use tomcat's jdbc pool since intersys already does pooling however, disabling the pool cleaner it should yield better results. On Fri, Jan 30, 2015 at 11:02 AM, Filip Hanik fi...@hanik.com wrote: Disable the pool cleaner timeBetweenEvictionRunsMillis=0
Re: tomcat-jdbc PoolCleaner deadlock
Could you post a full stacktrace, or threaddump? ajp-apr-8009-exec-13 ^ 30/01/2015 - 09:39:58 - DB:DATASOURCE(java:/comp/env/jdbc/cacheapp) daemon prio=10 tid=0x13bb nid=0x7a6d waiting for monitor entry [0x5125b000] java.lang.Thread.State: BLOCKED (on object monitor) at com.intersys.jdbc.CacheConnection.close(CacheConnection.java:552) - waiting to lock 0x00071ba001d0 (a com.intersys.jdbc.CacheConnection) at com.intersys.jdbc.InStream.invalidMessageReceived(InStream.java:234) - locked 0x00071ba094c0 (a com.intersys.jdbc.InStream) at com.intersys.jdbc.InStream.checkHeader(InStream.java:104) - eliminated 0x00071ba094c0 (a com.intersys.jdbc.InStream) at com.intersys.jdbc.InStream.readHeader(InStream.java:148) - locked 0x00071ba094c0 (a com.intersys.jdbc.InStream) at com.intersys.jdbc.CacheStatement.sendDirectQueryRequest(CacheStatement.java:551) - locked 0x00071ba007f0 (a com.intersys.jdbc.CacheConnection$MessageCount) - locked 0x00071ba00150 (a com.intersys.jdbc.CacheStatement) at com.intersys.jdbc.CacheStatement.Query(CacheStatement.java:486) - locked 0x00071ba00150 (a com.intersys.jdbc.CacheStatement) at com.intersys.jdbc.CacheStatement.executeQuery(CacheStatement.java:418) - locked 0x00071ba00150 (a com.intersys.jdbc.CacheStatement) at br.com.itx.database.impl.ConnectionSql.execute(ConnectionSql.java:246) at br.com.itx.integration.DatabaseHandler.execute(DatabaseHandler.java:274) at br.com.itx.integration.DatabaseHandler.execute(DatabaseHandler.java:163) at br.com.itx.engine.CoreObjectElement.execute(CoreObjectElement.java:88) at br.com.itx.component.taglib.ExecuteCore.doStartTag(ExecuteCore.java:98) at org.apache.jsp.portaladv.main_005fpre_jsp._jspx_meth_w_005fexecuteCore_005f41(main_005fpre_jsp.java:2858) at org.apache.jsp.portaladv.main_005fpre_jsp._jspService(main_005fpre_jsp.java:718) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:727) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:432) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:395) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:339) at javax.servlet.http.HttpServlet.service(HttpServlet.java:727) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:748) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:604) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:543) at br.com.itx.engine.Execute.doJsp(Execute.java:476) at br.com.itx.engine.Execute.doPost(Execute.java:425) - locked 0x00071ba34398 (a java.lang.Object) at br.com.itx.engine.Execute.doGet(Execute.java:98) at javax.servlet.http.HttpServlet.service(HttpServlet.java:620) at javax.servlet.http.HttpServlet.service(HttpServlet.java:727) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:503) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:170) at com.googlecode.psiprobe.Tomcat70AgentValve.invoke(Tomcat70AgentValve.java:38) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103) at org.apache.catalina.valves.StuckThreadDetectionValve.invoke(StuckThreadDetectionValve.java:221) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:421) at org.apache.coyote.ajp.AjpAprProcessor.process(AjpAprProcessor.java:188) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:611) at
Re: tomcat-jdbc PoolCleaner deadlock
Ok, Filip!
Thanks,
Robert
2015-01-30 16:31 GMT-03:00 Filip Hanik fi...@hanik.com:
Robert, kindly let us know if disabling the pool cleaner does resolve your
dead lock
Filip
On Fri, Jan 30, 2015 at 12:25 PM, Robert Anderson ranom...@gmail.com
wrote:
Great, Filip!
Returns true if the pool sweeper is enabled for the connection pool. The
pool sweeper is enabled if any settings that require async intervention
in
the pool are turned on boolean result =
getTimeBetweenEvictionRunsMillis()0; result = result
(isRemoveAbandoned() getRemoveAbandonedTimeout()0); result = result
||
(isTestWhileIdle() getValidationQuery()!=null); return result; [1]
Best regards.
[1]
https://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/tomcat/jdbc/pool/PoolConfiguration.html#isPoolSweeperEnabled()
2015-01-30 16:13 GMT-03:00 Filip Hanik fi...@hanik.com:
Are you seeing that message, cause it seems to be a defensive check,
but
wouldn't happen due to
509 public void initializePoolCleaner(PoolConfiguration properties) {
510
//if
the evictor thread is supposed to run, start it now 511 if (properties.
isPoolSweeperEnabled()) { 512 poolCleaner = new PoolCleaner(this,
properties
.getTimeBetweenEvictionRunsMillis()); 513 poolCleaner.start(); 514 }
//end
if 515 }
On Fri, Jan 30, 2015 at 12:05 PM, Robert Anderson ranom...@gmail.com
wrote:
Filip,
timeBetweenEvictionRunsMillis=0 does not disable PoolCleaner [1].
if (sleepTime = 0) {
log.warn(Database connection pool evicter thread
interval is set to 0, defaulting to 30 seconds);
this.sleepTime = 1000 * 30;
} else if (sleepTime 1000) {
log.warn(Database connection pool evicter thread
interval is set to lower than 1 second.);
}
[1]
http://svn.apache.org/repos/asf/tomcat/tc7.0.x/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/ConnectionPool.java
2015-01-30 15:17 GMT-03:00 Robert Anderson ranom...@gmail.com:
Sorry,
[1] https://people.apache.org/~fhanik/jdbc-pool/jdbc-pool.html
2015-01-30 15:15 GMT-03:00 Robert Anderson ranom...@gmail.com:
Filip,
however, disabling the pool cleaner it should yield better
results.
The documention[1] says:
This value should not be set under 1 second
Isn't true?
2015-01-30 15:07 GMT-03:00 Filip Hanik fi...@hanik.com:
Looking at the locks that are involved in the dead lock, it's all
in
the
intersys traces. Furthermore, it seems as intersys may already be
doing
pooling inside the driver. If that is the case, you have two
options
1. disable pooling in intersys OR
2. don't use tomcat's jdbc pool since intersys already does
pooling
however, disabling the pool cleaner it should yield better
results.
On Fri, Jan 30, 2015 at 11:02 AM, Filip Hanik fi...@hanik.com
wrote:
Disable the pool cleaner
timeBetweenEvictionRunsMillis=0
Re: tomcat-jdbc PoolCleaner deadlock
Disable the pool cleaner timeBetweenEvictionRunsMillis=0
Re: tomcat-jdbc PoolCleaner deadlock
Robert, it should say, if you set a positive value, the value should not be
less than 1000ms. Otherwise you are hammering the system with eviction
checks.
Setting the value to 0, disables the check all together. There are other
ways to disable the same check by setting other flags,
918 @Override 919 public boolean isPoolSweeperEnabled() { 920 boolean timer
= getTimeBetweenEvictionRunsMillis()0; 921 boolean result = timer (
isRemoveAbandoned() getRemoveAbandonedTimeout()0); 922 result = result
|| (timer getSuspectTimeout()0); 923 result = result || (timer
isTestWhileIdle() getValidationQuery()!=null); 924 result = result || (
timer getMinEvictableIdleTimeMillis()0); 925 return result; 926 }
On Fri, Jan 30, 2015 at 11:17 AM, Robert Anderson ranom...@gmail.com
wrote:
Sorry,
[1] https://people.apache.org/~fhanik/jdbc-pool/jdbc-pool.html
2015-01-30 15:15 GMT-03:00 Robert Anderson ranom...@gmail.com:
Filip,
however, disabling the pool cleaner it should yield better results.
The documention[1] says:
This value should not be set under 1 second
Isn't true?
2015-01-30 15:07 GMT-03:00 Filip Hanik fi...@hanik.com:
Looking at the locks that are involved in the dead lock, it's all in the
intersys traces. Furthermore, it seems as intersys may already be doing
pooling inside the driver. If that is the case, you have two options
1. disable pooling in intersys OR
2. don't use tomcat's jdbc pool since intersys already does pooling
however, disabling the pool cleaner it should yield better results.
On Fri, Jan 30, 2015 at 11:02 AM, Filip Hanik fi...@hanik.com wrote:
Disable the pool cleaner
timeBetweenEvictionRunsMillis=0
Re: tomcat-jdbc PoolCleaner deadlock
Filip,
timeBetweenEvictionRunsMillis=0 does not disable PoolCleaner [1].
if (sleepTime = 0) {
log.warn(Database connection pool evicter thread
interval is set to 0, defaulting to 30 seconds);
this.sleepTime = 1000 * 30;
} else if (sleepTime 1000) {
log.warn(Database connection pool evicter thread
interval is set to lower than 1 second.);
}
[1]http://svn.apache.org/repos/asf/tomcat/tc7.0.x/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/ConnectionPool.java
2015-01-30 15:17 GMT-03:00 Robert Anderson ranom...@gmail.com:
Sorry,
[1] https://people.apache.org/~fhanik/jdbc-pool/jdbc-pool.html
2015-01-30 15:15 GMT-03:00 Robert Anderson ranom...@gmail.com:
Filip,
however, disabling the pool cleaner it should yield better results.
The documention[1] says:
This value should not be set under 1 second
Isn't true?
2015-01-30 15:07 GMT-03:00 Filip Hanik fi...@hanik.com:
Looking at the locks that are involved in the dead lock, it's all in the
intersys traces. Furthermore, it seems as intersys may already be doing
pooling inside the driver. If that is the case, you have two options
1. disable pooling in intersys OR
2. don't use tomcat's jdbc pool since intersys already does pooling
however, disabling the pool cleaner it should yield better results.
On Fri, Jan 30, 2015 at 11:02 AM, Filip Hanik fi...@hanik.com wrote:
Disable the pool cleaner
timeBetweenEvictionRunsMillis=0
Re: tomcat-jdbc PoolCleaner deadlock
Are you seeing that message, cause it seems to be a defensive check, but
wouldn't happen due to
509 public void initializePoolCleaner(PoolConfiguration properties) { 510 //if
the evictor thread is supposed to run, start it now 511 if (properties.
isPoolSweeperEnabled()) { 512 poolCleaner = new PoolCleaner(this, properties
.getTimeBetweenEvictionRunsMillis()); 513 poolCleaner.start(); 514 } //end
if 515 }
On Fri, Jan 30, 2015 at 12:05 PM, Robert Anderson ranom...@gmail.com
wrote:
Filip,
timeBetweenEvictionRunsMillis=0 does not disable PoolCleaner [1].
if (sleepTime = 0) {
log.warn(Database connection pool evicter thread
interval is set to 0, defaulting to 30 seconds);
this.sleepTime = 1000 * 30;
} else if (sleepTime 1000) {
log.warn(Database connection pool evicter thread
interval is set to lower than 1 second.);
}
[1]
http://svn.apache.org/repos/asf/tomcat/tc7.0.x/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/ConnectionPool.java
2015-01-30 15:17 GMT-03:00 Robert Anderson ranom...@gmail.com:
Sorry,
[1] https://people.apache.org/~fhanik/jdbc-pool/jdbc-pool.html
2015-01-30 15:15 GMT-03:00 Robert Anderson ranom...@gmail.com:
Filip,
however, disabling the pool cleaner it should yield better results.
The documention[1] says:
This value should not be set under 1 second
Isn't true?
2015-01-30 15:07 GMT-03:00 Filip Hanik fi...@hanik.com:
Looking at the locks that are involved in the dead lock, it's all in the
intersys traces. Furthermore, it seems as intersys may already be doing
pooling inside the driver. If that is the case, you have two options
1. disable pooling in intersys OR
2. don't use tomcat's jdbc pool since intersys already does pooling
however, disabling the pool cleaner it should yield better results.
On Fri, Jan 30, 2015 at 11:02 AM, Filip Hanik fi...@hanik.com wrote:
Disable the pool cleaner
timeBetweenEvictionRunsMillis=0
Re: tomcat-jdbc PoolCleaner deadlock
Robert, kindly let us know if disabling the pool cleaner does resolve your
dead lock
Filip
On Fri, Jan 30, 2015 at 12:25 PM, Robert Anderson ranom...@gmail.com
wrote:
Great, Filip!
Returns true if the pool sweeper is enabled for the connection pool. The
pool sweeper is enabled if any settings that require async intervention in
the pool are turned on boolean result =
getTimeBetweenEvictionRunsMillis()0; result = result
(isRemoveAbandoned() getRemoveAbandonedTimeout()0); result = result ||
(isTestWhileIdle() getValidationQuery()!=null); return result; [1]
Best regards.
[1]
https://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/tomcat/jdbc/pool/PoolConfiguration.html#isPoolSweeperEnabled()
2015-01-30 16:13 GMT-03:00 Filip Hanik fi...@hanik.com:
Are you seeing that message, cause it seems to be a defensive check, but
wouldn't happen due to
509 public void initializePoolCleaner(PoolConfiguration properties) { 510
//if
the evictor thread is supposed to run, start it now 511 if (properties.
isPoolSweeperEnabled()) { 512 poolCleaner = new PoolCleaner(this,
properties
.getTimeBetweenEvictionRunsMillis()); 513 poolCleaner.start(); 514 }
//end
if 515 }
On Fri, Jan 30, 2015 at 12:05 PM, Robert Anderson ranom...@gmail.com
wrote:
Filip,
timeBetweenEvictionRunsMillis=0 does not disable PoolCleaner [1].
if (sleepTime = 0) {
log.warn(Database connection pool evicter thread
interval is set to 0, defaulting to 30 seconds);
this.sleepTime = 1000 * 30;
} else if (sleepTime 1000) {
log.warn(Database connection pool evicter thread
interval is set to lower than 1 second.);
}
[1]
http://svn.apache.org/repos/asf/tomcat/tc7.0.x/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/ConnectionPool.java
2015-01-30 15:17 GMT-03:00 Robert Anderson ranom...@gmail.com:
Sorry,
[1] https://people.apache.org/~fhanik/jdbc-pool/jdbc-pool.html
2015-01-30 15:15 GMT-03:00 Robert Anderson ranom...@gmail.com:
Filip,
however, disabling the pool cleaner it should yield better results.
The documention[1] says:
This value should not be set under 1 second
Isn't true?
2015-01-30 15:07 GMT-03:00 Filip Hanik fi...@hanik.com:
Looking at the locks that are involved in the dead lock, it's all in
the
intersys traces. Furthermore, it seems as intersys may already be
doing
pooling inside the driver. If that is the case, you have two
options
1. disable pooling in intersys OR
2. don't use tomcat's jdbc pool since intersys already does pooling
however, disabling the pool cleaner it should yield better results.
On Fri, Jan 30, 2015 at 11:02 AM, Filip Hanik fi...@hanik.com
wrote:
Disable the pool cleaner
timeBetweenEvictionRunsMillis=0
Exception page after installation of Tomcat 7.0.54
Dear Experts, I have installed Apache Tomcat 7.0.54, after installation when I open https://host_name:port_number I am getting below exception org.apache.jasper.JasperException: java.lang.IllegalStateException: No Java compiler available org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:585) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:391) But I am able to open https://host_name:port_number/manager/html page and can be able proceed with normal operation. Would you please suggest. Rajesh
RE: JDBC authentication problem
Thanks for the reply, it is the JDBCRealm not the data source. I have set this password for test only but it will be changed when everything will be ok and in production . (But didn't saw i had paste it ...) -Message d'origine- De : Konstantin Kolinko [mailto:knst.koli...@gmail.com] Envoyé : vendredi 30 janvier 2015 14:52 À : Tomcat Users List Objet : Re: JDBC authentication problem 2015-01-30 16:45 GMT+03:00 Luc DALLEMANE ldallem...@alaloop.com: Hi, I'm facing a problem with my web application. I'm using Tomcat 7.0.56, Java 1.8, Postgres 9.4 and Debian 7. The application is configured as followed : The web server is located in a DMZ. The database server is located in our LAN. To communicate with each other, a firewall has been setup (Cisco asa firewall) To authenticate an user to the website, I use the tomcat JDBC Realm. 1. Realm configuration =? Is it JDBCRealm or DataSourceRealm? If it is the former, then your Resource is not used at all. 2. Posting the actual password on a public mailing list? Consider it compromised. At the beginning, everything works fine, but after about an hour of inactivity, its impossible to authenticate again : Tomcat process seems to be running but doesn't log anything and doesn't answer any other requests. The firewall is rejecting the connection with the following message : Deny TCP (no connection) from WEB/50790 to DB/5432 FIN ACK on interface DMZ_clients I thought, the problem was after a while, if tomcat connexions were not used, the firewall would drop them. So, I tried to add keepAlive time-outs (tomcat site, postgres side, ) but none of them worked : Here is the tomcat context.xml : Resource name=jdbc/elkar auth=Container type=javax.sql.DataSource driverClassName=org.postgresql.Driver [...] / The postgresql.conf : # - TCP Keepalives - # see man 7 tcp for details #tcp_keepalives_idle = 300 # TCP_KEEPIDLE, in seconds; # 0 selects the system default #tcp_keepalives_interval = 0# TCP_KEEPINTVL, in seconds; # 0 selects the system default #tcp_keepalives_count = 0 And finally, the Sysctl.conf : net.ipv4.tcp_keepalive_time = 900 net.ipv4.tcp_keepalive_intvl = 60 net.ipv4.tcp_keepalive_probes = 9 Before that, the application was tested without using the firewall and everything worked fine. If you have any idea of why this is happening, I haven't found a solution yet. Regards, Luc D. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat sending 411 Length Required due to Chunked Transfer Encoding
Thank you for pointing out my error in assuming that it was Tomcat's fault. I have forwarded the issue to the application vendor to see if they can fix. I appreciate your time in responding to my question as well as giving me additional information with which to attempt to debug and/or correct the issue (i.e. the filter option) I will consider this question closed. THanks, Jeff On Thu, Jan 29, 2015 at 4:58 PM, Konstantin Kolinko knst.koli...@gmail.com wrote: 2015-01-30 1:29 GMT+03:00 Jeff Kohut jeff.ko...@gmail.com: My first post to Tomcat list, pardon me if I make any mistakes, Any help you can provide would be greatly appreciated. I have a Tomcat Server (V 7.0.54) running under Windows 2008 R2 With Service Pack 1 (and up to date on Security as well as OS patches). That server is running a vendor supplied group of applications via .war file as normal. to receive Soap/XML data from remote computer and process and return data back to calling application. The remote calling application hosted by IBM Websphere Application Server (running Axis2 jars) that is sending XML Soap data via a Post to the Tomcat Web server on port 8080/8443. If the amount of data is relatively small (i.e. 14 K) we have no problem receiving the data as Websphere is using Length Http 1.1 header and Tomcat sends the data to the application with no issue. However as the data gets larger, Websphere begins using Chunked Transfer Encoding and apparently Tomcat does not seem to like this as it returns Http 411 Length Required message. I have searched Tomcat site, and Tomcat indicates that is support Chunked encoding (part of the MUST supported parts of the HTTP 1.1 RFC standard. My connector in Tomcat is configured: Connector port=8080 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=8443 / I have tried forcing BIO,NIO, and APR with no luck to see if the implementations might handle Chunked Encoding differently. I also have a more complicated 8443 SSL port that also works, until Chunked encoding is used, and then it also responds with 411 Length Required error. I am able to replicate the problem by using SoapUI to send the same Soap formatted XML Data. It works fine sending all sizes of data UNTIL I enable Chunked Encoding Threshold which is smaller than the XML payload size (threshold means to not Chunk until data is larger than Threshold), When Chunking starts, Tomcat responds with 411 Length required. To finally work around this issue, I have put an Apache 2.4 server in front of Tomcat, and have enable the mod_proxy_http, and am using an Apache SetEnv variable setting of : SetEnv proxy-sendcl 1 The proxy-sendcl tells Apache to send the Length , and then Tomcat and application are happy with the data (i.e. no 411 method sent back). As I stated above, Tomcat indicates it supports Chunked Encoding on it's site, but it acts as if it is not happy with it. We have looked at packet traces and it appears that the Chunks are formatted correctly (we are getting an initial Chunk(s) and then the last Chunk is zero with Cr Lf following it as it seems to indicate in RFC. Has anyone else seen this issue and is there any way to alter the Tomcat behavior with Chunked encoded data? We found an IBM Websphere article that seems to admit to the problem, but they indicate that they should not have to offer a method to disable chunked encoding as some who seem to have encountered this problem suggest. IBM states that since Http 1.1 mandates support of Chunked Encoding, then HTTP 1.1. servers should support Chunked encoding correctly. FYI, I took the time to recreate the problem in C# code, and as soon as I turn on Chunked Encoding, the 411 errors is present from that application also when sending data to Tomcat Server. Tomcat 7 does not send status code 411 (a constant is declared in HttpServletResponse class but it is never used). That response code is coming from a web application that you are using. You may try debugging. http://wiki.apache.org/tomcat/FAQ/Developing#Debugging with a breakpoint on sendError(int,String), setStatus(int) methods of org.apache.catalina.connector.Response. It should be possible to implement a javax.servlet.Filter to cache a request and feed it to the web application for further processing, but it would be better to fix the web application itself. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: mod_jk and session stickiness
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Rainer, On 1/30/15 5:57 AM, Rainer Jung wrote: Am 30.01.2015 um 03:06 schrieb Christopher Schultz: On 7/23/14 5:14 PM, Christopher Schultz wrote: Rainer, On 7/23/14, 4:10 PM, Rainer Jung wrote: Am 23.07.2014 um 21:03 schrieb Christopher Schultz: On 7/23/14, 1:49 PM, Rainer Jung wrote: The other case, a request with an invalid session ID accessing a tomcat instance with activation disabled can IMHO be handled by a filter that - checks whether the request has a valid session using getSession(false), if it has one, let the request proceed - checks activation state, if active, let the request proceed - checks the request method, if not GET, let the request proceed - otherwise: - set the session cookie, e.g. JSESSIONID the an empty value - issue an external redirect to the same request URL - optional redirect loop detection: add a query string param or cookie that gets the local jvmRoute appended during each redirect. Before doing the redirect, check that the local jvmRoute is not already part of that token (we have already been here before) This would not really interfere with your saved requests: they would get a redirect which the browser follwos automatically and after that you will observe the normal behavior. This is exactly what I have implemented -- as a Filter since we can insert it before SecurityFilter intercepts the requests -- and my tests suggest that it will work correctly. I added code to strip-out any ;jsessionid path parameter from the URL ACK if it exists, but haven't done any of the redirect loop detection (yet). I think the loop detection is going to have to keep a running list of visited nodes which, in large clusters, could grow very large especially if the node names are long. I'll post my code when it's a little more featureful. As long as nothing goes wrong, the first redirect - having no more session info - should not end up in getting redirected as well, because it should only be send to an active node by mod_jk. So you can even stop redirecting if you detect, that it already happened once. For a large cluster that might be better. Multiple might happen (didn't check the code), if all active members are in error state. Even then one would not like to produce many of those redirects for one request, so again, only allowing one redirect might be the right solution. That's a good thought, and simplifies things. The request parameter could then just be a boolean flag and not actually identify the node that produced the redirect: any node considering redirecting simply would not redirect if that flag had been set. So, I've implemented all of the above and just given it a real test-drive in production. It seems to work well on the first shot. Good! I'll be testing it a bit more as time does on, actually. I also converted it to a Valve that I will propose to include in Tomcat once I get some real mileage on it. Was a Valve more useful than a filter? Did you need to access Tomcat internals? I can do everything without using Tomcat internals *except* for determining whether or not the cookie path should end with a /. I'll have to make that part of the configuration, and have it default to true. That's the only part that isn't exposed by the Servlet API. (This was one of the things that bit me when deploying this recently.) I got crickets when posting a while back to the dev list: http://markmail.org/thread/4oldeombollmp2dw Feel free to lend your opinion. I also discovered that I'd like to have a new feature: the ability for a whitelisted client to ignore the re-balance rules and continue to contact the server. So, if you have a cluster member called, say, foo and you want to force your way into foo, you can make a request to any page with a jsessionid parameter: http://host/some_page;jsessionid=1234.foo mod_jk will send you to the foo node, even though it is in the DISABLED state. Normally, my Filter/Valve would see that you have no valid session (1234.foo is not valid) and perform a redirect without the jsessionid path parameter added, thus re-balancing you to another node. Instead, I've added the ability to configure an ignore cookie and cookie value (like ignore=SECRETCODE). If the client presents this cookie to the Filter/Valve, then it's business as usual. This allows a trusted user to log into the DISABLED node through the load-balancer to take a look around, make sure that things are working properly, etc. before re-enabling the node in the cluster. I'll give this a shot in the next few days, clean it all up, and publish it (soon?). That sounds useful. I'm testing it in development right now. Thanks, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUy5G7AAoJEBzwKT+lPKRYn3MP/3KTIAq8QP8CqyEQR1ckXLWM
Re: Problem with mod_jk JKStatus: where is the worker state property?
Rainer Jung wrote: ... state is only printed of the worker is a member of a load balancer. Otherwise there is no such thing as state. It is good practise to wrap even a single worker in a load balancer because of its enhanced failure detection and reporting. Even if you don't have a second worker to fail over. Maybe it is worth adding this to the mod_jk documentation somewhere ? (If it isn't already there, but I didn't find it) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: JDBC authentication problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Luc, On 1/30/15 9:05 AM, Luc DALLEMANE wrote: Thanks for the reply, it is the JDBCRealm not the data source. Your Resource configuration is therefore ignored. The JDBCRealm should really not be used at all. Switch to DataSourceRealm. If you don't like using your application's DataSource for authentication (some folks don't), then create a second DataSource just for authentication. The DataSourceRealm has some significant advantages, such as being able to use a configurable pool of Connections, instead of a single Connection like JDBCRealm does. This improved performance and allows for re-connections, etc. I think this will fix your immediate problem plus eliminate some other problems down the line (like performance). I have set this password for test only but it will be changed when everything will be ok and in production . (But didn't saw i had paste it ...) Good. :) - -chris -Message d'origine- De : Konstantin Kolinko [mailto:knst.koli...@gmail.com] Envoyé : vendredi 30 janvier 2015 14:52 À : Tomcat Users List Objet : Re: JDBC authentication problem 2015-01-30 16:45 GMT+03:00 Luc DALLEMANE ldallem...@alaloop.com: Hi, I'm facing a problem with my web application. I'm using Tomcat 7.0.56, Java 1.8, Postgres 9.4 and Debian 7. The application is configured as followed : The web server is located in a DMZ. The database server is located in our LAN. To communicate with each other, a firewall has been setup (Cisco asa firewall) To authenticate an user to the website, I use the tomcat JDBC Realm. 1. Realm configuration =? Is it JDBCRealm or DataSourceRealm? If it is the former, then your Resource is not used at all. 2. Posting the actual password on a public mailing list? Consider it compromised. At the beginning, everything works fine, but after about an hour of inactivity, its impossible to authenticate again : Tomcat process seems to be running but doesn't log anything and doesn't answer any other requests. The firewall is rejecting the connection with the following message : Deny TCP (no connection) from WEB/50790 to DB/5432 FIN ACK on interface DMZ_clients I thought, the problem was after a while, if tomcat connexions were not used, the firewall would drop them. So, I tried to add keepAlive time-outs (tomcat site, postgres side, ) but none of them worked : Here is the tomcat context.xml : Resource name=jdbc/elkar auth=Container type=javax.sql.DataSource driverClassName=org.postgresql.Driver [...] / The postgresql.conf : # - TCP Keepalives - # see man 7 tcp for details #tcp_keepalives_idle = 300 # TCP_KEEPIDLE, in seconds; # 0 selects the system default #tcp_keepalives_interval = 0# TCP_KEEPINTVL, in seconds; # 0 selects the system default #tcp_keepalives_count = 0 And finally, the Sysctl.conf : net.ipv4.tcp_keepalive_time = 900 net.ipv4.tcp_keepalive_intvl = 60 net.ipv4.tcp_keepalive_probes = 9 Before that, the application was tested without using the firewall and everything worked fine. If you have any idea of why this is happening, I haven't found a solution yet. Regards, Luc D. - 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 iQIcBAEBCAAGBQJUy5PtAAoJEBzwKT+lPKRYqI4P/0kZuZuJCopHe88BXTNj/1O7 cEdmsoJq/7Ba/kLZ3/xqElzAjOQfnWK22GTCVGdsEou95MB4MspAcD8unGJgKiKs b1Ko/ixTN8irY7w5QGbXAv52NX9N/h9vrsr/EASxe/A8nSCSP9sjdh9Qr2OAOXBC 2FAMcpS3blpik78nFBBPkwJY5L3nhbkcEq0AMSqGGsfo+WJPFUtXBtzPO4JoAtGJ 8d1HxDd8PsL0tOMsqdIbJ9EqfW7Fano7ajk2Cu4gczGA3G3XlwsuHo5Glq9MSkzW DZYqxW3JwpgvMQO2o/vZyZcK7aqADqaMNE+sgaaAvRYbHzMtOTqCLebfLHqst17q eg+85Pm/5815SVvbW7kQX2Pv2bAs+bzyz7zdWk4KFdUaU1sD3bwNtkgWewNB/Gex jbZXLbKK27EFPd8M8W8PWd0x11veJ5hHEPyCWwM2njF5OoB3OSumY+yPUTWg/9oD 7xcFWjntybTHWpOcE5uxtPSzZqz1ctijiBvYo5DI8qh0W0CVsFYGGYmBucPcMc5M PapWz+jYPgqzxDIHq27jpqmDqch6h1EQCmj3rGriWifxl9qTw4WtDgL/9sEmmkjd NfysWjaNW+nqkt8qg6pmuHs0K1PLp2IO7C9jftE3jJ/lIZCy+yo+LSe2U7mhUvn9 Qj6PY8Ds4aaN0GzgUan/ =8zAr -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: JDBC authentication problem
2015-01-30 16:45 GMT+03:00 Luc DALLEMANE ldallem...@alaloop.com: Hi, I'm facing a problem with my web application. I'm using Tomcat 7.0.56, Java 1.8, Postgres 9.4 and Debian 7. The application is configured as followed : The web server is located in a DMZ. The database server is located in our LAN. To communicate with each other, a firewall has been setup (Cisco asa firewall) To authenticate an user to the website, I use the tomcat JDBC Realm. 1. Realm configuration =? Is it JDBCRealm or DataSourceRealm? If it is the former, then your Resource is not used at all. 2. Posting the actual password on a public mailing list? Consider it compromised. At the beginning, everything works fine, but after about an hour of inactivity, its impossible to authenticate again : Tomcat process seems to be running but doesn't log anything and doesn't answer any other requests. The firewall is rejecting the connection with the following message : Deny TCP (no connection) from WEB/50790 to DB/5432 FIN ACK on interface DMZ_clients I thought, the problem was after a while, if tomcat connexions were not used, the firewall would drop them. So, I tried to add keepAlive time-outs (tomcat site, postgres side, ) but none of them worked : Here is the tomcat context.xml : Resource name=jdbc/elkar auth=Container type=javax.sql.DataSource driverClassName=org.postgresql.Driver [...] / The postgresql.conf : # - TCP Keepalives - # see man 7 tcp for details #tcp_keepalives_idle = 300 # TCP_KEEPIDLE, in seconds; # 0 selects the system default #tcp_keepalives_interval = 0# TCP_KEEPINTVL, in seconds; # 0 selects the system default #tcp_keepalives_count = 0 And finally, the Sysctl.conf : net.ipv4.tcp_keepalive_time = 900 net.ipv4.tcp_keepalive_intvl = 60 net.ipv4.tcp_keepalive_probes = 9 Before that, the application was tested without using the firewall and everything worked fine. If you have any idea of why this is happening, I haven't found a solution yet. Regards, Luc D. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat sending 411 Length Required due to Chunked Transfer Encoding
Thank you for pointing out my error in assuming that it was Tomcat's fault. I have forwarded the issue to the application vendor to see if they can fix. I appreciate your time in responding to my question. I will consider this questions closed. On Thu, Jan 29, 2015 at 5:02 PM, Mark Thomas ma...@apache.org wrote: On 29/01/2015 22:29, Jeff Kohut wrote: My first post to Tomcat list, pardon me if I make any mistakes, Any help you can provide would be greatly appreciated. I have a Tomcat Server (V 7.0.54) running under Windows 2008 R2 With Service Pack 1 (and up to date on Security as well as OS patches). That server is running a vendor supplied group of applications via .war file as normal. to receive Soap/XML data from remote computer and process and return data back to calling application. The remote calling application hosted by IBM Websphere Application Server (running Axis2 jars) that is sending XML Soap data via a Post to the Tomcat Web server on port 8080/8443. If the amount of data is relatively small (i.e. 14 K) we have no problem receiving the data as Websphere is using Length Http 1.1 header and Tomcat sends the data to the application with no issue. However as the data gets larger, Websphere begins using Chunked Transfer Encoding and apparently Tomcat does not seem to like this as it returns Http 411 Length Required message. snip/ The mistake you have made is assuming that it is Tomcat internal code that is returning the 411. It isn't. Tomcat never sends that response code. It is the application that is processing the data and failing to handle the lack of content-length when chunked encoding is used. For the record, Tomcat handles chunked request bodies quite happily and we have a bunch of unit tests that cover this. You need to complain to the vendor that provides the applications you are running on your Tomcat instance. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Session being dropped in Virtual Host in 8.0.9
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Rory, On 1/30/15 6:08 AM, Rory Kelly wrote: I’m having a lot of trouble with maintaining a session in a Virtual Host environment on 8.0.9. I installed Tomcat through apt-get on an Ubuntu 14.04 server My application is a JRuby padrino bundled with Warbler, with 2 steps for logging in, a login page and a challenge page. The session persists from Login through to challenge, but appears to be dropped without any errors or warnings when I try to proceed from the Challenge page. I configured the virtual host using the following format: Host name=virtual1 appBase=virtual1 unpackWARs=true autoDeploy=true Valve className=org.apache.catalina.valves.AccessLogValve directory=logs prefix=test_access_log suffix=.txt pattern=%h %l %u %t quot;%rquot; %s %b / Aliastestsitex.site.io/Alias /Host No other configuration was done to the server. You might want a fully-qualified host name in the host's name field... or at least whatever your clients DNS will resolve to your server. That may actually be virtual1 but I just thought I'd mention it. It shouldn't have any bearing on the session-handling, unless your web application switches hostnames by telling a client requesting virtual1 that it should redirect to testsitex.site.io or vice-versa. When I run the site on my local Windows environment without Virtual Hosting, the session is maintained and I can log in. Is there something else I need to configure to ensure that the session is being maintained? Are you using cookies for session-tracking? Can you watch the HTTP conversation to see what's being sent back and forth during that workflow? LiveHttpHeaders is great for Firefox, and these days Chrome, Firefox, and IE have something similar built-into them. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUy5KNAAoJEBzwKT+lPKRYgnMP/2jDnAFvf0ga8DH+p6GMkyE0 uETGMF4TvWIIibavAqoRnFvNqVBFOkJDFKZGOc1rb2pBfD+LN+zPMQ5sAKyNRCYH mA/zBUGkyOLgIaM5oB9RWBGu4MrLs0YNelQSxlLrFUAp0GBt66y9Gc6EQWuk6zqf JqT1b1elHRqLeFChVhMBRABGC14u+czycgF9gy7WcDw5PwvYCyOY9yIYf+R0mkXc GExE9h9H/emUS5RtiuHrtgPXIhAOeleahiTCCj0TZbvpGb7axaOrR6aUutpbwNB5 JyFr1w86B2eQARlGBZ55JDi8NfiZaj+Cdarwos1od0bL5FHlTh7L5qEJDSC8RTAm HU68A5LvrAho+9Er4zGyOHUfcfdSGD/nEcX8Aqk5PpKjKjo3MZfuOa8/PqvMe8c8 02bRsXcj4AlImO70em/wHzeonnbnmRcm+wDN1f06s4lIlO93IFY24SBj+yP7kRds yV/pqcGVnZqcubUWxBq8KuBumVzX3GyLj6SzmKYVHY/g8UTOIaoA2H+yZ0bHTSwn XjAPN2R2vX+CaqWr/xsrl7Qh05CC+ugCpgTGy2xQamTgOiM0HmENvE5gdTpCxgZs bGm3lgT11CvgJybsQidfcTwzhp9JOuEyz7xP+bbA189OpFatR/kaMCUt5nsdKRg8 TUFjhv9QtjxXhsRVGR3U =qgxw -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How-to disable SSL V3 on Tomcat 6.0.18.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jason, On 1/30/15 4:32 AM, Jason Y wrote: Please refer to https://access.redhat.com/solutions/1232233 This link is /slightly/ out of date, in that it is missing more-recent information (i.e. support for TLSv1.1 and TLSv1.2 in tcnative versions after 1.1.21. By the way, why would you disable SSL? What is your current problem? I may have the same problem with tomcat 7.0.55... https://community.qualys.com/blogs/securitylabs/2014/10/15/ssl-3-is-dead-killed-by-the-poodle-attack - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUy5T+AAoJEBzwKT+lPKRYdBEQALUAXjY5wZHglrUU7vVQ00qd I1vdAhY5X6VXhfesK+cHYFdzIkedq15O+2J0MNY5G+SivUPXvWw1xd2VIflpsfCp VBf6/d3qHVRwmyAdYHWRtP6CRyWfvYY24YO/UO5EuD4Uellrr5DVEeZvfMnyuZJf IqnZ4NphqVNtar+EUkZ5FH1TyiVVDGmReZcEtLEA8Y2WJGUzcloALRoUMq8dmPQJ 4u38hDH/K0CpTsoxgQQJBtppFxxbK6c4klsTQO/eWZohSngL8JF0jPKiYjr3RFV6 4bT/2DNaoTENUiB8+9qLiGdWhRUofs8qM2/WXo4/Z4eekMSaqFCtRtW5gfelgIhn D750yqJZtycz+7X+jpnM2724SE3cPc2DxCXZ4mYGG2bH+LAi2bUOBkJYnhUbNpUB mtEkePXFgBjl4luP57w0+hIohH09q5E6a4206uQzN+0+MFgVtWu3498Ys9OSBO1q fMaiOk1vvcH3MELuOnseyKA3YyR2AppttQHp+6YJ7YePNx3EuewAoOEBLo2hP5tF zH4Uu1cUSRe/HSdsnwglHw/xzE9QOn5bc6s5lne0Y9E+8+CP+9cJcFV7D6dA6fDB ul0cuFbIoyHu2VhUmtnDvuxNS6/xgTy3Nioc0G6jdOTaqR7AxhQx/vyaruN+dGK+ w1vZbFCCmCe2toKLWdPy =D+1m -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: JDBC authentication problem
Ok, I'm going to try this. Hope this will help to solve my problem. Regards Luc D. -Message d'origine- De : Christopher Schultz [mailto:ch...@christopherschultz.net] Envoyé : vendredi 30 janvier 2015 15:24 À : Tomcat Users List Objet : Re: JDBC authentication problem -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Luc, On 1/30/15 9:05 AM, Luc DALLEMANE wrote: Thanks for the reply, it is the JDBCRealm not the data source. Your Resource configuration is therefore ignored. The JDBCRealm should really not be used at all. Switch to DataSourceRealm. If you don't like using your application's DataSource for authentication (some folks don't), then create a second DataSource just for authentication. The DataSourceRealm has some significant advantages, such as being able to use a configurable pool of Connections, instead of a single Connection like JDBCRealm does. This improved performance and allows for re-connections, etc. I think this will fix your immediate problem plus eliminate some other problems down the line (like performance). I have set this password for test only but it will be changed when everything will be ok and in production . (But didn't saw i had paste it ...) Good. :) - -chris -Message d'origine- De : Konstantin Kolinko [mailto:knst.koli...@gmail.com] Envoyé : vendredi 30 janvier 2015 14:52 À : Tomcat Users List Objet : Re: JDBC authentication problem 2015-01-30 16:45 GMT+03:00 Luc DALLEMANE ldallem...@alaloop.com: Hi, I'm facing a problem with my web application. I'm using Tomcat 7.0.56, Java 1.8, Postgres 9.4 and Debian 7. The application is configured as followed : The web server is located in a DMZ. The database server is located in our LAN. To communicate with each other, a firewall has been setup (Cisco asa firewall) To authenticate an user to the website, I use the tomcat JDBC Realm. 1. Realm configuration =? Is it JDBCRealm or DataSourceRealm? If it is the former, then your Resource is not used at all. 2. Posting the actual password on a public mailing list? Consider it compromised. At the beginning, everything works fine, but after about an hour of inactivity, its impossible to authenticate again : Tomcat process seems to be running but doesn't log anything and doesn't answer any other requests. The firewall is rejecting the connection with the following message : Deny TCP (no connection) from WEB/50790 to DB/5432 FIN ACK on interface DMZ_clients I thought, the problem was after a while, if tomcat connexions were not used, the firewall would drop them. So, I tried to add keepAlive time-outs (tomcat site, postgres side, ) but none of them worked : Here is the tomcat context.xml : Resource name=jdbc/elkar auth=Container type=javax.sql.DataSource driverClassName=org.postgresql.Driver [...] / The postgresql.conf : # - TCP Keepalives - # see man 7 tcp for details #tcp_keepalives_idle = 300 # TCP_KEEPIDLE, in seconds; # 0 selects the system default #tcp_keepalives_interval = 0# TCP_KEEPINTVL, in seconds; # 0 selects the system default #tcp_keepalives_count = 0 And finally, the Sysctl.conf : net.ipv4.tcp_keepalive_time = 900 net.ipv4.tcp_keepalive_intvl = 60 net.ipv4.tcp_keepalive_probes = 9 Before that, the application was tested without using the firewall and everything worked fine. If you have any idea of why this is happening, I haven't found a solution yet. Regards, Luc D. - 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 iQIcBAEBCAAGBQJUy5PtAAoJEBzwKT+lPKRYqI4P/0kZuZuJCopHe88BXTNj/1O7 cEdmsoJq/7Ba/kLZ3/xqElzAjOQfnWK22GTCVGdsEou95MB4MspAcD8unGJgKiKs b1Ko/ixTN8irY7w5QGbXAv52NX9N/h9vrsr/EASxe/A8nSCSP9sjdh9Qr2OAOXBC 2FAMcpS3blpik78nFBBPkwJY5L3nhbkcEq0AMSqGGsfo+WJPFUtXBtzPO4JoAtGJ 8d1HxDd8PsL0tOMsqdIbJ9EqfW7Fano7ajk2Cu4gczGA3G3XlwsuHo5Glq9MSkzW DZYqxW3JwpgvMQO2o/vZyZcK7aqADqaMNE+sgaaAvRYbHzMtOTqCLebfLHqst17q eg+85Pm/5815SVvbW7kQX2Pv2bAs+bzyz7zdWk4KFdUaU1sD3bwNtkgWewNB/Gex jbZXLbKK27EFPd8M8W8PWd0x11veJ5hHEPyCWwM2njF5OoB3OSumY+yPUTWg/9oD 7xcFWjntybTHWpOcE5uxtPSzZqz1ctijiBvYo5DI8qh0W0CVsFYGGYmBucPcMc5M PapWz+jYPgqzxDIHq27jpqmDqch6h1EQCmj3rGriWifxl9qTw4WtDgL/9sEmmkjd NfysWjaNW+nqkt8qg6pmuHs0K1PLp2IO7C9jftE3jJ/lIZCy+yo+LSe2U7mhUvn9 Qj6PY8Ds4aaN0GzgUan/ =8zAr -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail:
JDBC Fails to connect to SQL Server
Hi, I have Apache Solr hosted on Tomcat 6. There have been no changes to the code on Tomcat whatsoever.However for the last few days I now see this error in the Log files: SEVERE: Full Import failed Throwable occurred: org.apache.solr.handler.dataimport.DataImportHandlerException: Unable to execute query: SELECT ID, ENTRY_TYPE_REF, PROFILE_REF, ITEM_REF, TITLE, ABSTRACT, SOLUTION, SOLUTION_HTML, FREE_TEXT, DATE_UPDATED, ENTRY_TYPE, PROFILE_TYPE, SERVICE_TYPE FROM INFRA_KO_V Processing Document # 1 at org.apache.solr.handler.dataimport.DataImportHandlerException.wrapAndThrow(DataImportHandlerException.java:72) at org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator.init(JdbcDataSource.java:251) at org.apache.solr.handler.dataimport.JdbcDataSource.getData(JdbcDataSource.java:208) at org.apache.solr.handler.dataimport.JdbcDataSource.getData(JdbcDataSource.java:39) at org.apache.solr.handler.dataimport.SqlEntityProcessor.initQuery(SqlEntityProcessor.java:58) at org.apache.solr.handler.dataimport.SqlEntityProcessor.nextRow(SqlEntityProcessor.java:71) at org.apache.solr.handler.dataimport.EntityProcessorWrapper.nextRow(EntityProcessorWrapper.java:233) at org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:579) at org.apache.solr.handler.dataimport.DocBuilder.doFullDump(DocBuilder.java:260) at org.apache.solr.handler.dataimport.DocBuilder.execute(DocBuilder.java:184) at org.apache.solr.handler.dataimport.DataImporter.doFullImport(DataImporter.java:334) at org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:392) at org.apache.solr.handler.dataimport.DataImporter$1.run(DataImporter.java:373) *Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: The driver could not establish a secure connection to SQL Server by using Secure Sockets Layer (SSL) encryption. Error: SQL Server did not return a response. The connection has been closed..* at com.microsoft.sqlserver.jdbc.SQLServerConnection.terminate(SQLServerConnection.java:1368) at com.microsoft.sqlserver.jdbc.TDSChannel.enableSSL(IOBuffer.java:1412) at com.microsoft.sqlserver.jdbc.SQLServerConnection.connectHelper(SQLServerConnection.java:1058) at com.microsoft.sqlserver.jdbc.SQLServerConnection.login(SQLServerConnection.java:833) at com.microsoft.sqlserver.jdbc.SQLServerConnection.connect(SQLServerConnection.java:716) at com.microsoft.sqlserver.jdbc.SQLServerDriver.connect(SQLServerDriver.java:841) at org.apache.solr.handler.dataimport.JdbcDataSource$1.call(JdbcDataSource.java:160) at org.apache.solr.handler.dataimport.JdbcDataSource$1.call(JdbcDataSource.java:127) at org.apache.solr.handler.dataimport.JdbcDataSource.getConnection(JdbcDataSource.java:361) at org.apache.solr.handler.dataimport.JdbcDataSource.access$200(JdbcDataSource.java:39) at org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator.init(JdbcDataSource.java:238) ... 11 more *Caused by: java.io.IOException: SQL Server did not return a response. The connection has been closed.* at com.microsoft.sqlserver.jdbc.TDSChannel$SSLHandshakeInputStream.ensureSSLPayload(IOBuffer.java:513) at com.microsoft.sqlserver.jdbc.TDSChannel$SSLHandshakeInputStream.readInternal(IOBuffer.java:570) at com.microsoft.sqlserver.jdbc.TDSChannel$SSLHandshakeInputStream.read(IOBuffer.java:562) at com.microsoft.sqlserver.jdbc.TDSChannel$ProxyInputStream.readInternal(IOBuffer.java:757) at com.microsoft.sqlserver.jdbc.TDSChannel$ProxyInputStream.read(IOBuffer.java:745) at com.ibm.jsse2.b.a(b.java:286) at com.ibm.jsse2.b.a(b.java:67) at com.ibm.jsse2.SSLSocketImpl.a(SSLSocketImpl.java:313) at com.ibm.jsse2.SSLSocketImpl.h(SSLSocketImpl.java:63) at com.ibm.jsse2.SSLSocketImpl.a(SSLSocketImpl.java:316) at com.ibm.jsse2.SSLSocketImpl.startHandshake(SSLSocketImpl.java:220) at com.microsoft.sqlserver.jdbc.TDSChannel.enableSSL(IOBuffer.java:1379) ... 20 more I can confirmthat there has been no change to firewall settings etc . Need help on this. Regards Aniket
Re: How-to disable SSL V3 on Tomcat 6.0.18.0
Hi Jammy, Please refer to https://access.redhat.com/solutions/1232233 When using Tomcat with the JSSE connectors, the SSL protocol to be used can be configured via $TOMCAT_HOME/conf/server.xml. The following example shows how the sslProtocol in an https connector is configured. Tomcat 5 and 6 (prior to 6.0.38) Connector port=8443 protocol=org.apache.coyote.http11.Http11Protocol maxThreads=150 SSLEnabled=true scheme=https secure=true clientAuth=false sslProtocols = TLSv1,TLSv1.1,TLSv1.2 / Tomcat 6 (6.0.38 and later) and 7 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 / If the sslEnabledProtocols or sslProtocols attributes are specified, only protocols that are listed and supported by the SSL implementation will be enabled. If not specified, the JVM default is used. The permitted values may be obtained from the JVM documentation for the allowed values for algorithm when creating an SSLContext instance e.g. Oracle Java 6 and Oracle Java 7. By the way, why would you disable SSL? What is your current problem? I may have the same problem with tomcat 7.0.55... On Fri, Jan 30, 2015 at 2:44 PM, Terence M. Bandoian tere...@tmbsw.com wrote: On 1/29/2015 10:02 AM, Jammy Chen wrote: Hello Chuck, Thanks for replying, I understood this is old, our product has already upgraded to latest version, but somehow, some of our users are still in such old stage, they do not plan uptake now but they want disable SSL V3 as everybody know this is big security vulnerability. *so now the important thing is how I can disable SSL V3 on Tomcat 6.0.18.0? I cannot find the solution* Jammy 2015-01-29 22:00 GMT+08:00 Caldarale, Charles R chuck.caldar...@unisys.com : From: Jammy Chen [mailto:jamm...@gmail.com] Subject: How-to disable SSL V3 on Tomcat 6.0.18.0 Do everybody knows how-to disable SSL v3 in older tomcat version Server version: Apache Tomcat/6.0.18 Server built: Jul 22 2008 02:00:36 Yes - move up to a current level and read the docs. Seriously, if you're using a Tomcat of that vintage (this one is more than 6.5 years old), you have a lot more security issues to worry about than SSLv3. It's irresponsible not to upgrade. OS Name:Windows 2003 A few months from end-of-life. JVM Version:1.6.0-b105 Two years past end-of-life. Is there a pattern here? - Chuck Hi, Jammy- I'd suggest downloading Tomcat 6.0.18 which includes the then-current documentation. -Terence Bandoian - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: mod_jk and session stickiness
Am 30.01.2015 um 03:06 schrieb Christopher Schultz: On 7/23/14 5:14 PM, Christopher Schultz wrote: Rainer, On 7/23/14, 4:10 PM, Rainer Jung wrote: Am 23.07.2014 um 21:03 schrieb Christopher Schultz: On 7/23/14, 1:49 PM, Rainer Jung wrote: The other case, a request with an invalid session ID accessing a tomcat instance with activation disabled can IMHO be handled by a filter that - checks whether the request has a valid session using getSession(false), if it has one, let the request proceed - checks activation state, if active, let the request proceed - checks the request method, if not GET, let the request proceed - otherwise: - set the session cookie, e.g. JSESSIONID the an empty value - issue an external redirect to the same request URL - optional redirect loop detection: add a query string param or cookie that gets the local jvmRoute appended during each redirect. Before doing the redirect, check that the local jvmRoute is not already part of that token (we have already been here before) This would not really interfere with your saved requests: they would get a redirect which the browser follwos automatically and after that you will observe the normal behavior. This is exactly what I have implemented -- as a Filter since we can insert it before SecurityFilter intercepts the requests -- and my tests suggest that it will work correctly. I added code to strip-out any ;jsessionid path parameter from the URL ACK if it exists, but haven't done any of the redirect loop detection (yet). I think the loop detection is going to have to keep a running list of visited nodes which, in large clusters, could grow very large especially if the node names are long. I'll post my code when it's a little more featureful. As long as nothing goes wrong, the first redirect - having no more session info - should not end up in getting redirected as well, because it should only be send to an active node by mod_jk. So you can even stop redirecting if you detect, that it already happened once. For a large cluster that might be better. Multiple might happen (didn't check the code), if all active members are in error state. Even then one would not like to produce many of those redirects for one request, so again, only allowing one redirect might be the right solution. That's a good thought, and simplifies things. The request parameter could then just be a boolean flag and not actually identify the node that produced the redirect: any node considering redirecting simply would not redirect if that flag had been set. So, I've implemented all of the above and just given it a real test-drive in production. It seems to work well on the first shot. Good! I'll be testing it a bit more as time does on, actually. I also converted it to a Valve that I will propose to include in Tomcat once I get some real mileage on it. Was a Valve more useful than a filter? Did you need to access Tomcat internals? I also discovered that I'd like to have a new feature: the ability for a whitelisted client to ignore the re-balance rules and continue to contact the server. So, if you have a cluster member called, say, foo and you want to force your way into foo, you can make a request to any page with a jsessionid parameter: http://host/some_page;jsessionid=1234.foo mod_jk will send you to the foo node, even though it is in the DISABLED state. Normally, my Filter/Valve would see that you have no valid session (1234.foo is not valid) and perform a redirect without the jsessionid path parameter added, thus re-balancing you to another node. Instead, I've added the ability to configure an ignore cookie and cookie value (like ignore=SECRETCODE). If the client presents this cookie to the Filter/Valve, then it's business as usual. This allows a trusted user to log into the DISABLED node through the load-balancer to take a look around, make sure that things are working properly, etc. before re-enabling the node in the cluster. I'll give this a shot in the next few days, clean it all up, and publish it (soon?). That sounds useful. Thanks! Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
JDBC authentication problem
Hi, I'm facing a problem with my web application. I'm using Tomcat 7.0.56, Java 1.8, Postgres 9.4 and Debian 7. The application is configured as followed : The web server is located in a DMZ. The database server is located in our LAN. To communicate with each other, a firewall has been setup (Cisco asa firewall) To authenticate an user to the website, I use the tomcat JDBC Realm. At the beginning, everything works fine, but after about an hour of inactivity, its impossible to authenticate again : Tomcat process seems to be running but doesn't log anything and doesn't answer any other requests. The firewall is rejecting the connection with the following message : Deny TCP (no connection) from WEB/50790 to DB/5432 FIN ACK on interface DMZ_clients I thought, the problem was after a while, if tomcat connexions were not used, the firewall would drop them. So, I tried to add keepAlive time-outs (tomcat site, postgres side, ) but none of them worked : Here is the tomcat context.xml : Resource name=jdbc/elkar auth=Container type=javax.sql.DataSource driverClassName=org.postgresql.Driver url=jdbc:postgresql://10.2.1.128/elkar username=asa password=mei!z60Hm maxActive=100 maxIdle=20 maxWait=1 maxAge=6 removeAbandonned=true removeAbandonnedTimeout=60 keepAlive=true autoReconnect=true / The postgresql.conf : # - TCP Keepalives - # see man 7 tcp for details #tcp_keepalives_idle = 300 # TCP_KEEPIDLE, in seconds; # 0 selects the system default #tcp_keepalives_interval = 0# TCP_KEEPINTVL, in seconds; # 0 selects the system default #tcp_keepalives_count = 0 And finally, the Sysctl.conf : net.ipv4.tcp_keepalive_time = 900 net.ipv4.tcp_keepalive_intvl = 60 net.ipv4.tcp_keepalive_probes = 9 Before that, the application was tested without using the firewall and everything worked fine. If you have any idea of why this is happening, I haven't found a solution yet. Regards, Luc D.
RE: Problem with mod_jk JKStatus: where is the worker state property?
Hi Lorenzo, Am 30.01.2015 um 12:22 schrieb Lorenzo Maurizi - C.S.I.A. UniMC: Dear All, I need help on an issue I'm facing. I've tried to find an answer with the online documentation but I didn't succeed. I am trying to fix a munin plugin for monitoring the mod_jk ajp13 connector for apache. The mod_jk is version 1.2.37 (the default version for the Debian Wheezy package). The munin plugin reads the http://localhost/jk-status?mime=prop output and searches for the worker.workername.state value. But my jk-status mime=prop output does not contains that state row, while the State is correctly shown on HTML output of the jk-status. I looked at the changelog of mod-jk trying to find something about a change in the output of JKStatus, without success. Is it a bug of mod_jk ver. 1.2.37? state is only printed of the worker is a member of a load balancer. Otherwise there is no such thing as state. It is good practise to wrap even a single worker in a load balancer because of its enhanced failure detection and reporting. Even if you don't have a second worker to fail over. HTH Rainer Thank you very much for your help, I added a loadbalancer worker and it now works as expected! Best regards! Lorenzo M. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problem with mod_jk JKStatus: where is the worker state property?
Hi Lorenzo, Am 30.01.2015 um 12:22 schrieb Lorenzo Maurizi - C.S.I.A. UniMC: Dear All, I need help on an issue I'm facing. I've tried to find an answer with the online documentation but I didn't succeed. I am trying to fix a munin plugin for monitoring the mod_jk ajp13 connector for apache. The mod_jk is version 1.2.37 (the default version for the Debian Wheezy package). The munin plugin reads the http://localhost/jk-status?mime=prop output and searches for the worker.workername.state value. But my jk-status mime=prop output does not contains that state row, while the State is correctly shown on HTML output of the jk-status. I looked at the changelog of mod-jk trying to find something about a change in the output of JKStatus, without success. Is it a bug of mod_jk ver. 1.2.37? state is only printed of the worker is a member of a load balancer. Otherwise there is no such thing as state. It is good practise to wrap even a single worker in a load balancer because of its enhanced failure detection and reporting. Even if you don't have a second worker to fail over. HTH Rainer Output of my jk-status properties (I changed some values to anonymize it): 8- worker.server_name=193.x.x.x worker.server_port=80 worker.time_datetime=20150130121721 worker.time_tz=CET worker.time_unix=1422616641 worker.web_server=Apache/2.2.22 (Debian) mod_jk/1.2.37 mod_ssl/2.2.22 OpenSSL/1.0.1e worker.jk_version=mod_jk/1.2.37 worker.ajp_count=1 worker.ajp13.list=ajp13 worker.ajp13.type=ajp13 worker.ajp13.host=localhost worker.ajp13.port=8009 worker.ajp13.address=127.0.0.1:8009 worker.ajp13.connection_pool_timeout=1300 worker.ajp13.ping_timeout=1 worker.ajp13.connect_timeout=0 worker.ajp13.prepost_timeout=0 worker.ajp13.reply_timeout=0 worker.ajp13.retries=2 worker.ajp13.connection_ping_interval=0 worker.ajp13.recovery_options=0 worker.ajp13.max_packet_size=8192 worker.ajp13.used=174 worker.ajp13.errors=0 worker.ajp13.client_errors=0 worker.ajp13.reply_timeouts=0 worker.ajp13.transferred=5197555 worker.ajp13.read=121336154 worker.ajp13.busy=0 worker.ajp13.max_busy=1 worker.ajp13.connected=2 worker.ajp13.map_count=9 worker.ajp13.last_reset_at=1422616434 worker.ajp13.last_reset_ago=207 worker.ajp13.map.1.server=x.x.x [*:443] worker.ajp13.map.1.uri=/olat/raw/extensions/* worker.ajp13.map.1.type=Unmount Wildchar worker.ajp13.map.1.source=JkMount worker.ajp13.map.1.reply_timeout=-1 worker.ajp13.map.1.sticky_ignore=0 worker.ajp13.map.1.stateless=0 worker.ajp13.map.1.fail_on_status= worker.ajp13.map.1.active= worker.ajp13.map.1.disabled= worker.ajp13.map.1.stopped= worker.ajp13.map.1.use_server_errors=0 worker.ajp13.map.2.server=x.x.x [*:443] worker.ajp13.map.2.uri=/olat/raw/images/* worker.ajp13.map.2.type=Unmount Wildchar worker.ajp13.map.2.source=JkMount worker.ajp13.map.2.reply_timeout=-1 worker.ajp13.map.2.sticky_ignore=0 worker.ajp13.map.2.stateless=0 worker.ajp13.map.2.fail_on_status= worker.ajp13.map.2.active= worker.ajp13.map.2.disabled= worker.ajp13.map.2.stopped= worker.ajp13.map.2.use_server_errors=0 worker.ajp13.map.3.server=x.x.x [*:443] worker.ajp13.map.3.uri=/olat/raw/css/* worker.ajp13.map.3.type=Unmount Wildchar worker.ajp13.map.3.source=JkMount worker.ajp13.map.3.reply_timeout=-1 worker.ajp13.map.3.sticky_ignore=0 worker.ajp13.map.3.stateless=0 worker.ajp13.map.3.fail_on_status= worker.ajp13.map.3.active= worker.ajp13.map.3.disabled= worker.ajp13.map.3.stopped= worker.ajp13.map.3.use_server_errors=0 worker.ajp13.map.4.server=x.x.x [*:443] worker.ajp13.map.4.uri=/olat/raw/js/* worker.ajp13.map.4.type=Unmount Wildchar worker.ajp13.map.4.source=JkMount worker.ajp13.map.4.reply_timeout=-1 worker.ajp13.map.4.sticky_ignore=0 worker.ajp13.map.4.stateless=0 worker.ajp13.map.4.fail_on_status= worker.ajp13.map.4.active= worker.ajp13.map.4.disabled= worker.ajp13.map.4.stopped= worker.ajp13.map.4.use_server_errors=0 worker.ajp13.map.5.server=x.x.x [*:443] worker.ajp13.map.5.uri=/olat/raw/extensions* worker.ajp13.map.5.type=Unmount Wildchar worker.ajp13.map.5.source=JkMount worker.ajp13.map.5.reply_timeout=-1 worker.ajp13.map.5.sticky_ignore=0 worker.ajp13.map.5.stateless=0 worker.ajp13.map.5.fail_on_status= worker.ajp13.map.5.active= worker.ajp13.map.5.disabled= worker.ajp13.map.5.stopped= worker.ajp13.map.5.use_server_errors=0 worker.ajp13.map.6.server=x.x.x [*:443] worker.ajp13.map.6.uri=/olat/raw/images* worker.ajp13.map.6.type=Unmount Wildchar worker.ajp13.map.6.source=JkMount worker.ajp13.map.6.reply_timeout=-1 worker.ajp13.map.6.sticky_ignore=0 worker.ajp13.map.6.stateless=0 worker.ajp13.map.6.fail_on_status= worker.ajp13.map.6.active= worker.ajp13.map.6.disabled= worker.ajp13.map.6.stopped= worker.ajp13.map.6.use_server_errors=0 worker.ajp13.map.7.server=x.x.x [*:443] worker.ajp13.map.7.uri=/olat/raw/js* worker.ajp13.map.7.type=Unmount Wildchar worker.ajp13.map.7.source=JkMount worker.ajp13.map.7.reply_timeout=-1 worker.ajp13.map.7.sticky_ignore=0 worker.ajp13.map.7.stateless=0
Session being dropped in Virtual Host in 8.0.9
Hi, I’m having a lot of trouble with maintaining a session in a Virtual Host environment on 8.0.9. I installed Tomcat through apt-get on an Ubuntu 14.04 server My application is a JRuby padrino bundled with Warbler, with 2 steps for logging in, a login page and a challenge page. The session persists from Login through to challenge, but appears to be dropped without any errors or warnings when I try to proceed from the Challenge page. I configured the virtual host using the following format: Host name=virtual1 appBase=virtual1 unpackWARs=true autoDeploy=true Valve className=org.apache.catalina.valves.AccessLogValve directory=logs prefix=test_access_log suffix=.txt pattern=%h %l %u %t quot;%rquot; %s %b / Aliastestsitex.site.io/Alias /Host No other configuration was done to the server. When I run the site on my local Windows environment without Virtual Hosting, the session is maintained and I can log in. Is there something else I need to configure to ensure that the session is being maintained? Thanks, R Kelly
Problem with mod_jk JKStatus: where is the worker state property?
Dear All, I need help on an issue I'm facing. I've tried to find an answer with the online documentation but I didn't succeed. I am trying to fix a munin plugin for monitoring the mod_jk ajp13 connector for apache. The mod_jk is version 1.2.37 (the default version for the Debian Wheezy package). The munin plugin reads the http://localhost/jk-status?mime=prop output and searches for the worker.workername.state value. But my jk-status mime=prop output does not contains that state row, while the State is correctly shown on HTML output of the jk-status. I looked at the changelog of mod-jk trying to find something about a change in the output of JKStatus, without success. Is it a bug of mod_jk ver. 1.2.37? Thanks in advance. Regards. Lorenzo M. Output of my jk-status properties (I changed some values to anonymize it): 8- worker.server_name=193.x.x.x worker.server_port=80 worker.time_datetime=20150130121721 worker.time_tz=CET worker.time_unix=1422616641 worker.web_server=Apache/2.2.22 (Debian) mod_jk/1.2.37 mod_ssl/2.2.22 OpenSSL/1.0.1e worker.jk_version=mod_jk/1.2.37 worker.ajp_count=1 worker.ajp13.list=ajp13 worker.ajp13.type=ajp13 worker.ajp13.host=localhost worker.ajp13.port=8009 worker.ajp13.address=127.0.0.1:8009 worker.ajp13.connection_pool_timeout=1300 worker.ajp13.ping_timeout=1 worker.ajp13.connect_timeout=0 worker.ajp13.prepost_timeout=0 worker.ajp13.reply_timeout=0 worker.ajp13.retries=2 worker.ajp13.connection_ping_interval=0 worker.ajp13.recovery_options=0 worker.ajp13.max_packet_size=8192 worker.ajp13.used=174 worker.ajp13.errors=0 worker.ajp13.client_errors=0 worker.ajp13.reply_timeouts=0 worker.ajp13.transferred=5197555 worker.ajp13.read=121336154 worker.ajp13.busy=0 worker.ajp13.max_busy=1 worker.ajp13.connected=2 worker.ajp13.map_count=9 worker.ajp13.last_reset_at=1422616434 worker.ajp13.last_reset_ago=207 worker.ajp13.map.1.server=x.x.x [*:443] worker.ajp13.map.1.uri=/olat/raw/extensions/* worker.ajp13.map.1.type=Unmount Wildchar worker.ajp13.map.1.source=JkMount worker.ajp13.map.1.reply_timeout=-1 worker.ajp13.map.1.sticky_ignore=0 worker.ajp13.map.1.stateless=0 worker.ajp13.map.1.fail_on_status= worker.ajp13.map.1.active= worker.ajp13.map.1.disabled= worker.ajp13.map.1.stopped= worker.ajp13.map.1.use_server_errors=0 worker.ajp13.map.2.server=x.x.x [*:443] worker.ajp13.map.2.uri=/olat/raw/images/* worker.ajp13.map.2.type=Unmount Wildchar worker.ajp13.map.2.source=JkMount worker.ajp13.map.2.reply_timeout=-1 worker.ajp13.map.2.sticky_ignore=0 worker.ajp13.map.2.stateless=0 worker.ajp13.map.2.fail_on_status= worker.ajp13.map.2.active= worker.ajp13.map.2.disabled= worker.ajp13.map.2.stopped= worker.ajp13.map.2.use_server_errors=0 worker.ajp13.map.3.server=x.x.x [*:443] worker.ajp13.map.3.uri=/olat/raw/css/* worker.ajp13.map.3.type=Unmount Wildchar worker.ajp13.map.3.source=JkMount worker.ajp13.map.3.reply_timeout=-1 worker.ajp13.map.3.sticky_ignore=0 worker.ajp13.map.3.stateless=0 worker.ajp13.map.3.fail_on_status= worker.ajp13.map.3.active= worker.ajp13.map.3.disabled= worker.ajp13.map.3.stopped= worker.ajp13.map.3.use_server_errors=0 worker.ajp13.map.4.server=x.x.x [*:443] worker.ajp13.map.4.uri=/olat/raw/js/* worker.ajp13.map.4.type=Unmount Wildchar worker.ajp13.map.4.source=JkMount worker.ajp13.map.4.reply_timeout=-1 worker.ajp13.map.4.sticky_ignore=0 worker.ajp13.map.4.stateless=0 worker.ajp13.map.4.fail_on_status= worker.ajp13.map.4.active= worker.ajp13.map.4.disabled= worker.ajp13.map.4.stopped= worker.ajp13.map.4.use_server_errors=0 worker.ajp13.map.5.server=x.x.x [*:443] worker.ajp13.map.5.uri=/olat/raw/extensions* worker.ajp13.map.5.type=Unmount Wildchar worker.ajp13.map.5.source=JkMount worker.ajp13.map.5.reply_timeout=-1 worker.ajp13.map.5.sticky_ignore=0 worker.ajp13.map.5.stateless=0 worker.ajp13.map.5.fail_on_status= worker.ajp13.map.5.active= worker.ajp13.map.5.disabled= worker.ajp13.map.5.stopped= worker.ajp13.map.5.use_server_errors=0 worker.ajp13.map.6.server=x.x.x [*:443] worker.ajp13.map.6.uri=/olat/raw/images* worker.ajp13.map.6.type=Unmount Wildchar worker.ajp13.map.6.source=JkMount worker.ajp13.map.6.reply_timeout=-1 worker.ajp13.map.6.sticky_ignore=0 worker.ajp13.map.6.stateless=0 worker.ajp13.map.6.fail_on_status= worker.ajp13.map.6.active= worker.ajp13.map.6.disabled= worker.ajp13.map.6.stopped= worker.ajp13.map.6.use_server_errors=0 worker.ajp13.map.7.server=x.x.x [*:443] worker.ajp13.map.7.uri=/olat/raw/js* worker.ajp13.map.7.type=Unmount Wildchar worker.ajp13.map.7.source=JkMount worker.ajp13.map.7.reply_timeout=-1 worker.ajp13.map.7.sticky_ignore=0 worker.ajp13.map.7.stateless=0 worker.ajp13.map.7.fail_on_status= worker.ajp13.map.7.active= worker.ajp13.map.7.disabled= worker.ajp13.map.7.stopped= worker.ajp13.map.7.use_server_errors=0 worker.ajp13.map.8.server=x.x.x [*:443] worker.ajp13.map.8.uri=/olat/* worker.ajp13.map.8.type=Wildchar worker.ajp13.map.8.source=JkMount worker.ajp13.map.8.reply_timeout=-1
