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