[
https://issues.jboss.org/browse/JBIDE-22658?page=com.atlassian.jira.plugi...
]
arjan tijms commented on JBIDE-22658:
-------------------------------------
{quote} But one hour seems to be too long anyway. {quote}
It's pretty long indeed and it takes 100+% CPU while doing, so when on battery the
laptop barely gets through that hour. In a multi module project it easily gets worse, as
it seems (not tested explicitly) that every module will take this time again if the
dependency is in a parent pom.
Infinite or very long hang in CDI builder with Payara embedded maven
dep
------------------------------------------------------------------------
Key: JBIDE-22658
URL:
https://issues.jboss.org/browse/JBIDE-22658
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: cdi
Reporter: arjan tijms
Assignee: Viacheslav Kabanovich
Fix For: 4.4.x
In the latest JBoss Tools for Eclipse Mars .2 (would be great if it was easy to see the
main version easily, but I guess it's 4.3.1), the CDI builder either infinitely hangs
or takes an enormous amount of time (an hour at least on a core M laptop) when payara
embedded is present as (test) dependency in a maven project.
During this hang I took a stack trace, which looks as follows:
{noformat}
"Worker-20" #96 prio=5 os_prio=31 tid=0x0000000101512000 nid=0x14803 runnable
[0x0000700003fde000]
java.lang.Thread.State: RUNNABLE
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.<init>(ZipFile.java:219)
at java.util.zip.ZipFile.<init>(ZipFile.java:149)
at java.util.zip.ZipFile.<init>(ZipFile.java:163)
at
org.eclipse.jdt.internal.core.JavaModelManager.getZipFile(JavaModelManager.java:2678)
at
org.eclipse.jdt.internal.core.JavaModelManager.getZipFile(JavaModelManager.java:2644)
at
org.eclipse.jdt.internal.core.JarPackageFragmentRoot.getJar(JarPackageFragmentRoot.java:156)
at org.eclipse.jdt.internal.core.ClassFile.getJarBinaryTypeInfo(ClassFile.java:355)
at org.eclipse.jdt.internal.core.ClassFile.getBinaryTypeInfo(ClassFile.java:290)
at org.eclipse.jdt.internal.core.ClassFile.getBinaryTypeInfo(ClassFile.java:284)
at org.eclipse.jdt.internal.core.ClassFile.buildStructure(ClassFile.java:93)
at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:259)
at
org.eclipse.jdt.internal.core.SourceRefElement.generateInfos(SourceRefElement.java:107)
at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:579)
at org.eclipse.jdt.internal.core.BinaryType.getElementInfo(BinaryType.java:287)
at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:302)
at org.eclipse.jdt.internal.core.JavaElement.exists(JavaElement.java:220)
at
org.jboss.tools.cdi.internal.core.scanner.ImplementationCollector.process(ImplementationCollector.java:41)
at
org.jboss.tools.cdi.internal.core.scanner.ImplementationCollector.<init>(ImplementationCollector.java:32)
at org.jboss.tools.cdi.internal.core.impl.CDIProject.rebuildBeans(CDIProject.java:1309)
at org.jboss.tools.cdi.internal.core.impl.CDIProject.update(CDIProject.java:1216)
- locked <0x000000078ecd93d8> (a org.jboss.tools.cdi.internal.core.impl.CDICache)
at
org.jboss.tools.cdi.internal.core.impl.definition.DefinitionContext.applyWorkingCopy(DefinitionContext.java:442)
at org.jboss.tools.cdi.core.CDICoreBuilder.build(CDICoreBuilder.java:267)
at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:734)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:205)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:245)
at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:300)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:303)
at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:359)
at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:382)
at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:144)
at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:235)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
{noformat}
I debugged Eclipse with a second Eclipse, and it appeared that the code is repeatedly
opening
{{.m2/repository/fish/payara/extras/payara-embedded-all/4.1.1.162/payara-embedded-all-4.1.1.162.jar}}
from {{CDIProject#rebuildBeans}}.
The specific line of code is:
{code:java}
ImplementationCollector ic = new ImplementationCollector(typeDefinitions);
{code}
The number of type definitions it seems to go through in
{{ImplementationCollector#process}} is *33009* and the loop looks to be making progress,
so it's more likely just incredibly slow and not an infinite hang.
The dependency in pom.xml looks as follows:
{code:xml}
<dependency>
<groupId>fish.payara.extras</groupId>
<artifactId>payara-embedded-all</artifactId>
<version>4.1.1.162</version>
<scope>test</scope>
</dependency>
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)