You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "Susan Hinrichs (JIRA)" <ji...@apache.org> on 2014/11/20 21:07:35 UTC

[jira] [Updated] (TS-3191) Confusion with HTTP_TUNNEL_STATIC_PRODUCER

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

Susan Hinrichs updated TS-3191:
-------------------------------
    Fix Version/s: 5.2.0

> 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
>             Fix For: 5.2.0
>
>
> 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)