+++ This bug was initially created as a clone of Bug #1143048 +++ Description of problem: Either database or postgres plugin leave a dangling timer thread running past the plugin container lifecycle. These threads hold on to the classloader of the code that started them and thus keeping reference to the plugin classloader of the database plugin. Each plugin container restart (not a full agent restart) leaves 1 such thread running so over time there is a large number of classloaders accumulated and the JVM will eventually run out of permgen due to the number of loaded classes. Version-Release number of selected component (if applicable): 4.13.0-SNAPSHOT How reproducible: always Steps to Reproduce: 1. Inventory a postgres server 2. restart plugin container repeatedly Actual results: OOM error reporting permgen depletion Expected results: no errors Additional info:
master: 1cd368ebd06bde6a496b6afbc442c3a937f013fb release/jon3.3.x: 91ecc35da63f74d2b4571c55f28b9be4849a94c4 Author: Lukas Krejci <lkrejci> Date: Wed Oct 8 17:25:17 2014 +0200 [BZ 1143050] Work around the CL leak in Posgres JDBC driver. (cherry picked from commit 1cd368ebd06bde6a496b6afbc442c3a937f013fb)
Moving to ON_QA as available to test with the latest brew build: https://brewweb.devel.redhat.com//buildinfo?buildID=394734
Still visible in Version : 3.3.0.ER05 Build Number : 92b6d6a:2cdb528 Not sure if the leak is in postgres plugin. Heapdump provided. Please create a separate bz if necessary
Judged by the inspection of the provided heapdumps, the leak seems to be coming from the rhqserver plugin. Could you please re-test this with the rhqserver agent plugin deleted from the JON server?
FYI, created BZ 1156035 to track the rhqserver plugin leak.
You are right the issues is not visible any more without the rhqserver agent plugin. Version : 3.3.0.ER05 Build Number : 92b6d6a:2cdb528