[
https://issues.apache.org/jira/browse/TS-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-1919:
---------------------------
Assignee: Leif Hedstrom
> 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: 7.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 was sent by Atlassian JIRA
(v6.3.4#6332)
