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 <aw@ice-sa.com>
To: Tomcat Users List <users@tomcat.apache.org>
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
down.
>> 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 :
> http://tomcat.apache.org/connectors-doc/reference/apache.html
>
> 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 :
replace
<Location /LCSW>
by
<Location /LCSW/>
in the above. Otherwise, it would also match /LCSW1/ for instance.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
|