[
https://issues.apache.org/jira/browse/HBASE-18829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16168505#comment-16168505
]
Josh Elser commented on HBASE-18829:
------------------------------------
bq. If Phoenix has solution in place dealing with the
NotServingRegionException, it would be safer to revert.
It seems like this would be the better long-term solution to make (we're not
under the gun right now). Admittedly, I haven't traced through the HRegion code
to appreciate the concurrency.
Unless I've missed it, there's no other reason that HBASE-14893 was done than
letting the Phoenix code work without a more substantial change downstream. In
that case, I think the revert makes sense and we can do a "non-lazy" fix in
Phoenix land. I think this is what Lars is saying too. This means we'd improve
this dodgy code via PHOENIX-3177? Or just PHOENIX-4214?
What's your take, [~rajeshbabu]?
> Consider reverting HBASE-14893 Race between mutation on region and region
> closing operation
> -------------------------------------------------------------------------------------------
>
> Key: HBASE-18829
> URL: https://issues.apache.org/jira/browse/HBASE-18829
> Project: HBase
> Issue Type: Bug
> Reporter: Ted Yu
> Assignee: Ted Yu
> Attachments: 18829.v1.txt
>
>
> HBASE-14893 was brought to attention by [~rajeshbabu] over PHOENIX-3111.
> This issue is to consider reverting the fix from HBASE-14893 based on the
> following observations:
> * The closing boolean was intended to be acquired before taking the lock
> ([~enis])
> * Phoenix local index has evolved over the years, the situation leading to
> NotServingRegionException may not exist from Phoenix side
> * Even if the situation still exists, downstream project (Phoenix) should
> properly handle NotServingRegionException without change in locking scheme in
> hbase
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
