Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
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
future.
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 :
http://en.wikipedia.org/wiki/IP_over_Avian_Carriers
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
