Uploaded image for project: 'Hadoop HDFS'
  1. Hadoop HDFS
  2. HDFS-15069

DecommissionMonitor-0 thread will block forever while its timer task scheduled encountered any unchecked exceptions.

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Resolved
    • Major
    • Resolution: Duplicate
    • 3.1.3
    • None
    • namenode
    • None

    Description

      More than once, we have observed that during decommissioning of a large number of DNs, the thread DecommissionMonitor-0 will stop scheduling, blocking for a long time, and there will be no exception logs or notifications at all.

      e.g. Recently, we are decommissioning 65 DNs at the same time, each DN about 10TB, and the DecommissionMonitor-0 thread blocked for about 15 days.

      The stack of DecommissionMonitor-0 looks like this:

      1. stack on 2019.12.17 16:12
      2. stack on 2019.12.17 16:42

      It can be seen that during half an hour, this thread has not been scheduled at all, its Waited count has not changed.

      We think the cause of the problem is:

      1. The DecommissionMonitor task submitted by NameNode encounters an unchecked exception during its running , and then this task will be never executed again.
      2. But NameNode does not care about the ScheduledFuture of this task, and never calls ScheduledFuture.get(), so the unchecked exception thrown by the task above will always be placed there, no one knows.

      After that, the subsequent phenomenon is:

      1. The ScheduledExecutorService thread DecommissionMonitor-0 will block forever in ThreadPoolExecutor.getTask().
      2. The previously submitted task DecommissionMonitor will be never executed again.
      3. No logs or notifications can let us know exactly what had happened.

      Possible solutions:

      1. Do not use thread pool to execute decommission monitor task, alternatively we can introduce a separate thread to do this, just like HeartbeatManager, ReplicationMonitor, LeaseManager, BlockReportThread, and so on.

             OR

             2. Catch all exceptions in decommission monitor task's run() method, so it does not throw any exceptions.

      I prefer the second option.

       

      Attachments

        1. stack_on_16_42.png
          19 kB
          Xudong Cao
        2. stack_on_16_12.png
          17 kB
          Xudong Cao

        Issue Links

          Activity

            People

              xudongcao Xudong Cao
              xudongcao Xudong Cao
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: