On 12 Aug 2014, at 22:41, Dan Berindei <dan.berin...@gmail.com> wrote:
> > > > On Tue, Aug 5, 2014 at 11:27 AM, Galder Zamarreño <gal...@redhat.com> wrote: > Can’t comment on the document, so here are my thoughts: > > Re: “Get rid of lazy cache starting...all the caches run on all nodes...it > should still be possible to start a cache at runtime, but it will be run on > all nodes as well” > > ^ Though I like the idea, it might change a crucial aspect of how default > cache configuration works (if we leave the concept of default cache at all). > Say you start a cache named “a” for which there’s no config. Up until now > we’d use the default cache configuration and create a cache “a” with that > config. However, if caches are started cluster wide now, before you can do > that, you’d have to check that there’s no cache “a” configuration anywhere in > the cluster. If there is, I guess the configuration would be shipped to the > node that starts the cache (if it does not have it) and create the cache with > it? Or are you assuming all nodes in the cluster must have all configurations > defined? > > +1 to remove the default cache as a default configuration. > > I like the idea of shipping the cache configuration to all the nodes. We will > have to require any user-provided objects in the configuration to be > serializable/externalizable, but I don't see a big problem with that. > > In fact, it would also allow us to send the entire configuration to the > coordinator on join, so we could verify that the configuration on all nodes > is compatible (not exactly the same, since things like capacityFactor can be > different). And it would remove the need for the CacheJoinInfo class... > > A more limited alternative, not requiring config serialization, would be to > disallow getCache(name) when a configuration doesn't exist but add a method > createCache(name, configurationName) that only requires configurationName to > be defined everywhere. > > > Re: “Revisiting Configuration elements…" > > If we’re going to do another round of updates in this area, I think we should > consider what to do with unconfigured values. Back in the 4.x days, the JAXB > XML parsing allowed us to know which configuration elements the user had not > configured, which helped us tweak configuration and do validation more > easily. Now, when we look at a Configuration builder object, we see default > values but we do not that a value is the one it is because the user has > specifically defined it, or because it’s unconfigured. One way to do so is by > separating the default values, say to an XML file which is reference (I think > WF does something along these lines) and leave the builder object with all > null values. This would make it easy to figure out which elements have been > touched and for that those that have not, use default values. This has popped > up in the forums before but can’t find a link right now... > > I was also thinking of doing something like that, but instead of having a > separate XML with the defaults I was going to propose creating a layer of > indirection: every configuration value would be a ConfigurationProperty<T>, > with a default value, an override value, and an actual value. We already do > something similar for e.g. StateTransferConfiguration.awaitInitialTransfer > and originalAwaitInitialTransfer). ^ What’s the problem with a separate XML file? I really like the idea of externalizing default values from a documentation perspective and ease of change down the line, both for us and for users. On top of that, it could be validated and be presented as a reference XML file, getting rid of the sample XML file that we currently have which is half done and no one really updates it. > > I haven't seen the forum post, but I think that would allow us more properly > validate conflicting configuration values. E.g. the checks in > Configurations.isVersioningEnabled() could be moved to > ConfigurationBuilder.validate()/create(). Totally, validation right now it’s quite tricky due to the lack of separation. Cheers, > > > Cheers, > > On 28 Jul 2014, at 17:04, Mircea Markus <mmar...@redhat.com> wrote: > > > Hi, > > > > Tristan, Sanne, Gustavo and I meetlast week to discuss a) Infinispan > > usability and b) monitoring and management. Minutes attached. > > > > https://docs.google.com/document/d/1dIxH0xTiYBHH6_nkqybc13_zzW9gMIcaF_GX5Y7_PPQ/edit?usp=sharing > > > > Cheers, > > -- > > Mircea Markus > > Infinispan lead (www.infinispan.org) > > > > > > > > > > > > _______________________________________________ > > infinispan-dev mailing list > > infinispan-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > -- > Galder Zamarreño > gal...@redhat.com > twitter.com/galderz > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño gal...@redhat.com twitter.com/galderz _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
