[
https://issues.apache.org/jira/browse/TS-2791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13994113#comment-13994113
]
Sudheer Vinukonda commented on TS-2791:
---------------------------------------
So, the race condition seems to be with the code below. It looks like there's a
header_done flag to guard against sending the client response too soon. But,
that may be an issue with POST requests. When I removed that flag, the POST
requests (even large ones) are now successful. Am considering enhancing the API
below to not check for header_done for POST requests towards origin.
{code}
--- a/proxy/FetchSM.cc 2014-05-10 01:42:07.006063763 +0000
+++ b/proxy/FetchSM.cc 2014-05-10 01:43:56.714348545 +0000
@@ -532,8 +532,10 @@
// Before header_done, FetchSM may not
// be initialized.
//
- if (header_done)
+ //if (header_done) {
write_vio->reenable();
+ fetch_handler(TS_EVENT_VCONN_WRITE_READY, write_vio);
+ //}
if (header_done && (fetch_flags & TS_FETCH_FLAGS_NEWLOCK)) {
MUTEX_UNTAKE_LOCK(mutex, this_ethread());
{code}
> POST transactions failing with ERR_CLIENT_ABORT
> -----------------------------------------------
>
> Key: TS-2791
> URL: https://issues.apache.org/jira/browse/TS-2791
> Project: Traffic Server
> Issue Type: Bug
> Components: SPDY
> Reporter: Sudheer Vinukonda
> Labels: spdy, yahoo
>
> During our production testing of SPDY, we noticed that when trying to compose
> mails (POST transactions) on Firefox, we are seeing "Network Error" from the
> browser and ERR_CLIENT_ABORT from squid.logs. Upon some analysis, this issue
> appears to be likely specific to SPDY transactions and seem to be triggered
> by the expiry of proxy.config.http.transaction_no_activity_timeout_in timer.
> After some investigation, it looks like this may be caused by a timing issue
> related to streaming of the POST data to the origin.. If the POST body (data)
> is available by the time client session and origin connection is ready, the
> POST is successful, but, if the data is large enough that it is not all read
> yet by the time origin connection is established, the streaming does not get
> triggered. Debugging further to identify the root cause.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
