You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ant.apache.org by Markus Oley <ma...@vsa.de> on 2011/07/07 15:57:17 UTC

Classloader not collected using junit4 in ant 1.8.1

Hi all, 

I have a problem which classloading and ant 1.8.1, junit 4.8.2 and log4j
1.2.16 or any 
third-party libraries: 

<junit reloading="true"> 
<classpath refid="junit.classpath.ref"/> 
<batchtest fork="false"> 
<fileset refid="${test-fileset-refid}"/> 
</batchtest> 
..... 
</junit> 

with the classpath: 
<fileset dir="${modules.dir}"> 
<include name="**/lib*/*.jar" /> 
<exclude name="**/**/log4j.jar"/> 
</fileset> 

Following target is called: 
<target name="only.junit4.example"> 
<antcall target="only.junit4.example1"/> 
<antcall target="only.junit4.example2"/> 
</target>

only.junit4.example1 and only.junit4.example2 both call the target with
junit-call above 
with different filesets. 

in the testclasses of both antcalls I have static variables private
static LOGGER = Logger.getLogger(... .class);

If I create a heapdump after the second target there's the following
behaviour: 

1. If I remove exclude log4j from fileset, two SplitClassLoader-instance
are still available, which seem to be never gc'd
2. If I start it with the exclude-tag, but give log4j with -lib to ant,
both splitcalssloaders are gc'd correctly, but it seems there are
multiple AntClassLoader5-instance not gc'd

Problem: 

Without forking every testcase (not suite) the memory-usage increases
step by step, because neither the classloaders nor any static reference
is gcd (singletons from legacycode). 
After half my tests have run, I get a PermGenSpace-OOM (configured 500M
for permgenspace)

1. Is this behaviour of the classloaders a behaviour you would expect or
do we have a classloader-leak?
2. Do we have to cleanup all statics and singletons to decrease
memory-footprint or does a generic solution exist?
3. parameter -lib is only a workaround, isn't it? How should we give the
libs to ant? 
4. Is it possible to use reloading="false"? I guess I didn't have any
other behaviour

Any help welcome 

Thank you by now 
Markus

Re: Classloader not collected using junit4 in ant 1.8.1

Posted by Stefan Bodewig <bo...@apache.org>.
On 2011-07-07, Markus Oley wrote:

> I have a problem which classloading and ant 1.8.1, junit 4.8.2 and
> log4j 1.2.16 or any third-party libraries:

Any chance you could try 1.8.2?  I vaguely recall we fixed something
there but can't find any evidence for it in svn.

It would also be good if you could try to figure out whether <junit> or
<antcall> is causing the problem by moving the <antcall> out of the way.

> 1. Is this behaviour of the classloaders a behaviour you would expect
> or do we have a classloader-leak?

It definitively sounds like a bug to me.

> 2. Do we have to cleanup all statics and singletons to decrease
> memory-footprint or does a generic solution exist?

In theory Ant will remove all references to the classloaders but it is
unclear to me whether log4j may be keeping hold on them.

> 3. parameter -lib is only a workaround, isn't it? How should we give
> the libs to ant?

-libs is not a workaround at all.  It is the recommended way to put
things into the system classloader for a runnign Ant instance.

> 4. Is it possible to use reloading="false"? I guess I didn't have any
> other behaviour

With reloading="false" all test run within the same <junit> task
instance should be sharing the same classloader.  In your case you have
two different <junit> tasks and thus two different classloaders anyway.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org