[ https://issues.jboss.org/browse/AS7-3478?page=com.atlassian.jira.plugin.s... ] Richard Achmatowicz commented on AS7-3478: ------------------------------------------ Yes, my mistake. I reworked the description providers last week to be based on AttributeDefinitions and it looks as though I left out adding the clustered cache attributes (of which MODE is one) to invalidation-cache, replicated-cache and distributed-cache. Fixing. Thanks again! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-3478?page=com.atlassian.jira.plugin.s... ] Richard Achmatowicz commented on AS7-3478: ------------------------------------------ With the current setup, creating separate attribute definitions for these two is a problem. At the moment, we do not use resources in the Infinispan subsystem, and we store all AttributeDefinitions in an interface called CommonAttributes. In other words, attribute definitions have global scope. The net effect is that it is not easy to set up a situation where two attributes are accessed within the model by different keys (e.g. cache-mode and txn-mode) and yet these attributes use the same parameter name in add or read-attribute commands (i.e. mode). This is the case we have with use of the key "mode" which is used both in cache mode processing as well as transaction mode processing: {noformat} <cache mode="ASYNC" .../> ... <transaction mode="NON_XA" .../> {noformat} Previously, we were using one AttributeDefinition for MODE to handle both cases, but we can no longer as cache mode is required and txn mode is not. So we need two definitions. But defining AttributeDefinitions CACHE_MODE and TXN_MODE force the add() command parameter names to change from CacheAdd(mode=,...) to CacheAdd(cache-mode=,...) and similarly when adding a transaction element. In order to work around this, I created as ShareableNameAttributeDefinition: {noformat} ShareableNameAttributeDefinition CACHE_MODE = new ShareableNameAttributeDefinition(ModelKeys.CACHE_MODE, ModelKeys.MODE, ModelType.STRING, false, null, new CacheModeValidator(false)); {noformat} This allows specifying for an attribute, not only a different xmlName() (to be used when processing XML elements), but also a cliName() ( used when generating attribute and operation parameter descriptions for the add() and read-attribute() write-attribute() commands). So, we can now define two AttributeDefinitions for CACHE_MODE and TXN_MODE and still allow them to use the key "mode" in their operation descriptions. When we move to resources, this can go. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-3478?page=com.atlassian.jira.plugin.s... ] Richard Achmatowicz commented on AS7-3478: ------------------------------------------ Results: {noformat} [standalone@localhost:9999 /] /subsystem=infinispan/cache-container=hibernate/distributed-cache=*/:read-operation-description(name=add) { "outcome" => "success", "result" => { "operation-name" => "add", "description" => "Add a distributed cache to this cache container", "request-properties" => { "start" => { "type" => STRING, "description" => "The cache start mode, which can be EAGER (immediate start) or LAZY (on-demand start).", "expressions-allowed" => false, "required" => false, "nillable" => true, "min-length" => 1L, "max-length" => 2147483647L }, "batching" => { "type" => BOOLEAN, "description" => "If enabled, the invocation batching API will be made available for this cache.", "expressions-allowed" => false, "required" => false, "nillable" => true }, "indexing" => { "type" => STRING, "description" => "If enabled, entries will be indexed when they are added to the cache. Indexes will be updated as entries change or are removed.", "expressions-allowed" => false, "required" => false, "nillable" => true, "min-length" => 1L, "max-length" => 2147483647L }, "mode" => { "type" => STRING, "description" => "Sets the clustered cache mode, ASYNC for asynchronous operation, or SYNC for synchronous operation.", "expressions-allowed" => false, "required" => true, "nillable" => false, "allowed" => [ "SYNC", "ASYNC" ] }, "queue-size" => { "type" => INT, "description" => "In ASYNC mode, this attribute can be used to trigger flushing of the queue when it reaches a specific threshold.", "expressions-allowed" => false, "required" => false, "nillable" => true }, "queue-flush-interval" => { "type" => LONG, "description" => "In ASYNC mode, this attribute controls how often the asynchronous thread used to flush the replication queue runs. This should be a positive integer which represents thread wakeup time in milliseconds.", "expressions-allowed" => false, "required" => false, "nillable" => true, "unit" => "MILLISECONDS" }, "remote-timeout" => { "type" => LONG, "description" => "In SYNC mode, the timeout (in ms) used to wait for an acknowledgment when making a remote call, after which the call is aborted and an exception is thrown.", "expressions-allowed" => false, "required" => false, "nillable" => true, "unit" => "MILLISECONDS" }, "owners" => { "type" => INT, "description" => "Number of cluster-wide replicas for each cache entry.", "expressions-allowed" => false, "required" => false, "nillable" => true }, "virtual-nodes" => { "type" => INT, "description" => "Controls the number of virtual nodes per \"real\" node. If numVirtualNodes is 1, then virtual nodes are disabled. The topology aware consistent hash must be used if you wish to take advantage of virtual nodes. A default of 1 is used.", "expressions-allowed" => false, "required" => false, "nillable" => true }, "l1-lifespan" => { "type" => LONG, "description" => "Maximum lifespan of an entry placed in the L1 cache. This element configures the L1 cache behavior in 'distributed' caches instances. In any other cache modes, this element is ignored.", "expressions-allowed" => false, "required" => false, "nillable" => true, "unit" => "MILLISECONDS" }, "state-transfer" => { "type" => OBJECT, "description" => "The state transfer configuration for distribution and replicated caches.", "expressions-allowed" => false, "required" => false, "nillable" => true, "allowed" => [ "enabled", "timeout", "chunk-size" ], "value-type" => { "enabled" => { "type" => BOOLEAN, "description" => "If enabled, this will cause the cache to ask neighboring caches for state when it starts up, so the cache starts 'warm', although it will impact startup time.", "expressions-allowed" => false, "nillable" => true, "default" => false }, "timeout" => { "type" => LONG, "description" => "The maximum amount of time (ms) to wait for state from neighboring caches, before throwing an exception and aborting startup.", "expressions-allowed" => false, "nillable" => true, "default" => 0L, "unit" => "MILLISECONDS" }, "chunk-size" => { "type" => INT, "description" => "The size, in bytes, in which to batch the transfer of cache entries.", "expressions-allowed" => false, "nillable" => true, "default" => 0 } } } }, "read-only" => false } } {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-3478?page=com.atlassian.jira.plugin.s... ] Richard Achmatowicz commented on AS7-3478: ------------------------------------------ I revisited this solution and corrected the following: - eliminated definition of two keys (involving CACHE_MODE and MODE and the ShareableNameAttributeDefinition) and more simply moved the MODE definition for cache mode to a separate file so that I could avoid the scoping conflict and retain use of the two instances of MODE. Now, CommonAttributes.MODE holds the transaction mode definition, and ClusteredCacheAdd.MODE holds the cache mode definition, and the use of CACHE_MODE is eliminated. - used EnumValidator for all enums in the Infinispan subsystem, which include: StartMode (EAGER, LAZY) IsolationLevel (REPEATABLE_READ, ...) TransactionMode (NONE, NON_XA, NON_DURABLE,...) EvictionStrategy (NONE, UNORDERDED, FIFO, ...) Indexing (NONE, LOCAL, ALL) Mode (ASYNC, SYNC) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira