[JBoss JIRA] (WFLY-9278) EJB Access Timeout is ignored on SFSBs when using distributed caches
by Tomasz Adamski (Jira)
[ https://issues.redhat.com/browse/WFLY-9278?page=com.atlassian.jira.plugin... ]
Tomasz Adamski resolved WFLY-9278.
----------------------------------
Resolution: Out of Date
> EJB Access Timeout is ignored on SFSBs when using distributed caches
> --------------------------------------------------------------------
>
> Key: WFLY-9278
> URL: https://issues.redhat.com/browse/WFLY-9278
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 11.0.0.CR1
> Reporter: Bernhard Hablesreiter
> Assignee: Tomasz Adamski
> Priority: Major
> Attachments: wildfly-request-test.zip
>
>
> When using distributed caches on Stateful Session Beans, the configured access timeout is ignored. However, the caches acquire-timeout is used instead, leading to a "org.infinispan.util.concurrent.TimeoutException: ISPN000299: Unable to acquire lock after x seconds".
> The configuration:
> {code:xml}
> <session-bean>
> <stateless>
> <bean-instance-pool-ref pool-name="slsb-strict-max-pool"/>
> </stateless>
> <stateful default-access-timeout="2000" cache-ref="distributable" passivation-disabled-cache-ref="simple"/>
> <singleton default-access-timeout="2000"/>
> </session-bean>
> <pools>
> <bean-instance-pools>
> <strict-max-pool name="slsb-strict-max-pool" derive-size="from-worker-pools" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
> <strict-max-pool name="mdb-strict-max-pool" derive-size="from-cpu-count" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
> </bean-instance-pools>
> </pools>
> <caches>
> <cache name="simple"/>
> <cache name="distributable" passivation-store-ref="infinispan" aliases="passivating clustered"/>
> </caches>
> ...
> <subsystem xmlns="urn:jboss:domain:infinispan:4.0">
> ...
> <cache-container name="ejb" aliases="sfsb" default-cache="passivation" module="org.wildfly.clustering.ejb.infinispan">
> <local-cache name="passivation">
> <locking isolation="REPEATABLE_READ" acquire-timeout="10000"/>
> <transaction mode="BATCH" />
> <file-store passivation="true" purge="true"/>
> </local-cache>
> </cache-container>
> ...
> </subsystem>
> {code}
> With the above configuration, any access to a @Stateful-component does not timeout after 2 seconds, but the 10 seconds configured on the infinispan-cache.
> I have attached a simple JSF web application as an eclipse project to reproduce the problem. The application calls a method on a sfsb, increments a counter and waits for 300ms. If one sends multiple request at the same time (e.g. by pressing F5 repeatedly), the problem can easily be reproduced after a few seconds.
> If the cache-ref is set to "simple" the configured access timeout works as expected, however the access to the stateful bean does not appear to be in sync with the requests the client sent. We came around this issue when trying to migrate vom WF9 to WF10 (see also this forum post: https://developer.jboss.org/thread/266303). When the cache-ref is set to "distrubted", the requests are handled correctly/in correct order (in WF9 this was also the case with cache-ref "simple"), but the access timeout is ignored.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-9278) EJB Access Timeout is ignored on SFSBs when using distributed caches
by Tomasz Adamski (Jira)
[ https://issues.redhat.com/browse/WFLY-9278?page=com.atlassian.jira.plugin... ]
Tomasz Adamski commented on WFLY-9278:
--------------------------------------
I can no longer reproduce this error - closing.
> EJB Access Timeout is ignored on SFSBs when using distributed caches
> --------------------------------------------------------------------
>
> Key: WFLY-9278
> URL: https://issues.redhat.com/browse/WFLY-9278
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 11.0.0.CR1
> Reporter: Bernhard Hablesreiter
> Assignee: Tomasz Adamski
> Priority: Major
> Attachments: wildfly-request-test.zip
>
>
> When using distributed caches on Stateful Session Beans, the configured access timeout is ignored. However, the caches acquire-timeout is used instead, leading to a "org.infinispan.util.concurrent.TimeoutException: ISPN000299: Unable to acquire lock after x seconds".
> The configuration:
> {code:xml}
> <session-bean>
> <stateless>
> <bean-instance-pool-ref pool-name="slsb-strict-max-pool"/>
> </stateless>
> <stateful default-access-timeout="2000" cache-ref="distributable" passivation-disabled-cache-ref="simple"/>
> <singleton default-access-timeout="2000"/>
> </session-bean>
> <pools>
> <bean-instance-pools>
> <strict-max-pool name="slsb-strict-max-pool" derive-size="from-worker-pools" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
> <strict-max-pool name="mdb-strict-max-pool" derive-size="from-cpu-count" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
> </bean-instance-pools>
> </pools>
> <caches>
> <cache name="simple"/>
> <cache name="distributable" passivation-store-ref="infinispan" aliases="passivating clustered"/>
> </caches>
> ...
> <subsystem xmlns="urn:jboss:domain:infinispan:4.0">
> ...
> <cache-container name="ejb" aliases="sfsb" default-cache="passivation" module="org.wildfly.clustering.ejb.infinispan">
> <local-cache name="passivation">
> <locking isolation="REPEATABLE_READ" acquire-timeout="10000"/>
> <transaction mode="BATCH" />
> <file-store passivation="true" purge="true"/>
> </local-cache>
> </cache-container>
> ...
> </subsystem>
> {code}
> With the above configuration, any access to a @Stateful-component does not timeout after 2 seconds, but the 10 seconds configured on the infinispan-cache.
> I have attached a simple JSF web application as an eclipse project to reproduce the problem. The application calls a method on a sfsb, increments a counter and waits for 300ms. If one sends multiple request at the same time (e.g. by pressing F5 repeatedly), the problem can easily be reproduced after a few seconds.
> If the cache-ref is set to "simple" the configured access timeout works as expected, however the access to the stateful bean does not appear to be in sync with the requests the client sent. We came around this issue when trying to migrate vom WF9 to WF10 (see also this forum post: https://developer.jboss.org/thread/266303). When the cache-ref is set to "distrubted", the requests are handled correctly/in correct order (in WF9 this was also the case with cache-ref "simple"), but the access timeout is ignored.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-13386) Hung process instances and associated server.log WARN "Failed to reinstate timer 'kie-server.kie-server.EJBTimerScheduler' "
by Enrique González Martínez (Jira)
[ https://issues.redhat.com/browse/WFLY-13386?page=com.atlassian.jira.plugi... ]
Enrique González Martínez updated WFLY-13386:
---------------------------------------------
Issue Type: Bug (was: Enhancement)
> Hung process instances and associated server.log WARN "Failed to reinstate timer 'kie-server.kie-server.EJBTimerScheduler' "
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-13386
> URL: https://issues.redhat.com/browse/WFLY-13386
> Project: WildFly
> Issue Type: Bug
> Reporter: Enrique González Martínez
> Assignee: Brian Stansberry
> Priority: Major
>
> When a timer is reloaded for the first time in other node there are no listeners attached to it causing this problem (only in cluster environments with db timers)
> {code}
> 2020-04-15 16:43:57,733 WARN [org.jboss.as.ejb3.timer] (Timer-1) WFLYEJB0161: Failed to reinstate timer 'kie-server.kie-server.EJBTimerScheduler' (id=33170e5f-3b34-4503-8796-9b5e6871c074) from its persistent state: java.lang.NullPointerException
> at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence$RefreshTask.run(DatabaseTimerPersistence.java:851)
> at java.util.TimerThread.mainLoop(Timer.java:555)
> at java.util.TimerThread.run(Timer.java:505)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-13386) Hung process instances and associated server.log WARN "Failed to reinstate timer 'kie-server.kie-server.EJBTimerScheduler' "
by Enrique González Martínez (Jira)
Enrique González Martínez created WFLY-13386:
------------------------------------------------
Summary: Hung process instances and associated server.log WARN "Failed to reinstate timer 'kie-server.kie-server.EJBTimerScheduler' "
Key: WFLY-13386
URL: https://issues.redhat.com/browse/WFLY-13386
Project: WildFly
Issue Type: Enhancement
Reporter: Enrique González Martínez
Assignee: Brian Stansberry
When a timer is reloaded for the first time in other node there are no listeners attached to it causing this problem (only in cluster environments with db timers)
{code}
2020-04-15 16:43:57,733 WARN [org.jboss.as.ejb3.timer] (Timer-1) WFLYEJB0161: Failed to reinstate timer 'kie-server.kie-server.EJBTimerScheduler' (id=33170e5f-3b34-4503-8796-9b5e6871c074) from its persistent state: java.lang.NullPointerException
at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence$RefreshTask.run(DatabaseTimerPersistence.java:851)
at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)
{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-13385) Introduce ability to increase the timeout for the test which utilize CLI wrapper from shared testsuite module
by Ondrej Chaloupka (Jira)
Ondrej Chaloupka created WFLY-13385:
---------------------------------------
Summary: Introduce ability to increase the timeout for the test which utilize CLI wrapper from shared testsuite module
Key: WFLY-13385
URL: https://issues.redhat.com/browse/WFLY-13385
Project: WildFly
Issue Type: Enhancement
Components: Test Suite
Affects Versions: 19.0.0.Final
Reporter: Ondrej Chaloupka
Assignee: Ondrej Chaloupka
In Narayana CI we experience time to time a trouble of timeouting CLI operations which happens after {{reload}} is executed and just after that is run another CLI command.
We experience this with tests which use the {{CLIWrapper}} from the {{wildfly-core}} shared testsuite module (https://github.com/wildfly/wildfly-core/blob/12.0.0.Beta1/testsuite/share...)
For example test {{org.jboss.as.test.integration.management.cli.DataSourceTestCase}} (https://github.com/wildfly/wildfly/blob/19.0.0.Final/testsuite/integratio...) executes a change and then immediatelly runs {{reload}}, or other test cases which run {{reload}} and immediatelly runs some query.
When our CI is uder load then it's not capable to reload app server (or introduce changes of e.g. adding datasource to the model) in 5 seconds (which is the default {{--timeout}} for {{jboss-cli}} and fails.
{code}
testDataSource(org.jboss.as.test.integration.management.cli.DataSourceTestCase) Time elapsed: 6.102 s <<< FAILURE!
java.lang.AssertionError:
Failed to execute line 'reload'
org.jboss.as.cli.CommandLineException: java.util.concurrent.ExecutionException: org.jboss.as.cli.CommandLineException: Failed to establish connection in 6020ms
at org.jboss.as.cli.impl.CommandContextImpl.execute(CommandContextImpl.java:932)
at org.jboss.as.cli.impl.CommandContextImpl.handleLegacyCommand(CommandContextImpl.java:1902)
at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:869)
at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:218)
at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:244)
at org.jboss.as.test.integration.management.cli.DataSourceTestCase.testRemoveDataSource(DataSourceTestCase.java:160)
at org.jboss.as.test.integration.management.cli.DataSourceTestCase.testDataSource(DataSourceTestCase.java:82)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at org.jboss.arquillian.junit.Arquillian$8$1.invokeMethod(Arquillian.java:325)
at org.jboss.arquillian.junit.MethodInvoker$1.invoke(MethodInvoker.java:18)
at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:57)
at sun.reflect.GeneratedMethodAccessor53.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:62)
at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:50)
at sun.reflect.GeneratedMethodAccessor16.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:128)
at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:118)
at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:83)
at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:69)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:116)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:139)
at org.jboss.arquillian.junit.MethodInvoker.invoke(MethodInvoker.java:15)
at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:332)
at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:204)
at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:350)
at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:215)
at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:279)
at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.execute(ClientBeforeAfterLifecycleEventExecuter.java:88)
at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.on(ClientBeforeAfterLifecycleEventExecuter.java:66)
at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:128)
at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createBeforeContext(ContainerEventController.java:114)
at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:83)
at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:69)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:116)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159)
at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:273)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:166)
at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:350)
at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:177)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:115)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344)
at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417)
Caused by: java.util.concurrent.ExecutionException: org.jboss.as.cli.CommandLineException: Failed to establish connection in 6020ms
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:192)
at org.jboss.as.cli.impl.CommandExecutor.execute(CommandExecutor.java:713)
at org.jboss.as.cli.impl.CommandExecutor.execute(CommandExecutor.java:694)
at org.jboss.as.cli.impl.CommandContextImpl.lambda$handleLegacyCommand$4(CommandContextImpl.java:1903)
at org.jboss.as.cli.impl.CommandContextImpl.execute(CommandContextImpl.java:919)
... 125 more
Caused by: org.jboss.as.cli.CommandLineException: Failed to establish connection in 6020ms
at org.jboss.as.cli.handlers.ReloadHandler.ensureServerRebootComplete(ReloadHandler.java:332)
at org.jboss.as.cli.handlers.ReloadHandler.doHandle(ReloadHandler.java:231)
at org.jboss.as.cli.handlers.CommandHandlerWithHelp.handle(CommandHandlerWithHelp.java:89)
at org.jboss.as.cli.impl.CommandExecutor$2.lambda$build$0(CommandExecutor.java:685)
at org.jboss.as.cli.impl.CommandExecutor.lambda$execute$0(CommandExecutor.java:708)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
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)
{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years