[JBoss JIRA] (DROOLS-2352) Executable model test coverage: run the optaplanner turtleTests with the executable model turned on and see if it survives the ordeal
by Geoffrey De Smet (JIRA)
Geoffrey De Smet created DROOLS-2352:
----------------------------------------
Summary: Executable model test coverage: run the optaplanner turtleTests with the executable model turned on and see if it survives the ordeal
Key: DROOLS-2352
URL: https://issues.jboss.org/browse/DROOLS-2352
Project: Drools
Issue Type: Task
Components: core engine
Reporter: Geoffrey De Smet
Assignee: Mario Fusco
For now, we're looking for a one time test. Later I presume the exe model will be come the default, so these tests would just run?
To run the optaplanner turtle tests, run all tests in optaplanner-examples with the VM parameter `-DrunTurtleTests=true`. They take 48 hours to run. You can also just run one, for example NurseRosteringSolveAllTurtleTest, but don't forget that VM parameter.
Mario Fusco says you can do this to turn on the executable model:
{code}
kieBuilder.buildAll( ExecutableModelProject.class );
{code}
I presume you 'd need to hack that in `ScoreDirectorFactoryConfig.buildDroolsScoreDirectorFactory()`.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 3 months
[JBoss JIRA] (WFLY-9920) XAException/HeuristicRollbackException and others due to TimeoutException: Timed out waiting for topology
by Michal Vinkler (JIRA)
Michal Vinkler created WFLY-9920:
------------------------------------
Summary: XAException/HeuristicRollbackException and others due to TimeoutException: Timed out waiting for topology
Key: WFLY-9920
URL: https://issues.jboss.org/browse/WFLY-9920
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 12.0.0.Beta1
Reporter: Michal Vinkler
Assignee: Paul Ferraro
Priority: Critical
Seen in many failover tests:
failover-http-session-jvmkill-repl-sync
failover-http-session-shutdown-dist-sync
failover-http-session-shutdown-repl-sync
failover-http-granular-jvmkill-dist-sync
failover-http-granular-shutdown-repl-sync
failover-ejb-ejbservlet-jvmkill-dist-sync
failover-ejb-ejbservlet-undeploy-dist-sync
During our failover testing, we have seen many occurrences of "TimeoutException: Timed out waiting for topology X".
Here are the variants we have identified:
{code:title=ISPN000136: Error executing command PrepareCommand}
[JBossINF] [0m[31m06:14:11,769 ERROR [org.infinispan.interceptors.impl.InvocationContextInterceptor] (timeout-thread--p9-t1) ISPN000136: Error executing command PrepareCommand, writing keys [SessionAttributesKey(u8mzm-09YKM6zLEb7aaTZapiXz3-y4i8OOMegJRL), SessionCreationMetaDataKey(u8mzm-09YKM6zLEb7aaTZapiXz3-y4i8OOMegJRL), SessionAccessMetaDataKey(u8mzm-09YKM6zLEb7aaTZapiXz3-y4i8OOMegJRL)]: org.infinispan.util.concurrent.TimeoutException: Timed out waiting for topology 29
[JBossINF] at org.infinispan.interceptors.impl.BaseStateTransferInterceptor$CancellableRetry.run(BaseStateTransferInterceptor.java:337)
[JBossINF] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
[JBossINF] at java.util.concurrent.FutureTask.run(FutureTask.java:266)
[JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
[JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
[JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[JBossINF] at java.lang.Thread.run(Thread.java:748)
{code}
link: http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/perflab_eap-7x-fa...
{code:title=ISPN000097: Error while processing a prepare in a single-phase transaction}
[JBossINF] [0m[31m06:14:11,773 ERROR [org.infinispan.transaction.impl.TransactionCoordinator] (default task-65) ISPN000097: Error while processing a prepare in a single-phase transaction: org.infinispan.util.concurrent.TimeoutException: Timed out waiting for topology 29
[JBossINF] at org.infinispan.interceptors.impl.AsyncInterceptorChainImpl.invoke(AsyncInterceptorChainImpl.java:259)
[JBossINF] at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:137)
[JBossINF] at org.infinispan.transaction.impl.TransactionCoordinator.commit(TransactionCoordinator.java:166)
[JBossINF] at org.infinispan.transaction.xa.XaTransactionTable.commit(XaTransactionTable.java:126)
[JBossINF] at org.infinispan.transaction.xa.TransactionXaAdapter.commit(TransactionXaAdapter.java:68)
[JBossINF] at org.infinispan.commons.tx.TransactionImpl.finishResource(TransactionImpl.java:446)
[JBossINF] at org.infinispan.commons.tx.TransactionImpl.commitResources(TransactionImpl.java:493)
[JBossINF] at org.infinispan.commons.tx.TransactionImpl.runCommit(TransactionImpl.java:335)
[JBossINF] at org.infinispan.commons.tx.TransactionImpl.commit(TransactionImpl.java:110)
[JBossINF] at org.wildfly.clustering.ee.infinispan.InfinispanBatch.close(InfinispanBatch.java:97)
[JBossINF] at org.wildfly.clustering.web.undertow.session.DistributableSession.requestDone(DistributableSession.java:91)
[JBossINF] at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:945)
[JBossINF] at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:577)
[JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:339)
[JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
[JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
[JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
[JBossINF] at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
[JBossINF] at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
[JBossINF] at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
[JBossINF] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
[JBossINF] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
[JBossINF] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
[JBossINF] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
[JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
[JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
[JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
[JBossINF] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
[JBossINF] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
[JBossINF] at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1979)
[JBossINF] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1481)
[JBossINF] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1360)
[JBossINF] at java.lang.Thread.run(Thread.java:748)
[JBossINF] Caused by: org.infinispan.util.concurrent.TimeoutException: Timed out waiting for topology 29
[JBossINF] at org.infinispan.interceptors.impl.BaseStateTransferInterceptor$CancellableRetry.run(BaseStateTransferInterceptor.java:337)
[JBossINF] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
[JBossINF] at java.util.concurrent.FutureTask.run(FutureTask.java:266)
[JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
[JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
[JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[JBossINF] ... 1 more
{code}
link: http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/perflab_eap-7x-fa...
{code:title=ISPN000927: exception while committing: javax.transaction.xa.XAException}
[JBossINF] [0m[33m06:14:11,780 WARN [org.infinispan.commons.tx.TransactionImpl] (default task-65) ISPN000927: exception while committing: javax.transaction.xa.XAException
[JBossINF] at org.infinispan.transaction.impl.TransactionCoordinator.handleCommitFailure(TransactionCoordinator.java:222)
[JBossINF] at org.infinispan.transaction.impl.TransactionCoordinator.commit(TransactionCoordinator.java:168)
[JBossINF] at org.infinispan.transaction.xa.XaTransactionTable.commit(XaTransactionTable.java:126)
[JBossINF] at org.infinispan.transaction.xa.TransactionXaAdapter.commit(TransactionXaAdapter.java:68)
[JBossINF] at org.infinispan.commons.tx.TransactionImpl.finishResource(TransactionImpl.java:446)
[JBossINF] at org.infinispan.commons.tx.TransactionImpl.commitResources(TransactionImpl.java:493)
[JBossINF] at org.infinispan.commons.tx.TransactionImpl.runCommit(TransactionImpl.java:335)
[JBossINF] at org.infinispan.commons.tx.TransactionImpl.commit(TransactionImpl.java:110)
[JBossINF] at org.wildfly.clustering.ee.infinispan.InfinispanBatch.close(InfinispanBatch.java:97)
[JBossINF] at org.wildfly.clustering.web.undertow.session.DistributableSession.requestDone(DistributableSession.java:91)
[JBossINF] at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:945)
[JBossINF] at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:577)
[JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:339)
[JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
[JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
[JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
[JBossINF] at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
[JBossINF] at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
[JBossINF] at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
[JBossINF] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
[JBossINF] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
[JBossINF] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
[JBossINF] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
[JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
[JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
[JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
[JBossINF] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
[JBossINF] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
[JBossINF] at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1979)
[JBossINF] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1481)
[JBossINF] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1360)
[JBossINF] at java.lang.Thread.run(Thread.java:748)
[JBossINF] Caused by: org.infinispan.util.concurrent.TimeoutException: Timed out waiting for topology 29
[JBossINF] at org.infinispan.interceptors.impl.AsyncInterceptorChainImpl.invoke(AsyncInterceptorChainImpl.java:259)
[JBossINF] at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:137)
[JBossINF] at org.infinispan.transaction.impl.TransactionCoordinator.commit(TransactionCoordinator.java:166)
[JBossINF] ... 30 more
[JBossINF] Caused by: org.infinispan.util.concurrent.TimeoutException: Timed out waiting for topology 29
[JBossINF] at org.infinispan.interceptors.impl.BaseStateTransferInterceptor$CancellableRetry.run(BaseStateTransferInterceptor.java:337)
[JBossINF] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
[JBossINF] at java.util.concurrent.FutureTask.run(FutureTask.java:266)
[JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
[JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
[JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[JBossINF] ... 1 more
{code}
link: http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/perflab_eap-7x-fa...
{code:title=UT005023: ... HeuristicRollbackException}
[JBossINF] [0m[31m08:57:51,979 ERROR [io.undertow.request] (default task-56) UT005023: Exception handling request to /clusterbench-granular/granular: org.infinispan.commons.CacheException: javax.transaction.HeuristicRollbackException
[JBossINF] at org.wildfly.clustering.ee.infinispan.InfinispanBatch.close(InfinispanBatch.java:102)
[JBossINF] at org.wildfly.clustering.server.registry.CacheRegistry.getEntry(CacheRegistry.java:174)
[JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanRouteLocator.locate(InfinispanRouteLocator.java:57)
[JBossINF] at org.wildfly.clustering.web.undertow.session.DistributableSessionIdentifierCodec.encode(DistributableSessionIdentifierCodec.java:48)
[JBossINF] at org.wildfly.extension.undertow.session.CodecSessionConfig.findSessionId(CodecSessionConfig.java:60)
[JBossINF] at io.undertow.servlet.spec.ServletContextImpl$ServletContextSessionConfig.findSessionId(ServletContextImpl.java:1215)
[JBossINF] at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:158)
[JBossINF] at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:858)
[JBossINF] at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:933)
[JBossINF] at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:69)
[JBossINF] at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
[JBossINF] at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
[JBossINF] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
[JBossINF] at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
[JBossINF] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
[JBossINF] at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
[JBossINF] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
[JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
[JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
[JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
[JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
[JBossINF] at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
[JBossINF] at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
[JBossINF] at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
[JBossINF] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
[JBossINF] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
[JBossINF] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
[JBossINF] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
[JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
[JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
[JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
[JBossINF] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
[JBossINF] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
[JBossINF] at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1979)
[JBossINF] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1481)
[JBossINF] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1360)
[JBossINF] at java.lang.Thread.run(Thread.java:748)
[JBossINF] Caused by: javax.transaction.HeuristicRollbackException
[JBossINF] at org.infinispan.commons.tx.TransactionImpl.finishResource(TransactionImpl.java:478)
[JBossINF] at org.infinispan.commons.tx.TransactionImpl.commitResources(TransactionImpl.java:493)
[JBossINF] at org.infinispan.commons.tx.TransactionImpl.runCommit(TransactionImpl.java:335)
[JBossINF] at org.infinispan.commons.tx.TransactionImpl.commit(TransactionImpl.java:110)
[JBossINF] at org.wildfly.clustering.ee.infinispan.InfinispanBatch.close(InfinispanBatch.java:97)
[JBossINF] ... 36 more
[JBossINF] Caused by: javax.transaction.xa.XAException
[JBossINF] at org.infinispan.transaction.impl.TransactionCoordinator.handleCommitFailure(TransactionCoordinator.java:222)
[JBossINF] at org.infinispan.transaction.impl.TransactionCoordinator.commit(TransactionCoordinator.java:168)
[JBossINF] at org.infinispan.transaction.xa.XaTransactionTable.commit(XaTransactionTable.java:126)
[JBossINF] at org.infinispan.transaction.xa.TransactionXaAdapter.commit(TransactionXaAdapter.java:68)
[JBossINF] at org.infinispan.commons.tx.TransactionImpl.finishResource(TransactionImpl.java:446)
[JBossINF] ... 40 more
[JBossINF] Caused by: org.infinispan.util.concurrent.TimeoutException: Timed out waiting for topology 21
[JBossINF] at org.infinispan.interceptors.impl.AsyncInterceptorChainImpl.invoke(AsyncInterceptorChainImpl.java:259)
[JBossINF] at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:137)
[JBossINF] at org.infinispan.transaction.impl.TransactionCoordinator.commit(TransactionCoordinator.java:166)
[JBossINF] ... 43 more
[JBossINF] Caused by: org.infinispan.util.concurrent.TimeoutException: Timed out waiting for topology 21
[JBossINF] at org.infinispan.interceptors.impl.BaseStateTransferInterceptor$CancellableRetry.run(BaseStateTransferInterceptor.java:337)
[JBossINF] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
[JBossINF] at java.util.concurrent.FutureTask.run(FutureTask.java:266)
[JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
[JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
[JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[JBossINF] ... 1 more
{code}
link: http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/perflab_eap-7x-fa...
The client is affected, getting 500 as a response:
{code}
2018/02/16 08:57:51:748 EST [WARN ][Runner - 1950] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Invalid response code: 500 Content: <html><head><title>Error</title></head><body>Internal Server Error</body></html>>
org.jboss.smartfrog.loaddriver.RequestProcessingException: Invalid response code: 500 Content: <html><head><title>Error</title></head><body>Internal Server Error</body></html>
at org.jboss.smartfrog.loaddriver.http.HttpRequestProcessorFactoryImpl$HttpRequestProcessor.processRequest(HttpRequestProcessorFactoryImpl.java:164)
at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:52)
at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:103)
at java.lang.Thread.run(Thread.java:748)
{code}
link: http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/perflab_eap-7x-fa...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 3 months
[JBoss JIRA] (WFLY-9913) Balancer fails to balance requests according to load provided by custom load metric
by Jan Kašík (JIRA)
[ https://issues.jboss.org/browse/WFLY-9913?page=com.atlassian.jira.plugin.... ]
Jan Kašík updated WFLY-9913:
----------------------------
Description:
When balancer uses load provided by custom load metric, it intermittently fails to redirect requests to expected workers. We use following scenario in our test with EAP 7.1.1 nodes:
# Prepare one balancer and three workers with custom load metric which has these attribute values:
{{history: 0, decay: 0, capacity: 1000}} and uses implementation from \[1\].
# The implementation takes dummy load values from files in local filesystem. So the values in files are set then.
# The verification, that expected load factor is loaded is made by running {{"/subsystem=undertow/configuration=filter/mod-cluster=modcluster:read-resource(include-runtime=true, recursive=true, recursive-depth=100)}}.
# 1000+ requests is made on balancer and for each request, the JVM route of handling node is noted.
# It is verified, that expected amount of request went to each node according to load factor.
# Load values in files are changes and verification, that they were loaded is made again.
# 1000+ requests is made on balancer and for each request, the JVM route of handling node is noted.
# After the requests were made, the verification, that all went according to expectations is made. In this step, the verification sometimes fails, because there were unexpected count of requests on each node.
This occurs only on EAP/Wildlfly balancer and we suspect, that this is an error in Undertow mod_cluster implementation. The problem is, that sometimes more requests than expected ends up on the worker with lowest load:
{{java.lang.AssertionError: Assert #5, Request distribution according to the load was supposed to be [jboss-eap-7.2-1:106, jboss-eap-7.2-2:106, jboss-eap-7.2-3:789] with tolerance +/-10, but was: [jboss-eap-7.2-1:36, jboss-eap-7.2-2:35, jboss-eap-7.2-3:930]}}
[1]: https://github.com/Karm/mod_cluster-custom-load-metric
was:
When balancer uses load provided by custom load metric, it intermittently fails to redirect requests to expected workers. We use following scenario in our test with EAP 7.1.1 nodes:
# Prepare one balancer and three workers with custom load metric which has these attribute values:
{{history: 0, decay: 0, capacity: 1000}} and uses implementation from \[1\].
# The implementation takes dummy load values from files in local filesystem. So the values in files are set then.
# The verification, that expected load factor is loaded is made by running {{"/subsystem=undertow/configuration=filter/mod-cluster=modcluster:read-resource(include-runtime=true, recursive=true, recursive-depth=100)}}.
# 1000+ requests is made on balancer and for each request, the JVM route of handling node is noted.
# It is verified, that expected amount of request went to each node according to load factor.
# Load values in files are changes and verification, that they were loaded is made again.
# 1000+ requests is made on balancer and for each request, the JVM route of handling node is noted.
# After the requests were made, the verification, that all went according to expectations is made. In this step, the verification sometimes fails, because there were unexpected count of requests on each node.
[1]: https://github.com/Karm/mod_cluster-custom-load-metric
> Balancer fails to balance requests according to load provided by custom load metric
> -----------------------------------------------------------------------------------
>
> Key: WFLY-9913
> URL: https://issues.jboss.org/browse/WFLY-9913
> Project: WildFly
> Issue Type: Bug
> Components: mod_cluster, Web (Undertow)
> Affects Versions: 12.0.0.Beta1
> Reporter: Jan Kašík
> Assignee: Radoslav Husar
>
> When balancer uses load provided by custom load metric, it intermittently fails to redirect requests to expected workers. We use following scenario in our test with EAP 7.1.1 nodes:
> # Prepare one balancer and three workers with custom load metric which has these attribute values:
> {{history: 0, decay: 0, capacity: 1000}} and uses implementation from \[1\].
> # The implementation takes dummy load values from files in local filesystem. So the values in files are set then.
> # The verification, that expected load factor is loaded is made by running {{"/subsystem=undertow/configuration=filter/mod-cluster=modcluster:read-resource(include-runtime=true, recursive=true, recursive-depth=100)}}.
> # 1000+ requests is made on balancer and for each request, the JVM route of handling node is noted.
> # It is verified, that expected amount of request went to each node according to load factor.
> # Load values in files are changes and verification, that they were loaded is made again.
> # 1000+ requests is made on balancer and for each request, the JVM route of handling node is noted.
> # After the requests were made, the verification, that all went according to expectations is made. In this step, the verification sometimes fails, because there were unexpected count of requests on each node.
> This occurs only on EAP/Wildlfly balancer and we suspect, that this is an error in Undertow mod_cluster implementation. The problem is, that sometimes more requests than expected ends up on the worker with lowest load:
> {{java.lang.AssertionError: Assert #5, Request distribution according to the load was supposed to be [jboss-eap-7.2-1:106, jboss-eap-7.2-2:106, jboss-eap-7.2-3:789] with tolerance +/-10, but was: [jboss-eap-7.2-1:36, jboss-eap-7.2-2:35, jboss-eap-7.2-3:930]}}
> [1]: https://github.com/Karm/mod_cluster-custom-load-metric
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 3 months
[JBoss JIRA] (WFLY-9919) Deployment throwing exception on upgrade to JBOSS EAP 7.1
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/WFLY-9919?page=com.atlassian.jira.plugin.... ]
jaikiran pai updated WFLY-9919:
-------------------------------
Affects Version/s: 11.0.0.Final
> Deployment throwing exception on upgrade to JBOSS EAP 7.1
> ---------------------------------------------------------
>
> Key: WFLY-9919
> URL: https://issues.jboss.org/browse/WFLY-9919
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 11.0.0.Final
> Reporter: Sainath Machupalli
> Assignee: Jason Greene
>
> Our deployment worked on EAP 7 and we started seeing the below exception when we upgraded to EAP 7.1.
>
> 2018-02-07 09:19:46,234 INFO [org.jboss.weld.deployer] (MSC service thread 1-3) WFLYWELD0003: Processing weld deployment inner.war
> 2018-02-07 09:19:46,239 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.deployment.subunit."myEAR.ear"."inner.war".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."myEAR.ear"."inner.war".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of subdeployment "inner.war" of deployment "myEAR.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:172)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.IllegalArgumentException: VFS000025: Given parent ("/content/myEAR.ear/inner.war") is not an ancestor of this virtual file
> at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:119)
> at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:125)
> at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:125)
> at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:125)
> at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:125)
> at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:125)
> at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:112)
> at org.jboss.as.weld.deployment.processors.BeanArchiveProcessor$ResourceRootHandler.createBeanArchiveId(BeanArchiveProcessor.java:348)
> at org.jboss.as.weld.deployment.processors.BeanArchiveProcessor$ResourceRootHandler.processResourceRoot(BeanArchiveProcessor.java:296)
> at org.jboss.as.weld.deployment.processors.BeanArchiveProcessor$ResourceRootHandler.handleResourceRoot(BeanArchiveProcessor.java:237)
> at org.jboss.as.weld.deployment.processors.BeanArchiveProcessor$ResourceRootHandler.access$100(BeanArchiveProcessor.java:206)
> at org.jboss.as.weld.deployment.processors.BeanArchiveProcessor.deploy(BeanArchiveProcessor.java:113)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:165)
> ... 5 more
>
> Our jboss-deployment-structure.xml is as below.
>
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-deployment-structure>
> <ear-subdeployments-isolated>false</ear-subdeployments-isolated>
> <sub-deployment name="inner.war">
> <dependencies>
> <module name="org.jboss.remote-naming"/>
> </dependencies>
> <resources>
> <resource-root path="APP-INF/lib/dep1.jar" />
> <resource-root path="APP-INF/lib/dep2.jar" />
> </resources>
> </sub-deployment>
> </jboss-deployment-structure>
>
> Our EAR structure is below,
> >myEAR.ear
> >inner.war
> >APP-INF
> >lib
> >dep1.jar
> >dep2.jar
> >META-INF
> >jboss-deployment-structure.xml
>
> The same structure and jboss-deployment-structure.xml worked for us on JBOSS EAP 7.
>
> Is there any change in deployment structure? or is it a BUG?
> More details @ https://developer.jboss.org/message/980164#980164
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 3 months
[JBoss JIRA] (WFLY-9919) Deployment throwing exception on upgrade to JBOSS EAP 7.1
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/WFLY-9919?page=com.atlassian.jira.plugin.... ]
jaikiran pai updated WFLY-9919:
-------------------------------
Component/s: CDI / Weld
> Deployment throwing exception on upgrade to JBOSS EAP 7.1
> ---------------------------------------------------------
>
> Key: WFLY-9919
> URL: https://issues.jboss.org/browse/WFLY-9919
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 11.0.0.Final
> Reporter: Sainath Machupalli
> Assignee: Jason Greene
>
> Our deployment worked on EAP 7 and we started seeing the below exception when we upgraded to EAP 7.1.
>
> 2018-02-07 09:19:46,234 INFO [org.jboss.weld.deployer] (MSC service thread 1-3) WFLYWELD0003: Processing weld deployment inner.war
> 2018-02-07 09:19:46,239 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.deployment.subunit."myEAR.ear"."inner.war".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."myEAR.ear"."inner.war".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of subdeployment "inner.war" of deployment "myEAR.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:172)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.IllegalArgumentException: VFS000025: Given parent ("/content/myEAR.ear/inner.war") is not an ancestor of this virtual file
> at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:119)
> at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:125)
> at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:125)
> at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:125)
> at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:125)
> at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:125)
> at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:112)
> at org.jboss.as.weld.deployment.processors.BeanArchiveProcessor$ResourceRootHandler.createBeanArchiveId(BeanArchiveProcessor.java:348)
> at org.jboss.as.weld.deployment.processors.BeanArchiveProcessor$ResourceRootHandler.processResourceRoot(BeanArchiveProcessor.java:296)
> at org.jboss.as.weld.deployment.processors.BeanArchiveProcessor$ResourceRootHandler.handleResourceRoot(BeanArchiveProcessor.java:237)
> at org.jboss.as.weld.deployment.processors.BeanArchiveProcessor$ResourceRootHandler.access$100(BeanArchiveProcessor.java:206)
> at org.jboss.as.weld.deployment.processors.BeanArchiveProcessor.deploy(BeanArchiveProcessor.java:113)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:165)
> ... 5 more
>
> Our jboss-deployment-structure.xml is as below.
>
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-deployment-structure>
> <ear-subdeployments-isolated>false</ear-subdeployments-isolated>
> <sub-deployment name="inner.war">
> <dependencies>
> <module name="org.jboss.remote-naming"/>
> </dependencies>
> <resources>
> <resource-root path="APP-INF/lib/dep1.jar" />
> <resource-root path="APP-INF/lib/dep2.jar" />
> </resources>
> </sub-deployment>
> </jboss-deployment-structure>
>
> Our EAR structure is below,
> >myEAR.ear
> >inner.war
> >APP-INF
> >lib
> >dep1.jar
> >dep2.jar
> >META-INF
> >jboss-deployment-structure.xml
>
> The same structure and jboss-deployment-structure.xml worked for us on JBOSS EAP 7.
>
> Is there any change in deployment structure? or is it a BUG?
> More details @ https://developer.jboss.org/message/980164#980164
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 3 months
[JBoss JIRA] (WFLY-9919) Deployment throwing exception on upgrade to JBOSS EAP 7.1
by Jive JIRA Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-9919?page=com.atlassian.jira.plugin.... ]
Jive JIRA Integration updated WFLY-9919:
----------------------------------------
Forum Reference: https://developer.jboss.org/message/980164#980164
> Deployment throwing exception on upgrade to JBOSS EAP 7.1
> ---------------------------------------------------------
>
> Key: WFLY-9919
> URL: https://issues.jboss.org/browse/WFLY-9919
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 11.0.0.Final
> Reporter: Sainath Machupalli
> Assignee: Jason Greene
>
> Our deployment worked on EAP 7 and we started seeing the below exception when we upgraded to EAP 7.1.
>
> 2018-02-07 09:19:46,234 INFO [org.jboss.weld.deployer] (MSC service thread 1-3) WFLYWELD0003: Processing weld deployment inner.war
> 2018-02-07 09:19:46,239 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.deployment.subunit."myEAR.ear"."inner.war".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."myEAR.ear"."inner.war".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of subdeployment "inner.war" of deployment "myEAR.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:172)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.IllegalArgumentException: VFS000025: Given parent ("/content/myEAR.ear/inner.war") is not an ancestor of this virtual file
> at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:119)
> at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:125)
> at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:125)
> at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:125)
> at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:125)
> at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:125)
> at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:112)
> at org.jboss.as.weld.deployment.processors.BeanArchiveProcessor$ResourceRootHandler.createBeanArchiveId(BeanArchiveProcessor.java:348)
> at org.jboss.as.weld.deployment.processors.BeanArchiveProcessor$ResourceRootHandler.processResourceRoot(BeanArchiveProcessor.java:296)
> at org.jboss.as.weld.deployment.processors.BeanArchiveProcessor$ResourceRootHandler.handleResourceRoot(BeanArchiveProcessor.java:237)
> at org.jboss.as.weld.deployment.processors.BeanArchiveProcessor$ResourceRootHandler.access$100(BeanArchiveProcessor.java:206)
> at org.jboss.as.weld.deployment.processors.BeanArchiveProcessor.deploy(BeanArchiveProcessor.java:113)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:165)
> ... 5 more
>
> Our jboss-deployment-structure.xml is as below.
>
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-deployment-structure>
> <ear-subdeployments-isolated>false</ear-subdeployments-isolated>
> <sub-deployment name="inner.war">
> <dependencies>
> <module name="org.jboss.remote-naming"/>
> </dependencies>
> <resources>
> <resource-root path="APP-INF/lib/dep1.jar" />
> <resource-root path="APP-INF/lib/dep2.jar" />
> </resources>
> </sub-deployment>
> </jboss-deployment-structure>
>
> Our EAR structure is below,
> >myEAR.ear
> >inner.war
> >APP-INF
> >lib
> >dep1.jar
> >dep2.jar
> >META-INF
> >jboss-deployment-structure.xml
>
> The same structure and jboss-deployment-structure.xml worked for us on JBOSS EAP 7.
>
> Is there any change in deployment structure? or is it a BUG?
> More details @ https://developer.jboss.org/message/980164#980164
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 3 months
[JBoss JIRA] (WFLY-9919) Deployment throwing exception on upgrade to JBOSS EAP 7.1
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/WFLY-9919?page=com.atlassian.jira.plugin.... ]
jaikiran pai updated WFLY-9919:
-------------------------------
Priority: Major (was: Critical)
> Deployment throwing exception on upgrade to JBOSS EAP 7.1
> ---------------------------------------------------------
>
> Key: WFLY-9919
> URL: https://issues.jboss.org/browse/WFLY-9919
> Project: WildFly
> Issue Type: Bug
> Reporter: Sainath Machupalli
> Assignee: Jason Greene
>
> Our deployment worked on EAP 7 and we started seeing the below exception when we upgraded to EAP 7.1.
>
> 2018-02-07 09:19:46,234 INFO [org.jboss.weld.deployer] (MSC service thread 1-3) WFLYWELD0003: Processing weld deployment inner.war
> 2018-02-07 09:19:46,239 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.deployment.subunit."myEAR.ear"."inner.war".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."myEAR.ear"."inner.war".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of subdeployment "inner.war" of deployment "myEAR.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:172)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.IllegalArgumentException: VFS000025: Given parent ("/content/myEAR.ear/inner.war") is not an ancestor of this virtual file
> at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:119)
> at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:125)
> at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:125)
> at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:125)
> at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:125)
> at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:125)
> at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:112)
> at org.jboss.as.weld.deployment.processors.BeanArchiveProcessor$ResourceRootHandler.createBeanArchiveId(BeanArchiveProcessor.java:348)
> at org.jboss.as.weld.deployment.processors.BeanArchiveProcessor$ResourceRootHandler.processResourceRoot(BeanArchiveProcessor.java:296)
> at org.jboss.as.weld.deployment.processors.BeanArchiveProcessor$ResourceRootHandler.handleResourceRoot(BeanArchiveProcessor.java:237)
> at org.jboss.as.weld.deployment.processors.BeanArchiveProcessor$ResourceRootHandler.access$100(BeanArchiveProcessor.java:206)
> at org.jboss.as.weld.deployment.processors.BeanArchiveProcessor.deploy(BeanArchiveProcessor.java:113)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:165)
> ... 5 more
>
> Our jboss-deployment-structure.xml is as below.
>
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-deployment-structure>
> <ear-subdeployments-isolated>false</ear-subdeployments-isolated>
> <sub-deployment name="inner.war">
> <dependencies>
> <module name="org.jboss.remote-naming"/>
> </dependencies>
> <resources>
> <resource-root path="APP-INF/lib/dep1.jar" />
> <resource-root path="APP-INF/lib/dep2.jar" />
> </resources>
> </sub-deployment>
> </jboss-deployment-structure>
>
> Our EAR structure is below,
> >myEAR.ear
> >inner.war
> >APP-INF
> >lib
> >dep1.jar
> >dep2.jar
> >META-INF
> >jboss-deployment-structure.xml
>
> The same structure and jboss-deployment-structure.xml worked for us on JBOSS EAP 7.
>
> Is there any change in deployment structure? or is it a BUG?
> More details @ https://developer.jboss.org/message/980164#980164
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 3 months
[JBoss JIRA] (WFLY-9919) Deployment throwing exception on upgrade to JBOSS EAP 7.1
by Sainath Machupalli (JIRA)
Sainath Machupalli created WFLY-9919:
----------------------------------------
Summary: Deployment throwing exception on upgrade to JBOSS EAP 7.1
Key: WFLY-9919
URL: https://issues.jboss.org/browse/WFLY-9919
Project: WildFly
Issue Type: Bug
Reporter: Sainath Machupalli
Assignee: Jason Greene
Priority: Critical
Our deployment worked on EAP 7 and we started seeing the below exception when we upgraded to EAP 7.1.
2018-02-07 09:19:46,234 INFO [org.jboss.weld.deployer] (MSC service thread 1-3) WFLYWELD0003: Processing weld deployment inner.war
2018-02-07 09:19:46,239 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.deployment.subunit."myEAR.ear"."inner.war".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."myEAR.ear"."inner.war".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of subdeployment "inner.war" of deployment "myEAR.ear"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:172)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.IllegalArgumentException: VFS000025: Given parent ("/content/myEAR.ear/inner.war") is not an ancestor of this virtual file
at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:119)
at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:125)
at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:125)
at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:125)
at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:125)
at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:125)
at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:112)
at org.jboss.as.weld.deployment.processors.BeanArchiveProcessor$ResourceRootHandler.createBeanArchiveId(BeanArchiveProcessor.java:348)
at org.jboss.as.weld.deployment.processors.BeanArchiveProcessor$ResourceRootHandler.processResourceRoot(BeanArchiveProcessor.java:296)
at org.jboss.as.weld.deployment.processors.BeanArchiveProcessor$ResourceRootHandler.handleResourceRoot(BeanArchiveProcessor.java:237)
at org.jboss.as.weld.deployment.processors.BeanArchiveProcessor$ResourceRootHandler.access$100(BeanArchiveProcessor.java:206)
at org.jboss.as.weld.deployment.processors.BeanArchiveProcessor.deploy(BeanArchiveProcessor.java:113)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:165)
... 5 more
Our jboss-deployment-structure.xml is as below.
<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
<ear-subdeployments-isolated>false</ear-subdeployments-isolated>
<sub-deployment name="inner.war">
<dependencies>
<module name="org.jboss.remote-naming"/>
</dependencies>
<resources>
<resource-root path="APP-INF/lib/dep1.jar" />
<resource-root path="APP-INF/lib/dep2.jar" />
</resources>
</sub-deployment>
</jboss-deployment-structure>
Our EAR structure is below,
>myEAR.ear
>inner.war
>APP-INF
>lib
>dep1.jar
>dep2.jar
>META-INF
>jboss-deployment-structure.xml
The same structure and jboss-deployment-structure.xml worked for us on JBOSS EAP 7.
Is there any change in deployment structure? or is it a BUG?
More details @ https://developer.jboss.org/message/980164#980164
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 3 months