The best way to fix a dead lock of any sort is to, if possible, track
down the code that caused it and see if changing that is possible.
In other words there is more to this stack trace and probably some
related stack traces (that may not be logged or readily accessible
because of the annoying nature of such problems) that refer to the
code that is calling this code. Basically it is possible to write code
to cause this behavior, both intentionally or through funny cross
dependencies, so tracking down that code is the first step to fixing
this and review of the code and what it does is the first step to
deciding if that code needs to (or can) change, or if the
synchronization needs to be relaxed on some of this stuff.
-David
On Apr 22, 2008, at 6:10 AM, Rajendra Upa wrote:
- waiting to
lock <0x622d9aa8> (a org.ofbiz.entity.GenericValue)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Nabble-From: [EMAIL PROTECTED]
hi ,
I am getting very high CPU usage. I saw one of the Thread among other
thread's as follow :
"http-0.0.0.0-8080-Processor6" daemon prio=1 tid=0x081e0430 nid=0x706a
runnable [0x3c34f000..0x3c350030]
at java.util.Observable.clearChanged(Observable.java)
- waiting to lock <0x622d9aa8> (a org.ofbiz.entity.GenericValue)
at java.util.Observable.notifyObservers(Observable.java:138)
- locked <0x622d9aa8> (a org.ofbiz.entity.GenericValue)
at org.ofbiz.entity.GenericEntity.set(GenericEntity.java:402)
- locked <0x622d9aa8> (a org.ofbiz.entity.GenericValue)
at org.ofbiz.entity.GenericEntity.setFields(GenericEntity.java:851)
- locked <0x622d9aa8> (a org.ofbiz.entity.GenericValue)
From above thread dump , Processor6 is waiting for the lock on
object which
whose hashvalue is 0x622d9aa8 , but it has already got the lock for
this
object. I am not getting why this thread is waiting to acquire lock on
object whom which it has already lock. Above code is executed in Multi
environment , there could be many threads trying to acess the
setFields()
function of GenericEntity which is synchronized. setFields()
function has
set() method which again
snchronized and at the end it is notifying the observers. That point
this
thread is waiting for lock to invoke clearChange() which again
synchronized.
It would be nice some one can provide some information that.
--
View this message in context:
http://www.nabble.com/at-java.util.Observable.clearChanged%28Observable.java%29%0D%0A--waiting-to-lock-%3C0x622d9aa8%3E-%28a-org.ofbiz.entity.GenericValue%29-tp16823826p16823826.html
Sent from the OFBiz - User mailing list archive at Nabble.com.