Nic Ferrier wrote:
> The JVM implementation can and should be happy with
> threads that aren't doing anything.
>
But they aren't. On big servers, threads are a scarce
resource and have to be managed carefully since they take up
operating system resources. On some JVM's (like on
linux) they take up real threads, on others they take
up a lightweight process[1], but there's always a limit.
On a simple little run-once 5 line utility program you
don't have to worry, but on 'real' server programs you do.
Most people should not try to write servlets that spawn
threads (unless they're backed into a corner and can't
avoid it)
> > Premature optimization is the root of all evil, etc.
>
> I've never heard that one before.
The 'premature optimization' quote is widely attributed
to Donald Knuth. The rule is: do it the simplest way
first, then do performance testing to find out what's
slow, and then fix based on what you learned. Just
guessing (like guessing that writing to the file on
each servlet call is a problem) never works. You have
to test. The performance testing part is vital, since
you will always get it wrong if you guess.
> Kinda goes against
> the grain of my guiding principle which is "make things
> which you'll use over and over again".
>
Turning everything into a library leads to a hellishly
complex mass of myriads of miniscule api's, all of which
have to be learned and understood, and none of which
work quite right. Writing reusable code is very hard, and
very slow, and for the most part, it's better just to do
it the simplest way possible and move on.[2]
In this case, it's just about guaranteed that opening
the file in init(), writing to it (and maybe flush()ing
it) on each request, and closing it on destroy is going
to be fast enough, and it's by far the simplest method.
But: that's just a guess :-) The poster will need to
try it out and see. (But unless the servlet is designed
for massive loads, it's gonna work just fine.)
> > But remember to flush the buffer in the destroy() method
> > of the servlet.
>
> Again, finalization in the Logger class could be used
> instead.
>
Finalization can be delayed until the jvm exits (if it
happens at all). If the servlet is destroyed() and reloaded(),
then you have a potential problem. It's generally not a good
idea to reloy on finalization for resource recovery, it's not
like C++ and dtr's.
[1] I might be out of date on this, I know there's been
work to make the java-threads to os-threads mapping more
efficient.
[2] That bit sort of turned into a rant :-), sorry Nic, it
really wasn't directed at you, but in a world gone mad with
inappropriate reuse mania, and in dire need of chastisement
from the righteous :-) :-)
--
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
