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:
I assume you hit submit too soon. What's the problem?
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)
Created attachment 861388 [details] Build log
Exactly which version of xmvn did you test? Which version of apache-ivy? Which version of ivy-local?
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
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
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.
Fixed upstream in a21439c
Fixed in xmvn-2.0.1-1
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