ctubbsii opened a new issue, #5809:
URL: https://github.com/apache/accumulo/issues/5809
**Test name(s)**
- IdleRatioScanPrioritizerTest.testSort
**Describe the failure observed**
```
org.opentest4j.AssertionFailedError: expected: <e> but was: <d>
at
org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
at
org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
at
org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
at
org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182)
at
org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:177)
at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1145)
at
org.apache.accumulo.core.spi.scan.IdleRatioScanPrioritizerTest.testSort(IdleRatioScanPrioritizerTest.java:72)
at java.base/java.lang.reflect.Method.invoke(Method.java:569)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
```
**Testing Environment:**
- Version of this project: 2.1.4-rc2
- First commit known to fail (or current commit):
bc1fe477999d4f19a8591fdb8984502f9305072d
- OS: Fedora 42
- Java: temurin-17-jdk-17.0.16.0.0.8-0.x86_64
- Maven: 3.9.9
- Other environment details: Observed in Jenkins; reproduced in Eclipse on
a loop
**What have you tried already?**
I saw the failure in a local Jenkins build, and tried to reproduce in
Eclipse. I couldn't reproduce it when running the testSort method a single
time. I then created a second test method and disabled the testSort method, so
I could run it many times in a loop to see when it failed, as in:
```java
@Test
public void runALot() {
for (int i = 0; i < 2000; i++) {
try {
testSort();
} catch (Throwable e) {
System.out.println(i);
throw e;
}
}
}
```
In my environment, it always fails on the second iteration (i=1), but in
Eclipse, the error message was:
`expected: <f> but was: <d>` (expecting `f`; in Jenkins, it was expecting
`e`; in both, `d` was the actual value seen). I did get it to fail on the first
iteration once in Eclipse, still expecting `f`, but seeing `d` instead, but
getting it to fail on a single iteration is hard to reproduce. It's easier to
reproduce by running it in a loop. It might have something to do with Java
HotSpot optimizations and `System.currentTimeMillis()` being an intrinsic
candidate for HotSpot.
I then replaced `long now = System.currentTimeMillis()` with a fixed value:
`long now = 100`, and the test always passes.
If I replace it with a value close to the current time (approximately
`System.currentTimeMillis() - 5 < now < System.currentTimeMillis + 15`), the
test fails consistently. It seems that the idleRatio calculation is not
reliable for small values. The IdleRatioScanPrioritizer does rely on
`System.currentTimeMillis`.
**Additional context**
This seems like poor handling of an edge case in IdleRatioScanPrioritizer.
Other prioritizer tests do not seem to have this same issue. Perhaps it has
something to do with Double precision on small values?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@accumulo.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
