Closing since discoverd and corrected with CONJ-671

I don't see this is fixed at all. I still get the same error with v2.4.3.

I believe the source of the issue is that the class org.mariadb.jdbc.internal.protocol.AbstractQueryProtocol has a ThreadPoolExecutor stored in the variable "readScheduler" that is never shutdown... there maybe other resources in mariadb's connector/j that aren't properly shut down as well but this is on I always run into as well.

The org.mariadb.jdbc.Driver class should be creating a DriverAction that should shutdown these executors and free resources etc. "DriverManager.registerDriver(new Driver());" is where the DriverAction should be passed which is called when DriverManager.deregisterDriver is called.

right, the error has been reproduced.
Correction is done with this commit correcting these thread leak.

This will only be in 2.5.0 release since it changes the interface of pool implementation (a new close method) that has to be implemented for customs implementations.

Nice work Diego, I didn't test the changes yet but I reviewed the commit and you did exactly what I was thinking needed to be done when I was originally reviewing the problem.

One tiny concern that would be irrelevant to me but maybe valid for someone else... If the default provider is used at some point and then setSchedulerProvider is used later with a custom provider, the resources used in the default provider wouldn't be closed... not sure the proper handling of what to do in that case other than tracking all providers used and then verifying on the deregister that all were closed, or if a simple note in the javadoc would be fine, but I would think whoever calls that method probably shouldn't have used the default provider to start with if a custom provider was intended.

Another thought would be just to call close on the default provider and the current provider set, and if the coder is doing something strange with more then one custom provider their responsible for closing?

reopenning issue, since it might not be relevant for the use case, but it would be better to handle that anyway : after deregistration of the driver, if it's registered afterwhile, the thread pools that have been already used and registered as static like here would be in an inconsistent state.

I'll handle closing previous implementation when assigning custom Implementation at the same time.