You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@trafficserver.apache.org by Jeremy Payne <jp...@gmail.com> on 2017/09/22 22:45:56 UTC

ATS 6.2.1 + cache read

Question.. Is there a known issue with ATS 6.2.1(or any version),
where if ATS can't read from
cache fast enough for a given object, ATS simply sends an IMS to the
origin, instead of waiting for a response from the cache lookup ?

I am noticing that if multiple requests fall in the same second for a
given object, that ATS gives up
trying to read from cache, and simply sends an IMS to the origin.

Known issue? Or possible PEBCAK error again ?

Re: ATS 6.2.1 + cache read

Posted by Steven Hunter <st...@gmail.com>.
The new w7pre hds overrides operations and shuts down memories overload
capabilities...

On Sat, Sep 23, 2017 at 3:36 PM, Leif Hedstrom <zw...@apache.org> wrote:

> Hmmm but there are settings for this, overridable, to retry the cache
> operation some number of times. You will want read-while-writer too.
>
> — Leif
>
> On Sep 22, 2017, at 17:15, Alan Carroll <so...@oath.com> wrote:
>
> I think this is a known issue for a long time. What's happening is the
> requests are trying to get the write lock on the object and failing, which
> results in giving up and going direct to origin. There might be a collapsed
> forwarding plugin which sort of mitigates this. There is on going work on
> fixing it but that's not ready for production yet.
>
> On Fri, Sep 22, 2017 at 5:45 PM, Jeremy Payne <jp...@gmail.com> wrote:
>
>> Question.. Is there a known issue with ATS 6.2.1(or any version),
>> where if ATS can't read from
>> cache fast enough for a given object, ATS simply sends an IMS to the
>> origin, instead of waiting for a response from the cache lookup ?
>>
>> I am noticing that if multiple requests fall in the same second for a
>> given object, that ATS gives up
>> trying to read from cache, and simply sends an IMS to the origin.
>>
>> Known issue? Or possible PEBCAK error again ?
>>
>
>

Re: ATS 6.2.1 + cache read

Posted by Leif Hedstrom <zw...@apache.org>.
Hmmm but there are settings for this, overridable, to retry the cache operation some number of times. You will want read-while-writer too.

— Leif 

> On Sep 22, 2017, at 17:15, Alan Carroll <so...@oath.com> wrote:
> 
> I think this is a known issue for a long time. What's happening is the requests are trying to get the write lock on the object and failing, which results in giving up and going direct to origin. There might be a collapsed forwarding plugin which sort of mitigates this. There is on going work on fixing it but that's not ready for production yet.
> 
>> On Fri, Sep 22, 2017 at 5:45 PM, Jeremy Payne <jp...@gmail.com> wrote:
>> Question.. Is there a known issue with ATS 6.2.1(or any version),
>> where if ATS can't read from
>> cache fast enough for a given object, ATS simply sends an IMS to the
>> origin, instead of waiting for a response from the cache lookup ?
>> 
>> I am noticing that if multiple requests fall in the same second for a
>> given object, that ATS gives up
>> trying to read from cache, and simply sends an IMS to the origin.
>> 
>> Known issue? Or possible PEBCAK error again ?
> 

Re: ATS 6.2.1 + cache read

Posted by Alan Carroll <so...@oath.com>.
I think this is a known issue for a long time. What's happening is the
requests are trying to get the write lock on the object and failing, which
results in giving up and going direct to origin. There might be a collapsed
forwarding plugin which sort of mitigates this. There is on going work on
fixing it but that's not ready for production yet.

On Fri, Sep 22, 2017 at 5:45 PM, Jeremy Payne <jp...@gmail.com> wrote:

> Question.. Is there a known issue with ATS 6.2.1(or any version),
> where if ATS can't read from
> cache fast enough for a given object, ATS simply sends an IMS to the
> origin, instead of waiting for a response from the cache lookup ?
>
> I am noticing that if multiple requests fall in the same second for a
> given object, that ATS gives up
> trying to read from cache, and simply sends an IMS to the origin.
>
> Known issue? Or possible PEBCAK error again ?
>