Talking about next steps, have you ever considered a second level of (off
heap) cache? My question is of course not so casual, being the PMC of
DirectMemory :) I think there are a lot of potential synergies, here. I
include DM's dev list to gather opinions and solicitate feedback from the
team members.
Ciao,
R
2014-05-06 22:39 GMT+02:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
> That's my experience too. So let's go for the concurrenthashmap impl
> (patch on jira) and then see how we do the invalidation stuff in a
> 2.1?
>
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
> 2014-05-06 19:54 GMT+02:00 Mark Struberg <strub...@yahoo.de>:
> > Well my personal experience only:
> >
> >
> > 1.) I barely use distributed caches. I use ehcache in most of my
> projects as of today, but do not use the distribution feature much. Way too
> complicated
> >
> > 2.) What actually IS useful is distributed cache invalidation. The
> caching side is fine to just select any values from my DB if they are not
> yet cached. But if I change those values, then I really need some ways to
> get rid of the values in all the caches on all my cluster nodes.
> >
> > So from a purely personal point I would favour a mode which is really
> fast as a local cache but would have some ways to distribute the
> invalidation of a cache to all other nodes.
> >
> > Not sure how this fits into jcs - don't know the codebase well enough to
> judge about it.
> >
> > LieGrue,
> > strub
> >
> >
> > On Tuesday, 6 May 2014, 13:29, Romain Manni-Bucau <rmannibu...@gmail.com>
> wrote:
> >
> > Here some pseudo-core details about my first mail:
> >>
> >>New internals:
> >>* NetworkTopology
> >>* EntryRepartitor: compute the index of the
> >>* Node (LocalNode which is current impl and RemoteNode which is just a
> >>remote facade relying Network)
> >>
> >>NetworkTopology { // impl using udp/tcp/or whatever
> >> Node[] findAll() // used by a background thread to check if there
> >>is a new node and if so rebalance the cluster
> >>}
> >>
> >>Node { // remote and local API
> >> get(k), put(k, v) .... (Cache<K, V> primitive methods)
> >> Statistics getStatistics() // used by a background thread to
> >>aggregate stats on each node
> >>}
> >>
> >>
> >>EntryRepartitor {
> >> Node[] nodeAndBackups(key)
> >>}
> >>
> >>
> >>get(key) { // symmetrical for put of course
> >> Node[] nodes = entryRepartitor.nodeAndBackups(key);
> >> for (final Node node : nodes) {
> >> try {
> >> return node.get(key);
> >> } catch(final RemoteCacheException rce) { // API exception
> >> throw rce.getJCacheException();
> >> } catch(final Exception e) { // network exception try next node
> >> // continue
> >> }
> >> }
> >>}
> >>
> >>Of course we'll get LocalNode implementing Node with the current impl
> >>(ConcurrentHashMap) and RemoteNode will be a client view of the
> >>LocalNode over the network.
> >>
> >>To keep it testable we need to be able to test a RemoteNode ->
> >>LocalNode connection in the same JVM creating manually two
> >>CachingProviders.
> >>
> >>wdyt?
> >>
> >>
> >>Romain Manni-Bucau
> >>Twitter: @rmannibucau
> >>Blog: http://rmannibucau.wordpress.com/
> >>LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >>Github: https://github.com/rmannibucau
> >>
> >>
> >>
> >>2014-05-06 12:50 GMT+02:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
> >>> FYI I attached a patch using a ConcurrentHashMap here
> >>> https://issues.apache.org/jira/browse/JCS-127
> >>>
> >>> It is pretty fast compared to previous impl.
> >>>
> >>>
> >>> Romain Manni-Bucau
> >>> Twitter: @rmannibucau
> >>> Blog: http://rmannibucau.wordpress.com/
> >>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >>> Github: https://github.com/rmannibucau
> >>>
> >>>
> >>> 2014-05-06 8:31 GMT+02:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
> >>>> Hi guys,
> >>>>
> >>>> few questions about jcs:
> >>>>
> >>>> 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.
> >>>>
> >>>> wdyt?
> >>>>
> >>>> I don't know how much JCS is used ATM and if we can break that much
> >>>> the API but since that would be a 2.0 I think it is the moment
> >>>>
> >>>>
> >>>> Romain Manni-Bucau
> >>>> Twitter: @rmannibucau
> >>>> Blog: http://rmannibucau.wordpress.com/
> >>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >>>> Github: https://github.com/rmannibucau
> >>
> >>---------------------------------------------------------------------
> >>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
>
>
