commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [VETO] Re: [jcs] What's next?
Date Thu, 22 May 2014 21:32:42 GMT
On 5/22/14, 12:45 PM, Romain Manni-Bucau wrote:
> well Now JCache is based on JCS so think almost all comments are no more
> relevant.
>
> Well if commons can't support module (jcs wouldn't be the first BTW) I have
> no issue moving it outside of commons. This is quite common actually.

This bothers me - and not for the reason that you may think.   To
jump from another committer asking questions to "commons can't
support module" is bogus.

Phil
>
> The point about remote mode is it is not as easy as alternatives and API
> doesn't completely fit needs of JCache, but this is not a big deal now, we
> have something enough for now.
>
> Yes I got some formatting issues, saw a lot of classes didn't have
> organized imports but miss my settings regarding java.* was maybe not
> correct. We can fix it in all cases.
>
>
>
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
> 2014-05-22 21:37 GMT+02:00 Thomas Vandahl <tv@apache.org>:
>
>> On 22.05.14 19:24, Romain Manni-Bucau wrote:
>>> About eviction: is it still the case? Thought I removed it when merged
>> with
>>> jcs backend
>> I have no idea. I lost track when I needed to merge my changes with your
>> reformatted imports (That was one thing I forgot). Why was that necessary?
>>
>>> Not sure I get your point about removing network/remote features, never
>>> said we should remove it but we shouldn't have it by default for JCache.
>> You wrote:
>> ---8<---
>> 1) I played a bit with remote cache server etc and didn't find a lot
>> of use cases, do we keep it this way (linked to 4) )?
>> 2) API: do we use JCache as main API or do we keep core?
>> 3) Reviewing JCache module I really wonder if we shouldn't use a
>> ConcurrentHashMap instead of a the currently backing CompositeCache
>> and add on top of this "locally optimized" implementation two things:
>> a) eviction (a thread regularly iterating over local items to check
>> expiry would be enough), b) distribution (see 4) )
>> 4) distributed mode: I wonder if we shouldn't rethink it and
>> potentially add Cache<K, V> listeners usable in JCache to know if
>> another node did something (useful to get consistent stats at least -
>> basically we need a way to aggregate on each note stats) + use a key
>> for each node to keep data on a single node + potentially add backup
>> on another node.
>> ---8<---
>>
>> JCS *has* eviction and it *can* work in a distributed environment. Many
>> people use this.
>>
>>> JCache uses JCS so once again not sure I follow.
>> See 3) above.
>>
>>> Finally extra module is quite useful when you use JCache and that's what
>> we
>>> do in all "EE" projects cause this module doesn't depend on the
>>> implementation.
>> Yes, but we are at Commons here. I miss the willingness to discuss
>> project matters before reorganizing a project that you barely know.
>>
>> Bye, Thomas.
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message