Nic Ferrier <[EMAIL PROTECTED]>
> >>> Garth Somerville <[EMAIL PROTECTED]>
> >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!
>
> What VM are you using?
Green threads can create a whole separate set of problems for some programs.
But even though green threads could theoretically solve the problem we
raised, we can solve it a whole lot better by the way we write our programs.
> Well... I'm the architecht for a servlet based webmail service, we
> use SunOS to host (principally because of the excellent threading). We
> have never had a problem with performance, indeed for a long time we
> ran the service using the Sun reference VM. We have >3m subscribers.
>
> So what levels of performance are a problem? because I haven't hit
> them yet...
Are you suggesting that because your application is running just fine that
there are no applications that could benefit from an asynchronous
programming model? Whether the problem we are describing is real or not is
very easy to prove or disprove by starting with a servlet that requires
substantial time to service requests (on the order of seconds) and then
determining the accept rate of the server as a function of connection load,
the maximum possible number of connected clients, and the behavior of the
server at the limits. I think people might be surprised if they tried this;
certainly the end-to-end Java servers will get into trouble very quickly.
>From the replies that Dave received to his original post, it seems there was
a three-step answer given to the concern he raised. First, that there is no
problem or that any perceived problem can be solved by the existing
programming model; secondly that there is nothing to worry about because the
VM can create several thousand threads; and thirdly, should that turn out to
be a problem, then a VM that implements green threads that look and act
exactly like real threads but are not really threads at all could solve the
problem. But such a VM does not exist. Where does that leave us if we want
our web-apps to support large numbers of connected clients?
> On my own side note IMHO one of the problems here seems to be the
> idea that Java is portable C. It isn't. It's an environment that has
> inherited some of C's syntax and there the similarity ends.
I don't think this is a fair dismissal of our concern. Sun has heavily
promoted Java as a server side solution. Customers and marketing people
have bought into this. The companies we work for have told us to rewrite
our server applications in Java. As developers we have found we really like
Java and now we want to follow through with the promise. I don't think we
are asking for Java to be not-Java, we are suggesting that certain APIs
would be improved if they supported an asynchronous programming model.
> The VM design of Java is supposed to achieve a separation of
> responsibilities. It is for VM designers to provide good threading
> implementations that allow us to write code that performs as well as
> it can.
Java already provides a reasonably good implementation of threads. The
position you seem to be advocating is asking for it to do a whole lot more
than that though, namely that the VM should be additionally responsible for
completely hiding and overcoming the reality that threads are a limited and
expensive resource on virtually every supported platform. The problem is
that VMs cannot do that. I think it reasonable to conclude that the
introduction of async IO in 1.4 is evidence that Sun does not intend for
Java to meet that requirement.
> I do agree that we must have some way to express async IO but I don't
> agree we need to change the thread model for servlets in any way, and
> certainly not to improve performance.
Performance is the overriding reason for introducing async IO, why then is
"performance" an unacceptable requirement for servlets? These two problems
are exactly analogous -- when it comes to sockets Java requires a thread per
socket to pend a read on the socket, when it comes to servlets the APIs
require a thread per connection to process requests on that connection. In
both cases the restriction severely limits the number of simultaneous
clients that can be serviced. In both cases the restriction is arbitrary,
artificial, and unnecessary (though certainly convenient for programmers
whose requirements do not exceed the capabilities of the model).
The async IO APIs by no means preclude a programmer from using
java.net.Socket as usual. Similarly, Dave and I have both been clear that
we do not want to change the existing model in which returning from
service() indicates completed processing of the request. We are suggesting
an extension that would allow those who need it to create high-performance
web apps. IMHO, I don't yet understand the argument against it or the
apparent resistance to the suggestion.
-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
