[
https://issues.apache.org/jira/browse/TS-3191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14218510#comment-14218510
]
ASF GitHub Bot commented on TS-3191:
------------------------------------
Github user SolidWallOfCode commented on the pull request:
https://github.com/apache/trafficserver/pull/145#issuecomment-63715069
I'm a little concerned about the kill_tunnel() in HttpSM::kill_this(). The
problem IMHO is that we may not want to toast off the NetVCs in the tunnel even
if the SM is shutting down because of potential keep alives. There is also the
issue of potentially calling do_io_close() more than once on a VC. I think the
other changes are reasonable.
> Confusion with HTTP_TUNNEL_STATIC_PRODUCER
> ------------------------------------------
>
> Key: TS-3191
> URL: https://issues.apache.org/jira/browse/TS-3191
> Project: Traffic Server
> Issue Type: Bug
> Reporter: Susan Hinrichs
> Assignee: Susan Hinrichs
>
> In the HttpTunnel processing, normally a producer has a VC associated with
> it. The VC is used to lookup the producer via the HttpTunnel::get_producer
> method out of the HttpTunnel producer array.
> All is well and good, but in the case of a static producer, there is no vc.
> Rather the constant HTTP_TUNNEL_STATIC_PRODUCER is used in lieu of the vc.
> If there is only only one static producer all is still well, get_producer
> will return the one producer associated with HTTP_TUNNEL_STATIC_PRODUCER.
> But if there is more than one static producer involved with the tunnel,
> get_producer() will only return one producer. Both static consumers will
> only interact with one of the static producers and things will go down hill
> from here.
> I ran into this case while chasing down crashes via TS-3105, so this
> situation does come up in the wild.
> I fixed it by clearing out the tunnel before starting a static producer and
> making some other checks along the way.
> We could also avoid some calls to get_producer since it many cases, the
> caller already has the producer in question, but the callee ends up looking
> up that value again via the VC.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
