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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
