tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tp>
Subject Re: Rephrased: Maximum number of simultaneous HTTP connections
Date Mon, 03 Apr 2006 12:55:57 GMT
Remy Maucherat schrieb:
> On 4/3/06, Tp <> wrote:
>>>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
>>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.
> There's no topic here, obviously, as Tomcat did not introduce the term
> "continuation". As I said, this was introduced to qualify a new
> programming model for wizard style processes that are often seen in
> web applications (registration, checkout, etc).
> You definitely need to think about this topic more, as the thread
> handling is very important for your application.
>>>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
>>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.
> The HTTP connection is kept alive during a predefined time (the socket
> timeout) between requests. You then need to use a Tomcat connector
> that doesn't use a thread to handle each connection during keepalives
> (such as the HTTP APR connector). 

You are right.

> This will mean all your clients will
> rely on frequent polling to get the new posts of you chat room, which
> is going to cause a fairly large load on your server.

Well, I don't know what you understand under polling. I guess you mean 
the clients will have to sent GET and POST requests repeately, right?

The load is going to be even higher with polling. That's I would not 
introduce any polling. How would I do this anyway, if I only use HTML?

My idea was opening a connection and then just let the client wait and 
sit there. Whenever I get new messages, then I will sent them over.

Here a diagram:

Client sends GET -> Server
Server sends HEADERS (Content Encoding: Chunked) -> Client
Server sends chunks -> Client
Client displays them whenever they arrive.

>>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.
> I don't understand why the connections will be closed (unless, say,
> the client is asking for the connection to be closed after the
> request), since it is not the default HTTP/1.1 behavior. You should
> investigate that.

Well actually you caught me here. You are right. I mean I have tested it 
and after the doGet() and doPost() methods returned the connection was 
closed. But you are absolutely right, that this can't be a general 
policy and indeed depends on the keepalive timeout. So I have to check 
this out, it could actually be the solutions for my problem at least 
when it comes to saving the threads for each conneciton.

I could just remember the HttpRespone Objects and use one thread, which 
gets, when new messages arrive in the queue. The thread then could 
println() them to all he HttpRespones. This would save me all the 
Threads. Hmm, sounds good, or have I missed somthing?!

>>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.
> Yes, but you need the 5000 or so threads to do this, and there's no
> workaround. So it is the real problem since it forces you to use
> polling.

What do you mean with polling? I mean none of the threads is polling 
using this method, or? For example 5000 Threads would be waiting. Then a 
message arrives and all of them get notified and then they sent the 
message to the clients. So I don't see where polling comes in?!

> --
> xxxxxxxxxxxxxxxxxxxxxxxxx
> Rémy Maucherat
> Developer & Consultant
> JBoss Inc
> xxxxxxxxxxxxxxxxxxxxxxxxx
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message