[jira] [Updated] (OAK-9634) CacheLIRS: test failure with ARM processor

["Thomas Mueller (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/OAK-9634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Mueller updated OAK-9634:
--------------------------------
    Fix Version/s: 1.22.11

> CacheLIRS: test failure with ARM processor
> ------------------------------------------
>
>                 Key: OAK-9634
>                 URL: https://issues.apache.org/jira/browse/OAK-9634
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>            Reporter: Thomas Mueller
>            Assignee: Thomas Mueller
>            Priority: Major
>              Labels: arm
>             Fix For: 1.42.0, 1.22.11
>
>
> In a ARM machine (MacBook with M1 chip) I get a "somewhat" reproducible failure as follows:
> {noformat}
> [ERROR] Tests run: 3, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 2.304 s <<< FAILURE! - in org.apache.jackrabbit.oak.cache.ConcurrentTest
> [ERROR] testRandomOperations(org.apache.jackrabbit.oak.cache.ConcurrentTest)  Time elapsed: 1.068 s  <<< ERROR!
> java.lang.NullPointerException
> 	at org.apache.jackrabbit.oak.cache.CacheLIRS$Segment.find(CacheLIRS.java:1323)
> 	at org.apache.jackrabbit.oak.cache.CacheLIRS.peek(CacheLIRS.java:263)
> 	at org.apache.jackrabbit.oak.cache.CacheLIRS.entrySet(CacheLIRS.java:545)
> 	at org.apache.jackrabbit.oak.cache.CacheLIRS$1.entrySet(CacheLIRS.java:1731)
> 	at org.apache.jackrabbit.oak.cache.ConcurrentTest$3.run(ConcurrentTest.java:210)
> {noformat}
> If I slightly change the code (e.g. add try-catch in the find method), then it no longer fails. I think the problem is the different memory model of ARM chips, and so e.key is assigned a bit after the entry is added to the array.
> Making the key final resolved the issue for me.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)