Re: A WOLongResponsePage that _sometimes_ seems to create a deadlock
Re: A WOLongResponsePage that _sometimes_ seems to create a deadlock
- Subject: Re: A WOLongResponsePage that _sometimes_ seems to create a deadlock
- From: Chuck Hill <email@hidden>
- Date: Wed, 4 May 2005 10:52:30 -0700
Hi Kaj,
On May 4, 2005, at 5:39 AM, Kaj Hejer wrote:
Hi!
We have a WOLongResponsePage that _sometimes_ seems to create a
deadlock. What we observe is that the applications isn't answering to
requests.
Is concurrent request handling enabled or disabled? Does it stop
responding to all requests, or just ones for that particular session?
It is not so easy to reproduce. I have just managed to reproduce this
once in testing. I created a thread dump with kill -QUIT.
Can the use of a inner class create any problems, ref. the followings
lines that refere to the constructor of our inner class (Rapport1 is
out WOLongResponsePage and SvaraltLight is a inner class, see the url
to the sourcefile bellow):
at
com.webobjects.eocontrol._EOCheapCopyMutableArray.count(_EOCheapCopyMut
ableArray.java:92)
at Sporsmal.getSvaralternativCount(Sporsmal.java:237)
at Rapport1$SvaraltLight.<init>(Rapport1.java:59)
I would not think this would be a problem.
Are the following lines interesting since they include NSRecursiveLock:
"WorkerThread7" prio=5 tid=0x00477840 nid=0x13 in Object.wait()
[f0100000..f01019c8]
at java.lang.Object.wait(Native Method)
- waiting on <0xf411e370> (a
com.webobjects.foundation.NSRecursiveLock)
at java.lang.Object.wait(Object.java:429)
at
com.webobjects.foundation.NSRecursiveLock.lock(NSRecursiveLock.java:
72)
- locked <0xf411e370> (a
com.webobjects.foundation.NSRecursiveLock)
at
com.webobjects.eocontrol.EOEditingContext.lock(EOEditingContext.java:
4607)
at Rapport1.awake(Rapport1.java:103)
It looks like line 103 of Rapport1 is attempting to lock an EC already
locked by another thread. Do the status page and long running thread
share an EC? This can cause deadlock of the status update request.
at
com.webobjects.appserver.WOComponent._awakeInContext(WOComponent.java:
862)
at
com.webobjects.appserver.WOSession.restorePageForContextID(WOSession.ja
va:710)
at
com.webobjects.appserver._private.WOComponentRequestHandler._restorePag
eForContextID(WOComponentRequestHandler.java:156)
This looks like a request has come in for the Rapport1 page which is
attempting to lock an EC already locked by another thread. My
suspicion falls immediately to your worker thread.
Should this be something to worry about or should I look elsewhere to
solve this issue?
I think you have found the problem.
We create our own EOObjectStoreCoordinator to not block the rest of
the app from serving requests:
EOObjectStoreCoordinator osc = new EOObjectStoreCoordinator();
//editingContext = new LockErrorScreamerEditingContext(osc);
editingContext = new EOEditingContext(osc);
getSession().writeLog("Rapport1:constructor:EOObjectStoreCoordinator:
" + osc);
getSession().writeLog("Rapport1:constructor:editingContext: "
+ editingContext);
editingContext.setSharedEditingContext(null);
I don't see any locking going on, but I assume it must be. Single
thread and new EOF stack or not, I'd still lock.
The sourcecode for this page can be found at
http://folk.uio.no/kajh/tmp/Rapport1.java
The full thread dump can be found at
http://folk.uio.no/kajh/tmp/dump.txt
We are using WO5.2.3, solaris and Oracle 9.2.
TIA for any input on this issue! :)
I'm a little too busy to dive into source at the moment. Sorry.
Chuck
--
Practical WebObjects - a book for intermediate WebObjects developers
who want to increase their overall knowledge of WebObjects, or those
who are trying to solve specific application development 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