tor 2007-05-24 klockan 13:22 +0200 skrev Niklas Edmundsson:
c) RFC-wise it seems to me that a not-modified object is a
not-modified object. There is no guarantee that next request will
hit the same cache, so nothing can expect a max-age=0 request to
force a cache to rewrite its
tis 2007-05-22 klockan 11:40 +0200 skrev Niklas Edmundsson:
-8---
Does anybody see a problem with changing mod_cache to not update the
stored headers when the request has max-age=0, the body turns out not
to be stale and the on-disk header hasn't expired?
-8
On Mon, May 21, 2007 4:49 pm, Niklas Edmundsson wrote:
Does anybody see a problem with changing mod_cache to not update the
stored headers when the request has max-age=0, the body turns out
not to be stale and the on-disk header hasn't expired?
The rationale behind
On Mon, 21 May 2007, Graham Leggett wrote:
Since max-age=0 requests can't be fulfilled without revalidating the
object they don't benefit from this header rewrite, and requests with
max-age!=0 that can benefit from the header rewrite won't be affected
by this change.
Am I making sense? Have I
On May 21, 2007, at 7:49 AM, Niklas Edmundsson wrote:
Does anybody see a problem with changing mod_cache to not update
the stored headers when the request has max-age=0, the body turns
out not to be stale and the on-disk header hasn't expired?
Yes, the problem is that it will break content
Niklas Edmundsson wrote:
At first glance, doing this I think will break RFC2616 compliance, and if
it does break RFC compliance then I think it should not be default
behaviour. However if it does solve a real problem for admins, then
having
a directive allowing the admin to enable this
On May 21, 2007, at 2:22 PM, Ruediger Pluem wrote:
Why don't you just add an ignore of cache-control on requests from
those stupid download managers? A simple BrowserMatch should do.
I am not quite sure what you mean by this. AFAIK you cannot set
CacheIgnoreCacheControl based on env
On 04/16/2007 10:58 PM, Ruediger Pluem wrote:
Looking at the problem I noticed a related problem already mentioned in a
FIXME comment:
It can happen that the headers of a 304 response from the backend cause the
response to be
uncacheable (e.g. Cache-Control: no-store).
Currently this
the cache out of it
entirely - inventing Expires values deep inside of mod_cache seems
unclean. mod_cache, IMO, should just respect what it is told and not
change how things appear to downstream folks. (mod_expires is more
than capable of inserting in the Expires header if the admin wants
it.)
I
On 05/18/2007 01:33 AM, Justin Erenkrantz wrote:
With this patch, the only thing mod_cache ever touches is...Age. =)
I'll let this sit here for a bit and if we agree this is right, we can
commit. -- justin
Index: modules/cache/mod_cache.c
On 5/17/07, Ruediger Pluem [EMAIL PROTECTED] wrote:
Hm. In this case date would be undefined and it is used later on.
Oh. Good catch.
Maybe we should remove the else branch and set date = info-date in
any case so that it is either the contents of Date: or now.
Sure. That'll work.
See
On 02.05.2007 14:21, Niklas Edmundsson wrote:
It did, but it caused the freshness calculation to overflow so the end
Ouch.
result was bollocks. I hard-coded 100 years for the max-stale without
value case, not pretty but it works.
I would suggest using *one* year here. Although 14.9.3 of
We encountered the following bug: httpd segfaulted due to a client
emitting Cache-Control: max-age=216000, max-stale which is a
perfectly valid header.
The segfault is caused by the fact that ap_cache_liststr() sets the
value pointer to NULL when there is no value, and this isn't checked
On Wed, 2 May 2007, Niklas Edmundsson wrote:
We encountered the following bug: httpd segfaulted due to a client emitting
Cache-Control: max-age=216000, max-stale which is a perfectly valid header.
The segfault is caused by the fact that ap_cache_liststr() sets the value
pointer to NULL when
On Mon, 16 Apr 2007, Ruediger Pluem wrote:
I have now tested this patch, and it seems to solve the problem. This is
on httpd-2.2.4 + patch for PR41475 + our mod_disk_cache patches.
Without the patch a HEAD on a cached expired object that isn't modified
will unconditionally return 304 and
-Ursprüngliche Nachricht-
Von: Niklas Edmundsson
Gesendet: Dienstag, 17. April 2007 09:07
An: dev@httpd.apache.org
Betreff: Re: [PATCH] mod_cache 304 on HEAD (bug 41230)
On Mon, 16 Apr 2007, Ruediger Pluem wrote:
Are you really sure that it gets deleted?
cache
hacking on mod_disk_cache
we fixed remove_entity to also remove the cache-files. If I remember
correctly it was leaving stale cache files in some code paths, I guess
that this was one of them. And we never figured out why there was both
remove_entity and remove_url anyway, even the mod_cache-code
On 04/13/2007 05:31 PM, Niklas Edmundsson wrote:
On Wed, 11 Apr 2007, Niklas Edmundsson wrote:
Looking a bit further, I think that something like this would actually
be enough:
snip, included as an attachment
I have now tested this patch, and it seems to solve the problem. This is
on
mån 2007-04-16 klockan 22:58 +0200 skrev Ruediger Pluem:
My first question in this situation is: What is the correct thing to do here?
Generate the response from the cache (of course with the updated headers from
the 304
backend response) and delete the cache entry afterwards?
My
On Wed, 11 Apr 2007, Niklas Edmundsson wrote:
Looking a bit further, I think that something like this would actually be
enough:
snip, included as an attachment
I have now tested this patch, and it seems to solve the problem. This
is on httpd-2.2.4 + patch for PR41475 + our mod_disk_cache
On Wed, 11 Apr 2007, Niklas Edmundsson wrote:
Would the correct fix be to check for r-header_only in cache_select(), or
are there even more funky stuff going on? You don't want the cached object to
be removed just because you got a HEAD request when it really isn't stale but
just in need of
Bart van der Schans wrote:
Davi Arnaut wrote:
Looking at it more, the previous check it's also useless. Attempted
patch...
I finally had some time to test the patch and it seems to work
correctly. It still recognizes Unix epoch as a bad date, but mod_cache
won't cache
Bart van der Schans wrote:
Is there any change the patch from Davi will make it in the trunk (and
That should have read chance of course, sorry about the typo.
Bart
as a bad date, but mod_cache
won't cache it.
Is there any change the patch from Davi will make it in the trunk (and
hopefully backported to the branch)? What is the correct way to move
forward with this? Can I help in some way?
Providing a better reference to the patch you are talking about
Ruediger Pluem wrote:
Providing a better reference to the patch you are talking about would be a
start :-).
Of course, and now when I'm trying to find Davi's mail from the 18th of
January in the archive it seems to be missing, so maybe it didn't even
make it to the list :( So here is his
Hi!
I might be jumping the gun here, but I'd really like to see the fix
for PR 41475 backported to 2.2.5. We're hitting this issue when
mirroring the firefox installer which has a space in the filename...
We'll probably apply the fix locally, but it would be nice to have the
mod_cache
Hi,
I was looking for something more reliable so I now realize it will
require patching of mod_cache.c by adding some flag (i.e. setting some
key r-notes, registering mod_log_config modifier via log_pfn_register
or similar).
On 2/12/07, Joshua Slive [EMAIL PROTECTED] wrote:
On 2/12/07, Dziugas
Hi list,
I'm using httpd 2.2.4 as both reverse and forward proxy having caching
enabled with mod_cache.
I'm trying to figure out the way how to put information in access log
(via mod_log_config) whether the request was a cache hit or miss
(similar to what squid does - TCP_MISS and TCP_HIT). I
On 2/12/07, Dziugas Baltrunas [EMAIL PROTECTED] wrote:
I'm trying to figure out the way how to put information in access log
(via mod_log_config) whether the request was a cache hit or miss
(similar to what squid does - TCP_MISS and TCP_HIT). I think this
information is necessary for any proxy
Hi,
I use an Apache 2.2 with mod_perl, mod_cache mod_disk_cache.
I add an unique string to $r-uri with an perl script, but have to
save/load the cache files without this string. The uri I build looks
like /UNIQ123456789/filename, but the cached target should look like
/filename. Other pathes
-Ursprüngliche Nachricht-
Von: Tigges
Gesendet: Donnerstag, 1. Februar 2007 12:36
An: dev@httpd.apache.org
Betreff: mod_cache mod_disk_cache
Hi,
I use an Apache 2.2 with mod_perl, mod_cache mod_disk_cache.
I add an unique string to $r-uri with an perl script, but have
unique meta-information to each request mod_cache will treat each
request as a new request. Since mod_cache is run as a quick handler it
is not possible to use mod_rewrite to remove the query-string part of
the request.
I believe this should be considered a relevant scenario, and that an
option
On Wed, 24 Jan 2007, Plüm, Rüdiger, VF EITO wrote:
Of course practically you don't want to make assumptions about the
emptiness of the existing brigade, so clearing the brigade as
a first step
makes definite sense.
It is not needed to clear the brigade, because the brigade passed to
the
In mod_cache, recall_body() is called in the cache_save_filter() when
revalidating an entity.
However, if I have understood things correctly the brigade is already
populated when the save filter is called, so calling recall_body() in
this case would place additional stuff in the bucket
On 24 Jan 2007, at 13:15, Niklas Edmundsson wrote:
In mod_cache, recall_body() is called in the cache_save_filter()
when revalidating an entity.
However, if I have understood things correctly the brigade is
already populated when the save filter is called, so calling
recall_body
On Wed, January 24, 2007 2:15 pm, Niklas Edmundsson wrote:
In mod_cache, recall_body() is called in the cache_save_filter() when
revalidating an entity.
However, if I have understood things correctly the brigade is already
populated when the save filter is called, so calling recall_body
On Wed, 24 Jan 2007, Graham Leggett wrote:
On Wed, January 24, 2007 2:15 pm, Niklas Edmundsson wrote:
In mod_cache, recall_body() is called in the cache_save_filter() when
revalidating an entity.
However, if I have understood things correctly the brigade is already
populated when the save
On 24 Jan 2007, at 14:39, Giuliano Gavazzi wrote:
this could be the underlying cause to a bug I reported against
mod_cache+mod_include in 2.2.4 and then reported to this list:
I spoke too early, I was wrong.
Regarding your observation, I see that in cache_save_filter
recall_body is called
-Ursprüngliche Nachricht-
Von: Graham Leggett
Gesendet: Mittwoch, 24. Januar 2007 16:15
An: dev@httpd.apache.org
Cc: dev@httpd.apache.org
Betreff: Re: mod_cache: save filter recalls body to non-empty brigade?
On Wed, January 24, 2007 2:15 pm, Niklas Edmundsson wrote
Niklas Edmundsson wrote:
Since mod_cache runs as a quick handler, matching based on URL would
probably be the easiest since you don't have the mime type info then.
Maybe something like
CacheEnable disk /special/path ignore_query
Could add other options if future as well.
--
Brian Akins
Chief
On 1/23/07 10:44 AM, Niklas Edmundsson [EMAIL PROTECTED] wrote:
Ah, you can place CacheEnable-directives in the vhost context too.
Then it should be sufficient, unless you want to say ignore
querystring for all .gif:s or something like that. Perhaps use a
regex instead?
In our home-grown
Akins, Brian wrote:
In our home-grown cache module, the rules are actually provider based. We
have providers that provide matches based on exact match, string match,
regex, prefix, environment variable, and other assorted things.
Something like:
CacheEnable disk regex=\.gif$ ignore_query
I wrote a patch friday, had a few minutes over to test it and it seemed
to work fine. Of course it's a minimal patch, but I'll double check it
tomorrow anyway, and try to convince you guys to accept it. :)
Kind regards,
Fredrik Widlund
Ruediger Pluem skrev:
On 01/19/2007 05:49 PM, Scott
On 01/21/2007 04:09 PM, Scott MacVicar wrote:
We did use mod_expires but the Expires header was being passed on to the
client, mod_headers didn't appear to be able to unset this during tests.
This is true, but what is the problem with passing the Expires header to the
client? If you want to
Ruediger Pluem wrote:
On 01/21/2007 04:09 PM, Scott MacVicar wrote:
We did use mod_expires but the Expires header was being passed on to the
client, mod_headers didn't appear to be able to unset this during tests.
This is true, but what is the problem with passing the Expires header to the
On 01/21/2007 05:55 PM, Scott MacVicar wrote:
Ruediger Pluem wrote:
On 01/21/2007 04:09 PM, Scott MacVicar wrote:
We did use mod_expires but the Expires header was being passed on to the
client, mod_headers didn't appear to be able to unset this during tests.
This is true, but what is
I'm trying to get mod_cache to ignore the query_string part of the
request, since our customers use clicktags in references to static
banners. I need to cache these request to improve performance.
My idea was to RewriteRule .* %{REQUEST_URI}?, however I have learned
that mod_cache is run
-Ursprüngliche Nachricht-
Von: Fredrik Widlund
Gesendet: Freitag, 19. Januar 2007 10:23
An: dev@httpd.apache.org
Betreff: mod_cache+mod_rewrite behaviour
I'm trying to get mod_cache to ignore the query_string part of the
request, since our customers use clicktags
ask this?
Kind regards,
Fredrik Widlund
Plüm wrote:
-Ursprüngliche Nachricht-
Von: Fredrik Widlund
Gesendet: Freitag, 19. Januar 2007 10:23
An: dev@httpd.apache.org
Betreff: mod_cache+mod_rewrite behaviour
I'm trying to get mod_cache to ignore the query_string part of the
request
-Ursprüngliche Nachricht-
Von: Fredrik Widlund
Gesendet: Freitag, 19. Januar 2007 12:30
An: dev@httpd.apache.org
Betreff: Re: mod_cache+mod_rewrite behaviour
Hi,
Thanks for the information. Tried the patch and it mends it the
behaviour, however it doesn't really help me
accepted? Who/where do I ask this?
Kind regards,
Fredrik Widlund
Plüm wrote:
-Ursprüngliche Nachricht-
Von: Fredrik Widlund
Gesendet: Freitag, 19. Januar 2007 10:23
An: dev@httpd.apache.org
Betreff: mod_cache+mod_rewrite behaviour
I'm trying to get mod_cache to ignore the query_string
-Ursprüngliche Nachricht-
Von: Roy T. Fielding
Gesendet: Mittwoch, 17. Januar 2007 23:23
An: Ruediger Pluem
Cc: dev@httpd.apache.org; dev@apr.apache.org
Betreff: Re: Mod_cache expires check
On Jan 17, 2007, at 12:23 PM, Ruediger Pluem wrote:
I would say 0 is not a bad
tor 2007-01-18 klockan 12:05 +0100 skrev Plüm, Rüdiger, VF EITO:
Just curious: Is the Unix epoch an invalid date in the Expires header
(as this in the past it does not really matter for the question whether
this document is expired or not as it would be in both cases)?
The RFC does not care
On 01/18/2007 12:49 PM, Henrik Nordstrom wrote:
tor 2007-01-18 klockan 12:05 +0100 skrev Plüm, Rüdiger, VF EITO:
Any valid date which can be represented in the textual form is a valid
Expires header. And any Expires header you can not understand for
whatever reason is already expired in
In r463496 the following check was added to mod_cache.c :
else if (exp != APR_DATE_BAD exp r-request_time)
{
/* if a Expires header is in the past, don't cache it */
reason = Expires header already expired, not cacheable;
}
This check fails to correctly identify the
mån 2007-01-15 klockan 13:56 +0100 skrev Bart van der Schans:
In r463496 the following check was added to mod_cache.c :
else if (exp != APR_DATE_BAD exp r-request_time)
{
/* if a Expires header is in the past, don't cache it */
reason = Expires header already
On 01/15/2007 01:56 PM, Bart van der Schans wrote:
In r463496 the following check was added to mod_cache.c :
else if (exp != APR_DATE_BAD exp r-request_time)
{
/* if a Expires header is in the past, don't cache it */
reason = Expires header already expired, not
On Jan 17, 2007, at 12:23 PM, Ruediger Pluem wrote:
On 01/15/2007 01:56 PM, Bart van der Schans wrote:
In r463496 the following check was added to mod_cache.c :
else if (exp != APR_DATE_BAD exp r-request_time)
{
/* if a Expires header is in the past, don't cache it */
it, there are four cases:
a - Expires not set
b - Expires set to a bad (unparsable) date
c - Expires set to a date in the past (from and including 0)
d - Expires set to the future (up to +1 year)
According to rfc 2616 14.21, b and c should be treated as the same, but
mod_cache treats a and b
Thanks Roy. So, the goals for mod_disk_cache as I see it:
A simple general-purpose disk cache which makes no assumptions about
speed of backend, speed of storage or speed of clients; is
single-threaded and does not involve any multi-process synchronisation
beyond open/O_EXCL. Specifically:
vetoed this.
The mod_cache itself should be responsible for breaking any large buckets
into bite size chunks, to prevent the cache module from having to care
about large responses. This maintains the abstraction between
write-to-cache and write-to-network.
A disk cache which makes different
On Mon, Oct 30, 2006 at 12:18:30PM +0200, Graham Leggett wrote:
On Mon, October 30, 2006 12:07 pm, Joe Orton wrote:
1) cannot write entire response to disk for any content type before
sending anything to the client; filter acts by writing to cache and
client synchronously
Justin vetoed
On Mon, October 30, 2006 1:03 pm, Joe Orton wrote:
On Mon, October 30, 2006 12:07 pm, Joe Orton wrote:
1) cannot write entire response to disk for any content type before
sending anything to the client; filter acts by writing to cache and
client synchronously
Justin vetoed this.
Can we
Davi Arnaut wrote:
The solution consists of using the cache file as a output buffer by
splitting the buckets into smaller chunks and writing then to disk. Once
written (apr_file_write_full) a new file bucket is created with offset
and size of the just written buffer. The old bucket is deleted.
On Mon, October 30, 2006 4:44 pm, Brian Akins wrote:
Without having looked very much at the code, this approach sounds
feasible.
I'm still confused as to why we need the temporary brigade??? Why not
swap
the buckets?
The current cache (as in what is in trunk right now) does exactly that -
to the
store_body() analogue that the provider can call after it writes a
bucket which mod_cache can then pass along down the filter chain on
its behalf. Otherwise, we'd have way too much duplicate code to deal
with and that concerns me.
The implementation that was recently checked in makes it so that we
On Mon, Oct 30, 2006 at 10:26:18AM -0700, Justin Erenkrantz wrote:
On 10/30/06, Joe Orton [EMAIL PROTECTED] wrote:
1) cannot write entire response to disk for any content type before
sending anything to the client; filter acts by writing to cache and
client synchronously
My concern with
On 10/30/06, Joe Orton [EMAIL PROTECTED] wrote:
On Mon, Oct 30, 2006 at 10:26:18AM -0700, Justin Erenkrantz wrote:
My concern with this is we should be careful not to teach the
providers about the fact that it is sitting in an output filter chain.
This is solvable if desired, but I'd like to
that the provider can call after it writes a
bucket which mod_cache can then pass along down the filter chain on
its behalf. Otherwise, we'd have way too much duplicate code to deal
with and that concerns me.
The implementation that was recently checked in makes it so that we
can not distinguish
to be
consumed by relatively low-rate).
By operating as a normal output filter mod_cache must deal with
potentially large brigades of (possibly) different (other than the stock
ones) bucket types created by other filters on the chain.
This first problem has largely been solved, bar some testing
Davi Arnaut wrote:
Graham, could you please summarize the problems we want to solve and the
possible solutions and send then to the list ?
The cache needs a notifier api, because as Joe pointed out, it cannot be
guaranteed that the ap_core_output_filter() will not block. You have one
in the
mod_cache must deal with
potentially large brigades of (possibly) different (other than the stock
ones) bucket types created by other filters on the chain.
This first problem has largely been solved, bar some testing.
Those fixes were vetoed if I remember correctly.
The solution was to pass
for mod_cache to be RFC compliant. It may be that
we circle around the same things again and again and sometimes this may be even
unproductive. But this way for sure we do not get anything (and the past proved
it)
productive out of this. As we had this in the past I try to throw a flag very
early
month ago regarding the need for mod_cache to be RFC compliant.
Yes, but it was about the generic cache architecture.
It may be that
we circle around the same things again and again and sometimes this may be
even
unproductive. But this way for sure we do not get anything (and the past
Davi Arnaut wrote:
I've just described that. Maybe my English was poor in the e-mail.
Your English is spot on, unfortunately the aggressive nature of your
email isn't.
You are not going to bully anybody on this list into accepting any
patch, it's not how this project works.
It is quite
miserably. I just hope our minor disagreements won't
interfere with us working on mod_cache in the future. I will repeat
again, I'm not attacking you. I was pursing what I thought was better
for mod_cache.
--
Davi Arnaut
a consensus but failed miserably. I just hope our minor
disagreements won't interfere with us working on mod_cache in
the future. I will repeat again, I'm not attacking you. I was
pursing what I thought was better for mod_cache.
mod_cache doesn't get better when the maintainers get fed up
this thread die now, which was created to gather
a consensus but failed miserably. I just hope our minor
disagreements won't interfere with us working on mod_cache in
the future. I will repeat again, I'm not attacking you. I was
pursing what I thought was better for mod_cache
As far as mod_*cache is concerned, we should work out the technical
definition of what those modules are supposed to be doing and just
stick with one direction on trunk. Once that decision is made,
folks can veto code on the basis of technical concerns (such as, that
module should be for small
Roy T. Fielding wrote:
As far as *I* am concerned, changes to the cache code must be correct
first and then perform second, and both of those should be proven by
actual testing before being committed to trunk.
+1.
We have an existing cache that breaks in real world environments.
We have a
Hi,
It's quite clear that without some agreement we won't be able to
actually fix mod_cache shortcomings. The idea now is to gather our
efforts to get consensus on the proposed fixes and commit then one by one.
The current high priority issues can be summarized as:
* Buffering
. Problem
I think we have had enough -1s passed over the last couple days related
to mod_cache, that it indicates there is not a consensus on what should
be done, nor on how it should be done.
I think we need to stop committing code for a couple days, and try to
make a rudimentary plan for the intended
On Fri, October 27, 2006 6:36 pm, Paul Querna wrote:
I think we have had enough -1s passed over the last couple days related
to mod_cache, that it indicates there is not a consensus on what should
be done, nor on how it should be done.
I think we need to stop committing code for a couple
Paul Querna wrote:
I think we have had enough -1s passed over the last couple days related
to mod_cache, that it indicates there is not a consensus on what should
be done, nor on how it should be done.
I think we need to stop committing code for a couple days, and try to
make
The following patch should eliminate bogus error log entries similar
to:
[Wed Sep 27 15:31:29 2006] [error] (-3)Unknown error 18446744073709551613:
cache: error returned while trying to return disk cached data
If I have understood things right AP_FILTER_ERROR only means that an
error has
, we'd have
to do all this even now, wouldn't we?
As promised, I looked into this. mod_proxy de-chunks the incoming
response, mod_cache caches it un-chunked, without the content-length or
transport-encoding headers, and the content-length output filter decides
what to do with it. Trailers were
On Wed, September 20, 2006 9:50 pm, Ruediger Pluem wrote:
You can set a max cache file size (CacheMaxFileSize) which prevents
caching files that are larger then
a specfic size. This is checked after each bucket is written to the disk.
If the
stream is larger then the max file size the file
-Ursprüngliche Nachricht-
Von: Niklas Edmundsson
Gesendet: Donnerstag, 21. September 2006 11:38
An: dev@httpd.apache.org
Betreff: Re: mod_cache responsibilities vs mod_xxx_cache
provider responsibilities
On Thu, 21 Sep 2006, Graham Leggett wrote:
This means the backend
to cooperate by passing the trailers somehow up the
filter stack if a trailer is present, cache_save would then add the
trailer to the existing headers.
In theory, all mod_proxy needs to do is add the trailer to the headers
list when one is received. Once mod_cache has finished caching an entity
tor 2006-09-21 klockan 12:18 +0200 skrev Plüm, Rüdiger, VF EITO:
IMHO this waits for a DoS to happen if the requestor can trick the backend
to get stuck with the request. So one request of this type would be sufficient
to DoS the whole server if the timeout is not very short.
How would this
On Mon, 18 Sep 2006, Brian Akins wrote:
Niklas Edmundsson wrote:
Extra tracking sounds unnecessary if you can do it in a way that
doesn't need it.
It's not extra it just adding some tracking. When an objects gets cached
log (sql, db, whatever) that /blah/foo/bar.html is cached as
On Mon, 18 Sep 2006, Brian Akins wrote:
Graham Leggett wrote:
I have not seen inside the htcacheclean code, why is the code reading the
headers? In theory the cache should be purged based on last access time,
deleted as space is needed.
Everyone should be mounting cache directories noatime,
Niklas Edmundsson wrote:
On Mon, 18 Sep 2006, Brian Akins wrote:
Niklas Edmundsson wrote:
* Only one session caches the same file.
Easy to do if we use deterministic tmp files and not the way we
currently do it. Then all you have to do is when creating temp files
use O_EXCL.
Or,
Niklas Edmundsson wrote:
don't care about performance...
Actually, cache on xfs mounted with atime doesn't seem to be a
performance killer oddly enough... Our frontends had no problems
surviving 1k requests/s during the latest mozilla-update-barrage.
1k requests/second is not really that
from the wrong angle. Rather than
modifying mod_cache, modify the garbage-collector (e.g., htcacheclean).
Do a two pass cleanup. The first pass is a data-store transversal pass
which decides what to remove. It immediately purges the header file,
and stores the entity key (or filename
On Wed, 20 Sep 2006, Brian Akins wrote:
Niklas Edmundsson wrote:
don't care about performance...
Actually, cache on xfs mounted with atime doesn't seem to be a performance
killer oddly enough... Our frontends had no problems surviving 1k
requests/s during the latest mozilla-update-barrage.
. Rather than
modifying mod_cache, modify the garbage-collector (e.g., htcacheclean).
Do a two pass cleanup.
I think it's insane that it has to traverse the directory structure to
do find the objects. There should be an index of objects. Traversing
the tree can be a huge hit on large, busy
On Wed, September 20, 2006 5:27 pm, Brian Akins wrote:
unless 0 is a valid content-length, which it can be. Also, what about
when we are reading something in without a know C-L, for example from an
origin doing chunks?
I am not sure what the current cache code does to handle chunked entities
.
For any other length we don't introduce any problem we don't have now.
You're right, this is a tricky one, but there is a solution out there.
Maybe we're attacking the problem from the wrong angle. Rather than
modifying mod_cache, modify the garbage-collector (e.g.,
htcacheclean). Do a two
Graham Leggett wrote:
On Wed, September 20, 2006 5:27 pm, Brian Akins wrote:
unless 0 is a valid content-length, which it can be. Also, what about
when we are reading something in without a know C-L, for example from an
origin doing chunks?
I am not sure what the current cache code
201 - 300 of 732 matches
Mail list logo
