<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 5, 2017 at 9:56 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">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>
</span><span class="gmail-">> <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 implementation<br>
> is a wrapper on a normal Cache where only Cache Key's are used to<br>
> implement the multi map [2].<br>
> This is not very efficient, so after trying some other alternative<br>
> implementations [3] that don't fully work (injection not 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 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>
</span>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 (and<br>
therefore we need some messages from owners to originator), I wouldn't<br>
include them.<br></blockquote><div><br></div><div>Today's vert-x API calls the <span style="color:rgb(36,41,46);font-family:sfmono-regular,consolas,"liberation mono",menlo,courier,monospace;font-size:12px;white-space:pre">vertx</span><span class="gmail-pl-k" style="box-sizing:border-box;color:rgb(167,29,93);font-family:sfmono-regular,consolas,"liberation mono",menlo,courier,monospace;font-size:12px;white-space:pre">.</span><span style="color:rgb(36,41,46);font-family:sfmono-regular,consolas,"liberation mono",menlo,courier,monospace;font-size:12px;white-space:pre">executeBlocking(future => cache...)</span></div><div><br></div><div>I considered the option of CompletableFuture, but for simplicity I suggested the basic method.</div><div>Today's CacheAPI makes a difference between "put" and "putAsync". Would you call the interface CacheMultimapAsync or CacheMultimap with addAsyc method ?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> V put(K key,V value);<br>
<span class="gmail-">><br>
> This should probably return a boolean or Void. I am leaning towards<br>
> the first, but I am open either way.<br>
<br>
</span>I would rather call this "add", as vert-x does. CompletableFuture as<br>
return type here will allow to easily register the handler</blockquote><div><br></div><div>-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.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> Collection<V> get(K key);<br>
><br>
> boolean remove(K key,V value);<br>
<span class="gmail-">><br>
> We probably want a `boolean remove(K key)` method as well that removes<br>
> all values mapped to the given key.<br>
<br>
</span>What about "reset(key)"? </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-"><br>
> }<br>
><br>
> CacheMultimapImpl will be a wrapper on a normal Cache, 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 (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 `getCache`<br>
> method on the `CacheMultiMap`.<br>
<br>
</span>+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 something like<br>
<br>
static <K, V> CacheMultimap<K, V> CacheMultimapFactory.get(<wbr>Cache<K,<br>
Object> c) { ... }<br>
<span class="gmail-"><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>
><br>
> [2]<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] <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>
</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>
<span class="gmail-im gmail-HOEnZb">><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>
</span><span class="gmail-HOEnZb"><font color="#888888">--<br>
Radim Vansa <<a href="mailto:rvansa@redhat.com">rvansa@redhat.com</a>><br>
JBoss Performance Team<br>
</font></span><div class="gmail-HOEnZb"><div class="gmail-h5"><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></div>