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

>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


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

_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev