[
https://issues.apache.org/jira/browse/TS-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12919512#action_12919512
]
Alan M. Carroll commented on TS-480:
------------------------------------
During out testing we have been having problems with ATS stalling out, then
recovering when doing multiple simultaneous clients. I think the problem is
caused by the default for NetVCOptions::f_blocking_connect being set to true.
When I did that fix initially it wasn't clear to me what the correct default
was (as evidenced by the comments for NetVCOptions in I_NetVConnection.h state
the default as "false").
As a fix, I propose to
1) Change the default to "false" (that is, connect() does not block).
2) Explicit set the opt.f_blocking_connect to false in
HttpSM::do_http_server_open.
I am currently testing this fix locally.
My concern is possible side effects from changing the default. I am still not
sufficiently familiar with the connection logic to be confident of this change.
Note that for this specific issue, (2) should suffice but I now think that
overall the expectation of other code is for the default to be non-blocking.
> Unresponsive server can stall ATS
> ---------------------------------
>
> Key: TS-480
> URL: https://issues.apache.org/jira/browse/TS-480
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
> Affects Versions: 2.1.4, 2.1.3, 2.1.2, 2.1.1
> Reporter: Alan M. Carroll
> Assignee: Alan M. Carroll
>
> If a cache fill request from ATS to an origin stalls, this can block all
> other HTTP connections outbound from ATS. ATS appears to be unresponsive
> until the stalled request fails, at which point ATS resumes operation.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
