Gokul Singh wrote:
>
> So once again it is up to the servlet writers to write appropriate code and
> not the responsibility of the framework to ensure that what they code is up
> to the mark!!
>
Right, and for some deployment scenarios this is a
bad thing. If, for example, an ISP wanted to allow its
users to have servlets as well as cgi scripts, you'd
need some way to ensure that the servlets did not
endlessly use up resources.
You can't do that now. A hostile (or poorly written)
servlet can grab resources and there's no way to make it
give them back without shutting down the entire container.
The ISP deployment scenario is sort of a worst case
for servlets, because it asks a Java app to act as a
mini-operating system, and it's not really up to that
quite yet.
> In my understanding of this, the thread pools used in the well designed
> servlet containers ( I have seen paperclips source) are dynamic in size and
> if such a blocking is observed, new threads will be created on the fly.
Thread pools are designed not only for efficiency,
but as a resource control measure. In some cases, you
don't _want_ to keep giving out threads as the load
increases. It depends heavily on the situation.
> Nic Ferrier wrote:
> Threads are quite lightweight objects (even when they're implemented
> as system level threads) and so it is possible to handle quoite large
> loads without pools.
>
Threads are fairly heavyweight objects, at least they're
heavyweight enough that the "thread-per-socket" architecture
is an impediment to writing high-load servers in Java.
> One day (and soon I imagine) thread pools will be made irrelevant by
> better thread implementations. For example something we have talked
> about with Kaffe is the VM providing a green threads implementation
> that used an internal pool of established pthreads.
>
Solaris already does this internally. It's hard to do right,
and doesn't solve the basic problem, which is that a thread
has a certain weight to it no matter what you do, and using
them everywhere gets expensive. Ref the endless non-blocking
i/o discussions...
-cks
___________________________________________________________________________
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
