tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tp ...@weboperations.com>
Subject Re: Rephrased: Maximum number of simultaneous HTTP connections
Date Mon, 03 Apr 2006 11:19:50 GMT
Remy Maucherat schrieb:
> On 4/3/06, Rajeev Jha <jha.rajeev@gmail.com> 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.

What do you mean exactly by this? I guess I'm not familiar with the the 
topic, maybe you can elaborate a little more on this or point me to 
another thread about this topic.

> 
> If all you need is to reinvoke the service method once there's more
> input data available, you can just as easily use multiple small
> requests (over a kept alive connection), which is equally cheap in
> terms of processing and allows not breaking the HTTP and Servlet API
> designs.
> 

Well, first I hoped, that it is possible to leave the doGet() and 
doPost() method without the HTTP connection being closed. If that would 
be possible, then I could keep the HttpResponse and write to it, 
whenever there is new data available.

That is actually the real challenge and that's what my question is about 
partly. However, once the methods finish, the http connections get 
closed and I there is no way of preventing this. So, I have to keep the 
thread busy, which handles the doGet() or doPost() method in order for 
the connecton to stay alive.

That's the whole problem. So that's why the Jetty solutions sounds 
interesting, as it seems to be possible to leave the doGet() or doPost() 
method, without the http connection being closed. If I undestood correclty?!

> 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).
> 

This is not the real problem. You can use Object.wait() and 
Object.notifyAll() to signal, when new data is available and then sent 
it over the HTTP conneciton, if you can't multiplex. If there would be a 
single thread I would just run through a loop and always dispatch new 
messages, if there are any in the queue.

> --
> xxxxxxxxxxxxxxxxxxxxxxxxx
> Rémy Maucherat
> Developer & Consultant
> JBoss Inc
> xxxxxxxxxxxxxxxxxxxxxxxxx
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message