Concurrent Timeout exception on starting Jboss Wildfly 9.02 server

Asked 3/12, 2015 at 11:27 Answered 15/11, 2021 at 10:35

I am new to jboss server. When I am trying to deploy .war file on server the following exception gets print on console:

6:38:04,388 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0348: Timeout after [300] seconds waiting for service container stability. Operation will roll back. Step that first updated the service container was 'add' at address '[
    ("core-service" => "management"),
    ("management-interface" => "http-interface")
]'
16:38:05,642 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-4) WFLYJCA0019: Stopped Driver service with driver-name = Aerobay.war_com.mysql.jdbc.Driver_5_1
16:38:09,548 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0190: Step handler org.jboss.as.server.DeployerChainAddHandler$FinalRuntimeStepHandler@5f88823f for operation {"operation" => "add-deployer-chains","address" => []} at address [] failed handling operation rollback -- java.util.concurrent.TimeoutException: java.util.concurrent.TimeoutException
    at org.jboss.as.controller.OperationContextImpl.waitForRemovals(OperationContextImpl.java:396)
    at org.jboss.as.controller.AbstractOperationContext$Step.handleResult(AbstractOperationContext.java:1384)
    at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:1332)
    at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:1292)
    at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:1180)
    at org.jboss.as.controller.AbstractOperationContext.handleContainerStabilityFailure(AbstractOperationContext.java:964)
    at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:590)
    at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:354)
    at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:330)
    at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1183)
    at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:453)
    at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:327)
    at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:313)
    at org.jboss.as.server.ServerService.boot(ServerService.java:384)
    at org.jboss.as.server.ServerService.boot(ServerService.java:359)
    at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:271)
    at java.lang.Thread.run(Thread.java:745)

Thanks in advance for the help !

Threephase answered 3/12, 2015 at 11:27 Comment(1)

I faced this Issue after installing LDPlayer, I remember that installation asked for [disabling/enabling] some feature to fasten the VM, and that makes my Wildfly starting in debug mode noticeably faster! – Sherwin 20/5 at 9:49

I had the same problem when I tried to deploy the WAR file on my Red Hat Jboss EAP 7.0.

But the server was integrated into my IDE (Eclipse Neon) and the problem only occured in Debug-Modus.

I was able to solve the problem by removing all breakpoints and after that i started the server again.

Cuman answered 2/8, 2016 at 12:6 Comment(6)

After updating to neon today I am also seeing this sporadically with WildFly 10 also, but unfortunately even when I have no breakpoints set. I am using JRebel, which might contribute however. For the time being, I think I will go back to Mars.2, which was working well and quite stable. – Germinal 2/8, 2016 at 15:35

Thank you very much for your comment ... I forgot to mention that I started the server in "standard" mode before... (that worked very well). After that I removed all breakpoints and started the server again. And the problem disappeared. – Cuman 2/8, 2016 at 19:5

Same issue with IJ, JRebel and wildfly 8. Remove breakpoints and restart solved it. Thanks. – Morman 20/9, 2016 at 7:51

I'm really pleased! Thank you very much for your vote! :) – Cuman 19/1, 2019 at 21:47

Thanks a lot, I started facing this in last couple of day, would have never able to guess its because of break points in IJ. Thanks – Shred 4/7, 2019 at 11:19

Thanks a lot, your solution solve the problem even with Eclipse – Conduction 2/7 at 22:13

Try increasing timeout by adding java option "blocking.timeout". You can do it in bin/standalone.conf.bat (depends on how you configure wildfly) by adding line:
set "JAVA_OPTS=%JAVA_OPTS% -Djboss.as.management.blocking.timeout=600
Change the number if it's not enough.

Introduce answered 15/12, 2015 at 11:54 Comment(1)

does the increase really solve the problem? – Lytle 18/2, 2021 at 17:33

increasing the timeout doesn't solve the root cause of the problem. You need to check the cause of the time of the block and solve the issue. Maybe in some cases the solution is to increase the timeout.

In most cases, increasing resources is a bad way to solve issues. I had this case, the Wildfly took a lot of time to boot. I increased the timeout to 600 and solved the issue but was still having issue with the wildfly booting time which was so annoying.

2018-03-26 07:50:36,523 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0348: Timeout after [300] seconds waiting for service container stability. Operation will roll back. Step that first updated the service container was 'add' at address '[("path" => "xxxxxxxxxxxxxxxx")]'

Finally I checked the block cause in and found the block was due to network host resolving (NAS storage defined as a path in wildfly).

I jumped to the network setting and found that my local DNS was not set properly. I added the local DNS instead of the public DNS and the block issue was gone. Hope this helps

Regards Sleem

Mcneill answered 26/3, 2018 at 10:52 Comment(1)

I think a part of cases are due to network problems too when changing timeout or resources does not solve the situation. It is also my case ... Because I see network error when enabling TRACE log. But cannot see how to resolve them for the moment ... – Oakleil 9/3, 2022 at 12:26

When i tried to debug and started the server with debug mode got the following error:

16:19:50,096 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) JBAS013412: Timeout after [300] seconds waiting for service container stability. Operation will roll back. Step that first updated the service container was 'deploy' at address '[("deployment" => "ViprWeb.war")]'
16:19:50,096 ERROR [org.jboss.as.server] (management-handler-thread - 1) JBAS015870
16:20:00,117 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) JBAS013413: Timeout after [5000] seconds waiting for service container stability while finalizing an operation.

I removed all my breakpoints and restarted my server jboss and it resolved the issue.

Temptation answered 25/10, 2016 at 22:54 Comment(1)

Months I've (with the help of team members from time to time) been trying to resolve this issue, literally months. Been running wildfly from the command line in the mean time. thank you. – Rodriguez 23/10, 2020 at 11:3

I had the same problem running a "dockerized" application locally - turns out increasing the resources fixed the issue. What I finally settled on: CPUs: 4 Memory: 8GB Swap: 2GB

Couchman answered 3/3, 2020 at 16:12 Comment(0)

just increase time out in standalone.conf.bat set as set "JAVA_OPTS=%JAVA_OPTS% -Djboss.as.management.blocking.timeout=600 It worked for me.

Wauters answered 1/12, 2017 at 12:43 Comment(0)

Same problem, with netbeans

but I had not break points. Running jboss by command line, helped me

Stop jboss
Close Netbeans
open command line
Go to jboss folder > bin >
type: standalone.bat (this starts jboss)
open Netbeans
worked fine!

Hope it'll help someone else.

Eurhythmics answered 30/4, 2019 at 15:19 Comment(1)

thanks, this solved my problem and i am using MyEclipse – Picturize 6/8, 2019 at 7:16

I've been facing the same problem recently with WildFly 18 and 21, trying to run a WAR file containing JSR-352 batch jobs that worked fine on WildFly 14.

Increasing the timeout did not solve the situation, only prolonged the time before the TimeoutException was casted, no matter the value (e.g. 5, 10 or 20 minutes).

I've just found that to turn off microprofile-metrics-smallryesubsystem seems to be a possible solution.

After commenting out this line from the standalone.xml file, the war deploy was successful and much faster (about 2 minutes):

<subsystem xmlns="urn:wildfly:microprofile-metrics-smallrye:2.0" security-enabled="false" exposed-subsystems="*" prefix="${wildfly.metrics.prefix:wildfly}"/>

Trillbee answered 18/11, 2020 at 3:6 Comment(0)

I am having problem with keycloak server 15.0.2.

WFLYCTL0190: Step handler org.jboss.as.server.DeployerChainAddHandler$FinalRuntimeStepHandler@410c55ac for operation add-deployer-chains at address [] failed

I am using mysql5.7 with jconnect8.0 jar.

Deoxyribonuclease answered 15/11, 2021 at 10:35 Comment(0)

I had the same problem. Then I killed the Kaspersky process and it helped!

Colobus answered 29/3, 2018 at 11:40 Comment(0)

I tackled a similar problem and had only succeed with undeploy the the apps. This gave a clean environment for Wildfly to restart and start the management and http-service. Then deploy the apps/WARs and identify what got you to this state.

In my case it was transactions that wanted to recover and deleting those from DB solve the problem bot to re-occur.

Strung answered 24/7, 2018 at 12:27 Comment(0)

Recommended topics

Hot tags