trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leif Hedstrom <zw...@apache.org>
Subject Re: [DISCUSS] TS-1919: Eliminate CacheLookupHttpConfig
Date Wed, 13 Nov 2013 14:27:36 GMT
On Nov 12, 2013, at 10:41 PM, Yongming Zhao <ming.zym@gmail.com> wrote:
> 
> Leif: as we have talked, we are using that feature, and the late read-while-writer enhancement(not
yet submit due to it is bound to our cluster refine) is also built onto this structure. can
we keep it?
> 
> afaik, the CacheLookupHttpConfig is a control from http cache layer that will permit
flex control before the cache is really done, as the http & cache is designed to be two
separated  layer, that sounds not a too bad idea for me.

I think you need to reread the mails and the patch. This behavior is not changing, in fact
it's getting much stronger. Instead of just 4 configs being transferred over cluster communications,
all of them are, including the overridable configs. And this is communicated between HTTP
and layers cache on the node.

I think from what you describe you need, TS-1919 is a major improvement, so there must be
some major communications problem here.

> 
> -1, that is my concern, cluster is the feature I can not compromise.

Sigh, ok. Can you please read the emails and patch once more, and if you still -1 in, I will
remove it. The only thing you are missing in the patch is the transport of those four configs
over cluster communications, and you probably never change those configs (they are not overrideable
before this patch, but after the patch they could be).

Leif




> 
>> 在 2013年11月12日,下午11:53,Leif Hedstrom <zwoop@apache.org> 写道:
>> 
>> 
>>> On Nov 3, 2013, at 1:27 PM, Leif Hedstrom <zwoop@apache.org> wrote:
>>> 
>>> Hi all,
>>> 
>>> I’d like to get some closure on the TS-1919 Jira issue. There have been concerns
raised about this patch, and I will try to explain the pros and the cons of this patch. Note
that this is committed on the v5.0.x branch (it’s an incompatible change), and I really
want to decide the future of this commit such that we can either agree to keep it, or back
it out right now.
>> 
>> Haven’t heard any -1’s on this topic so far, so last call. Any concerns with
keeping this change as it currently applies to in the v5.0.x ?
>> 
>> Thanks,
>> 
>> — leif
>> 

Mime
View raw message