[jira] [Assigned] (TS-1919) Eliminate CacheLookupHttpConfig

["Leif Hedstrom (JIRA)" <ji...@apache.org>]

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

Leif Hedstrom reassigned 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
>
> 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