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?
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...
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