[#TODO] connection and pool improvements #1657
Conversation
… resource management
…ence activemq-pool tests use default broker name causing BrokerRegistry collisions Missing waitUntilStopped() after broker.stop() in tests
…ent and prevent task execution on closed connections
|
I need to think through impacts of making PooledConnectionFactory AutoCloseable. It usually is more of an init/destroy or start/stop lifecycle since it is long lived for the lifetime of the JVM. Adding AutoCloseable may lead to a lot of users getting WARN from IDE |
|
When using the resource adapter inside an app server for example (Apache TomEE), the connection pool might be created and destroyed multiple times without restart the entire server (deploy / undeploy). It delegates to stop(). For tests it's convenient to avoid leaking a connection factory from one test to the other or having to cope with try/catch. It's not the end of the world. I can revert that and rework all the tests. I don't think it harms though. |
…EvictsFromPoolTest
|
ok to merge @mattrpav |
|
@cshannon thoughts on adding AutoCloseable to PooledConnectionFactory in a patch release? I think this will make IDEs bark at users' existing code and create false negatives. Most things today (Camel routes, etc) use start()/stop() and not a try-with-resources. edit: Another option would be to create a sub-class (ie AutoPooledConnectionFactory) that extends the existing class and adds only the close() method. |
I guess it could cause some warnings to be thrown etc. in an IDE but it shouldn't break anyone's code or have any real other effects so I don't really think it's a big deal to add it. It also wouldn't hurt to just add it in 6.3.0 (ie not backport to a patch release). I guess it depends on how useful it is to add it for fixing tests and backports. I don't really think we need a subclass because adding the interface on the existing class won't actually cause any issues. |
3 participants
No description provided.