Bug 1192459 - Java-level deadlock after deleting project
Summary: Java-level deadlock after deleting project
Keywords:
Status: CLOSED EOL
Alias: None
Product: JBoss BRMS Platform 6
Classification: Retired
Component: Business Central
Version: 6.1.0
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: CR1
: 6.1.0
Assignee: Alexandre Porcelli
QA Contact: Jiri Locker
Dawn Eisner
URL:
Whiteboard:
: 1194103 (view as bug list)
Depends On:
Blocks: 1153674 1159278 1194103
TreeView+ depends on / blocked
 
Reported: 2015-02-13 12:20 UTC by Jiri Locker
Modified: 2020-03-27 19:46 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-03-27 19:46:31 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
jstack output detecting 1 deadlock (149.00 KB, text/plain)
2015-02-13 12:20 UTC, Jiri Locker
no flags Details
deadlock after cloning repository (163.66 KB, text/plain)
2015-02-17 17:08 UTC, Jiri Locker
no flags Details
deadlock in ER6 (20.69 KB, text/plain)
2015-03-10 14:08 UTC, Jiri Locker
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1194103 1 None None None 2021-01-20 06:05:38 UTC

Internal Links: 1194103

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.


Note You need to log in before you can comment on or make changes to this bug.