On Fri, Aug 15, 2014 at 11:37 AM, Galder Zamarreño <galder(a)redhat.com
wrote:
On 12 Aug 2014, at 22:41, Dan Berindei <dan.berindei(a)gmail.com> wrote:
> On
Tue, Aug 5, 2014 at 11:27 AM, Galder Zamarreño <galder(a)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.
First of all, how would that XML look? Like a regular configuration file,
with one cache of each type? One store of each type? In every cache? How
would we handle defaults for custom stores?
We already have an XML file with default values: infinispan-config-7.0.xsd.
It would be nice if we could parse that and keep the defaults in a single
place, but if we need to duplicate the defaults anyway, I'd rather keep
them in code.
I also think with a separate XML file, we'd still need to
keep some
not-quite-defaults in the various builder.build() methods (or
Configurations methods). My idea was to keep all these in the
*ConfigurationBuilder classes, though I know we'll never get to 100%.
>
> > 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
<mmarkus(a)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_GX5...
> >
> > > Cheers,
> > > --
> > > Mircea Markus
> > > Infinispan lead (
www.infinispan.org)
> >
> >
> >
> >
> >
> >
> _______________________________________________
> > > infinispan-dev mailing list
> > > infinispan-dev(a)lists.jboss.org
> > >
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> > --
> > Galder Zamarreño
> > galder(a)redhat.com
> >
twitter.com/galderz
>
>
> >
_______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev(a)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
> --
> Galder Zamarreño
> galder(a)redhat.com
>
twitter.com/galderz
>
_______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev