Description of problem: In org.infinispan.loaders.decorators.AsyncStoreConfig, the default flushLockTimeout is set to 5000. However, the default in the JBoss Infinispan schema ($JBOSS_HOME/docs/schema/jboss-as-infinispan_1_X.xsd) is set to 1. Because of this, if the thread-pool-size for write-behind is increased, then it is likely that one of the threads will not be able to obtain the state map lock within the 1 millisecond time provided by the schema default. This results in the following error: ERROR o.i.loaders.decorators.AsyncStore.run - ISPN000051: Unexpected error org.infinispan.CacheException: Unable to acquire lock on update map at org.infinispan.loaders.decorators.AsyncStore.acquireLock(AsyncStore.java:293) ~[infinispan-core-5.1.3.FINAL.jar:5.1.3.FINAL] at org.infinispan.loaders.decorators.AsyncStore.access$900(AsyncStore.java:86) ~[infinispan-core-5.1.3.FINAL.jar:5.1.3.FINAL] at org.infinispan.loaders.decorators.AsyncStore$AsyncProcessor.innerRun(AsyncStore.java:336) ~[infinispan-core-5.1.3.FINAL.jar:5.1.3.FINAL] at org.infinispan.loaders.decorators.AsyncStore$AsyncProcessor.run(AsyncStore.java:312) ~[infinispan-core-5.1.3.FINAL.jar:5.1.3.FINAL] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) ~[na:1.6.0_31] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) ~[na:1.6.0_31] at java.lang.Thread.run(Thread.java:662) ~[na:1.6.0_31] Version-Release number of selected component (if applicable): Infinispan version 5.1.8 How reproducible: Code inspection Steps to Reproduce: 1. Check the default value for flush-lock-timeout in $JBOSS_HOME/docs/schema/jboss-as-infinispan_1_3.xsd 2. Check the default value for flushLockTimeout in the org.infinispan.loaders.decorators.AsyncStoreConfig class 3. Note the disparity Actual results: Default in schema is 1 Expected results: Default in schema is 5000 Additional info:
Jason, which component should this be filed under?
Let me investigate this.
Upstream: https://issues.jboss.org/browse/WFLY-3435
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1007015 PM + QA >>> NOT acked (yet) >>> https://github.com/jbossas/jboss-eap/pull/1401/files modifies >>> already published XSD files >>> I think only jboss-as-infinispan_1_5.xsd should be modified >>> Adding Rado for feedback >> I am a bit unsure about that one. I *think* we normally fix them if >> there are problems, but it would be good to get Brian’s input as well. > > I believe the rule of thumb has always been that if the value was > clearly wrong and nobody could have used the value reliably (in this > case a timeout of 1 ms instead of 5 seconds) and it doesn't break > existing configurations we can change it and IIRC we have done it in the > past. > > Nevertheless I agree it's a mess to change already published XSD, but > that's why we ship them in every release again and again so we can > correct mistakes of the past. > > But Brian is the boss here :-) > This isn't great, but I don't see a better alternative. The change in the AttributeDefinition and the 1.5 xsd are fine. Changing the previous xsds isn't great, but the alternative is to modify the parsers for those versions to set "1" on the operation. And that would result in writing the "1" back to the xml even though the user didn't directly specify that. That's also not great, although it's what we'd normally do if we change a default. But if the "1" value never worked properly anyway I don't see the point of doing that.
Verified with EAP 6.4.0.DR11. (Note: I went through the logs and this was merged to EAP 6.4.0 in DR6.)