On Tue, September 26, 2006 10:52 am, Niklas Edmundsson wrote:
I'll attach the thing to bug #39380 as well.
Will take a look.
Regards,
Graham
--
This patch depends on mod_disk_cache LFS-aware config submitted
earlier and is for trunk.
It makes caching of large files possible on 32bit machines by:
* Realising that a file is a file and can be copied as such, without
reading the whole thing into memory first.
* When a file is cached
Forgive me for missing the obvious, but why not just use mod_file_cache
for this?
I recall you mentioning that your use of mod_cache was for locally
caching very large remote files, so don't see how this would help that
in any case since the file doesn't exist locally when being stored, and
On Tue, Sep 26, 2006 at 12:45:39PM +0300, Issac Goldstand wrote:
Forgive me for missing the obvious, but why not just use mod_file_cache
for this?
I recall you mentioning that your use of mod_cache was for locally
caching very large remote files, so don't see how this would help that
in
On Tue, 26 Sep 2006, Issac Goldstand wrote:
Forgive me for missing the obvious, but why not just use mod_file_cache for
this? I recall you mentioning that your use of mod_cache was for locally
caching very large remote files, so don't see how this would help that in any
case since the file
On 09/26/2006 01:00 PM, Joe Orton wrote:
On Tue, Sep 26, 2006 at 10:52:18AM +0200, Niklas Edmundsson wrote:
This patch depends on mod_disk_cache LFS-aware config submitted
earlier and is for trunk.
It makes caching of large files possible on 32bit machines by:
* Realising that a file is a
On Tue, 26 Sep 2006, Graham Leggett wrote:
On Tue, September 26, 2006 1:00 pm, Joe Orton wrote:
This was discussed a while back. I think this is an API problem which
needs to be fixed at API level, not something which should be worked
around by adding bucket-type-specific hacks.
API
Ruediger Pluem wrote:
Maybe stupid question, but the disk_cache_conf is not part of the API, right?
Otherwise I guess we would
need to have some sort of bump here (and I would guess a major one).
My understanding is that it isn't part of the API, as nothing depends on
it, but that is
On Tue, September 26, 2006 1:00 pm, Joe Orton wrote:
This was discussed a while back. I think this is an API problem which
needs to be fixed at API level, not something which should be worked
around by adding bucket-type-specific hacks.
API changes won't be backportable to v2.2.x though,
On Tue, Sep 26, 2006 at 02:20:35PM +0200, Niklas Edmundsson wrote:
On Tue, 26 Sep 2006, Graham Leggett wrote:
On Tue, September 26, 2006 1:00 pm, Joe Orton wrote:
This was discussed a while back. I think this is an API problem which
needs to be fixed at API level, not something which
On 09/26/2006 03:29 PM, wrote:
Author: minfrin
Date: Tue Sep 26 06:29:09 2006
New Revision: 450042
URL: http://svn.apache.org/viewvc?view=revrev=450042
Log:
mod_disk_cache: Make sure that only positive integers are accepted
for the CacheMaxFileSize and CacheMinFileSize parameters in the
I received a note that some users would appreciate distinguishing
notes with a subject line.
Most lists in the ASF don't do this for many good reasons, but I noticed
that many of our peer-user lists (and modules-dev is a developement-users
discussion) do so.
So thoughts? +/- to adding
I'm for adding [modules-dev] to the subject line.
At 09:54 AM 9/26/2006, you wrote:
I received a note that some users would appreciate distinguishing
notes with a subject line.
Most lists in the ASF don't do this for many good reasons, but I noticed
that many of our peer-user lists (and
On Tue, Sep 26, 2006 at 11:54:32AM -0500, William A. Rowe, Jr. wrote:
Most lists in the ASF don't do this for many good reasons, but I noticed
which is why I'm -1 to polluting the subject - there's plenty of X-
headers to work on.
vh
Mads Toftum
--
`Darn it, who spiked my coffee with water?!'
which is why I'm -1 to polluting the subject - there's plenty of X-
headers to work on.
This would be ok, if you always work with one mail client at home.
Since there are certainly several people like me who are working with several
mail clients (tb at home, pine over ssh at work,
On Tue, Sep 26, 2006 at 11:54:32AM -0500, William A. Rowe, Jr. wrote:
Most lists in the ASF don't do this for many good reasons, but I
noticed
On 2006, Sep 26, at 12:01, Mads Toftum wrote:
which is why I'm -1 to polluting the subject - there's plenty of X-
headers to work on.
I'm always a
William A. Rowe, Jr. wrote:
So thoughts? +/- to adding [modules-dev] or [EMAIL PROTECTED] to our
subject headers?
Count me as a plus (+) vote for adding to the subject headers. Having
the quick identifier makes it easier for low function mail clients (like
web mail or cell-phone mail) to
On Tuesday 26 September 2006 17:54, William A. Rowe, Jr. wrote:
So thoughts? +/- to adding [modules-dev] or [EMAIL PROTECTED] to our
subject headers?
Please don't. Subject lines should be meaningful. Especially in the
first few words, which is what you see when they're truncated in a
Nick Kew wrote:
I would suspect that anyone asking for crap in the subject line
needs to rtfm procmail, or whatever other tools they have available.
Sorting of incoming mail has been a solved problem for over 20 years.
I agree with you, up until the introduction of webmail.
Since this list
On 09/26/2006 06:26 PM, wrote:
Author: minfrin
Date: Tue Sep 26 09:26:56 2006
New Revision: 450105
Modified: httpd/httpd/trunk/modules/cache/mod_disk_cache.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/cache/mod_disk_cache.c?view=diffrev=450105r1=450104r2=450105
Ruediger Pluem wrote:
+#define CACHE_BUF_SIZE 65536
+
Is it really a got idea to store 64k on the stack? Shouldn't we get this memory
from a pool?
+1.
Regards,
Graham
--
On 26/09/2006, at 17:35, [EMAIL PROTECTED] wrote:
Author: minfrin
Date: Tue Sep 26 13:35:42 2006
New Revision: 450188
+
+char *buf = apr_palloc(p, CACHE_BUF_SIZE);
+if (!buf) {
+return APR_ENOMEM;
+}
IIRC, apache abort()s on memory allocation errors.
--
Davi Arnaut
On 09/26/2006 10:35 PM, wrote:
Author: minfrin
Date: Tue Sep 26 13:35:42 2006
New Revision: 450188
Modified: httpd/httpd/trunk/modules/cache/mod_disk_cache.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/cache/mod_disk_cache.c?view=diffrev=450188r1=450187r2=450188
Ruediger Pluem wrote:
Are we sure that we do not iterate too often ( 100) over this during the
lifetime
of a request? I would say 'No, we do not iterate too often', but I think a
crosscheck
by someone else is a good idea. Otherwise we would have a potential temporary
memory
leak here.
We
24 matches
Mail list logo
