APACHE 2.0 STATUS: -*-text-*-
Last modified at [$Date: 2006-09-13 15:45:30 -0400 (Wed, 13 Sep 2006) $]
The current version of this file can be found at:
* http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/STATUS
Documentation status is main
APACHE 2.3 STATUS: -*-text-*-
Last modified at [$Date: 2006-08-22 16:41:03 -0400 (Tue, 22 Aug 2006) $]
The current version of this file can be found at:
* http://svn.apache.org/repos/asf/httpd/httpd/trunk/STATUS
Documentation status is maintained se
Am Dienstag, den 26.09.2006, 11:54 -0500 schrieb William A. Rowe, Jr.:
> So thoughts? +/- to adding [modules-dev] or [EMAIL PROTECTED] to
> our
> subject headers?
-
Sincerely,
Joachim
FWIW, there seemed to be an initial feeling from
people that "Yeah, this is a good idea" and then
it kind of degraded into a "Nah, it's stupid; It's
too hard to do it completely; We can already do
this now by adding all these other config
directives" so I decided not to waste my time
on it right n
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 occ
On Wed, Sep 27, 2006 at 02:41:11PM +0200, Graham Leggett wrote:
> On Wed, September 27, 2006 2:31 pm, Joe Orton wrote:
>
> > The new approach is exactly the same for other bucket types, FILE should
> > not be treated as special just to avoid that. Other bucket types will
> > cause the same memory
On Wed, 27 Sep 2006, Graham Leggett wrote:
On Wed, September 27, 2006 11:07 am, Niklas Edmundsson wrote:
In practice this isn't enough when dealing with large files, so in our
production code (the hideously large jumbopatch) this is fixed by
read-while-caching and spawning a thread to do the c
On Wed, September 27, 2006 2:31 pm, Joe Orton wrote:
> The new approach is exactly the same for other bucket types, FILE should
> not be treated as special just to avoid that. Other bucket types will
> cause the same memory consumption issue (notably CGI/PIPE).
I looked at this issue, but I coul
On Wed, Sep 27, 2006 at 01:31:05PM +0200, Graham Leggett wrote:
> On Wed, September 27, 2006 11:37 am, Joe Orton wrote:
>
> > I don't get it - as discussed, this approach is completely unsound.
> > There is no reason to assume it's possible to copy the entire content
> > into the cache before send
On Wed, September 27, 2006 11:07 am, Niklas Edmundsson wrote:
> In practice this isn't enough when dealing with large files, so in our
> production code (the hideously large jumbopatch) this is fixed by
> read-while-caching and spawning a thread to do the caching in the
> background while deliveri
On Wed, September 27, 2006 11:37 am, Joe Orton wrote:
> I don't get it - as discussed, this approach is completely unsound.
> There is no reason to assume it's possible to copy the entire content
> into the cache before sending anything to the client just because it
> happens to be a FILE bucket (
On Wed, 27 Sep 2006, Joe Orton wrote:
I don't get it - as discussed, this approach is completely unsound.
There is no reason to assume it's possible to copy the entire content
into the cache before sending anything to the client just because it
happens to be a FILE bucket (think slow NFS servers
On Wed, September 27, 2006 10:12 am, Ruediger Pluem wrote:
>> We would copy the body once per request, surely? That's how I read it -
>> copy_body would be called once, resulting in the buffer being declared
>> once, and reused inside the copy_body loop.
>
> Yes, of course. Stupid thought of mine.
On Tue, Sep 26, 2006 at 04:26:57PM -, Graham Leggett wrote:
> Author: minfrin
> Date: Tue Sep 26 09:26:56 2006
> New Revision: 450105
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=450105
> Log:
> mod_disk_cache: Make caching of large files possible on 32bit machines
> by determining wheth
On Wed, 27 Sep 2006, Graham Leggett wrote:
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 p
On Tue, 26 Sep 2006, Graham Leggett wrote:
Niklas Edmundsson wrote:
* 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 by copying, replace the brigade with a new one
refering to the cached file so we don't
On 09/27/2006 12:22 AM, Graham Leggett wrote:
> 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. Otherwis
17 matches
Mail list logo