[JBoss JIRA] (ISPN-4919) Configuration templates
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/ISPN-4919?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on ISPN-4919:
------------------------------------
[~dan.berindei] On the contrary, you lost that behavior in 5.x.
EmbeddedCacheManager.defineConfiguration(String cacheName, String templateCacheName, Configuration configurationOverride)
... behaves exactly the same as:
EmbeddedCacheManager.defineConfiguration(String cacheName, Configuration configuration)
... since the configurationOverride is fully defined - and thus overrides *everything* in the Configuration of the template cache.
Similarly, using the latter method, the Configuration parameter overrides *everything* in the Configuration of the default cache.
> Configuration templates
> -----------------------
>
> Key: ISPN-4919
> URL: https://issues.jboss.org/browse/ISPN-4919
> Project: Infinispan
> Issue Type: Feature Request
> Components: Configuration
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Fix For: 7.1.0.Beta1
>
>
> Currently there is a 1:1 relationship between configuration and named caches. While the programmatic API does have the ability to .read() an existing configuration to create a new one, the declarative config does not.
> We should introduce the concept of configuration inheritance, e.g.:
> {code}
> <local-cache name="eviction-cache">
> <eviction strategy="LIRS" maxEntries="10000"/>
> </local-cache>
> <local-cache name="mycache" template="eviction-cache" />
> {code}
> Possibly, cache templates should be made "abstract" so that they cannot be instantiated as named caches directly, e.g.:
> {code}
> <local-cache name="eviction-cache" abstract="true">
> ...
> </local-cache>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-4919) Configuration templates
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/ISPN-4919?page=com.atlassian.jira.plugin.... ]
Paul Ferraro edited comment on ISPN-4919 at 12/2/14 11:29 AM:
--------------------------------------------------------------
[~NadirX] I'm not arguing against the concept, just the usability/implementation. It's not just the schema that implies different behavior, but the Resources themselves. The cache resource and its children don't have nullable attributes. Every attribute of a cache and its children (e.g. transaction, locking, etc.) have default values that are applied to the model if no value was specified via a given operation. So, from the perspective of an add/write-attribute operation, there's no simple way to distinguish a value that is intended to be overridden from one that is intended to be inherited -- /unless/ you create parallel resource definitions for templates vs extending caches, where the resource attribute definitions for extending caches are completely nullable.
In general though - the Configuration objects in 4.x did support the concept of overrides - where every property of the cache might be undefined, and thus take a default from some template or default cache. You guys changed this in 5.x-7.0, where Configuration objects are now completely defined. new ConfigurationBuilder().read(configuration) is semantically very different than the 4.x behavior, since a new configuration builder is already completely defined, and the read(Configuration) operation is effectively a means for cloning the entire configuration. Overriding is only every supported via programmatic calls to the resulting configuration builder - which is now a clone of the read configuration.
It sounds like you guys want to revert the current Configuration behavior to be more like the 4.x configuration behavior. Is that a fair summation?
was (Author: pferraro):
[~NadirX] I'm not arguing against the concept, just the usability/implementation. It's not just the schema that implies different behavior, but the Resources themselves. The cache resource and its children don't have nullable attributes. Every attribute of a cache and its children (e.g. transaction, locking, etc.) have default values that are applied to the model if no value was specified via a given operation. So, from the perspective of an add/write-attribute operation, there's no simple way to distinguish a value that is intended to be overridden from one that is intended to be inherited -- /unless/ you create parallel resource definitions for template vs extending caches, where the resource attribute definitions for extending caches are completely nullable.
In general though - the Configuration objects in 4.x did support the concept of overrides - where every property of the cache might be undefined, and thus take a default from some template or default cache. You guys changed this in 5.x-7.0, where Configuration objects are now completely defined. new ConfigurationBuilder().read(configuration) is semantically very different than the 4.x behavior, since a new configuration builder is already completely defined, and the read(Configuration) operation is effectively a means for cloning the entire configuration. Overriding is only every supported via programmatic calls to the resulting configuration builder - which is now a clone of the read configuration.
It sounds like you guys want to revert the current Configuration behavior to be more like the 4.x configuration behavior. Is that a fair summation?
> Configuration templates
> -----------------------
>
> Key: ISPN-4919
> URL: https://issues.jboss.org/browse/ISPN-4919
> Project: Infinispan
> Issue Type: Feature Request
> Components: Configuration
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Fix For: 7.1.0.Beta1
>
>
> Currently there is a 1:1 relationship between configuration and named caches. While the programmatic API does have the ability to .read() an existing configuration to create a new one, the declarative config does not.
> We should introduce the concept of configuration inheritance, e.g.:
> {code}
> <local-cache name="eviction-cache">
> <eviction strategy="LIRS" maxEntries="10000"/>
> </local-cache>
> <local-cache name="mycache" template="eviction-cache" />
> {code}
> Possibly, cache templates should be made "abstract" so that they cannot be instantiated as named caches directly, e.g.:
> {code}
> <local-cache name="eviction-cache" abstract="true">
> ...
> </local-cache>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-4919) Configuration templates
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/ISPN-4919?page=com.atlassian.jira.plugin.... ]
Paul Ferraro edited comment on ISPN-4919 at 12/2/14 11:18 AM:
--------------------------------------------------------------
[~NadirX] I'm not arguing against the concept, just the usability/implementation. It's not just the schema that implies different behavior, but the Resources themselves. The cache resource and its children don't have nullable attributes. Every attribute of a cache and its children (e.g. transaction, locking, etc.) have default values that are applied to the model if no value was specified via a given operation. So, from the perspective of an add/write-attribute operation, there's no simple way to distinguish a value that is intended to be overridden from one that is intended to be inherited -- /unless/ you create parallel resource definitions for template vs extending caches, where the resource attribute definitions for extending caches are completely nullable.
In general though - the Configuration objects in 4.x did support the concept of overrides - where every property of the cache might be undefined, and thus take a default from some template or default cache. You guys changed this in 5.x-7.0, where Configuration objects are now completely defined. new ConfigurationBuilder().read(configuration) is semantically very different than the 4.x behavior, since a new configuration builder is already completely defined, and the read(Configuration) operation is effectively a means for cloning the entire configuration. Overriding is only every supported via programmatic calls to the resulting configuration builder - which is now a clone of the read configuration.
It sounds like you guys want to revert the current Configuration behavior to be more like the 4.x configuration behavior. Is that a fair summation?
was (Author: pferraro):
[~NadirX] I'm not arguing against the concept, just the usability. It's not just the schema that implies different behavior, but the Resources themselves. The cache resource and its children don't have nullable attributes. Every attribute of a cache and its children (e.g. transaction, locking, etc.) have default values that are applied to the model if no value was specified via a given operation. So, from the perspective of an add/write-attribute operation, there's no simple way to distinguish a value that is intended to be overridden from one that is intended to be inherited -- /unless/ you create parallel resource definitions for template vs extending caches, where the resource attribute definitions for extending caches are completely nullable.
In general though - the Configuration objects in 4.x did support the concept of overrides - where every property of the cache might be undefined, and thus take a default from some template or default cache. You guys changed this in 5.x-7.0, where Configuration objects are now completely defined. new ConfigurationBuilder().read(configuration) is semantically very different than the 4.x behavior, since a new configuration builder is already completely defined, and the read(Configuration) operation is effectively a means for cloning the entire configuration. Overriding is only every supported via programmatic calls to the resulting configuration builder - which is now a clone of the read configuration.
It sounds like you guys want to revert the current Configuration behavior to be more like the 4.x configuration behavior. Is that a fair summation?
> Configuration templates
> -----------------------
>
> Key: ISPN-4919
> URL: https://issues.jboss.org/browse/ISPN-4919
> Project: Infinispan
> Issue Type: Feature Request
> Components: Configuration
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Fix For: 7.1.0.Beta1
>
>
> Currently there is a 1:1 relationship between configuration and named caches. While the programmatic API does have the ability to .read() an existing configuration to create a new one, the declarative config does not.
> We should introduce the concept of configuration inheritance, e.g.:
> {code}
> <local-cache name="eviction-cache">
> <eviction strategy="LIRS" maxEntries="10000"/>
> </local-cache>
> <local-cache name="mycache" template="eviction-cache" />
> {code}
> Possibly, cache templates should be made "abstract" so that they cannot be instantiated as named caches directly, e.g.:
> {code}
> <local-cache name="eviction-cache" abstract="true">
> ...
> </local-cache>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-4919) Configuration templates
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/ISPN-4919?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on ISPN-4919:
------------------------------------
[~NadirX] I'm not arguing against the concept, just the usability. It's not just the schema that implies different behavior, but the Resources themselves. The cache resource and its children don't have nullable attributes. Every attribute of a cache and its children (e.g. transaction, locking, etc.) have default values that are applied to the model if no value was specified via a given operation. So, from the perspective of an add/write-attribute operation, there's no simple way to distinguish a value that is intended to be overridden from one that is intended to be inherited -- /unless/ you create parallel resource definitions for template vs extending caches, where the extending caches are completely nullable.
In general though - the Configuration objects in 4.x did support the concept of overrides - where every property of the cache might be undefined, and thus take a default from some template or default cache. You guys changed this in 5.x-7.0, where Configuration objects are now completely defined. new ConfigurationBuilder().read(configuration) is semantically very different than the 4.x behavior, since a new configuration builder is already completely defined, and the read(Configuration) operation is effectively a means for cloning the entire configuration. Overriding is only every supported via programmatic calls to the resulting configuration builder - which is now a clone of the read configuration.
It sounds like you guys want to revert the current Configuration behavior to be more like the 4.x configuration behavior. Is that a fair summation?
> Configuration templates
> -----------------------
>
> Key: ISPN-4919
> URL: https://issues.jboss.org/browse/ISPN-4919
> Project: Infinispan
> Issue Type: Feature Request
> Components: Configuration
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Fix For: 7.1.0.Beta1
>
>
> Currently there is a 1:1 relationship between configuration and named caches. While the programmatic API does have the ability to .read() an existing configuration to create a new one, the declarative config does not.
> We should introduce the concept of configuration inheritance, e.g.:
> {code}
> <local-cache name="eviction-cache">
> <eviction strategy="LIRS" maxEntries="10000"/>
> </local-cache>
> <local-cache name="mycache" template="eviction-cache" />
> {code}
> Possibly, cache templates should be made "abstract" so that they cannot be instantiated as named caches directly, e.g.:
> {code}
> <local-cache name="eviction-cache" abstract="true">
> ...
> </local-cache>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-4919) Configuration templates
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/ISPN-4919?page=com.atlassian.jira.plugin.... ]
Paul Ferraro edited comment on ISPN-4919 at 12/2/14 11:17 AM:
--------------------------------------------------------------
[~NadirX] I'm not arguing against the concept, just the usability. It's not just the schema that implies different behavior, but the Resources themselves. The cache resource and its children don't have nullable attributes. Every attribute of a cache and its children (e.g. transaction, locking, etc.) have default values that are applied to the model if no value was specified via a given operation. So, from the perspective of an add/write-attribute operation, there's no simple way to distinguish a value that is intended to be overridden from one that is intended to be inherited -- /unless/ you create parallel resource definitions for template vs extending caches, where the resource attribute definitions for extending caches are completely nullable.
In general though - the Configuration objects in 4.x did support the concept of overrides - where every property of the cache might be undefined, and thus take a default from some template or default cache. You guys changed this in 5.x-7.0, where Configuration objects are now completely defined. new ConfigurationBuilder().read(configuration) is semantically very different than the 4.x behavior, since a new configuration builder is already completely defined, and the read(Configuration) operation is effectively a means for cloning the entire configuration. Overriding is only every supported via programmatic calls to the resulting configuration builder - which is now a clone of the read configuration.
It sounds like you guys want to revert the current Configuration behavior to be more like the 4.x configuration behavior. Is that a fair summation?
was (Author: pferraro):
[~NadirX] I'm not arguing against the concept, just the usability. It's not just the schema that implies different behavior, but the Resources themselves. The cache resource and its children don't have nullable attributes. Every attribute of a cache and its children (e.g. transaction, locking, etc.) have default values that are applied to the model if no value was specified via a given operation. So, from the perspective of an add/write-attribute operation, there's no simple way to distinguish a value that is intended to be overridden from one that is intended to be inherited -- /unless/ you create parallel resource definitions for template vs extending caches, where the extending caches are completely nullable.
In general though - the Configuration objects in 4.x did support the concept of overrides - where every property of the cache might be undefined, and thus take a default from some template or default cache. You guys changed this in 5.x-7.0, where Configuration objects are now completely defined. new ConfigurationBuilder().read(configuration) is semantically very different than the 4.x behavior, since a new configuration builder is already completely defined, and the read(Configuration) operation is effectively a means for cloning the entire configuration. Overriding is only every supported via programmatic calls to the resulting configuration builder - which is now a clone of the read configuration.
It sounds like you guys want to revert the current Configuration behavior to be more like the 4.x configuration behavior. Is that a fair summation?
> Configuration templates
> -----------------------
>
> Key: ISPN-4919
> URL: https://issues.jboss.org/browse/ISPN-4919
> Project: Infinispan
> Issue Type: Feature Request
> Components: Configuration
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Fix For: 7.1.0.Beta1
>
>
> Currently there is a 1:1 relationship between configuration and named caches. While the programmatic API does have the ability to .read() an existing configuration to create a new one, the declarative config does not.
> We should introduce the concept of configuration inheritance, e.g.:
> {code}
> <local-cache name="eviction-cache">
> <eviction strategy="LIRS" maxEntries="10000"/>
> </local-cache>
> <local-cache name="mycache" template="eviction-cache" />
> {code}
> Possibly, cache templates should be made "abstract" so that they cannot be instantiated as named caches directly, e.g.:
> {code}
> <local-cache name="eviction-cache" abstract="true">
> ...
> </local-cache>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-4444) After state transfer, a node is able to read keys it no longer owns from its data container
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4444?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4444:
-----------------------------------------------
Pedro Ruivo <pruivo(a)redhat.com> changed the Status of [bug 1163665|https://bugzilla.redhat.com/show_bug.cgi?id=1163665] from ASSIGNED to POST
> After state transfer, a node is able to read keys it no longer owns from its data container
> -------------------------------------------------------------------------------------------
>
> Key: ISPN-4444
> URL: https://issues.jboss.org/browse/ISPN-4444
> Project: Infinispan
> Issue Type: Bug
> Components: Core, State Transfer
> Affects Versions: 7.0.0.Alpha4
> Reporter: Dan Berindei
> Assignee: Pedro Ruivo
> Priority: Critical
> Fix For: 7.1.0.Alpha1
>
>
> When state transfer ends and each node receives a CH_UPDATE command from the coordinator, it first installs the new topology and then it starts invalidating entries it no longer owns.
> However, there are two cases when the node can still read its stale values:
> 1. If L1 is enabled, it will look in the local DataContainer first, regardless of the key's location.
> 2. If L1 is disabled, but the key was removed on the new owners, the node will still look up the key in the local DataContainer after receiving a null response.
> The problem can be reproduced with {{TxReadAfterLosingOwnershipTest}} and its subclasses, by replacing the {{operation.update(cache(1));}} line with {{operation.update(cache(0));}}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-4919) Configuration templates
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-4919?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-4919:
------------------------------------
[~pferraro] we have the same situation today, at least in embedded mode: the values inherited from the default cache will override the defaults (mentioned in the XSD).
> Configuration templates
> -----------------------
>
> Key: ISPN-4919
> URL: https://issues.jboss.org/browse/ISPN-4919
> Project: Infinispan
> Issue Type: Feature Request
> Components: Configuration
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Fix For: 7.1.0.Beta1
>
>
> Currently there is a 1:1 relationship between configuration and named caches. While the programmatic API does have the ability to .read() an existing configuration to create a new one, the declarative config does not.
> We should introduce the concept of configuration inheritance, e.g.:
> {code}
> <local-cache name="eviction-cache">
> <eviction strategy="LIRS" maxEntries="10000"/>
> </local-cache>
> <local-cache name="mycache" template="eviction-cache" />
> {code}
> Possibly, cache templates should be made "abstract" so that they cannot be instantiated as named caches directly, e.g.:
> {code}
> <local-cache name="eviction-cache" abstract="true">
> ...
> </local-cache>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-5037) Do not replicate value from backup owner
by Radim Vansa (JIRA)
Radim Vansa created ISPN-5037:
---------------------------------
Summary: Do not replicate value from backup owner
Key: ISPN-5037
URL: https://issues.jboss.org/browse/ISPN-5037
Project: Infinispan
Issue Type: Enhancement
Components: Core
Reporter: Radim Vansa
When a write is replicated from primary owner to backup owner, the backup owner returns the old value. This is unnecessary as the primary owner ignores this value, and introduces networking and marshalling overhead.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-4919) Configuration templates
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-4919?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant commented on ISPN-4919:
---------------------------------------
I think the concept of inheritance is pretty obvious, regardless of what XML Schema's mechanism for "default" attribute values means, and I don't believe anybody would be confused by that.
The issue at the moment is that in Infinispan's ConfigurationBuilders, most values use primitives which do not semantically carry the concept of default/overridden which is something [~dan.berindei] suggested to fix by using some kind of Value wrapper object (similar to the DMR's ModelNode)
> Configuration templates
> -----------------------
>
> Key: ISPN-4919
> URL: https://issues.jboss.org/browse/ISPN-4919
> Project: Infinispan
> Issue Type: Feature Request
> Components: Configuration
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Fix For: 7.1.0.Beta1
>
>
> Currently there is a 1:1 relationship between configuration and named caches. While the programmatic API does have the ability to .read() an existing configuration to create a new one, the declarative config does not.
> We should introduce the concept of configuration inheritance, e.g.:
> {code}
> <local-cache name="eviction-cache">
> <eviction strategy="LIRS" maxEntries="10000"/>
> </local-cache>
> <local-cache name="mycache" template="eviction-cache" />
> {code}
> Possibly, cache templates should be made "abstract" so that they cannot be instantiated as named caches directly, e.g.:
> {code}
> <local-cache name="eviction-cache" abstract="true">
> ...
> </local-cache>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months