Re: [SOLVED] dev runs fine - server gives errors
Re: [SOLVED] dev runs fine - server gives errors
- Subject: Re: [SOLVED] dev runs fine - server gives errors
- From: Nathan Dumar <email@hidden>
- Date: Wed, 22 Dec 2004 19:44:35 -0500
Oh no. I did something really stupid. It was bound to happen, and I
had a bad feeling during these *days* of struggle to deploy my first
app, that this was all somehow the result of something painfully
stupid. And it would all come down to something I've done, or failed
to do. It did.
Chuck, thank you for such thorough and thoughtful help in this message.
I will use it one day. I will print it and tape it to the inside
cover of Practical WebObjects. It will not be in vain!
So what did I do? Geez, I'm embarrassed to say ... I've heard so many,
many times to delete the "Build" directory when things go unexplainably
bad. I've done it myself more times than I can remember. During my
first deployment, I forgot that the .woa was not a single file, but a
directory containing many files. During one of my (many) uploads, I
happened to notice that the modification date was today, and the
creation date was sometime last year. I absently wondered how that
strange error could have occurred. Then it hit me. The .woa was also
a build directory, and needed to be deleted before a fresh build. I
should have known that. Trashing the existing .woa and building again
solved all of the problems. Let this be a lesson to all!
Randall Perry at Systame.com (hosting my app) has shown tremendous
patience, persistence, and professionalism during these several days of
my floundering around, trying to deploy my first app. I have to
recommend Systame wholeheartedly. He has put up with a lot, and never
a negative word, just straight business. It's a pleasure working with
him. He has earned a "Hosted by Systame" link on my site.
So, thank you for everyone's help. (Some of the locking problems were
real, and were fixed -- see the recent, lengthy thread "locking
problem".)
Take care,
Nathan
On Dec 22, 2004, at 1:24 PM, Chuck Hill wrote:
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