You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by "Chou, Peter" <pb...@labs.att.com> on 2018/08/17 18:29:47 UTC

GitHub Issue #3991 - Truncate byte range responses with RWW.

Hi All,

I opened an issue on GitHub #3991 a while back. Somebody just responded that they may be seeing the same thing. Thought I would try the mailing list for some additional exposure :).

We were running 6.2.1 with RWW=1, and we found that byte range request responses were truncated. We thought this might be related to the old Jira TS-2314 and TS-1955 so we used the same work-around of RWW=2 (which disables RWW for byte range requests -- forwards to origin without waiting). Of course, this is not ideal in terms of protecting the origin from thundering herd. So is anyone else seeing this problem or have any ideas?

In our case, the full files are multiple megabytes in length, and each byte range request is a 1MB portion of the full file. The symptom is the byte range response is truncated to less than 1MB by some tens of KB. Our cache fragment size is the default of 1MB -- not sure if this is just coincidence.

Thanks,
Peter

Re: GitHub Issue #3991 - Truncate byte range responses with RWW.

Posted by Leif Hedstrom <zw...@apache.org>.
I can’t look at these issues now , but we fixed an issue with parent proxies and truncated range requests. They happened the object went stale, and the origin responded with a 304 (if I recall).

— Leif 

> On Aug 17, 2018, at 10:29, Chou, Peter <pb...@labs.att.com> wrote:
> 
> Hi All,
>  
> I opened an issue on GitHub #3991 a while back. Somebody just responded that they may be seeing the same thing. Thought I would try the mailing list for some additional exposure J.
>  
> We were running 6.2.1 with RWW=1, and we found that byte range request responses were truncated. We thought this might be related to the old Jira TS-2314 and TS-1955 so we used the same work-around of RWW=2 (which disables RWW for byte range requests -- forwards to origin without waiting). Of course, this is not ideal in terms of protecting the origin from thundering herd. So is anyone else seeing this problem or have any ideas?
>  
> In our case, the full files are multiple megabytes in length, and each byte range request is a 1MB portion of the full file. The symptom is the byte range response is truncated to less than 1MB by some tens of KB. Our cache fragment size is the default of 1MB -- not sure if this is just coincidence.
>  
> Thanks,
> Peter

Re: GitHub Issue #3991 - Truncate byte range responses with RWW.

Posted by Leif Hedstrom <zw...@apache.org>.
I can’t look at these issues now , but we fixed an issue with parent proxies and truncated range requests. They happened the object went stale, and the origin responded with a 304 (if I recall).

— Leif 

> On Aug 17, 2018, at 10:29, Chou, Peter <pb...@labs.att.com> wrote:
> 
> Hi All,
>  
> I opened an issue on GitHub #3991 a while back. Somebody just responded that they may be seeing the same thing. Thought I would try the mailing list for some additional exposure J.
>  
> We were running 6.2.1 with RWW=1, and we found that byte range request responses were truncated. We thought this might be related to the old Jira TS-2314 and TS-1955 so we used the same work-around of RWW=2 (which disables RWW for byte range requests -- forwards to origin without waiting). Of course, this is not ideal in terms of protecting the origin from thundering herd. So is anyone else seeing this problem or have any ideas?
>  
> In our case, the full files are multiple megabytes in length, and each byte range request is a 1MB portion of the full file. The symptom is the byte range response is truncated to less than 1MB by some tens of KB. Our cache fragment size is the default of 1MB -- not sure if this is just coincidence.
>  
> Thanks,
> Peter