Re: Progressively all threads go into deadlock
Re: Progressively all threads go into deadlock
- Subject: Re: Progressively all threads go into deadlock
- From: Chuck Hill <email@hidden>
- Date: Tue, 19 Feb 2008 11:33:41 -0800
Hi Fabrice,
On Feb 19, 2008, at 11:17 AM, Fabrice Pipart wrote:
Thanks for the answer Chuck !
I ll add the stack traces below.
We never lock anything else than EOEditingContext ... (ERXEC
actually).
We are thinking about a different thing : could it be a memory
problem ?
We are allocating "only" 256 Mb and are dealing concurrently with
thousands of objects in background threads, components and
wolongresponses tasks....
Could it lead to a deadlock ?
Possibly. If the JVM runs out of memory, almost anything can
happen. But it sounds like this is the only problem you are seeing
and that it happens somewhat consistently. That does not sound like
an out of memory exception.
Is there anything special to do with EOObjectStoreCoordinator?
I saw properties about pools of EOObjectStoreCoordinator, are they
useful in my case?
Probably not.
Here are some of the stack traces (I reduced the size of traces a
bit and removed the threads sleeping, if you really want all
threads, tell me) :
ApplicationHealthTask:
[1] sun.misc.Unsafe.park (native method)
[2] java.util.concurrent.locks.LockSupport.park (LockSupport.java:
118)
[3]
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInte
rrupt (AbstractQueuedSynchronizer.java:716)
[4]
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued
(AbstractQueuedSynchronizer.java:746)
[5] java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire
(AbstractQueuedSynchronizer.java:1,076)
[6] java.util.concurrent.locks.ReentrantLock$NonfairSync.lock
(ReentrantLock.java:184)
[7] java.util.concurrent.locks.ReentrantLock.lock
(ReentrantLock.java:256)
[8] com.webobjects.eocontrol.EOObjectStoreCoordinator.lock
(EOObjectStoreCoordinator.java:420)
[9] com.webobjects.eocontrol.EOEditingContext.lockObjectStore
(EOEditingContext.java:4,650)
[10] com.webobjects.eocontrol.EOCustomObject.willRead
(EOCustomObject.java:1,165)
[11] com.webobjects.eocontrol._EOMutableKnownKeyDictionary
$Initializer$_GenericRecordBinding.valueInObject
(_EOMutableKnownKeyDictionary.java:570)
[12] com.webobjects.eocontrol.EOCustomObject.storedValueForKey
(EOCustomObject.java:1,634)
[13] com.easyshadow.server.base._Area.type (_Area.java:80)
...
Was the app totally deadlocked when you make these dumps? If not,
these dumps might not mean much.
If it was totally deadlockes, here, I think, is your bug:
...
AWT-AppKit:
Monitoring Thread:
[1] java.net.SocketOutputStream.socketWrite0 (native method)
[2] java.net.SocketOutputStream.socketWrite
(SocketOutputStream.java:92)
[3] java.net.SocketOutputStream.write (SocketOutputStream.java:136)
[4] java.io.BufferedOutputStream.flushBuffer
(BufferedOutputStream.java:65)
[5] java.io.BufferedOutputStream.flush (BufferedOutputStream.java:
123)
[6] com.mysql.jdbc.MysqlIO.send (MysqlIO.java:3,119)
[7] com.mysql.jdbc.MysqlIO.sendCommand (MysqlIO.java:1,818)
[8] com.mysql.jdbc.MysqlIO.sqlQueryDirect (MysqlIO.java:1,961)
[9] com.mysql.jdbc.ConnectionImpl.execSQL (ConnectionImpl.java:
2,543)
[10] com.mysql.jdbc.PreparedStatement.executeInternal
(PreparedStatement.java:1,737)
[11] com.mysql.jdbc.PreparedStatement.execute
(PreparedStatement.java:998)
[12]
com.webobjects.jdbcadaptor.JDBCChannel._bindInputVariablesWithBindings
AndExecute (JDBCChannel.java:265)
[13] com.webobjects.jdbcadaptor.JDBCChannel._evaluateExpression
(JDBCChannel.java:337)
[14] com.webobjects.jdbcadaptor.JDBCChannel.evaluateExpression
(JDBCChannel.java:296)
[15] com.webobjects.jdbcadaptor.JDBCChannel.selectAttributes
(JDBCChannel.java:220)
[16]
com.webobjects.eoaccess.EODatabaseChannel._selectWithFetchSpecificatio
nEditingContext (EODatabaseChannel.java:898)
[17]
com.webobjects.eoaccess.EODatabaseChannel.selectObjectsWithFetchSpecif
ication (EODatabaseChannel.java:234)
[18]
com.webobjects.eoaccess.EODatabaseContext._objectsWithFetchSpecificati
onEditingContext (EODatabaseContext.java:3,055)
[19]
com.webobjects.eoaccess.EODatabaseContext.objectsWithFetchSpecificatio
n (EODatabaseContext.java:3,195)
[20] com.webobjects.eoaccess.EODatabaseContext._fireFault
(EODatabaseContext.java:4,187)
[21]
com.webobjects.eoaccess.EOAccessFaultHandler.completeInitializationOfO
bject (EOAccessFaultHandler.java:89)
[22] com.webobjects.eocontrol.EOCustomObject.willRead
(EOCustomObject.java:1,172)
[23] com.webobjects.eocontrol._EOMutableKnownKeyDictionary
$Initializer$_GenericRecordBinding.valueInObject
(_EOMutableKnownKeyDictionary.java:570)
[24] com.webobjects.eocontrol.EOCustomObject.storedValueForKey
(EOCustomObject.java:1,634)
...
Whatever is happening here has the EODatabaseContext locked which
will prevent any other thread from locking the EOObjectStoreCoordinator.
Chuck
On Feb 19, 2008, at 6:25 PM, Chuck Hill wrote:
On Feb 19, 2008, at 8:59 AM, Fabrice Pipart wrote:
Hi !
I am experiencing very annoying deadlock that happen both in
development and deployment situations under load situations.
It happens randomly. Progressively all threads go into deadlock.
They all block on the same method :
[1] sun.misc.Unsafe.park (native method)
I cannot understand why :-(
We use autolock from Project Wonder with the four magic lines in
Properties.
Both the WorkerThreads and the Background threads block on this
with varying stack traces (or at least I could not determine what
is in common) :
Are there any other traces? I looks like something is locking the
EOObjectStoreCoordinator and not unlocking it. I could be a bug
in WO 5.4 or it could be some place in your code where you are
manually locking, an EODatabaseContext for example, and the unlock
is not happening.
Chuck
AThreadLaunchedFromAWorkerThread
[1] sun.misc.Unsafe.park (native method)
[2] java.util.concurrent.locks.LockSupport.park
(LockSupport.java:118)
[3]
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckIn
terrupt (AbstractQueuedSynchronizer.java:716)
[4]
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued
(AbstractQueuedSynchronizer.java:746)
[5]
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire
(AbstractQueuedSynchronizer.java:1,076)
[6] java.util.concurrent.locks.ReentrantLock$NonfairSync.lock
(ReentrantLock.java:184)
[7] java.util.concurrent.locks.ReentrantLock.lock
(ReentrantLock.java:256)
[8] com.webobjects.eocontrol.EOObjectStoreCoordinator.lock
(EOObjectStoreCoordinator.java:420)
[9] com.webobjects.eocontrol.EOEditingContext.lockObjectStore
(EOEditingContext.java:4,650)
[10] com.webobjects.eocontrol.EOEditingContext.faultForGlobalID
(EOEditingContext.java:3,606)
[11] er.extensions.ERXEC.faultForGlobalID (ERXEC.java:972)
[12] com.webobjects.eoaccess.EOUtilities.localInstanceOfObject
(EOUtilities.java:989)
...
WorkerThread4:
[1] sun.misc.Unsafe.park (native method)
[2] java.util.concurrent.locks.LockSupport.park
(LockSupport.java:118)
[3]
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckIn
terrupt (AbstractQueuedSynchronizer.java:716)
[4]
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued
(AbstractQueuedSynchronizer.java:746)
[5]
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire
(AbstractQueuedSynchronizer.java:1,076)
[6] java.util.concurrent.locks.ReentrantLock$NonfairSync.lock
(ReentrantLock.java:184)
[7] java.util.concurrent.locks.ReentrantLock.lock
(ReentrantLock.java:256)
[8] com.webobjects.eocontrol.EOObjectStoreCoordinator.lock
(EOObjectStoreCoordinator.java:420)
[9] com.webobjects.eocontrol.EOEditingContext.lockObjectStore
(EOEditingContext.java:4,650)
[10]
com.webobjects.eocontrol.EOEditingContext.objectsWithFetchSpecificat
ion (EOEditingContext.java:4,051)
[11] er.extensions.ERXEC.objectsWithFetchSpecification
(ERXEC.java:1,068)
[12]
com.webobjects.eocontrol.EOEditingContext.objectsWithFetchSpecificat
ion (EOEditingContext.java:4,428)
...
It happens under 10.5.1 and 10.5.2 and WebObjects 5.4.0 and 5.4.1
Anyone experienced this?
Anyone has an idea how this can be happening?
Best regards
Fabrice Pipart
www.easyshadow.com
EasyMediaOnline
Digital Signage Software
Easyshadow
Palais de la Scala
1 avenue Henri Dunant
Suite 1155
MC - 98000 Monaco
Skype: fabrice.pipart
Tel. +377 97 98 21 04 (direct)
Fax. +377 97 70 88 07
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40global-village.net
This email sent to email@hidden
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve
specific problems.
http://www.global-village.net/products/practical_webobjects
www.easyshadow.com
EasyMediaOnline
Digital Signage Software
Easyshadow
Palais de la Scala
1 avenue Henri Dunant
Suite 1155
MC - 98000 Monaco
Skype: fabrice.pipart
Tel. +377 97 98 21 04 (direct)
Fax. +377 97 70 88 07
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden