You are viewing a plain text version of this content. The canonical link for it is here.
Posted to hdfs-dev@hadoop.apache.org by "Ding Yuan (JIRA)" <ji...@apache.org> on 2014/03/23 18:02:43 UTC

[jira] [Created] (HDFS-6145) Stopping unexpected exception from propagating to avoid serious consequences

Ding Yuan created HDFS-6145:
-------------------------------

             Summary: Stopping unexpected exception from propagating to avoid serious consequences
                 Key: HDFS-6145
                 URL: https://issues.apache.org/jira/browse/HDFS-6145
             Project: Hadoop HDFS
          Issue Type: Improvement
    Affects Versions: 2.2.0
            Reporter: Ding Yuan


There are a few cases where an exception should never have occurred, but the code simply logged it and let the execution continue. Since they shouldn't have occurred, a safer way may be to simply terminate the execution and stop them from propagating into some unexpected consequences.

==========================
Case 1:
Line: 336, File: "org/apache/hadoop/hdfs/server/namenode/snapshot/INodeDirectorySnapshottable.java"
{noformat}

325:       try {
326:         Quota.Counts counts = cleanSubtree(snapshot, prior, collectedBlocks,
327:             removedINodes, true);
328:         INodeDirectory parent = getParent();
 .. ..
335:       } catch(QuotaExceededException e) {
336:         LOG.error("BUG: removeSnapshot increases namespace usage.", e);
337:       }
{noformat}

Since this shouldn't have occurred unless some unexpected bugs occur,
should the NN simply stop the execution to prevent bad things from propagation?

Similar handling of QuotaExceededException can be found at:
  Line: 544, File: "org/apache/hadoop/hdfs/server/namenode/INodeReference.java"
  Line: 657, File: "org/apache/hadoop/hdfs/server/namenode/INodeReference.java"
  Line: 669, File: "org/apache/hadoop/hdfs/server/namenode/INodeReference.java"
==========================================
==========================
Case 2:
Line: 601, File: "org/apache/hadoop/hdfs/server/namenode/JournalSet.java"

{noformat}
591:  public synchronized RemoteEditLogManifest getEditLogManifest(long fromTxId,
..
595:    for (JournalAndStream j : journals) {
..
598:         try {
599:           allLogs.addAll(fjm.getRemoteEditLogs(fromTxId, forReading, false));
600:         } catch (Throwable t) {
601:           LOG.warn("Cannot list edit logs in " + fjm, t);
602:         }
{noformat}

An exception from addAll will result in some edit log files not considered, and not included in the checkpoint, which may result in dataloss.
==========================================
==========================
Case 3:
Line: 4029, File: "org/apache/hadoop/hdfs/server/namenode/FSNamesystem.java"

{noformat}
4010:       try {
4011:         while (fsRunning && shouldNNRmRun) {
4012:           checkAvailableResources();
4013:           if(!nameNodeHasResourcesAvailable()) {
4014:             String lowResourcesMsg = "NameNode low on available disk space. ";
4015:             if (!isInSafeMode()) {
4016:               FSNamesystem.LOG.warn(lowResourcesMsg + "Entering safe mode.");
4017:             } else {
4018:               FSNamesystem.LOG.warn(lowResourcesMsg + "Already in safe mode.");
4019:             }
4020:             enterSafeMode(true);
4021:           }
.. ..
4027:         }
4028:       } catch (Exception e) {
4029:         FSNamesystem.LOG.error("Exception in NameNodeResourceMonitor: ", e);
4030:       }
{noformat}

enterSafeMode might thrown exception. In the case of not being able to entering safe mode, should the execution simply terminate?
==========================================




--
This message was sent by Atlassian JIRA
(v6.2#6252)