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