Re: [squid-users] squid 2.6-rproxy: assertion store_client.c:211: "sc->cmp_offset == copy_offset"

On Tuesday 11 June 2002 21:51, Jeffrey D. Wheelhouse wrote:
> > -----Original Message-----
> > Try the following in squid.conf as a workaround:
> >
> > pipeline_prefetch off
> >
> > Please report back to the squid-dev list.
>
> In the past twelve hours, the "pipeline_prefetch off" accelerators
> did not crash. Boxes in the control group that didn't have this
> crashed an average of four times.

Good.

> This seems like a good workaround.

Will probably make it the default.. there is other perhaps more
serious issues with pipeline_prefetch.

> If I can help debug the pipelining problem or test fixes since I
> get it reliably, please let me know.

It is a bit of a design issue here.. The new store client
implementation does not allow reading of what has already been read,
and the pipeline apparently prefetch relied on this ability..

The question to figure out is why has some data already been read from
the reply when it was not the one currently being sent to the client?

The answer: Because the request processing does not figure out that
the reply is not the current one until there is data.. see
clientSendMoreData().

So what is needed to be done is that clientSendMoreData() needs to
buffer the received data somehow (or actually the fact that there is
data, the buffer is there already), and then start by sending this
out when sending out the reply in clientKeepaliveNextRequest()...
best done by having clientKeepaliveNextRequest() calling
clientSendMoreData() with the same arguments if data had arrived. If
data has not yet arrived I don't think clientKeepaliveNextRequest()
actaully needs to do anything..

On other words, the logics in clientKeepaliveNextRequest() that today
reads

        if (0 == storeClientCopyPending(http->sc, entry, http)) {
...
                storeClientCopy()

needs to read

        if (data had arrived to clientSendMoreData for the request) {
...
                /* process the same data again ...*/
                clientSendMoreData(...)

Regards
Henrik
Received on Tue Jun 11 2002 - 17:09:38 MDT