Search code examples
nolio

Nolio NES Threads


Is it expected behavior to have multiple "Discovery Worker" and "Keep Alive" Threads in WAITING state on the NES?

"DiscoveryWorker-10"
Id=62 WAITING on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@3c7f9371
    at sun.misc.Unsafe.park(Native Method)
    -  waiting on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@3c7f9371
    at java.util.concurrent.locks.LockSupport.park(Unknown Source)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(Unknown Source)
    at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(Unknown Source)
    at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor.getTask(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)

"KeepAliveWorker-4"
Id=61 WAITING on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@5ba8febe
    at sun.misc.Unsafe.park(Native Method)
    -  waiting on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@5ba8febe
    at java.util.concurrent.locks.LockSupport.park(Unknown Source)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(Unknown Source)
    at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(Unknown Source)
    at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor.getTask(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)

Solution

  • Yes, this is expected. It looks like these threads are waiting in the thread pool until they will be needed for a discovery or a keep-alive task.

    Threads waiting for long time in NiMi or Netty code (should be visible in the stack-trace), might imply that there is some kind of communication problem. (e.g. NimiConnectionImpl is one of the classes where DiscoveryWorker threads wait while writing to the Netty channel)