You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@trafficserver.apache.org by 오재경 <ge...@gmail.com> on 2013/05/30 09:05:48 UTC

why does a range request get in CACHE_EVENT_OPEN_WRITE?

Hi. how are you?

I converted rfc5861 plugin to a plugin that triggers a download from origin
server when it gets cache miss about the range request.

But the problem is background download hardly get cached at once. usually
it gets cached after 5~10 times background download.

So i traced the full debug log of ATS.

i found a range request also get in CACHE_EVENT_OPEN_WRITE, which finally
comes to "[is_response_cacheable] Partial content response - don't cache".

Meanwhile the triggered full contents download fails to get "(http_cache)
[41] [&HttpCacheSM::state_cache_open_write, CACHE_EVENT_OPEN_WRITE_FAILED]".

That happens several times until background download get cached and gives
heavy traffic to origin server.

Why does a range request get in CACHE_EVENT_OPEN_WRITE none the less it
won't be cached?

How can i force ATS to cache the background download at the first time? or
is there any way ATS have range request not get in CACHE_EVENT_OPEN_WRITE?


Thanks in advance.

P.S. i'm afraid it happens also in the case we
use background_fill_completed option. if there are many traffic i think ATS
can't assure the background_fill will be cached at once because of the
cache open write lock.

Re: unsubscribe

Posted by Reindl Harald <h....@thelounge.net>.
Am 01.06.2013 02:45, schrieb Aleksandrs Andrijenko:
> unsubsribe

how did you guys manage to subscribe without be able
to read the welcome-message like below which you got

why do you guys not look at the list-headers?
List-Help: <ma...@trafficserver.apache.org>
List-Unsubscribe: <ma...@trafficserver.apache.org>
List-Post: <ma...@trafficserver.apache.org>
List-Id: <users.trafficserver.apache.org>

it makes me tired to see this helplessness day for day
on different lists and no list footers with a unsubscribe
link does not help

*you* subscribed
*you* have to unsubscribe
*not on any* mailing-list you send unsubscribe messages to the list

-------- Original-Nachricht --------
Betreff: WELCOME to users@trafficserver.apache.org
Datum: 15 Jul 2012 18:54:42 -0000
Von: users-help@trafficserver.apache.org
An: h.reindl@thelounge.net

Hi! This is the ezmlm program. I'm managing the
users@trafficserver.apache.org mailing list.

Acknowledgment: I have added the address

   h.reindl@thelounge.net

to the users mailing list.

Welcome to users@trafficserver.apache.org!

Please save this message so that you know the address you are
subscribed under, in case you later want to unsubscribe or change your
subscription address.


--- Administrative commands for the users list ---

I can handle administrative requests automatically. Please
do not send them to the list address! Instead, send
your message to the correct command address:

To subscribe to the list, send a message to:
   <us...@trafficserver.apache.org>

To remove your address from the list, send a message to:
   <us...@trafficserver.apache.org>

Send mail to the following for info and FAQ for this list:
   <us...@trafficserver.apache.org>
   <us...@trafficserver.apache.org>

Similar addresses exist for the digest list:
   <us...@trafficserver.apache.org>
   <us...@trafficserver.apache.org>

To get messages 123 through 145 (a maximum of 100 per request), mail:
   <us...@trafficserver.apache.org>

To get an index with subject and author for messages 123-456 , mail:
   <us...@trafficserver.apache.org>

They are always returned as sets of 100, max 2000 per request,
so you'll actually get 100-499.

To receive all messages with the same subject as message 12345,
send a short message to:
   <us...@trafficserver.apache.org>

The messages should contain one line or word of text to avoid being
treated as sp@m, but I will ignore their content.
Only the ADDRESS you send to is important.

You can start a subscription for an alternate address,
for example "john@host.domain", just add a hyphen and your
address (with '=' instead of '@') after the command word:
<us...@trafficserver.apache.org>

To stop subscription for this address, mail:
<us...@trafficserver.apache.org>

In both cases, I'll send a confirmation message to that address. When
you receive it, simply reply to it to complete your subscription.

If despite following these instructions, you do not get the
desired results, please contact my owner at
users-owner@trafficserver.apache.org. Please be patient, my owner is a
lot slower than I am ;-)


Re: unsubscribe

Posted by Reindl Harald <h....@thelounge.net>.
how did you guys manage to subscribe without be able
to read the welcome-message like below which you got

why do you guys not look at the list-headers?
List-Help: <ma...@trafficserver.apache.org>
List-Unsubscribe: <ma...@trafficserver.apache.org>
List-Post: <ma...@trafficserver.apache.org>
List-Id: <users.trafficserver.apache.org>

it makes me tired to see this helplessness day for day
on different lists and no list footers with a unsubscribe
link does not help

*you* subscribed
*you* have to unsubscribe
*not on any* mailing-list you send unsubscribe messages to the list

-------- Original-Nachricht --------
Betreff: WELCOME to users@trafficserver.apache.org
Datum: 15 Jul 2012 18:54:42 -0000
Von: users-help@trafficserver.apache.org
An: h.reindl@thelounge.net

Hi! This is the ezmlm program. I'm managing the
users@trafficserver.apache.org mailing list.

Acknowledgment: I have added the address

   h.reindl@thelounge.net

to the users mailing list.

Welcome to users@trafficserver.apache.org!

Please save this message so that you know the address you are
subscribed under, in case you later want to unsubscribe or change your
subscription address.


--- Administrative commands for the users list ---

I can handle administrative requests automatically. Please
do not send them to the list address! Instead, send
your message to the correct command address:

To subscribe to the list, send a message to:
   <us...@trafficserver.apache.org>

To remove your address from the list, send a message to:
   <us...@trafficserver.apache.org>

Send mail to the following for info and FAQ for this list:
   <us...@trafficserver.apache.org>
   <us...@trafficserver.apache.org>

Similar addresses exist for the digest list:
   <us...@trafficserver.apache.org>
   <us...@trafficserver.apache.org>

To get messages 123 through 145 (a maximum of 100 per request), mail:
   <us...@trafficserver.apache.org>

To get an index with subject and author for messages 123-456 , mail:
   <us...@trafficserver.apache.org>

They are always returned as sets of 100, max 2000 per request,
so you'll actually get 100-499.

To receive all messages with the same subject as message 12345,
send a short message to:
   <us...@trafficserver.apache.org>

The messages should contain one line or word of text to avoid being
treated as sp@m, but I will ignore their content.
Only the ADDRESS you send to is important.

You can start a subscription for an alternate address,
for example "john@host.domain", just add a hyphen and your
address (with '=' instead of '@') after the command word:
<us...@trafficserver.apache.org>

To stop subscription for this address, mail:
<us...@trafficserver.apache.org>

In both cases, I'll send a confirmation message to that address. When
you receive it, simply reply to it to complete your subscription.

If despite following these instructions, you do not get the
desired results, please contact my owner at
users-owner@trafficserver.apache.org. Please be patient, my owner is a
lot slower than I am ;-)


unsubscribe

Posted by Phanindra Ganti <pg...@linkedin.com>.


unsubscribe

Posted by Aleksandrs Andrijenko <in...@eurohosting.lv>.
unsubsribe

Re: why does a range request get in CACHE_EVENT_OPEN_WRITE?

Posted by Leif Hedstrom <zw...@apache.org>.
On 5/31/13 4:54 PM, James Peach wrote:
> On May 31, 2013, at 1:32 AM, 오재경 <ge...@gmail.com> wrote:
>
>> I found a tricky solution.
>>   
>> Just let background_fill_completed work. That is the plugin disconnect right after get some from origin.
> This would be a great feature for core. It's not 100% of what people want from range requests, but it's common enough and very helpful.

+1 on adding this plugin into main git repo. It's a feature we've 
discussed in the past, and I'm sure other people would love to use it 
(and work on it).

-- Leif


Re: why does a range request get in CACHE_EVENT_OPEN_WRITE?

Posted by James Peach <jp...@apache.org>.
On May 31, 2013, at 1:32 AM, 오재경 <ge...@gmail.com> wrote:

> I found a tricky solution.
>  
> Just let background_fill_completed work. That is the plugin disconnect right after get some from origin.

This would be a great feature for core. It's not 100% of what people want from range requests, but it's common enough and very helpful.

>  
> Even if download happens a couple of times in stress test it’s better than the plugin keeps downloading again and again.
>  
> Thanks.
>  
> From: 오재경 [mailto:genextoh@gmail.com] 
> Sent: Thursday, May 30, 2013 4:06 PM
> To: users@trafficserver.apache.org
> Subject: why does a range request get in CACHE_EVENT_OPEN_WRITE?
>  
> Hi. how are you?
>  
> I converted rfc5861 plugin to a plugin that triggers a download from origin server when it gets cache miss about the range request.
>  
> But the problem is background download hardly get cached at once. usually it gets cached after 5~10 times background download.
>  
> So i traced the full debug log of ATS.
>  
> i found a range request also get in CACHE_EVENT_OPEN_WRITE, which finally comes to "[is_response_cacheable] Partial content response - don't cache".
>  
> Meanwhile the triggered full contents download fails to get "(http_cache) [41] [&HttpCacheSM::state_cache_open_write, CACHE_EVENT_OPEN_WRITE_FAILED]".
>  
> That happens several times until background download get cached and gives heavy traffic to origin server.
>  
> Why does a range request get in CACHE_EVENT_OPEN_WRITE none the less it won't be cached?
>  
> How can i force ATS to cache the background download at the first time? or is there any way ATS have range request not get in CACHE_EVENT_OPEN_WRITE?
>  
>  
> Thanks in advance.
>  
> P.S. i'm afraid it happens also in the case we use background_fill_completed option. if there are many traffic i think ATS can't assure the background_fill will be cached at once because of the cache open write lock.


RE: why does a range request get in CACHE_EVENT_OPEN_WRITE?

Posted by 오재경 <ge...@gmail.com>.
I found a tricky solution.

 

Just let background_fill_completed work. That is the plugin disconnect
right after get some from origin.

 

Even if download happens a couple of times in stress test it’s better than
the plugin keeps downloading again and again.

 

Thanks.

 

From: 오재경 [mailto:genextoh@gmail.com] 
Sent: Thursday, May 30, 2013 4:06 PM
To: users@trafficserver.apache.org
Subject: why does a range request get in CACHE_EVENT_OPEN_WRITE?

 

Hi. how are you?

 

I converted rfc5861 plugin to a plugin that triggers a download from origin
server when it gets cache miss about the range request.

 

But the problem is background download hardly get cached at once. usually
it gets cached after 5~10 times background download.

 

So i traced the full debug log of ATS.

 

i found a range request also get in CACHE_EVENT_OPEN_WRITE, which finally
comes to "[is_response_cacheable] Partial content response - don't cache".

 

Meanwhile the triggered full contents download fails to get "(http_cache)
[41] [&HttpCacheSM::state_cache_open_write, CACHE_EVENT_OPEN_WRITE_FAILED]".

 

That happens several times until background download get cached and gives
heavy traffic to origin server.

 

Why does a range request get in CACHE_EVENT_OPEN_WRITE none the less it
won't be cached?

 

How can i force ATS to cache the background download at the first time? or
is there any way ATS have range request not get in CACHE_EVENT_OPEN_WRITE?

 

 

Thanks in advance.

 

P.S. i'm afraid it happens also in the case we use
background_fill_completed option. if there are many traffic i think ATS
can't assure the background_fill will be cached at once because of the
cache open write lock.