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