swaldman
commented
9 months ago Thanks (years ago i'm a effing flake) for the very complete test.
I do see the offending lines in the mariadb log. Running against an instrumented c3p0, though, what I see is that the ComboPooledDataSource is constructed (I log from inside the constructor call of parent class AbstractPoolBackedDataSource), but there is no call to close() (logging in the same way from that method does not appear in the test run). It looks like the destructor threads don't succeed because they are never run because the DataSource is never destroyed.
I do see in your applicationContext.xml the destroy-method="close" attribute. So I'd think it should close! I wonder, though, if maybe the testing framework is not very careful about honoring this?
In this context, the only cost of this is really those log messages. Connections are destroyed abruptly by the client process dying, rather than cleanly by a close. It's not great, but not the worst thing in the world.
Nevertheless, if it is somehow the case that ComboPooledDataSource.close() is getting called, but somehow the resource cleanup threads are not doing their work, I would want to address that. But so far, I just can't seen any evidence that the DataSource is receiving a call to close()
It was very kind of you, now years ago, to write up so complete a poc. I am very sorry for a long absence from this project.
Hello,
I do have an issue with the DB connections from the c3p0 pool always get aborted after my JUnit tests have completed. It appears that the
"Resource Destroyer in BasicResourcePool.close()"thread cannot finish its cleanup before the JVM exits.I prepared a simple project with a single JUnit test to demonstrate the problem: https://github.com/friederici/c3p0_close_poc
Up to c3p0 version 0.9.0.4, there was no seperate cleanup thread and the connections get closed cleanly. Since c3p0 version 0.9.1 (up to the newest version 0.9.5.5) connections do not get closed. MariaDB logs then something like: