Thats the server VM which seems in normal condition.
Here is the surefire VM that is hanging:
Relevant section is:
"main" #1 prio=5 os_prio=0 tid=0xf6606c00 nid=0x4066 in Object.wait()
[0xf6752000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:502)
at org.xnio.AbstractIoFuture.await(AbstractIoFuture.java:71)
- locked <0xe0081818> (a java.lang.Object)
at org.xnio.AbstractIoFuture.get(AbstractIoFuture.java:167)
- locked <0xe0081818> (a java.lang.Object)
at
org.jboss.as.protocol.mgmt.FutureManagementChannel.openChannel(FutureManagementChannel.java:154)
at
org.jboss.as.protocol.mgmt.ManagementClientChannelStrategy$Establishing.openChannel(ManagementClientChannelStrategy.java:150)
at
org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.connectionOpened(FutureManagementChannel.java:223)
at
org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:79)
- locked <0xe007d870> (a org.jboss.as.protocol.ProtocolConnectionManager)
at
org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:212)
at
org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:146)
- locked <0xe005a3d0> (a
org.jboss.as.controller.client.impl.RemotingModelControllerClient)
at
org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:65)
at
org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:147)
at
org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:122)
at
org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263)
at
org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168)
at
org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147)
at
org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:75)
at
org.jboss.as.test.shared.ServerReload.waitForLiveServerToReload(ServerReload.java:104)
at
org.jboss.as.test.shared.ServerReload.executeReloadAndWaitForCompletion(ServerReload.java:72)
at
org.jboss.as.test.shared.ServerReload.executeReloadAndWaitForCompletion(ServerReload.java:59)
at
org.jboss.as.test.integration.management.jca.DsMgmtTestBase.reload(DsMgmtTestBase.java:56)
at
org.jboss.as.test.integration.jca.datasource.DatasourceXaEnableAttributeTestCase.createDataSource(DatasourceXaEnableAttributeTestCase.java:59)
at
org.jboss.as.test.integration.jca.datasource.DatasourceEnableAttributeTestBase.enableLater(DatasourceEnableAttributeTestBase.java:79)
On Jan 28, 2016, at 10:26 AM, Tomaž Cerar
<tomaz.cerar(a)gmail.com> wrote:
it just hanged again,
this is the thread dump
http://fpaste.org/315834/53998306/raw/
<
http://fpaste.org/315834/53998306/raw/>
On Thu, Jan 28, 2016 at 2:12 PM, Jason T. Greene <jason.greene(a)redhat.com
<mailto:jason.greene@redhat.com>> wrote:
It happens when a test hangs. So we have to get stack traces of the process when this
occurs to even know where to being to look.
On Jan 28, 2016, at 6:38 AM, Eduardo Sant´Ana da Silva
<eduardo.santanadasilva(a)gmail.com <mailto:eduardo.santanadasilva@gmail.com>>
wrote:
> I faced a similar problem recently.
> About this issue, my doubt is that if there is no nexus repository operation, and the
build is done sequentially, first core (installing locally), after that the wildfly entire
build, how this timeout is occurring?
>
> Seems that this could be a common problem if the maven is executing in parallel and
those intermittent problems can occur due synchronization issues.
>
> To resolve my problem I first resolve the dependencies recently installed on local
repository through: mvn dependency:build-classpath
>
> ---
> eduardo
>
> 2016-01-28 9:54 GMT-02:00 Tomaž Cerar <tomaz.cerar(a)gmail.com
<mailto:tomaz.cerar@gmail.com>>:
>
> On Thu, Jan 28, 2016 at 9:58 AM, Carlo de Wolf <cdewolf(a)redhat.com
<mailto:cdewolf@redhat.com>> wrote:
> There should be no SNAPSHOT dependencies in any CI build. While it does build core
beforehand, it might get overwritten by another CI run.
> [org.wildfly.core:wildfly-core-parent] [INFO] Installing
/opt/buildAgent/work/db872761b443af46/core/pom.xml to
/store/repository/org/wildfly/core/wildfly-core-parent/2.0.8.Final-SNAPSHOT/wildfly-core-parent-2.0.8.Final-SNAPSHOT.pom
>
> Would it be possible to use timed snapshots instead?
>
>
> As Stuart said, whole point of this builds is to have snapshot builds.
> Same build agent first builds core (clean install) and than builds full
> with -Dversion.wildfly.core=<version of wildfly core previousily built>
>
> snapshot used here are only build agent local, not publish on some outside nexus
repository.
>
> --
> tomaz
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
<
https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>
>
>
> --
> __________________________
> Eduardo Sant'Ana da Silva - Dr.
> Pesquisador / Consultor de TI
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
<
https://lists.jboss.org/mailman/listinfo/wildfly-dev>
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat