2 Replies Latest reply on Jun 14, 2018 8:31 AM by Petr H

    JBoss EAP 7.1 does not stop when using shared sessions

    Thomas Delhoménie Newbie

      Hello,

       

      I have an application deployed in JBoss EAP as an EAR. With JBoss EAP 7.0, when I deploy the application, I can stop it correctly using jboss cli, but when I deploy it in JBoss EAP 7.1, it hangs forever and never stops.

      It hangs on:

       

      "ServerService Thread Pool -- 79" #713 prio=5 os_prio=0 tid=0x000000000a7d9000 nid=0x17a3 waiting on condition [0x00007fc95257f000]
        java.lang.Thread.State: WAITING (parking)
      at sun.misc.Unsafe.park(Native Method)
      - parking to wait for  <0x000000009049a0c8> (a java.util.concurrent.locks.StampedLock)
      at java.util.concurrent.locks.StampedLock.acquireWrite(StampedLock.java:1119)
      at java.util.concurrent.locks.StampedLock.writeLockInterruptibly(StampedLock.java:413)
      at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.stop(DistributableSessionManager.java:90)
      - locked <0x00000000904994c8> (a org.wildfly.clustering.web.undertow.session.DistributableSessionManager)
      at io.undertow.servlet.core.DeploymentManagerImpl$3.call(DeploymentManagerImpl.java:599)
      at io.undertow.servlet.core.DeploymentManagerImpl$3.call(DeploymentManagerImpl.java:589)
      at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
      at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
      at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
      at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction$$Lambda$941/1901720026.call(Unknown Source)
      at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
      at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$942/738435965.call(Unknown Source)
      at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
      at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$942/738435965.call(Unknown Source)
      at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
      at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$942/738435965.call(Unknown Source)
      at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
      at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$942/738435965.call(Unknown Source)
      at io.undertow.servlet.core.DeploymentManagerImpl.stop(DeploymentManagerImpl.java:603)
      at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stopContext(UndertowDeploymentService.java:139)
      at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$2.run(UndertowDeploymentService.java:120)
      at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
      at java.util.concurrent.FutureTask.run(FutureTask.java:266)
      at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
      at java.lang.Thread.run(Thread.java:745)
      at org.jboss.threads.JBossThread.run(JBossThread.java:320)
      

       

      The application made of several wars (in an EAR), and I activated the sessions sharing in jboss-all.xml :

       

      <?xml version="1.0"?>
      <jboss umlns="urn:jboss:1.0">
          <shared-session-config xmlns="urn:jboss:shared-session-config:1.0">
              <session-config>
                  <cookie-config>
                      <path>/</path>
                  </cookie-config>
              </session-config>
          </shared-session-config>
          <weld xmlns="urn:jboss:weld:1.0" require-bean-descriptor="true"/>
      </jboss>
      

       

      That's the reason why JBoss uses the session manager DistributableSessionManager instead of the default one.

      I found a workaround by disabling the module org.wildfly.clustering.web.undertow in the definition of the module org.wildfly.extension.undertow (modules/system/layers/base/org/wildfly/extension/undertow/main/module.xml), but I am not sure of all the possible impacts, and I would like to solve this issue without changing jboss modules definition.

       

      Any idea ? Should I open an issue ?

      Thanks