Re: a refresh problem?

--MimeMultipartBoundary
Content-Type: text/plain; charset=us-ascii

> Oskar Pearson writes:
>
> >access log came up with:
> >
> >888357400.553 17 196.23.0.160 TCP_HIT/200 7158 GET http://www.altavista.di
> gital.com/ - NONE/- text/html
> >888357404.655 2239 196.23.0.160 TCP_CLIENT_REFRESH/200 11160 GET http://www.
> altavista.digital.com/ - DIRECT/www.altavista.digital.com text/html
> >888357406.065 18 196.23.0.160 TCP_HIT/200 7158 GET http://www.altavista.di
> gital.com/ - NONE/- text/html
>
> This is my assessment:
>
> The ASYNC_IO code is reading more from disk than it should be.
>
> The client side asks to fill a 4KB buffer:
>
> 1998/02/24 23:56:26| storeClientCopy: 3AB79EC8F47EF63C16B971700C7CF709,
> seen 0, want 0, size 4096, cb 0x80551c0, cbdata 0x840a600
>
> But aiops.c actually reads 8KB
>
> 1998/02/24 23:56:26| READ on fd: 22
> 1998/02/24 23:56:26| DONE: 8192 -> 4
>
> Then the client side asks for bytes 4097-8192
>
> 1998/02/24 23:56:26| storeClientCopy: 3AB79EC8F47EF63C16B971700C7CF709,
> seen 4096, want 4096, size 4096, cb 0x8055290, cbdata 0x840a600
>
> And aiops.c reads bytes 8193-11160
>
> 1998/02/24 23:56:26| READ on fd: 22
> 1998/02/24 23:56:26| DONE: 3048 -> 4
>
> And there's your courruption....

        What the ????

        The ASYNC library simply passes the variables its being given onto
the read() call. There may be final corruption on the end result, but some
where 4096 is being turned into 8192, and it sure isn't in the aiops.c or
async_io.c code. I'll take a dig.

        There is one outstanding race condition with the aiops.c code that
I've found. Not sure if it's been patched yet by somebody else.

        Stew.

--MimeMultipartBoundary--
Received on Tue Jul 29 2003 - 13:15:46 MDT