Re: tcnative CVE-2015-4000 (Logjam)
Am 12.06.2015 um 04:01 schrieb Christopher Schultz: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Arthur, On 6/11/15 4:34 PM, Arthur Ramsey wrote: On 06/11/2015 02:35 PM, Christopher Schultz wrote: Arthur, On 6/11/15 2:14 PM, Arthur Ramsey wrote: Is anyone aware of a way to mitigate the Logjam attack with tomcat 7 and java 7? Disable DHE_EXPORT on the server? I believe I have, but Qualys SSL Server Test still fails me on the Logjam check. SSLCipherSuite=ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SH A256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-A ES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128- SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128 - -SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256- SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE- DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES25 6-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK You also have DHE-* ciphers in there, which is probably the problem. Remove those and I think Qualys will be happier. Really, who is using DHE in the first place? I use tcnative and openssl-1.0.2a both compiled from source in production today, but I would be open to JSSE too. I believe I need Java 8 to mitigate CVE-2015-4000 with JSSE. Why? See http://stackoverflow.com/questions/30352105/how-to-set-custom-dh-grou p-in-java-sslengine-to-prevent-logjam-attack Understood. I thought you just wanted to remove the EXPORT and DHE ciphers in general. Increasing the number of bits in the DH parameters will in fact require an upgrade. I don't see anyway to use a unique 2048-bit or greater DH group with tcnative currently. I believe you are correct; there is a bug in BZ: https://bz.apache.org/bugzilla/show_bug.cgi?id=56108 It looks like 1.1.34 will have this feature. You can build the current trunk of the 1.1 branch and probably be okay. Thanks, I'll give it a try. Scary to use in production, but it may be my best answer. I'm not sure if there is anything I can do at compile time. I'd rather not change the cipher suites as I want to maintain browser support. You should disable EXPORT certificates no matter what. Or were you talking about the DH parameters? I was talking about DH parameters. My server configuration passed the Qualys SSL Server Test with flying colors until Logjam, so I would be worried about regressions on other security fixes if I used JSSE. -chris - -chris There's two parts under Logjam: - a downgrade attack that makes the real attack very feasible. The downgrade only works if client and derver support the export ciphers (it is not necessary that they are the preferred ciphers) and the attacker is an active man-in-the-middle, ie. she can observe and change the communication. In this case the encryption can be forced to use a 512 Bit key and is relatively easy to break. To mitigate the downgrade attack, it should be posible to just disable export ciphers on the server side, which is doable per configuration. - in addition for non-export ciphers, key length of 768 bits and 1024 bits are assumed to be atackable depending on the computing ressources tha attacker has at her hand. 768 is expected to be breakable using academic computing ressources, 1024 bits using national computing resources. To mitigate this, one should use longer keys. I think that is not possible with current tcnative 1.1.33. Only the head of 1.1 has code to allow that. This code would - use a longer key automatically, if the key in the server certificate is longer. E.g. a 2048 bit RSA key would lead to using also a 2048 bit DHE key automatically. This 2048 DH params are standard DH params but should nevertheless be safe due to their length. - allows to add custom DH params to the certificate file to choose completely custom DH params. With existing 1.1.33 you can choose your cipher suite, so that non-DHE ciphers come first and set SSLHonorCipherOrder such that the client chooses the first matching cipher and DHE will likely not be used, only by client who do not support a cipher to the left of DHE in your cipher list. Note that old Java versions as clients (6, maybe 7 depending on patch level?) have a problem with DHE keys longer than 768 or 1024 bits (depending on JVM details). So by mitigating Logjam you might run into compatibility issues with those. It would be interesting to know, what details SSLLabs tell you, e.g. if they say you are vulnerable to the export downgrade attack (really bad), or just to your DH params should be longer. You can use the OpenSSL commandline client in version 1.0.2 to check, what param length a handshake results in: openssl s_client -connect www.example.com:443 -cipher EDH | \ grep Server Temp Key See: https://www.openssl.org/blog/ Regards, Rainer
Re: Apache Tomcat Multiple Vulnerabilities Prior To 7.0.50
On 12/06/2015 13:12, Kaggwa, John wrote: Hello, I would like some help with the issue listed below and how to configure it into my system. Upgrade to the latest stable 7.0.x release. Mark Name Apache Tomcat Multiple Vulnerabilities Prior To 7.0.50 Risk 4 Intrusive No Description Multiple vulnerabilities are present in some versions of Apache Tomcat. Observation Apache Tomcat is an open source software implementation of the Java Servlet and JavaServer Pages technologies. Multiple vulnerabilities are present in some versions of Apache Tomcat. The flaws lie in multiple components. Successful exploitation could allow an attacker to obtain sensitive information or to cause denial of service. All the best JOHN KAGGWA ASSISTANT IT MANAGER / W DOHA P.O Box 19573 / West Bay / Doha / Qatar T: 974-4453-5031 / F: 974-4453-5220 / M: 974-3017-7061 / E: john.kag...@whotels.com This electronic message transmission contains information from the Company that may be proprietary, confidential and/or privileged. The information is intended only for the use of the individual(s) or entity named above. If you are not the intended recipient, be aware that any disclosure, copying or distribution or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify the sender immediately by replying to the address listed in the From: field. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tcnative CVE-2015-4000 (Logjam)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Rainer, On 6/12/15 6:32 AM, Rainer Jung wrote: With existing 1.1.33 you can choose your cipher suite, so that non-DHE ciphers come first and set SSLHonorCipherOrder such that the client chooses the first matching cipher and DHE will likely not be used, only by client who do not support a cipher to the left of DHE in your cipher list. A slight correction: the *server* chooses the cipher suite to be used, not the client. Note that old Java versions as clients (6, maybe 7 depending on patch level?) have a problem with DHE keys longer than 768 or 1024 bits (depending on JVM details). So by mitigating Logjam you might run into compatibility issues with those. +1 It would be interesting to know, what details SSLLabs tell you, e.g. if they say you are vulnerable to the export downgrade attack (really bad), or just to your DH params should be longer. You can use the OpenSSL commandline client in version 1.0.2 to check, what param length a handshake results in: openssl s_client -connect www.example.com:443 -cipher EDH | \ grep Server Temp Key See: https://www.openssl.org/blog/ +1 - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVetd7AAoJEBzwKT+lPKRYN7AQAIWyRymVO3NYefp/tdMU/9Kf 2uTnWgmL9j7iI9EeF8RwKNNBQBLWxJItEipsn44z6Cx16yh+ZbbI0ePKvSE3UBlQ 9lJfgRtHNfOLkUZQ0NWgl+cSAs8dfctN5Qpv9kSetO/IylRQE35uMN3UubNzieoo qpS3ub28bstMVD7ATmgG7/Cyhap2IVbVVQ4/EiuaxuZkrE1Yp+JujJFJ1kktbync rWC3EvYfQm2cThFXhwZQlewOqysvNkFh4wKLQf+SuVrVqBdrZ5CjrfkqfsrFqhRo pORL+q60Ik+7vu6Cymb1GCgFU6nnb/NCe5yZ07jzcYg1ebmFuOL/cginrfzeirsU CwZf/7XOblJToYLNGP/G33lmREPc4h/QOfnvcakjznkeKMRB6ijFEvcYTh5EOPfd IaNCnAqhv+zD7R4W00QfMZRricUfrzhHlwGSoLrU49ct+wwbZXfqW8N2mQRz11Bx LdsOVp2mitFvCFq0rf/88ZER+ub12NVYWiuJERtpV4mS2r3Hkck2wnj5pYIeLtti 9gl/8E8dNF5tuE/XnLreynHkEiUZov5KLszIihj5tgSbEmQkcr17RtkhnbTYFHq8 PsakYpaxactc8nBXvoi7Ev25VtOFUJzbG+jtQsJSscaE4dF4RnfruliBfTuLVzAh /XqCtf1Q2y/9LW6EbRb4 =si8C -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
failing final step to update ssl certificate for tomcat6
I am trying to update my SSL certificate in tomcat. The webserver keeps sending the old expired certificate I am taking over from long gone admins with no config notes, but this should be straightforward. The certificate authority support suggests there might be another configuration..but this is the only server.xml for the app The best answer from the cert authority is that there is another keystore but the xml file points to where my keystore is. It passes all the tests except for the cert authorities final test. I installed and verified the keystore I restarted tomcat6 I believe the XML file says the keystore is keystoreFile=/opt/atlassian/confluence/conf/.keystore/ (see below) Even though I changed the password, it is still reading the old key. I am wondering if there is a stale certificate in memory. I cannot think of anything else. If that be the case can I clear that without a reboot? root@dvm7:/opt/atlassian/confluence/conf#server.xml Connector address=127.0.0.1 port=8443 maxHttpHeaderSize=8192 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false disableUploadTimeout=true acceptCount=100 scheme=https secure=true clientAuth=false sslProtocol=TLS SSLEnabled=true URIEncoding=UTF-8 keystorePass=dsgroot keystoreFile=/opt/atlassian/confluence/conf/.keystore/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Apache Tomcat Multiple Vulnerabilities Prior To 7.0.50
Hello, I would like some help with the issue listed below and how to configure it into my system. Name Apache Tomcat Multiple Vulnerabilities Prior To 7.0.50 Risk 4 Intrusive No Description Multiple vulnerabilities are present in some versions of Apache Tomcat. Observation Apache Tomcat is an open source software implementation of the Java Servlet and JavaServer Pages technologies. Multiple vulnerabilities are present in some versions of Apache Tomcat. The flaws lie in multiple components. Successful exploitation could allow an attacker to obtain sensitive information or to cause denial of service. All the best JOHN KAGGWA ASSISTANT IT MANAGER / W DOHA P.O Box 19573 / West Bay / Doha / Qatar T: 974-4453-5031 / F: 974-4453-5220 / M: 974-3017-7061 / E: john.kag...@whotels.com This electronic message transmission contains information from the Company that may be proprietary, confidential and/or privileged. The information is intended only for the use of the individual(s) or entity named above. If you are not the intended recipient, be aware that any disclosure, copying or distribution or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify the sender immediately by replying to the address listed in the From: field. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SSL on Tomcat 6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Adriano, On 6/11/15 3:54 PM, Adriano Matos Meier wrote: Exactly! When I run keytool -list ..., the PrivateKeyEntry now has the fingerprint for SSL certificate. I belived that I had lost private key, and I would have to do it all again (keystore/CSR/intermed/SSL). I still import the SSL certificate with alias tomcat, and it appears in keytool as a trustedCertEntry, with same fingerprint of the PrivateKeyEntry. Very crazy, but it works! Yes. You can, if you want to, remove the extra certificate: $ keytool -delete -alias server [...] - -chris Em Qui, 2015-06-11 às 15:37 -0400, Christopher Schultz escreveu: Adriano, On 6/11/15 2:31 PM, Adriano Matos Meier wrote: I had success when I re-import SSL certificate using same name alias of PrivateKeyEntry and name alias used when I generate CSR (repository). That was going to be my second suggestion. This is one more reason why I hate working with Java keystores: you have to import the signed certificate /on top of/ a previously-generated certificate? I don't understand why keytool always wants to create a self-signed certificate when you request a CSR. I just want a CSR, independent of the key and keystore. :( -chris Em Qui, 2015-06-11 às 09:59 -0400, Christopher Schultz escreveu: Adriano, On 6/11/15 9:45 AM, Adriano Matos Meier wrote: I tried to add keyAlias=server in my server.xml, but I received this error: What does keytool -list show for that keystore? It returns 3 entries: 1 PrivateKeyEntry (Private Key) - alias repository 1 trustedCertEntry (Intermediate certificate) - alias intermed 1 trustedCertEntry (SSL certificate) - alias server The keyAlias attribute is for a key, not a cert. You want: Connector ... keyAlias=repository ... / I could have sworn that you could also specify the alias of the certificate, but it looks like maybe not. You may have to remove the certificate called server and instead re-import the certificate using the alias tomcat. Try just using keyAlias=repository first. -chris Em Qui, 2015-06-11 às 09:35 -0400, Christopher Schultz escreveu: LifecycleException: service.getName(): Catalina; Protocol handler start failed: java.io.IOException: Alias name server does not identify a key entry The alias of SSL certificate needs to be same of CSR? What I did wrong? Can anybody help me? I appreciate any help! -chris -- - -- - - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --- - -- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - 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- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVetb0AAoJEBzwKT+lPKRYY34P/iM+FGsAA9tSbwDNSGdI7Bxy MZzMIfBKQ82/+oWok0yCjIzLqJgkkCYiH8R462pJR471D2cPzAgGA0ZfrDHsxPaq tppmpIql27VtT/tDWcYj9Y3TEdrzDT5aZeY07Iijfd5z+PcqJjIkA333oGF0mtD8 BAPme56UmfwfbyCdPspVodcjISY7JncqQx8uRLHAhGMKrusJ9j5wlzmlYB8eSwXp mpRFEGk6fufTwbjmiRBv3zKe3RvKzQYdRhG5XOwM5Jn7MN+47Yat8B3MEgWQX0wW QtrBgMfI1L0J1vz7FA7KsgZNQaxY7EAtPdLsJxsp/TWmNk+wQVu4dkKOymCHONnl QGYwqGlPZTvBCgteMU1x2/+inYD3UqgMxGwbO1pSdl7rUCtg+rwPakb4J7SfHYNs Q6b2aTPiwyPN+GwrrUkxUi24LXIOpiRQyG/++6FEMTrCujzsA24xFoGghw6Cd6Gg +y1kPuovEAflVDTib43zo7siTBzIOyVyLA5jSnD50TrJ6uwSYQtU8f1735U2+tt0 YlYSg4ye+JyHpCzaDeWztr40YjYBNBMgfxCmylNsvLpY43OlKj3xTd2VecjkonLC AFql0iFH78TMnuKfl2yMS4bTm43HcLe0B0IgGWskGGZUp5i5POUcFwqpUTu3r9Xf RwuxjK0lJFdU7X5PglnC =QREu -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Apache Tomcat Multiple Vulnerabilities Prior To 7.0.50
What is the correct way of installing it, because I had downloaded version apache-tomcat-8.0.23-windows-x64 All the best JOHN KAGGWA ASSISTANT IT MANAGER / W DOHA -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Friday, June 12, 2015 3:50 PM To: Tomcat Users List Subject: Re: Apache Tomcat Multiple Vulnerabilities Prior To 7.0.50 On 12/06/2015 13:12, Kaggwa, John wrote: Hello, I would like some help with the issue listed below and how to configure it into my system. Upgrade to the latest stable 7.0.x release. Mark Name Apache Tomcat Multiple Vulnerabilities Prior To 7.0.50 Risk 4 Intrusive No Description Multiple vulnerabilities are present in some versions of Apache Tomcat. Observation Apache Tomcat is an open source software implementation of the Java Servlet and JavaServer Pages technologies. Multiple vulnerabilities are present in some versions of Apache Tomcat. The flaws lie in multiple components. Successful exploitation could allow an attacker to obtain sensitive information or to cause denial of service. All the best JOHN KAGGWA ASSISTANT IT MANAGER / W DOHA P.O Box 19573 / West Bay / Doha / Qatar T: 974-4453-5031 / F: 974-4453-5220 / M: 974-3017-7061 / E: john.kag...@whotels.com This electronic message transmission contains information from the Company that may be proprietary, confidential and/or privileged. The information is intended only for the use of the individual(s) or entity named above. If you are not the intended recipient, be aware that any disclosure, copying or distribution or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify the sender immediately by replying to the address listed in the From: field. - 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 This electronic message transmission contains information from the Company that may be proprietary, confidential and/or privileged. The information is intended only for the use of the individual(s) or entity named above. If you are not the intended recipient, be aware that any disclosure, copying or distribution or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify the sender immediately by replying to the address listed in the From: field. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: General question about removeAbandoned property
On 12/06/2015 20:15, Balana, Vishal wrote: Hello, I am trying to find if removeAbandoned property set to True would leads a connection returned back to pool and available to be borrowed again? If not, am I one connection less in pool? Abandoned connections are removed from the pool. The pool will replace it as necessary. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Fwd: Apache Tomcat 7 -Parameters lost
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Kartheek, On 6/12/15 12:32 PM, kartheek desineedi wrote: We are facing a weird issue where a similar configuration is yielding unexpected results for consecutive requests on Tomcat 7.0.54. We have enabled the request dumper filter on Tomcat 7 and it shows that consecutive requests are missing the parameters. What do you mean consecutive requests? Due to this our application is throwing a backend error and giving a bad user experience of not letting the user complete a transaction. Did anyone face a similar issue on Tomcat 7 ?I can share more configuration files as required to help give more details on the issue. Did you follow-up on all the questions we've already asked, and the ideas we've presented? You have a handful of replies on your earlier thread. Helpful pointers are greatly appreciated. LOG link: http://www.filedropper.com/requestdumper TCP dump -8009 http://www.filedropper.com/tcpdump I looked, and these don't tell me anything. I have no idea what I'm looking at. Additional Info: We are not aware of any specific pattern.The transaction is going through Browser [HTTP | Port 80] Web Server [HTTP | Port 80] Mod JK [AJP 13 | Port 8009] Tomcat [AJP 13 | Port 8009].The parameters are submitted through a form POST.We roughly see this issue once in 5 times.The log which we shared is from the tomcat's request dumper filter which is supposedly the first filter before any of the application level filters are invoked which means that our application is not even receiving them.Hope this gives you a better idea. So, is the RequestDumperFilter seeing the parameters but your application is not? Or are you saying that not even the RequestDumperFilter is seeing the parameters? Added the tcp dump for port 8009 which is the last layer before the request dumper log and the parameters are found in both the cases.(please ignore the file name in the logs) - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVezQCAAoJEBzwKT+lPKRYZf8QAKsRxMbOHgEsyJIvX6hEgqvY SMnVGSdTaIuwcxUqyvsqzTGdjO2yG3dwZO8otd/IHHOLBVko5s/irAAnYVS0o517 OJFRI0XG1mtaHwVy3Z9xgCvxgL7pSLbLoVBA+5t+zJR28RM3hhc8pRGNB/mZ5gYS FBQGFFJkIwdIN4RZNa4Z38HjfaXBMSDj0Na9a3QzbTj6s8eJHECQ3W54WDlc21yf o4AoErgu+XjXrHRfung5XMmjYipL5lyXnf7xrZqiDC8D5kneqB1dPQRL5luj54X8 T9XfRgXv9gfBTquRhLy5nUqCbz88Rp+XxkefhRmk1MAegOAC1bA4+4b7W7HbfikS 1DwsUHKKxxwHX6whQaljyTRt6CZ3Yf7A1/bOVyhzb0WvehzGAX7Bxz2snbDMahbB h22SVCCLoK/2fsWXUuuTo+CDq5zQ0YW9trJiCidytLRjegvWqfpdf5MmkgpizhWm TecD73OdSclDJpGMNbAqSlbnlJbNLDnjD6Xfnq2CQdys+tmxoKbpuAfTGeKG8Ymu qWfinzdcQgE8T9tpPEa3CPD/ApqNTW++e9nqLHSCs+JhqK+eMWCIwAfRRw+QTYAf jADEX9KYUNTU3QRTb1wbIYIFFszdTUuyLnSiKt5B0KeV1Dhz6o848Yo++akLndJP 3iL4Bf6tO+ZIIeFUBoQ3 =f0fK -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Fwd: Apache Tomcat 7 -Parameters lost
kartheek desineedi wrote: Yes we upgraded to Apache Tomcat 7.0.62 but still the issue is persisting. Failed request filter did not filter out any params indicating that the parameters are not malformed. We are sending all the requests in the SAME manner while most of them succeed,few of them fail. Which class in the tomcat source should we try adding more debugging if need be? [...] Kartheek, Extraordinary claims require extraordinary evidence [Carl Sagan] Processing POST requests with parameters is what webservers do 99% of the time, and Tomcat is a webserver, with several hundred thousand installations. If several versions of Tomcat were just losing POST parameters randomly, it seems very unlikely that you would have been the first and only one to have noticed this and posted a message about this on the list. So, without getting very technical about it, I would suggest that there must be another explanation to your problem; and I would further suggest that you re-examine your evidence very carefully. Are you 100% sure that there is nothing in these requests which could prevent a correct parsing of these parameters ? And/or are you sure that when you compare the tcpdump log and the requests that you see in the request dumper log, you are indeed looking at the /same/ requests ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
General question about removeAbandoned property
Hello, I am trying to find if removeAbandoned property set to True would leads a connection returned back to pool and available to be borrowed again? If not, am I one connection less in pool? Thanks, Vishal
RE: Fwd: Apache Tomcat 7 -Parameters lost
From: André Warnier [mailto:a...@ice-sa.com] Subject: Re: Fwd: Apache Tomcat 7 -Parameters lost Are you 100% sure that there is nothing in these requests which could prevent a correct parsing of these parameters ? And/or are you sure that when you compare the tcpdump log and the requests that you see in the request dumper log, you are indeed looking at the /same/ requests ? And of course, there's the not unusual webapp logic error of storing a request or response reference somewhere it shouldn't so that it gets used by multiple threads or in multiple requests. The typical spot is a servlet instance field, but thread-locals and static variables are also problematic. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Fwd: Apache Tomcat 7 -Parameters lost
Thanks for your response Christopher. Consecutive requests in the sense when 5(for example) users send requests in the normal transaction flow,one of them fails. The logs at different layers of the request flow indicate that the parameters are being passed from the original request till the AJP port 8009 but in the request dumper logs we do NOT see those parameters. Since our application would receive the requests AFTER the request dumper filter it is obvious that the parameters are lost even before our application gets them. What would be the best log to look at in our case? Is there any additional logging/config that needs to be enabled at Tomcat layer? On Fri, Jun 12, 2015 at 2:33 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Kartheek, On 6/12/15 12:32 PM, kartheek desineedi wrote: We are facing a weird issue where a similar configuration is yielding unexpected results for consecutive requests on Tomcat 7.0.54. We have enabled the request dumper filter on Tomcat 7 and it shows that consecutive requests are missing the parameters. What do you mean consecutive requests? Due to this our application is throwing a backend error and giving a bad user experience of not letting the user complete a transaction. Did anyone face a similar issue on Tomcat 7 ?I can share more configuration files as required to help give more details on the issue. Did you follow-up on all the questions we've already asked, and the ideas we've presented? You have a handful of replies on your earlier thread. Helpful pointers are greatly appreciated. LOG link: http://www.filedropper.com/requestdumper TCP dump -8009 http://www.filedropper.com/tcpdump I looked, and these don't tell me anything. I have no idea what I'm looking at. Additional Info: We are not aware of any specific pattern.The transaction is going through Browser [HTTP | Port 80] Web Server [HTTP | Port 80] Mod JK [AJP 13 | Port 8009] Tomcat [AJP 13 | Port 8009].The parameters are submitted through a form POST.We roughly see this issue once in 5 times.The log which we shared is from the tomcat's request dumper filter which is supposedly the first filter before any of the application level filters are invoked which means that our application is not even receiving them.Hope this gives you a better idea. So, is the RequestDumperFilter seeing the parameters but your application is not? Or are you saying that not even the RequestDumperFilter is seeing the parameters? Added the tcp dump for port 8009 which is the last layer before the request dumper log and the parameters are found in both the cases.(please ignore the file name in the logs) - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVezQCAAoJEBzwKT+lPKRYZf8QAKsRxMbOHgEsyJIvX6hEgqvY SMnVGSdTaIuwcxUqyvsqzTGdjO2yG3dwZO8otd/IHHOLBVko5s/irAAnYVS0o517 OJFRI0XG1mtaHwVy3Z9xgCvxgL7pSLbLoVBA+5t+zJR28RM3hhc8pRGNB/mZ5gYS FBQGFFJkIwdIN4RZNa4Z38HjfaXBMSDj0Na9a3QzbTj6s8eJHECQ3W54WDlc21yf o4AoErgu+XjXrHRfung5XMmjYipL5lyXnf7xrZqiDC8D5kneqB1dPQRL5luj54X8 T9XfRgXv9gfBTquRhLy5nUqCbz88Rp+XxkefhRmk1MAegOAC1bA4+4b7W7HbfikS 1DwsUHKKxxwHX6whQaljyTRt6CZ3Yf7A1/bOVyhzb0WvehzGAX7Bxz2snbDMahbB h22SVCCLoK/2fsWXUuuTo+CDq5zQ0YW9trJiCidytLRjegvWqfpdf5MmkgpizhWm TecD73OdSclDJpGMNbAqSlbnlJbNLDnjD6Xfnq2CQdys+tmxoKbpuAfTGeKG8Ymu qWfinzdcQgE8T9tpPEa3CPD/ApqNTW++e9nqLHSCs+JhqK+eMWCIwAfRRw+QTYAf jADEX9KYUNTU3QRTb1wbIYIFFszdTUuyLnSiKt5B0KeV1Dhz6o848Yo++akLndJP 3iL4Bf6tO+ZIIeFUBoQ3 =f0fK -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- *Saludos,* Kartheek DVRK http://dreamchannel.bigrock.in
Re: Tomcat 8 DB Connection Pooling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Douglas, In addition to what Filip posted... On 6/11/15 12:18 PM, Douglas Schaible wrote: Good Day All, I am having a problem with a connection pool and I was hoping for some guidance. I have defined the connection pool below for two deployed applications to use. When I bounce the server I can see that it immediately crates 100 connections to the DB. (I am ok with this, but that is not what is specified in the config). When you start your application, does it load a bunch of stuff from the database? If you are fetching lots of connections and not returning them, you may see your connection count go up to 100 (the maxTotal value). Then when I access the application repeatedly very quickly new connections to the DB are created each time a page is called till it reaches about 150 and then future calls fail with the message com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: Too many connections” logged by the server. I would have expected the pool to stop handing-out connections at 100. But, if you don't have removeAbandoned and you aren't returning the connections properly, then the pool is full of connections that can't be used. If we don’t place any extra load on the server the number of connections to the DB are reduced to 1 or 2 after 24 hours and you get the error Timeout: Pool empty. Unable to fetch a connection in 30 seconds, none available[size:100; busy:100; idle:0; lastwait:3].” from one of the applications and the other application continues to work just fine. The other application likely is using a different pool. Where is that Resource defined? I believe that the DB, MySQL, is dropping the connection, but tomcat does not know that it has been dropped. I am looking for some guidance on how to tune this configuration. Any suggestions? Resource name=jdbc/PDB auth=Container type=javax.sql.DataSource factory=org.apache.tomcat.jdbc.pool.DataSourceFactory initialSize=10 maxTotal=100 maxIdle=5 maxWaitMillis=1 username=“xx password=“xx driverClassName=com.mysql.jdbc.Driver url=jdbc:mysql://x.xx.us-east-1.rds.amazonaws.com”/ Your error message says Unable to fetch a connection in 30 seconds, but your maxWaitMillis is 1 (10 seconds). Are you sure this is the configuration being used? - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVe0oJAAoJEBzwKT+lPKRYqIYP/Rk23OUojZFYjhxMBzan18hV KcT2znvisAupRth5zEKiHwABEDwhhy4YZiexyVmiixR91HuAtoI0PpvuhKs8j2uM h1a+sdwWfgZz/PapiGr4FgXc0TlAc84RRlEG//5APeHkyQfE2XiCCwhkW7Q2hP3u pcRirzbXbSnftwXAMCTdrr5p37bpO2pCFMxcw3lCk7galAatrfGg05mGWw8NbkTD vL6iLepzK7krtk1QZskCRZ2TXRJ5H8UQjXMraLf8CEMxreP4gL9PNwLSUv2gCxrg Gn0TAVagjYtTvBObVYZUrNQ0f97t3IMtwy1bfyXTxBul6pwSXiv9L9B2p63YDO6t A13qjn3JJ4b3nkIm+ikejEkQdu1dVS+sNOlp2zKDV31wiMXQEHPIt5cUo8gmkI/O 3RagTmCMQO8w/OaC96+vIAgHrnEeq+1bANpbGfghQHcwObwmJ3OeMFte7YvwlBBP zaECgLOsNMHhvvllO3UrY2jEI6OQomE4FReuCr76txi0F6EdvHTO3OsVKL0Sz4Bd 6L7OdpBSvENRNMpXWLSoyFdkm0HOmoA+HW7wJtCG5B06YXJO7RgHTkBk/3HQ0tIi YUG661S4GkObOg0FEHYJshlvHmb9lOYVRlHqqlBut8hXoZrTlW3ac3Hk5Qb0d6Dh zpbhalTCHqsbaR66OT3n =4vP4 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: TCP connections reuse
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Andy, On 6/12/15 12:35 PM, Wang, Andy wrote: Could this be as simple as the default keepaliveTimeout = 2 (i.e. 20s) This could certainly be the issue. Maxim, what does the timing look like with these events? 1. First HTTP request made 2. Connection is dropped 3. Second HTTP request is made (on a new connection) When do those things happen? You said you had protocol traces of everything. If #2 happens 20 seconds after #1, then I think you have your answer. - -chris From: Andy Wang [aw...@ptc.com] Sent: Friday, June 12, 2015 11:31 AM To: Tomcat Users List Subject: Re: TCP connections reuse Could this be as simple as the default keepaliveTimeout = 15000 (i.e. 15s) Andy On 06/12/2015 11:20 AM, Christopher Schultz wrote: Maxim, On 6/12/15 1:53 AM, Maxim Neshcheret wrote: According to http://docs.oracle.com/javase/6/docs/technotes/guides/net/http-keep ali ve.html connections in HTTP 1.1 http://docs.oracle.com/javase/6/docs/technotes/guides/net/http-kee pal ive.html%20connections%20in%20HTTP%201.1 are persistent by default. But if it is incorrect behavior in Java then maybe there is some way or configuration in Tomcat to put Keep-alive parameter in the response header? I do call HttpURLConnection.disconnect() only when client is stopped. Keep-alive is used for sure. I would expect the connection to be kept open unless you call disconnect. But you are creating a new HttpURLConnection each time and then discarding it. I'm not sure how the connection pooling works under the hood within the JVM. It used to be difficult to get the JVM to release a connection and actually terminate the TCP/IP connection. http://docs.oracle.com/javase/8/docs/technotes/guides/net/http-keepali ve .html Pay close attention to the remarks about stream-handling. Tomcat may close the connection under certain circumstances, usually error-related. If you are getting 200 OK responses from Tomcat, then I'm not sure why the TCP/IP connection would be dropped, unless Java thinks that 30 seconds is too long of an idle time to keep those connections open. Thanks, -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVezA+AAoJEBzwKT+lPKRYV6QP/RvmRCvEdPszj9KriN6P+6ab B5sqrB5mlNtfxvyv8k33EtJf3l6h/tQDYE2eOCN4MvKRAGf7XdhA7udYxXUYBDRQ vhHPoUIhqP32RmQwEBnB3i47xASHDg1G1F7Ttqw6wL9p48APr5IlIs47Pr61en0n 11pHTt+25bGr36NgK0UlIIzJzEpH/HYikLS/wfqYNoVXn7RczkzKDrxg0xwZRgbg TacT4zz1noCaNPOqM1Jjdn+7Ilq+fPabhW8cOXPhkBU0RCE58HdwQ5Fu8BEPx5Sp 6qFmjtAEsTEGHHSin10/6GFA6EAypDQXRTulFQpq5eIZLNSl+l7EeFfE98n4Qyqj xrNeXKX06qdPO0gzjA0Q064vu2ZFSSIDFp6/zGtMqLhPhbPPTS5A6zpvXOJcfW28 k6b+mdOVGSiJ8zjz1NgsRtqtbwm1+y+Uh/UPdMDf7KhmS2EtxDtw4h8JYvKprkeQ Jwgh99Qu1a/hAmSRmRXjmlaC1RRXlMJcoHezHAicvRlwv0fko7/p5aqhK5nbogO+ aZV3GbaGmwWtp6JN2oCK4PdoQfgQS6nUYMmWoIHHSd1lTs8TQranG6M/bITNFinM vcUUZn6cqy6o+X4E/wz1x0CMiUoVlGIJeZevq65lhiaEXL3I2NMpeJtqpNP3cIof y4Cg/KPPs/B8TfnLM9WP =bGdd -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Fwd: Apache Tomcat 7 -Parameters lost
Yes we upgraded to Apache Tomcat 7.0.62 but still the issue is persisting. Failed request filter did not filter out any params indicating that the parameters are not malformed. We are sending all the requests in the SAME manner while most of them succeed,few of them fail. Which class in the tomcat source should we try adding more debugging if need be? On Fri, Jun 12, 2015 at 3:34 PM, kartheek desineedi kartheekdesine...@gmail.com wrote: Thanks for your response Christopher. Consecutive requests in the sense when 5(for example) users send requests in the normal transaction flow,one of them fails. The logs at different layers of the request flow indicate that the parameters are being passed from the original request till the AJP port 8009 but in the request dumper logs we do NOT see those parameters. Since our application would receive the requests AFTER the request dumper filter it is obvious that the parameters are lost even before our application gets them. What would be the best log to look at in our case? Is there any additional logging/config that needs to be enabled at Tomcat layer? On Fri, Jun 12, 2015 at 2:33 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Kartheek, On 6/12/15 12:32 PM, kartheek desineedi wrote: We are facing a weird issue where a similar configuration is yielding unexpected results for consecutive requests on Tomcat 7.0.54. We have enabled the request dumper filter on Tomcat 7 and it shows that consecutive requests are missing the parameters. What do you mean consecutive requests? Due to this our application is throwing a backend error and giving a bad user experience of not letting the user complete a transaction. Did anyone face a similar issue on Tomcat 7 ?I can share more configuration files as required to help give more details on the issue. Did you follow-up on all the questions we've already asked, and the ideas we've presented? You have a handful of replies on your earlier thread. Helpful pointers are greatly appreciated. LOG link: http://www.filedropper.com/requestdumper TCP dump -8009 http://www.filedropper.com/tcpdump I looked, and these don't tell me anything. I have no idea what I'm looking at. Additional Info: We are not aware of any specific pattern.The transaction is going through Browser [HTTP | Port 80] Web Server [HTTP | Port 80] Mod JK [AJP 13 | Port 8009] Tomcat [AJP 13 | Port 8009].The parameters are submitted through a form POST.We roughly see this issue once in 5 times.The log which we shared is from the tomcat's request dumper filter which is supposedly the first filter before any of the application level filters are invoked which means that our application is not even receiving them.Hope this gives you a better idea. So, is the RequestDumperFilter seeing the parameters but your application is not? Or are you saying that not even the RequestDumperFilter is seeing the parameters? Added the tcp dump for port 8009 which is the last layer before the request dumper log and the parameters are found in both the cases.(please ignore the file name in the logs) - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVezQCAAoJEBzwKT+lPKRYZf8QAKsRxMbOHgEsyJIvX6hEgqvY SMnVGSdTaIuwcxUqyvsqzTGdjO2yG3dwZO8otd/IHHOLBVko5s/irAAnYVS0o517 OJFRI0XG1mtaHwVy3Z9xgCvxgL7pSLbLoVBA+5t+zJR28RM3hhc8pRGNB/mZ5gYS FBQGFFJkIwdIN4RZNa4Z38HjfaXBMSDj0Na9a3QzbTj6s8eJHECQ3W54WDlc21yf o4AoErgu+XjXrHRfung5XMmjYipL5lyXnf7xrZqiDC8D5kneqB1dPQRL5luj54X8 T9XfRgXv9gfBTquRhLy5nUqCbz88Rp+XxkefhRmk1MAegOAC1bA4+4b7W7HbfikS 1DwsUHKKxxwHX6whQaljyTRt6CZ3Yf7A1/bOVyhzb0WvehzGAX7Bxz2snbDMahbB h22SVCCLoK/2fsWXUuuTo+CDq5zQ0YW9trJiCidytLRjegvWqfpdf5MmkgpizhWm TecD73OdSclDJpGMNbAqSlbnlJbNLDnjD6Xfnq2CQdys+tmxoKbpuAfTGeKG8Ymu qWfinzdcQgE8T9tpPEa3CPD/ApqNTW++e9nqLHSCs+JhqK+eMWCIwAfRRw+QTYAf jADEX9KYUNTU3QRTb1wbIYIFFszdTUuyLnSiKt5B0KeV1Dhz6o848Yo++akLndJP 3iL4Bf6tO+ZIIeFUBoQ3 =f0fK -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- *Saludos,* Kartheek DVRK http://dreamchannel.bigrock.in -- *Saludos,* Kartheek DVRK http://dreamchannel.bigrock.in
Re: Fwd: Apache Tomcat 7 -Parameters lost
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Kartheek, On 6/12/15 4:41 PM, kartheek desineedi wrote: Yes we upgraded to Apache Tomcat 7.0.62 but still the issue is persisting. Failed request filter did not filter out any params indicating that the parameters are not malformed. We are sending all the requests in the SAME manner while most of them succeed,few of them fail. Which class in the tomcat source should we try adding more debugging if need be? Can you add this Filter to your web application to see if the problem is that the request itself is badly-formatted in some way? http://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#Failed_Reques t_Filter - -chris On Fri, Jun 12, 2015 at 3:34 PM, kartheek desineedi kartheekdesine...@gmail.com wrote: Thanks for your response Christopher. Consecutive requests in the sense when 5(for example) users send requests in the normal transaction flow,one of them fails. The logs at different layers of the request flow indicate that the parameters are being passed from the original request till the AJP port 8009 but in the request dumper logs we do NOT see those parameters. Since our application would receive the requests AFTER the request dumper filter it is obvious that the parameters are lost even before our application gets them. What would be the best log to look at in our case? Is there any additional logging/config that needs to be enabled at Tomcat layer? On Fri, Jun 12, 2015 at 2:33 PM, Christopher Schultz ch...@christopherschultz.net wrote: Kartheek, On 6/12/15 12:32 PM, kartheek desineedi wrote: We are facing a weird issue where a similar configuration is yielding unexpected results for consecutive requests on Tomcat 7.0.54. We have enabled the request dumper filter on Tomcat 7 and it shows that consecutive requests are missing the parameters. What do you mean consecutive requests? Due to this our application is throwing a backend error and giving a bad user experience of not letting the user complete a transaction. Did anyone face a similar issue on Tomcat 7 ?I can share more configuration files as required to help give more details on the issue. Did you follow-up on all the questions we've already asked, and the ideas we've presented? You have a handful of replies on your earlier thread. Helpful pointers are greatly appreciated. LOG link: http://www.filedropper.com/requestdumper TCP dump -8009 http://www.filedropper.com/tcpdump I looked, and these don't tell me anything. I have no idea what I'm looking at. Additional Info: We are not aware of any specific pattern.The transaction is going through Browser [HTTP | Port 80] Web Server [HTTP | Port 80] Mod JK [AJP 13 | Port 8009] Tomcat [AJP 13 | Port 8009].The parameters are submitted through a form POST.We roughly see this issue once in 5 times.The log which we shared is from the tomcat's request dumper filter which is supposedly the first filter before any of the application level filters are invoked which means that our application is not even receiving them.Hope this gives you a better idea. So, is the RequestDumperFilter seeing the parameters but your application is not? Or are you saying that not even the RequestDumperFilter is seeing the parameters? Added the tcp dump for port 8009 which is the last layer before the request dumper log and the parameters are found in both the cases.(please ignore the file name in the logs) -chris - - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- *Saludos,* Kartheek DVRK http://dreamchannel.bigrock.in -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVe0i4AAoJEBzwKT+lPKRYE5AP/3KWQvCuFd6A87/tLhzhVBf3 Itc755Kmiv/553bFwRrhg+a2dEEDACaTyfrl1kZBijg5U6nftQkL9GVJU3k/oLDf YaS2hkU1MpWhRbkp8RLxxzz+L0wPFZOw2ao/W8E9gWQRZOMJyYDFxKL0VcAJtTVR C9vgesIYzdN/P74HVsuZJuNo4jgOAG9O+ns8mC5/88k5ob7OULTvDto4m+BAGmTC bOD7hw7eA9CpdU79g5hrd//TLoMrDdrO3BUIbnN5SY0XROV6ceDIUsA0u5rYAuC9 GNsLdP8JvqqOMgCvl24Hu9bA72P8OEa3xQvhwnCFSJlooSAwZJbu6FmnYdymuKjj i77/x0+5z1vSja5Tzpd+lsFfPowq0kvHw3lWcPIA4q9zTDcJzn4PY4hhu+WxWBll tjFQwmxInRbV4P2/v0eyYzUYvbwD4wyik08ceYrPwEjfvoEFhDk28TgrxJggccck bPkP2puCEnPs2+DCoWQrxmNLtJaNbPv8Fu83/wbahf7IWLLu2NVJEa5aFH1I5fnl FWpLwmON/8b9j1G1GDq2p7Sn2jj619jHNk7Hs4fdNUIkrK2Qt1pOFpJqwsDL7Tuq UYt5fn5AweqZwHuAbiCeCVD+MRRx+sJcZxmMEQMMcndiQQVzqvKVwIXGqNQB1kYj RigdeTdAeJs2S08/uqp5 =oDRI -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8 DB Connection Pooling
Hi Chris, I have the connection pool defined in /etc/tomcat8/context.xml. Is that the wrong place the define it? Is what is defined there being copied into each application? I underplayed some sample application and I am now seeing 10 time the number of apps being deployed DB connections. I am creating war files from eclipse to be deployed. Should I be creating a context file in eclipse so that it is included in the war file? If yes, should I copy the context.xml from from /etc/tomcat8 and then remove the pool definition from that file and just have it in the one in the war file? Responses to the questions are below. I have also implemented what Filip recommended, however after 24 hours the app start intermittently failing and there are only 2 open connections to the DB. This is in the log: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: The last packet successfully received from the server was 79,290,702 milliseconds ago. The last packet sent successfully to the server was 79,290,702 milliseconds ago. is longer than the server configured value of 'wait_timeout'. You should consider either expiring and/or testing connection validity before use in your application, increasing the server configured values for client timeouts, or using the Connector/J connection property 'autoReconnect=true' to avoid this problem. 12-Jun-2015 16:51:55.659 WARNING [Tomcat JDBC Pool Cleaner[147643626:1434048550658]] org.apache.tomcat.jdbc.pool.ConnectionPool.abandon Connection has been abandoned PooledConnection[com.mysql.jdbc.JDBC4Connection@1fa3cd0e]:java.lang.Exception 79,290,702 milliseconds is ~22 hours if my calculations are correct. That is way way longer than what is specified. Here is what I added: logAbandoned=true removeAbandoned=true removeAbandonedTimeout=60 timeBetweenEvictionRunsMillis=15000 Thanks, Doug On Jun 12, 2015, at 4:07 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Douglas, In addition to what Filip posted... On 6/11/15 12:18 PM, Douglas Schaible wrote: Good Day All, I am having a problem with a connection pool and I was hoping for some guidance. I have defined the connection pool below for two deployed applications to use. When I bounce the server I can see that it immediately crates 100 connections to the DB. (I am ok with this, but that is not what is specified in the config). When you start your application, does it load a bunch of stuff from the database? If you are fetching lots of connections and not returning them, you may see your connection count go up to 100 (the maxTotal value). No, it does not. Both of the apps on the server only make connections to the DB in doGet and they do not have an init method. Then when I access the application repeatedly very quickly new connections to the DB are created each time a page is called till it reaches about 150 and then future calls fail with the message com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: Too many connections” logged by the server. I would have expected the pool to stop handing-out connections at 100. But, if you don't have removeAbandoned and you aren't returning the connections properly, then the pool is full of connections that can't be used. The server will make more than 100 connections, it will make about 150 and then start giving the error. If we don’t place any extra load on the server the number of connections to the DB are reduced to 1 or 2 after 24 hours and you get the error Timeout: Pool empty. Unable to fetch a connection in 30 seconds, none available[size:100; busy:100; idle:0; lastwait:3].” from one of the applications and the other application continues to work just fine. The other application likely is using a different pool. Where is that Resource defined? it uses the same pool. The pool is defined in /etc/tomcat8/context.xml. There is only one Resource I believe that the DB, MySQL, is dropping the connection, but tomcat does not know that it has been dropped. I am looking for some guidance on how to tune this configuration. Any suggestions? Resource name=jdbc/PDB auth=Container type=javax.sql.DataSource factory=org.apache.tomcat.jdbc.pool.DataSourceFactory initialSize=10 maxTotal=100 maxIdle=5 maxWaitMillis=1 username=“xx password=“xx driverClassName=com.mysql.jdbc.Driver url=jdbc:mysql://x.xx.us-east-1.rds.amazonaws.com”/ Your error message says Unable to fetch a connection in 30 seconds, but your maxWaitMillis is 1 (10 seconds). Are you sure this is the configuration being used? Yes. I am not sure why the timeout is different or more connections are made than expected. If I removed the configuration from context.xml and bounce the server all of the connection attempts the DB fail, so I believe that config is being used. -
Re: Apache Tomcat Multiple Vulnerabilities Prior To 7.0.50
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 John, On 6/12/15 8:56 AM, Kaggwa, John wrote: What is the correct way of installing it, because I had downloaded version apache-tomcat-8.0.23-windows-x64 Do you want to install Tomcat 7 (like the OP seems to want to do), or do you want to install Tomcat 8? If you are going from Tomcat 7 to Tomcat 8, there's always this guide: http://tomcat.apache.org/migration-8.html - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVewPJAAoJEBzwKT+lPKRY10cP/0V7dP3JPSlQ2JjNqlxzSoED y3X4JLr1E4L6Mtb27WdvkuPwLCCPPLk2efxVpG9w6l+nHsjRW9aOqVzB6GsHzOJn ZsRtkJxJQ146A9fwCDUkyogWzUdBF37lyEADK+swF3mUiAC/48GTC28ppzvfxDQ8 V2MmjYEq2T9ZBCIS4G1yNscUwn5WUbYU4lQFvdopGFX4+BMwOz0fzFeKXqa1U/i4 2Y+0OPeV7Xrhqmyvg+VgsTgZrx1tk1Za3c19cxS/TdTTtl75FCuG67y50QJTs8Ad Ip9VIDYs2N74+YIyy6/UUgKqZFXaJb1Pc6dy99BlwCU/gEcvncPEXpkP8g85yIO2 LF5HdDYn+zx9DAWC5JMtQOHt0gzp4/n9/CNNZlU+HWt8lzzUVfwO07jP58qHYwFR 6DFB7IZ+WFMF+Hc+ktdftwdXnqaKmKAWNeIe+9mw9ljvnr7HGx49KYBHbdXrBBpZ /grYyS8YmpRupPN2O/xRNcS9SAtIw1jGoUre3Pa9jQDoasSlxIhLqIre8OfPOwZP pO9yWwPQMWj6sv2PCRPrYz4z+fy2mCs7hFb9qlAkIJyAJdcztztU4aiJd78YxI3D agyYTLbdxLHkCvXzauB9vM6NDAHikSHP9+9VDF54dvqWp6iOyJcT0aq6HCIVPEmT 1m4yoW+eqYJrg0c4Dclo =5zXg -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: TCP connections reuse
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Maxim, On 6/12/15 1:53 AM, Maxim Neshcheret wrote: According to http://docs.oracle.com/javase/6/docs/technotes/guides/net/http-keepali ve.html connections in HTTP 1.1 http://docs.oracle.com/javase/6/docs/technotes/guides/net/http-keepal ive.html%20connections%20in%20HTTP%201.1 are persistent by default. But if it is incorrect behavior in Java then maybe there is some way or configuration in Tomcat to put Keep-alive parameter in the response header? I do call HttpURLConnection.disconnect() only when client is stopped. Keep-alive is used for sure. I would expect the connection to be kept open unless you call disconnect. But you are creating a new HttpURLConnection each time and then discarding it. I'm not sure how the connection pooling works under the hood within the JVM. It used to be difficult to get the JVM to release a connection and actually terminate the TCP/IP connection. http://docs.oracle.com/javase/8/docs/technotes/guides/net/http-keepalive .html Pay close attention to the remarks about stream-handling. Tomcat may close the connection under certain circumstances, usually error-related. If you are getting 200 OK responses from Tomcat, then I'm not sure why the TCP/IP connection would be dropped, unless Java thinks that 30 seconds is too long of an idle time to keep those connections open. Thanks, - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVewa7AAoJEBzwKT+lPKRYke0QALlr4G7IZueNeG90NCsMhY4Y iU4RsiXDFRBgb3Wd9X305yyYiULzRB2u7TXAirB2vXttJiBmXR6v9cKqxW2DdgDZ cRRd+ymQbDyhhO3RDodVDQp8OAf3YlXoTH+zIvSYYFnzo148iuHxLyLrXyyHkfv2 wf5zwVjLVH0Pu7ndTbu23kJ6zhMKrOzzgKa1t/iWOa9LqxE6vht9d24HYzyluZoQ xnmkovYf2bNo4pVw4xcg9QNeeIDAnRBBcusNr4qUjif14pA7fmbliTPBtzFTyi9/ AuFlNdIJtz5zLXhTopjLwkrNDyx3AFwo0UQrlpoaoURAvVhDri5PlphDM94TyLBx VRPeChq1Tj0wnAP/j1wqr6VEyC30AZ/w/z89zwy1SpTE7ywUwmJmamFcSVoUTOjL U9J78+29pzlzcFj1OR0lh5xXMjL0yXmcLXSmKNWp0AwbVQacV5PSz5QqM32zM9Bn 1sOndI24BXcl3VyXPai9JdmxgoowGCszis+xCn+yuDwE5moeBV7xmeQtdagnhFex oBzGNDH/K/Up/Kh2bUxPXM0Ij0ksG6L8s8WTuyu1Tctly0NG5piW2xDwjs9nbomc qKQvfjnd5zI3ps6CyE/ZTa0LacyolaRgWVxXoZZ9En4bUVVexOHLllzc7e7uban4 C4Tgxbwn1lMQ8+GLYYrd =AbYE -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: TCP connections reuse
Could this be as simple as the default keepaliveTimeout = 15000 (i.e. 15s) Andy On 06/12/2015 11:20 AM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Maxim, On 6/12/15 1:53 AM, Maxim Neshcheret wrote: According to http://docs.oracle.com/javase/6/docs/technotes/guides/net/http-keepali ve.html connections in HTTP 1.1 http://docs.oracle.com/javase/6/docs/technotes/guides/net/http-keepal ive.html%20connections%20in%20HTTP%201.1 are persistent by default. But if it is incorrect behavior in Java then maybe there is some way or configuration in Tomcat to put Keep-alive parameter in the response header? I do call HttpURLConnection.disconnect() only when client is stopped. Keep-alive is used for sure. I would expect the connection to be kept open unless you call disconnect. But you are creating a new HttpURLConnection each time and then discarding it. I'm not sure how the connection pooling works under the hood within the JVM. It used to be difficult to get the JVM to release a connection and actually terminate the TCP/IP connection. http://docs.oracle.com/javase/8/docs/technotes/guides/net/http-keepalive .html Pay close attention to the remarks about stream-handling. Tomcat may close the connection under certain circumstances, usually error-related. If you are getting 200 OK responses from Tomcat, then I'm not sure why the TCP/IP connection would be dropped, unless Java thinks that 30 seconds is too long of an idle time to keep those connections open. Thanks, - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVewa7AAoJEBzwKT+lPKRYke0QALlr4G7IZueNeG90NCsMhY4Y iU4RsiXDFRBgb3Wd9X305yyYiULzRB2u7TXAirB2vXttJiBmXR6v9cKqxW2DdgDZ cRRd+ymQbDyhhO3RDodVDQp8OAf3YlXoTH+zIvSYYFnzo148iuHxLyLrXyyHkfv2 wf5zwVjLVH0Pu7ndTbu23kJ6zhMKrOzzgKa1t/iWOa9LqxE6vht9d24HYzyluZoQ xnmkovYf2bNo4pVw4xcg9QNeeIDAnRBBcusNr4qUjif14pA7fmbliTPBtzFTyi9/ AuFlNdIJtz5zLXhTopjLwkrNDyx3AFwo0UQrlpoaoURAvVhDri5PlphDM94TyLBx VRPeChq1Tj0wnAP/j1wqr6VEyC30AZ/w/z89zwy1SpTE7ywUwmJmamFcSVoUTOjL U9J78+29pzlzcFj1OR0lh5xXMjL0yXmcLXSmKNWp0AwbVQacV5PSz5QqM32zM9Bn 1sOndI24BXcl3VyXPai9JdmxgoowGCszis+xCn+yuDwE5moeBV7xmeQtdagnhFex oBzGNDH/K/Up/Kh2bUxPXM0Ij0ksG6L8s8WTuyu1Tctly0NG5piW2xDwjs9nbomc qKQvfjnd5zI3ps6CyE/ZTa0LacyolaRgWVxXoZZ9En4bUVVexOHLllzc7e7uban4 C4Tgxbwn1lMQ8+GLYYrd =AbYE -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Fwd: Apache Tomcat 7 -Parameters lost
Hi all, We are facing a weird issue where a similar configuration is yielding unexpected results for consecutive requests on Tomcat 7.0.54. We have enabled the request dumper filter on Tomcat 7 and it shows that consecutive requests are missing the parameters. Due to this our application is throwing a backend error and giving a bad user experience of not letting the user complete a transaction. Did anyone face a similar issue on Tomcat 7 ?I can share more configuration files as required to help give more details on the issue. Helpful pointers are greatly appreciated. LOG link: http://www.filedropper.com/requestdumper TCP dump -8009 http://www.filedropper.com/tcpdump Additional Info: We are not aware of any specific pattern.The transaction is going through Browser [HTTP | Port 80] Web Server [HTTP | Port 80] Mod JK [AJP 13 | Port 8009] Tomcat [AJP 13 | Port 8009].The parameters are submitted through a form POST.We roughly see this issue once in 5 times.The log which we shared is from the tomcat's request dumper filter which is supposedly the first filter before any of the application level filters are invoked which means that our application is not even receiving them.Hope this gives you a better idea. Added the tcp dump for port 8009 which is the last layer before the request dumper log and the parameters are found in both the cases.(please ignore the file name in the logs) -- *Saludos,* Kartheek DVRK http://dreamchannel.bigrock.in
RE: TCP connections reuse
Sorry, correction: default keepalivetimeout = connectionTimeout = 2 (20s) Andy From: Andy Wang [aw...@ptc.com] Sent: Friday, June 12, 2015 11:31 AM To: Tomcat Users List Subject: Re: TCP connections reuse Could this be as simple as the default keepaliveTimeout = 15000 (i.e. 15s) Andy On 06/12/2015 11:20 AM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Maxim, On 6/12/15 1:53 AM, Maxim Neshcheret wrote: According to http://docs.oracle.com/javase/6/docs/technotes/guides/net/http-keepali ve.html connections in HTTP 1.1 http://docs.oracle.com/javase/6/docs/technotes/guides/net/http-keepal ive.html%20connections%20in%20HTTP%201.1 are persistent by default. But if it is incorrect behavior in Java then maybe there is some way or configuration in Tomcat to put Keep-alive parameter in the response header? I do call HttpURLConnection.disconnect() only when client is stopped. Keep-alive is used for sure. I would expect the connection to be kept open unless you call disconnect. But you are creating a new HttpURLConnection each time and then discarding it. I'm not sure how the connection pooling works under the hood within the JVM. It used to be difficult to get the JVM to release a connection and actually terminate the TCP/IP connection. http://docs.oracle.com/javase/8/docs/technotes/guides/net/http-keepalive .html Pay close attention to the remarks about stream-handling. Tomcat may close the connection under certain circumstances, usually error-related. If you are getting 200 OK responses from Tomcat, then I'm not sure why the TCP/IP connection would be dropped, unless Java thinks that 30 seconds is too long of an idle time to keep those connections open. Thanks, - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVewa7AAoJEBzwKT+lPKRYke0QALlr4G7IZueNeG90NCsMhY4Y iU4RsiXDFRBgb3Wd9X305yyYiULzRB2u7TXAirB2vXttJiBmXR6v9cKqxW2DdgDZ cRRd+ymQbDyhhO3RDodVDQp8OAf3YlXoTH+zIvSYYFnzo148iuHxLyLrXyyHkfv2 wf5zwVjLVH0Pu7ndTbu23kJ6zhMKrOzzgKa1t/iWOa9LqxE6vht9d24HYzyluZoQ xnmkovYf2bNo4pVw4xcg9QNeeIDAnRBBcusNr4qUjif14pA7fmbliTPBtzFTyi9/ AuFlNdIJtz5zLXhTopjLwkrNDyx3AFwo0UQrlpoaoURAvVhDri5PlphDM94TyLBx VRPeChq1Tj0wnAP/j1wqr6VEyC30AZ/w/z89zwy1SpTE7ywUwmJmamFcSVoUTOjL U9J78+29pzlzcFj1OR0lh5xXMjL0yXmcLXSmKNWp0AwbVQacV5PSz5QqM32zM9Bn 1sOndI24BXcl3VyXPai9JdmxgoowGCszis+xCn+yuDwE5moeBV7xmeQtdagnhFex oBzGNDH/K/Up/Kh2bUxPXM0Ij0ksG6L8s8WTuyu1Tctly0NG5piW2xDwjs9nbomc qKQvfjnd5zI3ps6CyE/ZTa0LacyolaRgWVxXoZZ9En4bUVVexOHLllzc7e7uban4 C4Tgxbwn1lMQ8+GLYYrd =AbYE -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: failing final step to update ssl certificate for tomcat6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dan, On 6/12/15 8:37 AM, Dan Hyatt wrote: I am trying to update my SSL certificate in tomcat. The webserver keeps sending the old expired certificate I am taking over from long gone admins with no config notes, but this should be straightforward. The certificate authority support suggests there might be another configuration..but this is the only server.xml for the app The best answer from the cert authority is that there is another keystore but the xml file points to where my keystore is. It passes all the tests except for the cert authorities final test. I installed and verified the keystore I restarted tomcat6 I believe the XML file says the keystore is keystoreFile=/opt/atlassian/confluence/conf/.keystore/ (see below) Even though I changed the password, it is still reading the old key. I am wondering if there is a stale certificate in memory. I cannot think of anything else. If that be the case can I clear that without a reboot? Assuming that you have restarted Tomcat successfully, a reboot should not be necessary. You did restart Tomcat, right? root@dvm7:/opt/atlassian/confluence/conf#server.xml Is that # symbol in the path a typo? Connector address=127.0.0.1 port=8443 maxHttpHeaderSize=8192 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false disableUploadTimeout=true acceptCount=100 scheme=https secure=true clientAuth=false sslProtocol=TLS SSLEnabled=true URIEncoding=UTF-8 keystorePass=dsgroot keystoreFile=/opt/atlassian/confluence/conf/.keystore/ Does your keystore not have a password? Not that it really matters, but keystores typically have passwords. What does this command show: $ keytool -list -keystore /opt/atlassian/confluence/conf/.keystore You might want to consider running your server against ssllabs's SSL test and then modifying your cipher suites configuration. There are a number of cipher suites that have been deemed problematic lately that you'll want to disable. Unfortunately, since you are using a JSSE-based TLS implementation (that Java one), you have to white-list your ciphers and list them all, rather than black-listing the known bad ones. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVev+ZAAoJEBzwKT+lPKRYjB8QALJEM2gm6TpCObMo+3HaxvoQ p1v5wPjeciXNS9cWF3c4cXOwZiR9NDwI643qQ9dYT0ElfNztRDPXoCp/AeVJg1T/ WZe/6TGuGJiLBphHX6VKRyM1V9RMyJDLWJZm7Qljq/VDHWOMmi0la9oY+moXBwmG tasBwsbdBfJ5Fy58DphPKHrEwAPP0C3yxbXDkz0H6PU36Pyx7I3ehwsty0KDrlRB A+nscl8/AGiVuN7Kx2aCc3mgJzamQs8L/dEM82SdRUTI+N9DqBZ4+L4WAjREmz74 NmV8rj/GAfrXwU5BDcY7bXnBBWY8+2PQ4LBCm8ZO5PPavbkSwR1yOIIREJRoPkuw xo0e17/wqUSa4DvGQTs5mFZoSKj8JQeNsatc8yHhkovFzlw60Xg497Aayl2CXaXG HAozhJTStUDjaOw0kpGmT/jH5afAt0C/KcIyjaZa5Zsm8K5K6ngLgvNsXB9YtsDX XsVPim2gpM+PMG1lfAOL9ag8odt1U8iNlaLrELGqvkE5fsIDYImjvHenKvsaiIoo eMSr4SvGWEZEHueGv0XmncPBq0t8TEFGORLoqfSzhxyRMniM+r/p12aA5qkhuPyr cnNcnJfTry4yuBDCjARfoUHR0X3UX5xyGEdae2p6sRtumRolEIdAAxdsZs+gez0X 9eedkrRlGbdx4kErxfQI =bEj5 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
