Thanks for the backup,
On a side note, I completely agree that asynchronous IO is mandatory as
well, although I think that the 'unix' select paradigm isn't very good. It
requires polling of FD sets. Surprisingly, Micro$ofts IOCompletionPort
paradigm, imho, is much better.
Anyway, as you say ISAPI has the asynchronous mode, interestingly enough,
most people don't know of its existance, which is proof that extending the
Servlet API to allow asynchronous behavior shouldn't interfere with the
general populace's comfort level with their 'good ole' Servlet.
-dave
----- Original Message -----
From: "Garth Somerville" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, March 05, 2001 1:43 PM
Subject: Re: Why is servlet API synchronous only?
> 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
>
___________________________________________________________________________
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
