tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chetan Chheda <>
Subject Re: Tomcat not closing threads -- SOLVED ??
Date Tue, 26 May 2009 19:46:22 GMT
Great thanks! I will test out the alternate method ...

What I meant when I asked about gif files and tomcat was basically is it an expensive transaction
for tomcat ajp13 vs apache vs tomcat's http connector? I guess in other words I am trying
to assess the impact my proposed changes in our environment. 

From: André Warnier <>
To: Tomcat Users List <>
Sent: Tuesday, May 26, 2009 3:20:06 PM
Subject: Re: Tomcat not closing threads -- SOLVED ??

André Warnier wrote:
> Chetan Chheda wrote:
>> After some digging thru config files setup by the vendor, I think I might have found
the root cause ..Correlating the access_log and tomcat logs, I found out that tomcat threads
were shooting up whenever a large number of GIF files were being requested.
>> These are the modjk settings in our application config files that are included in
httpd.conf JkMount /LCSW/* ajp13  JkMount /LCSW/*.jsp ajp13
>> JkMount /LCSW/*.jsp/* ajp13
> The above seems totally redundant to me.  The first JkMount will "capture" anything
starting with /LCSW/, no ?
> If yes, then the following two are totally redundant.
>>  So when an image is accessed via the following URL, http://blahbhal/LCSW/images/header.gif
, the above routes were sending it to tomcat. I verified this by shutting down tomcat and
accessing the above URL, and was unsuccessful.
>>  Now I plan to add the following excludes JkUnMount /*.htm ajp13
>> JkUnMount /*.html ajp13
>> JkUnMount /*.png ajp13
>> JkUnMount /*.gif ajp13
>> JkUnMount /*.jpg ajp13
> That will work.
>> I tested the above in a test environment and was able to access a gif file with tomcat
>> my question is, how does the ajp13 connector interpret a gif file/static content
request as opposed to a jsp request?
> As far as I know, it does not see the difference, nor care about it.  It only takes
into account the match/unmatch of the request URL.  It has no idea of what "static" or "dynamic"
content is.
> Separately :
> For the kind of thing you are doing above, there exists an alternative syntax to the
JkMount/JkUnMount pair, which I personally prefer because I find that it better "fits" in
the Apache configuration logic.
> Here is an example :
> <Location /LCSW>
>  SetHandler jakarta-servlet
>  SetEnvIf REQUEST_URI \.(html?|png|gif|jpg)$ no-jk
>  ...
> </Location>
> (You can of course easily insert other Apache statements inside the same Location block,
for example authentication etc..
> You find this toward the end of this documentation page :
> The "SetHandler jakarta-servlet" does essentially the same as the JkMount, for everything
that fits under /LCSW.
> The SetEnvIf then selectively sets the Apache environment variable "no-jk" (here, whenever
the request URI ends in one of the listed extensions).
> The mod_jk module is always called (because it is the content handler for this section),
but it declines to process this URL because the no-jk variable is set.
> Apache thus processes the request with its own default handler, which serves the content.
> To see exactly what happens, step by step, set the JkLogLevel to "debug", make a request,
and look at the jk logfile.
Erratum :
<Location /LCSW>
<Location /LCSW/>
in the above. Otherwise, it would also match /LCSW1/ for instance.

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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message