[ 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