[CONJ-232] Failover : Thread cleaning Created: 2015-12-09 Updated: 2016-01-04 Resolved: 2015-12-31 |
|
| Status: | Closed |
| Project: | MariaDB Connector/J |
| Component/s: | Failover |
| Affects Version/s: | 1.2.0, 1.3.0, 1.2.2, 1.2.3, 1.3.2, 1.3.1 |
| Fix Version/s: | 1.3.4 |
| Type: | Bug | Priority: | Major |
| Reporter: | Diego Dupin | Assignee: | Diego Dupin |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Description |
|
received mail : scheduledFailover = Executors.newSingleThreadScheduledExecutor().scheduleWithFixedDelay scheduledFailover being the future from the dynamically constructed pool. Unfortunately in java.util.concurrent.ThreadPoolExecutor (and in this case the extending class ScheduledThreadPoolExecutor) there is what I would call a defect around garbage collection. The inner class of ThreadPoolExecutor "Worker" (which is used to keep the thread alive and accept tasks) is not static. And thus once a thread has started a reference is maintained to the parent ThreadPoolExecutor, preventing the thread and the pool from ever being collected unless a .shutdown() is invoked. I say this is a defect in java because Doug L. did override the finalizer with a "shutdown()" call inside, so it seems like this was not the desired behavior, but sadly that wont be invoked once any threads start....btw this is still the case in the latest version of java. The end result is that these threads, and ThreadPoolExecutors are NEVER collected. We have seen servers with > 300k threads due to this defect. Some possible solutions (in order of my least preferable to what I think would be most preferable....personally):
|
| Comments |
| Comment by Diego Dupin [ 2015-12-31 ] |
|
done by commit : https://github.com/MariaDB/mariadb-connector-j/pull/60 |