Bug 1063301

Summary: Ivy local resolution: too many worker threads leading to OOM
Product: [Fedora] Fedora Reporter: Michael Simacek <msimacek>
Component: xmvnAssignee: Mikolaj Izdebski <mizdebsk>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: mizdebsk, msimacek, msrb, sochotni
Target Milestone: ---Keywords: Upstream
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: 2.0.1-1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-06-09 02:10:07 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Build log none

Description Michael Simacek 2014-02-10 13:06:50 UTC 
Description of problem:


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
Comment 1 Mikolaj Izdebski 2014-02-10 13:08:32 UTC 
I assume you hit submit too soon.
What's the problem?
Comment 2 Michael Simacek 2014-02-10 13:26:48 UTC 
Yes, sorry for that.

Description of the problem:
Building complex projects with Ivy with XMvn local resolution leads to OOM error, because it creates too many worker threads. It seems like the depmap resolution worker threads are not properly destroyed. I tried watching the build with thermostat and there was almost one thousand of them.

Steps to reproduce:
Rebuild: http://msimacek.fedorapeople.org/lucene-4.6.1-1.fc20.src.rpm

End of stacktrace:
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Thread.java:713)
at java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:949)
at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1360)
at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:132)
at org.fedoraproject.maven.resolver.impl.DepmapReader.readMappings(DepmapReader.java:99)
at org.fedoraproject.maven.resolver.impl.DefaultDependencyMap.initialize(DefaultDependencyMap.java:234)
Comment 3 Michael Simacek 2014-02-10 13:29:07 UTC 
Created attachment 861388 [details]
Build log
Comment 4 Mikolaj Izdebski 2014-02-10 13:31:08 UTC 
Exactly which version of xmvn did you test?  Which version of apache-ivy? Which version of ivy-local?
Comment 5 Michael Simacek 2014-02-10 14:07:42 UTC 
Oh, sorry, it seems like it happens only when running tests and the SRPM had tests disabled. Could you please download it again? (Or just add test as another ant target)

xmvn-1.5.0-0.19.gitcb3a0a6.fc21.noarch
ivy-local-3.5.0-2.fc21.noarch
apache-ivy-2.3.0-9.fc21.noarch
Comment 6 Fedora Admin XMLRPC Client 2014-04-24 12:47:33 UTC 
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 7 Mikolaj Izdebski 2014-05-12 04:48:03 UTC 
Cause: XMvn spawns background threads to initialize some "eager" singletons in order to minimize delay on their first use and improve overall performance.

Consequence: Java allows isolated class realms to have multiple singleton instances, so hundreds of initializer threads may be spawned in applications heavily using isolated realms, such as in unit testing.

Fix: Use lazy initialization instead of eager initialization.

Result: Lower performance, but better worst-case behavior.
Comment 8 Mikolaj Izdebski 2014-06-02 06:22:10 UTC 
Fixed upstream in a21439c
Comment 9 Mikolaj Izdebski 2014-06-06 12:03:33 UTC 
Fixed in xmvn-2.0.1-1
Comment 10 Mikolaj Izdebski 2014-06-09 02:10:07 UTC 
I believe that this bug is fixed in xmvn-2.0.1-1,
which is available in Fedora Rawhide, so I am closing this bug now.

The build containing the fix can be found at Koji:
http://koji.fedoraproject.org/koji/buildinfo?buildID=521513