tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Remy Maucherat" <>
Subject Re: Rephrased: Maximum number of simultaneous HTTP connections
Date Mon, 03 Apr 2006 11:41:04 GMT
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
> > 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.

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

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

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

> 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

Rémy Maucherat
Developer & Consultant
JBoss Inc

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

View raw message