Heiko Braun <ike.braun> updated the status of jira HAL-776 to Resolved

I verified this bug for jboss-eap-6.4.4.CP.CR3-patch.

For EAP 6.4.4.CP.CR3 this seems to be just partially fixed. 
For standalone mode using web console go to Configuration > Infinispan > Invalidation caches > Details > Attrs > click Edit > select Batching > click Save. 
See attached screenshot with unexpected validation errors.

Created attachment 1078299 [details]
Screenshot of unexpected validation errors in infinispan configuration for EAP 6.4.4.Cp.CR3

Ryan Emerson <remerson> updated the status of jira HAL-776 to Reopened

Ryan Emerson <remerson> updated the status of jira HAL-776 to Coding In Progress

Ryan Emerson <remerson> updated the status of jira HAL-776 to Resolved

For EAP 6.4.5.CP.CR1 this is almost fixed. Still for most of Infinispan subsystem children there is the Eviction subtab with needless numeric validation of Max Entries input which prevent to change other Eviction tab fields as well.

Hi Pavel.  I believe that this behaviour is indeed correct.  The default max-entries value is -1, however if this value is set and eviction is enabled, upon startup EAP will throw the error listed below. Therefore, in this case I do not believe it makes sense to revert to the default value when eviction is enabled.  Also, it is still possible to disable eviction without having a max-entries value in place.  

09:30:12,536 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 31) JBAS014612: Operation ("add") failed - address: ([
    ("subsystem" => "infinispan"),
    ("cache-container" => "hibernate"),
    ("local-cache" => "entity")
]): org.infinispan.config.ConfigurationException: Eviction maxEntries value cannot be less than or equal to zero if eviction is enabled
	at org.infinispan.configuration.cache.EvictionConfigurationBuilder.validate(EvictionConfigurationBuilder.java:84)
	at org.infinispan.configuration.cache.ConfigurationBuilder.validate(ConfigurationBuilder.java:187)
	at org.infinispan.configuration.cache.ConfigurationBuilder.build(ConfigurationBuilder.java:203)
	at org.infinispan.configuration.cache.ConfigurationBuilder.build(ConfigurationBuilder.java:198)
	at org.jboss.as.clustering.infinispan.subsystem.CacheAdd.installRuntimeServices(CacheAdd.java:217)
	at org.jboss.as.clustering.infinispan.subsystem.CacheAdd.performRuntime(CacheAdd.java:186)
	at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:75) [jboss-as-controller-7.5.5.Final-redhat-SNAPSHOT.jar:7.5.5.Final-redhat-SNAPSHOT]
	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:702) [jboss-as-controller-7.5.5.Final-redhat-SNAPSHOT.jar:7.5.5.Final-redhat-SNAPSHOT]
	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:537) [jboss-as-controller-7.5.5.Final-redhat-SNAPSHOT.jar:7.5.5.Final-redhat-SNAPSHOT]
	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:338) [jboss-as-controller-7.5.5.Final-redhat-SNAPSHOT.jar:7.5.5.Final-redhat-SNAPSHOT]
	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:314) [jboss-as-controller-7.5.5.Final-redhat-SNAPSHOT.jar:7.5.5.Final-redhat-SNAPSHOT]
	at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:355) [jboss-as-controller-7.5.5.Final-redhat-SNAPSHOT.jar:7.5.5.Final-redhat-SNAPSHOT]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_45]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_45]
	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_45]
	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
09:30:12,577 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) "JBAS014784: Failed executing subsystem infinispan boot operations"
09:30:12,578 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014612: Operation ("parallel-subsystem-boot") failed - address: ([]) - failure description: "\"JBAS014784: Failed executing subsystem infinispan boot operations\""

Hi Ryan, 
I see your point - default -1 max-entries means no eviction, but still the default value is valid for strategy NONE and neither no value nor -1 can be entered to the Max Entries field even if it is valid combination.

The default value is only valid for 1/5 combinations, so it really does not make sense for this field to be set as the default (-1) for all eviction types, especially as the user will be unaware of the consequences of this change until EAP has been restarted.  It is possible for max-entries to be set to 0, which is the equivalent of setting it to -1 when the Strategy is NONE, so a valid NONE configuration is possible at the moment[1].  

In terms of removing the need for a value to be entered, I believe there are two courses of action possible (other than keeping the current behaviour):

1) change the default value associated with Eviction. In my opinion this is a none starter as it is a change in EAP behaviour.  

2) Hardcode default max-entries values into HAL for eviction strategies that aren't NONE (e.g. 10000).  I believe this is better than 1, however you then have the issue of determining a sensible default value and introducing undocumented behaviour. 




[1] If NONE is configured with a max-entries value > 0, then the eviction type is set to LIRS by Infinispan behind the scenes with only a debug message to inform the user.

3) We keep the behaviour as is.  When NONE is selected, the user can enter 0 instead of -1.  Or they can just not enable eviction in the first place (same result).

Note, that solution 2 proposed above should also resolve [1] as the max-entries field will have to be changed to allow negative values, therefore -1 (the EAP default) will be displayed instead of zero.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1278778

Marking as verified. Remaining work will be tracked in BZ 1278778.

Retroactively bulk-closing issues from released EAP 6.4 cumulative patches.

Retroactively bulk-closing issues from released EAP 6.4 cumulative patches.