Bug 1192459

Summary: Java-level deadlock after deleting project
Product: [Retired] JBoss BRMS Platform 6 Reporter: Jiri Locker <jlocker>
Component: Business CentralAssignee: Alexandre Porcelli <porcelli>
Status: CLOSED EOL QA Contact: Jiri Locker <jlocker>
Severity: urgent Docs Contact: Dawn Eisner <deisner>
Priority: urgent    
Version: 6.1.0CC: jlocker, kverlaen, lpetrovi, manstis, mbaluch, rrajasek
Target Milestone: CR1Keywords: TestBlocker
Target Release: 6.1.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-03-27 19:46:31 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1153674, 1159278, 1194103    
Attachments:
Description Flags
jstack output detecting 1 deadlock
none
deadlock after cloning repository
none
deadlock in ER6 none

Description Jiri Locker 2015-02-13 12:20:28 UTC
Created attachment 991351 [details]
jstack output detecting 1 deadlock

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.

Comment 2 Alexandre Porcelli 2015-02-13 12:57:00 UTC
What version is this test has been executed with?

Comment 3 Kris Verlaenen 2015-02-13 13:40:40 UTC
Description says 6.1.0.ER5

Comment 4 Jiri Locker 2015-02-17 17:08:36 UTC
Created attachment 992815 [details]
deadlock after cloning repository

Also reproduced by cloning (large) repository in Workbench UI.

Comment 5 Jiri Locker 2015-02-19 10:59:27 UTC
This happens quite frequently and complicates automated testing.

Comment 10 Jiri Locker 2015-03-10 14:08:06 UTC
Created attachment 999961 [details]
deadlock in ER6

We have hit the deadlock again in ER6.

It happened only once so far and a different part of code seems to be affected this time. It happened during manipulation with managed repository modules. Let me know if more info is needed.

Comment 11 Zuzana Krejčová 2015-03-10 14:21:04 UTC
*** Bug 1194103 has been marked as a duplicate of this bug. ***

Comment 12 Alexandre Porcelli 2015-03-10 20:48:31 UTC
Additional improvements:

(master) http://github.com/uberfire/uberfire/commit/f656d837f

Here a change to remove a missing sync method:

(master) http://github.com/droolsjbpm/kie-wb-common/commit/0ab922f2d

Comment 14 Jiri Locker 2015-04-14 13:43:33 UTC
Not observed in CRx builds.