[infinispan-dev] minutes from the monitoring&management meeting

[Dan Berindei]

On Tue, Aug 5, 2014 at 11:27 AM, Galder Zamarreño <galder at 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).

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().


>
> Cheers,
>
> On 28 Jul 2014, at 17:04, Mircea Markus <mmarkus at 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 at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> --
> Galder Zamarreño
> galder at redhat.com
> twitter.com/galderz
>
>
> _______________________________________________
> 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/20140812/ed7392b2/attachment.html