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....
http://en.wikibooks.org/wiki/Programming:WebObjects/
Web_Applications/Deployment/Debugging_Frozen_Deployed_Instances
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 protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
