-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 All,
I have a JNDI <Resource> which is a JDBC DataSource. It is set to singleton="true" via defaults (not explicitly set). The JDBC Connections in this DataSource pool (using dbcp2 as provided by Tomcat) have TLS configuration including client certificates, trusted server certificates, etc. I'd like to be able to "bounce" the DataSource so that each Connection is re-established in order to pick-up any new TLS configuration -- specifically, reloading the key store and trust store for the connection . What's the best way to do that? It looks like Tomcat will automatically register a JMX bean for the DataSource under /Catalina:DataSource/[host]/[webapp]/javax.sql.DataSource/[dataSourceNam e]. That JMX Bean has a "close" method that can be called. Calling "close" seems to kill the DataSource, but a webapp reload can resurrect it. There is also an "evict" method which takes zero arguments; that appears to call the DBCP2 eviction process which removes "old" pool members, not all. I wasn't able to find anything else via the JMX method. The class of the DataSource coming back from the JNDI lookup is org.apache.tomcat.dbcp.dbcp2.BasicDataSource. It looks like I might be able to downcast the object and call some other methods to stop / restart it, but that seems fragile. BasicDataSource.getConnectionPool is protected, but could be forced-open via reflection without a SecurityManager (yuck). Then GenericObjectPool.clear() could be called, but that only affects idle connections in the pool and you can't be sue you've evicted all of them. Any suggestions, other than reloading the context? I'm looking for a zero-downtime solution. Thanks, - -chris -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8bHoUACgkQHPApP6U8 pFgfqhAAol3JNOn/PIBZ0jD53N/jfIYjycF9NhHZ3EK7wMrB/clAl6rOVvR72C0E ljt7Q2zx69+tTezd6yOqx5KejCU6oF9bVBR1NDdwAf1QPG50m+B35k6S2Aj6o3Ge +5RNMS2OVDYHKi5nIxS5N1y8LtVcWBbo1LQN+QTjV6e5nEztg+fLct+HtDhwNYIv KwRDiDeztR/ulxKrDEHpuJzUHmIa+c+hD6teYLLPtEcOD11fXXO/VTtO3ZL37qCn JhEjb5ysoqHuIUH82CjzBghsEliZPczue5u7eaGhccnXR9y9WMM59yIf2jd3AH2L 2RVtw1/txdo3YmUGLJUi5IFQkQ8C8d13dSKT7I/KqO9NFywkiIPp7kimHmLdxvK5 vGJYFvZ6GV22oHWT0OaytaqbL1v4lf58k3frtt3bLRV7+2l78XUmsGsVksBr+3E+ 7S0nFw7Cc7vvDJP0euvHlZEEoK+EsnTtDLd7EoFLU6Mct2U58NT1nmp5Aepnia8/ oKSAd1SaHiPCZeqHadQl8N4dyTuRKtwbH1Hlv9+o7hnyISLcwf5Nx9PHjgVn9BEZ aOqpC5C0JxpGLXKDt4wTwjiIXdGo8c2T7pSV/pP82GnMhWAyHvGV1DPNHTvdoEKW Y4Z/azWfNdKPbKxHcOgu3Lfx2oDFpDn40Yx5SK823ERn/hNUTG4= =KgAg -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
