Leif Hedstrom created TS-1919:
---------------------------------
Summary: 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
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
