hadoop-hdfs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran (JIRA)" <j...@apache.org>
Subject [jira] Created: (HDFS-973) DataNode.setDataNode() considered dangerous
Date Fri, 12 Feb 2010 18:04:28 GMT
DataNode.setDataNode() considered dangerous
-------------------------------------------

                 Key: HDFS-973
                 URL: https://issues.apache.org/jira/browse/HDFS-973
             Project: Hadoop HDFS
          Issue Type: Bug
          Components: data-node
    Affects Versions: 0.22.0
            Reporter: Steve Loughran
            Priority: Minor


I don't have any plans to address this, but it seems to me that having the DataNode save a
reference to itself in its constructor by way of {{DataNode.setDataNode(this)}} is hazardous.


# The reference could be used before the constructor has finished, especially when subclasses
are involved
# Callers may assume the DN is actually live
# If startup fails, the DN tries to shut down, but the reference hangs around. Dangerous as
well as leaking a reference
# The reference gets retained forever
# It's a singleton that will get confused if >1 DN gets instantiated in-VM

The likely way these problems will surface are in race conditions that are more likely the
more cores you have on the machine -production rather than development. This is why it is
dangerous.

As part of the service lifecycle patch, I could have this reference only set when the service
gets started, set it to null when stopped (and the reference==this). But really the singleton
should be removed altogether, somehow. There are methods in DataNode, DataStorage, FSDataset
and the namenode that do this, and they should somehow get a reference to any in-VM DN in
a cleaner way. For example, servlets can have it set as servlet context.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message