tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: [a bit, but not totally OT] Tomcat Behavior on Multiple HTTP requests from same browser
Date Thu, 21 Mar 2013 13:51:22 GMT
Christopher Schultz wrote:
> Hash: SHA256
> André,
> On 3/21/13 7:15 AM, André Warnier wrote:
>> Christopher Schultz wrote:
>>> I think there might be a problem with the instrumentation, or
>>> just coincidences at a fairly implausible level. The trust of the
>>> matter is that Tomcat does not allocate a thread permanently to a
>>> remote client until ... whenever the client "disconnects"
>>> (whatever that means, as HTTP is a connection-less protocol).
>> (See the nitpick (*) below)
>> Possible, but see above again with the httpd/tomcat connections
>> managed by the mod_jk module.  It does have and manage its own pool
>> of connections, with each connection potentially "staying alive"
>> for a time much longer than any individual client request. I do not
>> deny that.
> Right, but the AJP connections are managed in a connection pool. I
> haven't really checked-into this, but I suspect that two requests
> coming from the same keepalive connection have no guarantee of being
> sent across the same AJP connection to Tomcat, and thus no guarantee
> that they will be served by the same JVM thread.
>> mod_jk is aware that the client/httpd connection is keepalive, and
>> it does not have any way to know that this client is not going to
>> send another request to Tomcat.  So what does mod_jk really do ? 
>> Does it relinquish the one connection that he had to Tomcat back to
>> the pool immediately after the first response has been served ? or
>> does it keep its handle on that pool connection until the
>> client/httpd timeout has expired ?
> It would be a mistake for mod_jk to retain control of the AJP
> connection for that keepalive request -- there's no guarantee that the
> /next/ request across that connection would even be routed through
> mod_jk: it might be for some other resource that another module handles.

On the other hand, if there were 10 successive requests for Tomcat from the same client on

the same connection, then it might be argued that it would be counterproductive to return

the connection to the pool each time, just to go obtain another one right after, and this

10 times in a row.

May be there should be an "adaptative" or "predictive" algorithm here : if this client in

the recent past has always sent several requests in short succession, then maybe I'll keep

this connection for now, just in case he does it again.
I can already hear Rainer saying "patches are always welcome".

But the real point is : does mod_jk keep the connection, or does it return it to the pool

at the end of each response ? Barring Rainer reading this, I guess that only looking at 
the code would tell.

Note that Apache httpd already maintains the client/httpd connection, and keeps a count of

how many requests have been received over this connection. It has to, for 
MaxKeepAliveRequests.  So it would not be too much of a complication for mod_jk to keep 
its own count, of how many requests forwarded to Tomcat have been received over this same

connection.  That would already be a good predictor of whether the same is likely in the 
a = time for which this client connection has been alive
b = number of requests forwarded to tomcat over this connection
c = a / b = average time between 2 requests forwarded to tomcat
if c is lower than the overhead for obtaining and returning a connection from the pool, 
then keep the connection.
It would be self-adaptative, because if the client slows down its request rate, then c 
would become larger, and the connection would be returned to the pool; and vice-versa.

>> There is also kind of a weird question here : what is really the
>> purpose of the keepAliveTimeout attribute on the Tomcat AJP
>> Connector ?
> +1
>> (*) nitpick about HTTP being connection-less : that may be true in
>> the sense that each request+response is supposedly independent from
>> any other request+response.  But HTTP 1.1 explicitly introduces
>> "persistent" TCP connections.
> Yes, and HTTP sessions are standard fare these days, too. But the fact
> is that HTTP itself is connection-less. We as engineers can make it
> feel like it's not and do stupid things like put JDBC connections into
> HttpSession objects and try to tie everything together to make the
> user feel like they have a permanent connection. We can even hold-open
> HTTP connections for long periods of time, but that's really abuse of
> the protocol IMO. You can send bowling balls via carrier pigeon, but
> there are better ways to send bowling balls.

You would need a fairly large, and well-disciplined team of pigeons to do that though. I 
don't think that this was a good metaphor, You should have chosen a bigger bird and/or a 
smaller load. Eagles and tennis balls maybe ?
I should also probably remind you of RFC 1149 :

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

View raw message