tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rajeev Jha <>
Subject Re: Rephrased: Maximum number of simultaneous HTTP connections
Date Mon, 03 Apr 2006 17:06:39 GMT
Remy Maucherat wrote:

>On 4/3/06, Rajeev Jha <> 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
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:
For additional commands, e-mail:

View raw message