-
Bug
-
Resolution: Done
-
Blocker
-
6.1.0
Description of problem:
I managed to create deadlock in Workbench by deleting a project. After that it is not possible to log into Workbench and server never shuts down because of the deadlocked threads.
Version-Release number of selected component (if applicable):
6.1.0.ER5
How reproducible:
race condition?
Steps to Reproduce:
Not yet.
Actual results:
1 deadlock reported by jstack, impossible to log into workbench, server does not shutdown.
Expected results:
Deadlock should be prevented.
Additional info:
In attached jstack report, look for deadlock section at the end, after full thread dump. It begins with:
Found one Java-level deadlock:
=============================
"http-localhost/127.0.0.1:8080-9":
waiting to lock monitor 0x00007f2fec07a858 (object 0x00000000b7f6e5e0, a org.uberfire.io.impl.IOServiceNio2WrapperImpl),
which is held by "http-localhost/127.0.0.1:8080-6"
"http-localhost/127.0.0.1:8080-6":
waiting for ownable synchronizer 0x00000000b7f6e7b0, (a java.util.concurrent.locks.ReentrantLock$FairSync),
which is held by "Thread-92"
"Thread-92":
waiting to lock monitor 0x00007f2fec07a858 (object 0x00000000b7f6e5e0, a org.uberfire.io.impl.IOServiceNio2WrapperImpl),
which is held by "http-localhost/127.0.0.1:8080-6"
Followed by stack traces of the 3 blocked threads.
- blocks
-
RHBPMS-80 B(P/R)MS cluster cyclic VFS synchronization most likely caused by social events
- Verified
-
RHBPMS-2401 BPM cluster's first node utilizes CPU over 70% without any real load
- Closed