The duration amount must be a positive value

[LeonardoSoaresDev]

Describe the bug
The performetrics is throwing an "IllegalArgumentException: The duration amount must be a positive value"

This only happen while trying to get the SYSTEM.TIME

To Reproduce
The only way is trying to run the library in a high-performance machine like used in production.

Expected behavior
Do not throw the exception in a high-performance machine.

Log
java.lang.IllegalArgumentException: The duration amount must be a positive value
at net.obvj.performetrics.util.Duration.of(Duration.java:133) ~[performetrics-2.5.1.jar:?]
at net.obvj.performetrics.util.Duration.of(Duration.java:104) ~[performetrics-2.5.1.jar:?]
at net.obvj.performetrics.Counter.elapsedTime(Counter.java:291) ~[performetrics-2.5.1.jar:?]
at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197) ~[?:?]
at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197) ~[?:?]
at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625) ~[?:?]
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509) ~[?:?]
at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499) ~[?:?]
at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:921) ~[?:?]
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) ~[?:?]
at java.util.stream.ReferencePipeline.reduce(ReferencePipeline.java:657) ~[?:?]
at net.obvj.performetrics.TimingSessionContainer.elapsedTime(TimingSessionContainer.java:231) ~[performetrics-2.5.1.jar:?]

Desktop:

• OS: Unix

Additional context
This error seems to occur on high-performance machines only.
The library was used also in a Windows 10 distribution, and we did not find any problem.
This only happend in a unix high-performance machine.

[oswaldobapvicjr]

Thank you for the issue.

I could reproduce the trouble creating a MonitoredRunnable that executes a simple and fast runnable 1 million times (the average duration for the SYSTEM_TIME counter was 0.000002312 seconds).

During the analysis, I realized that, in some (frequent) cases, the nanoseconds after the operation were populated with an amount that was lower than the value retrieved before the operation, due to a known accuracy issue inside JDK's ThreadMXBean.

According to the JDK 17 Javadoc: "The CPU time provided is of nanoseconds precision but not necessarily nanoseconds accuracy" (https://docs.oracle.com/en/java/javase/17/docs/api/java.management/java/lang/management/ThreadMXBean.html).

So, to avoid the negative elapsed time, I implemented the following fixes:

• The Counter.elapsedTimeNanos() was modified to return zero (instead of -1) when the time retrieved after the operation is lower than the one retrieved before the operation
• The Duration class now also allows negative amounts, to prevent the issue from happening in another situation (for example, if CPU time is not supported by the JVM)

The fix was validated with JUnit and a new stress test method at the PerformetricsTestDrive class.

✅ The fix will be released in Performetrics version 2.5.2.