[infinispan-dev] Feedback on MultimapCache

[Thomas SEGISMONT]

2017-10-10 15:03 GMT+02:00 Radim Vansa <rvansa at redhat.com>:

> 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.
>

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 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
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20171011/9c67ac45/attachment-0001.html