Почему Micrometer не прекращает отправку данных в datadog и просто закрывается? - PullRequest
0 голосов
/ 03 мая 2018

У меня есть приложение Spring Boot, которое из-за странных ограничений должно запускаться раз в три часа и не будет работать с Quartz, поэтому я запускал его раз в три часа из операционной системы cron, и оно завершало работу, когда это было сделано , Однако после добавления micrometer-registry-datadog (и spring-legacy) он никогда не завершает свою работу, он просто отправляет метрики каждые 20 секунд или любой период по умолчанию, даже после вызова registry.close ().

Обречен ли я, как голландец, вечно плыть по морям обработки, или я допустил явную ошибку?

Код: он достигает SpringApplication.exit (ctx), но фактически не завершается корректно. (служба является TimedExecutorService.)

        public void close() throws InterruptedException {
            service.shutdown();
            service.awaitTermination(Long.MAX_VALUE, TimeUnit.NANOSECONDS);
            meterRegistry.close();
            SpringApplication.exit(ctx);
    }

1 Ответ

0 голосов
/ 03 мая 2018

Это звучит как ошибка. Возможно, экспортер Datadog работает в потоке, не являющемся демоном. JVM рассматривает потоки, не являющиеся демонами, как критически важную работу приложения.

Так что, по сути, JVM считает, что не должна завершать работу, пока не завершится поток, не являющийся демоном. В случае потока экспорта Datadog этого, вероятно, не произойдет.

Чтобы убедиться, что потоки не являются демонами, используйте jstack для создания дампа потока. (команда: jstack <pid>) или сбросьте все потоки в вашем методе close:

ThreadMXBean threadMxBean = ManagementFactory.getThreadMXBean();
for (ThreadInfo ti : threadMxBean.dumpAllThreads(true, true)) {
  System.out.print(ti.toString());
}

Пример вывода дампа потока приведен ниже. Обратите внимание на слово «демон» в первой строке:

"pool-1-thread-1" #13 prio=5 os_prio=31 tid=0x00007fe885aa5000 nid=0xa907 waiting on condition [0x000070000d67b000]
   java.lang.Thread.State: WAITING (parking)
    at sun.misc.Unsafe.park(Native Method)
    - parking to wait for  <0x00000006c07e9720> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
    at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1081)
    at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
    at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
    at java.lang.Thread.run(Thread.java:748)
...