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: [jcs] What's next?
Date Wed, 07 May 2014 21:30:56 GMT
trunk should be in phase with this (ConcurrentHashMap). I'll test it
further tomorrow (hope to find time) but any review would be welcomed.

Main things which can be enhance I guess are the eviction rules
(org.apache.commons.jcs.jcache.JCSCache#evict).

Then I plan to add few utilities in jcache-extra module
(CompositeCacheLoader, CompositeCacheWriter, AsyncCacheLoader,
AsyncCacheWriter, SingleItemCacheLoader, SingleItemCacheWriter,...all
implementing Factory too to make it nicer in the MutableConfiguration
API)

Then JCache should be ok for a release.

Any objection (mainly on the fact we don't rely on jcs-core)?


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


Mime
View raw message