[
https://issues.apache.org/jira/browse/TS-3584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14635323#comment-14635323
]
Leif Hedstrom commented on TS-3584:
-----------------------------------
Alright, so tested with this (TS-3584) and TS-3640 both backed out, and then
the issues from TS-3640 are gone. So, we probably need to consider one of
1) Back out both TS-3584 and TS-3640.
2) Fix the commit for TS-3484, and revert TS-3640.
In either case, it seems reasonable to think that TS-3640 was directly caused
by the fix on this Jira, and likely is not necessary. I.e. I can not not
reproduce TS-3640 if TS-3584 is reverted.
> SPDY and H2 requests should not trigger connection keep-alive processing
> ------------------------------------------------------------------------
>
> Key: TS-3584
> URL: https://issues.apache.org/jira/browse/TS-3584
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP, HTTP/2, SPDY
> Reporter: Susan Hinrichs
> Assignee: Susan Hinrichs
> Fix For: 6.0.0
>
>
> For HTTP 1.1 the default value for the Connection header is keep-alive. So
> all requests coming from SPDY and H2 dutifully set up the HttpClientSession
> for potential future reuse.
> However, SPDY and H2 will create a new FetchSM request (and related
> HttpClientSession) for every HTTP request, so the HttpClientSession will
> never be reused.
> This results in unnecessary complexity and inefficiency. I'm seeing some
> crashes in SPDY start up that could be related to VC freeing race conditions.
> I'd like to tidy this up to remove one element from the equation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
