hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lars Hofhansl (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (HBASE-14465) Backport 'Allow rowlock to be reader/write' to branch-1
Date Fri, 28 Oct 2016 23:27:58 GMT

    [ https://issues.apache.org/jira/browse/HBASE-14465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15616925#comment-15616925
] 

Lars Hofhansl edited comment on HBASE-14465 at 10/28/16 11:27 PM:
------------------------------------------------------------------

> This was a coprocessor accessible API that was expressly annotated as can-change in a
minor version (according to our compat guide). If you're going to object to that, we're going
to have a long road ahead of us getting 1.3 or 2.0 to a place where we can agree to releasing.

I was objecting to coopting the same API and changing the meaning of a boolean to mean totally
different things. You call the same API and before you'd be waiting for the writelock and
now you're getting a readlock. I cant think of many API changes that can lead to more subtle
bugs. (such as in Phoenix now where changes to the SYSTEM.CATALOG are now suddenly lock and
concurrent updates can lead to corruption).

Regardless of any policy and whether it's allowed or not, it's just bad taste.

In any case :)
Let's look forward. I think we clearly all agree that (1) APIs marked such as this _may_ be
changed, and (2) that this particular change would have been better served with a new method.



was (Author: lhofhansl):
> This was a coprocessor accessible API that was expressly annotated as can-change in a
minor version (according to our compat guide). If you're going to object to that, we're going
to have a long road ahead of us getting 1.3 or 2.0 to a place where we can agree to releasing.

I was objecting to coopting the same API and changing the meaning of a boolean to mean totally
different things. You call the same API and before you'd be waiting for the writelock and
now you're getting a readlock. I cant think of many API that can lead to more subtle bugs.
(such as in Phoenix now where changes to the SYSTEM.CATALOG are now suddenly lock and concurrent
updates can lead to corruption).

Regardless of any policy and whether it's allowed or not, it's just bad taste.

In any case :)
Let's look forward. I think we clearly all agree that (1) APIs marked such as this _may_ be
changed, and (2) that this particular change would have been better served with a new method.


> Backport 'Allow rowlock to be reader/write' to branch-1
> -------------------------------------------------------
>
>                 Key: HBASE-14465
>                 URL: https://issues.apache.org/jira/browse/HBASE-14465
>             Project: HBase
>          Issue Type: Sub-task
>          Components: regionserver
>            Reporter: stack
>            Assignee: stack
>             Fix For: 1.2.0, 1.3.0
>
>         Attachments: 14465.branch-1.txt, 14465.branch-1.v2.txt, 14465.branch-1.v2.txt,
14465.branch-1.v2.txt, 14465.branch-1.v3.txt, 14465.branch-1.v3.txt, 14465.branch-1.v4.txt,
14465.branch-1.v4.txt, 14465.branch-1.v4.txt, 14465.branch-1.v5.txt, 14465.branch-1.v5.txt,
14465.branch-1.v9.txt, 14465.branch-1.v9.txt, 14465.branch-1.v9.txt, 14465.txt
>
>
> Backport to branch-1.
> You want this in 1.2 [~busbey]? Its cleanup and fixes a possible dataloss. On other hand,
its a bit of refactoring.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message