>>> Garth Somerville <[EMAIL PROTECTED]>
>Are you suggesting that because your application
>is running just fine that there are no applications that
>could benefit from an asynchronous programming
>model?
My app is a big complex app servicing a *lot* of concurrent
connections. What I'm trying to say is "Servlets can handle this
without creaking... what is it you're doing that's breaking the
model?"
This webmail app uses LDAP to store registry info and IMAP to store
mail. That's (conceptually) two remote connections for every HTTP
request. Yet it scales. And these are the sorts of app you are saying
are a problem.
>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.
This is a little unfair. I read Dave's first post and didn't respond
because I mistook him for a newbie. Perhaps Pier did too... I think
most of us expect this to be a newbie forum, not a forum where thread
models are discussed in intimate detail /8->
>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?
But I (and many others here and on advanced-servlets) have designed
webapps with large numbers of connected clients.
As Pier said in response to Dave the other day: What is the specific
problem you're having? If we talk about things in terms of specific
design issues then those of us who have worked on and with the API for
a long time might be able to point you in the right direction or might
suddenly see the light of what you're saying. But otherwise we tend to
descend into religion.
>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.
That's not what I'm saying. VMs can provide such thead
implementations but I don't beleive that every VM should or can.
Java isn't about complete portability, it never can be, it's about
code portability. To be facetious for a moment I wouldn't expect to
run my webmail service on Windows 95 boxes. The OS couldn't handle it.
Java is an environment that provides certain abstractions that make
writing programs easier than it might be in other languages. But the
specific implementation of the envionment that you choose makes the
difference to how your app runs. That choice of VM and the platform it
runs on has to be part of the design decision.
>Performance is the overriding reason for
>introducing async IO, why then is "performance"
>an unacceptable requirement for servlets?
It's not. But I'm not seeing any container performance issues that
could be solved by async IO.
>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.
As I say, my webmail system requires 2 sockets (one for LDAP and one
for IMAP) for each user logged into the system. In addition IMAP is
impossible to pool so we have to make and break connections all the
time. It scales.
>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.
My resistance (in part) is due to the fact that I haven't seen a
proper proposal.
If you feel really strongly that the API design team is ignoring
async then join the JSR and put your point across.
Nic
___________________________________________________________________________
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
