On July 24, 2020 5:46:45 PM UTC, Christopher Schultz <ch...@christopherschultz.net> wrote: >-----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
Short of code changes, I think you have identified all the solutions I can think of. If you want to be able to force a refresh of all the objects in the pool then you'd have to start with code changes to Commons Pool. Could you do something with the validation query? Something that queried some database provided env var that told you if the current cert was being used? That would require a round trip though which would be slow. How about simply dropping all the connections at the database server side? The next validation query fails and picks up a new connection. Assuming you updated the files on the client side I think you would pick up the new config. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
