Hiya,
I've created a new branch with my logging daemon framework.
Its pretty rough and very vaguely tested.
I'd like some feedback on the general direction I'm taking with
the aim to get it committed within the next couple of weeks or
so.
Adrian
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
There was a posting to squid-users with the following log messages in the
cache log:
2006/08/04 16:01:42| WARNING! Your cache is running out of filedescriptors
2006/08/04 16:01:42| comm_call_handlers(): WARNING defer handler for
fd=12 (desc=HTTP Socket) does not call commDeferFD() - backing off
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
mån 2006-08-07 klockan 18:26 +0800 skrev Steven:
2006/08/04 16:01:42| WARNING! Your cache is running out of filedescriptors
2006/08/04 16:01:42| comm_call_handlers(): WARNING defer handler for
fd=12 (desc=HTTP Socket) does not call commDeferFD() - backing off
manually
Thinking.. what is the
On Mon, 7 Aug 2006, Henrik Nordstrom wrote:
m??n 2006-08-07 klockan 18:26 +0800 skrev Steven:
2006/08/04 16:01:42| WARNING! Your cache is running out of filedescriptors
2006/08/04 16:01:42| comm_call_handlers(): WARNING defer handler for
fd=12 (desc=HTTP Socket) does not call
mån 2006-08-07 klockan 13:04 +0200 skrev Guido Serassio:
Yes, I also prefer a solution without any special markup, but this
solution warrants that the commiter must know what is doing, and it's
a not so big effort like the old 2.5 patch management :-)
What about the following simple
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:24 +0800 skrev Steven:
If you let the defer function call commDeferFD, you don't run through the
comm loop 2 times to cause a FD to back off (once to set the defer/backoff
flag, and once to actually back off). The code in the comm loop is there
as a fail-safe, but
On Mon, 7 Aug 2006, Henrik Nordstrom wrote:
m??n 2006-08-07 klockan 19:24 +0800 skrev Steven:
But the defer function is only called from there..
how could the number of loops differ if it's the defer function calling
commDeferFD or if it's the only caller which does this automatically
Hi Henrik,
At 13.33 07/08/2006, Henrik Nordstrom wrote:
mån 2006-08-07 klockan 13:04 +0200 skrev Guido Serassio:
Yes, I also prefer a solution without any special markup, but this
solution warrants that the commiter must know what is doing, and it's
a not so big effort like the old 2.5
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 14:44 +0200 skrev Guido Serassio:
What about an optional tag allowing a minimum length override ?
If we go to the tagged/guided form there will most likely be no lower
limits other than there must be a title and a following description.
For now I thinkt I'll just ignore
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
lör 2006-07-29 klockan 09:35 +0200 skrev Guido Serassio:
I have found an occasional DNS resolution error when browsing
www.microsoft.com.
I have seen the error only few times, less then 10, but the odd thing
is that this happens always only with www.microsoft.com and sometime
it was
Hi Henrik,
At 17.10 07/08/2006, Henrik Nordstrom wrote:
lör 2006-07-29 klockan 09:35 +0200 skrev Guido Serassio:
I have found an occasional DNS resolution error when browsing
www.microsoft.com.
I have seen the error only few times, less then 10, but the odd thing
is that this happens
Hi Henrik,
At 16.08 07/08/2006, Henrik Nordstrom wrote:
mån 2006-08-07 klockan 14:44 +0200 skrev Guido Serassio:
What about an optional tag allowing a minimum length override ?
If we go to the tagged/guided form there will most likely be no lower
limits other than there must be a title and
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
19 matches
Mail list logo
