[infinispan-dev] Special cache types and their configuration (or lack of)
Sanne Grinovero
sanne at infinispan.org
Fri Aug 7 07:40:24 EDT 2015
On 7 August 2015 at 11:35, Radim Vansa <rvansa at redhat.com> wrote:
> 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.
Ok, it was worth a try ;-)
Cheers,
Sanne
>
> 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
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
More information about the infinispan-dev
mailing list