tis 2006-08-08 klockan 07:51 +0800 skrev Steven:
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
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
mån 2006-08-07 klockan 17:50 +0800 skrev Steven:
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
On Mon, 7 Aug 2006, Henrik Nordstrom wrote:
m??n 2006-08-07 klockan 17:50 +0800 skrev Steven:
The attached patch is one solution.
Hmm. found the code not very obvious to follow here and your patch
didn't exacly improve this..
After re-reading my message, I agree it wasn't too easy to
mån 2006-08-07 klockan 19:38 +0800 skrev Steven:
From what I can tell, the attached patch will break the current
behaviour. storeCheckCachable() needs to remove the ENTRY_CACHABLE flag
so that other parts of the code know that they can free the memory.
There is only two users of
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...
Regards
Henrik
signature.asc
Description: Detta är en digitalt signerad meddelandedel
mån 2006-08-07 klockan 17:50 +0800 skrev Steven:
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
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
I had a problem today where a download for a particular file was hanging
forever after 128k. It looks like the store entry had the release
request flag set, but because all the data had been sent to the client
and the server side was being deferred, there was nothing to kick the
store entry into
On Sat, Aug 05, 2006, Steven wrote:
I had a problem today where a download for a particular file was hanging
forever after 128k. It looks like the store entry had the release
request flag set, but because all the data had been sent to the client
and the server side was being deferred, there
lör 2006-08-05 klockan 15:49 +0800 skrev Adrian Chadd:
When I went through this exercise a while ago my solution was to make sure
I 'kicked' (ie, started another comm read event) the server side if
all the clients had read all the data they could (and thus -someone- had to
kickstart an IO
On Sat, Aug 05, 2006, Henrik Nordstrom wrote:
Ideally delay pools would kick the I/O going again when the pool have
been filled up, and we could then get rid of the periodic repoll of
deferred connections relying almost exclusively on
storeDeferRead/storeResumeRead signaling to indicate when
lör 2006-08-05 klockan 15:45 +0800 skrev Steven:
if (fd = 0 mem-inmem_hi - mem-inmem_lo SM_PAGE_SIZE +
Config.Store.maxInMemObjSize + Config.readAheadGap) {
- storeDeferRead(e, fd);
- return 1;
+ if(storeLowestMemReaderOffset(e) != mem-inmem_hi) {
+
On Sat, 5 Aug 2006, Henrik Nordstrom wrote:
l??r 2006-08-05 klockan 15:45 +0800 skrev Steven:
if (fd = 0 mem-inmem_hi - mem-inmem_lo SM_PAGE_SIZE +
Config.Store.maxInMemObjSize + Config.readAheadGap) {
- storeDeferRead(e, fd);
- return 1;
+
14 matches
Mail list logo
