Re: [OT] Red Hat / CentOS specific question about certificates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Daniel, On 8/31/20 16:28, Christopher Schultz wrote: > Daniel, > > On 8/31/20 11:36, Daniel Savard wrote: >> Le lun. 31 août 2020 à 11:13, Christopher Schultz < >> ch...@christopherschultz.net> a écrit : > >>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 >>> >>> >>> Daniel, >>> >>> On 8/28/20 20:46, Daniel Savard wrote: Le ven. 28 août 2020 à 17:19, Darryl Philip Baker < darryl.ba...@northwestern.edu> a écrit : > I am having an issue that I don’t understand. On > RHEL6/CentOS and earlier my predecessors would put > self-signed certificates they wanted to trust in > /etc/pki/ca-trust/extracted/java/cacerts and it was good > for the life of the machine. On RHEL7 and I assume CentOS7 > that file is part of a package that is getting updated as > part of the regular patches. That wipes out our > self-signed certificates. The way I understand the > directions from Red Hat we should put the certificate in > pem format in the directory > /etc/pki/ca-trust/source/anchors and run update-ca-trust > extract and that will update the all the appropriate files. > Including the cacerts file. That does not seem to happen. > What is the proper way of handling self-signed certificates > you want tomcat to trust? > > Off topic but you are folks who might know: On a related > note I have the same issue with Java applications not > running in Tomcat that use the same file > /etc/pki….java/cacerts. Am I understanding the PKI update > process correctly? Am I putting the self-signed certificate > pem format file in the correct place? > > Darryl Baker, GSEC (he/him/his) Sr. System Administrator > (...) > > You can put your certificates and truststore wherever you want as long as you tell Tomcat where they are in the conf/server.xml configuration file when you configure the connector using them. Self-signed certificates should never be used on a production server, they are not secure. >>> What makes you say that? >>> >>> - -chris (...) > > > >> https://www.venafi.com/blog/self-signed-certificates-cyber-criminals- a > >> re-turning-strength-into-a-vulnerability > > This > > article is talking about securing miscreants' communications. It > really has nothing to do with self-signed certificates. It has to > do with users blindly "trusting" anything which claims to be > trustworthy just because it's encrypted. I've re-read this article and also read their linked article on Heartbleed, and I have come to the conclusion that the writers do not have any clue what they are talking about. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9NYTEACgkQHPApP6U8 pFgDwQ/+J1fhYRIMEjcDOhYmdtX6d3cid7pQ9pjBq3LePbeT+KrFWn7GbJcSU3Bg SpBzZJUg2KB1EzMaZFmXd/OBpdrq+1a08fdjvwnDB1nSmznuIpgRbagm6MWigFlm ghW5+96nQ/6L3a8LTZrjCkO7jxwuIMISYSOLvm9d9m7IHpgKWRl5UjBC/EuWpof6 blApEICEh4sWE9ZEBSYsphba3wP9nAFEKIb0/7ORRvQqkYZtSe/cQsTNXVOTQ9GF nBcT40jMnG3pvEKzz7Gjk+OXhe3tAATBMdCvwzGtmct4QKI7T1B1FWHKZod1zgne FqkX2ryRoq8F8MgDMkamzAQsW+n9WYVfQYDCaLMmoE2x3D3lulOUngL6g4qaA95u TGdeggVgIaOmeJclImbuvE/X2fA89D90sc0XuGbUcXa4uvm8l13RDZVRyuntoXMQ puMXypG0wRqlqfvA3ab4K+gI0AHjZ5tCJeqKMpUV+yOKDlB5ii0YBp6nB21x7C+4 afi4LXgIJsmXMpUp0ggjBmshrJ0KM5rnIdlpCdRKpuKic3Wy+C7sV0FxwOtx5bhj JI/Er4uVeBpXh0gWYpTko+3SqpEPOkdFlCNbPBUZ0UtdeK8BWbQPTpi4evumMj8Z WgLZ+FRS7mD3NAIRERrDKpAsKQK1vmU9t6OfZXV+zE+sZ3n6ap0= =4OMv -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: shared.loader classpaths
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Carles, On 8/31/20 12:45, Carles Franquesa wrote: > Thank you Chris, for keeping on the problem. I don't know if you > saw the last mail sent by me to the list. > > The thing was resolved by placing all the JSP referencing those > classes at the web root folder. I did that, and it worked. That's > why I hung my solution in the list. Moving the JSPs will not have had any effect on being able to locate the .class files. You must have changed something else. > Nevertheless, Mark Thomas told me I was wrong. What I supposed that > was the problem, and the solution was wrong. He told me JSPs may > go everywhere in the folder structure. And asked me for giving a > simple example of my error. Only if you want to actually solve your real problem. > Anyway, by then my app worked already, so I put off to make the > example until today. And certainly, I can't reproduce it. Mark is > right, of course. I am new in all this. Now, my last chance to > have the example is starting from a new copy of what is now going > on, recover the old hierarchy of JSP ant try to reproduce the > error. I am in> Thanks again for you help, Chris. You are welcome, any time. It wasn't clear to me that your more recent post was in reference to this one. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9NXv0ACgkQHPApP6U8 pFjY+Q/9HUHitx0LWtW5w85qdGk9WksWXHXH5DWo4Mjx9uqsWoYeKqUDmaqDIMDh 2e1P4C2OBKli1toYU3mc9WWrtJmJV+b3ADiJGdaWjaPdHABFoTWQhFofH3WGi9+B D3hxNBTlVY8dHnnDH0gvADFRsgJ7j1p4nTTM3krnDJW1KVH558CYE1G/9d3WcJV7 J66O3GAvyNG6LLQ7liUsr8dr+b7mVvpci/0b4I6LWmALQUqPGuCLKoZEkpZWOpA8 2b5Eq4cEGcYLCjv9LcZ3xocelTXHwxPNQDjZpFWXYqw7wYP9VnLLPwrkXlN4aRh5 O/1/aNALVLr6neDi4XCoCDFkMfPJpL2zwGHlrDfSqgtyQpQ0Gw1Xyh7dHoLM+RrK n4WMbKXdCpB0QiFBw2inwk+pSWnN5aINUnK2V0w73pXTwVqKSOTzpFlwXlxP3DDp OgcC+JYgkdcHYLUZFblrMesU/wEN8sQiV3dTTn8RsX3OGy3vfIPM2gc0/Z+JPSny 8b9+AkS/trv8FQRq8vXMQINesDoyFxjJZLCxb+/psCj6obePzl4QE/N3OHFZUxjM 6Y+TVXj3E9ogOnT3sOyapmaZfjySdhjXUw7AFKtDy4SABzNnL9rJEPUkt+9Zdjm6 fJE8FPnNquYxtr3IoznWCN47EJd1rImGW3WwOIRI9/QLe8r2uk8= =8jqr -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Red Hat / CentOS specific question about certificates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Daniel, On 8/31/20 11:36, Daniel Savard wrote: > Le lun. 31 août 2020 à 11:13, Christopher Schultz < > ch...@christopherschultz.net> a écrit : > >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 >> >> >> Daniel, >> >> On 8/28/20 20:46, Daniel Savard wrote: >>> Le ven. 28 août 2020 à 17:19, Darryl Philip Baker < >>> darryl.ba...@northwestern.edu> a écrit : >>> I am having an issue that I don’t understand. On RHEL6/CentOS and earlier my predecessors would put self-signed certificates they wanted to trust in /etc/pki/ca-trust/extracted/java/cacerts and it was good for the life of the machine. On RHEL7 and I assume CentOS7 that file is part of a package that is getting updated as part of the regular patches. That wipes out our self-signed certificates. The way I understand the directions from Red Hat we should put the certificate in pem format in the directory /etc/pki/ca-trust/source/anchors and run update-ca-trust extract and that will update the all the appropriate files. Including the cacerts file. That does not seem to happen. What is the proper way of handling self-signed certificates you want tomcat to trust? Off topic but you are folks who might know: On a related note I have the same issue with Java applications not running in Tomcat that use the same file /etc/pki….java/cacerts. Am I understanding the PKI update process correctly? Am I putting the self-signed certificate pem format file in the correct place? Darryl Baker, GSEC (he/him/his) Sr. System Administrator (...) >>> You can put your certificates and truststore wherever you want >>> as long as you tell Tomcat where they are in the >>> conf/server.xml configuration file when you configure the >>> connector using them. >>> >>> Self-signed certificates should never be used on a production >>> server, they are not secure. >> What makes you say that? >> >> - -chris (...) > > > > https://www.venafi.com/blog/self-signed-certificates-cyber-criminals-a re-turning-strength-into-a-vulnerability This > article is talking about securing miscreants' communications. It really has nothing to do with self-signed certificates. It has to do with users blindly "trusting" anything which claims to be trustworthy just because it's encrypted. Self-signed certificates by definition are not signed by a CA, so they are not globally-trusted (or even semi-globally-trusted). "Trusting All" certificates is a terrible mistake and the only way that self-signed certificates can be a problem, whether used on an "internal" network or exposed to the outside network. > Never may be exaggerated in my post. But in general, you should > avoid them. Meh. > But it all depends on your organization as well, mine is signing > internal certificates and managing to include itself in the > browsers of all the thousands employees. This is a good technique IMO. > In a small business, it may not be possible and the number of > self-signed certificates may be low. In our organization, in the > past we have seen people setting up their own self-signed > certificates with too short keys to be secured by today's > standards. Well, that's obviously a mistake. Especially if you aren't talking about browser-trust, I think self-signed (or local-CA-signed) certificates are a good thing. Services ought to be individually-trusting service certificates and not even accepting all globally-recognized CAs because a compromised CA or middle-box can intercept communications without a problem. Self-signed certificates offer isolation from CAs and can therefore be *more* secure for service-level certificates precisely because they require special deployment. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9NXWQACgkQHPApP6U8 pFicIxAAj04SbtcGa7UuCb65EvME1XAqRRwmsHVBGhLxBK/Nr3g+hDZ9xFd9Yo4i 5iuQ0yat4lD2y8BH1YF+EHrygfIp86EoDUKKukjuoAVQ4cgHFM6T2aoM8sWJR1CJ xoxbA+dWnYL12BZR6jRj2k5vcOvs/UYkz4A6dp9X2N1LaQHMw5/orrqLPwN/BxiZ qTzeEKqMAhLsfGVZVs9VGZPMLZYL6TvMkca22IltK1Z3dDkalijwyL83Q7vVGEvm 38qamO3FkgnfjZPgufkVoxfEKkG3lmMY7kpzxvGeoaPaH3he3tljXXVGbKxfSAuX NFYj1CciL2fJCGm0roIB/9kPvG3Eoiq96ubUwbpl2fIciMA+XFJ6nUDj0ogdHzl1 yYbAowAXN4YR7azmmhwSUzgUsaw5itAQxiQpb0A7G3yxmTt52xv62aV5PhDw0lsN HULi7GFm6JoeuzaGW6KBcOfBu+hZpek1Jqujn/Y435jIU5otE9R+yYDtdonLD0W3 ssWGdZRP6/Rgu41BEMPpdCgb+lDWBH/EkuTFHDerX2u9kpjALuJTTPRyt2REpOqY Oflifwm2f9R77J3LNK8CNqC9d1BtUJqwSJ5/u+dRpkExYzTf37mHkt2kmdDlZJYi mpjJUuoyEZnxhltyrp8Wn5bWNnA6P4kzVcPGqbG3MM/1KIHs++k= =kmkH -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 Pool Cleaner Deadlock Problem
Am 31.08.20 um 18:53 schrieb Phil Steitz: > > On 8/31/20 3:21 AM, Felix Schumacher wrote: >> Am 31.08.20 um 06:15 schrieb Gokhan Akgul: >>> Dear Phil , >>> Thanks for your feedback. I forgot to mention the mysql driver >>> version. The >>> Mysql driver version is 5.1.32. >>> My plan is to upgrade the mysql driver to 5.1.46 version and monitor >>> for a >>> while. >> If I read the bug report correctly, MySQL will not change its logic and >> therefore using newer versions of the driver will not help. > > Yeah. There was a comment in another related bug report about > changing the locking model in 5.1.x, so it is possible a later version > will help, but you are right that it probably won't. > >> >> What MySQL advises is to change the pool to use the abort-Method of the >> connection to close it in the case of abandoned connections. >> >> The dbcp2 pools seems to be able to use that method, while I found no >> reference to it in the jdbc-pool module (which you are using). > > We are talking about making that change on commons-dev now [1], but > currently dbcp2 uses close as jdbc-pool does. You are of course right, I just grepped the sources for abort and skimmed the comments. Should have looked more closely. Felix > > Comments / patches welcome! > > Phil > >> >> So, maybe it is a good idea to switch the used pool from the jdbc-pool >> to the default tomcat pool (see >> http://tomcat.apache.org/tomcat-9.0-doc/jndi-datasource-examples-howto.html). >> >> It should work equally well (I am not sure, if it supports something >> like the slowqueryreport, though). If you want to continue using the old >> jdbc-pool module, you might want to file a bug on the bugtracker asking >> for an enhancement to support the abort method. (I would use the dbcp2 >> pool.) >> >> Felix > > > [1] > https://lists.apache.org/thread.html/r598c0f654477372d112858af1c18bfc04008250156989647d883576f%40%3Cdev.commons.apache.org%3E > >> >>> On Sat, Aug 29, 2020 at 6:50 PM Phil Steitz >>> wrote: >>> On 8/27/20 2:47 AM, Gokhan Akgul wrote: > Hi , > > I have been facing the deadlock issue for the last 2 months about > JDBCPoolCleaner Thread . > > Following config set in context.xml > > auth="Container" > type="javax.sql.DataSource" > > factory="org.apache.tomcat.jdbc.pool.DataSourceFactory" > driverClassName="com.mysql.jdbc.Driver" > url="jdbc:mysql://adress:3306/db?useUnicode=truecharacterEncoding=latin5characterResultSet=latin5zeroDateTimeBehavior=convertToNullautoReconnect=trueinteractiveClient=true" > username="user" > password="pass" > initialSize="10" > maxActive="30" > maxIdle="15" > minIdle="10" > maxWait="3" > timeBetweenEvictionRunsMillis="5000" > minEvictableIdleTimeMillis="6" > removeAbandonedTimeout="600" > removeAbandoned="true" > logAbandoned="false" > testWhileIdle="true" > testOnBorrow="true" > testOnReturn="false" > validationQuery="/* ping */ SELECT 1" > validationInterval="3" > jmxEnabled="true" > jdbcInterceptors="ConnectionState;StatementFinalizer;ResetAbandonedTimer;SlowQueryReport" > /> > > > > Thread dump > > Tomcat JDBC Pool Cleaner[63445188:1598345711425] id=16 state=BLOCKED > - waiting to lock <0x57dcb0b7> (a com.mysql.jdbc.JDBC4PreparedStatement) > owned by http-nio-8080-exec-8 id=25 > at com.mysql.jdbc.PreparedStatement.realClose(PreparedStatement.java:3078) > at com.mysql.jdbc.ConnectionImpl.closeAllOpenStatements(ConnectionImpl.java:1584) > at > com.mysql.jdbc.ConnectionImpl.realClose(ConnectionImpl.java:4364) > at > com.mysql.jdbc.ConnectionImpl.close(ConnectionImpl.java:1556) > at org.apache.tomcat.jdbc.pool.PooledConnection.disconnect(PooledConnection.java:388) > at org.apache.tomcat.jdbc.pool.PooledConnection.release(PooledConnection.java:618) > at org.apache.tomcat.jdbc.pool.ConnectionPool.release(ConnectionPool.java:612) > at org.apache.tomcat.jdbc.pool.ConnectionPool.abandon(ConnectionPool.java:569) > at org.apache.tomcat.jdbc.pool.ConnectionPool.checkAbandoned(ConnectionPool.java:999) > at org.apache.tomcat.jdbc.pool.ConnectionPool$PoolCleaner.run(ConnectionPool.java:1468) > at java.util.TimerThread.mainLoop(Timer.java:555) > at java.util.TimerThread.run(Timer.java:505) > > Locked synchronizers: count = 1 > -
Re: Tomcat JDBC Pool Cleaner Deadlock Problem
On 8/31/20 3:21 AM, Felix Schumacher wrote: Am 31.08.20 um 06:15 schrieb Gokhan Akgul: Dear Phil , Thanks for your feedback. I forgot to mention the mysql driver version. The Mysql driver version is 5.1.32. My plan is to upgrade the mysql driver to 5.1.46 version and monitor for a while. If I read the bug report correctly, MySQL will not change its logic and therefore using newer versions of the driver will not help. Yeah. There was a comment in another related bug report about changing the locking model in 5.1.x, so it is possible a later version will help, but you are right that it probably won't. What MySQL advises is to change the pool to use the abort-Method of the connection to close it in the case of abandoned connections. The dbcp2 pools seems to be able to use that method, while I found no reference to it in the jdbc-pool module (which you are using). We are talking about making that change on commons-dev now [1], but currently dbcp2 uses close as jdbc-pool does. Comments / patches welcome! Phil So, maybe it is a good idea to switch the used pool from the jdbc-pool to the default tomcat pool (see http://tomcat.apache.org/tomcat-9.0-doc/jndi-datasource-examples-howto.html). It should work equally well (I am not sure, if it supports something like the slowqueryreport, though). If you want to continue using the old jdbc-pool module, you might want to file a bug on the bugtracker asking for an enhancement to support the abort method. (I would use the dbcp2 pool.) Felix [1] https://lists.apache.org/thread.html/r598c0f654477372d112858af1c18bfc04008250156989647d883576f%40%3Cdev.commons.apache.org%3E On Sat, Aug 29, 2020 at 6:50 PM Phil Steitz wrote: On 8/27/20 2:47 AM, Gokhan Akgul wrote: Hi , I have been facing the deadlock issue for the last 2 months about JDBCPoolCleaner Thread . Following config set in context.xml url="jdbc:mysql://adress:3306/db?useUnicode=truecharacterEncoding=latin5characterResultSet=latin5zeroDateTimeBehavior=convertToNullautoReconnect=trueinteractiveClient=true" username="user" password="pass" initialSize="10" maxActive="30" maxIdle="15" minIdle="10" maxWait="3" timeBetweenEvictionRunsMillis="5000" minEvictableIdleTimeMillis="6" removeAbandonedTimeout="600" removeAbandoned="true" logAbandoned="false" testWhileIdle="true" testOnBorrow="true" testOnReturn="false" validationQuery="/* ping */ SELECT 1" validationInterval="3" jmxEnabled="true" jdbcInterceptors="ConnectionState;StatementFinalizer;ResetAbandonedTimer;SlowQueryReport" /> Thread dump Tomcat JDBC Pool Cleaner[63445188:1598345711425] id=16 state=BLOCKED - waiting to lock <0x57dcb0b7> (a com.mysql.jdbc.JDBC4PreparedStatement) owned by http-nio-8080-exec-8 id=25 at com.mysql.jdbc.PreparedStatement.realClose(PreparedStatement.java:3078) at com.mysql.jdbc.ConnectionImpl.closeAllOpenStatements(ConnectionImpl.java:1584) at com.mysql.jdbc.ConnectionImpl.realClose(ConnectionImpl.java:4364) at com.mysql.jdbc.ConnectionImpl.close(ConnectionImpl.java:1556) at org.apache.tomcat.jdbc.pool.PooledConnection.disconnect(PooledConnection.java:388) at org.apache.tomcat.jdbc.pool.PooledConnection.release(PooledConnection.java:618) at org.apache.tomcat.jdbc.pool.ConnectionPool.release(ConnectionPool.java:612) at org.apache.tomcat.jdbc.pool.ConnectionPool.abandon(ConnectionPool.java:569) at org.apache.tomcat.jdbc.pool.ConnectionPool.checkAbandoned(ConnectionPool.java:999) at org.apache.tomcat.jdbc.pool.ConnectionPool$PoolCleaner.run(ConnectionPool.java:1468) at java.util.TimerThread.mainLoop(Timer.java:555) at java.util.TimerThread.run(Timer.java:505) Locked synchronizers: count = 1 - java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync@58039868 http-nio-8080-exec-8 id=25 state=BLOCKED - waiting to lock <0x42de9995> (a com.mysql.jdbc.JDBC4Connection) owned by Tomcat JDBC Pool Cleaner[63445188:1598345711425] id=16 at com.mysql.jdbc.ConnectionImpl.useAnsiQuotedIdentifiers(ConnectionImpl.java:5435) at com.mysql.jdbc.DatabaseMetaData.getIdentifierQuoteString(DatabaseMetaData.java:3269) at com.mysql.jdbc.DatabaseMetaData.(DatabaseMetaData.java:675) at com.mysql.jdbc.JDBC4DatabaseMetaData.(JDBC4DatabaseMetaData.java:39) at sun.reflect.GeneratedConstructorAccessor24.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:526) at
Re: shared.loader classpaths
Thank you Chris, for keeping on the problem. I don't know if you saw the
last mail sent by me to the list.
The thing was resolved by placing all the JSP referencing those classes at
the web root folder. I did that, and it worked. That's why I hung my
solution in the list.
Nevertheless, Mark Thomas told me I was wrong. What I supposed that was the
problem, and the solution was wrong. He told me JSPs may go everywhere in
the folder structure. And asked me for giving a simple example of my error.
Anyway, by then my app worked already, so I put off to make the example
until today. And certainly, I can't reproduce it. Mark is right, of course.
I am new in all this. Now, my last chance to have the example is starting
from a new copy of what is now going on, recover the old hierarchy of JSP
ant try to reproduce the error. I am in
Thanks again for you help, Chris.
Carles
Missatge de Christopher Schultz del dia dl.,
31 d’ag. 2020 a les 17:29:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Carles,
>
> On 8/29/20 15:13, Carles Franquesa wrote:
> > Is anybody out there that could explain to me the way to know
> > which classpath is being used by shared.loader. Or better, for any
> > loader.
>
> http://tomcat.apache.org/tomcat-9.0-doc/class-loader-howto.htmlv
>
> > My problem is the tomcat does not find a class that certainly is
> > in WEB-INF/classes.
>
> What is the path of the file in WEB-INF/classes?
>
> What is the name of the package+class of the class?
>
> > I tried to set explicitly in all loaders by editing
> > catalina.properties.
>
> Do not do that. It's almost never necessary.
>
> > My last test has been giving the folders to the common.loader,
> > this way:
> >
> >
> > *common.loader="${catalina.base}/lib","${catalina.base}/lib/*.jar","${
> catalina.home}/lib","${catalina.home}/lib/*.jar","${catalina.base}/apren
> online/WEB-INF/classes/lib","${catalina.base}/aprenonline/WEB-INF/classe
> s/model","${catalina.base}/aprenonline/WEB-INF/classes/servlets","${cata
> lina.base}/aprenonline/WEB-INF/lib/*.jar"*
>
> This
> >
> will cause endless problems if you try to deploy more than one
> application at a time. It will probably also cause weird problems even
> with a single application deployed.
>
> > But no way. Tomcat keeps on failing when JSP files try to make use
> > of those classes.
>
> Please post the <%@page> directive from a sample JSP file.
>
> > In all Tomcat manuals say that webapp's classes should be placed
> > in WEB-INF/classes when the WAR file is build.
>
> This is the correct way to do things.
>
> > And certainly, they are.
>
> Either the class files are not in the right place, or you are not
> referencing them correctly.
>
> > But error continues. I also found some people that had this
> > problem in the past, and by then, it was resolved updating to new
> > versions. I tried with Tomcat 8 and 9.
> I don't know of any version of Tomcat where the ClassLoaders didn't work
> .
>
> > Already spent four days in this, and I am totally stuck.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9NF3MACgkQHPApP6U8
> pFisnA/+Ly+r1R1HrHkKA1YHZVC72H8SS15AXJ+Twly/dH3QJ4HbMyX2tdBnSXOS
> DKC0fsmKDUG7fLg1yKPAKYbnbQHoZEo6yfboMTuVrIG5sshVvdTqX/xfjN3V29D3
> jYr1CIb/4esLCBg2Wq2DIck6mrJtg7ko95WYQnaMXODMJYf/KjZu8c/hoPSn70B7
> +qYr+9GNO5qo6dTXcbaSFql4uex+c8NYyDMLZNDPml7Ub76aDAWJ2YOpxozzpftF
> KYnGWdwhCXWtGOKrmhJ6WwEmK36unlJyq3BY12t+0hHP4aLg1ObcqiUtiiUrcO/D
> saK5yF/JmSa5N6d+RpfNPvXe/zNUpnOm8/HlOZyWm23szWfNHLH27VMQfN8vPoSP
> IjyXe/+eMSoRil5pnfeMKmTlU6ic9Om+abL0Wjva/v/MxS6HTbf1tJxAPxFkLpY5
> dkI3R1YiqZwHpVPNlWiRpMgm39MSzphEy3vRpAxyEw/MWese4ZA/VS1CoZHK9fc8
> jGigahmx5XS8X0c5y7AndwoD3iQ+mhQjOkNkexDqc9tTbzIcyg1hRJyHxsSV1iBk
> Fdv8JrLORRyCymN6j2WIdDDbESeHTSDnHTKGc8C2/489eFVcsFip8EKW0oxbhqQp
> nfHqrHvfPaGy9cNSRzWFis7OWvnBQpf78VIbYjxmi4o3Mu36ioQ=
> =6UY2
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
Re: [OT] Red Hat / CentOS specific question about certificates
Le lun. 31 août 2020 à 11:13, Christopher Schultz < ch...@christopherschultz.net> a écrit : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > > Daniel, > > On 8/28/20 20:46, Daniel Savard wrote: > > Le ven. 28 août 2020 à 17:19, Darryl Philip Baker < > > darryl.ba...@northwestern.edu> a écrit : > > > >> I am having an issue that I don’t understand. On RHEL6/CentOS > >> and earlier my predecessors would put self-signed certificates > >> they wanted to trust in /etc/pki/ca-trust/extracted/java/cacerts > >> and it was good for the life of the machine. On RHEL7 and I > >> assume CentOS7 that file is part of a package that is getting > >> updated as part of the regular patches. That wipes out our > >> self-signed certificates. The way I understand the directions > >> from Red Hat we should put the certificate in pem format in the > >> directory /etc/pki/ca-trust/source/anchors and run > >> update-ca-trust extract and that will update the all the > >> appropriate files. Including the cacerts file. That does not seem > >> to happen. What is the proper way of handling self-signed > >> certificates you want tomcat to trust? > >> > >> Off topic but you are folks who might know: On a related note I > >> have the same issue with Java applications not running in Tomcat > >> that use the same file /etc/pki….java/cacerts. Am I > >> understanding the PKI update process correctly? Am I putting the > >> self-signed certificate pem format file in the correct place? > >> > >> Darryl Baker, GSEC (he/him/his) Sr. System Administrator (...) > >> > >> > > You can put your certificates and truststore wherever you want as > > long as you tell Tomcat where they are in the conf/server.xml > > configuration file when you configure the connector using them. > > > > Self-signed certificates should never be used on a production > > server, they are not secure. > What makes you say that? > > - -chris > (...) https://www.venafi.com/blog/self-signed-certificates-cyber-criminals-are-turning-strength-into-a-vulnerability Never may be exaggerated in my post. But in general, you should avoid them. But it all depends on your organization as well, mine is signing internal certificates and managing to include itself in the browsers of all the thousands employees. In a small business, it may not be possible and the number of self-signed certificates may be low. In our organization, in the past we have seen people setting up their own self-signed certificates with too short keys to be secured by today's standards. Regards, - Daniel Savard
Re: shared.loader classpaths
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Carles,
On 8/29/20 15:13, Carles Franquesa wrote:
> Is anybody out there that could explain to me the way to know
> which classpath is being used by shared.loader. Or better, for any
> loader.
http://tomcat.apache.org/tomcat-9.0-doc/class-loader-howto.htmlv
> My problem is the tomcat does not find a class that certainly is
> in WEB-INF/classes.
What is the path of the file in WEB-INF/classes?
What is the name of the package+class of the class?
> I tried to set explicitly in all loaders by editing
> catalina.properties.
Do not do that. It's almost never necessary.
> My last test has been giving the folders to the common.loader,
> this way:
>
>
> *common.loader="${catalina.base}/lib","${catalina.base}/lib/*.jar","${
catalina.home}/lib","${catalina.home}/lib/*.jar","${catalina.base}/apren
online/WEB-INF/classes/lib","${catalina.base}/aprenonline/WEB-INF/classe
s/model","${catalina.base}/aprenonline/WEB-INF/classes/servlets","${cata
lina.base}/aprenonline/WEB-INF/lib/*.jar"*
This
>
will cause endless problems if you try to deploy more than one
application at a time. It will probably also cause weird problems even
with a single application deployed.
> But no way. Tomcat keeps on failing when JSP files try to make use
> of those classes.
Please post the <%@page> directive from a sample JSP file.
> In all Tomcat manuals say that webapp's classes should be placed
> in WEB-INF/classes when the WAR file is build.
This is the correct way to do things.
> And certainly, they are.
Either the class files are not in the right place, or you are not
referencing them correctly.
> But error continues. I also found some people that had this
> problem in the past, and by then, it was resolved updating to new
> versions. I tried with Tomcat 8 and 9.
I don't know of any version of Tomcat where the ClassLoaders didn't work
.
> Already spent four days in this, and I am totally stuck.
- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9NF3MACgkQHPApP6U8
pFisnA/+Ly+r1R1HrHkKA1YHZVC72H8SS15AXJ+Twly/dH3QJ4HbMyX2tdBnSXOS
DKC0fsmKDUG7fLg1yKPAKYbnbQHoZEo6yfboMTuVrIG5sshVvdTqX/xfjN3V29D3
jYr1CIb/4esLCBg2Wq2DIck6mrJtg7ko95WYQnaMXODMJYf/KjZu8c/hoPSn70B7
+qYr+9GNO5qo6dTXcbaSFql4uex+c8NYyDMLZNDPml7Ub76aDAWJ2YOpxozzpftF
KYnGWdwhCXWtGOKrmhJ6WwEmK36unlJyq3BY12t+0hHP4aLg1ObcqiUtiiUrcO/D
saK5yF/JmSa5N6d+RpfNPvXe/zNUpnOm8/HlOZyWm23szWfNHLH27VMQfN8vPoSP
IjyXe/+eMSoRil5pnfeMKmTlU6ic9Om+abL0Wjva/v/MxS6HTbf1tJxAPxFkLpY5
dkI3R1YiqZwHpVPNlWiRpMgm39MSzphEy3vRpAxyEw/MWese4ZA/VS1CoZHK9fc8
jGigahmx5XS8X0c5y7AndwoD3iQ+mhQjOkNkexDqc9tTbzIcyg1hRJyHxsSV1iBk
Fdv8JrLORRyCymN6j2WIdDDbESeHTSDnHTKGc8C2/489eFVcsFip8EKW0oxbhqQp
nfHqrHvfPaGy9cNSRzWFis7OWvnBQpf78VIbYjxmi4o3Mu36ioQ=
=6UY2
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Implications of setting createDirs attribute on host declarations to false in Tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Paul, On 8/31/20 05:36, Paul wrote: > Hello, > > When running Tomcat in a Docker container as non-root, I'm getting > an error entry in the logs: > > Unable to create directory for deployment: > [/usr/local/tomcat/conf/Catalina/localhost] I traced this down to > the aforementioned directory not being there when Tomcat gets > launched and the user running Tomcat does not having the > permissions to create the directory. > > I also traced where this error message is coming from and its due > to the createDirs attribute on the host declaration in server.xml > not being set to false. The docs for the createDirs property states > that if its set to true (the default) it'll attempt to create some > directories, log an error when it fails, but the failure wont stop > the startup of Tomcat. > > But what I cannot find anywhere is why those directories are > created in the first place and what the ramifications are of them > not being created when createDirs is set to false. You are deploying a WAR file, right? If you don't set createDirs="true" then Tomcat will not be able to unpack WAR files for you. > This question is for Tomcat docker images in general (in order to > determine whether generic Tomcat Docker images should do something > different to prevent these Errors in the logs), in my specific > scenario however I'm running one webapp: an exploded WAR in the > webapps/ROOT directory, which comes with its on context.xml in > /webapps/ROOT/META-INF/context.xml If webapps/ already exists, what directory is Tomcat trying to create? conf/[engine]/[host]? Can you arrange for conf/[engine]/[host] (usually conf/Catalina/localhost) to exist so that the setting for createDirs doesn't matter? - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9NFjoACgkQHPApP6U8 pFi/7xAAs6Rg39EWDFLkL2DutF4sGu6MeB9lwaRxq/OmsubS5X44+w+kFGha05fx wHYFe6vhl6WL+UEIo/bja+JRgQCTCDTYf6fMmPYvJ6am/b2Ew0GmtjQlU6eimH2y uGM/sfT0No+FYRpAxW9mbsh86H6rYMBNvj+dNWeusSkS/3uX2cELm/WwDKnOQb9I bX5ZxgsA2DlXP37Zn+Q3G1bjP71Wbx1C/pbiXCYL3tGq3RLalBY3Y++GoTjAtEkX 4/jBNqLGBwgmFKQY0pfEc9iNCgwbgMh85zAvvUkzIxt+oKxYQLWPDwjs5Krfu2ZK /pUIFey33rqAO9Vo2iuyX8W03kU0hhAK0PIXimPW8H3848o4Qe+5mJt46jrcpAb7 DFGZUiwS7plD9UrTZpY4UGfWtwAx1GwD9Db/l50Ru32mVtbYgvfzYKqKfZKe7hbI gOUjIu+5jk0cgUE8d+bK2kiTnX5CQJNHT2N44y1/HLRBtuS7RX5e7yLuQfLZ6yeI YpmQAr5oxccQ4XSbL9XQMtckG46JqSL1GwbejMT4n0pMzj7zI8J2Eeh3hCsov5bL trDml0upYcWFoLNUJhFn+Lo1a0ujqOlH2iKS0xg+RU37t0mH0U8/ys77ZS12cnk8 bbwztsxUVPHKc2VjKOMhn47v+cmeGhAP6zeB2ZZ7O9fv3Si9xOQ= =g5QV -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Probelm with shutdown script
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 8/29/20 20:28, Mark Thomas wrote: > On 28/08/2020 20:54, Christopher Schultz wrote: >> Calder, >> >> On 8/27/20 18:23, calder wrote: >>> On Thu, Aug 27, 2020, 16:16 Christopher Schultz < >>> ch...@christopherschultz.net> wrote: >> >>> [ snip ] >> >>> If you want to *kill* the application and it won't shut down >>> on its own, SIGKILL is the answer. But that's not a great way to shut down an application /in general/ because the application might want/need to do something convenient on shutdown (flush caches, save state, etc.). >> >> >> >>> SIGTERM is the polite way to ask an application to shut down. A >>> JVM will respond to this signal. (SIGHUP will also initiate a >>> shut down, but TERM is preferred). Using TERM will cause the >>> shutdown hooks to initiate. >> >>> As Chris states, SIGKILL is a last resort (hooks are not >>> called). >> >> If you send a SIGTERM to a Tomcat process, your application's >> ServletContextListeners and stuff like that will not run. > > Yes it will. Tomcat will shutdown cleanly (after cleanly shutting > down any running web applications). Oh really? How does that work? Oh, right. A shutdown-hook. :) >> Sure, you can register shutdown-hook, but ... eew. That's like, >> AWFUL, man. > > You mean like Tomcat already does? Applications don't/shouldn't do > this because Tomcat has already done so. Exactly. Shutdown hooks from web applications should never be done. I don't think of Tomcat as an "application". It does make sense for containers to register such things. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9NFU0ACgkQHPApP6U8 pFjL3g/8DDOQDPdx+tuPw1ecd98u5YEuotkZXfFxl9u266up9fmBG8XubDRS85bX 60etRvJCmcH5lXCsBCmmnrDyK/KaxPDpM4OOMwnuEIfQOrQDN4uA3pz5FncAL1sO VC3XJg9u341M2CHyw4yC0uqshSSWXXAhum3VoKBR82iHMQmlxu8bStwep1V39irS rb4hqUIMi2puIXb8TJXln4oUSh+dL37Y5ksSc+0bk4+xiJF4KwevRbdp8AzoSFMO H85W6Oafzj6R6mWbs2OL09PCxC05A5UqR5BlfspJWTHwT3hq8NeVIlDBWX3tzK8n L5M8gKwjL0UdXmINwJbsjPdesDrQdVwjvqZrIvYFCKl0SIaG2q0vRr2Qi+RmaNIC zG7+U1SR1WQ8nVTnynvo3xP36eXnmyLNFG/4sXvxG30VpiLatpoCMZnNfb7ChtMC waX68CREil12sNgLXP+GGfbWFhxnnBrMoaGI/6/+9Ed8DBwGwGRiOcbN0mxgAOQy 09dpMXsx4bgUTfmYd/GI2bWQW5XoJfz9Z3xzq9UvMsd1RaHSHIFRwxRvQYkw0HZm eKhUYq198FrxR9l+IJirKsZBwgIqYUFHc1p1pdCF14R7l2w94ofHPAEL/Q7Nj1ce SdYsNq73dfaaW+fWwj8t3MLuDjqtQv+gwWQwV+0KzjjZ5wvCIHM= =zfLt -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Red Hat / CentOS specific question about certificates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Daniel, On 8/28/20 20:46, Daniel Savard wrote: > Le ven. 28 août 2020 à 17:19, Darryl Philip Baker < > darryl.ba...@northwestern.edu> a écrit : > >> I am having an issue that I don’t understand. On RHEL6/CentOS >> and earlier my predecessors would put self-signed certificates >> they wanted to trust in /etc/pki/ca-trust/extracted/java/cacerts >> and it was good for the life of the machine. On RHEL7 and I >> assume CentOS7 that file is part of a package that is getting >> updated as part of the regular patches. That wipes out our >> self-signed certificates. The way I understand the directions >> from Red Hat we should put the certificate in pem format in the >> directory /etc/pki/ca-trust/source/anchors and run >> update-ca-trust extract and that will update the all the >> appropriate files. Including the cacerts file. That does not seem >> to happen. What is the proper way of handling self-signed >> certificates you want tomcat to trust? >> >> Off topic but you are folks who might know: On a related note I >> have the same issue with Java applications not running in Tomcat >> that use the same file /etc/pki….java/cacerts. Am I >> understanding the PKI update process correctly? Am I putting the >> self-signed certificate pem format file in the correct place? >> >> Darryl Baker, GSEC (he/him/his) Sr. System Administrator (...) >> >> > You can put your certificates and truststore wherever you want as > long as you tell Tomcat where they are in the conf/server.xml > configuration file when you configure the connector using them. > > Self-signed certificates should never be used on a production > server, they are not secure. What makes you say that? - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9NE5wACgkQHPApP6U8 pFg57BAAl6VNkfGacih8/Uxn1tiyEbDkGAvcFpxbJkhcS1q4yTR171cGaKE50z1l 1GIWiiRdTdFCwI3SlCdQySKDZa4kCDPscv24zcPAIhVJ/1WKJ9PC/mLFZuRzR+3R u2yYb5tUFcG7rESOf2WWgdB9uQrd/WMigr6qaLYIZFdOSKJ1xT1ujMMNUrFzleUw FveFimPKg7MkMgCYKJWmH28dUKOICIGdL2hmq7gAsT161XCwFVcjHRT/lKRpnIlD Mg1KTG6qTxMXSyBI4IopA8VRWAdjM6JaTyD65q4jjyeKTglklzmnU3WhFO4F1Jl2 vFlimBs0aNoRmNIuFfvQGyf5u7DKAdSYqrFk44atZQ2MNw5+Z6EDCtelLT/rneTf xyYTkwqKgt7MRngTsJZ5w8T7exd7ZjhFSnwAs4ekohbh9sUTsd0DadTM6XbGsacL p4c5aHrV9yYrye3RSfTEbwOr5FWR1G0VIMgONKdZA+BgNhm9CqdtoT04DA0iRY++ DskueqaKKEzEwV3P4/NYFKGj2nKtTMpYfrB6IUFghjMs/z29PYLgVVk/WVIEbLan w3Er4oa/6r3C1ltq3EevvMbthww4nMf/cZqMRpG8ilIR4wn7t+IqfBGTJN9Ox4pj Ik3pdWXw+5XoVaOqafUfhzc5Q1n6XSnTB5/yZifDhnsz/jzELIM= =4pHT -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 Pool Cleaner Deadlock Problem
Am 31.08.20 um 06:15 schrieb Gokhan Akgul: > Dear Phil , > Thanks for your feedback. I forgot to mention the mysql driver version. The > Mysql driver version is 5.1.32. > My plan is to upgrade the mysql driver to 5.1.46 version and monitor for a > while. If I read the bug report correctly, MySQL will not change its logic and therefore using newer versions of the driver will not help. What MySQL advises is to change the pool to use the abort-Method of the connection to close it in the case of abandoned connections. The dbcp2 pools seems to be able to use that method, while I found no reference to it in the jdbc-pool module (which you are using). So, maybe it is a good idea to switch the used pool from the jdbc-pool to the default tomcat pool (see http://tomcat.apache.org/tomcat-9.0-doc/jndi-datasource-examples-howto.html). It should work equally well (I am not sure, if it supports something like the slowqueryreport, though). If you want to continue using the old jdbc-pool module, you might want to file a bug on the bugtracker asking for an enhancement to support the abort method. (I would use the dbcp2 pool.) Felix > > On Sat, Aug 29, 2020 at 6:50 PM Phil Steitz wrote: > >> On 8/27/20 2:47 AM, Gokhan Akgul wrote: >>> Hi , >>> >>> I have been facing the deadlock issue for the last 2 months about >>> JDBCPoolCleaner Thread . >>> >>> Following config set in context.xml >>> >>> >> auth="Container" >>> type="javax.sql.DataSource" >>> factory="org.apache.tomcat.jdbc.pool.DataSourceFactory" >>> driverClassName="com.mysql.jdbc.Driver" >>> >> >> url="jdbc:mysql://adress:3306/db?useUnicode=truecharacterEncoding=latin5characterResultSet=latin5zeroDateTimeBehavior=convertToNullautoReconnect=trueinteractiveClient=true" >>> username="user" >>> password="pass" >>> initialSize="10" >>> maxActive="30" >>> maxIdle="15" >>> minIdle="10" >>> maxWait="3" >>> timeBetweenEvictionRunsMillis="5000" >>> minEvictableIdleTimeMillis="6" >>> removeAbandonedTimeout="600" >>> removeAbandoned="true" >>> logAbandoned="false" >>> testWhileIdle="true" >>> testOnBorrow="true" >>> testOnReturn="false" >>> validationQuery="/* ping */ SELECT 1" >>> validationInterval="3" >>> jmxEnabled="true" >>> >> >> jdbcInterceptors="ConnectionState;StatementFinalizer;ResetAbandonedTimer;SlowQueryReport" >>> /> >>> >>> >>> >>> Thread dump >>> >>> Tomcat JDBC Pool Cleaner[63445188:1598345711425] id=16 state=BLOCKED >>> - waiting to lock <0x57dcb0b7> (a >> com.mysql.jdbc.JDBC4PreparedStatement) >>> owned by http-nio-8080-exec-8 id=25 >>> at >> com.mysql.jdbc.PreparedStatement.realClose(PreparedStatement.java:3078) >>> at >> com.mysql.jdbc.ConnectionImpl.closeAllOpenStatements(ConnectionImpl.java:1584) >>> at com.mysql.jdbc.ConnectionImpl.realClose(ConnectionImpl.java:4364) >>> at com.mysql.jdbc.ConnectionImpl.close(ConnectionImpl.java:1556) >>> at >> org.apache.tomcat.jdbc.pool.PooledConnection.disconnect(PooledConnection.java:388) >>> at >> org.apache.tomcat.jdbc.pool.PooledConnection.release(PooledConnection.java:618) >>> at >> org.apache.tomcat.jdbc.pool.ConnectionPool.release(ConnectionPool.java:612) >>> at >> org.apache.tomcat.jdbc.pool.ConnectionPool.abandon(ConnectionPool.java:569) >>> at >> org.apache.tomcat.jdbc.pool.ConnectionPool.checkAbandoned(ConnectionPool.java:999) >>> at >> org.apache.tomcat.jdbc.pool.ConnectionPool$PoolCleaner.run(ConnectionPool.java:1468) >>> at java.util.TimerThread.mainLoop(Timer.java:555) >>> at java.util.TimerThread.run(Timer.java:505) >>> >>> Locked synchronizers: count = 1 >>>- >> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync@58039868 >>> >>> >>> http-nio-8080-exec-8 id=25 state=BLOCKED >>> - waiting to lock <0x42de9995> (a com.mysql.jdbc.JDBC4Connection) >>> owned by Tomcat JDBC Pool Cleaner[63445188:1598345711425] id=16 >>> at >> com.mysql.jdbc.ConnectionImpl.useAnsiQuotedIdentifiers(ConnectionImpl.java:5435) >>> at >> com.mysql.jdbc.DatabaseMetaData.getIdentifierQuoteString(DatabaseMetaData.java:3269) >>> at com.mysql.jdbc.DatabaseMetaData.(DatabaseMetaData.java:675) >>> at >> com.mysql.jdbc.JDBC4DatabaseMetaData.(JDBC4DatabaseMetaData.java:39) >>> at sun.reflect.GeneratedConstructorAccessor24.newInstance(Unknown >> Source) >>> at >> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) >>> at java.lang.reflect.Constructor.newInstance(Constructor.java:526) >>> at com.mysql.jdbc.Util.handleNewInstance(Util.java:411) >>> at >>
Re: Tomcat JDBC Pool Cleaner Deadlock Problem
Am 31.08.20 um 06:26 schrieb Gokhan Akgul: > Dear Felix, > > Thanks for your feedback , the health check period is so aggressive now. > SRE team's and apm monitor tools call internally and externally endpoint > and health indicators. > I asked the sre guys to decrease the frequency of those calls. They made > some decrease on calls but nothing changed. No, don't decrease the frequency. I meant to have the calls happen more often than every ten minutes. > Due to an old spring mvc project it doesn't have a kubernetes probe , about > 100 calls in minutes. Those calls have to use the connection, that the health check is using. Maybe you could check, whether the healtcheck is releasing its connection back to the pool after it has done its work. Felix > > Gökhan > > On Thu, Aug 27, 2020 at 9:48 PM Felix Schumacher < > felix.schumac...@internetallee.de> wrote: > >> Am 27.08.20 um 11:47 schrieb Gokhan Akgul: >>> Hi , >>> >>> I have been facing the deadlock issue for the last 2 months about >>> JDBCPoolCleaner Thread . >>> >>> Following config set in context.xml >>> >>> >> auth="Container" >>> type="javax.sql.DataSource" >>> factory="org.apache.tomcat.jdbc.pool.DataSourceFactory" >>> driverClassName="com.mysql.jdbc.Driver" >>> >> url="jdbc:mysql://adress:3306/db?useUnicode=truecharacterEncoding=latin5characterResultSet=latin5zeroDateTimeBehavior=convertToNullautoReconnect=trueinteractiveClient=true" >>> username="user" >>> password="pass" >>> initialSize="10" >>> maxActive="30" >>> maxIdle="15" >>> minIdle="10" >>> maxWait="3" >>> timeBetweenEvictionRunsMillis="5000" >>> minEvictableIdleTimeMillis="6" >>> removeAbandonedTimeout="600" >>> removeAbandoned="true" >>> logAbandoned="false" >>> testWhileIdle="true" >>> testOnBorrow="true" >>> testOnReturn="false" >>> validationQuery="/* ping */ SELECT 1" >>> validationInterval="3" >>> jmxEnabled="true" >>> >> jdbcInterceptors="ConnectionState;StatementFinalizer;ResetAbandonedTimer;SlowQueryReport" >>> /> >>> >>> >>> >>> Thread dump >>> >>> Tomcat JDBC Pool Cleaner[63445188:1598345711425] id=16 state=BLOCKED >>> - waiting to lock <0x57dcb0b7> (a >> com.mysql.jdbc.JDBC4PreparedStatement) >>> owned by http-nio-8080-exec-8 id=25 >> So, Tomcat tries to close a connection, that it thinks is abandoned >> (i.e. in your setup hasn't been used for more than 600 seconds and the >> pool of idle connections is getting empty). >> >> The connection is still in use ... >> >>> at >> com.mysql.jdbc.PreparedStatement.realClose(PreparedStatement.java:3078) >>> at >> com.mysql.jdbc.ConnectionImpl.closeAllOpenStatements(ConnectionImpl.java:1584) >>> at com.mysql.jdbc.ConnectionImpl.realClose(ConnectionImpl.java:4364) >>> at com.mysql.jdbc.ConnectionImpl.close(ConnectionImpl.java:1556) >>> at >> org.apache.tomcat.jdbc.pool.PooledConnection.disconnect(PooledConnection.java:388) >>> at >> org.apache.tomcat.jdbc.pool.PooledConnection.release(PooledConnection.java:618) >>> at >> org.apache.tomcat.jdbc.pool.ConnectionPool.release(ConnectionPool.java:612) >>> at >> org.apache.tomcat.jdbc.pool.ConnectionPool.abandon(ConnectionPool.java:569) >>> at >> org.apache.tomcat.jdbc.pool.ConnectionPool.checkAbandoned(ConnectionPool.java:999) >>> at >> org.apache.tomcat.jdbc.pool.ConnectionPool$PoolCleaner.run(ConnectionPool.java:1468) >>> at java.util.TimerThread.mainLoop(Timer.java:555) >>> at java.util.TimerThread.run(Timer.java:505) >>> >>> Locked synchronizers: count = 1 >>> - >> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync@58039868 >>> >>> >>> http-nio-8080-exec-8 id=25 state=BLOCKED >>> - waiting to lock <0x42de9995> (a com.mysql.jdbc.JDBC4Connection) >>> owned by Tomcat JDBC Pool Cleaner[63445188:1598345711425] id=16 >> ... by hibernate. The question now is, how often is your healtheck >> getting called (every 10 min == 600s)? >> >> If they are close together, you might want to set the abandoned timeout >> higher than the healthcheck interval, or you could try to close the >> connection (or whatever the equivalent is in hibernate (a session?)) in >> your code. >> >> Felix >> >>> at >> com.mysql.jdbc.ConnectionImpl.useAnsiQuotedIdentifiers(ConnectionImpl.java:5435) >>> at >> com.mysql.jdbc.DatabaseMetaData.getIdentifierQuoteString(DatabaseMetaData.java:3269) >>> at com.mysql.jdbc.DatabaseMetaData.(DatabaseMetaData.java:675) >>> at >> com.mysql.jdbc.JDBC4DatabaseMetaData.(JDBC4DatabaseMetaData.java:39) >>> at sun.reflect.GeneratedConstructorAccessor24.newInstance(Unknown >> Source) >>> at >>
Implications of setting createDirs attribute on host declarations to false in Tomcat
Hello, When running Tomcat in a Docker container as non-root, I'm getting an error entry in the logs: Unable to create directory for deployment: [/usr/local/tomcat/conf/Catalina/localhost] I traced this down to the aforementioned directory not being there when Tomcat gets launched and the user running Tomcat does not having the permissions to create the directory. I also traced where this error message is coming from and its due to the createDirs attribute on the host declaration in server.xml not being set to false. The docs for the createDirs property states that if its set to true (the default) it'll attempt to create some directories, log an error when it fails, but the failure wont stop the startup of Tomcat. But what I cannot find anywhere is why those directories are created in the first place and what the ramifications are of them not being created when createDirs is set to false. This question is for Tomcat docker images in general (in order to determine whether generic Tomcat Docker images should do something different to prevent these Errors in the logs), in my specific scenario however I'm running one webapp: an exploded WAR in the webapps/ROOT directory, which comes with its on context.xml in /webapps/ROOT/META-INF/context.xml TIA Paul -- This email has been checked for viruses by AVG. https://www.avg.com
