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

Fri Aug 7 05:32:38 EDT 2015

+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> 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> 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>
> 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>
> >>>>> JBoss Performance Team
> >>>>>
> >>>>> _______________________________________________
> >>>>> infinispan-dev mailing list
> >>>>> 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
> >>> _______________________________________________
> >>> 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
> > _______________________________________________
> > 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/20150807/56fa68d9/attachment.html