7172 2009-07-30 08:10:07 +0000 Memory leak: TesterConfiguration kept in threads local storage once thread is over 2009-08-04 13:48:39 +0000 1 1 1 Unclassified mobileOK Basic checker Java Library unspecified PC Linux RESOLVED FIXED P2 normal --- 1 fd fd oldest_to_newest 26134 0 fd 2009-07-30 08:10:07 +0000 Problem ----- The configuration of the Checker is set as a per-thread singleton using Thread local storage. The Checker uses multithreading though, and references to the initial singleton are thus made in each of the thread created to check a given URI. Upon termination of the preprocessing, the Thread instances seem to return to a global static pool that is controlled by the JVM. The instances keep the reference to the the TesterConfiguration instance as long as they haven't been re-used. No consequence when the Checker is run once on a given URI, as the whole process is killed at the end. It is a major problem though when the Checker is to stay in memory: the TesterConfiguration instance now contains references to most of the structures created during preprocessing and thus may require an awful lot of memory. When 50-100 instances of TesterConfiguration are in memory, OutOfMemory exceptions start to show up. Solution ----- The best solution would be to get rid of the per-thread singleton but that would require a fair amount of changes. A simple solution is to reset the per-thread TesterConfiguration singleton at the end of each thread. 26137 1 fd 2009-07-30 08:59:22 +0000 The Preprocessor class now is in charge of setting and then resetting the TesterConfiguration instance in processResource (main method of a Runnable thread). Similar code to set the configuration in the Resource class was removed, as it's not needed anymore. 26145 2 fd 2009-07-30 16:00:38 +0000 Call to shutdown() on the ExecutorService thread pool added at the end of Preprocessor.preprocess as well, so that Thread instances may be garbage collected as well.