[CONJ-563] Thread leak reported by Tomcat when using the connector Created: 2017-12-29 Updated: 2019-09-13 Resolved: 2019-09-11 |
|
| Status: | Closed |
| Project: | MariaDB Connector/J |
| Component/s: | batch |
| Affects Version/s: | 2.2.1 |
| Fix Version/s: | 2.5.0 |
| Type: | Task | Priority: | Minor |
| Reporter: | Bugra Gedik | Assignee: | Diego Dupin |
| Resolution: | Fixed | Votes: | 3 |
| Labels: | None | ||
| Environment: |
Linux 64-bit rhel07 |
||
| Issue Links: |
|
||||||||||||||||
| Description |
|
When used in a Tomcat application, the following thread leaks are reported sometimes:
The Driver is properly unloaded. It seems like these threads are not being joined. |
| Comments |
| Comment by Diego Dupin [ 2019-01-11 ] |
|
Closing since discoverd and corrected with |
| Comment by Arthur Fiedler [ 2019-09-06 ] |
|
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. |
| Comment by Diego Dupin [ 2019-09-09 ] |
|
right, the error has been reproduced. 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. |
| Comment by Arthur Fiedler [ 2019-09-10 ] |
|
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. |
| Comment by Arthur Fiedler [ 2019-09-10 ] |
|
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? |
| Comment by Diego Dupin [ 2019-09-10 ] |
|
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. |