[
https://issues.jboss.org/browse/WFCORE-2235?page=com.atlassian.jira.plugi...
]
Brian Stansberry reassigned WFCORE-2235:
----------------------------------------
Assignee: Richard Opalka
[~ropalka] I'm assigning this to you since per our chats you've got this fixed in
MSC and an MSC upgrade will take care of it.
When the upgrade comes in
https://github.com/wildfly/wildfly-core/pull/2871 should be
reverted. That PR was an alternative to putting @Ignore on the test, one that should make
the failures with the current code rare without completely losing coverage.
Intermittent module loading failure in
InterdependentDeploymentTestCase
-----------------------------------------------------------------------
Key: WFCORE-2235
URL:
https://issues.jboss.org/browse/WFCORE-2235
Project: WildFly Core
Issue Type: Bug
Components: Modules, Server
Affects Versions: 3.0.0.Alpha22
Reporter: Brian Stansberry
Assignee: Richard Opalka
Attachments: WFCORE-2235svcdump.txt
InterdependentDeploymentTestCase tests deployment handling of a set of interdependent
deployments, where some of the dependencies are optional.
The test intermittently fails due to a ModuleLoadException while deploying one of the
modules:
https://ci.wildfly.org/viewLog.html?buildId=42957&buildTypeId=WildFly...
The most notable bit of info in the log is:
{code}
17:32:08,639 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001:
Failed to start service
jboss.module.service."deployment.interrelated-c.jar".main:
org.jboss.msc.service.StartException in service
jboss.module.service."deployment.interrelated-c.jar".main: WFLYSRV0179: Failed
to load module: deployment.interrelated-c.jar
at
org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:91)
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
at org.jboss.msc.service.MSCExecutor$1.run(MSCExecutor.java:77)
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)
Caused by: org.jboss.modules.ModuleNotFoundException: deployment.interrelated-c.jar
at org.jboss.modules.ModuleLoader$FutureModule.getModule(ModuleLoader.java:834)
at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:472)
at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:457)
at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:370)
at
org.jboss.as.server.moduleservice.ServiceModuleLoader.preloadModule(ServiceModuleLoader.java:147)
at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:387)
at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:282)
at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:270)
at
org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:68)
... 6 more
{code}
The interrelated-c.jar deployment depends (*not optionally*) on interrelated-a.jar.The
failure occurs during execution of a management op that redeploys interrelated-a.jar.
FWIW, another deployment in the set, interrelated-f.jar, does depend optionally on
interrelated-c.jar.
The full stdout output for the failed test in the above linked CI run also includes a
dump of all MSC services following the failure. Note though that the failure does not
result in MSC not obtaining stability. Inability to reach stability was the initial
problem that led to the introduction of this test (see
https://github.com/wildfly/wildfly-core/pull/2099.)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)