[
https://issues.apache.org/jira/browse/TS-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13769168#comment-13769168
]
Leif Hedstrom commented on TS-1919:
-----------------------------------
Right, I definitely understand what the feature was there for. I think it
possibly predates the concept of cluster configurations.
Are you concerned that the configuration changes are not propagating fast
enough and this would cause problems? Is it unreasonable to make it such that
if you make such a dramatic change to your configs, that you have to do it
while out of rotation?
Also, none of these configurations are configurable through conf_remap anyways
(I'm 99% sure, but I'll have to double check). In fact, part of my reasons for
making this change is such that we can allow overridable cache configurations
(that's not possible right now, because the cache doesn't have access to the
general HTTP configs).
- cache_global_user_agent_header(false),
- cache_enable_default_vary_headers(false),
- ignore_accept_mismatch(false),
- ignore_accept_language_mismatch(false),
- ignore_accept_encoding_mismatch(false),
- ignore_accept_charset_mismatch(false),
- cache_vary_default_text(NULL), cache_vary_default_images(NULL),
cache_vary_default_other(NULL)
Those are the configurations related to this, pretty sure none of these are
overridable. The ignore_mismatch options are generally really bad to use, and
you certainly couldn't safely use them anyways. The vary_default configs seems
like a generally bad idea, but could be usable. Global user-agent maybe could
be useful, but I doubt it really affect much caching at this point in time (but
it *might*).
The reason I'm asking is that, getting rid of this really would simplify the
cache core quite a lot. ANd in fact, make things better. The configurations
we'd "lose" are incredibly obscure IMO.
If you feel that this feature must stay in the cache core, I'll back it out.
I'd really ask you to take a second look though, before you -1 this.
Thanks!
-- leif
> 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
