[
https://issues.apache.org/jira/browse/TS-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13769141#comment-13769141
]
Zhao Yongming commented on TS-1919:
-----------------------------------
from the talking with Weijin, it seems the change will cause us some trouble,
the CacheLookupHttpConfig is design to control the cache internal functions
from the http side, due to that cache is a lower layer.
the CacheLookupHttpConfig is there for some of the reasons:
1, in some situation, where some of the critical cache lookup or matching
config may vary between every request or hostname:
1.1 you make a tiny change from the conf_remap plugin on that remap rule
1.2 other plugins that will use TSHttpTxnConfigIntSet() etc
2, when in cluster mode, the matching is done on the remote machine, and it is
better to get that control message send with the request.
from what we have learned from our usage, it is better to get more control over
the remap point, to set seperated timeout, cache directives, matching
directives etc. if we have something we can send to cache with remap plugin
etc, that is far great. and that is the reason we refined the remap.config.
so, basicly, the CacheLookupHttpConfig is a cache control message send from the
http layer to cache, to avoid the reverse access of those informations, and get
more flex on cache control.
if we remove that, it will make trouble when we'd like to do more control over
the cache behavior, we should supply some better solution on that.
> Eliminate CacheLookupHttpConfig
> -------------------------------
>
> Key: TS-1919
> URL: https://issues.apache.org/jira/browse/TS-1919
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
> Reporter: Leif Hedstrom
> Assignee: Leif Hedstrom
> Fix For: 5.0.0
>
> Attachments: TS-1919.diff
>
>
> We have a notion of creating (and transmitting) a very tiny subset of
> HttpConfigParams, in a struct named CacheLookupHttpConfig. As it turns out,
> this is generally not used, and as far as I can tell, cluster config provides
> the same / similar functionality (assuring that all nodes in the cluster uses
> the same config). One complication with this CacheLookupHttpConfig struct is
> that it sort of violates modularity, in that the I/O core, clustering and
> HTTPSM share this partial HTTP config in a non-opaque way.
> I have a patch that eliminates this (I'll post it later), but there are two
> thoughts / questions I'd like to discuss.
> 1) Do we feel it adequate to use the cluster config mechanism of distributing
> / sharing configurations across the cluster? Or do we really think that it's
> necessary to transfer the configs as part of every Cluster response message?
> 2) If we agree to eliminate the CacheLookupHttpConfig in favor of just using
> HttpConfigParam's (which are synchronized between cluster nodes), how
> important is it to preserve compatibility in the Cluster protocol? Right now,
> my patch does not do this (I'd break clustering between e.g. ATS v3.2 and ATS
> v3.4).
> For 2), we have a few options, the cleanest probably involves knowing the
> version of the Cluster message (does that exist today?). Before I go down
> that route, I'd like to ask the people using clustering if they feel it
> important to retain compatibility such that you can run a cluster with a mix
> of v3.2 and v3.4 nodes.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
