You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@trafficserver.apache.org by Igor Galić <i....@brainsware.org> on 2015/02/18 10:05:18 UTC
ERR_READ_ERROR/200 ... TIMEOUT_DIRECT
Fellow humans,
we have a peculiar network setup in our infrastructure that
forces us to use ipv6 for pretty much every machine, except
for those few that really need to be reachable by the outside
world. because we've been putting off to setup our own nat64
gateway, we're using a public one, but it's *slooooow*, like
a really slow thing. we can feel this particularly with package
downloads which are not available via ipv6 (ppa.launchpad.net
and many others…).
but that's a known and easily solved problem! we can just put
traffic server as forward proxy to cache our package downloads!
well, yesno… for particularly large packages traffic server
seems to abort the connection (transaction?)
pkg02% curl --keepalive-time 900 -ivx http://pkg.esat:3142 http://repos.azulsystems.com/ubuntu/pool/main/zulu1.8.0_31-8.5.0.1_amd64.deb >/dev/null
* Hostname was NOT found in DNS cache
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 2a01:4f8:211:9d6::126...
* Connected to pkg.esat (2a01:4f8:211:9d6::126) port 3142 (#0)
> GET http://repos.azulsystems.com/ubuntu/pool/main/zulu1.8.0_31-8.5.0.1_amd64.deb HTTP/1.1
> User-Agent: curl/7.35.0
> Host: repos.azulsystems.com
> Accept: */*
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 200 OK
< x-amz-id-2: qGbKzSL/PzHYeKH7ZrBB4dpV/fEEIhjUoIenhl7/0RtvjPFJgiCoExSDCR04oKFI
< x-amz-request-id: 1010A0D32A1AE6B2
< Date: Wed, 18 Feb 2015 08:15:49 GMT
< x-amz-meta-s3cmd-attrs: uid:10116/gname:eroper/uname:eroper/gid:10116/mode:33188/mtime:1422558044/atime:1422558044/md5:7d5b314849fbba47ddcaeccf257ca4
e7/ctime:1422558044
< Last-Modified: Thu, 29 Jan 2015 20:59:35 GMT
< ETag: "7d5b314849fbba47ddcaeccf257ca4e7"
< Content-Type: application/x-debian-package
< Content-Length: 77361366
* Server ATS/5.2.0 is not blacklisted
< Server: ATS/5.2.0
< Age: 1
< Proxy-Connection: keep-alive
< Via: http/1.1 <proxy_name> (ApacheTrafficServer/5.2.0 [uScMsSf pSeN:t cCMi p sS])
<
{ [data not shown]
1 73.7M 1 1057k 0 0 8686 0 2:28:26 0:02:04 2:26:22 0* transfer closed with 76278642 bytes remaining to read
1 73.7M 1 1057k 0 0 8645 0 2:29:08 0:02:05 2:27:03 0
* Closing connection 0
curl: (18) transfer closed with 76278642 bytes remaining to read
pkg02%
the squid.blob then reads:
1424247473.770 125226 2a01:4f8:211:9d6::126 ERR_READ_ERROR/200 638 GET http://repos.azulsystems.com/ubuntu/pool/main/zulu1.8.0_31-8.5.0.1_amd64.deb - TIMEOUT_DIRECT/repos.azulsystems.com application/x-debian-package
note that curl does *not* abort, when i download this without -x proxy.
but it does take about 25~ minutes to download.
the following changes have shown neither positive or negative effect:
proxy.config.http.transaction_no_activity_timeout_out => 120 # default 30
proxy.config.http.down_server.abort_threshold => 30 # default 10
i've also tried using tspush to push the artefact into traffic server's
cache (after changing proxy.config.http.push_method_enabled to 1), with
no success:
pkg02% perl tspush -f zulu1.8.0_31-8.5.0.1_amd64.deb -u http://repos.azulsystems.com/ubuntu/pool/main/zulu1.8.0_31-8.5.0.1_amd64.deb -s http://127.0.0.1:3142
HTTP/1.0 400 Response Not Cachable
Date: Wed, 18 Feb 2015 09:02:57 GMT
Via: http/1.1 <proxy_name> (ApacheTrafficServer/5.2.0 [uEc s f p eH:t cC i p s ])
Server: ATS/5.2.0
Cache-Control: no-store
Content-Type: text/html
Content-Language: en
Content-Length: 207
and from the logs:
20150218.09h02m57s RESPONSE: sent 127.0.0.1 status 400 (Response Not Cachable) for 'http://repos.azulsystems.com/ubuntu/pool/main/zulu1.8.0_31-8.5.0.1_amd64.deb'
1424250177.091 0 127.0.0.1 ERR_INVALID_REQ/400 477 PUSH http://repos.azulsystems.com/ubuntu/pool/main/zulu1.8.0_31-8.5.0.1_amd64.deb - NONE/- text/html
--
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/
GPG: 8716 7A9F 989B ABD5 100F 4008 F266 55D6 2998 1641
Re: ERR_READ_ERROR/200 ... TIMEOUT_DIRECT
Posted by Igor Galić <i....@brainsware.org>.
----- On 18 Feb, 2015, at 13:16, Luca Rea luca.rea@contactlab.com wrote:
> Hi Igalic,
> can you test the following parameters?
>
> CONFIG proxy.config.http.accept_no_activity_timeout INT 900
> CONFIG proxy.config.http.connect_attempts_timeout INT 900
done, both with no success.
i wonder how long until the origin server starts rate-limiting me ;)
--
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/
GPG: 8716 7A9F 989B ABD5 100F 4008 F266 55D6 2998 1641
RE: ERR_READ_ERROR/200 ... TIMEOUT_DIRECT
Posted by Luca Rea <lu...@contactlab.com>.
Hi Igalic,
can you test the following parameters?
CONFIG proxy.config.http.accept_no_activity_timeout INT 900
CONFIG proxy.config.http.connect_attempts_timeout INT 900
Re: ERR_READ_ERROR/200 ... TIMEOUT_DIRECT
Posted by Igor Galić <i....@brainsware.org>.
----- On 18 Feb, 2015, at 11:55, Luca Rea luca.rea@contactlab.com wrote:
> Hi,
> in your previous email I read "Proxy-Connection: keep-alive", what are your
> keep-alive timeouts ?
they are unchanged from the defaults:
pkg02% sudo traffic_line -m 'proxy.config.*keep.*time'
proxy.config.http.keep_alive_no_activity_timeout_in 115
proxy.config.http.keep_alive_no_activity_timeout_out 120
proxy.config.prefetch.keepalive_timeout 900
setting
* proxy.config.prefetch.keepalive_timeout 2700
* proxy.config.http.keep_alive_no_activity_timeout_out 2700
* proxy.config.http.keep_alive_no_activity_timeout_in to 2700
did nothing.
the transfer still breaks off after around 6-10% (of 77MiB)
-- i
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/
GPG: 8716 7A9F 989B ABD5 100F 4008 F266 55D6 2998 1641
RE: ERR_READ_ERROR/200 ... TIMEOUT_DIRECT
Posted by Luca Rea <lu...@contactlab.com>.
Hi,
in your previous email I read "Proxy-Connection: keep-alive", what are your keep-alive timeouts ?
Re: ERR_READ_ERROR/200 ... TIMEOUT_DIRECT
Posted by Igor Galić <i....@brainsware.org>.
----- On 18 Feb, 2015, at 10:17, Uri Shachar <us...@hotmail.com> wrote:
> On Wed, 18 Feb 2015 09:05:18 +0000 Igor Galic wrote: > well, yesno… for
> particularly large packages traffic server > seems to abort the connection
> (transaction?) ... > the following changes have shown neither positive or
> negative effect: > > proxy.config.http.transaction_no_activity_timeout_out =>
> 120 # default 30 > proxy.config.http.down_server.abort_threshold => 30 #
> default 10 Did you try increasing
> proxy.config.http.transaction_active_timeout_in? The default is 15 minutes....
> Cheers, Uri
nope, haven't tried that yet. (trying now, will report back)
but even with 15 (now 45) minutes, it shouldn't cut off after two~ minutes
i
--
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/
GPG: 8716 7A9F 989B ABD5 100F 4008 F266 55D6 2998 1641
RE: ERR_READ_ERROR/200 ... TIMEOUT_DIRECT
Posted by Uri Shachar <us...@hotmail.com>.
On Wed, 18 Feb 2015 09:05:18 +0000 Igor Galic wrote:
> well, yesno… for particularly large packages traffic server
> seems to abort the connection (transaction?)
...
> the following changes have shown neither positive or negative effect:
>
> proxy.config.http.transaction_no_activity_timeout_out => 120 # default 30
> proxy.config.http.down_server.abort_threshold => 30 # default 10
Did you try increasing proxy.config.http.transaction_active_timeout_in? The default is 15 minutes....
Cheers,
Uri