• 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: WOWorkerThread deadlocks
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: WOWorkerThread deadlocks


  • Subject: Re: WOWorkerThread deadlocks
  • From: Chuck Hill <email@hidden>
  • Date: Wed, 12 Sep 2012 17:25:25 -0700

Hi John,


On 2012-09-12, at 7:13 AM, John Huss wrote:

> >>> The state the app was in when I took that jstack was that no login was possible and user's requests would not return, ultimately running into "no instance" responses after the timeout elapsed.
> >>
> >> Grep the app logs for OutOfMemory, that is one possibility.  They look ready to accept connections.  It could also be that they got so back logged that wotaskd gave up on them and decided they were dead.  Having the lower numbers above should help in this respect - the app will be able to recover more quickly.
> >
> > Never out of memory. The app is allowed to grow up to 24 GByte, stays in the 1-4 GByte range in normal use and occasionally grows up to 12 GByte with the most advanced statistics that tend to suck in the whole database.
> >
> > That's also the reason though that I can't use separate EOF stacks for the statistics, because as soon as there were more than one of them, I'd have multiple 10 GByte-ish snapshot caches. The server has 48 GByte and I don't really want to hit that limit... and with separate stacks, it also would be difficult to keep the stats reflect current changes in the other stacks.
>
>
> I am not sure about the background threads (depends on how long OSC locks are held), but using ECs sharing the same EOF stack with regular requests is likely to cause problems like you are seeing.
>
> Do you mean that the application would be unresponsive while the lock was held in the background thread, or that simply doing it that way will lead to unrecoverable deadlocks?

I meant that when the EC locks the OSC (e.g during fetches and saves) it would block all other requests also needing to lock the OSC.  If the background thread's locks of the OSC are very short in duration (and also not happening constantly) it would have little effect on the other request.  However that is not what background processing is often used for.

Chuck

--
Chuck Hill             Senior Consultant / VP Development

Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems.
http://www.global-village.net/gvc/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

References: 
 >WOWorkerThread deadlocks (From: Maik Musall <email@hidden>)
 >Re: WOWorkerThread deadlocks (From: Chuck Hill <email@hidden>)
 >Re: WOWorkerThread deadlocks (From: Maik Musall <email@hidden>)
 >Re: WOWorkerThread deadlocks (From: Chuck Hill <email@hidden>)
 >Re: WOWorkerThread deadlocks (From: Maik Musall <email@hidden>)
 >Re: WOWorkerThread deadlocks (From: Chuck Hill <email@hidden>)
 >Re: WOWorkerThread deadlocks (From: Maik Musall <email@hidden>)
 >Re: WOWorkerThread deadlocks (From: Chuck Hill <email@hidden>)
 >Re: WOWorkerThread deadlocks (From: John Huss <email@hidden>)

  • Prev by Date: Re: WOWorkerThread deadlocks
  • Next by Date: Re: WOWorkerThread deadlocks
  • Previous by thread: Re: WOWorkerThread deadlocks
  • Next by thread: Re: WOWorkerThread deadlocks
  • Index(es):
    • Date
    • Thread