-----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. > 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. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRSwfNAAoJEBzwKT+lPKRYAMgQAKyONnliLXad6HDwO9raxN+d evcEl8zAeYr6vbevZJ/KJK/FALoFVOmHdMDj+twGEWM+zrIOkHel2y9LHKzxR+St 6Fz1466yDeHM45D/PBcyMow2WaOSR9a6Ewj8uDprJLuVjT20qRlaiw0pQjvfB5M2 rPfX0rEP6NPMQNaTTdaTiq56LP4j/kNMiIhNZyZrq3Gu+9hP/LGEZgKW4j9PDPRF wvNUnWrHwhl4cUJwtRF1CuyynmJmnsrglQWpLgj1cYvBnzHp/19I3CKUevut5JUj NtcCmZ+u/is9zsJbWn6g1yRpyVFNForyV2XF2UFMDm/4UO+Ofyq1lVsGtvkMu3b2 2PQ7vMPqMM34JBySI3ZWVMFxD3GZUMm+Bqc4H5iKIzcGxRg0MgQn5z6DHniuIOmw lUxsjiwHiJ8xF/W3cdN1cxzPPzG92MOp4FWpsnMF+XcAN8ctGr5MuRJzDJKfct1o VcQojNqhmDyBHlJd3188aAz94KUXIGyXkmsLNdvnYhSZLZWxjFwBNxYm/4RzmHeA Dm/Heoe+qpxsk868YGKvJcIAk/1Rdxje8ZEJv44YRNXyCqfDkq0t9HUCduzyNBJF 4H/RVCSSS6OEXvdXUMywS2JJElcss560fSZ1ZF45YSW6NiLMIyl5PjFR1mb0Kfsf YYwN2L9egDE8ZDibeON2 =Bxsy -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
