The second request is threated as the first.. if the cached reply
isn't suitable a cache revalidation is initiated. If two such
requests arrive at "the same time" then two cache revalidations will
be inititated.
Where things differ is after the reply headers have been received.
The new object is then marked as "public" (storeSetPublicKey()), and
any new requests received after this will hit the new object, even
while data is still being received.
This is in the default "neighbors_do_private_keys = true" scenario.
If neighbors_do_private_keys is false then I am not entirely sure on
what happens.. I have never tested the details without private keys,
and I don't think any of the other developers have either..
"neighbors_do_private_keys = false" is a Squid internal hack to work
around non-Squid ICP peers not supporting the ICP request number
field (covered by the ICP RFC, but was not implemented in the first
ICP implementations of Harvest Cached from where many other ICP
implementations have been derived).
Regards
Henrik
On Monday 06 May 2002 09:39, you wrote:
> Hi Henrik,
>
> I have been reading the squid mailing list for a
> while, searching for a solution to a problem I have. I
> saw that you had several responses and ideas on that
> issue.
>
> What I'm talking about, is a scenario that 2 (or more)
> requests for the same object come in the same time,
> and squid should not go out with two requests to the
> origin server. I know that squid should "behave well"
> with this scenario, if the object is cachable, and if
> it was not a refresh (cache-control: no-cache, etc.)
> request.
>
> My problem is, that I never succeeded using this
> feature of squid in the past. I am very familiar with
> the squid code, and I was wondering where the decision
> to treat the second request differently is made ?
>
> I know that if you use the neighbors_do_private_keys
> hack then squid will create a new StoreEntry, make it
> public key (and the previously cached one private),
> and so the next request for this object will exit in
> storeClientCopy2, because ENTRY_FWD_HDR_WAIT is set. I
> don't understand where/how squid handles the second
> request differently without this hack.
>
> Thanks in advance,
> Shlomi
>
>
>
>
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Health - your guide to health and wellness
> http://health.yahoo.com
Received on Mon May 06 2002 - 01:59:28 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:15:25 MST