Thank you, dnovo, I hadn't noticed that thread, which is somewhat similar to my problem. Unfortunately the problem in that thread does not seem to be solved.
In my case VisualVM shows me that all my task threads are available (parking). However, one of the EJB threads seem to be deadlocked. How can i debug what is causing this deadlocking? Can the deadlocking of one EJB thread be the cause of this kind of behaviour (WildFly not responding to any HTTP requests), or is this deadlocking just a consequence of the same problem locking other parts of WildFly?
Found one Java-level deadlock:
"EJB default - 1":
waiting to lock monitor 0x000000002c0fcd28 (object 0x00000000b7366880, a java.util.ArrayDeque),
which is held by "default I/O-5"
waiting to lock monitor 0x0000000022623ac8 (object 0x00000000ff048350, a org.xnio.streams.BufferPipeOutputStream),
which is held by "EJB default - 1"
Hi @helmutz I've also encountered the same issue here. In my case, some background (Scheduler) tasks are still running even though wildfly does not respond HTTP requests. Please share the means by which you have solved or reduce the occurrence of this issue to the barest minimum. Thanks.
We are also seeing the same issue on Wildfly 8.2.0 Final. We have set the read-timeout as well as no-request-timeout parameters. Is there any other parameter that needs to be configured in the https listener of undertow? Do we need to tune any IO subsystem parameter?