[JBoss JIRA] (WFLY-9917) renewal of server certificate for Undertow without restarting server
by Bernard H (JIRA)
[ https://issues.jboss.org/browse/WFLY-9917?page=com.atlassian.jira.plugin.... ]
Bernard H commented on WFLY-9917:
---------------------------------
scope:
* add/renew CA root certs
* add/renew remote parties certs for remote party authentication
* add/renew local server identities (when multiple realms+HTTPS listeners are used on different inbound connection ports)
Tips?
* move all params/settings to host controller side, trust related + identity related(already)
* host controller to dispatch updates (push? pull?)
* note: host controller can already be restarted without restarting servers
> renewal of server certificate for Undertow without restarting server
> --------------------------------------------------------------------
>
> Key: WFLY-9917
> URL: https://issues.jboss.org/browse/WFLY-9917
> Project: WildFly
> Issue Type: Feature Request
> Components: Web (Undertow)
> Affects Versions: 11.0.0.Final
> Reporter: Hisanobu Okuda
> Assignee: Stuart Douglas
>
> It is convenient that a server certificate for https interface can be renewed without restarting a server.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 8 months
[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)
[ https://issues.jboss.org/browse/DROOLS-2352?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet updated DROOLS-2352:
-------------------------------------
Description:
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()`.
Note: I have no idea if this even make sense: those turtle tests use a drl file input and don't use the kie-maven-plugin. We're looking for a switch to just turn it on and see if they are all still green. Mario thinks it's possible.
was:
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()`.
> 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
>
> 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()`.
> Note: I have no idea if this even make sense: those turtle tests use a drl file input and don't use the kie-maven-plugin. We're looking for a switch to just turn it on and see if they are all still green. Mario thinks it's possible.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 8 months
[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)
[ https://issues.jboss.org/browse/DROOLS-2352?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet reassigned DROOLS-2352:
----------------------------------------
Assignee: (was: Mario Fusco)
> 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
>
> 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)
7 years, 8 months
[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)
7 years, 8 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)
7 years, 8 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)
7 years, 8 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)
7 years, 8 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)
7 years, 8 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)
7 years, 8 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)
7 years, 8 months