> -Original Message-
> From: Henrik Nordstrom [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, March 15, 2005 11:03 AM
> To: [EMAIL PROTECTED]
> Cc: Squid Developers
> Subject: Re: epoll squid-2.5
>
> On Mon, 14 Mar 2005 [EMAIL PROTECTED] wrote:
>
> > ps. I've hacked together the visolve real
Here is the patch :)
diff -Nur squid-2.5.STABLE9/src/cf.data.pre
squid-2.5.STABLE9-expire/src/cf.data.pre
--- squid-2.5.STABLE9/src/cf.data.pre 2005-02-22 21:06:34.0
-0300
+++ squid-2.5.STABLE9-expire/src/cf.data.pre2005-03-15
00:43:53.131302928 -0300
@@ -1698,7 +1698,7 @@
On Tue, 15 Mar 2005, Steven Wilton wrote:
Just to check that I understand correctly, if there was an error doing a
write once close_request is set to 1, it is object will (most likely) still
be incomplete on disk when squid thinks the object is completely written to
disk.
No, in such case the I/O c
On Mon, 14 Mar 2005 [EMAIL PROTECTED] wrote:
ps. I've haved together the visolve realtime signal code with the squid
3.0 epoll code to make a version of squid 2.5 that supports epoll. It
overrides the select and poll methods, but it does scale very well.
Interesting!
Is this something you'd like
On Tue, 15 Mar 2005, Henrik Nordstrom wrote:
On Mon, 14 Mar 2005 [EMAIL PROTECTED] wrote:
written to disk. The attached patch seems to fix this by fixing what
seems to be a logic flaw.
Indeed.
I am collecting this and more (including patches) in the already open aufs
bug report #671.
Regards
He
On Mon, 14 Mar 2005 [EMAIL PROTECTED] wrote:
I tried enabling the ASYNC_WRITE define in src/fs/aufs/store_asyncufs.h
and found that the the cache log was filling up with "this be aioCancel.
Danger ahead!" errors. The squid-users list says that these errors are
harmless, but I found that they were
I noticed that squid checks if it is running by checking if pid file
exists. I think it will be better to check if there is really process
with that pid like:
if(kill(pid,0)==0){//squid is running
}else{ // no process
//unlink the pid file
}
I don't know how kill is implemented in other operat
Hi all,
I'm trying to trace the bug solved by squid-2.5.STABLE9-setcookie.patch
and see if it applies to the current stable debian package.
It appears that this bug was introduced in squid-2.5-STABLE7. Can
somebody point me to the patch that introduced it? I could not find any
reference in bugzill
Hi,
I tried enabling the ASYNC_WRITE define in src/fs/aufs/store_asyncufs.h
and found that the the cache log was filling up with "this be aioCancel.
Danger ahead!" errors. The squid-users list says that these errors are
harmless, but I found that they were not, as objects were not being fully
wri
