Description
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.
Attachments
Attachments
Issue Links
- blocks
-
TS-1809 Remove HTTP_CACHE build option
- Open
-
TS-1845 Make proxy.config.cache.max_doc_size configurable via conf_remap plugin
- Closed
-
TS-4026 Remove clustering feature in 7.0.0 release
- Closed
- is depended upon by
-
TS-2245 Fix the semantics and behavior of e.g. proxy.config.http.cache.ignore_accept_encoding_mismatch
- Closed