Remy Maucherat wrote:
On 4/3/06, Rajeev Jha <[EMAIL PROTECTED]> wrote:
Tp wrote:
And there seems to be no workaround, because the connection will close
after the doGet() and doPost() method finishes (is that actually
true?). So, the only way to keep 3000 simultaneous connections is to
keep 3000 of those methods from returning, wehich means keeping 3000
threads busy.
You can try jetty 6 also [ if you are not very particular about using
tomcat ] . Jetty 6 Continuations can help you do a suspend/resume of
request. so a thread is not blocked due to idle wait and you can
multiplex more connections on less threads.
The hype friendly "continuation" name has no business being associated
with this particular feature, since the said feature is not
continuations (which is a fancy - and IMO forward thinking and
actually useful - programming model for implementing the often seen
multiple HTML form "wizard" style process - and of course, which is
going to use one HTTP request per form, as usual), and is also quite
useless.
That is true. This is not "continuation" as defined in for programming
languages/compilers. on encountering the suspend() for first time, an
exception is percolated up and the request is queued in the server. when
you call resume(), the request is re-tried. So it is not even
suspend()/resume() when you think about it. Maybe it should be re-named
OneMoreRetryQueue ;o)
The real problem, and the actually useful capability (especially for a
big chat room like is the case here), is to be able to output data
asynchronously (= without polling).
we have netscape NPE servers that can suspend/resumes the requests
using an async controller. But all the magic is in native code.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
