Mark Thomas wrote:
On 14/07/2011 11:29, André Warnier wrote:
Hi.
This is a bit of a side question, or let's say a question-by-proxy.
I happen to be also subscribed to a support list for mod_perl, and
someone there made the following comment as part of a post :
quote
We have 100+ web servers where apache fronts a separate tomcat server
using mod_proxy.
Sadly, the tomcat dev's forgot to set any caching headers in the HTTP
response (either Expires, Last-Modified or Cache-control) so the sites
are largely uncacheable by browsers and the various tomcats are becoming
overloaded.
unquote
Do any of the dev's here have a comment to make ?
"Sadly, the mod_perl OP forget to do any research (such as requesting
Tomcat's homepage and reading the headers) so my response is largely
unprintable in polite society and the various Tomcat devs are becoming
under impressed."
Wooaw.
It was not my intention to start an inter-Apache-list war here, so I have a couple of
things to add :
1) reading the next post of the original mod_perl poster, it has become clear to me that
what he meant by "the tomcat dev's" was not "The Tomcat Dev's". He obviously meant "the
dev's who developed the applications running under Tomcat".
And he was not talking about static pages, it is more complicated than that.
So you can all get back to being your usual serene and competent helpful selves
again.
2) to further dispel the issue, here is the second post by the same OP.
(I also have to add that I am quoting all this without permission, and it was just by
curiosity).
quote
...
> Assuming that what you say about Tomcat is true (I don't know, and it
> may be worth asking this on the Tomcat list), I can think of another way
> to achieve what you seem to want :
> if you can distinguish, from the request URL (or any other request
> property), the requests that are for invariant things, then you could
> arrange to /not/ proxy these requests to Tomcat, and serve them directly
> from Apache httpd.
Indeed that is a good idea. We are doing that for new projects for css and js files
(apache does not proxy certain paths and picks these up from the local filesystem).
We can't do that for the 100 odd legacy servers as no-one has time o delve into the
java/JSP code. I need to do something "outside" of tomcat where possible. Just to explain,
each web server is a paid-for project - and when it's done, it sits there for 5+ years.
Only I have the time/inclination to fix this as it's killing my VMWare infrastructure.
Because the sites are all fronted by apache in a similar way, one solution is likely to
apply to most of the sites.
I would also add that most of the sites are "dynamically" driven pages, even involving
MySQL querying, but once launched, the data remains fairly static - eg GET X will always
resolve to reponse Y.
I'm planning a small seminar on the value of Cache-Control for my dev colleagues so they
can stop making this mistake ;-> But that still leaves a lot of "done" projects to fix.
> Which proxying method exactly are you using between Apache and Tomcat ?
> (if you are using mod_proxy, then you are either using mod_proxy_http or
> mod_proxy_ajp; you could also consider using mod_jk).
mod_proxy_http specifically.
mod_jk looks interesting for new projects (we have local tomcats for those now) - I think
it may be a non-starter for old stuff as trying to retro fit it may not be so simple (our
older tomcat servers are in a remote farm on their own machines hence the use of
mod_proxy_http).
> Also, what are the versions of Apache and Tomcat that you are using ?
>
Apache 2.2 (various sub versions) and both tomcat 5.5 and tomcat 6 (but all on remote
machines listening on TCP sockets).
I think for this problem, I have to treat tomcat as a little, rather inefficient, black
box and try to fixup on the apache front ends, hence the direction of my original idea...
unquote
.. and I am sure that he does not *really* mean it either, like he says in that
last phrase.
One interesting suggestion here was to use the URLRewriteFilter. I will pass that on to
the mod_perl OP.
Thanks for your answers, and peace to all.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
