> From: "Nic Ferrier" <[EMAIL PROTECTED]>
> > And as long as these blocked threads are really blocked then a decent
> > threading implementation (eg: green threads) won't actually create any
> > more processing overhead because the thread layer should be
> > implemented as a swappable pool of OS threads.
>
> "then a decent threading implementation"
>
> perhaps, but what implementations are decent?
In general I agree with Nic (unsurprisingly) but here I do have
to chime in that in the icky, grotty real world you often have to deal
with really poor technology choices that were made before you showed
up. Forget about the java threads, in a common configuration you have
to worry about the netscape or apache processes that are feeding
requests to your servlet engine.
I can say for a dead cold certainty that under NES 3.4 with JRun
and JDK 1.1.6 if you have a lot of servlet requests hanging around
waiting for something time-consuming to come back with an answer you
are *not* going to like what happens to your web server (browser
requests timing out without response).
What's the answer? I don't know. In the example above it didn't
really matter what the immediate answer was, so I could cheat and just
fork off a thread to complete the request while the servelt invocation
immediately returned a page to the user's browser. Maybe that points
to the real answer - that the real world is messy and uncooperative,
and no network is reliable, and you have to take that into account in
your application design and in what expectations you set with the
users.
Steven J. Owens
[EMAIL PROTECTED]
___________________________________________________________________________
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
