On Sun, 1 Oct 2006, Davi Arnaut wrote:
store_body:
.. if (is_file_bucket(bucket))
copy_file_bucket(bucket, bb);
Probably, but that doesn't allow for creating a thread/process that
does the copying in the background, which is my long term goal.
Also, simply doing
Niklas Edmundsson wrote:
On Sun, 1 Oct 2006, Davi Arnaut wrote:
store_body:
.. if (is_file_bucket(bucket))
copy_file_bucket(bucket, bb);
Probably, but that doesn't allow for creating a thread/process that
does the copying in the background, which is my long term goal.
Also,
On Mon, 2 Oct 2006, Davi Arnaut wrote:
Simpler, yes. But it only has the benefit of not eating all your
memory...
Well, that was the goal. Maybe we could merge this one instead and work
together on the other goals.
As I have said before, we have a large patchset that fixes a bunch of
Niklas Edmundsson wrote:
On Mon, 2 Oct 2006, Davi Arnaut wrote:
Simpler, yes. But it only has the benefit of not eating all your
memory...
Well, that was the goal. Maybe we could merge this one instead and work
together on the other goals.
As I have said before, we have a large patchset
Niklas Edmundsson wrote:
If the intent is a total redesign of mod_disk_cache, ie you're not
interested in these patches at all, please say so and I would have not
wasted a lot of work on bending our patches to get something that works
when applying them one by one and then do QA on the thing.
Ruediger Pluem wrote:
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:
*
On Sat, 30 Sep 2006, Davi Arnaut wrote:
Hi,
Wouldn't you avoid a lot of complexity in this patch
if you just deleted from the brigade the implicitly
created heap buckets while reading file buckets ?
Something like:
store_body:
.. if (is_file_bucket(bucket))
Niklas Edmundsson wrote:
On Sat, 30 Sep 2006, Davi Arnaut wrote:
Hi,
Wouldn't you avoid a lot of complexity in this patch
if you just deleted from the brigade the implicitly
created heap buckets while reading file buckets ?
Something like:
store_body:
.. if
On 26/09/2006, at 05:52, 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 file and can be copied as such, without
reading the
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
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 delivering
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
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
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
21 matches
Mail list logo
