0 Replies Latest reply on Jul 6, 2016 6:40 PM by rhanus

ear deployment is getting suck for quite a long time when using richfaces as module

rhanus Jul 6, 2016 6:40 PM

Hi,

I have an ear deployment with 3 web applications inside each uses richfaces 4.5.x

for some reasons richfaces libraries are configured as wildfly module, here Peter Falken manages them for us

when I deploy the ear on wildfly-10.0.0.Final (with richfaces module deployed under $JBOSS_HOME/modules/system/layers/base/) I observe huge time gap during its deployment:

00:38:20,818 INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) WFLYSRV0027: Starting deployment of "app.ear" (runtime-name: "app.ear")

00:38:20,876 INFO [org.jboss.as.server.deployment] (MSC service thread 1-7) WFLYSRV0207: Starting subdeployment (runtime-name: "app2.war")

00:38:20,876 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0207: Starting subdeployment (runtime-name: "app1.war")

00:38:20,876 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) WFLYSRV0207: Starting subdeployment (runtime-name: "app3.war")

00:38:21,214 INFO [org.jboss.weld.deployer] (MSC service thread 1-8) WFLYWELD0003: Processing weld deployment app.ear

00:38:21,266 INFO [org.hibernate.validator.internal.util.Version] (MSC service thread 1-8) HV000001: Hibernate Validator 5.2.3.Final

00:38:21,361 INFO [org.jboss.weld.deployer] (MSC service thread 1-8) WFLYWELD0003: Processing weld deployment app3.war

00:38:21,361 INFO [org.jboss.weld.deployer] (MSC service thread 1-1) WFLYWELD0003: Processing weld deployment app2.war

00:38:21,363 INFO [org.jboss.weld.deployer] (MSC service thread 1-3) WFLYWELD0003: Processing weld deployment app1.war

00:38:32,978 INFO [org.jboss.weld.deployer] (MSC service thread 1-5) WFLYWELD0006: Starting Services for CDI deployment: app.ear

00:38:33,004 INFO [org.jboss.weld.Version] (MSC service thread 1-5) WELD-000900: 2.3.2 (Final)

00:38:33,016 INFO [org.jboss.weld.deployer] (MSC service thread 1-1) WFLYWELD0009: Starting weld service for deployment app.ear

00:38:33,743 INFO [io.undertow.servlet] (ServerService Thread Pool -- 6) Initializing AtmosphereFramework

I cannot figure out why, TRACE logging of org.jboss category doesn't help much, the only interesting clue I have tracked is thread dump when the server is sucked:

all "ServerService Thread Pool" and "MSC service thread" are WAITING except of following:

"MSC service thread 1-7" #21 prio=5 os_prio=0 tid=0x00007f1334001800 nid=0x2848 waiting for monitor entry [0x00007f135a95c000]

java.lang.Thread.State: BLOCKED (on object monitor)

at java.util.zip.ZipFile$ZipEntryIterator.hasNext(ZipFile.java:492)

- waiting to lock <0x00000000d7801378> (a java.util.jar.JarFile)

at java.util.zip.ZipFile$ZipEntryIterator.hasMoreElements(ZipFile.java:488)

at java.util.jar.JarFile$JarEntryIterator.hasNext(JarFile.java:253)

at java.util.jar.JarFile$JarEntryIterator.hasMoreElements(JarFile.java:262)

at org.jboss.modules.JarFileResourceLoader$1.hasNext(JarFileResourceLoader.java:262)

at org.jboss.modules.ModuleClassLoader$2.hasNext(ModuleClassLoader.java:689)

at org.jboss.modules.Module$4.hasNext(Module.java:772)

at org.jboss.modules.filter.PathFilters$1.hasNext(PathFilters.java:223)

at org.wildfly.extension.undertow.deployment.ExternalTldParsingDeploymentProcessor.deploy(ExternalTldParsingDeploymentProcessor.java:84)

at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)

- locked <0x00000000d781f4f0> (a org.jboss.as.server.deployment.DeploymentUnitPhaseService)

at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)

at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)

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)

"MSC service thread 1-3" #17 prio=5 os_prio=0 tid=0x00007f13bc891000 nid=0x2844 runnable [0x00007f135ad60000]

java.lang.Thread.State: RUNNABLE

at java.util.zip.ZipFile.getNextEntry(Native Method)

at java.util.zip.ZipFile.access$500(ZipFile.java:60)

at java.util.zip.ZipFile$ZipEntryIterator.next(ZipFile.java:508)

- locked <0x00000000d7801378> (a java.util.jar.JarFile)

at java.util.zip.ZipFile$ZipEntryIterator.nextElement(ZipFile.java:499)

at java.util.zip.ZipFile$ZipEntryIterator.nextElement(ZipFile.java:480)

at java.util.jar.JarFile$JarEntryIterator.next(JarFile.java:257)

at java.util.jar.JarFile$JarEntryIterator.nextElement(JarFile.java:266)

at java.util.jar.JarFile$JarEntryIterator.nextElement(JarFile.java:247)

at org.jboss.modules.JarFileResourceLoader$1.hasNext(JarFileResourceLoader.java:265)