Nic wrote:
> >>> Dave Brosius <[EMAIL PROTECTED]> 05/03/01 17:03:53 >>>
>
> >Let's suppose my servlet writes requests to
> >a javaspace, and then reads responses from
> >that javaspace, Further let's suppose that this
> >turn around takes 5 seconds. Let's say I have
> >50 threads in the Servlet container. And I get 500
> >simultaneous requests (< 1 second).
>
> But that's not how containers work, the container will grow the
> thread pool to the size needed. As new requests come in there will be
> new threads.
We have discussed this before on the advanced servlets list, and
I believe that Dave's concerns are legitimate and accurate. The
servlet specification requires a thread-per-client model which is widely
known
to be expensive and inefficient. There is no way around that. This
situation is closely analogous to the problem caused by the omission of
select() from the Java socket APIs
which has made it plainly impossible to write a high performance server
in pure Java (i.e. one that can handle the "thundering herd" problem).
This flaw in Java shouldl be solved by the asynchronous IO that will be
part of 1.4. In the meantime the container can solve it's own
thread-per-client
problem at the network layer by using JNI and a thread pool. But it cannot
get around the issue that Dave is raising of a servlet that is waiting on
something
else and has no way to release the now-blocked thread used to call
service().
On most platforms you cannot expect to keep creating new threads for very
long until everything grinds to a halt. If anyone is planning to deploy a
pure Java servlet runner they would be well advised to investigate the
performance characteristics of the container in the face of large numbers of
connected clients.
IMHO, it would be well worth it for the committee to just spend some time
thinking about an addition to servlets along the lines of specifying a
return code from service() (or more likely a new method) which could be used
to indicate either that the request has been completed or that the request
is in progress and the servlet will complete it later. In this case the
request and response objects would remain useable by the servlet until it
closes the response indicating the response is complete. I am pretty sure
this could be done while maintaining full backward compatibility with
existing servlets. New servlets could choose between the synchronous and
asynchronous processing models. There is a very good reason why ISAPI DLLs
have this same capability.
> 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.
You are right that a very good implementation of green threads could solve
the
problem and restore Java's thread ideology. Let me know when you find it!
Sun tried
to do something admirable with Java by leaving out select() which was to
simply the programming model. However it has not worked out in practice and
we need to move forward with the APIs and constructs that will allow us to
write high performance servers in Java.
-Garth
___________________________________________________________________________
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
