[ 
https://issues.apache.org/jira/browse/TS-4025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15047330#comment-15047330
 ] 

Leif Hedstrom commented on TS-4025:
-----------------------------------

Talking with Phil on this some more, it'd be nice if we could use the URL 
object and its existing hashing mechanism for generation of this. In addition 
to that, we could then

1) Add a new public API to set the parent-selection URL (object) from a plugin.

2) Provide a "bit mask" specifying which component of the URL to use for the 
hash generation.

2) could be generalized (and exposed via plugin APIs) such that the cache key 
can easily be specified to e.g. exclude the query params as well. It'd be 
fairly straight forward to just has a mask for each possible URL component, 
with a yay or nay whether the hashing should include that component or not.

> Consistent hashing in parent.config can use suboptimal URL for hash
> -------------------------------------------------------------------
>
>                 Key: TS-4025
>                 URL: https://issues.apache.org/jira/browse/TS-4025
>             Project: Traffic Server
>          Issue Type: Bug
>          Components: Parent Proxy
>            Reporter: Leif Hedstrom
>            Assignee: John Rushford
>             Fix For: 6.1.0
>
>
> In a setup, where the same assets can have different URLs (e.g. query 
> parameters, or two paths normalized to the same cache key), parent proxy can 
> be suboptimal. This is TS-4020, and the solutions would be similar; Use the 
> cache key (CacheInfo->md5) which is internally what we call LookupURL. 
> LookupURL is that URL that plugins modify to change the cache key.
> This has to be rolled out carefully as well, we're thinking something like
> 6.x - We add a new configuration, that lets you use the LookupURL for the 
> hash (default off)
> 7.x - We change this new configuration to be enabled by default
> 8.x - We remove this configuration.
> This Jira tracks the first step, we'll file subsequent Jira's for 7.x and 8.x.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to