[
https://issues.apache.org/jira/browse/TS-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13775943#comment-13775943
]
Leif Hedstrom commented on TS-1919:
-----------------------------------
I was looking at this some more, and yes, those things are not overridable
(because of the fact that they are passed along in this damn struct :).
With the patch e.g.
{code}
HttpTransactCache::calculate_quality_of_match(CacheLookupHttpConfig *
http_config_param, // in
HTTPHdr * client_request, // in
HTTPHdr * obj_client_request,
// in
HTTPHdr *
obj_origin_server_response // in
)
{code}
would change such that all the cache calculating options can be overridable. In
itself, I think this would be a huge win (you can change cache rules by remap
rules).
This would break if you have different configs / plugins on different machines,
but that seems like a bad idea anyways. Is there anything we could do such that
we e.g. know if two machines are out of sync on e.g. installed plugins / plugin
versions, or remap.config lines ?
The other benefit is that we would remove an entire allocator for every request
by eliminating this. It gets allocated for every request, just to hold these
"special" configs.
If you feel this really must stay, I can look into making this
records.config'urable, such that we pass CacheLookupHttpConfig's only when
cache clustering is in effect. But then you would lose out on the benefits the
changes adds, but maybe that's ok ?
The reason this is coming up again is because I'm looking at e.g. the
proxy.config.http.cache.ignore_accept_encoding_mismatch. I'm 99% certain that
they were added and implemented wrongly, to solve a real problem. As such, I
want to fix these, but to use them safely, I need them to be overridable
configurations (via e..g conf_remap.so).
Thoughts?
> 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
