Github user franz1981 commented on the issue:
https://github.com/apache/activemq-artemis/pull/2481
Nice investigation! Anyway, CLOCK_MONOTONIC is not subject to NTP backward
adjustment, but just incremental ones ie clock acceleration of any kind, but
this would happen mostly for syst
Github user franz1981 commented on the issue:
https://github.com/apache/activemq-artemis/pull/2481
Ah, another consideration: nanoTime can actually go backward due to
"starting in an unspecified point of time", but usually this need to be handled
by not comparing directly values and j
Github user franz1981 commented on the issue:
https://github.com/apache/activemq-artemis/pull/2482
Nice catch!!!
If you care about checking perf of paging please try to profile the broker
with https://github.com/jvm-profiling-tools/async-profiler using lock/cpu
events too: it will
Github user wy96f commented on the issue:
https://github.com/apache/activemq-artemis/pull/2481
@franz1981 thanks for the explanation. We have verified nanoTime is
correctly supported. We observed the queue delivered messages and received no
messages for abount 2mins, then broker is ki
Github user franz1981 commented on the issue:
https://github.com/apache/activemq-artemis/pull/2481
I will be able to look into that in the next days :)
I can already ask you to collect time to safepoints/GC pauses if possible
ie -XX:+PrintGCApplicationStoppedTime.
2 minutes se
