[JBoss JIRA] (JBIDE-23767) Jenkins build for OpenShift is failing with mirror problems
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23767?page=com.atlassian.jira.plugi... ]
Andre Dietisheim commented on JBIDE-23767:
------------------------------------------
[~nickboldt] ok, gotcha, thanks for the pointer, fixing it.
Did we announce this or how did I miss this change that breaks our build?
> Jenkins build for OpenShift is failing with mirror problems
> -----------------------------------------------------------
>
> Key: JBIDE-23767
> URL: https://issues.jboss.org/browse/JBIDE-23767
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.4.3.AM1
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Priority: Critical
> Labels: build
> Fix For: 4.4.3.AM2
>
>
> Starting with [#1782|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JBossTools/view/JBossTools_Master/job/jbosstools-openshift_master/1782/] jenkins build for OpenShift started to fail with problems in the mirror tool (basic maven build competes successfully):
> {code}
> Results :
> Tests run: 15, Failures: 0, Errors: 0, Skipped: 0
> [INFO] All tests passed!
> [INFO]
> [INFO] --- tycho-p2-extras-plugin:0.26.0:compare-version-with-baselines (default) @ org.jboss.tools.openshift.cdk.server.test ---
> [INFO] Skipped
> [INFO] ------------------------------------------------------------------------
> [INFO] Reactor Summary:
> [INFO]
> [INFO] openshift.tests .................................... SUCCESS [ 1.115 s]
> [INFO] org.jboss.tools.openshift.egit.test ................ SUCCESS [ 20.698 s]
> [INFO] org.jboss.tools.openshift.express.test ............. SUCCESS [ 17.420 s]
> [INFO] org.jboss.tools.openshift.test ..................... SUCCESS [ 40.148 s]
> [INFO] org.jboss.tools.openshift.cdk.server.test .......... SUCCESS [ 17.296 s]
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD SUCCESS
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 02:20 min
> [INFO] Finished at: 2017-01-18T05:49:08-05:00
> [INFO] Final Memory: 68M/657M
> [INFO] ------------------------------------------------------------------------
> Terminating xvnc.
> $ vncserver -kill :91
> Killing Xvnc process ID 589
> Checking console output
> /qa/hudson_master/hudson_home/hudson_workspace/jobs/jbosstools-openshift_master/builds/1788/log:
> [WARNING] Mirror tool: Problems resolving provisioning plan.: [Unable to satisfy dependency from v20170118-1044.JBoss Tools OpenShift Nightly Build Update Site 1.0.0._F_A8ccKm-FVF2YSFS8veUq9Grd2 to org.jboss.tools.openshift.js.feature.source.feature.group [1.0.0.v20161116-1518].; Unable to satisfy dependency from v20170118-1044.JBoss Tools OpenShift Nightly Build Update Site 1.0.0._F_A8ccKm-FVF2YSFS8veUq9Grd2 to org.jboss.tools.openshift.js.feature.feature.group [1.0.0.v20161116-1518].; Unable to satisfy dependency from v20170118-1044.JBoss Tools OpenShift Nightly Build Update Site 1.0.0._F_A8ccKm-FVF2YSFS8veUq9Grd2 to org.jboss.tools.openshift.test.feature.source.feature.group [3.3.1.v20161124-1528].; Unable to satisfy dependency from v20170118-1044.JBoss Tools OpenShift Nightly Build Update Site 1.0.0._F_A8ccKm-FVF2YSFS8veUq9Grd2 to org.jboss.tools.openshift.cdk.test.feature.feature.group [3.3.1.v20160928-2042].; Unable to satisfy dependency from v20170118-1044.JBoss Tools OpenShift Nightly Build Update Site 1.0.0._F_A8ccKm-FVF2YSFS8veUq9Grd2 to org.jboss.tools.openshift.feature.feature.group [3.3.1.v20161202-0851].; Unable to satisfy dependency from v20170118-1044.JBoss Tools OpenShift Nightly Build Update Site 1.0.0._F_A8ccKm-FVF2YSFS8veUq9Grd2 to org.jboss.tools.openshift.express.test.feature.feature.group [3.3.1.v20160919-1711].; Unable to satisfy dependency from v20170118-1044.JBoss Tools OpenShift Nightly Build Update Site 1.0.0._F_A8ccKm-FVF2YSFS8veUq9Grd2 to org.jboss.tools.openshift.egit.integration.feature.feature.group [3.3.1.v20160919-1711].; Unable to satisfy dependency from v20170118-1044.JBoss Tools OpenShift Nightly Build Update Site 1.0.0._F_A8ccKm-FVF2YSFS8veUq9Grd2 to org.jboss.tools.openshift.egit.integration.test.feature.feature.group [3.3.1.v20160919-1711].; Unable to satisfy dependency from v20170118-1044.JBoss Tools OpenShift Nightly Build Update Site 1.0.0._F_A8ccKm-FVF2YSFS8veUq9Grd2 to org.jboss.tools.openshift.feature.source.feature.group [3.3.1.v20161202-0851].; Unable to satisfy dependency from v20170118-1044.JBoss Tools OpenShift Nightly Build Update Site 1.0.0._F_A8ccKm-FVF2YSFS8veUq9Grd2 to org.jboss.tools.openshift.egit.integration.feature.source.feature.group [3.3.1.v20160919-1711].; Unable to satisfy dependency from v20170118-1044.JBoss Tools OpenShift Nightly Build Update Site 1.0.0._F_A8ccKm-FVF2YSFS8veUq9Grd2 to org.jboss.tools.openshift.test.feature.feature.group [3.3.1.v20161124-1528].; Unable to satisfy dependency from v20170118-1044.JBoss Tools OpenShift Nightly Build Update Site 1.0.0._F_A8ccKm-FVF2YSFS8veUq9Grd2 to org.jboss.tools.openshift.express.feature.source.feature.group [3.3.1.v20161117-0751].; Unable to satisfy dependency from v20170118-1044.JBoss Tools OpenShift Nightly Build Update Site 1.0.0._F_A8ccKm-FVF2YSFS8veUq9Grd2 to org.jboss.tools.openshift.cdk.feature.feature.group [3.3.1.v20161025-0131].; Unable to satisfy dependency from v20170118-1044.JBoss Tools OpenShift Nightly Build Update Site 1.0.0._F_A8ccKm-FVF2YSFS8veUq9Grd2 to org.jboss.tools.openshift.egit.integration.test.feature.source.feature.group [3.3.1.v20160919-1711].; Unable to satisfy dependency from v20170118-1044.JBoss Tools OpenShift Nightly Build Update Site 1.0.0._F_A8ccKm-FVF2YSFS8veUq9Grd2 to org.jboss.tools.openshift.cdk.test.feature.source.feature.group [3.3.1.v20160928-2042].; Unable to satisfy dependency from v20170118-1044.JBoss Tools OpenShift Nightly Build Update Site 1.0.0._F_A8ccKm-FVF2YSFS8veUq9Grd2 to org.jboss.tools.openshift.express.test.feature.source.feature.group [3.3.1.v20160919-1711].; Unable to satisfy dependency from v20170118-1044.JBoss Tools OpenShift Nightly Build Update Site 1.0.0._F_A8ccKm-FVF2YSFS8veUq9Grd2 to org.jboss.tools.openshift.express.feature.feature.group [3.3.1.v20161117-0751].; Unable to satisfy dependency from v20170118-1044.JBoss Tools OpenShift Nightly Build Update Site 1.0.0._F_A8ccKm-FVF2YSFS8veUq9Grd2 to org.jboss.tools.openshift.cdk.feature.source.feature.group [3.3.1.v20161025-0131].]
> Build step 'Jenkins Text Finder' changed build result to FAILURE
> Archiving artifacts
> Recording test results
> [description-setter] Description set:
> Sending e-mails to: jbosstools-builds(a)lists.jboss.org adietish(a)redhat.com jcantril(a)redhat.com fbricon(a)redhat.com slkabanovich(a)gmail.com
> Notifying upstream projects of job completion
> Finished: FAILURE
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (JBDS-4252) Installer waits for failed Virtualbox installation (MacOS)
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBDS-4252?page=com.atlassian.jira.plugin.... ]
Andre Dietisheim edited comment on JBDS-4252 at 1/19/17 4:48 AM:
-----------------------------------------------------------------
And then, given the Virtualbox installation failed, why would you have the CDK installation wait for the Virtualbox installation to finish (see screenshot: CDK install process says it's waiting for the Virtualbox install to finish even though the virtualbox install is finished, it failed)? Why not have the installer stopping and telling the user that the installation could not be processed?
was (Author: adietish):
And then, given the Virtualbox installation failed, why would you have the CDK installation wait for the Virtualbox installation to finish (see screenshot)? Why not have the installer stopping and telling the user that the installation could not be processed?
> Installer waits for failed Virtualbox installation (MacOS)
> ----------------------------------------------------------
>
> Key: JBDS-4252
> URL: https://issues.jboss.org/browse/JBDS-4252
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Enhancement
> Components: platform-installer
> Affects Versions: 10.2.0.GA
> Reporter: Andre Dietisheim
> Assignee: Denis Golovin
> Fix For: 10.3.0.AM2
>
> Attachments: waiting-for-virtualbox-install-that-failed.png
>
>
> steps to reproduce:
> # ASSERT: make sure that you have VirtualBox 5.1.x running but the app is removed from the Applications folder
> # EXEC: launch installer, log in and select VirtualBox etc.
> Result:
> Installer fails to install VirtualBox.
> !waiting-for-virtualbox-install-that-failed.png!
> In the logs you see the following:
> {code}
> 0:233: execution error: installer: Error - The installer has detected running virtual machines. Please shut down all running VirtualBox machines and then restart the installation. (1)
> {code}
> The installer simply states "Failed". It would be nice if the installer could provide more details on why/what failed. Sparing me from having to inspect the logs.
> It simply states "Failed" for VirtualBox, the "Red Hat Container Development Kit" process is waiting for VirtualBox to get installed even though that failed.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (JBDS-4252) Installer waits for failed Virtualbox installation (MacOS)
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBDS-4252?page=com.atlassian.jira.plugin.... ]
Andre Dietisheim commented on JBDS-4252:
----------------------------------------
And then, given the Virtualbox installation failed, why would you have the CDK installation wait for the Virtualbox installation to finish (see screenshot)? Why not have the installer stopping and telling the user that the installation could not be processed?
> Installer waits for failed Virtualbox installation (MacOS)
> ----------------------------------------------------------
>
> Key: JBDS-4252
> URL: https://issues.jboss.org/browse/JBDS-4252
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Enhancement
> Components: platform-installer
> Affects Versions: 10.2.0.GA
> Reporter: Andre Dietisheim
> Assignee: Denis Golovin
> Fix For: 10.3.0.AM2
>
> Attachments: waiting-for-virtualbox-install-that-failed.png
>
>
> steps to reproduce:
> # ASSERT: make sure that you have VirtualBox 5.1.x running but the app is removed from the Applications folder
> # EXEC: launch installer, log in and select VirtualBox etc.
> Result:
> Installer fails to install VirtualBox.
> !waiting-for-virtualbox-install-that-failed.png!
> In the logs you see the following:
> {code}
> 0:233: execution error: installer: Error - The installer has detected running virtual machines. Please shut down all running VirtualBox machines and then restart the installation. (1)
> {code}
> The installer simply states "Failed". It would be nice if the installer could provide more details on why/what failed. Sparing me from having to inspect the logs.
> It simply states "Failed" for VirtualBox, the "Red Hat Container Development Kit" process is waiting for VirtualBox to get installed even though that failed.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (JBDS-4252) Installer waits for failed Virtualbox installation (MacOS)
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBDS-4252?page=com.atlassian.jira.plugin.... ]
Andre Dietisheim edited comment on JBDS-4252 at 1/19/17 4:44 AM:
-----------------------------------------------------------------
[~dgolovin] the problem is not the detection of an existing installation. I had 5.1.x installed, got told by the installer that it was too new and thus, moved the app from /Applications to the trash - I uninstalled it. But, and here's the gotcha, virtualbox was still running. The error message in the log reflects this, it's talking about a running virtualbox. To me it looks like detecting an installation is not enough. A running virtualbox will hinder equally. I'd either have a more expressive error message (it just says "Failed") or even better, detect a running instance beforehand and tell the user to shut it down.
was (Author: adietish):
[~dgolovin] the problem is not the detection of an existing installation. I had 5.1.x installed, got told by the installer that it was too new and thus, moved the app from /Applications to the trash. But, and here's the gotcha, virtualbox was still running. The error message in the log reflects this, it's talking about a running virtualbox. To me it looks like detecting an installation is not enough. A running virtualbox will hinder equally. I'd either have a more expressive error message (it just says "Failed") or even better, detect a running instance beforehand and tell the user to shut it down.
> Installer waits for failed Virtualbox installation (MacOS)
> ----------------------------------------------------------
>
> Key: JBDS-4252
> URL: https://issues.jboss.org/browse/JBDS-4252
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Enhancement
> Components: platform-installer
> Affects Versions: 10.2.0.GA
> Reporter: Andre Dietisheim
> Assignee: Denis Golovin
> Fix For: 10.3.0.AM2
>
> Attachments: waiting-for-virtualbox-install-that-failed.png
>
>
> steps to reproduce:
> # ASSERT: make sure that you have VirtualBox 5.1.x running but the app is removed from the Applications folder
> # EXEC: launch installer, log in and select VirtualBox etc.
> Result:
> Installer fails to install VirtualBox.
> !waiting-for-virtualbox-install-that-failed.png!
> In the logs you see the following:
> {code}
> 0:233: execution error: installer: Error - The installer has detected running virtual machines. Please shut down all running VirtualBox machines and then restart the installation. (1)
> {code}
> The installer simply states "Failed". It would be nice if the installer could provide more details on why/what failed. Sparing me from having to inspect the logs.
> It simply states "Failed" for VirtualBox, the "Red Hat Container Development Kit" process is waiting for VirtualBox to get installed even though that failed.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (JBDS-4252) Installer waits for failed Virtualbox installation (MacOS)
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBDS-4252?page=com.atlassian.jira.plugin.... ]
Andre Dietisheim commented on JBDS-4252:
----------------------------------------
[~dgolovin] the problem is not the detection of an existing installation. I had 5.1.x installed, got told by the installer that it was too new and thus, moved the app from /Applications to the trash. But, and here's the gotcha, virtualbox was still running. The error message in the log reflects this, it's talking about a running virtualbox. To me it looks like detecting an installation is not enough. A running virtualbox will hinder equally. I'd either have a more expressive error message (it just says "Failed") or even better, detect a running instance beforehand and tell the user to shut it down.
> Installer waits for failed Virtualbox installation (MacOS)
> ----------------------------------------------------------
>
> Key: JBDS-4252
> URL: https://issues.jboss.org/browse/JBDS-4252
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Enhancement
> Components: platform-installer
> Affects Versions: 10.2.0.GA
> Reporter: Andre Dietisheim
> Assignee: Denis Golovin
> Fix For: 10.3.0.AM2
>
> Attachments: waiting-for-virtualbox-install-that-failed.png
>
>
> steps to reproduce:
> # ASSERT: make sure that you have VirtualBox 5.1.x running but the app is removed from the Applications folder
> # EXEC: launch installer, log in and select VirtualBox etc.
> Result:
> Installer fails to install VirtualBox.
> !waiting-for-virtualbox-install-that-failed.png!
> In the logs you see the following:
> {code}
> 0:233: execution error: installer: Error - The installer has detected running virtual machines. Please shut down all running VirtualBox machines and then restart the installation. (1)
> {code}
> The installer simply states "Failed". It would be nice if the installer could provide more details on why/what failed. Sparing me from having to inspect the logs.
> It simply states "Failed" for VirtualBox, the "Red Hat Container Development Kit" process is waiting for VirtualBox to get installed even though that failed.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (JBIDE-23768) Publish tagged version of jboss tools parent pom to public repository
by Aurélien Pupier (JIRA)
Aurélien Pupier created JBIDE-23768:
---------------------------------------
Summary: Publish tagged version of jboss tools parent pom to public repository
Key: JBIDE-23768
URL: https://issues.jboss.org/browse/JBIDE-23768
Project: Tools (JBoss Tools)
Issue Type: Task
Components: build
Affects Versions: 4.4.3.AM1, 4.4.2.Final
Reporter: Aurélien Pupier
it will allow Fuse Tooling (and other dependent projects) to have tagged version of their parent pom for tagged release.
i'm talking about org.jboss.tools:parent
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (JBIDE-23766) ZipException in CDICoreBuilder when indexing some Camel artifacts
by Aurélien Pupier (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23766?page=com.atlassian.jira.plugi... ]
Aurélien Pupier commented on JBIDE-23766:
-----------------------------------------
[~jmurphey] Can you check that the VPN is working correctly? (as the company VPN is in transition phase)
For that can you connect using web browser to http://download.eng.bos.redhat.com/brewroot/repos/jb-fis-2.0-maven-build/... and http://download.eng.brq.redhat.com/brewroot/repos/jb-fuse-6.2-build/lates... ?
Can share your settings.xml of your .m2 that you are using?
after that I don't other ideas on what is happening, i was able to reproduce one of your issue but after using the corresponding Switchyard Tooling, verything was working fine for me.
> ZipException in CDICoreBuilder when indexing some Camel artifacts
> -----------------------------------------------------------------
>
> Key: JBIDE-23766
> URL: https://issues.jboss.org/browse/JBIDE-23766
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdi
> Affects Versions: 4.4.2.Final
> Reporter: Aurélien Pupier
> Assignee: Jeff MAURY
> Fix For: 4.4.3.AM2
>
> Attachments: FT_blankBlueprintProj.log, FuseToolingInstalledSW.png, blankBlueprintPomError.png
>
>
> it would be nice to provide more information in log such as teh classes in inspection by CDI Core Builder
> {noformat}
> !ENTRY org.jboss.tools.common.core 4 0 2017-01-17 11:17:20.815
> !MESSAGE invalid LOC header (bad signature)
> !STACK 0
> java.util.zip.ZipException: invalid LOC header (bad signature)
> at java.util.zip.ZipFile.read(Native Method)
> at java.util.zip.ZipFile.access$1400(ZipFile.java:60)
> at java.util.zip.ZipFile$ZipFileInputStream.read(ZipFile.java:717)
> at java.util.zip.ZipFile$ZipFileInflaterInputStream.fill(ZipFile.java:419)
> at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:158)
> at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:286)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
> at java.io.DataInputStream.readFully(DataInputStream.java:195)
> at java.io.DataInputStream.readFully(DataInputStream.java:169)
> at org.jboss.jandex.Indexer.verifyMagic(Indexer.java:433)
> at org.jboss.jandex.Indexer.index(Indexer.java:689)
> at org.jboss.tools.common.core.jandex.JandexUtil.createJarIndex(JandexUtil.java:56)
> at org.jboss.tools.common.core.jandex.JandexUtil.hasAnnotation(JandexUtil.java:104)
> at org.jboss.tools.cdi.internal.core.scanner.lib.BeanArchiveDetector.hasAnnotatedBeans(BeanArchiveDetector.java:276)
> at org.jboss.tools.cdi.internal.core.scanner.lib.BeanArchiveDetector.resolve(BeanArchiveDetector.java:203)
> at org.jboss.tools.cdi.internal.core.scanner.lib.ClassPathMonitor.detectBeanModule(ClassPathMonitor.java:150)
> at org.jboss.tools.cdi.internal.core.scanner.lib.ClassPathMonitor.process(ClassPathMonitor.java:106)
> at org.jboss.tools.cdi.core.CDICoreBuilder.build(CDICoreBuilder.java:215)
> at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:735)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:206)
> at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:246)
> at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:301)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:304)
> at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:360)
> at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:383)
> 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}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (JBIDE-23766) ZipException in CDICoreBuilder when indexing some Camel artifacts
by Jane Murphey (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23766?page=com.atlassian.jira.plugi... ]
Jane Murphey commented on JBIDE-23766:
--------------------------------------
[~aurelien.pupier], [~nickboldt] I downloaded/installed JBDS10.3.0.AM2 and then the integration stack Paul built today from https://devstudio.redhat.com/10.0/staging/updates/integration-stack/. I had to force quit JBDS when it got stuck for 6mins (at 78%) building the workspace for an empty Blueprint Fuse project. I had enabled Fuse Tooling>staging repos before creating the fuse project.
> ZipException in CDICoreBuilder when indexing some Camel artifacts
> -----------------------------------------------------------------
>
> Key: JBIDE-23766
> URL: https://issues.jboss.org/browse/JBIDE-23766
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdi
> Affects Versions: 4.4.2.Final
> Reporter: Aurélien Pupier
> Assignee: Jeff MAURY
> Fix For: 4.4.3.AM2
>
> Attachments: FT_blankBlueprintProj.log, FuseToolingInstalledSW.png, blankBlueprintPomError.png
>
>
> it would be nice to provide more information in log such as teh classes in inspection by CDI Core Builder
> {noformat}
> !ENTRY org.jboss.tools.common.core 4 0 2017-01-17 11:17:20.815
> !MESSAGE invalid LOC header (bad signature)
> !STACK 0
> java.util.zip.ZipException: invalid LOC header (bad signature)
> at java.util.zip.ZipFile.read(Native Method)
> at java.util.zip.ZipFile.access$1400(ZipFile.java:60)
> at java.util.zip.ZipFile$ZipFileInputStream.read(ZipFile.java:717)
> at java.util.zip.ZipFile$ZipFileInflaterInputStream.fill(ZipFile.java:419)
> at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:158)
> at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:286)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
> at java.io.DataInputStream.readFully(DataInputStream.java:195)
> at java.io.DataInputStream.readFully(DataInputStream.java:169)
> at org.jboss.jandex.Indexer.verifyMagic(Indexer.java:433)
> at org.jboss.jandex.Indexer.index(Indexer.java:689)
> at org.jboss.tools.common.core.jandex.JandexUtil.createJarIndex(JandexUtil.java:56)
> at org.jboss.tools.common.core.jandex.JandexUtil.hasAnnotation(JandexUtil.java:104)
> at org.jboss.tools.cdi.internal.core.scanner.lib.BeanArchiveDetector.hasAnnotatedBeans(BeanArchiveDetector.java:276)
> at org.jboss.tools.cdi.internal.core.scanner.lib.BeanArchiveDetector.resolve(BeanArchiveDetector.java:203)
> at org.jboss.tools.cdi.internal.core.scanner.lib.ClassPathMonitor.detectBeanModule(ClassPathMonitor.java:150)
> at org.jboss.tools.cdi.internal.core.scanner.lib.ClassPathMonitor.process(ClassPathMonitor.java:106)
> at org.jboss.tools.cdi.core.CDICoreBuilder.build(CDICoreBuilder.java:215)
> at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:735)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:206)
> at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:246)
> at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:301)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:304)
> at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:360)
> at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:383)
> 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}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (JBIDE-23757) Thread deadlock when starting Eclipse
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23757?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-23757:
--------------------------------
Fix Version/s: 4.4.3.AM2
(was: 4.4.3.Final)
> Thread deadlock when starting Eclipse
> -------------------------------------
>
> Key: JBIDE-23757
> URL: https://issues.jboss.org/browse/JBIDE-23757
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.4.2.Final
> Environment: MacOS Sierra, JDK 1.8.0_112
> Reporter: Jon Kranes
> Assignee: Rob Stryker
> Fix For: 4.4.3.AM2
>
>
> Steps to reproduce:
> * Install latest Eclipse (Neon 4.6.2) (also tested with Spring ToolSuite 3.8.3 with same result)
> * Install JBoss AS, Wildfly & EAP Server Tools from JBoss Tools 4.4.2 Final
> * Add Wildfly 10.x runtime to Eclipse (tested 10.0 and 10.1 with same results)
> * Add Wildfly 10.x server to Eclipse
> * Create a default Maven Web App project
> * Add the web app project to the Wildfly server
> * Exit Eclipse and restart
> Eclipse hangs on startup with a thread deadlock. Eclipse "Progress" window shows "Registering Listeners" which never completes and blocks other Eclipse startup tasks. At this point Eclipse cannot exit and must be force-quit.
> Thread dump output from jvisualvm shows a thread deadlock:
> Found one Java-level deadlock:
> =============================
> "Thread-8":
> waiting to lock monitor 0x000000011fe4e758 (object 0x0000000782b7aa00, a org.eclipse.wst.server.core.internal.Server),
> which is held by "Worker-0"
> "Worker-0":
> waiting to lock monitor 0x0000000101a566e8 (object 0x0000000782b7aa70, a org.jboss.ide.eclipse.as.core.server.UnitedServerListenerManager),
> which is held by "Thread-8"
> Java stack information for the threads listed above:
> ===================================================
> "Thread-8":
> at org.eclipse.wst.server.core.internal.Server.getServerNotificationManager(Server.java:1034)
> - waiting to lock <0x0000000782b7aa00> (a org.eclipse.wst.server.core.internal.Server)
> at org.eclipse.wst.server.core.internal.Server.removeServerListener(Server.java:697)
> at org.jboss.ide.eclipse.as.core.server.UnitedServerListenerManager.protectAddManagerAsListeners(UnitedServerListenerManager.java:152)
> - locked <0x0000000782b7aa70> (a org.jboss.ide.eclipse.as.core.server.UnitedServerListenerManager)
> at org.jboss.ide.eclipse.as.core.server.UnitedServerListenerManager.initializeManager(UnitedServerListenerManager.java:81)
> at org.jboss.ide.eclipse.as.core.server.UnitedServerListenerManager.access$1(UnitedServerListenerManager.java:73)
> at org.jboss.ide.eclipse.as.core.server.UnitedServerListenerManager$1.run(UnitedServerListenerManager.java:68)
> "Worker-0":
> at org.jboss.ide.eclipse.as.core.server.UnitedServerListenerManager.addListener(UnitedServerListenerManager.java:109)
> - waiting to lock <0x0000000782b7aa70> (a org.jboss.ide.eclipse.as.core.server.UnitedServerListenerManager)
> at org.jboss.ide.eclipse.as.core.JBossServerCorePlugin.start(JBossServerCorePlugin.java:74)
> at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:774)
> at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:1)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:767)
> at org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:724)
> at org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:932)
> at org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:309)
> at org.eclipse.osgi.container.Module.doStart(Module.java:581)
> at org.eclipse.osgi.container.Module.start(Module.java:449)
> at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:470)
> at org.eclipse.osgi.internal.hooks.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:107)
> at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClass(ClasspathManager.java:529)
> at org.eclipse.osgi.internal.loader.ModuleClassLoader.findLocalClass(ModuleClassLoader.java:325)
> at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:345)
> at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:423)
> at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:372)
> at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:364)
> at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:161)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at org.eclipse.osgi.internal.framework.EquinoxBundle.loadClass(EquinoxBundle.java:564)
> at org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI.createExecutableExtension(RegistryStrategyOSGI.java:174)
> at org.eclipse.core.internal.registry.ExtensionRegistry.createExecutableExtension(ExtensionRegistry.java:905)
> at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:243)
> at org.eclipse.core.internal.registry.ConfigurationElementHandle.createExecutableExtension(ConfigurationElementHandle.java:55)
> at org.eclipse.wst.server.core.internal.ServerType.createServerDelegate(ServerType.java:91)
> at org.eclipse.wst.server.core.internal.Server.getDelegate(Server.java:506)
> - locked <0x0000000782b7aa00> (a org.eclipse.wst.server.core.internal.Server)
> at org.eclipse.wst.server.core.internal.Server.getChildModules(Server.java:2634)
> at org.eclipse.wst.server.core.internal.Server.visitModule(Server.java:3058)
> at org.eclipse.wst.server.core.internal.Server.visit(Server.java:3039)
> at org.eclipse.wst.server.core.internal.Server.getAllModules(Server.java:1542)
> at org.eclipse.wst.server.ui.internal.cnf.ServersView2$3.run(ServersView2.java:189)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> Found 1 deadlock.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (JBIDE-23757) Thread deadlock when starting Eclipse
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23757?page=com.atlassian.jira.plugi... ]
Rob Stryker resolved JBIDE-23757.
---------------------------------
Resolution: Done
* c045711 - JBIDE-23757 - fix deadlock in UnitedServerManagerListener (again) (65 seconds ago) <Rob Stryker>
My tracing through has shown that this fixes the deadlock. By ensuring that further listeners are added in a job, the start() method doesn't block and completes, allowing the server view to release it's lock on the given servers, which then allows the UnitedServerManagerListener's spawned thread to complete afterwards.
> Thread deadlock when starting Eclipse
> -------------------------------------
>
> Key: JBIDE-23757
> URL: https://issues.jboss.org/browse/JBIDE-23757
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.4.2.Final
> Environment: MacOS Sierra, JDK 1.8.0_112
> Reporter: Jon Kranes
> Assignee: Rob Stryker
> Fix For: 4.4.3.Final
>
>
> Steps to reproduce:
> * Install latest Eclipse (Neon 4.6.2) (also tested with Spring ToolSuite 3.8.3 with same result)
> * Install JBoss AS, Wildfly & EAP Server Tools from JBoss Tools 4.4.2 Final
> * Add Wildfly 10.x runtime to Eclipse (tested 10.0 and 10.1 with same results)
> * Add Wildfly 10.x server to Eclipse
> * Create a default Maven Web App project
> * Add the web app project to the Wildfly server
> * Exit Eclipse and restart
> Eclipse hangs on startup with a thread deadlock. Eclipse "Progress" window shows "Registering Listeners" which never completes and blocks other Eclipse startup tasks. At this point Eclipse cannot exit and must be force-quit.
> Thread dump output from jvisualvm shows a thread deadlock:
> Found one Java-level deadlock:
> =============================
> "Thread-8":
> waiting to lock monitor 0x000000011fe4e758 (object 0x0000000782b7aa00, a org.eclipse.wst.server.core.internal.Server),
> which is held by "Worker-0"
> "Worker-0":
> waiting to lock monitor 0x0000000101a566e8 (object 0x0000000782b7aa70, a org.jboss.ide.eclipse.as.core.server.UnitedServerListenerManager),
> which is held by "Thread-8"
> Java stack information for the threads listed above:
> ===================================================
> "Thread-8":
> at org.eclipse.wst.server.core.internal.Server.getServerNotificationManager(Server.java:1034)
> - waiting to lock <0x0000000782b7aa00> (a org.eclipse.wst.server.core.internal.Server)
> at org.eclipse.wst.server.core.internal.Server.removeServerListener(Server.java:697)
> at org.jboss.ide.eclipse.as.core.server.UnitedServerListenerManager.protectAddManagerAsListeners(UnitedServerListenerManager.java:152)
> - locked <0x0000000782b7aa70> (a org.jboss.ide.eclipse.as.core.server.UnitedServerListenerManager)
> at org.jboss.ide.eclipse.as.core.server.UnitedServerListenerManager.initializeManager(UnitedServerListenerManager.java:81)
> at org.jboss.ide.eclipse.as.core.server.UnitedServerListenerManager.access$1(UnitedServerListenerManager.java:73)
> at org.jboss.ide.eclipse.as.core.server.UnitedServerListenerManager$1.run(UnitedServerListenerManager.java:68)
> "Worker-0":
> at org.jboss.ide.eclipse.as.core.server.UnitedServerListenerManager.addListener(UnitedServerListenerManager.java:109)
> - waiting to lock <0x0000000782b7aa70> (a org.jboss.ide.eclipse.as.core.server.UnitedServerListenerManager)
> at org.jboss.ide.eclipse.as.core.JBossServerCorePlugin.start(JBossServerCorePlugin.java:74)
> at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:774)
> at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:1)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:767)
> at org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:724)
> at org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:932)
> at org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:309)
> at org.eclipse.osgi.container.Module.doStart(Module.java:581)
> at org.eclipse.osgi.container.Module.start(Module.java:449)
> at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:470)
> at org.eclipse.osgi.internal.hooks.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:107)
> at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClass(ClasspathManager.java:529)
> at org.eclipse.osgi.internal.loader.ModuleClassLoader.findLocalClass(ModuleClassLoader.java:325)
> at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:345)
> at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:423)
> at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:372)
> at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:364)
> at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:161)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at org.eclipse.osgi.internal.framework.EquinoxBundle.loadClass(EquinoxBundle.java:564)
> at org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI.createExecutableExtension(RegistryStrategyOSGI.java:174)
> at org.eclipse.core.internal.registry.ExtensionRegistry.createExecutableExtension(ExtensionRegistry.java:905)
> at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:243)
> at org.eclipse.core.internal.registry.ConfigurationElementHandle.createExecutableExtension(ConfigurationElementHandle.java:55)
> at org.eclipse.wst.server.core.internal.ServerType.createServerDelegate(ServerType.java:91)
> at org.eclipse.wst.server.core.internal.Server.getDelegate(Server.java:506)
> - locked <0x0000000782b7aa00> (a org.eclipse.wst.server.core.internal.Server)
> at org.eclipse.wst.server.core.internal.Server.getChildModules(Server.java:2634)
> at org.eclipse.wst.server.core.internal.Server.visitModule(Server.java:3058)
> at org.eclipse.wst.server.core.internal.Server.visit(Server.java:3039)
> at org.eclipse.wst.server.core.internal.Server.getAllModules(Server.java:1542)
> at org.eclipse.wst.server.ui.internal.cnf.ServersView2$3.run(ServersView2.java:189)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> Found 1 deadlock.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months