commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: [VETO] Re: [jcs] What's next?
Date Thu, 22 May 2014 19:45:32 GMT
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.

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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message