4:44 p.m.
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 :
public interface CacheMultimap<K, V> {
V put(K key, V value);
Collection<V> get(K key);
boolean remove(K key, V value);
}
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);
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
[2]
https://github.com/vert-x3/vertx-infinispan/blob/master/src/main/java/io/...
[3] https://gist.github.com/karesti/194bb998856d4a2828d83754130ed79c
6:12 p.m.
On Tue, Apr 4, 2017 at 3:44 PM, Katia Aresti <karesti(a)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.
Sounds a great idea! This structure could be useful internally as well, for
example in the Lucene directory, where we emulate a multimap using a
DeltaAware Set in the value + IGNORE_RETURN_VALUE flag for better
performance.
As a quick start, the smallest multimap we need should implement the
following interface :
public interface CacheMultimap<K, V> {
V put(K key, V value);
What would it return here?
Gustavo
Collection<V> get(K key);
boolean remove(K key, V value);
}
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);
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
[2] 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
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
6:40 p.m.
On Tue, Apr 4, 2017 at 11:45 AM Katia Aresti <karesti(a)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> {
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.
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.
}
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`.
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
[2]
https://github.com/vert-x3/vertx-infinispan/blob/master/src/main/java/io/...
[3] https://gist.github.com/karesti/194bb998856d4a2828d83754130ed79c
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
8:47 a.m.
@Gustavo, Concerning put it should return void, yes ! :D a little
copy/paste mistake in the mail from me, sorry !
On Tue, Apr 4, 2017 at 6:40 PM, William Burns <mudokonman(a)gmail.com> wrote:
On Tue, Apr 4, 2017 at 11:45 AM Katia Aresti <karesti(a)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> {
> 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.
>
> 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.
> }
>
> 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`.
>
>
> 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
>
> [2] 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
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
9:56 a.m.
On 04/04/2017 06:40 PM, William Burns wrote:
On Tue, Apr 4, 2017 at 11:45 AM Katia Aresti <karesti(a)redhat.com
<mailto:karesti@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.
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.
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
[2]
https://github.com/vert-x3/vertx-infinispan/blob/master/src/main/java/io/...
[3] https://gist.github.com/karesti/194bb998856d4a2828d83754130ed79c
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org <mailto:infinispan-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Radim Vansa <rvansa(a)redhat.com>
JBoss Performance Team
12:15 a.m.
On Wed, Apr 5, 2017 at 9:56 AM, Radim Vansa <rvansa(a)redhat.com> wrote:
On 04/04/2017 06:40 PM, William Burns wrote:
>
>
> On Tue, Apr 4, 2017 at 11:45 AM Katia Aresti <karesti(a)redhat.com
> <mailto:karesti@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 ?
> 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.
> 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
>
> [2]
> 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
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org <mailto:infinispan-dev@lists.
jboss.org>
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Radim Vansa <rvansa(a)redhat.com>
JBoss Performance Team
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
11:04 a.m.
On 04/06/2017 12:15 AM, Katia Aresti wrote:
On Wed, Apr 5, 2017 at 9:56 AM, Radim Vansa <rvansa(a)redhat.com
<mailto:rvansa@redhat.com>> wrote:
On 04/04/2017 06:40 PM, William Burns wrote:
>
>
> On Tue, Apr 4, 2017 at 11:45 AM Katia Aresti <karesti(a)redhat.com
<mailto:karesti@redhat.com>
> <mailto:karesti@redhat.com <mailto:karesti@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/...
<https://github.com/vert-x3/vertx-infinispan/blob/master/src/main/java/io/...
>
> [3]
https://gist.github.com/karesti/194bb998856d4a2828d83754130ed79c
<https://gist.github.com/karesti/194bb998856d4a2828d83754130ed79c>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)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(a)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 <rvansa(a)redhat.com <mailto:rvansa@redhat.com>>
JBoss Performance Team
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Radim Vansa <rvansa(a)redhat.com>
JBoss Performance Team
2:29 p.m.
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 <rvansa(a)redhat.com> wrote:
On 04/06/2017 12:15 AM, Katia Aresti wrote:
>
>
> On Wed, Apr 5, 2017 at 9:56 AM, Radim Vansa <rvansa(a)redhat.com
> <mailto:rvansa@redhat.com>> wrote:
>
> On 04/04/2017 06:40 PM, William Burns wrote:
> >
> >
> > On Tue, Apr 4, 2017 at 11:45 AM Katia Aresti <karesti(a)redhat.com
> <mailto:karesti@redhat.com>
> > <mailto:karesti@redhat.com <mailto:karesti@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(a)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(a)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 <rvansa(a)redhat.com <mailto:rvansa@redhat.com>>
> JBoss Performance Team
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Radim Vansa <rvansa(a)redhat.com>
JBoss Performance Team
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
12:25 p.m.
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 ! :)
Cheers
Katia
On Thu, Apr 6, 2017 at 2:29 PM, Katia Aresti <karesti(a)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 <rvansa(a)redhat.com> wrote:
> On 04/06/2017 12:15 AM, Katia Aresti wrote:
> >
> >
> > On Wed, Apr 5, 2017 at 9:56 AM, Radim Vansa <rvansa(a)redhat.com
> > <mailto:rvansa@redhat.com>> wrote:
> >
> > On 04/04/2017 06:40 PM, William Burns wrote:
> > >
> > >
> > > On Tue, Apr 4, 2017 at 11:45 AM Katia Aresti <karesti(a)redhat.com
> > <mailto:karesti@redhat.com>
> > > <mailto:karesti@redhat.com <mailto:karesti@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/InfinispanAs
> yncMultiMap.java
> > <https://github.com/vert-x3/vertx-infinispan/blob/master/sr
> c/main/java/io/vertx/ext/cluster/infinispan/impl/InfinispanA
> syncMultiMap.java>
> > >
> > > [3]
> > https://gist.github.com/karesti/194bb998856d4a2828d83754130ed79c
> > <https://gist.github.com/karesti/194bb998856d4a2828d83754130ed79c>
> > > _______________________________________________
> > > infinispan-dev mailing list
> > > infinispan-dev(a)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(a)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 <rvansa(a)redhat.com <mailto:rvansa@redhat.com>>
> > JBoss Performance Team
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev(a)lists.jboss.org <mailto:infinispan-dev@lists.j
> boss.org>
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> > <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
> >
> >
> >
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> --
> Radim Vansa <rvansa(a)redhat.com>
> JBoss Performance Team
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
1 p.m.
On 10 April 2017 at 11:25, Katia Aresti <karesti(a)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 <karesti(a)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 <rvansa(a)redhat.com> wrote:
>>
>> On 04/06/2017 12:15 AM, Katia Aresti wrote:
>> >
>> >
>> > On Wed, Apr 5, 2017 at 9:56 AM, Radim Vansa <rvansa(a)redhat.com
>> > <mailto:rvansa@redhat.com>> wrote:
>> >
>> > On 04/04/2017 06:40 PM, William Burns wrote:
>> > >
>> > >
>> > > On Tue, Apr 4, 2017 at 11:45 AM Katia Aresti
<karesti(a)redhat.com
>> > <mailto:karesti@redhat.com>
>> > > <mailto:karesti@redhat.com
<mailto:karesti@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/...
>> >
>> >
<https://github.com/vert-x3/vertx-infinispan/blob/master/src/main/java/io/...
>> > >
>> > > [3]
>> > https://gist.github.com/karesti/194bb998856d4a2828d83754130ed79c
>> >
<https://gist.github.com/karesti/194bb998856d4a2828d83754130ed79c>
>> > > _______________________________________________
>> > > infinispan-dev mailing list
>> > > infinispan-dev(a)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(a)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 <rvansa(a)redhat.com <mailto:rvansa@redhat.com>>
>> > JBoss Performance Team
>> >
>> > _______________________________________________
>> > infinispan-dev mailing list
>> > infinispan-dev(a)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(a)lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>> --
>> Radim Vansa <rvansa(a)redhat.com>
>> JBoss Performance Team
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
11:31 p.m.
--
Galder Zamarreño
Infinispan, Red Hat
On 6 Apr 2017, at 11:04, Radim Vansa <rvansa(a)redhat.com>
wrote:
On 04/06/2017 12:15 AM, Katia Aresti wrote:
>
>
> On Wed, Apr 5, 2017 at 9:56 AM, Radim Vansa <rvansa(a)redhat.com
> <mailto:rvansa@redhat.com>> wrote:
>
> On 04/04/2017 06:40 PM, William Burns wrote:
>>
>>
>> On Tue, Apr 4, 2017 at 11:45 AM Katia Aresti <karesti(a)redhat.com
> <mailto:karesti@redhat.com>
>> <mailto:karesti@redhat.com <mailto:karesti@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.
Amen!
CompletableFuture is not a rocket science, and you can use the
already
asynchronous Infinispan internals.
Indeed!
CompletableFuture is good.
In hindsight, I would have maybe chosen java.util.concurrent.CompletionStage since
it's more flexible (interface vs class), and doesn't bring in
java.util.concurrent.Future which contains blocking methods.
CompletableFuture/CompletionStage works for single returns. The bigger problem is when you
want multiple returns asynchronously. Here a can of worms opens up, e.g. do you push the
results? do you pull the results?
For the functional map API, we experimented with a pull model using Traversable. A push
model is harder to implement and non-trivial, and there you're getting into Rx
territory.
I don't think we should have two interfaces, I believe that
single
interface with async methods only is absolutely sufficient.
^ I'm not so sure actually... Both sets of methods are used for different use cases.
Conceptually and from a user's perspective, I'd rather have separate interfaces
since I'd not expect calls to both use cases to be interleaved.
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.
^ We shouldn't promote calling Future.get() for asynchronous APIs since it goes
against everything that async APIs stand for ;)
>
>> 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/...
>
<https://github.com/vert-x3/vertx-infinispan/blob/master/src/main/java/io/...
>>
>> [3]
> https://gist.github.com/karesti/194bb998856d4a2828d83754130ed79c
> <https://gist.github.com/karesti/194bb998856d4a2828d83754130ed79c>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)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(a)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 <rvansa(a)redhat.com <mailto:rvansa@redhat.com>>
> JBoss Performance Team
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Radim Vansa <rvansa(a)redhat.com>
JBoss Performance Team
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
10:05 a.m.
I love the idea of starting with a simple interface, so +1000 from me.
I'm also assuming that our new MultiMap will be accessible in both Embedded
and Client/Server mode, am I correct? I also think CacheMultimap should
extend Iterable. I suspect some of our users might want to use for-each
loop with it. Finally, we also need to think about some integration bits
(maybe not for the initial implementation but it might be beneficial to
create JIRAs for them). With CDI and Spring support we can make them super
easy to use (by injecting newly created instances to the users code:
@Inject CacheMultimap myMap<String, String>).
I also put some more comments below. Nice proposal Katia!
On Tue, Apr 4, 2017 at 7:09 PM William Burns <mudokonman(a)gmail.com> wrote:
On Tue, Apr 4, 2017 at 11:45 AM Katia Aresti
<karesti(a)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> {
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.
Could you please tell me more why are you suggesting boolean or void?
Returning previous value would make it more similar to a Map.
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.
+1
}
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);
How about the other way around? Something like:
static <K, V> CacheMultimap<K, V> CacheMultimap.create(BasicCache<K,V>
cache);
This way we would avoid dependency from DefaultCacheManager
to CacheMultimap. If we wanted to support both Embedded/Client Server mode
we would probably need to use BasicCache as a parameter. The last argument
for this solution is that creating producers in CDI/Spring would be trivial
(we would just need to provide a generic producer method and with some luck
that would be it).
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`.
If we want to support both Embedded/Client Server mode, it should go to
commons. Otherwise I would vote for core.
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
[2]
https://github.com/vert-x3/vertx-infinispan/blob/master/src/main/java/io/...
[3] https://gist.github.com/karesti/194bb998856d4a2828d83754130ed79c
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
SEBASTIAN ŁASKAWIEC
INFINISPAN DEVELOPER
Red Hat EMEA <https://www.redhat.com/>
<https://red.ht/sig>
2:42 p.m.
On 05/04/2017 10:05, Sebastian Laskawiec wrote:
I love the idea of starting with a simple interface, so +1000 from
me.
I'm also assuming that our new MultiMap will be accessible in both
Embedded and Client/Server mode, am I correct?
Agreed. The design must take into account both variants before it can be
considered ready.
Tristan
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
4:34 p.m.
On Wed, Apr 5, 2017 at 4:30 AM Sebastian Laskawiec <slaskawi(a)redhat.com>
wrote:
I love the idea of starting with a simple interface, so +1000 from
me.
I'm also assuming that our new MultiMap will be accessible in both
Embedded and Client/Server mode, am I correct? I also think CacheMultimap
should extend Iterable. I suspect some of our users might want to use
for-each loop with it. Finally, we also need to think about some
integration bits (maybe not for the initial implementation but it might be
beneficial to create JIRAs for them). With CDI and Spring support we can
make them super easy to use (by injecting newly created instances to the
users code: @Inject CacheMultimap myMap<String, String>).
I also put some more comments below. Nice proposal Katia!
On Tue, Apr 4, 2017 at 7:09 PM William Burns <mudokonman(a)gmail.com> wrote:
On Tue, Apr 4, 2017 at 11:45 AM Katia Aresti <karesti(a)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> {
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.
Could you please tell me more why are you suggesting boolean or void?
Returning previous value would make it more similar to a Map.
The value of the MultiMap is a Collection<V> which in this version doesn't
allow duplicates. By returning boolean we can say if the value was added
(true) or it was already present (false).
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.
+1
}
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);
How about the other way around? Something like:
static <K, V> CacheMultimap<K, V> CacheMultimap.create(BasicCache<K,V>
cache);
This way we would avoid dependency from DefaultCacheManager
to CacheMultimap. If we wanted to support both Embedded/Client Server mode
we would probably need to use BasicCache as a parameter. The last argument
for this solution is that creating producers in CDI/Spring would be trivial
(we would just need to provide a generic producer method and with some luck
that would be it).
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`.
If we want to support both Embedded/Client Server mode, it should go to
commons. Otherwise I would vote for core.
Commons should work. Only problem is the functional commands don't really
work efficiently over Hot Rod (does get/replace in a loop). We would need
to add some more handling in the protocol to allow for only partial
replication of values and only 1 remote call.
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
[2]
https://github.com/vert-x3/vertx-infinispan/blob/master/src/main/java/io/...
[3] https://gist.github.com/karesti/194bb998856d4a2828d83754130ed79c
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
SEBASTIAN ŁASKAWIEC
INFINISPAN DEVELOPER
Red Hat EMEA
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
10:42 a.m.
On 04/05/2017 04:34 PM, William Burns wrote:
On Wed, Apr 5, 2017 at 4:30 AM Sebastian Laskawiec
<slaskawi(a)redhat.com <mailto:slaskawi@redhat.com>> wrote:
I love the idea of starting with a simple interface, so +1000 from
me.
I'm also assuming that our new MultiMap will be accessible in both
Embedded and Client/Server mode, am I correct? I also think
CacheMultimap should extend Iterable. I suspect some of our users
might want to use for-each loop with it. Finally, we also need to
think about some integration bits (maybe not for the initial
implementation but it might be beneficial to create JIRAs for
them). With CDI and Spring support we can make them super easy to
use (by injecting newly created instances to the users code:
@Inject CacheMultimap myMap<String, String>).
I also put some more comments below. Nice proposal Katia!
On Tue, Apr 4, 2017 at 7:09 PM William Burns
<mudokonman(a)gmail.com> wrote:
On Tue, Apr 4, 2017 at 11:45 AM Katia Aresti
<karesti(a)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> {
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.
Could you please tell me more why are you suggesting boolean or
void? Returning previous value would make it more similar to a Map.
The value of the MultiMap is a Collection<V> which in this version
doesn't allow duplicates. By returning boolean we can say if the value
was added (true) or it was already present (false).
If it does not allow duplicates, why get() does not return a Set<V>?
Btw., there are other ~useful return types possible, e.g. `int`
returning size of the collection pre/post modification (not advocating
that, though - I would personally rather see the boolean, if not
CompletableFuture<Boolean>).
I wouldn't return the whole previous value (full collection).
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.
+1
}
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);
How about the other way around? Something like:
static <K, V> CacheMultimap<K, V>
CacheMultimap.create(BasicCache<K,V> cache);
This way we would avoid dependency from DefaultCacheManager
to CacheMultimap. If we wanted to support both Embedded/Client
Server mode we would probably need to use BasicCache as a
parameter. The last argument for this solution is that creating
producers in CDI/Spring would be trivial (we would just need to
provide a generic producer method and with some luck that would be
it).
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`.
If we want to support both Embedded/Client Server mode, it should
go to commons. Otherwise I would vote for core.
Commons should work. Only problem is the functional commands don't
really work efficiently over Hot Rod (does get/replace in a loop). We
would need to add some more handling in the protocol to allow for only
partial replication of values and only 1 remote call.
I guess that only the CacheMultimap interface (+ maybe some helper
classes) should land in commons, the actual implementation (in
hotrod-client module or its extension module) wouldn't use compute()
over Hot Rod.
R.
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
[2]
https://github.com/vert-x3/vertx-infinispan/blob/master/src/main/java/io/...
[3]
https://gist.github.com/karesti/194bb998856d4a2828d83754130ed79c
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
SEBASTIANŁASKAWIEC
INFINISPAN DEVELOPER
Red HatEMEA
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Radim Vansa <rvansa(a)redhat.com>
JBoss Performance Team
11:31 p.m.
--
Galder Zamarreño
Infinispan, Red Hat
On 5 Apr 2017, at 10:05, Sebastian Laskawiec
<slaskawi(a)redhat.com> wrote:
I love the idea of starting with a simple interface, so +1000 from me.
I'm also assuming that our new MultiMap will be accessible in both Embedded and
Client/Server mode, am I correct? I also think CacheMultimap should extend Iterable. I
suspect some of our users might want to use for-each loop with it.
Hmmmm, that would only really work for a synchronous API version. For async you'd
something like Traversable that we did for the functional map experiment.
Finally, we also need to think about some integration bits (maybe not
for the initial implementation but it might be beneficial to create JIRAs for them). With
CDI and Spring support we can make them super easy to use (by injecting newly created
instances to the users code: @Inject CacheMultimap myMap<String, String>).
I also put some more comments below. Nice proposal Katia!
On Tue, Apr 4, 2017 at 7:09 PM William Burns <mudokonman(a)gmail.com> wrote:
On Tue, Apr 4, 2017 at 11:45 AM Katia Aresti <karesti(a)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> {
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.
Could you please tell me more why are you suggesting boolean or void? Returning previous
value would make it more similar to a Map.
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.
+1
}
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);
How about the other way around? Something like:
static <K, V> CacheMultimap<K, V> CacheMultimap.create(BasicCache<K,V>
cache);
This way we would avoid dependency from DefaultCacheManager to CacheMultimap. If we
wanted to support both Embedded/Client Server mode we would probably need to use
BasicCache as a parameter. The last argument for this solution is that creating producers
in CDI/Spring would be trivial (we would just need to provide a generic producer method
and with some luck that would be it).
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`.
If we want to support both Embedded/Client Server mode, it should go to commons.
Otherwise I would vote for core.
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
[2]
https://github.com/vert-x3/vertx-infinispan/blob/master/src/main/java/io/...
[3] https://gist.github.com/karesti/194bb998856d4a2828d83754130ed79c
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
SEBASTIAN ŁASKAWIEC
INFINISPAN DEVELOPER
Red Hat EMEA
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
9:47 a.m.
Hi Galder !
Thanks for your comments and ideas ! I'm going to move the content you
posted in the list to the design PR here : https://github.com/infinispan/
infinispan-designs/pull/3
++
Katia
On Thu, Apr 13, 2017 at 11:31 PM, Galder Zamarreño <galder(a)redhat.com>
wrote:
--
Galder Zamarreño
Infinispan, Red Hat
> On 5 Apr 2017, at 10:05, Sebastian Laskawiec <slaskawi(a)redhat.com>
wrote:
>
> I love the idea of starting with a simple interface, so +1000 from me.
>
> I'm also assuming that our new MultiMap will be accessible in both
Embedded and Client/Server mode, am I correct? I also think CacheMultimap
should extend Iterable. I suspect some of our users might want to use
for-each loop with it.
Hmmmm, that would only really work for a synchronous API version. For
async you'd something like Traversable that we did for the functional map
experiment.
> Finally, we also need to think about some integration bits (maybe not
for the initial implementation but it might be beneficial to create JIRAs
for them). With CDI and Spring support we can make them super easy to use
(by injecting newly created instances to the users code: @Inject
CacheMultimap myMap<String, String>).
>
> I also put some more comments below. Nice proposal Katia!
>
> On Tue, Apr 4, 2017 at 7:09 PM William Burns <mudokonman(a)gmail.com>
wrote:
> On Tue, Apr 4, 2017 at 11:45 AM Katia Aresti <karesti(a)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> {
> 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.
>
> Could you please tell me more why are you suggesting boolean or void?
Returning previous value would make it more similar to a Map.
>
> 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.
>
> +1
>
> }
> 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);
>
> How about the other way around? Something like:
> static <K, V> CacheMultimap<K, V>
CacheMultimap.create(BasicCache<K,V>
cache);
>
> This way we would avoid dependency from DefaultCacheManager to
CacheMultimap. If we wanted to support both Embedded/Client Server mode we
would probably need to use BasicCache as a parameter. The last argument for
this solution is that creating producers in CDI/Spring would be trivial (we
would just need to provide a generic producer method and with some luck
that would be it).
>
>
> 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`.
>
> If we want to support both Embedded/Client Server mode, it should go to
commons. Otherwise I would vote for core.
>
>
>
>
> 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
>
> [2] 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
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> --
> SEBASTIAN ŁASKAWIEC
> INFINISPAN DEVELOPER
> Red Hat EMEA
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
10:22 a.m.
Hi Katia,
2017-04-04 16:44 GMT+02:00 Katia Aresti <karesti(a)redhat.com>:
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!)
This can't be the primary goal. Making it the best cluster manager would be
great though!
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 :
public interface CacheMultimap<K, V> {
V put(K key, V value);
Collection<V> get(K key);
boolean remove(K key, V value);
}
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);
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.
One thing we need in vertx-infinispan is the ability to clean the multimap,
meaning removing some key/value pairs if value matches criteria.
It doesn't seem possible with this interface. At least, it misses a method
to get all the keys from this multimap. Ideally, I would like to be able to
supply a Serializable Predicate.
Cheers
Katia
Thank you for looking into this!
[1] 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
[3] https://gist.github.com/karesti/194bb998856d4a2828d83754130ed79c
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
2822
days inactive
2832
days old
infinispan-dev@lists.jboss.org
17 comments
9 participants
participants (9)
-
Galder Zamarreño -
Gustavo Fernandes -
Katia Aresti -
Radim Vansa -
Sanne Grinovero -
Sebastian Laskawiec -
Thomas SEGISMONT -
Tristan Tarrant -
William Burns