[ 
https://issues.apache.org/jira/browse/TS-2306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ron Barber updated TS-2306:
---------------------------

    Attachment: TS-2306.patch

Prevent producer from running "wide open" if there is no space in the write 
buffer, thereby allowing the consumer the chance to run to consume its data.

> Client connection hang while downloading big file from origin server over SSL 
> connection
> ----------------------------------------------------------------------------------------
>
>                 Key: TS-2306
>                 URL: https://issues.apache.org/jira/browse/TS-2306
>             Project: Traffic Server
>          Issue Type: Bug
>          Components: Network, SSL
>            Reporter: Thach Tran
>             Fix For: 4.2.0
>
>         Attachments: TS-2306.patch
>
>
> Setup:
> ATS in reverse proxy mode and Apache server in the backend to serve some very 
> large test files (~10GB). Backend Apache server listens on both 80 for plain 
> HTTP and 443 for HTTPS. Remap rules for ATS (with two plain HTTP ports of 
> 8080 and 8081):
> map http://localhost:8080/ http://localhost/
> map http://localhost:8081/ https://localhost/
> What I am seeing is request for http://localhost:8081/files/testfile10g.bin 
> will hang very quickly without getting much data back while request for 
> http://localhost:8080/files/testfile10g.bin will continue to download just 
> fine until it's finished. I've tried with other smaller files (~200MB, ~1MB) 
> and it seems to work fine.
> I've disabled the caching (proxy.config.http.cache.http=0) in case it has 
> something to do with that.
> I'm wondering if this is similar to TS-2211 but in reverse direction (client 
> is non-SSL while origin connection is SSL). I've tested with trunk which 
> includes a fix for TS-2211 but still be able to reproduce this.
> In my test setup both ATS and Apache are running on the same Linux Mint 13 
> box (which is effectively Ubuntu 12.04) with OpenSSL version 1.0.1.
> Any help would be much appreciated.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Reply via email to