Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/2481
@wy96f if you could close, only the person opening can close, or when we
merge.
---
Github user wy96f commented on the issue:
https://github.com/apache/activemq-artemis/pull/2481
> interim
Yes. The problem did't occur these days. We'll give more investigation.
---
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/2481
Can we close this for the interim?
---
Github user wy96f commented on the issue:
https://github.com/apache/activemq-artemis/pull/2481
@franz1981 thanks for your advice. We've enabled gc log and run the nano
program. Any news will be reported:)
---
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
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
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
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
Github user wy96f commented on the issue:
https://github.com/apache/activemq-artemis/pull/2481
We add a pending counter to count enterCritical calls. If left time is less
than enter time and pending counter equals to 0, we don't expire component as
all threads have called
Github user wy96f commented on the issue:
https://github.com/apache/activemq-artemis/pull/2481
@michaelandrepearce @franz1981
Here is the code of System::nanoTime from openjdk:
jlong os::javaTimeNanos() {
if (Linux::supports_monotonic_clock()) {
struct timespec
Github user franz1981 commented on the issue:
https://github.com/apache/activemq-artemis/pull/2481
@michaelandrepearce thanks buddy you too!!!
---
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/2481
@franz1981 haha snap. I had same thinking.
---
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/2481
I dont see how this handles clock drift if im honest. The test case doesnt
actually cause a drift in nano.
Also Nanoseconds also are from an arbitary offset on the cpu,
Github user franz1981 commented on the issue:
https://github.com/apache/activemq-artemis/pull/2481
I know that System::nanoTime is based on monothonic clock of the CPU
thast's not wall clock time ie can't go back.
System::currentTimeMillis ie UTC wall-clock can go backwards
14 matches
Mail list logo
