Hi All
Has anyone experienced this kind of deadlock issue due to a locking order in
Cocoon.
In general, how do we get bugs addressed - is anyone actively looking at bugs ?
Thanks for your pointers!
----- Forwarded Message ----
From: neeru mhatre (JIRA) <j...@apache.org>
To: opensrcn...@yahoo.com
Sent: Thursday, July 9, 2009 2:40:14 PM
Subject: [jira] Created: (COCOON-2261) Deadlock in Cocoon leads to server crash
Deadlock in Cocoon leads to server crash
----------------------------------------
Key: COCOON-2261
URL: https://issues.apache.org/jira/browse/COCOON-2261
Project: Cocoon
Issue Type: Bug
Components: * Cocoon Core
Affects Versions: 2.1.11
Reporter: neeru mhatre
Fix For: 2.1.11
The DEADLOCK scenario:
======================
Inside Cocoon's FOM_JavaScriptInterpreter.java we have the following two
methods:
Method 1 called by [ACTIVE] ExecuteThread: '5'
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.han
dleContinuation(FOM_JavaScriptInterpreter.java:850)
------------------------------------------------
handleContinuation() {
..................
ThreadScope kScope = (ThreadScope)k.getParentScope();
synchronized (kScope) { -> LOCK A [Blocks on 0xbbb26dd8 (kScope)]
................
} finally {
.....................
setSessionScope(kScope); -> LOCK B [Blocks on 0xbd197028
"AttributeWrapper for kScope" with the call AttributeWrapper.getObject() ->
LOCK A [Blocks on 0xbbb26dd8 (kScope) with the call
ScriptableObject.writeObject() <ThreadScope isA ScriptableObject>]]
..............
}
}
}
..
..
Method 2 called by [ACTIVE] ExecuteThread: '4'
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.cal
lFunction(FOM_JavaScriptInterpreter.java:711)
-----------------------------------------------
callFunction() {
......................
ThreadScope thrScope = getSessionScope(); -> LOCK B [Blocks on 0xbd197028
"AttributeWrapper for thrScope == kScope" -> LOCK A [Blocks on 0xbbb26dd8
(thrScope == kScope) with the call ScriptableObject.writeObject()
<ThreadScope isA ScriptableObject>]]
synchronized (thrScope) { -> LOCK A [Blocks on 0xbbb26dd8 (kScope)]
...............
}
}
To summarize we have:
[ACTIVE] ExecuteThread: '5' LOCK A, LOCK B, LOCK A
[ACTIVE] ExecuteThread: '4' LOCK B, LOCK A, LOCK A
which leads to a deadlock. Eventually, this causes a server to crash.
This is causing serious problems on a production server, causing unavailability
of server.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
