On Sat, 5 Aug 2006, Henrik Nordstrom wrote:
> l??r 2006-08-05 klockan 17:27 +0800 skrev Steven:
>
> > No worries, that's what I was expecting to hear.
>
> Ok.
>
> > I can reproduce the problem here
>
> Good. Makes life easier.
>
I think the problem is that because I'm playing with COSS, i've got
max-object-size set. The following code then kicks in (store_swapout.c
around line 200):
* the swapout based upon size
*/
swapout_size = mem->inmem_hi - mem->swapout.queue_offset;
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
<snip>
*/
return;
}
Once an object reachs store_maxobjsize (in my case 128K), it falls through
and eventually runs storeCheckCachable() and figures out that the object
is not cachable. The problem here is that if all data has been sent to
the client, there is nothing to kick the store entry into freeing the
memory.
The attached patch is one solution. The other option I can see would be
to call storeCheckCachable() just before line 212:
swapout_able = storeSwapOutMaintainMemObject(e);
I think the attached patch is the better option.
Steven
Index: store_swapout.c
===================================================================
RCS file: /server/cvs-server/squid/squid/src/store_swapout.c,v
retrieving revision 1.94
diff -u -r1.94 store_swapout.c
--- store_swapout.c 2 Jun 2006 00:07:40 -0000 1.94
+++ store_swapout.c 7 Aug 2006 09:39:16 -0000
@@ -243,8 +243,13 @@
assert(mem->inmem_lo == 0);
if (storeCheckCachable(e))
storeSwapOutStart(e);
- else
+ else {
+ /* Now that we know the data is not cachable, free the memory
+ * to make sure the forwarding code does not defer the connection
+ */
+ storeSwapOutMaintainMemObject(e);
return;
+ }
/* ENTRY_CACHABLE will be cleared and we'll never get here again */
}
if (NULL == mem->swapout.sio)
