Re: Download hanging

From: Steven <swilton@dont-contact.us>
Date: Tue, 8 Aug 2006 07:51:39 +0800 (WST)

On Mon, 7 Aug 2006, Henrik Nordstrom wrote:

> Steven, do you think this could be the cause of Bug #1304?
>
> Never got to the bottom with that bug and it seemed to disappear, but it
> feels like this could be the root cause...
>

This definitely looks like the same bug to me.

I did have one other thought. If you set max-object-size on a cache_dir,
it effectively allows an object to use up to max-object-size woth of RAM
before it will start to swap out. I can understand this being needed if
there is no content-length header, but should the following code also do a
check against the content-length header if the header has given us a size?

store.c near line 200:

    if ((e->store_status != STORE_OK) && (swapout_size <
store_maxobjsize)) {
        /*
         * NOTE: the store_maxobjsize here is the max of optional
         * max-size values from 'cache_dir' lines. It is not the
         * same as 'maximum_object_size'. By default, store_maxobjsize
         * will be set to -1. However, I am worried that this
         * deferance may consume a lot of memory in some cases.
         * It would be good to make this decision based on reply
         * content-length, rather than wait to accumulate huge
         * amounts of object data in memory.
         */
        debug(20, 5) ("storeSwapOut: Deferring starting swapping out\n");
        return;
    }

i.e. should it look like:
if ((e->store_status != STORE_OK) && (swapout_size < store_maxobjsize) &&
(e->mem_obj->reply->content_length < 0)) {

If e->mem_obj->reply->content_length is > 0, I don;t believe that we need
to wait for the object to grow too large before we can make a decision on
where to store it.

Steven
Received on Mon Aug 07 2006 - 17:51:46 MDT

This archive was generated by hypermail pre-2.1.9 : Fri Sep 01 2006 - 12:00:03 MDT