Like @Rajkumar Singh mentioned above, the application state (like life cycle related events) get persistent in RM with RMStateStore. For ApplicationMaster (AM), there is no central place for AM to persistent its own internal state but it is flexible for AM to pickup places to store temporary results/progress so AM failed/restart won't have to lose all progress that last AM attempt gains. Take MapReduce for example, when configured properly, MR AM after restart will read finished map/reduce tasks from job history files on HDFS, so finished map/reduce tasks won't get re-executed after AM restart. Other application could have similar behavior in case it want to persist something. ... View more

Hi Arun, you can configure RM HA so 2nd RM (we called it standby RM) will automatically take effective when 1st RM (active RM) get down due to hardware/software issues. For how to deploy it, please refer: https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.4.2/bk_hadoop-ha/content/ha-rm-deploy-ra-cluster.html . For MapReduce JHS (Job HistoryServer), because all write path are in application AM (write to HDFS directly) and JHS only play as reader. Anytime you found it is down, just bring it back should be ok. ATS (application timeline server) is a bit complicated. while v1 based on levelDB (a local k-v store) and v1.5 based on it (with adding a HDFS cache layer) which still have problem of SPOF (Single Point of Failure). ATS v2 is still in development which has distributed write path and use HBase as backend store that can totally get rid of SPOF issues. I would suggest to keep using ATS v1.5 and upgrade to v2 in future when it get ready. ... View more

ShuffleHandler is part of NM auxiliary service so it will use NM daemon's memory rather than container's. So increase container's heap size may not be helpful for your case. You should increase NM's daemon size instead as suggested by @Neeraj Sabharwal. @Hajime ... View more