Re: cachemgr objects return internal server errors

On Sat, 2002-10-12 at 20:50, Henrik Nordstrom wrote:

> Seems to be a general clientSendMoreData() HEAD problem.. the correct
> data gets into storeClientCallback() and passed into
> clientSendMoreData(), but the datastream then gets messed up...

Good catch. It is a consistency problem.

>
> The culpit line seems to be 1422...
>
> 1419 if (buf != result.data) {
> 1420 /* we've got to copy some data */
> 1421 assert(result.length <= next->readBuffer.length);
> 1422 xmemcpy(buf, result.data, result.length);
> 1423 body_buf = buf;
> 1424 }

Yeah, the buf != result.data test is wrong. The test needs to know how
far into buf we requested the data. I'll drill into this
tonight/tomorrow. The reason for the move is if we are given data that
is not in the client buffer we have been requested to fill.
 
> >From what I can tell this overwrites the already received data with
> the newly received data
>
> result.data points at where storeClientCopy() asked the data to be
> returned, which is in the middle of the next->readBuffer:
>
> 1536 /* TODO: copy into the supplied buffer */

This is to guarantee that clientStreamNode clients get the data where
they asked for it. Thats not actually part of the semantics at the
moment, which is why it is a TODO.

> If I comment out the block starting at 1419 then everything seems to
> work fine, but I am not sure if this has some other purpose...
>
>
> Also, a explanation of the purpose of
> context->flags.storelogiccomplete would be nice..

This is set once the store logic has been completed. I.E. all vary
processing, IMS, cache hit/miss logic is complete. clientGetMoreData
uses this to determine if it needs to lookup data or simply call
clientStoreCopy.

Rob