Bug 1007015

Summary: jboss-as-infinispan_1_X.xsd schema and domain model has incorrect default value for flush-lock-timeout in write-behind
Product: [JBoss] JBoss Enterprise Application Platform 6 Reporter: Brent Driskill <bdriskil>
Component: ClusteringAssignee: Radoslav Husar <rhusar>
Status: CLOSED CURRENTRELEASE QA Contact: Jitka Kozana <jkudrnac>
Severity: medium Docs Contact:
Priority: low    
Version: 6.0.1CC: brian.stansberry, david, jason.greene, kkhan, lthon, myarboro, rhusar, rsvoboda, wbirkhea
Target Milestone: ER6   
Target Release: EAP 6.4.0   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Brent Driskill 2013-09-11 18:00:48 UTC
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:

Comment 1 Fernando Nasser 2013-09-11 18:06:39 UTC
Jason, which component should this be filed under?

Comment 3 Radoslav Husar 2014-05-21 13:36:06 UTC
Let me investigate this.

Comment 5 Radoslav Husar 2014-06-03 10:02:41 UTC
Upstream: https://issues.jboss.org/browse/WFLY-3435

Comment 6 Rostislav Svoboda 2014-06-03 14:00:50 UTC
>>>> 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.

Comment 9 Ladislav Thon 2014-11-26 08:39:02 UTC
Verified with EAP 6.4.0.DR11.

(Note: I went through the logs and this was merged to EAP 6.4.0 in DR6.)