On Nov 12, 2013, at 10:41 PM, Yongming Zhao <ming....@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 <zw...@apache.org> 写道:
>> 
>> 
>>> On Nov 3, 2013, at 1:27 PM, Leif Hedstrom <zw...@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
>> 

Reply via email to