[infinispan-dev] Native Infinispan Multimap support

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

[infinispan-dev] Native Infinispan Multimap support

Katia Aresti
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, VCacheMultimap<K, V> getCacheMultimap(String cacheName, boolean createIfAbsent);

Implementation will create a cache as always and return a new CacheMultimapImpl(cache). 


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Native Infinispan Multimap support

Gustavo Fernandes-2
On Tue, Apr 4, 2017 at 3:44 PM, Katia Aresti <[hidden email]> 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, VCacheMultimap<K, V> getCacheMultimap(String cacheName, boolean createIfAbsent);

Implementation will create a cache as always and return a new CacheMultimapImpl(cache). 


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Native Infinispan Multimap support

William Burns-3
In reply to this post by Katia Aresti


On Tue, Apr 4, 2017 at 11:45 AM Katia Aresti <[hidden email]> 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, VCacheMultimap<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). 

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Native Infinispan Multimap support

Katia Aresti

@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 <[hidden email]> wrote:


On Tue, Apr 4, 2017 at 11:45 AM Katia Aresti <[hidden email]> 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, VCacheMultimap<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). 

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Native Infinispan Multimap support

Radim Vansa
In reply to this post by William Burns-3
On 04/04/2017 06:40 PM, William Burns wrote:

>
>
> On Tue, Apr 4, 2017 at 11:45 AM Katia Aresti <[hidden email]
> <mailto:[hidden email]>> 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/vertx/ext/cluster/infinispan/impl/InfinispanAsyncMultiMap.java
>
>     [3] https://gist.github.com/karesti/194bb998856d4a2828d83754130ed79c
>     _______________________________________________
>     infinispan-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Radim Vansa <[hidden email]>
JBoss Performance Team

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Native Infinispan Multimap support

Sebastian Laskawiec
In reply to this post by William Burns-3
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 <[hidden email]> wrote:
On Tue, Apr 4, 2017 at 11:45 AM Katia Aresti <[hidden email]> 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, VCacheMultimap<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). 

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--

SEBASTIAN ŁASKAWIEC

INFINISPAN DEVELOPER


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Native Infinispan Multimap support

Thomas SEGISMONT
In reply to this post by Katia Aresti
Hi Katia,

2017-04-04 16:44 GMT+02:00 Katia Aresti <[hidden email]>:
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, VCacheMultimap<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!
 

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Native Infinispan Multimap support

Tristan Tarrant-2
In reply to this post by Sebastian Laskawiec


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
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Native Infinispan Multimap support

William Burns-3
In reply to this post by Sebastian Laskawiec


On Wed, Apr 5, 2017 at 4:30 AM Sebastian Laskawiec <[hidden email]> 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 <[hidden email]> wrote:
On Tue, Apr 4, 2017 at 11:45 AM Katia Aresti <[hidden email]> 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, VCacheMultimap<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). 

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--

SEBASTIAN ŁASKAWIEC

INFINISPAN DEVELOPER

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Native Infinispan Multimap support

Katia Aresti
In reply to this post by Radim Vansa


On Wed, Apr 5, 2017 at 9:56 AM, Radim Vansa <[hidden email]> wrote:
On 04/04/2017 06:40 PM, William Burns wrote:
>
>
> On Tue, Apr 4, 2017 at 11:45 AM Katia Aresti <[hidden email]
> <mailto:[hidden email]>> 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
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Radim Vansa <[hidden email]>
JBoss Performance Team

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Native Infinispan Multimap support

Radim Vansa
In reply to this post by William Burns-3
On 04/05/2017 04:34 PM, William Burns wrote:

>
>
> On Wed, Apr 5, 2017 at 4:30 AM Sebastian Laskawiec
> <[hidden email] <mailto:[hidden email]>> 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
>     <[hidden email]> wrote:
>
>         On Tue, Apr 4, 2017 at 11:45 AM Katia Aresti
>         <[hidden email]> 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/vertx/ext/cluster/infinispan/impl/InfinispanAsyncMultiMap.java
>
>             [3]
>             https://gist.github.com/karesti/194bb998856d4a2828d83754130ed79c
>
>             _______________________________________________
>             infinispan-dev mailing list
>             [hidden email]
>             https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>         _______________________________________________
>         infinispan-dev mailing list
>         [hidden email]
>         https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>     --
>
>     SEBASTIANŁASKAWIEC
>
>     INFINISPAN DEVELOPER
>
>     Red HatEMEA
>
>     _______________________________________________
>     infinispan-dev mailing list
>     [hidden email]
>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Radim Vansa <[hidden email]>
JBoss Performance Team

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Native Infinispan Multimap support

Radim Vansa
In reply to this post by Katia Aresti
On 04/06/2017 12:15 AM, Katia Aresti wrote:

>
>
> On Wed, Apr 5, 2017 at 9:56 AM, Radim Vansa <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     On 04/04/2017 06:40 PM, William Burns wrote:
>     >
>     >
>     > On Tue, Apr 4, 2017 at 11:45 AM Katia Aresti <[hidden email]
>     <mailto:[hidden email]>
>     > <mailto:[hidden email] <mailto:[hidden email]>>> 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
>     > [hidden email]
>     <mailto:[hidden email]>
>     <mailto:[hidden email]
>     <mailto:[hidden email]>>
>     > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>     <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>     >
>     >
>     >
>     > _______________________________________________
>     > infinispan-dev mailing list
>     > [hidden email]
>     <mailto:[hidden email]>
>     > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>     <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>
>
>     --
>     Radim Vansa <[hidden email] <mailto:[hidden email]>>
>     JBoss Performance Team
>
>     _______________________________________________
>     infinispan-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>     <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Radim Vansa <[hidden email]>
JBoss Performance Team

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Native Infinispan Multimap support

Katia Aresti
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 <[hidden email]> wrote:
On 04/06/2017 12:15 AM, Katia Aresti wrote:
>
>
> On Wed, Apr 5, 2017 at 9:56 AM, Radim Vansa <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     On 04/04/2017 06:40 PM, William Burns wrote:
>     >
>     >
>     > On Tue, Apr 4, 2017 at 11:45 AM Katia Aresti <[hidden email]
>     <mailto:[hidden email]>
>     > <mailto:[hidden email] <mailto:[hidden email]>>> 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
>     > [hidden email]
>     <mailto:[hidden email]>
>     <mailto:[hidden email]
>     <mailto:[hidden email]>>
>     > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>     <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>     >
>     >
>     >
>     > _______________________________________________
>     > infinispan-dev mailing list
>     > [hidden email]
>     <mailto:[hidden email]>
>     > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>     <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>
>
>     --
>     Radim Vansa <[hidden email] <mailto:[hidden email]>>
>     JBoss Performance Team
>
>     _______________________________________________
>     infinispan-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>     <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Radim Vansa <[hidden email]>
JBoss Performance Team

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Native Infinispan Multimap support

Katia Aresti
Hi all

I've moved the discussion to infinispan-designs


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 <[hidden email]> 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 <[hidden email]> wrote:
On 04/06/2017 12:15 AM, Katia Aresti wrote:
>
>
> On Wed, Apr 5, 2017 at 9:56 AM, Radim Vansa <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     On 04/04/2017 06:40 PM, William Burns wrote:
>     >
>     >
>     > On Tue, Apr 4, 2017 at 11:45 AM Katia Aresti <[hidden email]
>     <mailto:[hidden email]>
>     > <mailto:[hidden email] <mailto:[hidden email]>>> 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
>     > [hidden email]
>     <mailto:[hidden email]>
>     <mailto:[hidden email]
>     <mailto:[hidden email]>>
>     > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>     <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>     >
>     >
>     >
>     > _______________________________________________
>     > infinispan-dev mailing list
>     > [hidden email]
>     <mailto:[hidden email]>
>     > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>     <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>
>
>     --
>     Radim Vansa <[hidden email] <mailto:[hidden email]>>
>     JBoss Performance Team
>
>     _______________________________________________
>     infinispan-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>     <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Radim Vansa <[hidden email]>
JBoss Performance Team

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev



_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Native Infinispan Multimap support

Sanne Grinovero-3
On 10 April 2017 at 11:25, Katia Aresti <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>>
>>> On 04/06/2017 12:15 AM, Katia Aresti wrote:
>>> >
>>> >
>>> > On Wed, Apr 5, 2017 at 9:56 AM, Radim Vansa <[hidden email]
>>> > <mailto:[hidden email]>> wrote:
>>> >
>>> >     On 04/04/2017 06:40 PM, William Burns wrote:
>>> >     >
>>> >     >
>>> >     > On Tue, Apr 4, 2017 at 11:45 AM Katia Aresti <[hidden email]
>>> >     <mailto:[hidden email]>
>>> >     > <mailto:[hidden email] <mailto:[hidden email]>>> 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
>>> >     > [hidden email]
>>> >     <mailto:[hidden email]>
>>> >     <mailto:[hidden email]
>>> >     <mailto:[hidden email]>>
>>> >     > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>> >     <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>>> >     >
>>> >     >
>>> >     >
>>> >     > _______________________________________________
>>> >     > infinispan-dev mailing list
>>> >     > [hidden email]
>>> >     <mailto:[hidden email]>
>>> >     > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>> >     <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>>> >
>>> >
>>> >     --
>>> >     Radim Vansa <[hidden email] <mailto:[hidden email]>>
>>> >     JBoss Performance Team
>>> >
>>> >     _______________________________________________
>>> >     infinispan-dev mailing list
>>> >     [hidden email]
>>> > <mailto:[hidden email]>
>>> >     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>> >     <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>>> >
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > infinispan-dev mailing list
>>> > [hidden email]
>>> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>>
>>> --
>>> Radim Vansa <[hidden email]>
>>> JBoss Performance Team
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Native Infinispan Multimap support

Galder Zamarreño
In reply to this post by Radim Vansa

--
Galder Zamarreño
Infinispan, Red Hat

> On 6 Apr 2017, at 11:04, Radim Vansa <[hidden email]> wrote:
>
> On 04/06/2017 12:15 AM, Katia Aresti wrote:
>>
>>
>> On Wed, Apr 5, 2017 at 9:56 AM, Radim Vansa <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>   On 04/04/2017 06:40 PM, William Burns wrote:
>>>
>>>
>>> On Tue, Apr 4, 2017 at 11:45 AM Katia Aresti <[hidden email]
>>   <mailto:[hidden email]>
>>> <mailto:[hidden email] <mailto:[hidden email]>>> 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/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
>>> [hidden email]
>>   <mailto:[hidden email]>
>>   <mailto:[hidden email]
>>   <mailto:[hidden email]>>
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>   <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>>>
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>   <mailto:[hidden email]>
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>   <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>>
>>
>>   --
>>   Radim Vansa <[hidden email] <mailto:[hidden email]>>
>>   JBoss Performance Team
>>
>>   _______________________________________________
>>   infinispan-dev mailing list
>>   [hidden email] <mailto:[hidden email]>
>>   https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>   <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>>
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> --
> Radim Vansa <[hidden email]>
> JBoss Performance Team
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Native Infinispan Multimap support

Galder Zamarreño
In reply to this post by Sebastian Laskawiec

--
Galder Zamarreño
Infinispan, Red Hat

> On 5 Apr 2017, at 10:05, Sebastian Laskawiec <[hidden email]> 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 <[hidden email]> wrote:
> On Tue, Apr 4, 2017 at 11:45 AM Katia Aresti <[hidden email]> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> --
> SEBASTIAN ŁASKAWIEC
> INFINISPAN DEVELOPER
> Red Hat EMEA
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Native Infinispan Multimap support

Katia Aresti
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 <[hidden email]> wrote:

--
Galder Zamarreño
Infinispan, Red Hat

> On 5 Apr 2017, at 10:05, Sebastian Laskawiec <[hidden email]> 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 <[hidden email]> wrote:
> On Tue, Apr 4, 2017 at 11:45 AM Katia Aresti <[hidden email]> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> --
> SEBASTIAN ŁASKAWIEC
> INFINISPAN DEVELOPER
> Red Hat EMEA
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev