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 13:21:35 GMT
On 4/3/06, Tp <> wrote:
> 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.

Of course. It's the problem I was describing. The only way to do it
using the Servlet model is to keep the service method running forever,
since the Servlet API doesn't allow the server to write data
asynchronously in response to certain events.

It is actually the SIP Servlets model (which is why I mentioned it earlier).

> 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?!

At this point, this has nothing to do with a Servlet. I know it won't
work in Tomcat.

> > 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?!

Right. I said you need to use polling, or use 5000 threads (which is
not a problem if you have enough memory).

Rémy Maucherat
Developer & Consultant
JBoss Inc

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

View raw message