2017-10-10 15:03 GMT+02:00 Radim Vansa <rva...@redhat.com>: > On 10/10/2017 11:08 AM, Thomas SEGISMONT wrote: > > > > > > 2017-10-09 18:30 GMT+02:00 Radim Vansa <rva...@redhat.com > > <mailto:rva...@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. >
I ended up doing this and it worked like a charm (see https://github.com/vert-x3/vertx-infinispan/commit/ff2b541f52086578e1015937c36e1f2550c85b4f ) 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 > > > 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 <rva...@redhat.com <mailto:rva...@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 <rva...@redhat.com> > JBoss Performance Team > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > 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