[
https://issues.apache.org/jira/browse/HDFS-1758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tanping Wang updated HDFS-1758:
-------------------------------
Affects Version/s: (was: 0.20.203.1)
0.20.204
Fix Version/s: (was: 0.20.4)
0.20.204
> 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.204
> Environment: branch-20-security
> Reporter: Tanping Wang
> Assignee: Tanping Wang
> Priority: Minor
> Fix For: 0.20.204
>
> 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
