Indeed.
So either you create a sript/program that goes directly in the cache and
clears the document (which would mean you can recalculate the hash that
mod_cache uses for a given URL), or else you find another clever way.
Let's say that for Tomcat, the expensive part of the operation is to
re-generate the PDF response. But since this seems to be some kind of
database-based application, I imagine that :
- when your application on Tomcat gets a request for an item, it goes
off into the database to retrieve the information, then formats this
into a PDF and sends this as a response. That's expensive.
- but the information in the database must have some kind of timestamp,
since you can determine when the response would need to be regenerated
and when not.
- so what about your application checking first if the information is
really "new", and if not returning some other kind of response to the
caller (in this case the caller would be Apache/mod_cache).
What I mean is a bit complicated to explain, but roughly :
- when mod_cache examines a request, it can find that the document is
not in the cache, and then the request goes through to Tomcat. The
response from Tomcat is then stored in the cache, by a filter set up by
mod_cache for this request and for this purpose. I imagine that in this
case, the request as it goes to Tomcat is "unconditional", meaning that
it tells Tomcat "give me this document, no matter what".
- on the other hand, when mod_cache finds the document already in the
cache, it must still, under certain circumstances, let a request go
through to Tomcat, to verify that the cached document is still valid.
I am not quite clear myself on which combination of circumstances and
request and response headers control this behaviour, but I have a
feeling somehow that it must be possible to play with this, to avoid the
Tomcat application having to unnecessarily generate those expensive PDF
answers. It would still get calls, and would still need to interrogate
the database, but in many cases it could answer with something like a
"Not modified" status instead of a new PDF.
Any real guru available here ?
Karim Zaki wrote:
Seems I'm back at square 1. The idea of using max-age=0 did not work, which, on second
thought, makes sense. CacheIgnoreCacheControl should ignore the "cache-control"
header regardless of its value. The virtual host solution did not work either. It created
new cache entries for the vhost.
-----Original Message-----
From: André Warnier [mailto:[EMAIL PROTECTED]
Sent: Monday, December 01, 2008 6:20 PM
To: users@httpd.apache.org
Subject: Re: [EMAIL PROTECTED] Clearing cache selectively on Apache + mod_cache
Eric Covener wrote:
On Mon, Dec 1, 2008 at 11:09 AM, André Warnier <[EMAIL PROTECTED]> wrote:
Which leads me to believe that, as such, the scheme proposed with the
separate VirtualHost will not work as simply as expected.
Yep, it looks like you'd need to jump through hoops to have a vhost
that was able to nuke these requests (using the same hostname on a
separate interface).
Just intellectual curiosity : other than going through the source code
of mod_cache, is there a description somewhere of the algorithm used by
mod_cache to calculate this hashcode ?
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: [EMAIL PROTECTED]
" from the digest: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: [EMAIL PROTECTED]
" from the digest: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: [EMAIL PROTECTED]
" from the digest: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
