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: Kaj Hejer <email@hidden>
- Date: Fri, 6 May 2005 16:56:31 +0200
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
}
}
public void sleep() {
if (editingContext != null && isPerformActionFinished) {
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.
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 :)
_______________________________________________
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