• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: A WOLongResponsePage that _sometimes_ seems to create a deadlock
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • Follow-Ups:
    • Re: A WOLongResponsePage that _sometimes_ seems to create a deadlock
      • From: Chuck Hill <email@hidden>
    • Re: A WOLongResponsePage that _sometimes_ seems to create a deadlock
      • From: Anjo Krank <email@hidden>
References: 
 >A WOLongResponsePage that _sometimes_ seems to create a deadlock (From: Kaj Hejer <email@hidden>)
 >Re: A WOLongResponsePage that _sometimes_ seems to create a deadlock (From: Chuck Hill <email@hidden>)

  • Prev by Date: Re: WebObjects 5.2.4
  • Next by Date: Re: WebObjects 5.2.4
  • Previous by thread: Re: A WOLongResponsePage that _sometimes_ seems to create a deadlock
  • Next by thread: Re: A WOLongResponsePage that _sometimes_ seems to create a deadlock
  • Index(es):
    • Date
    • Thread