-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Mark,
On 8/2/20 11:55, Mark Thomas wrote: > On July 24, 2020 5:46:45 PM UTC, Christopher Schultz <ch...@christopherschultz.net> wrote: > 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/[dataSourceN am > > 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 >> >> --------------------------------------------------------------------- >> >> 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. Okay. If I can come up with some suggestions, it that something you could look at getting into upstream? We can modify our own copy of course (have we diverged significantly at this point? Or was that pre-dbcp-2.x?) but upstream is better IMO if possible. > 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. Yeah, that might be slow. I'm also not sure what my options are for querying the current client certificate being used. > 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. That sounds wonderfully hacky, but what I really need to do is have the pool reconfigure the driver with a "new" connection URL. The URL of course won't have changed, but presumably re-initing the pool will cause everything to be re-read, including (my goal) the keystore. Now, maybe I'm putting too much faith in the DriverManager and/or JDBC driver. It's possible that I will have to literally change the URL in some trivial way so that the DM/driver doesn't just say "oh, I have one of those already!" and return the existing objects. Certainly further testing of those components is warranted before proceeding any further with the connection pool. It might all be wasted effort. Thanks, - -chris -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8oPB0ACgkQHPApP6U8 pFibNw/+MwUGt+aohxG6jQOup3TKCTC5B6aXEO6VByJq/9DOETlngiFXJGE+lctA H3Ma+Kr+VpOvEzXxtxEDcvZlTwLy3dGWsiXeR0EDDZEoSwxDDg6LmRwWAfdT1OBo dRc904x9N2njA302LpPLiS7auNxO0njzkCcS/J3q2GqnwMRBFPJlPWQryxwkw5HX Ro3FtJf6Y8YbOLH7JuetQtAa7Czqs6MY8YlvqJP03hkboyX3hUQ3AwcY+XOJ7KQR OAUdtQFqc6b3QoNtahXmv3LsQYH6me/Nc1yzCHh0hDJ22SKCDzEUN9hEyOLu3LrF +W6Wgop7Bx75WroDWbf4aJ4fEWGzOOJn8VMN3xDJeANO0O1e/W1u4ftFOP6lEuZJ UNvDswdj1JmcbhxKWzgkkz0IAUnnY0h49tSpYD+zkwi1wgf3yGhQY05gadhqXfH1 lN9mL7spHJrNnmmDUphoszDCkn0ZxmXU8xTl14vXHsl04FNbmJegzq99nlr1x7Z7 H3ZOVJzb3wBXK3ctKJGsJ8eJ6eIQBn5rFtd+fMqoI+2mamkvXjy7GRtnm8wAwECP noTwHb69IW0KZtriXFSsfi3l2pBT3WtNYHZjJapeNy1uW11YnKlLOzb5ZUrtYi7N UHSfpLP4Lk7olcoq/7yF91tIfY27FwTew2CYTCef6uL2SeZPyAk= =DMvU -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
