[ https://issues.apache.org/jira/browse/HBASE-9095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13729870#comment-13729870 ]
ramkrishna.s.vasudevan commented on HBASE-9095: ----------------------------------------------- Ok to do this in 0.94 also to avoid many of the concurrency issues? Need to see the code to see how much it helps though? What [~jxiang], [~jeffreyz] feel? > AssignmentManager's handleRegion should respect the single threaded nature of > the processing > -------------------------------------------------------------------------------------------- > > Key: HBASE-9095 > URL: https://issues.apache.org/jira/browse/HBASE-9095 > Project: HBase > Issue Type: Bug > Components: Region Assignment > Reporter: Devaraj Das > Assignee: Devaraj Das > Fix For: 0.95.2 > > Attachments: 9095-1 (1).txt, 9095-1.txt, 9095-1.txt, 9095-1.txt, > 9095-2.txt > > > While debugging a case where a region was getting opened on a RegionServer > and then closed soon after (and then never re-opened anywhere thereafter), it > seemed like the processing in handleRegion to do with deletion of ZK nodes > should be non-asynchronous. This achieves two things: > 1. The synchronous deletion prevents more than one processing on the same > event data twice. Assuming that we do get more than one notification (on > let's say, region OPENED event), the subsequent processing(s) in handleRegion > for the same znode would end up with a zookeeper node not found exception. > The return value of the data read would be null and that's already handled. > If it is asynchronous, it leads to issues like - master opens a region on a > certain RegionServer and soon after it sends that RegionServer a close for > the same region, and then the znode is deleted. > 2. The deletion is currently handled in an executor service. This is > problematic since by design the events for a given region should be processed > in order. By delegating a part of the processing to executor service we are > somewhat violating this contract since there is no guarantee of the ordering > in the executor service executions... > Thanks to [~jeffreyz] and [~enis] for the discussions on this issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira