The ASConnection of the EAP plug-in has a static thread pool which runs connection "cleaners" to prevent connection leakage.
When the plug-in container was restarted, the classes of the plug-in were loaded again. However the static thread pool was never shut down which left a thread running with a context classloader from the previous plug-in container.
The stale thread lead to an eventual out-of-memory exception because of depleted permgen memory needed to hold all the classes from all the plug-in container runs in the agent's lifetime.
The AS7 plug-in now has a plug-in lifecycle listener that shuts down the aforementioned thread pool preventing the leak from happening.
+++ This bug was initially created as a clone of Bug #1076258 +++
Description of problem:
ASConnection has a static thread pool which runs connection "cleaners" to prevent connection leakage.
On every plugin container restart, the classes of the plugin are loaded anew, but the above thread pool is never shut down, leaving a thread running with a context classloader from the previous plugin container run.
This leads to an eventual OOME because of depleted perm gen memory needed to hold all the classes from all the plugin container runs in the agent's lifetime.
This problem has been made more apparent by our switch to HTTP client which is a much heavier library than the java's own Authenticator and HTTPUrlConnection we used before (but which had their own deal of problems).
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. inventory an AS7
2. periodically restart the plugin container without fully restarting the agent
out of memory error after a couple of repetitions (>10 usually, but depends on your perm gen set up)
--- Additional comment from Lukas Krejci on 2014-03-13 21:44:44 EDT ---
Author: Lukas Krejci <email@example.com>
Date: Fri Mar 14 02:42:44 2014 +0100
[BZ 1076258] Fix classloader leak in as7 plugin
The plugin-wide thread pool for closing stale connections was leaving
threads running and those threads held on to the "old" plugin classloaders
from previous plugin container "runs".
The AS7 plugin now has a plugin lifecycle listener that shuts down that
thread pool preventing that leak from happening.
Moving to ON_QA as available to test with brew build of DR01: https://brewweb.devel.redhat.com//buildinfo?buildID=373993
BZ 1119516 is ON_QA, so this can, too, be retested. Moving to ON_QA again.
After repeatedly restarting the plugin container the PermGen used memory keeps growing, thus the class loader leak is still visible. After consulting this issue with devs it seems that the problem might not be specifically in EAP's classloader but rather in other component. The issue is covered by BZ 1134902, thus adding 'depends on' flag.
Build Number :
1- AS7 is in inventory
2- schedule agent operation "Restart Plugin Container" each 2 minutes
After 6 hours which corresponds to ~ 180 Plugin container restarts is the perm gen still stable
This verifies leaks in AS7 plugin. There are other leaks which are covered by bz 1134902
*** Bug 1119516 has been marked as a duplicate of this bug. ***