[infinispan-dev] Feedback on MultimapCache

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

[infinispan-dev] Feedback on MultimapCache

Thomas SEGISMONT
Hi,

I've created a branch in vertx-infinispan to start incorporating the new features in 9.2.

https://github.com/vert-x3/vertx-infinispan/tree/ispn92

Here are a couple of comments/concerns on MultimapCache:
1/ EmbeddedMultimapCacheManagerFactory#from returns a raw MultimapCacheManager; it would be nice to have type arguments instead, to avoid unchecked assignment warnings
2/ MultimapCache does not accept entry listeners. We use them to build a near cache to increase the speed of sending

1/ is easy, but do you think 2/ could be added in 9.2?

Thank you,
Thomas

_______________________________________________
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] Feedback on MultimapCache

Radim Vansa
On 10/09/2017 03:04 PM, Thomas SEGISMONT wrote:

> Hi,
>
> I've created a branch in vertx-infinispan to start incorporating the
> new features in 9.2.
>
> https://github.com/vert-x3/vertx-infinispan/tree/ispn92 
> <https://github.com/vert-x3/vertx-infinispan/tree/ispn92>
>
> Here are a couple of comments/concerns on MultimapCache:
> 1/ EmbeddedMultimapCacheManagerFactory#from returns a raw
> MultimapCacheManager; it would be nice to have type arguments instead,
> to avoid unchecked assignment warnings
> 2/ MultimapCache does not accept entry listeners. We use them to build
> a near cache to increase the speed of sending

Do you need clustered listeners or only those on owners? Btw., you can
register a listener on the underlying cache, but I agree that an
interface that will adapt it correctly (e.g. mapping @EntryModified on
multi-value to @EntryCreated on the new value) would appear less crude.

R.

>
> 1/ is easy, but do you think 2/ could be added in 9.2?
>
> Thank you,
> Thomas
>
>
> _______________________________________________
> 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] Feedback on MultimapCache

Emmanuel Bernard
Stupid question. Hot Rod does not have near cache invalidation already ? Does not suit your needs or not implemented for multimapcache?

> On 9 Oct 2017, at 18:30, Radim Vansa <[hidden email]> wrote:
>
>> On 10/09/2017 03:04 PM, Thomas SEGISMONT wrote:
>> Hi,
>>
>> I've created a branch in vertx-infinispan to start incorporating the
>> new features in 9.2.
>>
>> https://github.com/vert-x3/vertx-infinispan/tree/ispn92 
>> <https://github.com/vert-x3/vertx-infinispan/tree/ispn92>
>>
>> Here are a couple of comments/concerns on MultimapCache:
>> 1/ EmbeddedMultimapCacheManagerFactory#from returns a raw
>> MultimapCacheManager; it would be nice to have type arguments instead,
>> to avoid unchecked assignment warnings
>> 2/ MultimapCache does not accept entry listeners. We use them to build
>> a near cache to increase the speed of sending
>
> Do you need clustered listeners or only those on owners? Btw., you can
> register a listener on the underlying cache, but I agree that an
> interface that will adapt it correctly (e.g. mapping @EntryModified on
> multi-value to @EntryCreated on the new value) would appear less crude.
>
> R.
>
>>
>> 1/ is easy, but do you think 2/ could be added in 9.2?
>>
>> Thank you,
>> Thomas
>>
>>
>> _______________________________________________
>> 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] Feedback on MultimapCache

Thomas SEGISMONT
In reply to this post by Radim Vansa


2017-10-09 18:30 GMT+02:00 Radim Vansa <[hidden email]>:
On 10/09/2017 03:04 PM, Thomas SEGISMONT wrote:
> Hi,
>
> I've created a branch in vertx-infinispan to start incorporating the
> new features in 9.2.
>
> https://github.com/vert-x3/vertx-infinispan/tree/ispn92
> <https://github.com/vert-x3/vertx-infinispan/tree/ispn92>
>
> Here are a couple of comments/concerns on MultimapCache:
> 1/ EmbeddedMultimapCacheManagerFactory#from returns a raw
> MultimapCacheManager; it would be nice to have type arguments instead,
> to avoid unchecked assignment warnings
> 2/ MultimapCache does not accept entry listeners. We use them to build
> a near cache to increase the speed of sending

Do you need clustered listeners or only those on owners? Btw., you can
register a listener on the underlying cache, but I agree that an
interface that will adapt it correctly (e.g. mapping @EntryModified on
multi-value to @EntryCreated on the new value) would appear less crude.

We need clustered listeners because any member should be able to update its near cache.

If a listener is registered on the underlying cache, the event payload would be the full collection when an element is added/removed from the multimap cache?
 

R.

>
> 1/ is easy, but do you think 2/ could be added in 9.2?
>
> Thank you,
> Thomas
>
>
> _______________________________________________
> 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] Feedback on MultimapCache

Thomas SEGISMONT
In reply to this post by Emmanuel Bernard
We don't use the Infinispan client, we use Infinispan embedded. We could use Infinispan Client if there were:
- an API for retrieving a list of connected clients (preferably w/ some properties, like when I connect I tell the server I want to join the Vert.x cluster)
- events when other clients connect/leave

Besides multimap is available for embedded mode right now. I'm not sure but I believe it's the same for clustered counters.

2017-10-09 19:21 GMT+02:00 Emmanuel Bernard <[hidden email]>:
Stupid question. Hot Rod does not have near cache invalidation already ? Does not suit your needs or not implemented for multimapcache?

> On 9 Oct 2017, at 18:30, Radim Vansa <[hidden email]> wrote:
>
>> On 10/09/2017 03:04 PM, Thomas SEGISMONT wrote:
>> Hi,
>>
>> I've created a branch in vertx-infinispan to start incorporating the
>> new features in 9.2.
>>
>> https://github.com/vert-x3/vertx-infinispan/tree/ispn92
>> <https://github.com/vert-x3/vertx-infinispan/tree/ispn92>
>>
>> Here are a couple of comments/concerns on MultimapCache:
>> 1/ EmbeddedMultimapCacheManagerFactory#from returns a raw
>> MultimapCacheManager; it would be nice to have type arguments instead,
>> to avoid unchecked assignment warnings
>> 2/ MultimapCache does not accept entry listeners. We use them to build
>> a near cache to increase the speed of sending
>
> Do you need clustered listeners or only those on owners? Btw., you can
> register a listener on the underlying cache, but I agree that an
> interface that will adapt it correctly (e.g. mapping @EntryModified on
> multi-value to @EntryCreated on the new value) would appear less crude.
>
> R.
>
>>
>> 1/ is easy, but do you think 2/ could be added in 9.2?
>>
>> Thank you,
>> Thomas
>>
>>
>> _______________________________________________
>> 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] Feedback on MultimapCache

Katia Aresti
In reply to this post by Emmanuel Bernard
Hi Thomas,

Thank you for the first feedback ! :)
We can add listeners on the cache directly, yes, but without specific listeners, the payload will contain all the values. I'm going to check with the team to estimate the modifications needed and the impact for this particular case.

Concerning hotrod, even if this is not used for vert.x cluster manager, Multimap will support it soon :)

Katia


On Mon, Oct 9, 2017 at 7:21 PM, Emmanuel Bernard <[hidden email]> wrote:
Stupid question. Hot Rod does not have near cache invalidation already ? Does not suit your needs or not implemented for multimapcache?

> On 9 Oct 2017, at 18:30, Radim Vansa <[hidden email]> wrote:
>
>> On 10/09/2017 03:04 PM, Thomas SEGISMONT wrote:
>> Hi,
>>
>> I've created a branch in vertx-infinispan to start incorporating the
>> new features in 9.2.
>>
>> https://github.com/vert-x3/vertx-infinispan/tree/ispn92
>> <https://github.com/vert-x3/vertx-infinispan/tree/ispn92>
>>
>> Here are a couple of comments/concerns on MultimapCache:
>> 1/ EmbeddedMultimapCacheManagerFactory#from returns a raw
>> MultimapCacheManager; it would be nice to have type arguments instead,
>> to avoid unchecked assignment warnings
>> 2/ MultimapCache does not accept entry listeners. We use them to build
>> a near cache to increase the speed of sending
>
> Do you need clustered listeners or only those on owners? Btw., you can
> register a listener on the underlying cache, but I agree that an
> interface that will adapt it correctly (e.g. mapping @EntryModified on
> multi-value to @EntryCreated on the new value) would appear less crude.
>
> R.
>
>>
>> 1/ is easy, but do you think 2/ could be added in 9.2?
>>
>> Thank you,
>> Thomas
>>
>>
>> _______________________________________________
>> 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] Feedback on MultimapCache

Pedro Ruivo-2
In reply to this post by Thomas SEGISMONT


On 10-10-2017 10:13, Thomas SEGISMONT wrote:
> Besides multimap is available for embedded mode right now. I'm not sure
> but I believe it's the same for clustered counters.

Yes the counters are available in Embedded. They will be added to Hot
Rod soon.
_______________________________________________
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] Feedback on MultimapCache

Radim Vansa
In reply to this post by Thomas SEGISMONT
On 10/10/2017 11:08 AM, Thomas SEGISMONT wrote:

>
>
> 2017-10-09 18:30 GMT+02:00 Radim Vansa <[hidden email]
> <mailto:[hidden email]>>:
>
>     On 10/09/2017 03:04 PM, Thomas SEGISMONT wrote:
>     > Hi,
>     >
>     > I've created a branch in vertx-infinispan to start incorporating the
>     > new features in 9.2.
>     >
>     > https://github.com/vert-x3/vertx-infinispan/tree/ispn92
>     <https://github.com/vert-x3/vertx-infinispan/tree/ispn92>
>     > <https://github.com/vert-x3/vertx-infinispan/tree/ispn92
>     <https://github.com/vert-x3/vertx-infinispan/tree/ispn92>>
>     >
>     > Here are a couple of comments/concerns on MultimapCache:
>     > 1/ EmbeddedMultimapCacheManagerFactory#from returns a raw
>     > MultimapCacheManager; it would be nice to have type arguments
>     instead,
>     > to avoid unchecked assignment warnings
>     > 2/ MultimapCache does not accept entry listeners. We use them to
>     build
>     > a near cache to increase the speed of sending
>
>     Do you need clustered listeners or only those on owners? Btw., you can
>     register a listener on the underlying cache, but I agree that an
>     interface that will adapt it correctly (e.g. mapping @EntryModified on
>     multi-value to @EntryCreated on the new value) would appear less
>     crude.
>
>
> We need clustered listeners because any member should be able to
> update its near cache.
>
> If a listener is registered on the underlying cache, the event payload
> would be the full collection when an element is added/removed from the
> multimap cache?

Yes, by default all the values stored under that key. And the event type
wouldn't be correct. You'd probably want to use addFilteredListener to
diff previous and current value on owner-side and send only the changed
entries.

>
>     R.
>
>     >
>     > 1/ is easy, but do you think 2/ could be added in 9.2?
>     >
>     > Thank you,
>     > Thomas
>     >
>     >
>     > _______________________________________________
>     > 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] Feedback on MultimapCache

Thomas SEGISMONT
In reply to this post by Pedro Ruivo-2


2017-10-10 11:26 GMT+02:00 Pedro Ruivo <[hidden email]>:


On 10-10-2017 10:13, Thomas SEGISMONT wrote:
> Besides multimap is available for embedded mode right now. I'm not sure
> but I believe it's the same for clustered counters.

Yes the counters are available in Embedded. They will be added to Hot
Rod soon.

Thanks Pedro. I have a question about counters as well, may I proceed here or do you prefer to discuss it in a separate thread?
 
_______________________________________________
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] Feedback on MultimapCache

Pedro Ruivo-2


On Tue, 10 Oct 2017, 15:24 Thomas SEGISMONT, <[hidden email]> wrote:
2017-10-10 11:26 GMT+02:00 Pedro Ruivo <[hidden email]>:


On 10-10-2017 10:13, Thomas SEGISMONT wrote:
> Besides multimap is available for embedded mode right now. I'm not sure
> but I believe it's the same for clustered counters.

Yes the counters are available in Embedded. They will be added to Hot
Rod soon.

Thanks Pedro. I have a question about counters as well, may I proceed here or do you prefer to discuss it in a separate thread?

Please create another thread :)

I might take a while to reply since I'm at airport waiting for my flight. 

 
_______________________________________________
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] Feedback on MultimapCache

Thomas SEGISMONT
In reply to this post by Radim Vansa


2017-10-10 15:03 GMT+02:00 Radim Vansa <[hidden email]>:
On 10/10/2017 11:08 AM, Thomas SEGISMONT wrote:
>
>
> 2017-10-09 18:30 GMT+02:00 Radim Vansa <[hidden email]
> <mailto:[hidden email]>>:
>
>     On 10/09/2017 03:04 PM, Thomas SEGISMONT wrote:
>     > Hi,
>     >
>     > I've created a branch in vertx-infinispan to start incorporating the
>     > new features in 9.2.
>     >
>     > https://github.com/vert-x3/vertx-infinispan/tree/ispn92
>     <https://github.com/vert-x3/vertx-infinispan/tree/ispn92>
>     > <https://github.com/vert-x3/vertx-infinispan/tree/ispn92
>     <https://github.com/vert-x3/vertx-infinispan/tree/ispn92>>
>     >
>     > Here are a couple of comments/concerns on MultimapCache:
>     > 1/ EmbeddedMultimapCacheManagerFactory#from returns a raw
>     > MultimapCacheManager; it would be nice to have type arguments
>     instead,
>     > to avoid unchecked assignment warnings
>     > 2/ MultimapCache does not accept entry listeners. We use them to
>     build
>     > a near cache to increase the speed of sending
>
>     Do you need clustered listeners or only those on owners? Btw., you can
>     register a listener on the underlying cache, but I agree that an
>     interface that will adapt it correctly (e.g. mapping @EntryModified on
>     multi-value to @EntryCreated on the new value) would appear less
>     crude.
>
>
> We need clustered listeners because any member should be able to
> update its near cache.
>
> If a listener is registered on the underlying cache, the event payload
> would be the full collection when an element is added/removed from the
> multimap cache?

Yes, by default all the values stored under that key. And the event type
wouldn't be correct. You'd probably want to use addFilteredListener to
diff previous and current value on owner-side and send only the changed
entries.


I explored a suggestion from Will regarding L1 caching. But then I realized we'll always need our own near cache, as we maintain a "ChoosableSet" view of eventbus handlers (to balance the load)
 

>
>     R.
>
>     >
>     > 1/ is easy, but do you think 2/ could be added in 9.2?
>     >
>     > Thank you,
>     > Thomas
>     >
>     >
>     > _______________________________________________
>     > 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