Mailing-List: contact dev-help@directmemory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@directmemory.apache.org
Received-SPF: pass (nike.apache.org: domain of raffaele.p.guidi@gmail.com
 designates 209.85.220.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAAnVOG2W2CsZmV8o72hZ=f4cYHneVJwgboPV0WFRfhaiQVpRgA@mail.gmail.com>
References: 
 <CACLE=7M_SxxZ99_k_pWvThofmXQNUnRg_u8tKCz26G73OYgAsw@mail.gmail.com>
	<CACLE=7MxZyNR3sm6M1cT33z-40pZATHwCehYwJUvGLO3UuzpjA@mail.gmail.com>
	<CACLE=7PiQCpsxxaYSKoh1KTX81DcJHd=DdYZBFHwE8cPtb1PZw@mail.gmail.com>
	<1399398858.89552.YahooMailNeo@web28906.mail.ir2.yahoo.com>
	<CACLE=7MfpTi4cdphPEp4kDc5gViL21QBT_FYFXaHNPDk0ftQyw@mail.gmail.com>
	<CAAnVOG2W2CsZmV8o72hZ=f4cYHneVJwgboPV0WFRfhaiQVpRgA@mail.gmail.com>
Date: Thu, 8 May 2014 18:28:14 +0200
Message-ID: 
 <CAAnVOG0q+PGcReXKngpXKqt9GW5WOXuAF8tqc4HTA4XWqqpNWQ@mail.gmail.com>
Subject: Re: [jcs] What's next?
From: "Raffaele P. Guidi" <raffaele.p.guidi@gmail.com>
To: Commons Developers List <dev@commons.apache.org>,
 dev@directmemory.apache.org
Cc: Mark Struberg <struberg@yahoo.de>
Content-Type: multipart/alternative; boundary=001a11c1bf92bdc44804f8e5f752

--001a11c1bf92bdc44804f8e5f752
Content-Type: text/plain; charset=UTF-8

Oops, wrong address, sorry :)


2014-05-07 12:03 GMT+02:00 Raffaele P. Guidi <raffaele.p.guidi@gmail.com>:

> 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 <rmannibucau@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 <struberg@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 <
>> rmannibucau@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 <rmannibucau@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 <rmannibucau@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-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
>>
>>
>

--001a11c1bf92bdc44804f8e5f752--