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: Mon, 9 May 2005 09:41:46 -0700
On May 6, 2005, at 7:56 AM, Kaj Hejer wrote:
Hi!
Thank you for answering!!
On 4. mai 2005, at 19.52, Chuck Hill wrote:
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?
diabled (or more correct: not enabled). It stop responding to all
requests.
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.
The statuspage does not use any ec. It just show a static message + a
counter. The page does not use an ec before performAction is finished
(a woconditional in the component using isPerformActionFinished).
Here is the code containing line 103:
public void awake() {
super.awake();
if (editingContext != null && isPerformActionFinished) {
editingContext.lock(); //line 103
What else uses this editing context? Either it has it locked or, as
Anjo pointed out, awake got called twice and sleep once in a previous
request and the EC was left locked.
}
}
public void sleep() {
if (editingContext != null && isPerformActionFinished) {
Um, what is going to happen if isPerformActionFinished changed from
false to true during the RR loop?
editingContext.unlock();
}
super.sleep();
}
isPerformActionFinished is set to true at the end of performAction.
We found two bad things we have done:
1)
In performAction we have a ec.lock; doSometing(); ec.unlock() without
a try/catch/finaly. Not good! Fixed!
2)
One of the tings we do in performAction is to proccess an NSArray of
objects. We get this array by following a toMany relationship, but the
object that get get this array from was not in our local ec created
from our ObjectStoreCoordinator. No! It was in the
session.defaultEditingContext, so that might be the reason for the
application not responing to requests, since it was busy running a
heavy proccessing in session.defaultEditingContext.
Both of these issues are now fixed and it will be very interesting to
see these changes solves our deadlock looking situastion that occur
about once each day.
Let us know!
Chuck
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.
We do, but we do it in performAction, now even with a try/catch/finaly
clause :)
I'm a little too busy to dive into source at the moment. Sorry.
Ofcource! No problem! :) I'm very glad for the ideas you have given us
here (and before :) The source was just for anyone who for some reason
would get curious and would want to dig.
-Kaj :)
--
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