Re: [infinispan-dev] Special cache types and their configuration (or lack of)

The simple cache is just a thin wrapper over DataContainer, and uses listeners, CacheNotifier and all that stuff from infinispan-core. The low-dependency part is BoundedConcurrentHashMap.

Radim On 08/07/2015 11:32 AM, Sanne Grinovero wrote: > > +1 > If it doesn't get too complex, I would love to see that packaged in a > low-dependency module. That's of course secondary, but we'd be using > it in many more projects. > > Thanks, > Sanne > > On 7 Aug 2015 10:05, "Radim Vansa" <rvansa(a)redhat.com > <mailto:rvansa@redhat.com>> wrote: > > It seems that I am outnumbered by the 'new local-cache attribute' camp > (though not convinced!). If there is not any other input on this > topic, > I'll migrate that to local attribute, since I want to squeeze simple > cache to 8.0.0.Final > (That attribute will need to be explicitly set, I will not > implement any > hot-switch) > > Radim > > On 08/05/2015 10:24 PM, Dan Berindei wrote: > > On Wed, Aug 5, 2015 at 5:31 PM, Radim Vansa <rvansa(a)redhat.com > <mailto:rvansa@redhat.com>> wrote: > >> On 08/05/2015 03:37 PM, Dan Berindei wrote: > >>> Radim's implementation already throws exceptions when the > application > >>> tries to use unsupported features like throwing exceptions. The > >>> question is how to choose the simple cache: a new CacheMode/XML > >>> element, an attribute on the local-cache element, or reusing the > >>> existing configuration to figure out whether the user needs > advanced > >>> features. > >>> > >>> Radim's implementation uses a new CacheMode and a new > "simple-cache" > >>> XML element. I feel this makes it too visible, since it's based on > >>> what we can do now without an interceptor stack, and that > might change > >>> in the future. > >>> > >>> I'm in the "new local-cache attribute" camp, because the > programmatic > >>> configuration has to validate all those impossible configurations > >>> anyway. In the UI as well, when a user tries to create a cache > with a > >>> store, I think it's better to tell him explicitly that he > can't add a > >>> store to a simple cache, than let him wonder why there isn't any > >>> option to add a store in Infinispan. > >> What UI do you mean? IDE with XSD, or does Infinispan have any > tool with > >> Mr. Clippy? > > I meant the server (and WildFly) management console. No Clippy > there, > > at least not yet :) > > > >> Not having a button/configuration element is IMO the _proper_ > way to > >> tell the user 'You can't do that', rather than showing > pop-up/throwing > >> exception with 'Don't press this button, please!'. I admit that > >> exception with link to docs is more _BFU-proof_, though. If > users really > >> cared about the schema, there wouldn't be so many threads where > they try > >> to copy-paste embedded configuration into server. The parser error > >> message should be more ironic, like 'Something's wrong. I won't > tell you > >> what, but your XSD schema validator will!' > >> > > I admit having only the options that really work in the XSD and > > relying on the XSD to point out mistakes seems cleaner. My > concern is > > discoverability: the user may be looking for an option that's only > > available on a local-cache, and there's nothing telling them to > > replace simple-cache with local-cache. > > > >>> I don't really like the idea of switching the cache implementation > >>> dynamically, either. From the JIT's point of view, I think a > call site > >>> in an application is likely to always use the same kind of > cache, so > >>> the call will be monomorphic most of the time. But as a user, I'd > >>> rather have something that's constantly slow than something that's > >>> initially fast and then suddenly gets slower without me > knowing why. > >> +1 I was about to write the dynamic switcher, but having consistent > >> performance is strong argument against that. > >> > >> Radim > >> > >>> Cheers > >>> Dan > >>> > >>> > >>> > >>> On Wed, Aug 5, 2015 at 11:48 AM, Galder Zamarreno > <galder(a)redhat.com <mailto:galder@redhat.com>> wrote: > >>>> Indeed, JCache, MR and DistExec assume you'll be given a > fully fledged Cache instance that allows them to do things that go > beyond the basics, so as correctly pointed out here, it's hard to > make the distinction purely based on the configuration. > >>>> > >>>> My gut feeling is that we need a way to specifically build a > simple/basic cache directly based on your use case. With existing > usages out there, you can't simply get a simple/basic cache just > like that since a lot of the existing use cases expect to be able > to use advanced features. An easy solution, as hinted by Radim, > would be to have a wrapper for a simple/basic cache, which takes a > standard Cache in, but don't go as far as to allow dynamic > switching. E.g. if you chose to build a simple/basic cache, then > things like add interceptor would fail...etc. I think this would > work well for scenarios such as 2LC where we can control how the > cache to be used is constructed. However, in scenarios where we > expect it to work magically with existing code, it'd not work due > to the need to know about the wrapper. > >>>> > >>>> Cheers, > >>>> -- > >>>> Galder Zamarreño > >>>> Infinispan, Red Hat > >>>> > >>>> ----- Original Message ----- > >>>>> There's one glitch that needs to be stressed: some > limitations of > >>>>> simplified cache are not discoverable on creation time. While > >>>>> persistence, tx and others are, adding custom interceptors > and running > >>>>> map-reduce or distributed-executors can't be guessed when > the cache is > >>>>> created. > >>>>> I could (theoretically) implement MR and DistExec, but never > the custom > >>>>> interceptors: the idea of simple cache is that there are *no > >>>>> interceptors*. And regrettably, this is not as rare case as > I have > >>>>> initially assumed, as for example JCaches grab any cache, > insert their > >>>>> interceptor and provide the wrapper. > >>>>> > >>>>> One way to go would be to not return the simple cache > directly, but wrap > >>>>> it in a delegating cache that would switch the > implementation on the fly > >>>>> as soon as someone tries to play with interceptors. However, > this is not > >>>>> without cost - the delegate would have to read a volatile > field and > >>>>> execute megamorphic call upon every cache operation. > Applications could > >>>>> get around that by doing instanceof and calling unwrap > method during > >>>>> initialization, but it's not really elegant solution. > >>>>> > >>>>> I wanted the choice transparent to the user from the > beginning, but it's > >>>>> not a way to go without penalties. > >>>>> > >>>>> For those who will suggest 'just a flag on local cache': > Following the > >>>>> 'less configuration, not more' I believe that the amount of > >>>>> runtime-prohibited configurations should be kept at minimum. > With such > >>>>> flag, we would expand the state space of configuration 2 > times, while > >>>>> 95% of the configurations would be illegal. That's why I > have rather > >>>>> used new cache mode than adding a flag. > >>>>> > >>>>> Radim > >>>>> > >>>>> On 07/27/2015 04:41 PM, Tristan Tarrant wrote: > >>>>>> Hi all, > >>>>>> > >>>>>> I wanted to bring attention to some discussion that has > happened in the > >>>>>> context of Radim's work on simplified code for specific > cache types [1]. > >>>>>> > >>>>>> In particular, Radim proposes adding explicit configuration > options > >>>>>> (i.e. a new simple-cache cache type) to the > programmatic/declarative API > >>>>>> to ensure that a user is aware of the limitations of the > resulting cache > >>>>>> type (no interceptors, no persistence, no tx, etc). > >>>>>> > >>>>>> My opinion is that we should aim for "less" configuration > and not > >>>>>> "more", and that optimizations such as these should get enabled > >>>>>> implicitly when the parameters allow it: if the > configuration code > >>>>>> detects it can use a "simple" cache. > >>>>>> > >>>>>> Also, this choice should happen at cache construction time, > and not > >>>>>> dynamically at cache usage time. > >>>>>> > >>>>>> WDYT ? > >>>>>> > >>>>>> Tristan > >>>>>> > >>>>>> [1] https://github.com/infinispan/infinispan/pull/3577 > >>>>> -- > >>>>> Radim Vansa <rvansa(a)redhat.com <mailto:rvansa@redhat.com>> > >>>>> JBoss Performance Team > >>>>> > >>>>> _______________________________________________ > >>>>> infinispan-dev mailing list > >>>>> infinispan-dev(a)lists.jboss.org > <mailto:infinispan-dev@lists.jboss.org> > >>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev > >>>>> > >>>> _______________________________________________ > >>>> infinispan-dev mailing list > >>>> infinispan-dev(a)lists.jboss.org > <mailto:infinispan-dev@lists.jboss.org> > >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev > >>> _______________________________________________ > >>> infinispan-dev mailing list > >>> infinispan-dev(a)lists.jboss.org > <mailto:infinispan-dev@lists.jboss.org> > >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev > >> > >> -- > >> Radim Vansa <rvansa(a)redhat.com <mailto:rvansa@redhat.com>> > >> JBoss Performance Team > >> > >> _______________________________________________ > >> infinispan-dev mailing list > >> infinispan-dev(a)lists.jboss.org > <mailto:infinispan-dev@lists.jboss.org> > >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > > infinispan-dev mailing list > > infinispan-dev(a)lists.jboss.org > <mailto:infinispan-dev@lists.jboss.org> > > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > -- > Radim Vansa <rvansa(a)redhat.com <mailto:rvansa@redhat.com>> > JBoss Performance Team > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org <mailto:infinispan-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Radim Vansa <rvansa(a)redhat.com&gt; JBoss Performance Team _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev