Re: Progressive download

[Brian Geffon <br...@apache.org>]

Sounds like it wasn't properly linked, it's missing the symbol

BgFetchConfig::readConfig(const char *config_file)

Which is configs.cc. I checked Makefile.am for background_fetch and it
appears that it should be compiling and linking properly. Did you build
this plugin in a strange way, for example by using tsxs or a hand rolled
makefile?

Brian

On Wed, Oct 7, 2015 at 1:09 PM, Sudheer Vinukonda <su...@yahoo-inc.com>
wrote:

> Adding dev@ and users@ - perhaps, someone else might have run into the
> same issue?
>
>
> Sent from Yahoo Mail for iPhone <https://yho.com/footer0>
>
> On Oct 6, 2015, 10:04:26 PM, Umamaheswari Muthu wrote:
> Hi Sudheer,
>
> I compiled and installed the background_fetch plugin. But when i restarted
> the ATS I am getting the FATAL error as *undefined symbol:
> _ZN13BgFetchConfig10readConfigEPKc *unable to load background_fetch.so
> file.
>
> *in plugin.config added*
>
> background_fetch.so --config
> /opt/ts/etc/trafficserver/background_fetch.config
>
> *and in background_fetch.config*
>
> include Content-Type video/mp4
>
> Let me know if i have missed anything else.
>
> Thanks
>
> On Wed, Oct 7, 2015 at 7:12 AM, Sudheer Vinukonda <su...@yahoo-inc.com>
> wrote:
>
>> Ah, you are doing a progressive download (partial byte range request).
>>
>> ATS doesn't support caching partial byte range responses, but it does
>> support serving byte range requests from an already cached object.
>>
>> You may use background_fetch plugin which can automatically download the
>> full object in the background ln receiving a byte range response.
>>
>> Thanks,
>>
>> Sudheer
>>
>> Sent from Yahoo Mail for iPhone <https://yho.com/footer0>
>>
>> On Oct 6, 2015, 6:34:52 PM, Umamaheswari Muthu wrote:
>> Hi,
>>
>> I still see TCP_MISS, even if i hit after some delay. And this issue
>> happens only for .mp4 file which makes byte range-request(206),
>> There are other .m3u8,xml,doc files those are getting cached properly.Do
>> i need to enable any other configuration for byte range request?
>>
>> Thanks,
>>
>> On Wed, Oct 7, 2015 at 6:20 AM, Sudheer Vinukonda <sudheerv@yahoo-inc.com
>> > wrote:
>>
>>> What happens when you issue the requests with a small delay (a few
>>> seconds) in between? Are you seeing a TCP_HIT then or still a TCP_MISS?
>>>
>>>
>>>
>>> On Tuesday, October 6, 2015 4:22 AM, Umamaheswari Muthu <
>>> umamaheswari.soft@gmail.com> wrote:
>>>
>>>
>>> Hi,
>>>
>>> Both the request is exactly the same.
>>>
>>> http://10.10.26.78/Sample.mp4 was hit from the browser in 2 hits. Both
>>> the hits is giving TCP_MISS and fetching from the origin.
>>>
>>> This is the response i get in custom_ats.log
>>>
>>> 1444108139.831 chi=10.27.4.10 phn=10.10.26.78 shn=10.10.26.77 url=
>>> http://10.10.26.78/Sample.mp4 cqhm=GET cqhv=HTTP/1.1 pssc=*206* ttms=5
>>> b=1 sssc=206 sscl=1 cfsc=FIN pfsc=FIN crc=TCP_MISS phr=DIRECT
>>> uas="Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko)
>>> Chrome/45.0.2454.85 Safari/537.36"
>>>
>>> in remap.config entry is
>>>
>>> map http://10.10.26.78 http://10.10.26.77/
>>>
>>> records.config file is attached.
>>>
>>> Any configuration am I missing? Is it possible to force ATS to retrieve
>>> an object from origin server for only once for a cache-miss object?
>>>
>>> Thanks.
>>>
>>> On Tue, Oct 6, 2015 at 2:59 PM, Sudheer Vinukonda <
>>> sudheerv@yahoo-inc.com> wrote:
>>>
>>> Are both request URLs exactly identical? ATS by default uses the entire
>>> URL as the cache key, so, even if the requests have different query params,
>>> they will be considered as two different cache objects. You may need to
>>> strip the query params if that's the case (examples, cacheurl plugin, or
>>> regex_remap plugin).
>>>
>>> Thanks,
>>>
>>> Sudheer
>>>
>>>
>>> Sent from Yahoo Mail for iPhone <https://yho.com/footer0>
>>>
>>> On Oct 6, 2015, 2:10:14 AM, Umamaheswari Muthu wrote:
>>> Hi,
>>>
>>> I am testing ATS 6.1.0 as a reverse proxy cache.
>>> There are two client connections requesting the same .mp4 object. I
>>> expect there shall be only one request to the origin server for one of the
>>> objects. But each hit or each request is fetching the data from origin
>>> instead of ATS cache.
>>>
>>> I have enabled the Read While Writer option followed the guide:
>>>
>>> CONFIG proxy.config.cache.enable_read_while_writer INT 1
>>> CONFIG proxy.config.http.background_fill_active_timeout INT 0
>>> CONFIG proxy.config.http.background_fill_completed_threshold FLOAT
>>> 0.000000
>>> CONFIG proxy.config.cache.max_doc_size INT 0
>>>
>>> And also set the Open Read Retry Timeout:
>>>
>>> CONFIG proxy.config.http.cache.max_open_read_retries INT 10
>>> CONFIG proxy.config.http.cache.open_read_retry_time INT 10
>>>
>>> I have tried the proxy.config.http.cache.max_open_read_retries as -1 or
>>> 100, but the results are the same.
>>>
>>> Any configuration am I missing? Is it possible to force ATS to retrieve
>>> an object from origin server for only once for a cache-miss object?
>>>
>>> Thanks,
>>> Uma
>>>
>>>
>>>
>>>
>>>
>>
>

Re: Progressive download

[Brian Geffon <br...@apache.org>]

It just sounds like he was using tsxs to build the plugin and linked with
only 1 of 6 or so of the compilation units required. Compiling with -O0
shouldn't make a difference.

Brian

On Wed, Oct 7, 2015 at 2:54 PM, Nick Kew <ni...@apache.org> wrote:

> On Wed, 2015-10-07 at 13:24 +0800, Brian Geffon wrote:
> > Sounds like it wasn't properly linked, it's missing the symbol
>
> Some build inconsistency between the plugin and the core.
>
> > BgFetchConfig::readConfig(const char *config_file)
>
> Could the compiler have optimised out that symbol?
> Does compiling with -O0 make any difference?
>
> --
> Nick Kew
>
>

Re: Progressive download

[Nick Kew <ni...@apache.org>]

On Wed, 2015-10-07 at 13:24 +0800, Brian Geffon wrote:
> Sounds like it wasn't properly linked, it's missing the symbol

Some build inconsistency between the plugin and the core.

> BgFetchConfig::readConfig(const char *config_file)

Could the compiler have optimised out that symbol?
Does compiling with -O0 make any difference?

-- 
Nick Kew