hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Allen Wittenauer (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-1758) Web UI JSP pages thread safety issue
Date Thu, 24 Mar 2011 19:50:05 GMT

    [ https://issues.apache.org/jira/browse/HDFS-1758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13010877#comment-13010877
] 

Allen Wittenauer commented on HDFS-1758:
----------------------------------------

I'm confused by this commit. 

It looks like it was committed to branch-0.20-security but 0.20.203.1 is listed as the environment.
 Was this actually supposed to get committed to branch-0.20-security-203 or both or what?

> Web UI JSP pages thread safety issue
> ------------------------------------
>
>                 Key: HDFS-1758
>                 URL: https://issues.apache.org/jira/browse/HDFS-1758
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: tools
>    Affects Versions: 0.20.203.1
>         Environment: branch-20-security
>            Reporter: Tanping Wang
>            Assignee: Tanping Wang
>            Priority: Minor
>             Fix For: 0.20.4
>
>         Attachments: HDFS-1758.patch
>
>
> The set of JSP pages that web UI uses are not thread safe.  We have observed some problems
when requesting Live/Dead/Decommissioning pages from the web UI, incorrect page is displayed.
 To be more specific, requesting Dead node list page, sometimes, Live node page is returned.
 Requesting decommissioning page, sometimes, dead page is returned.
> The root cause of this problem is that JSP page is not thread safe by default.  When
multiple requests come in,  each request is assigned to a different thread, multiple threads
access the same instance of the servlet class resulted from a JSP page.  A class variable
is shared by multiple threads.  The JSP code in 20 branche, for example, dfsnodelist.jsp has
> {code}
> <!%
>   int rowNum = 0;
>   int colNum = 0;
>   String sorterField = null;
>   String sorterOrder = null;
>   String whatNodes = "LIVE";
>   ...
> %>
> {code}
> declared as  class variables.  ( These set of variables are declared within <%! code
%> directives which made them class members. )  Multiple threads share the same set of
class member variables, one request would step on anther's toe. 
> However, due to the JSP code refactor, HADOOP-5857, all of these class member variables
are moved to become function local variables.  So this bug does not appear in Apache trunk.
 Hence, we have proposed to take a simple fix for this bug on 20 branch alone, to be more
specific, branch-0.20-security.
> The simple fix is to add jsp ThreadSafe="false" directive into the related JSP pages,
dfshealth.jsp and dfsnodelist.jsp to make them thread safe, i.e. only on request is processed
at each time. 
> We did evaluate the thread safety issue for other JSP pages on trunk, we noticed a potential
problem is that when we retrieving some statistics from namenode, for example, we make the
call to 
> {code}
> NamenodeJspHelper.getInodeLimitText(fsn);
> {code}
> in dfshealth.jsp, which eventuality is 
> {code}
>   static String getInodeLimitText(FSNamesystem fsn) {
>     long inodes = fsn.dir.totalInodes();
>     long blocks = fsn.getBlocksTotal();
>     long maxobjects = fsn.getMaxObjects();
>     ....
> {code}
> some of the function calls are already guarded by readwritelock, e.g. dir.totalInodes,
but others are not.  As a result of this, the web ui results are not 100% thread safe.  But
after evaluating the prons and cons of adding a giant lock into the JSP pages, we decided
not to issue FSNamesystem ReadWrite locks into JSPs.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message