You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Kristian Rosenvold <kr...@gmail.com> on 2010/03/03 12:34:06 UTC

MavenITmng4482ForcePluginSnapshotUpdateTest and embedding, an intricate issue

MavenITmng4482ForcePluginSnapshotUpdateTest was failing on my CI 
environment, and I have found out why - the reason is a bit intricate:

My CI is one 32 bit linux node and a 64 bit linux node. Interestingly 
enought the 64 bit vm is "server" because AFAIK that's the only 64 bit 
vm there is.

The 4482 integration test was consistently failing on the 64 bit node, 
and intermittently on the 32 bit node. The failures on the 64 bit node 
were approx 20% VM crash (inside native Zip code used
by classloader to read jar file), 70% of a very odd error message 
indicating that plexus configuration was inconsistent and 10% success.

The test is trying to replace the local-repo version of an extension jar 
file. When forking maven in the int-test, the exenstion jar is locked 
for the duration of the test and unlocked when the forked vm terminates. 
When running the integration tests with verifier.forkMode=auto, the 
extension jar file is kept open as long as the classloader is active. On 
a windows box, this will effectively lock the
file, on a linux box it's even worse, as it seemingly allows you to 
replace the contents of the file but it actually corrupts it (or at 
least the in-memory image, unsure of the details).

Now since the 64 bit vm is "server", it actually has quite different 
behaviour when it comes to unloading stuff than the "client" vm. That's 
why it was failing so much.

I found a blog post that explains it well 
http://management-platform.blogspot.com/2009/01/classloaders-keeping-jar-files-open.html 

The post references a sun bug om the issue 
(http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5041014). 
<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5041014>The bug 
actually describes the problems I've been having on linux too.

In an isolated fix, I can disable the 4482 test when running 
verifier.forkMode=auto. But it seems to me like there is a larger 
problem here when running any kind of
embedded usage; is stuff like the "-U" option actually supported ?


Kristian


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: MavenITmng4482ForcePluginSnapshotUpdateTest and embedding, an intricate issue

Posted by Jason van Zyl <ja...@sonatype.com>.
On Mar 3, 2010, at 6:34 AM, Kristian Rosenvold wrote:

> MavenITmng4482ForcePluginSnapshotUpdateTest was failing on my CI environment, and I have found out why - the reason is a bit intricate:
> 
> My CI is one 32 bit linux node and a 64 bit linux node. Interestingly enought the 64 bit vm is "server" because AFAIK that's the only 64 bit vm there is.
> 
> The 4482 integration test was consistently failing on the 64 bit node, and intermittently on the 32 bit node. The failures on the 64 bit node were approx 20% VM crash (inside native Zip code used
> by classloader to read jar file), 70% of a very odd error message indicating that plexus configuration was inconsistent and 10% success.
> 
> The test is trying to replace the local-repo version of an extension jar file. When forking maven in the int-test, the exenstion jar is locked for the duration of the test and unlocked when the forked vm terminates. When running the integration tests with verifier.forkMode=auto, the extension jar file is kept open as long as the classloader is active. On a windows box, this will effectively lock the
> file, on a linux box it's even worse, as it seemingly allows you to replace the contents of the file but it actually corrupts it (or at least the in-memory image, unsure of the details).
> 
> Now since the 64 bit vm is "server", it actually has quite different behaviour when it comes to unloading stuff than the "client" vm. That's why it was failing so much.
> 
> I found a blog post that explains it well http://management-platform.blogspot.com/2009/01/classloaders-keeping-jar-files-open.html 
> The post references a sun bug om the issue (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5041014). <http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5041014>The bug actually describes the problems I've been having on linux too.
> 
> In an isolated fix, I can disable the 4482 test when running verifier.forkMode=auto. But it seems to me like there is a larger problem here when running any kind of
> embedded usage; is stuff like the "-U" option actually supported ?

I believe there is code to fix this bug in the classloader code in Geronimo or XBean I can't remember exactly where. But Dain explained to me at one point that this needed to be fixed because it was causing problems in Geronimo for an IBM customer. 

> 
> 
> Kristian
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------