Thats the server VM which seems in normal condition.

Here is the surefire VM that is hanging:

http://fpaste.org/315840/98783145/


Relevant section is:
  1. "main" #1 prio=5 os_prio=0 tid=0xf6606c00 nid=0x4066 in Object.wait() [0xf6752000]
  2.    java.lang.Thread.State: WAITING (on object monitor)
  3.         at java.lang.Object.wait(Native Method)
  4.         at java.lang.Object.wait(Object.java:502)
  5.         at org.xnio.AbstractIoFuture.await(AbstractIoFuture.java:71)
  6.         - locked <0xe0081818> (a java.lang.Object)
  7.         at org.xnio.AbstractIoFuture.get(AbstractIoFuture.java:167)
  8.         - locked <0xe0081818> (a java.lang.Object)
  9.         at org.jboss.as.protocol.mgmt.FutureManagementChannel.openChannel(FutureManagementChannel.java:154)
  10.         at org.jboss.as.protocol.mgmt.ManagementClientChannelStrategy$Establishing.openChannel(ManagementClientChannelStrategy.java:150)
  11.         at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.connectionOpened(FutureManagementChannel.java:223)
  12.         at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:79)
  13.         - locked <0xe007d870> (a org.jboss.as.protocol.ProtocolConnectionManager)
  14.         at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:212)
  15.         at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:146)
  16.         - locked <0xe005a3d0> (a org.jboss.as.controller.client.impl.RemotingModelControllerClient)
  17.         at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:65)
  18.         at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:147)
  19.         at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:122)
  20.         at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263)
  21.         at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168)
  22.         at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147)
  23.         at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:75)
  24.         at org.jboss.as.test.shared.ServerReload.waitForLiveServerToReload(ServerReload.java:104)
  25.         at org.jboss.as.test.shared.ServerReload.executeReloadAndWaitForCompletion(ServerReload.java:72)
  26.         at org.jboss.as.test.shared.ServerReload.executeReloadAndWaitForCompletion(ServerReload.java:59)
  27.         at org.jboss.as.test.integration.management.jca.DsMgmtTestBase.reload(DsMgmtTestBase.java:56)
  28.         at org.jboss.as.test.integration.jca.datasource.DatasourceXaEnableAttributeTestCase.createDataSource(DatasourceXaEnableAttributeTestCase.java:59)
  29.         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@gmail.com> wrote:

it just hanged again,
this is the thread dump http://fpaste.org/315834/53998306/raw/

On Thu, Jan 28, 2016 at 2:12 PM, Jason T. Greene <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@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@gmail.com>:

On Thu, Jan 28, 2016 at 9:58 AM, Carlo de Wolf <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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev



--
__________________________
Eduardo Sant'Ana da Silva - Dr.
Pesquisador / Consultor de TI

_______________________________________________
wildfly-dev mailing list
wildfly-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev


--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat