From users-return-97825-apmail-cocoon-users-archive=cocoon.apache.org@cocoon.apache.org Thu Jul 09 17:40:21 2009 Return-Path: Delivered-To: apmail-cocoon-users-archive@www.apache.org Received: (qmail 2137 invoked from network); 9 Jul 2009 17:40:20 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 9 Jul 2009 17:40:20 -0000 Received: (qmail 81911 invoked by uid 500); 9 Jul 2009 17:40:30 -0000 Delivered-To: apmail-cocoon-users-archive@cocoon.apache.org Received: (qmail 81811 invoked by uid 500); 9 Jul 2009 17:40:29 -0000 Mailing-List: contact users-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: users@cocoon.apache.org List-Id: Delivered-To: mailing list users@cocoon.apache.org Received: (qmail 81803 invoked by uid 99); 9 Jul 2009 17:40:29 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 09 Jul 2009 17:40:29 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [68.142.237.91] (HELO n6.bullet.re3.yahoo.com) (68.142.237.91) by apache.org (qpsmtpd/0.29) with SMTP; Thu, 09 Jul 2009 17:40:16 +0000 Received: from [68.142.230.29] by n6.bullet.re3.yahoo.com with NNFMP; 09 Jul 2009 17:39:55 -0000 Received: from [67.195.9.81] by t2.bullet.re2.yahoo.com with NNFMP; 09 Jul 2009 17:39:55 -0000 Received: from [67.195.9.97] by t1.bullet.mail.gq1.yahoo.com with NNFMP; 09 Jul 2009 17:39:55 -0000 Received: from [127.0.0.1] by omp101.mail.gq1.yahoo.com with NNFMP; 09 Jul 2009 17:39:55 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 88233.29456.bm@omp101.mail.gq1.yahoo.com Received: (qmail 84114 invoked by uid 60001); 9 Jul 2009 17:39:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1247161194; bh=Q6dvCKnHavkEfQjArIMRoSDvBYKn7AVmZfrXH/05O+0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=b/KcTU+dusHlGEt4ZqRbH9Htrd7Y7pbQ1x5zK3V0btKAXxp98rUvR0QEurlO/Y1ZUipDjYKb2/QIKcH34aILtatAolFDxGCD9B7Ui45HnV315MewILsRKmW9BtayuWUFrntrrpdC0/EfH/sdmiebaQklAiFlfB9WLWt+i3rdjZA= DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=qgvGLWWImYr0XkIXkgVkmfS0x5PhrYXQT5NuNeJztlk2XSY0VwHEk/SR+PDyfKhDeRlwnbXkZ75sUQyQvlfvDpwQmTemRW1Pr4L+b+Viu3QS3Iphjjk/Q47SR3DlsEUGWnccirid18s6LUwIyWS79CIp/VfRUGYA20cck8SH4lk=; Message-ID: <979032.73913.qm@web111920.mail.gq1.yahoo.com> X-YMail-OSG: SO.FvJMVM1kvy9RfZcmjswZ5LaMCV8PY5AZLpx1LgwYxHyABzo3G3gydJ.euLhhJ03PHehaeIhTHe8azjCfoMfUXbCODWGlhpuYZSxafRHJV_FNbPAK_xv3PlCvUkuyoKSulyl8xfnMcoTx8UJ3C1t0MuS0aAhVQs7mhKphql2_A_VEyTDj3jYEphw5qzmHaBL8JX0ENqCskFU3TN35jUKM.tqAKXjOaXqGp8kaNB7RrhBwlbkiWmsud8zFtbJunWia2sVMtygBuU.jpJ7LDaLNciE43QGMYBS7hEBgcocg- Received: from [96.57.168.20] by web111920.mail.gq1.yahoo.com via HTTP; Thu, 09 Jul 2009 10:39:54 PDT X-Mailer: YahooMailRC/1358.21 YahooMailWebService/0.7.289.15 Date: Thu, 9 Jul 2009 10:39:54 -0700 (PDT) From: Niru Mhatre Subject: Cocoon Deadlock Issue crashing weblogic server To: users@cocoon.apache.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1760959241-1247161194=:73913" X-Virus-Checked: Checked by ClamAV on apache.org --0-1760959241-1247161194=:73913 Content-Type: text/plain; charset=us-ascii We are using Cocoon as part of a Content Management System application. The CMS is being hosted in production on a Weblogic application server. The client using this configuration is periodically experiencing a deadlock issue that from the thread dump appears to be coming from the Cocoon application. Could you please let us know if this is a known issue. If not, do you have a recommendation on how to resolve this issue. This deadlock eventually causes the system to run out of memory and crashes the server. Here is the thread dump that shows the deadlock: nside 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() ]] .............. } } } .. .. 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() ]] 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 will lead in time to a deadlock. Can we ensure that the same locking order happens in the two methods. Thanks for your help and recommendations. --0-1760959241-1247161194=:73913 Content-Type: text/html; charset=us-ascii

We are using Cocoon as part of a Content Management System application. The CMS is being hosted in production on a Weblogic application server. The client using this configuration is periodically experiencing a deadlock issue that from the thread dump appears to be coming from the Cocoon application. Could you please let us know if this is a known issue. If not, do you have a recommendation on how to resolve this issue.

This deadlock eventually causes the system to run out of memory and crashes the server.
Here is the thread dump that shows the deadlock:

nside 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 will lead in time to a deadlock.


Can we ensure that the same locking order happens in the two methods.


Thanks for your help and recommendations.



--0-1760959241-1247161194=:73913--