This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
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.
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.