Chris St.John said:
>If you create a thread in the init() method, you have
>to get rid of it in the destroy() method. But Java
>doesn't make it easy to get rid of threads: the thead
>itself has to cooperate, and be very carefully written.
>So if at all possible it's a good idea to avoid spawning
>threads in servlets.
I didn't go into much detail about how I thought the threading should
work coz I was thinking that people could work it out for themselves.
I was thinking of a static daemon thread maintained by the logger
class. Different instances of Logger would co-operate about it's
creation and destruction doing the latter by using finalizers and
perhaps using a standard period of timeout (10 minutes say).
>It might seem trivial (what's a couple of extra threads
>laying around?), but it's like not free'ing memory in
>C++: fine for little 5 line utilities, but in servers,
>leaks accumulate and are expensive to hunt down. Plus,
>it's just bad practice.
True... but I wouldn't say it's like unfreed memory or that it's bad
practice per se. But then I wasn't suggesting that you should leave it
running, taking it for granted that the author would provide the
missing parts of my design (and maybe that was wrong of me).
The JVM implementation can and should be happy with threads that
aren't doing anything. That's why Java is useful, because the vm can
do optimizations like this that would be really hard with a natively
compiled language. I've always liked the green thread approach, Sun
might be losing interest but I anticipate it will gain favour with
microkernel JVM developers.
>Depending on the expected load, it might make
>sense to just try open/write/close-on-every-request
>and see if it really is a problem. Premature optimization is the
>root of all evil, etc.
I've never heard that one before. Kinda goes against the grain of my
guiding principle which is "make things which you'll use over and over
again".
>If that doesn't work, then Nic's idea works fine without
>using a thread if you have the log method itself write out
>the buffer once every 1000 (or 100 or 10 or whatever)
>requests. That way, the file i/o cost is amortized out over
>many requests.
The trouble with that is that you don't get to choose a period when
load is reduced. Using a thread you can set the thread to really low
priority but have it forced if it hasn't cleared it's buffer for a
while.
>But remember to flush the buffer in the
>destroy() method of the servlet. And you might
>add a way for a servlet request to force a buffer flush.
Again, finalization in the Logger class could be used instead.
Nic
___________________________________________________________________________
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
