You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by André Warnier <aw...@ice-sa.com> on 2013/03/21 12:15:34 UTC

Re: [a bit, but not totally OT] Tomcat Behavior on Multiple HTTP requests from same browser

Christopher,

Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> André,
> 
> On 3/20/13 2:25 PM, André Warnier wrote:
>> Saurabh Agrawal wrote:
>>> All our assets are served from L3 CDN. So the asset requests
>>> never come to the application server.
>> That, I do not understand. I do not understand what you mean by
>> "assets" here, and I do not understand "L3 CDN". So I cannot tell
>> of this is relevant or not to the problem.
> 
> CDN = Content Delivery Network. I'm not sure what "L3" (probably
> "Level 3", a data center operations company) is, but a CDN is
> basically a whole bunch of copies of your files geographically
> distributed such that requesting a file always gets the bits that are
> closest to you. Kind of a cool thing. ;)
> 

Thank your for the above Rosetta Stone.  This computer business os so full of acronyms of 
all kinds - some of them with multiple interpretations - that it is sometimes difficult to 
grasp the meaning.  And I really don't feel like having to use Wikipedia every 3 words of 
a post on the list.  Not when "static content is delivered by the Apache front-end" would 
have done it.

> The bottom line is that Saurabh expects only dynamic requests to come
> to Tomcat, so keepalives should be much less useful than if Tomcat
> were to be serving everything. Imagine httpd out front serving all
> static content and forwarding dynamic stuff to Tomcat via AJP --
> that's almost exactly what's going on here, except that the static
> stuff is being served very efficiently from a network-topology
> perspective.
> 
> Since AJP is in use, keepalive is almost entirely a red herring as
> typical AJP connections are permanently-connected to the web server.
>

Well, I would say so indeed forthe case of a html page wit embedded images e.g.
Butit may not be so in the "benchmark" case that Saurabh explained, with each of the 10000 
clients making multiple requests to non-static content, presumably served by Tomcat.
A human user may have delays, that his testcase might not have.

>> So, by default, the keepAliveTimeout [for AJP] is set to
>> "infinite".
>>
>> [snip]
>>
>> And if the client keeps the connection open, but does not send any 
>> additional request on that connection, the Thread will wait 
>> theoretically forever (because that is what the documentation says
>> about the default value of these parameters).
> 
> No, the defaults are different for non-AJP connections. Tomcat's
> default default is 60 seconds but the stock server.xml configures it
> to 20 seconds.

Right.  But my explanation was meant as an example only, to point out the interlinked 
effects of the various attributes and timeouts.
And 20 seconds is still an incredibly long time, in the context of 10000 "simultaneous" 
clients sending multiple requests each.

> 
>> Now your case is a bit different, because - you are not using the
>> HTTP BIO connector (you use AJP)
> 
> I think you've gotten yourself confused, here, unfortunately. You can
> use AJP with BIO, NIO, or APR (maybe you mixed-up AJP and APR between
> your eyes and your brain... the two are honestly too close to each
> other and it is very easy to do that).

Yes, I was confused and thank you for making me see the light.  I though that the AJP 
Connector was a beast all of it's own, and did not "use" these different underlying 
layers.  It is clear fom the documentation that it does though, I don't know how I could 
have overlooked that for so long.

> 
> He is in fact using the BIO connector because he has specified
> protocol="org.apache.coyote.ajp.AjpProtocol".
> 
>> - in front of your Tomcat, is an Apache httpd server.  This server
>> has its own keep-alive settings which apply to the connection of
>> the client with Apache httpd.  And these keep-alive settings are a
>> bit different from the Tomcat ones (for example, there is a
>> keep-alive timeout, but also a MaxKeepAliveRequests)
> 
> +1
> 
>> - between Apache httpd and Tomcat, there is the mod_jk module in
>> Apache, and that module uses its own timeouts (as set in
>> workers.properties), and in addition it uses itself a pool of
>> connections to Tomcat, and this pool of connections has its own
>> rules for keeping alive a connection between Apache and Tomcat.
>>
>> But the basic principles above apply, and may explain why you are
>> seeing what appears to be one Thread dedicated to one client,
>> forever.
> 
> 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.
But what I am not so sure of (and maybe Rainer could comment here) is this scenario :
- a client, via httpd+mod_jk, sends a single request to tomcat on a keep-alive connection, 
and receives a response.  Now the client does not send another request anymore on the same 
connection, but keeps it open "just in case".
Now say that at the client/httpd level, the keep-alive timeout is set to 30 seconds; and 
say that on the Tomcat AJP connector, the keep-alive timeout is set for 20 seconds.
What really happens ?
After this first request, Apache httpd would have to keep the client/httpd connection 
alive for 30 seconds, right ?  At the Apache-httpd level, that means that this "Apache 
child" process keeps its connection to the client open, and sits there waiting for another 
request.  Mod_jk is not a separate animal; it is an Apache module, so it is code 
"embedded" in this one Apache-httpd child process.
So what does mod_jk really do ? he needed one connection to Tomcat, to send the first 
request and get the response, so he got it from the pool of connections.
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 ?
And assuming for a moment that it keeps this handle to himself for a while, what does that 
mean at the Tomcat level ? is a Tomcat Thread also waiting on that same httpd/tomcat 
connection (at least for 20 seconds) ? or do Tomcat Threads *always* go back to the pool 
after serving one request ? or does it depend, and on what ?

There is also kind of a weird question here : what is really the purpose of the 
keepAliveTimeout attribute on the Tomcat AJP Connector ? I mean, connections to that 
Connector always come from some front-end module (be it mod_jk, mod_proxy_ajp or the 
isapi_redirector).  (It is very unlikely that they would come from some independent 
AJP-capable client).
Why would the AJP Connector need its own keepAliveTimeout attribute, if these front-end 
modules are themselves managing their connections to Tomcat, in the way that they deem 
appropriate ?
These front-end modules could pass to Tomcat the timeout that /they/ want, when they open 
their individual pool connections to Tomcat, right?
Isn't that Connector keepAliveTimeout then more confusing than really useful ?
(And I guess that the same could be said for the connectionTimeout).

Come to think of it, that is probably why, in the case of the AJP Connector, the defaults 
are "infinite". And maybe the attributes are left accessible for the rare edge cases where 
they could prove useful.
If so, then I guess that a small note in the documentation would be useful.


(*) 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. And Microsoft has its own take on 
this, as for instance for Windows Integrated Authentication purposes, it is the 
*connection* which is authenticated, and each time the connection changes, the client has 
to re-authenticate.  So the practice is a bit less connection-less than the theory.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: [a bit, but not totally OT] Tomcat Behavior on Multiple HTTP requests from same browser

Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
On Fri, Mar 22, 2013 at 10:04 AM, Jeffrey Janner <
Jeffrey.Janner@polydyne.com> wrote:

> > -----Original Message-----
> > From: André Warnier [mailto:aw@ice-sa.com]
> > Sent: Thursday, March 21, 2013 8:51 AM
> > To: Tomcat Users List
> > Subject: Re: [a bit, but not totally OT] Tomcat Behavior on Multiple
> > HTTP requests from same browser
> >
> > Christopher Schultz wrote:
> > > 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 ?
> >
>
> Or swallows and coconuts.
>
> Jeff
> (sorry, couldn't resist.)
>
>
Wow, you all are funny! LOL

Re: [totally OT] Tomcat Behavior on Multiple HTTP requests from same browser

Posted by Mark Eggers <it...@yahoo.com>.
On 3/22/2013 9:35 AM, André Warnier wrote:
> Caldarale, Charles R wrote:
>>> From: Jeffrey Janner [mailto:Jeffrey.Janner@PolyDyne.com] Subject:
>>> RE: [a bit, but not totally OT] Tomcat Behavior on Multiple HTTP
>>> requests from same browser
>>
>>>> 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 ?
>>
>>> Or swallows and coconuts.
>>
>> Someone had to bring that up.  African or European?
>>
>> I think we can remove the "not" from the subject line now...
>>
> Done.
> This all reminds me of this (locally) well-known Belgian bird : the
> oye-oye-oye bird.
> For those who don't know the species :
> It is a very strong, sturdy bird. Rather bad-tempered too, you shouldn't
> mess with it.
> It is a bit the bird-equivalent of the Belgian horse really.
> It has a big round head, with a strong beak, say oh a good 5 inches wide
> and 7 inches long.  A really strong beak, he can crush nuts or bones
> with it.
> Then it has very strong wings too, strong enough to lift a small sheep
> for instance (or a bowling ball for that matter).
> And tough feathers, you can make brooms with them.
> And also rather short, but very strong sturdy legs; like 2 inches thick
> and 2 inches long.
> And then its balls, no kidding, they are the size of coconuts.
> And each time it lands, it goes "oye oye oye".

Sounds very much like the African oomy-goomie bird.

There's a rugby song about that - something about going off to see a 
wild west show . . . elephants and kangaroos.

Looks like at least one subspecies migrated north.

/mde/


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: [totally OT] Tomcat Behavior on Multiple HTTP requests from same browser

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

André,

On 3/22/13 12:35 PM, André Warnier wrote:
> Caldarale, Charles R wrote:
>>> From: Jeffrey Janner [mailto:Jeffrey.Janner@PolyDyne.com]
>>> Subject: RE: [a bit, but not totally OT] Tomcat Behavior on
>>> Multiple HTTP requests from same browser
>> 
>>>> 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 ?
>> 
>>> Or swallows and coconuts.
>> 
>> Someone had to bring that up.  African or European?
>> 
>> I think we can remove the "not" from the subject line now...
>> 
> Done. This all reminds me of this (locally) well-known Belgian bird
> : the oye-oye-oye bird. For those who don't know the species : It
> is a very strong, sturdy bird. Rather bad-tempered too, you
> shouldn't mess with it. It is a bit the bird-equivalent of the
> Belgian horse really. It has a big round head, with a strong beak,
> say oh a good 5 inches wide and 7 inches long.  A really strong
> beak, he can crush nuts or bones with it. Then it has very strong
> wings too, strong enough to lift a small sheep for instance (or a
> bowling ball for that matter). And tough feathers, you can make
> brooms with them. And also rather short, but very strong sturdy
> legs; like 2 inches thick and 2 inches long. And then its balls, no
> kidding, they are the size of coconuts. And each time it lands, it
> goes "oye oye oye".

That sounds absolutely terrifying. A 7-inch-long beak that's 5-inches
wide? That's like an oil tunnel for a car.

I don't even want to hear about the Belgian Horse...

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

iQIcBAEBCAAGBQJRTNzSAAoJEBzwKT+lPKRY79EP/0xwu/G4cTHvKoJldQRdFYUX
cT9vBgr/xrdkNuV8gO/+cwBhiAGVAw2LOtkT6aF85zdv0Da6PALk6DOrvx4PLcnz
KVAGG2mp6KHngISB09ti1I/QycNfKFQUkA3ogHFB8N3LDxQoTc1ZfbcWm1+UcRYu
BMvXrzAcAapx0ZKYP4ZId7Z9vtIyB5mpGmCXu88x0bJs+D/shzLTPGiE7tYzZfpi
R/VJhE4TezajaRFvnCNLLooeHAGEx3qJ/FNLaynr1QB8X7QRhOomulr5tR4n5+Za
ELoGLkeIfcYCrXiSDANJAEGrLUf5/4ub/yZqPhXuL2dgSI5FvI4+Np7PfscfJ0xi
BtTZ8JYB6I0FQfJqRHnB0krpvnBhncmnyqdk+OKuxoSqYeHabaX8PlqGMQu6mlpR
ay71I8qrHYsBvOjTF+rexstcNEkzWeEON06Q+AzlWElp/NAyI+OT6lpHXAew7A5e
wX8RcVU7/5vC14RnpUVwaA4OSvqQpMH29hk9n0s5rEjR8zro+fm5ZFUCHxsg6j51
Xmgq0AwENY2hm6EVducDs2aFUK1n1xoz0z09Vc9Jb9dIiXuz0DgPW/Ls7YcoiRce
kh04Jn+M8oQl1nZsteb3egXasExm/S8EoCg/HrFpenLje30z+riW7mBPRpwx4v5p
WenLW/6m51hgZNpuccxx
=QmXY
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: [totally OT] Tomcat Behavior on Multiple HTTP requests from same browser

Posted by André Warnier <aw...@ice-sa.com>.
Caldarale, Charles R wrote:
>> From: Jeffrey Janner [mailto:Jeffrey.Janner@PolyDyne.com] 
>> Subject: RE: [a bit, but not totally OT] Tomcat Behavior on Multiple HTTP requests from same browser
> 
>>> 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 ?
> 
>> Or swallows and coconuts.
> 
> Someone had to bring that up.  African or European?
> 
> I think we can remove the "not" from the subject line now...
> 
Done.
This all reminds me of this (locally) well-known Belgian bird : the oye-oye-oye bird.
For those who don't know the species :
It is a very strong, sturdy bird. Rather bad-tempered too, you shouldn't mess with it.
It is a bit the bird-equivalent of the Belgian horse really.
It has a big round head, with a strong beak, say oh a good 5 inches wide and 7 inches 
long.  A really strong beak, he can crush nuts or bones with it.
Then it has very strong wings too, strong enough to lift a small sheep for instance (or a 
bowling ball for that matter).
And tough feathers, you can make brooms with them.
And also rather short, but very strong sturdy legs; like 2 inches thick and 2 inches long.
And then its balls, no kidding, they are the size of coconuts.
And each time it lands, it goes "oye oye oye".


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


RE: [totally OT] Tomcat Behavior on Multiple HTTP requests from same browser

Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Christopher Schultz [mailto:chris@christopherschultz.net] 
> Subject: Re: [totally OT] Tomcat Behavior on Multiple HTTP requests from same browser
 
> > > Or swallows and coconuts.

> > Someone had to bring that up.  African or European?

> > I think we can remove the "not" from the subject line now...

> I think someone gets thrown off a bridge into an abyss if we keep
> going. The Spring Generation probably doesn't have any idea what we're
> tottering on about.

The rules say the Spring Generation goes over if they can't answer the questions...

Auuuuuuuugh.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: [totally OT] Tomcat Behavior on Multiple HTTP requests from same browser

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Chuck,

On 3/22/13 10:25 AM, Caldarale, Charles R wrote:
>> From: Jeffrey Janner [mailto:Jeffrey.Janner@PolyDyne.com] 
>> Subject: RE: [a bit, but not totally OT] Tomcat Behavior on
>> Multiple HTTP requests from same browser
> 
>>> 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 ?
> 
>> Or swallows and coconuts.
> 
> Someone had to bring that up.  African or European?
> 
> I think we can remove the "not" from the subject line now...

I think someone gets thrown off a bridge into an abyss if we keep
going. The Spring Generation probably doesn't have any idea what we're
tottering on about.

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

iQIcBAEBCAAGBQJRTNxAAAoJEBzwKT+lPKRY3koQAIkmmGnn4SA1u1VeLkU8ZAre
8YWDktOOvf6J0xJQl8iRajoV2ZZT0EjoHSO9ODopS7BiYRcbuCfLROXaIYLSD/PR
nLiporwrtehxW7yTHxtpM3P599E/Gr2vvLhw3/9Wl7BcM1exnQrsDkmTa3bLEIxT
XvUaisgwhDquCyfFyPxV5fy46Fn128fyHa6E4ZUaeRGYYH4hcwkAJRc7lM1TaX+y
BOmNr0jR60Z2KfSMEWeXR2J4FpYoFUrkS3KDRWi7RruZp28BR7MPLX/49inioy3K
a+K7lgus9s6p0QySBREDEpi2oCXEO31m2gRYQ4O7iXOoKaKcOkMS7Vx2hKkbO2eq
unJ/pcjkTWYXVx5oahbi9VEOSf3PiXGV3xYA/JFFbG/xYkKeVReofTmCoeHIfVTh
H9GKbzGR0jQAWUkZpnuMumg+Dbra6/J3+Nau/ItDy5kQ1e1xIbLyYswEbzTjxnHa
0wNkQkfID/IfOpz9mnM5wkowE8cDrqVFO3YkWDzYo5GsIliGT8o6NapTf7y8ll1D
rVyVhPfMUJWMjq6QlJRcPJE3EuluOtRP+73UejZmqssL/V2RJCH+5f2sbBipB1gW
X+VwBRVuD0qCGgniDIrXYjLZqTKsp+Y/9d38H1SgZgdTdIOPtqMVJ8IwU1uYopTa
L2rZsjHHYmB7+eYyzvMf
=Ttie
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


RE: [a bit, but not totally OT] Tomcat Behavior on Multiple HTTP requests from same browser

Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Jeffrey Janner [mailto:Jeffrey.Janner@PolyDyne.com] 
> Subject: RE: [a bit, but not totally OT] Tomcat Behavior on Multiple HTTP requests from same browser

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

> Or swallows and coconuts.

Someone had to bring that up.  African or European?

I think we can remove the "not" from the subject line now...

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


RE: [a bit, but not totally OT] Tomcat Behavior on Multiple HTTP requests from same browser

Posted by Jeffrey Janner <Je...@PolyDyne.com>.
> -----Original Message-----
> From: André Warnier [mailto:aw@ice-sa.com]
> Sent: Thursday, March 21, 2013 8:51 AM
> To: Tomcat Users List
> Subject: Re: [a bit, but not totally OT] Tomcat Behavior on Multiple
> HTTP requests from same browser
> 
> Christopher Schultz wrote:
> > 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 ?
> 

Or swallows and coconuts.

Jeff
(sorry, couldn't resist.)

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: [a bit, but not totally OT] Tomcat Behavior on Multiple HTTP requests from same browser

Posted by André Warnier <aw...@ice-sa.com>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: [a bit, but not totally OT] Tomcat Behavior on Multiple HTTP requests from same browser

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org