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