On 10 April 2017 at 11:25, Katia Aresti <kare...@redhat.com> wrote: > Hi all > > I've moved the discussion to infinispan-designs > > https://github.com/infinispan/infinispan-designs/pull/3 > > I think I put everything we said on this thread. Let me know if I forgot > something important on the PR. Let's continue the design on Github, should > be nicer to follow ! :)
Great idea! I often get a bit lost in long mailing list threads. Thanks, Sanne > > Cheers > > Katia > > On Thu, Apr 6, 2017 at 2:29 PM, Katia Aresti <kare...@redhat.com> wrote: >> >> What if we move the discussion to >> https://github.com/infinispan/infinispan-designs ? >> >> >> Katia >> >> On Thu, Apr 6, 2017 at 11:04 AM, Radim Vansa <rva...@redhat.com> wrote: >>> >>> On 04/06/2017 12:15 AM, Katia Aresti wrote: >>> > >>> > >>> > On Wed, Apr 5, 2017 at 9:56 AM, Radim Vansa <rva...@redhat.com >>> > <mailto:rva...@redhat.com>> wrote: >>> > >>> > On 04/04/2017 06:40 PM, William Burns wrote: >>> > > >>> > > >>> > > On Tue, Apr 4, 2017 at 11:45 AM Katia Aresti <kare...@redhat.com >>> > <mailto:kare...@redhat.com> >>> > > <mailto:kare...@redhat.com <mailto:kare...@redhat.com>>> wrote: >>> > > >>> > > Hi all, >>> > > >>> > > As you probably know, Will and I are working on the vert-x >>> > > infinispan integration [1], where the primary goal is to make >>> > > infinispan the default cluster management of vert-x. (yeah!) >>> > > Vert-x needs support for an Async Multimap. Today's >>> > implementation >>> > > is a wrapper on a normal Cache where only Cache Key's are >>> > used to >>> > > implement the multi map [2]. >>> > > This is not very efficient, so after trying some other >>> > alternative >>> > > implementations [3] that don't fully work (injection not >>> > working), >>> > > Will and I have come to the conclusion that it might be a >>> > good >>> > > idea to start having our own native CacheMultimap. This first >>> > > multimap won't support duplicate values on key's. >>> > > >>> > > As a quick start, the smallest multimap we need should >>> > implement >>> > > the following interface : >>> > > >>> > > I agree that having a very slim API to start should be better >>> > since we >>> > > know how much trouble we get into implementing a very large API >>> > like >>> > > ConcurrentMap :) >>> > > >>> > > public interface CacheMultimap<K,V> { >>> > > >>> > >>> > I don't see anything async in this interface. If that's async, >>> > provide >>> > CompletableFuture return values. >>> > I am also considering if we want any fire & forget variants for >>> > these >>> > operations, but since we have to do retries to achieve consistency >>> > (and >>> > therefore we need some messages from owners to originator), I >>> > wouldn't >>> > include them. >>> > >>> > >>> > Today's vert-x API calls the vertx.executeBlocking(future => cache...) >>> > >>> > I considered the option of CompletableFuture, but for simplicity I >>> > suggested the basic method. >>> > Today's CacheAPI makes a difference between "put" and "putAsync". >>> > Would you call the interface CacheMultimapAsync or CacheMultimap with >>> > addAsyc method ? >>> >>> "In a perfect world, there will be no war or hunger, all APIs will be >>> written asynchronously and bunny rabbits will skip hand-in-hand with >>> baby lambs across sunny green meadows." (quoting Vert.x docs) >>> >>> While minimalistic API is a good way to start, it shouldn't contain >>> anything we'd want to get rid of in close future. And especially since >>> the main drive for multimaps is Vert.x which consumes asynchronous APIs >>> (and has support for legacy synchronous APIs, the executeBlocking >>> method), we should have the design adapted to that from the beginning. >>> >>> CompletableFuture is not a rocket science, and you can use the already >>> asynchronous Infinispan internals. >>> >>> I don't think we should have two interfaces, I believe that single >>> interface with async methods only is absolutely sufficient. Though I >>> wouldn't add the *Async suffix at all there. If someone wants to execute >>> the methods synchronously he can call .get() or .join() - just 6/7 >>> characters more. >>> >>> > >>> > > V put(K key,V value); >>> > > >>> > > This should probably return a boolean or Void. I am leaning >>> > towards >>> > > the first, but I am open either way. >>> > >>> > I would rather call this "add", as vert-x does. CompletableFuture >>> > as >>> > return type here will allow to easily register the handler >>> > >>> > >>> > -1 I prefer keeping "put" name because it is still a Map and makes >>> > more sense to me considering the actual Cache API too. The return type >>> > V was a transcription mistake, it should be void for me, as Will >>> > pointed out. >>> >>> To me "put" is linked with overwriting the previous value, while you add >>> to the underlying collection or create a new single-element one. But >>> whatever, I care more about the return values :) >>> >>> R. >>> >>> > >>> > >>> > > Collection<V> get(K key); >>> > > >>> > > boolean remove(K key,V value); >>> > > >>> > > We probably want a `boolean remove(K key)` method as well that >>> > removes >>> > > all values mapped to the given key. >>> > >>> > What about "reset(key)"? >>> > >>> > >>> > > } >>> > > >>> > > CacheMultimapImpl will be a wrapper on a normal Cache, >>> > similar to [3]. >>> > > >>> > > We could add a new method in EmbeddedCacheManager.java >>> > > >>> > > <K, V> CacheMultimap<K, V> getCacheMultimap(String cacheName, >>> > > boolean createIfAbsent); >>> > > >>> > > >>> > > I was thinking maybe this would exist in a separate module >>> > (outside of >>> > > core)? or class that wraps (similar to DistributedExecutor) >>> > instead. >>> > > My worry is about transactions, since the entry point to that is >>> > > through Cache interface. The other option is we could add a >>> > `getCache` >>> > > method on the `CacheMultiMap`. >>> > >>> > +1 Since the names of multimaps and maps will clash, we shouldn't >>> > hide >>> > that the underlying implementation is a Cache, so I'd suggest >>> > something like >>> > >>> > static <K, V> CacheMultimap<K, V> CacheMultimapFactory.get(Cache<K, >>> > Object> c) { ... } >>> > >>> > > >>> > > >>> > > Implementation will create a cache as always and return a new >>> > > CacheMultimapImpl(cache). >>> > > >>> > > What do you think ? Please fell free to suggest any other >>> > > alternative or idea. >>> > > >>> > > Cheers >>> > > >>> > > Katia >>> > > >>> > > [1] https://github.com/vert-x3/vertx-infinispan >>> > <https://github.com/vert-x3/vertx-infinispan> >>> > > >>> > > [2] >>> > > >>> > >>> > https://github.com/vert-x3/vertx-infinispan/blob/master/src/main/java/io/vertx/ext/cluster/infinispan/impl/InfinispanAsyncMultiMap.java >>> > >>> > <https://github.com/vert-x3/vertx-infinispan/blob/master/src/main/java/io/vertx/ext/cluster/infinispan/impl/InfinispanAsyncMultiMap.java> >>> > > >>> > > [3] >>> > https://gist.github.com/karesti/194bb998856d4a2828d83754130ed79c >>> > <https://gist.github.com/karesti/194bb998856d4a2828d83754130ed79c> >>> > > _______________________________________________ >>> > > infinispan-dev mailing list >>> > > infinispan-dev@lists.jboss.org >>> > <mailto:infinispan-dev@lists.jboss.org> >>> > <mailto:infinispan-dev@lists.jboss.org >>> > <mailto:infinispan-dev@lists.jboss.org>> >>> > > https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> > <https://lists.jboss.org/mailman/listinfo/infinispan-dev> >>> > > >>> > > >>> > > >>> > > _______________________________________________ >>> > > infinispan-dev mailing list >>> > > infinispan-dev@lists.jboss.org >>> > <mailto:infinispan-dev@lists.jboss.org> >>> > > https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> > <https://lists.jboss.org/mailman/listinfo/infinispan-dev> >>> > >>> > >>> > -- >>> > Radim Vansa <rva...@redhat.com <mailto:rva...@redhat.com>> >>> > JBoss Performance Team >>> > >>> > _______________________________________________ >>> > infinispan-dev mailing list >>> > infinispan-dev@lists.jboss.org >>> > <mailto:infinispan-dev@lists.jboss.org> >>> > https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> > <https://lists.jboss.org/mailman/listinfo/infinispan-dev> >>> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > infinispan-dev mailing list >>> > infinispan-dev@lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> >>> >>> -- >>> Radim Vansa <rva...@redhat.com> >>> JBoss Performance Team >>> >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
