[infinispan-dev] Special cache types and their configuration (or lack of)
Radim Vansa
rvansa at redhat.com
Fri Aug 7 06:35:25 EDT 2015
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 at redhat.com
> <mailto:rvansa at 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 at redhat.com
> <mailto:rvansa at 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 at redhat.com <mailto:galder at 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 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
> >>>>>
> >>>> _______________________________________________
> >>>> 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
> >>> _______________________________________________
> >>> 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
> >>
> >> --
> >> 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
> > _______________________________________________
> > 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
>
>
> --
> 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
>
>
>
> _______________________________________________
> 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