Re: dev runs fine - server gives errors
Re: dev runs fine - server gives errors
- Subject: Re: dev runs fine - server gives errors
- From: Chuck Hill <email@hidden>
- Date: Wed, 22 Dec 2004 10:24:52 -0800
Um, specifically what errors does the server give? It is Christmas
time after all, perhaps it is just in the giving mood? :-P
On Dec 21, 2004, at 7:04 PM, Nathan Dumar wrote:
Growing number of worker threads to ...
Probably deadlock. Are you running serialized or concurrent dispatch?
Which WO version?
I've just finished reading a whole buncha stuff about this problem,
which all goes to either too many users or deadlock. I *know* I don't
have too many users. I have none. I conclude (could be wrong) that
my app is going to deadlock on the server, as soon as it's launched
(how? there is not one single lock made yet!!).
No. Perhaps in your code you have not made an explicit lock, but I
assure you that locks and unlocks are happening.
Meanwhile, I can use the exact same code on my dev machine for 10
minutes without a single locking problem. Which also means I have no
reasonable means of troubleshooting. I don't even know where to
start. Some setting somewhere??
Factories don't burn down by themselves. They need help from you. er,
no. That's not it. Oh, yeah. Deadlock does not happen by itself.
Requests cause deadlock. If you app never received any requests, it
would never deadlock. So the difference is in the requests received on
the server and on your dev machine. Yes, Virginia, there is a
difference. :-) First off, wotaskd sends requests to apps that it
launches for JavaMonitor (as opposed to dev mode launches). Second, if
you are using DirectConnect, or even a different web server adaptor for
development, then there will be differences in the headers. If your
code depends on headers not present your code may be throwing an
exception which is causing a deadlock. Finally, on the dev server you
can get all sorts of requests from the internet. Remember NIMDA? If
these reach your app, and your code tries to handle one, you can end up
throwing an exception that causes deadlock.
OK, now that you are good and scared... :-) There are two things that
you need to do to start debugging this. First off, you need to find
out exactly which deadlock is happening. Without that you are just
guessing. To do this you need a thread dump (Google that for details).
You can get this by doing a kill -quit <pid> on the hung instance. By
default the thread dump goes to /dev/null, not the most useful place
for this. To avoid this, you will need to edit
/System/Library/WebObjects/JavaApplications/wotaskd.woa/Contents/
Resources/SpawnOfWotaskd.sh. This has been posted several times in the
past, Google on it to find the needed changes if they are not obvious
to you.
OK, so now that we know what is locking, we need to know what is
causing this. You will need to override dispatchRequest in
WOApplication. You want it to go something like this:
- log out the URI
-log out the headers
- log out that you are starting dispatch and the time
- call super
- log out that dispatch is finished and the time
- log out the URI (makes it easier to read the log
- return the results of calling super
If you are doing concurrent dispatch, also log out the thread name
(Thread.currentThread().getName() or something like that).
This should show which request(s) are causing the lock. Then you need
to decided if you can/should block the requests at the web server
level, or if you have problems in you code that need to be fixed.
Chuck
--
Practical WebObjects - a book for intermediate WebObjects developers
who want to increase their overall knowledge of WebObjects, or those
who are trying to solve specific application development problems.
http://www.global-village.net/products/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