Re: Debugging a frozen instance
Re: Debugging a frozen instance
- Subject: Re: Debugging a frozen instance
- From: Mike Schrag <email@hidden>
- Date: Fri, 18 May 2007 16:52:56 -0400
1) Has java 5 given us any new way to attach to a running app and see the threads or does the foresight of applying jdb startup parameters to each instance still apply with a view to using jdb *if* you get a frozen app as outlined in WO wiki....
JProfiler can do this, but kill -QUIT will give you a snapshot.
kill -QUIT had no effect on it (it was a deployed instance on a G4 XServe), I had to do kill -9 to kill it
kill -QUIT dumps the current stack trace out to stderr, which is normally thrown away unless you modify spawnOfWotaskd.sh -- the wikibook talks about how. 2) I understood that wotaskd would kill and restart a deadlocked unresponsive instance automatically ..... but it did not do it today?
It does not do this ... It will restart a STOPPED instance automatically. But a deadlocked instance is not going anywhere on its own.
Is there any FOSS tools that can be used to check for specific WO instances being alive so that I can set up automatic notification or a scripted kill?
I have pingAction and pingDatabaseAction direct actions that take passwords that all our apps get, so you can use nagios or whatever to make sure the app is alive and the database is alive (but since database check is slightly heavier, they are split out so i can ping them at different frequencies). 3) Besides ERXObjectStoreCoordinator for broadcasting EOF stack changes, what other reliable synchronization options are available?
I have not heard of any of the synchronization options being reliable. It's why I started work on the multicast one, because every other one had a pretty spotty sounding history in the mailing list archives.
However, over the past month or so I have done many 500+ freaking-out-click-crazy-concurrent-user-reading-and-writing load tests on top of the ERX stack synchronizer, both multicast/remote and multistack single-instance without a single deadlock. Anything's possible, but I have not seen it happen under some pretty NASTY conditions.
My conditions are not nasty ....... so maybe I introduced something nasty in my code somewhere. Mostly one stack is being used in an instance for user interaction and separate stack(s) are used for occasional intense EOF imports, data cleaning/manipulation, in long response or background threads.
"in long response or background threads" start there ... I think you said you already do this, but I would recommend passing GIDs into threads and reloading them inside the thread. Out of unverified fear, I often manually lock ec's in background threads even though autolocking SHOULD be taking care of business -- mainly because I use lock coalescing in Wonder, and I never remember how it behaves outside of an R-R loop and I've been too lazy to check.
But I would get those Thread dumps first.
ms |
_______________________________________________
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