[infinispan-dev] Feedback on MultimapCache

Radim Vansa rvansa at redhat.com
Tue Oct 10 09:03:50 EDT 2017


On 10/10/2017 11:08 AM, Thomas SEGISMONT wrote:
>
>
> 2017-10-09 18:30 GMT+02:00 Radim Vansa <rvansa at redhat.com 
> <mailto:rvansa at redhat.com>>:
>
>     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
>     > infinispan-dev at lists.jboss.org
>     <mailto:infinispan-dev at lists.jboss.org>
>     > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>     <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>
>
>     --
>     Radim Vansa <rvansa at redhat.com <mailto:rvansa at redhat.com>>
>     JBoss Performance Team
>
>     _______________________________________________
>     infinispan-dev mailing list
>     infinispan-dev at lists.jboss.org <mailto:infinispan-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>     <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team



More information about the infinispan-dev mailing list