• 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
NSRecursiveLock.lock() causing deadlock??
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

NSRecursiveLock.lock() causing deadlock??


  • Subject: NSRecursiveLock.lock() causing deadlock??
  • From: Dov Rosenberg <email@hidden>
  • Date: Wed, 27 Aug 2008 19:18:13 -0400
  • Thread-topic: NSRecursiveLock.lock() causing deadlock??

Title: NSRecursiveLock.lock() causing deadlock??
We have a WO (5.4.1) app that is deployed as a servlet in Tomcat 5.5 (Java 1.5). We do not use Project Wonder or multiple ObjectStoreCoordinators. We have experienced intermittent hanging issues under load. When we look at the thread dumps I always see things like

"http-10042-Processor111" nid=60350 state=WAITING
    - waiting on <0xcb1792> (a com.webobjects.foundation.NSRecursiveLock)
    - locked <0xcb1792> (a com.webobjects.foundation.NSRecursiveLock)
    at java.lang.Object.wait(Native Method)
    at java.lang.Object.wait(Unknown Source)
    at com.webobjects.foundation.NSRecursiveLock.lock(NSRecursiveLock.java:72)
    at com.webobjects.eocontrol.EOObjectStoreCoordinator.lock(EOObjectStoreCoordinator.java:466)
    at com.webobjects.eocontrol.EOEditingContext.lockObjectStore(EOEditingContext.java:4735)
    at com.webobjects.eocontrol.EOEditingContext.objectsWithFetchSpecification(EOEditingContext.java:4112)
    at com.webobjects.eocontrol.EOEditingContext.objectsWithFetchSpecification(EOEditingContext.java:4500)
    at com.webobjects.eoaccess.EOUtilities.objectsMatchingValues(EOUtilities.java:193)
    at com.webobjects.eoaccess.EOUtilities.objectsMatchingKeyAndValue(EOUtilities.java:168)
...

It seems the root of every thread always has NSRecursiveLock.lock() as part of the thread dump. It doesn’t seem to matter if the call was via EOUtilities or thru a fetch. In a recent thread dump there were 286 threads listed of which 251 (all HTTP threads) had references to NSRecursiveLock.lock(). All of the threads were marked as state=WAITING (none were RUNNABLE). It seems that all of the threads were waiting for something and thus could not do anything but there was no Java deadlocks being thrown.

Questions:
  • Does this indicate that we have an issue with multiple threads within the same JVM? We have ConcurrentRequest handling turned on.
  • Should we investigate using multiple ObjectStoreCoordinators?
  • Is this a red herring and should I look elsewhere for the problem?

Thanks in advance for any insight

Dov Rosenberg
 _______________________________________________
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: NSRecursiveLock.lock() causing deadlock??
      • From: Chuck Hill <email@hidden>
    • Re: NSRecursiveLock.lock() causing deadlock??
      • From: Travis Britt <email@hidden>
  • Prev by Date: Re: WODisplayGroup + qualifyDisplayGroup() + mutators = FAIL
  • Next by Date: Re: NSRecursiveLock.lock() causing deadlock??
  • Previous by thread: Re: D2W Help
  • Next by thread: Re: NSRecursiveLock.lock() causing deadlock??
  • Index(es):
    • Date
    • Thread