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

On 28 July 2014 17:24, Dan Berindei <dan.berindei(a)gmail.com&gt; wrote: > 1. Configuration inheritance: I would go further and allow the definition of > "configurations" that cannot be started, only inherited from. > 2. Replication queue: I discussed an upgrade to the replication queue with > Will, similar to JGroups' TransferQueuBundler [1]. It does raise an > interesting point about why we need the same functionality both in JGroups > and in Infinispan, though... > 3. I think ClusterLoader is still useful in invalidation mode, and also > replication mode w/out state transfer ("lazy" state transfer). What's the use case for asking for REPL but not caring for actual REPL? In such use case I expect data to be either very uninportant (other than performance-wise) or persisted to a shared cachestore: I'd use Invalidation, L1 and maybe even disable state transfer.

Sanne > > [1] https://issues.jboss.org/browse/ISPN-4547 > > Cheers > Dan > > > > On Mon, Jul 28, 2014 at 6:04 PM, Mircea Markus <mmarkus(a)redhat.com&gt; 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 > > > > _______________________________________________ > 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

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

On Tue, Aug 5, 2014 at 11:27 AM, Galder Zamarreño <galder(a)redhat.com&gt; 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(a)redhat.com&gt; 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

On Fri, Aug 15, 2014 at 11:37 AM, Galder Zamarreño <galder(a)redhat.com&gt; wrote: On 12 Aug 2014, at 22:41, Dan Berindei <dan.berindei(a)gmail.com&gt; wrote: > > > > On Tue, Aug 5, 2014 at 11:27 AM, Galder Zamarreño <galder(a)redhat.com&gt; 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&gt; 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 _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On Wed, Aug 20, 2014 at 12:27 PM, Galder Zamarreño <galder(a)redhat.com <mailto:galder@redhat.com>> wrote: On 15 Aug 2014, at 12:41, Dan Berindei <dan.berindei(a)gmail.com <mailto:dan.berindei@gmail.com>> wrote: > > > > On Fri, Aug 15, 2014 at 11:37 AM, Galder Zamarreño <galder(a)redhat.com <mailto:galder@redhat.com>> wrote: > > On 12 Aug 2014, at 22:41, Dan Berindei <dan.berindei(a)gmail.com <mailto:dan.berindei@gmail.com>> wrote: > >> >> >> >> On Tue, Aug 5, 2014 at 11:27 AM, Galder Zamarreño <galder(a)redhat.com <mailto:galder@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? Yeah, could do. Wildfly guys already doing it: https://github.com/wildfly/wildfly/blob/master/clustering/infinispan/src/... > One store of each type? In every cache? How would we handle defaults for custom stores? The defaults for custom stores are the same as for any other cache store. The only thing you cannot default is the custom store specific stuff, which is specific to the custom store :) Except you can't include them in the default XML, because the default XML is in core (I assume) and the custom stores are not.

You could have a JDBC_CACHE_STORE cache with the defaults for JDBC cache stores...etc. In what XML file? > 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. An XSD file is not an XML file. By having the defaults in an XML file, we can validate it and confirm that it's a valid XML file that we can parse it. Users don't load Infinispan with XSD files :) I'm pretty sure infinispan-config-7.0.xsd is a valid XML file, it even starts with a standard XML declaration: <?xml version="1.0" encoding="UTF-8" standalone="yes"?> To avoid duplication, I'd be tempted to remove all default values from the XSD file and keep them only in the reference XML file. It would definitely be harder to look up the reference XML and check the defaults, compared to a Ctrl+click on the element/attribute name with the XSD. Of course, the XSD only allows one default value for each attribute, and even duplicating the element types for each cache mode sounds pretty daunting.

> 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). ^ What defaults are you talking about? Can you provide an example of such default options? With an XML, you could even have different defaults depending on the other attributes of the cache. E.g. say you have an OL cache, you could say that the default value for writeSkew with OL is true, whereas with PL, the default value is false. Yeah, that would be a good example of what I was thinking about :) But I was thinking we shouldn't just change the default value, we should also throw an exception when the user tries to enable write skew in a PL cache. That check would have to stay in the builder class - not a default, but still related.

On Tue, Aug 5, 2014 at 11:27 AM, Galder Zamarreño <galder(a)redhat.com&gt; 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.

On Wed, Aug 20, 2014 at 1:08 PM, Sanne Grinovero <sanne(a)infinispan.org&gt; wrote: > > On 12 August 2014 21:41, Dan Berindei <dan.berindei(a)gmail.com&gt; wrote: > > > > > > > > On Tue, Aug 5, 2014 at 11:27 AM, Galder Zamarreño <galder(a)redhat.com&gt; > > 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. > > That would be nice but needs some care, say for example that I want to > inject a custom JDBCCacheStore by instance which has a reference to a > datasource (Extremely useful use case). Shouldn't the datasource be registered in JNDI anyway? If yes, you could serialize the JNDI name.

> I could make it serializable by changing it from a CacheStore instance > to some kind of "CacheStoreLookupStrategy" but you'd need to give me > some hook we can react on to restore the references. Once again (as > asked previously) allowing to register custom components by instance > in the CacheManager's component Registry would solve this. > We already allow this: EmbeddedCacheManager.getGlobalComponentRegistry().registerComponent(instance, name)

On Wed, Aug 20, 2014 at 2:32 PM, Sanne Grinovero <sanne(a)infinispan.org&gt; wrote: > > On 20 August 2014 11:19, Dan Berindei <dan.berindei(a)gmail.com&gt; wrote: > > > > > > > > On Wed, Aug 20, 2014 at 1:08 PM, Sanne Grinovero <sanne(a)infinispan.org&gt; > > wrote: > >> > >> On 12 August 2014 21:41, Dan Berindei <dan.berindei(a)gmail.com&gt; wrote: > >> > > >> > > >> > > >> > On Tue, Aug 5, 2014 at 11:27 AM, Galder Zamarreño <galder(a)redhat.com&gt; > >> > 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. > >> > >> That would be nice but needs some care, say for example that I want to > >> inject a custom JDBCCacheStore by instance which has a reference to a > >> datasource (Extremely useful use case). > > > > > > Shouldn't the datasource be registered in JNDI anyway? If yes, you could > > serialize the JNDI name. > > You don't want to require the user to need to match configuration > settings in different configuration files of what he considers one > platform. > And we support many more options beyond JNDI. > Still, usually we want to share datasources for pooling, so the cache store should look up its datasource somewhere instead of creating a new connection pool for each cache.

> >> I could make it serializable by changing it from a CacheStore instance > >> to some kind of "CacheStoreLookupStrategy" but you'd need to give me > >> some hook we can react on to restore the references. Once again (as > >> asked previously) allowing to register custom components by instance > >> in the CacheManager's component Registry would solve this. > >> > > > > We already allow this: > > > > > > EmbeddedCacheManager.getGlobalComponentRegistry().registerComponent(instance, > > name) > > Can I use that before the CacheManager is started? Sure, all DefaultCacheManager.start() does is register some MBeans in JMX. > > > -- Sanne > > _______________________________________________ > 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

On 12/08/14 22:41, Dan Berindei wrote: > > 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... Can't we store the configuration defs in the cluster registry ? If a node attempts to overwrite an existing configuration based on the same name, an exception can be thrown.

On 26/08/14 15:50, Dan Berindei wrote: > > The cluster registry also uses a clustered cache, how would we ship > the cache configuration around for that cache? Currently the configuration for the cluster registry is static, so there isn't any need to propagate it. My reasoning obviously falls over when we want to add some configuration to it, such as persistence.

> > The cluster registry is also too limited to do this check ATM, as it > doesn't support conditional operations. I'm not sure whether that's > because they just weren't needed, or it's an intentional limitation. > I think it was just laziness. Tristan _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev