[jira] [Commented] (HBASE-25576) Should not use a byte array as a key of HashMap or an element of HashSet
[
https://issues.apache.org/jira/browse/HBASE-25576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17695134#comment-17695134
]
Toshihiro Suzuki commented on HBASE-25576:
--
[~umesh9414] If the PR for this Jira is going to be bulky, you can split it
into multiple PRs. If you want to work on this, you can assign it to you and go
ahead.
> Should not use a byte array as a key of HashMap or an element of HashSet
>
>
> Key: HBASE-25576
> URL: https://issues.apache.org/jira/browse/HBASE-25576
> Project: HBase
> Issue Type: Bug
>Reporter: Toshihiro Suzuki
>Priority: Major
> Labels: beginner
>
> I sometimes face the code where we use a byte array as a key of HashMap
> (ConcurrentHashMap) or an element of HashSet, which could cause very
> confusing bugs.
> The following code is an example where we use a byte array as a key of
> HashMap:
> https://github.com/apache/hbase/blob/326835e8372cc83092e0ec127650438ff153476a/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/wal/SequenceIdAccounting.java#L94
> In Java, we can't use a byte array as a key of HashMap or an element of
> HashSet directly. One solution for it is to use TreeMap
> (ConcurrentSkipListMap) or TreeSet (ConcurrentSkipListSet) with
> Bytes.BYTES_COMPARATOR instead of HashMap and HashSet as follows:
> {code}
> Map map1 = new TreeMap<>(Bytes.BYTES_COMPARATOR);
> Map map2 = new
> ConcurrentSkipListMap<>(Bytes.BYTES_COMPARATOR);
> Set set1 = new TreeSet<>(Bytes.BYTES_COMPARATOR);
> Set set2 = new ConcurrentSkipListSet<>(Bytes.BYTES_COMPARATOR);
> {code}
> We should fix the existing ones in this Jira.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (HBASE-25576) Should not use a byte array as a key of HashMap or an element of HashSet
[
https://issues.apache.org/jira/browse/HBASE-25576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Toshihiro Suzuki reassigned HBASE-25576:
Assignee: (was: Sourabh Dhanotia)
> Should not use a byte array as a key of HashMap or an element of HashSet
>
>
> Key: HBASE-25576
> URL: https://issues.apache.org/jira/browse/HBASE-25576
> Project: HBase
> Issue Type: Bug
>Reporter: Toshihiro Suzuki
>Priority: Major
> Labels: beginner
>
> I sometimes face the code where we use a byte array as a key of HashMap
> (ConcurrentHashMap) or an element of HashSet, which could cause very
> confusing bugs.
> The following code is an example where we use a byte array as a key of
> HashMap:
> https://github.com/apache/hbase/blob/326835e8372cc83092e0ec127650438ff153476a/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/wal/SequenceIdAccounting.java#L94
> In Java, we can't use a byte array as a key of HashMap or an element of
> HashSet directly. One solution for it is to use TreeMap
> (ConcurrentSkipListMap) or TreeSet (ConcurrentSkipListSet) with
> Bytes.BYTES_COMPARATOR instead of HashMap and HashSet as follows:
> {code}
> Map map1 = new TreeMap<>(Bytes.BYTES_COMPARATOR);
> Map map2 = new
> ConcurrentSkipListMap<>(Bytes.BYTES_COMPARATOR);
> Set set1 = new TreeSet<>(Bytes.BYTES_COMPARATOR);
> Set set2 = new ConcurrentSkipListSet<>(Bytes.BYTES_COMPARATOR);
> {code}
> We should fix the existing ones in this Jira.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (HBASE-26010) Backport HBASE-25703 and HBASE-26002 to branch-2.3
[ https://issues.apache.org/jira/browse/HBASE-26010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toshihiro Suzuki resolved HBASE-26010. -- Resolution: Won't Fix > Backport HBASE-25703 and HBASE-26002 to branch-2.3 > -- > > Key: HBASE-26010 > URL: https://issues.apache.org/jira/browse/HBASE-26010 > Project: HBase > Issue Type: Improvement > Components: backport >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Major > Fix For: 2.3.6 > > > Backport HBASE-25703 "Support conditional update in MultiRowMutationEndpoint" > and HBASE-26002 "MultiRowMutationEndpoint should return the result of the > conditional update" to branch-2.3. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-26010) Backport HBASE-25703 and HBASE-26002 to branch-2.3
[ https://issues.apache.org/jira/browse/HBASE-26010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17367905#comment-17367905 ] Toshihiro Suzuki commented on HBASE-26010: -- As it's not a bug fix, we shouldn't apply it to patch releases. Closing this. > Backport HBASE-25703 and HBASE-26002 to branch-2.3 > -- > > Key: HBASE-26010 > URL: https://issues.apache.org/jira/browse/HBASE-26010 > Project: HBase > Issue Type: Improvement > Components: backport >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Major > Fix For: 2.3.6 > > > Backport HBASE-25703 "Support conditional update in MultiRowMutationEndpoint" > and HBASE-26002 "MultiRowMutationEndpoint should return the result of the > conditional update" to branch-2.3. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (HBASE-26009) Backport HBASE-25766 "Introduce RegionSplitRestriction that restricts the pattern of the split point" to branch-2.3
[ https://issues.apache.org/jira/browse/HBASE-26009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toshihiro Suzuki resolved HBASE-26009. -- Resolution: Won't Fix > Backport HBASE-25766 "Introduce RegionSplitRestriction that restricts the > pattern of the split point" to branch-2.3 > --- > > Key: HBASE-26009 > URL: https://issues.apache.org/jira/browse/HBASE-26009 > Project: HBase > Issue Type: Sub-task >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Major > Fix For: 2.3.6 > > > Backport the parent issue to branch-2.3. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-26009) Backport HBASE-25766 "Introduce RegionSplitRestriction that restricts the pattern of the split point" to branch-2.3
[ https://issues.apache.org/jira/browse/HBASE-26009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17367901#comment-17367901 ] Toshihiro Suzuki commented on HBASE-26009: -- As discussed in https://github.com/apache/hbase/pull/3395, we won't fix this. Closing it. > Backport HBASE-25766 "Introduce RegionSplitRestriction that restricts the > pattern of the split point" to branch-2.3 > --- > > Key: HBASE-26009 > URL: https://issues.apache.org/jira/browse/HBASE-26009 > Project: HBase > Issue Type: Sub-task >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Major > Fix For: 2.3.6 > > > Backport the parent issue to branch-2.3. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-26010) Backport HBASE-25703 and HBASE-26002 to branch-2.3
[ https://issues.apache.org/jira/browse/HBASE-26010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toshihiro Suzuki updated HBASE-26010: - Fix Version/s: 2.3.6 > Backport HBASE-25703 and HBASE-26002 to branch-2.3 > -- > > Key: HBASE-26010 > URL: https://issues.apache.org/jira/browse/HBASE-26010 > Project: HBase > Issue Type: Improvement > Components: backport >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Major > Fix For: 2.3.6 > > > Backport HBASE-25703 "Support conditional update in MultiRowMutationEndpoint" > and HBASE-26002 "MultiRowMutationEndpoint should return the result of the > conditional update" to branch-2.3. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-26009) Backport HBASE-25766 "Introduce RegionSplitRestriction that restricts the pattern of the split point" to branch-2.3
[ https://issues.apache.org/jira/browse/HBASE-26009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toshihiro Suzuki updated HBASE-26009: - Fix Version/s: 2.3.6 > Backport HBASE-25766 "Introduce RegionSplitRestriction that restricts the > pattern of the split point" to branch-2.3 > --- > > Key: HBASE-26009 > URL: https://issues.apache.org/jira/browse/HBASE-26009 > Project: HBase > Issue Type: Sub-task >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Major > Fix For: 2.3.6 > > > Backport the parent issue to branch-2.3. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-26010) Backport HBASE-25703 and HBASE-26002 to branch-2.3
[ https://issues.apache.org/jira/browse/HBASE-26010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toshihiro Suzuki updated HBASE-26010: - Issue Type: Improvement (was: Bug) > Backport HBASE-25703 and HBASE-26002 to branch-2.3 > -- > > Key: HBASE-26010 > URL: https://issues.apache.org/jira/browse/HBASE-26010 > Project: HBase > Issue Type: Improvement > Components: backport >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Major > > Backport HBASE-25703 "Support conditional update in MultiRowMutationEndpoint" > and HBASE-26002 "MultiRowMutationEndpoint should return the result of the > conditional update" to branch-2.3. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (HBASE-26010) Backport HBASE-25703 and HBASE-26002 to branch-2.3
Toshihiro Suzuki created HBASE-26010: Summary: Backport HBASE-25703 and HBASE-26002 to branch-2.3 Key: HBASE-26010 URL: https://issues.apache.org/jira/browse/HBASE-26010 Project: HBase Issue Type: Bug Components: backport Reporter: Toshihiro Suzuki Assignee: Toshihiro Suzuki Backport HBASE-25703 "Support conditional update in MultiRowMutationEndpoint" and HBASE-26002 "MultiRowMutationEndpoint should return the result of the conditional update" to branch-2.3. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (HBASE-26009) Backport HBASE-25766 "Introduce RegionSplitRestriction that restricts the pattern of the split point" to branch-2.3
Toshihiro Suzuki created HBASE-26009: Summary: Backport HBASE-25766 "Introduce RegionSplitRestriction that restricts the pattern of the split point" to branch-2.3 Key: HBASE-26009 URL: https://issues.apache.org/jira/browse/HBASE-26009 Project: HBase Issue Type: Sub-task Reporter: Toshihiro Suzuki Assignee: Toshihiro Suzuki Backport the parent issue to branch-2.3. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-26002) MultiRowMutationEndpoint should return the result of the conditional update
[ https://issues.apache.org/jira/browse/HBASE-26002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17363382#comment-17363382 ] Toshihiro Suzuki commented on HBASE-26002: -- Pushed to branch-2 and branch-2.4. Thank you for reviewing this! [~zhangduo] > MultiRowMutationEndpoint should return the result of the conditional update > --- > > Key: HBASE-26002 > URL: https://issues.apache.org/jira/browse/HBASE-26002 > Project: HBase > Issue Type: Improvement > Components: Coprocessors >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Major > Fix For: 2.5.0, 3.0.0-alpha-2, 2.4.5 > > > HBASE-25703 added support for the conditional update in > MultiRowMutationEndpoint, but MultiRowMutationEndpoint doesn't return the > result of the conditional update (whether or not the mutations are executed). > In this Jira, we will make MultiRowMutationEndpoint return the result of the > conditional update. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (HBASE-26002) MultiRowMutationEndpoint should return the result of the conditional update
[ https://issues.apache.org/jira/browse/HBASE-26002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toshihiro Suzuki resolved HBASE-26002. -- Hadoop Flags: Reviewed Resolution: Fixed > MultiRowMutationEndpoint should return the result of the conditional update > --- > > Key: HBASE-26002 > URL: https://issues.apache.org/jira/browse/HBASE-26002 > Project: HBase > Issue Type: Improvement > Components: Coprocessors >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Major > Fix For: 2.5.0, 3.0.0-alpha-2, 2.4.5 > > > HBASE-25703 added support for the conditional update in > MultiRowMutationEndpoint, but MultiRowMutationEndpoint doesn't return the > result of the conditional update (whether or not the mutations are executed). > In this Jira, we will make MultiRowMutationEndpoint return the result of the > conditional update. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (HBASE-25576) Should not use a byte array as a key of HashMap or an element of HashSet
[
https://issues.apache.org/jira/browse/HBASE-25576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Toshihiro Suzuki reassigned HBASE-25576:
Assignee: (was: Swaroopa Kadam)
> Should not use a byte array as a key of HashMap or an element of HashSet
>
>
> Key: HBASE-25576
> URL: https://issues.apache.org/jira/browse/HBASE-25576
> Project: HBase
> Issue Type: Bug
>Reporter: Toshihiro Suzuki
>Priority: Major
> Labels: beginner
>
> I sometimes face the code where we use a byte array as a key of HashMap
> (ConcurrentHashMap) or an element of HashSet, which could cause very
> confusing bugs.
> The following code is an example where we use a byte array as a key of
> HashMap:
> https://github.com/apache/hbase/blob/326835e8372cc83092e0ec127650438ff153476a/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/wal/SequenceIdAccounting.java#L94
> In Java, we can't use a byte array as a key of HashMap or an element of
> HashSet directly. One solution for it is to use TreeMap
> (ConcurrentSkipListMap) or TreeSet (ConcurrentSkipListSet) with
> Bytes.BYTES_COMPARATOR instead of HashMap and HashSet as follows:
> {code}
> Map map1 = new TreeMap<>(Bytes.BYTES_COMPARATOR);
> Map map2 = new
> ConcurrentSkipListMap<>(Bytes.BYTES_COMPARATOR);
> Set set1 = new TreeSet<>(Bytes.BYTES_COMPARATOR);
> Set set2 = new ConcurrentSkipListSet<>(Bytes.BYTES_COMPARATOR);
> {code}
> We should fix the existing ones in this Jira.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (HBASE-26002) MultiRowMutationEndpoint should return the result of the conditional update
[ https://issues.apache.org/jira/browse/HBASE-26002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17363300#comment-17363300 ] Toshihiro Suzuki commented on HBASE-26002: -- Pushed to master and created a PR for branch-2 to run QA. > MultiRowMutationEndpoint should return the result of the conditional update > --- > > Key: HBASE-26002 > URL: https://issues.apache.org/jira/browse/HBASE-26002 > Project: HBase > Issue Type: Improvement > Components: Coprocessors >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Major > Fix For: 2.5.0, 3.0.0-alpha-2, 2.4.5 > > > HBASE-25703 added support for the conditional update in > MultiRowMutationEndpoint, but MultiRowMutationEndpoint doesn't return the > result of the conditional update (whether or not the mutations are executed). > In this Jira, we will make MultiRowMutationEndpoint return the result of the > conditional update. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-26002) MultiRowMutationEndpoint should return the result of the conditional update
[ https://issues.apache.org/jira/browse/HBASE-26002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toshihiro Suzuki updated HBASE-26002: - Fix Version/s: 2.5.0 > MultiRowMutationEndpoint should return the result of the conditional update > --- > > Key: HBASE-26002 > URL: https://issues.apache.org/jira/browse/HBASE-26002 > Project: HBase > Issue Type: Improvement > Components: Coprocessors >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Major > Fix For: 2.5.0, 3.0.0-alpha-2, 2.4.5 > > > HBASE-25703 added support for the conditional update in > MultiRowMutationEndpoint, but MultiRowMutationEndpoint doesn't return the > result of the conditional update (whether or not the mutations are executed). > In this Jira, we will make MultiRowMutationEndpoint return the result of the > conditional update. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-26002) MultiRowMutationEndpoint should return the result of the conditional update
[ https://issues.apache.org/jira/browse/HBASE-26002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toshihiro Suzuki updated HBASE-26002: - Fix Version/s: 2.4.5 3.0.0-alpha-2 > MultiRowMutationEndpoint should return the result of the conditional update > --- > > Key: HBASE-26002 > URL: https://issues.apache.org/jira/browse/HBASE-26002 > Project: HBase > Issue Type: Improvement > Components: Coprocessors >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Major > Fix For: 3.0.0-alpha-2, 2.4.5 > > > HBASE-25703 added support for the conditional update in > MultiRowMutationEndpoint, but MultiRowMutationEndpoint doesn't return the > result of the conditional update (whether or not the mutations are executed). > In this Jira, we will make MultiRowMutationEndpoint return the result of the > conditional update. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (HBASE-26002) MultiRowMutationEndpoint should return the result of the conditional update
Toshihiro Suzuki created HBASE-26002: Summary: MultiRowMutationEndpoint should return the result of the conditional update Key: HBASE-26002 URL: https://issues.apache.org/jira/browse/HBASE-26002 Project: HBase Issue Type: Improvement Components: Coprocessors Reporter: Toshihiro Suzuki Assignee: Toshihiro Suzuki HBASE-25703 added support for the conditional update in MultiRowMutationEndpoint, but MultiRowMutationEndpoint doesn't return the result of the conditional update (whether or not the mutations are executed). In this Jira, we will make MultiRowMutationEndpoint return the result of the conditional update. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (HBASE-25797) Batch version of checkAndMutate on AsyncTable always returns false
[
https://issues.apache.org/jira/browse/HBASE-25797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17339680#comment-17339680
]
Toshihiro Suzuki edited comment on HBASE-25797 at 5/5/21, 2:07 PM:
---
[~bryson] Thank you for sharing the code. But I just realized that you are
using different versions between client and server. Can you please use the same
version? And note that hbase-2.2.6 doesn't support batch version of
checkAndMutate(). We support that feature from hbase-2.4.0.
Please see the following Jira for the details:
https://issues.apache.org/jira/browse/HBASE-8458
was (Author: brfrn169):
[~bryson] Thank you for sharing the code. But I just realized that you are
using different versions between client and server. Can you please use the same
version? And note that hbase-2.2.6 doesn't support batch version of
checkAndMutate(). We support that feature from hbase-2.4.0:
Please see the following Jira for the details:
https://issues.apache.org/jira/browse/HBASE-8458
> Batch version of checkAndMutate on AsyncTable always returns false
> --
>
> Key: HBASE-25797
> URL: https://issues.apache.org/jira/browse/HBASE-25797
> Project: HBase
> Issue Type: Bug
> Components: Client
>Affects Versions: 2.4.1
>Reporter: Hochul Shin
>Assignee: Toshihiro Suzuki
>Priority: Minor
> Labels: bug
>
> Batch version of CheckAndMutate always returns false whereas non-batch
> version works fine.
> The code is like:
>
> {code:java}
> AysncTable table = connection.getTable(tableName, executorService);
> ...
> // add r1
> table.put(Arrays.asList(
> new Put(Bytes.toBytes("r1")).addColumn(COL_FAMILY, Bytes.toBytes("q1"),
> Bytes.toBytes("v1";
> CheckAndMutate checkAndMutate1 =
> CheckAndMutate.newBuilder(Bytes.toBytes("r1"))
> .ifNotExists(COL_FAMILY, Bytes.toBytes("q1"))
> .build(new Put(Bytes.toBytes("r1")).addColumn(COL_FAMILY,
> Bytes.toBytes("q1"), Bytes.toBytes("v1")));
> CheckAndMutate checkAndMutate2 =
> CheckAndMutate.newBuilder(Bytes.toBytes("r2"))
> .ifNotExists(COL_FAMILY, Bytes.toBytes("q2"))
> .build(new Put(Bytes.toBytes("r2")).addColumn(COL_FAMILY,
> Bytes.toBytes("q2"), Bytes.toBytes("v2")));
> {code}
>
> With batch version of checkAndMutate
> {code:java}
> List> results =
> table.checkAndMutate(Arrays.asList(checkAndMutate1, checkAndMutate2));
> System.out.println("first: " + results.get(0).join().isSuccess()); // false
> System.out.println("second: " + results.get(1).join().isSuccess()); //false!
> {code}
>
>
> Even it returned false, the r1 was written to the table. (timestamp was
> updated)
>
> With non-batch version of checkAndMutate
>
> {code:java}
> CompletableFuture result1 =
> table.checkAndMutate(checkAndMutate1);
> CompletableFuture result2 =
> table.checkAndMutate(checkAndMutate2);
> System.out.println("first: " + result1.join().isSuccess()); // false
> System.out.println("second: " + result2.join().isSuccess()); // true as
> expected
> {code}
>
> As expected r1 wasn't written to the table.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (HBASE-25797) Batch version of checkAndMutate on AsyncTable always returns false
[
https://issues.apache.org/jira/browse/HBASE-25797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17339680#comment-17339680
]
Toshihiro Suzuki commented on HBASE-25797:
--
[~bryson] Thank you for sharing the code. But I just realized that you are
using different versions between client and server. Can you please use the same
version? And note that hbase-2.2.6 doesn't support batch version of
checkAndMutate(). We support that feature from hbase-2.4.0:
Please see the following Jira for the details:
https://issues.apache.org/jira/browse/HBASE-8458
> Batch version of checkAndMutate on AsyncTable always returns false
> --
>
> Key: HBASE-25797
> URL: https://issues.apache.org/jira/browse/HBASE-25797
> Project: HBase
> Issue Type: Bug
> Components: Client
>Affects Versions: 2.4.1
>Reporter: Hochul Shin
>Assignee: Toshihiro Suzuki
>Priority: Minor
> Labels: bug
>
> Batch version of CheckAndMutate always returns false whereas non-batch
> version works fine.
> The code is like:
>
> {code:java}
> AysncTable table = connection.getTable(tableName, executorService);
> ...
> // add r1
> table.put(Arrays.asList(
> new Put(Bytes.toBytes("r1")).addColumn(COL_FAMILY, Bytes.toBytes("q1"),
> Bytes.toBytes("v1";
> CheckAndMutate checkAndMutate1 =
> CheckAndMutate.newBuilder(Bytes.toBytes("r1"))
> .ifNotExists(COL_FAMILY, Bytes.toBytes("q1"))
> .build(new Put(Bytes.toBytes("r1")).addColumn(COL_FAMILY,
> Bytes.toBytes("q1"), Bytes.toBytes("v1")));
> CheckAndMutate checkAndMutate2 =
> CheckAndMutate.newBuilder(Bytes.toBytes("r2"))
> .ifNotExists(COL_FAMILY, Bytes.toBytes("q2"))
> .build(new Put(Bytes.toBytes("r2")).addColumn(COL_FAMILY,
> Bytes.toBytes("q2"), Bytes.toBytes("v2")));
> {code}
>
> With batch version of checkAndMutate
> {code:java}
> List> results =
> table.checkAndMutate(Arrays.asList(checkAndMutate1, checkAndMutate2));
> System.out.println("first: " + results.get(0).join().isSuccess()); // false
> System.out.println("second: " + results.get(1).join().isSuccess()); //false!
> {code}
>
>
> Even it returned false, the r1 was written to the table. (timestamp was
> updated)
>
> With non-batch version of checkAndMutate
>
> {code:java}
> CompletableFuture result1 =
> table.checkAndMutate(checkAndMutate1);
> CompletableFuture result2 =
> table.checkAndMutate(checkAndMutate2);
> System.out.println("first: " + result1.join().isSuccess()); // false
> System.out.println("second: " + result2.join().isSuccess()); // true as
> expected
> {code}
>
> As expected r1 wasn't written to the table.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (HBASE-25797) Batch version of checkAndMutate on AsyncTable always returns false
[
https://issues.apache.org/jira/browse/HBASE-25797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Toshihiro Suzuki reassigned HBASE-25797:
Assignee: Toshihiro Suzuki
> Batch version of checkAndMutate on AsyncTable always returns false
> --
>
> Key: HBASE-25797
> URL: https://issues.apache.org/jira/browse/HBASE-25797
> Project: HBase
> Issue Type: Bug
> Components: Client
>Affects Versions: 2.4.1
>Reporter: Hochul Shin
>Assignee: Toshihiro Suzuki
>Priority: Minor
> Labels: bug
>
> Batch version of CheckAndMutate always returns false whereas non-batch
> version works fine.
> The code is like:
>
> {code:java}
> AysncTable table = connection.getTable(tableName, executorService);
> ...
> // add r1
> table.put(Arrays.asList(
> new Put(Bytes.toBytes("r1")).addColumn(COL_FAMILY, Bytes.toBytes("q1"),
> Bytes.toBytes("v1";
> CheckAndMutate checkAndMutate1 =
> CheckAndMutate.newBuilder(Bytes.toBytes("r1"))
> .ifNotExists(COL_FAMILY, Bytes.toBytes("q1"))
> .build(new Put(Bytes.toBytes("r1")).addColumn(COL_FAMILY,
> Bytes.toBytes("q1"), Bytes.toBytes("v1")));
> CheckAndMutate checkAndMutate2 =
> CheckAndMutate.newBuilder(Bytes.toBytes("r2"))
> .ifNotExists(COL_FAMILY, Bytes.toBytes("q2"))
> .build(new Put(Bytes.toBytes("r2")).addColumn(COL_FAMILY,
> Bytes.toBytes("q2"), Bytes.toBytes("v2")));
> {code}
>
> With batch version of checkAndMutate
> {code:java}
> List> results =
> table.checkAndMutate(Arrays.asList(checkAndMutate1, checkAndMutate2));
> System.out.println("first: " + results.get(0).join().isSuccess()); // false
> System.out.println("second: " + results.get(1).join().isSuccess()); //false!
> {code}
>
>
> Even it returned false, the r1 was written to the table. (timestamp was
> updated)
>
> With non-batch version of checkAndMutate
>
> {code:java}
> CompletableFuture result1 =
> table.checkAndMutate(checkAndMutate1);
> CompletableFuture result2 =
> table.checkAndMutate(checkAndMutate2);
> System.out.println("first: " + result1.join().isSuccess()); // false
> System.out.println("second: " + result2.join().isSuccess()); // true as
> expected
> {code}
>
> As expected r1 wasn't written to the table.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (HBASE-25797) Batch version of checkAndMutate on AsyncTable always returns false
[
https://issues.apache.org/jira/browse/HBASE-25797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17338700#comment-17338700
]
Toshihiro Suzuki commented on HBASE-25797:
--
Thank you [~bryson],
Can you please try to call the get() method of the CompletableFuture object
returned by table.put() as follows:
{code}
// add r1
table.put(Arrays.asList(
new Put(Bytes.toBytes("r1")).addColumn(COL_FAMILY, Bytes.toBytes("q1"),
Bytes.toBytes("v1".get();
{code}
As the *table* is AysncTable, we need to wait for table.put() to complete
before calling table.checkAndMutate(). Thanks.
> Batch version of checkAndMutate on AsyncTable always returns false
> --
>
> Key: HBASE-25797
> URL: https://issues.apache.org/jira/browse/HBASE-25797
> Project: HBase
> Issue Type: Bug
> Components: Client
>Affects Versions: 2.4.1
>Reporter: Hochul Shin
>Priority: Minor
> Labels: bug
>
> Batch version of CheckAndMutate always returns false whereas non-batch
> version works fine.
> The code is like:
>
> {code:java}
> AysncTable table = connection.getTable(tableName, executorService);
> ...
> // add r1
> table.put(Arrays.asList(
> new Put(Bytes.toBytes("r1")).addColumn(COL_FAMILY, Bytes.toBytes("q1"),
> Bytes.toBytes("v1";
> CheckAndMutate checkAndMutate1 =
> CheckAndMutate.newBuilder(Bytes.toBytes("r1"))
> .ifNotExists(COL_FAMILY, Bytes.toBytes("q1"))
> .build(new Put(Bytes.toBytes("r1")).addColumn(COL_FAMILY,
> Bytes.toBytes("q1"), Bytes.toBytes("v1")));
> CheckAndMutate checkAndMutate2 =
> CheckAndMutate.newBuilder(Bytes.toBytes("r2"))
> .ifNotExists(COL_FAMILY, Bytes.toBytes("q2"))
> .build(new Put(Bytes.toBytes("r2")).addColumn(COL_FAMILY,
> Bytes.toBytes("q2"), Bytes.toBytes("v2")));
> {code}
>
> With batch version of checkAndMutate
> {code:java}
> List> results =
> table.checkAndMutate(Arrays.asList(checkAndMutate1, checkAndMutate2));
> System.out.println("first: " + results.get(0).join().isSuccess()); // false
> System.out.println("second: " + results.get(1).join().isSuccess()); //false!
> {code}
>
>
> Even it returned false, the r1 was written to the table. (timestamp was
> updated)
>
> With non-batch version of checkAndMutate
>
> {code:java}
> CompletableFuture result1 =
> table.checkAndMutate(checkAndMutate1);
> CompletableFuture result2 =
> table.checkAndMutate(checkAndMutate2);
> System.out.println("first: " + result1.join().isSuccess()); // false
> System.out.println("second: " + result2.join().isSuccess()); // true as
> expected
> {code}
>
> As expected r1 wasn't written to the table.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (HBASE-25797) Batch version of checkAndMutate on AsyncTable always returns false
[
https://issues.apache.org/jira/browse/HBASE-25797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17337804#comment-17337804
]
Toshihiro Suzuki commented on HBASE-25797:
--
[~bryson] Could you please show me a complete code to reproduce this issue?
> Batch version of checkAndMutate on AsyncTable always returns false
> --
>
> Key: HBASE-25797
> URL: https://issues.apache.org/jira/browse/HBASE-25797
> Project: HBase
> Issue Type: Bug
> Components: Client
>Affects Versions: 2.4.1
>Reporter: Hochul Shin
>Priority: Minor
> Labels: bug
>
> Batch version of CheckAndMutate always returns false whereas non-batch
> version works fine.
> The code is like:
> ```
> AysncTable table = connection.getTable(tableName, executorService);
> ...
> // add r1
> table.put(Arrays.asList(
> new Put(Bytes.toBytes("r1")).addColumn(COL_FAMILY, Bytes.toBytes("q1"),
> Bytes.toBytes("v1";
> CheckAndMutate checkAndMutate1 =
> CheckAndMutate.newBuilder(Bytes.toBytes("r1"))
> .ifNotExists(COL_FAMILY, Bytes.toBytes("q1"))
> .build(new Put(Bytes.toBytes("r1")).addColumn(COL_FAMILY,
> Bytes.toBytes("q1"), Bytes.toBytes("v1")));
> CheckAndMutate checkAndMutate2 =
> CheckAndMutate.newBuilder(Bytes.toBytes("r2"))
> .ifNotExists(COL_FAMILY, Bytes.toBytes("q2"))
> .build(new Put(Bytes.toBytes("r2")).addColumn(COL_FAMILY,
> Bytes.toBytes("q2"), Bytes.toBytes("v2")));
> ```
> With batch version of checkAndMutate
> ```
> List> results =
> table.checkAndMutate(Arrays.asList(checkAndMutate1, checkAndMutate2));
> System.out.println("first: " + results.get(0).join().isSuccess()); // false
> System.out.println("second: " + results.get(1).join().isSuccess()); //false!
> ```
> Even it returned false, the r1 was written to the table. (timestamp was
> updated)
>
> With non-batch version of checkAndMutate
> ```
> CompletableFuture result1 =
> table.checkAndMutate(checkAndMutate1);
> CompletableFuture result2 =
> table.checkAndMutate(checkAndMutate2);
> System.out.println("first: " + result1.join().isSuccess()); // false
> System.out.println("second: " + result2.join().isSuccess()); // true as
> expected
> ```
> As expected r1 wasn't written to the table.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (HBASE-25797) Batch version of checkAndMutate on AsyncTable always returns false
[
https://issues.apache.org/jira/browse/HBASE-25797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17337800#comment-17337800
]
Toshihiro Suzuki commented on HBASE-25797:
--
Thank you for reporting this. Let me take a look at it.
> Batch version of checkAndMutate on AsyncTable always returns false
> --
>
> Key: HBASE-25797
> URL: https://issues.apache.org/jira/browse/HBASE-25797
> Project: HBase
> Issue Type: Bug
> Components: Client
>Affects Versions: 2.4.1
>Reporter: Hochul Shin
>Priority: Minor
> Labels: bug
>
> Batch version of CheckAndMutate always returns false whereas non-batch
> version works fine.
> The code is like:
> ```
> AysncTable table = connection.getTable(tableName, executorService);
> ...
> // add r1
> table.put(Arrays.asList(
> new Put(Bytes.toBytes("r1")).addColumn(COL_FAMILY, Bytes.toBytes("q1"),
> Bytes.toBytes("v1";
> CheckAndMutate checkAndMutate1 =
> CheckAndMutate.newBuilder(Bytes.toBytes("r1"))
> .ifNotExists(COL_FAMILY, Bytes.toBytes("q1"))
> .build(new Put(Bytes.toBytes("r1")).addColumn(COL_FAMILY,
> Bytes.toBytes("q1"), Bytes.toBytes("v1")));
> CheckAndMutate checkAndMutate2 =
> CheckAndMutate.newBuilder(Bytes.toBytes("r2"))
> .ifNotExists(COL_FAMILY, Bytes.toBytes("q2"))
> .build(new Put(Bytes.toBytes("r2")).addColumn(COL_FAMILY,
> Bytes.toBytes("q2"), Bytes.toBytes("v2")));
> ```
> With batch version of checkAndMutate
> ```
> List> results =
> table.checkAndMutate(Arrays.asList(checkAndMutate1, checkAndMutate2));
> System.out.println("first: " + results.get(0).join().isSuccess()); // false
> System.out.println("second: " + results.get(1).join().isSuccess()); //false!
> ```
> Even it returned false, the r1 was written to the table. (timestamp was
> updated)
>
> With non-batch version of checkAndMutate
> ```
> CompletableFuture result1 =
> table.checkAndMutate(checkAndMutate1);
> CompletableFuture result2 =
> table.checkAndMutate(checkAndMutate2);
> System.out.println("first: " + result1.join().isSuccess()); // false
> System.out.println("second: " + result2.join().isSuccess()); // true as
> expected
> ```
> As expected r1 wasn't written to the table.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (HBASE-25766) Introduce RegionSplitRestriction that restricts the pattern of the split point
[ https://issues.apache.org/jira/browse/HBASE-25766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toshihiro Suzuki resolved HBASE-25766. -- Hadoop Flags: Reviewed Resolution: Fixed > Introduce RegionSplitRestriction that restricts the pattern of the split point > -- > > Key: HBASE-25766 > URL: https://issues.apache.org/jira/browse/HBASE-25766 > Project: HBase > Issue Type: Improvement >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Major > Fix For: 3.0.0-alpha-1, 2.5.0, 2.4.3 > > > As discussed in HBASE-25706, we can introduce RegionSplitRestriction that > restricts the pattern of the split point. > See the following comment for the details: > https://issues.apache.org/jira/browse/HBASE-25706?focusedCommentId=17310190=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17310190 > CC: [~zhangduo] [~stack] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-25766) Introduce RegionSplitRestriction that restricts the pattern of the split point
[ https://issues.apache.org/jira/browse/HBASE-25766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17327106#comment-17327106 ] Toshihiro Suzuki commented on HBASE-25766: -- Pushed to master, branch-2 and branch-2.4. Thank you for reviewing and discussing this! [~zhangduo] [~stack] > Introduce RegionSplitRestriction that restricts the pattern of the split point > -- > > Key: HBASE-25766 > URL: https://issues.apache.org/jira/browse/HBASE-25766 > Project: HBase > Issue Type: Improvement >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Major > Fix For: 3.0.0-alpha-1, 2.5.0, 2.4.3 > > > As discussed in HBASE-25706, we can introduce RegionSplitRestriction that > restricts the pattern of the split point. > See the following comment for the details: > https://issues.apache.org/jira/browse/HBASE-25706?focusedCommentId=17310190=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17310190 > CC: [~zhangduo] [~stack] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-25766) Introduce RegionSplitRestriction that restricts the pattern of the split point
[ https://issues.apache.org/jira/browse/HBASE-25766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toshihiro Suzuki updated HBASE-25766: - Fix Version/s: 2.5.0 > Introduce RegionSplitRestriction that restricts the pattern of the split point > -- > > Key: HBASE-25766 > URL: https://issues.apache.org/jira/browse/HBASE-25766 > Project: HBase > Issue Type: Improvement >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Major > Fix For: 3.0.0-alpha-1, 2.5.0, 2.4.3 > > > As discussed in HBASE-25706, we can introduce RegionSplitRestriction that > restricts the pattern of the split point. > See the following comment for the details: > https://issues.apache.org/jira/browse/HBASE-25706?focusedCommentId=17310190=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17310190 > CC: [~zhangduo] [~stack] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-25766) Introduce RegionSplitRestriction that restricts the pattern of the split point
[
https://issues.apache.org/jira/browse/HBASE-25766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Toshihiro Suzuki updated HBASE-25766:
-
Release Note:
After HBASE-25766, we can specify a split restriction, "KeyPrefix" or
"DelimitedKeyPrefix", to a table with the
"hbase.regionserver.region.split_restriction.type" property. The "KeyPrefix"
split restriction groups rows by a prefix of the row-key. And the
"DelimitedKeyPrefix" split restriction groups rows by a prefix of the row-key
with a delimiter.
For example:
```
# Create a table with a "KeyPrefix" split restriction, where the prefix length
is 2 bytes
hbase> create 'tbl1', 'fam', {CONFIGURATION =>
{'hbase.regionserver.region.split_restriction.type' => 'KeyPrefix',
'hbase.regionserver.region.split_restriction.prefix_length' => '2'}}
# Create a table with a "DelimitedKeyPrefix" split restriction, where the
delimiter is a comma (,)
hbase> create 'tbl2', 'fam', {CONFIGURATION =>
{'hbase.regionserver.region.split_restriction.type' => 'DelimitedKeyPrefix',
'hbase.regionserver.region.split_restriction.delimiter' => ','}}
```
Instead of specifying a split restriction to a table directly, we can also set
the properties in hbase-site.xml. In this case, the specified split restriction
is applied for all the tables.
Note that the split restriction is also applied to a user-specified split point
so that we don't allow users to break the restriction, which is different
behavior from the existing KeyPrefixRegionSplitPolicy and
DelimitedKeyPrefixRegionSplitPolicy.
was:
After HBASE-25766, we can specify a split restriction, "KeyPrefix" or
"DelimitedKeyPrefix", to a table with the
"hbase.regionserver.region.split_restriction.type" property. The "KeyPrefix"
split restriction groups rows by a prefix of the row-key. And the
"DelimitedKeyPrefix" split restriction groups rows by a prefix of the row-key
with a delimiter.
For example:
```
# Create a table with a "KeyPrefix" split restriction, where the prefix length
is 2 bytes
hbase> create 'tbl1', 'fam', {CONFIGURATION =>
{'hbase.regionserver.region.split_restriction.type' => 'KeyPrefix',
'hbase.regionserver.region.split_restriction.prefix_length' => '2'}}
# Create a table with a "DelimitedKeyPrefix" split restriction, where the
delimiter is a comma (,)
hbase> create 'tbl2', 'fam', {CONFIGURATION =>
{'hbase.regionserver.region.split_restriction.type' => 'DelimitedKeyPrefix',
'hbase.regionserver.region.split_restriction.delimiter' => ','}}
```
Instead of specifying a split restriction to a table directly, we can also set
the properties in hbase-site.xml. In this case, the specified split restriction
is applied for all the tables.
Note that after this change, the split restriction is also applied to a
user-specified split point so that we don't allow users to break the
restriction, which is a behavior change.
> Introduce RegionSplitRestriction that restricts the pattern of the split point
> --
>
> Key: HBASE-25766
> URL: https://issues.apache.org/jira/browse/HBASE-25766
> Project: HBase
> Issue Type: Improvement
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Major
> Fix For: 3.0.0-alpha-1, 2.4.3
>
>
> As discussed in HBASE-25706, we can introduce RegionSplitRestriction that
> restricts the pattern of the split point.
> See the following comment for the details:
> https://issues.apache.org/jira/browse/HBASE-25706?focusedCommentId=17310190=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17310190
> CC: [~zhangduo] [~stack]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (HBASE-25766) Introduce RegionSplitRestriction that restricts the pattern of the split point
[
https://issues.apache.org/jira/browse/HBASE-25766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Toshihiro Suzuki updated HBASE-25766:
-
Release Note:
After HBASE-25766, we can specify a split restriction, "KeyPrefix" or
"DelimitedKeyPrefix", to a table with the
"hbase.regionserver.region.split_restriction.type" property. The "KeyPrefix"
split restriction groups rows by a prefix of the row-key. And the
"DelimitedKeyPrefix" split restriction groups rows by a prefix of the row-key
with a delimiter.
For example:
```
# Create a table with a "KeyPrefix" split restriction, where the prefix length
is 2 bytes
hbase> create 'tbl1', 'fam', {CONFIGURATION =>
{'hbase.regionserver.region.split_restriction.type' => 'KeyPrefix',
'hbase.regionserver.region.split_restriction.prefix_length' => '2'}}
# Create a table with a "DelimitedKeyPrefix" split restriction, where the
delimiter is a comma (,)
hbase> create 'tbl2', 'fam', {CONFIGURATION =>
{'hbase.regionserver.region.split_restriction.type' => 'DelimitedKeyPrefix',
'hbase.regionserver.region.split_restriction.delimiter' => ','}}
```
Instead of specifying a split restriction to a table directly, we can also set
the properties in hbase-site.xml. In this case, the specified split restriction
is applied for all the tables.
Note that after this change, the split restriction is also applied to a
user-specified split point so that we don't allow users to break the
restriction, which is a behavior change.
was:
After HBASE-25766, we can specify a split restriction, "KeyPrefix" or
"DelimitedKeyPrefix", to a table with the
"hbase.regionserver.region.split_restriction.type" property. The "KeyPrefix"
split restriction groups rows by a prefix of the row-key. And the
"DelimitedKeyPrefix" split restriction groups rows by a prefix of the row-key
with a delimiter.
For example:
```
# Create a table with a "KeyPrefix" split restriction, where the prefix length
is 2 bytes
hbase> create 'tbl1', 'fam', {CONFIGURATION =>
{'hbase.regionserver.region.split_restriction.type' => 'KeyPrefix',
'hbase.regionserver.region.split_restriction.prefix_length' => '2'}}
# Create a table with a "DelimitedKeyPrefix" split restriction, where the
delimiter is a comma (,)
hbase> create 'tbl2', 'fam', {CONFIGURATION =>
{'hbase.regionserver.region.split_restriction.type' => 'DelimitedKeyPrefix',
'hbase.regionserver.region.split_restriction.delimiter' => ','}}
```
Instead of specifying a split restriction to a table directly, we can also set
the properties in hbase-site.xml. In this case, the specified split restriction
is applied for all the tables.
> Introduce RegionSplitRestriction that restricts the pattern of the split point
> --
>
> Key: HBASE-25766
> URL: https://issues.apache.org/jira/browse/HBASE-25766
> Project: HBase
> Issue Type: Improvement
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Major
> Fix For: 3.0.0-alpha-1, 2.4.3
>
>
> As discussed in HBASE-25706, we can introduce RegionSplitRestriction that
> restricts the pattern of the split point.
> See the following comment for the details:
> https://issues.apache.org/jira/browse/HBASE-25706?focusedCommentId=17310190=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17310190
> CC: [~zhangduo] [~stack]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (HBASE-25766) Introduce RegionSplitRestriction that restricts the pattern of the split point
[
https://issues.apache.org/jira/browse/HBASE-25766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Toshihiro Suzuki updated HBASE-25766:
-
Release Note:
After HBASE-25766, we can specify a split restriction, "KeyPrefix" or
"DelimitedKeyPrefix", to a table with the
"hbase.regionserver.region.split_restriction.type" property. The "KeyPrefix"
split restriction groups rows by a prefix of the row-key. And the
"DelimitedKeyPrefix" split restriction groups rows by a prefix of the row-key
with a delimiter.
For example:
```
# Create a table with a "KeyPrefix" split restriction, where the prefix length
is 2 bytes
hbase> create 'tbl1', 'fam', {CONFIGURATION =>
{'hbase.regionserver.region.split_restriction.type' => 'KeyPrefix',
'hbase.regionserver.region.split_restriction.prefix_length' => '2'}}
# Create a table with a "DelimitedKeyPrefix" split restriction, where the
delimiter is a comma (,)
hbase> create 'tbl2', 'fam', {CONFIGURATION =>
{'hbase.regionserver.region.split_restriction.type' => 'DelimitedKeyPrefix',
'hbase.regionserver.region.split_restriction.delimiter' => ','}}
```
Instead of specifying a split restriction to a table directly, we can also set
the properties in hbase-site.xml. In this case, the specified split restriction
is applied for all the tables.
was:
After HBASE-25766, we can specify a split restriction, "KeyPrefix" or
"DelimitedKeyPrefix", to a table with
"hbase.regionserver.region.split_restriction.type" property. The "KeyPrefix"
split restriction groups rows by a prefix of the row-key. And the
"DelimitedKeyPrefix" split restriction groups rows by a prefix of the row-key
with a delimiter.
For example:
```
# Create a table with a "KeyPrefix" split restriction, where the prefix length
is 2 bytes
hbase> create 'tbl1', 'fam', {CONFIGURATION =>
{'hbase.regionserver.region.split_restriction.type' => 'KeyPrefix',
'hbase.regionserver.region.split_restriction.prefix_length' => '2'}}
# Create a table with a "DelimitedKeyPrefix" split restriction, where the
delimiter is a comma (,)
hbase> create 'tbl2', 'fam', {CONFIGURATION =>
{'hbase.regionserver.region.split_restriction.type' => 'DelimitedKeyPrefix',
'hbase.regionserver.region.split_restriction.delimiter' => ','}}
```
Instead of specifying a split restriction to a table directly, we can also set
the properties in hbase-site.xml. In this case, the specified split restriction
is applied for all the tables.
> Introduce RegionSplitRestriction that restricts the pattern of the split point
> --
>
> Key: HBASE-25766
> URL: https://issues.apache.org/jira/browse/HBASE-25766
> Project: HBase
> Issue Type: Improvement
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Major
> Fix For: 3.0.0-alpha-1, 2.4.3
>
>
> As discussed in HBASE-25706, we can introduce RegionSplitRestriction that
> restricts the pattern of the split point.
> See the following comment for the details:
> https://issues.apache.org/jira/browse/HBASE-25706?focusedCommentId=17310190=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17310190
> CC: [~zhangduo] [~stack]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (HBASE-25766) Introduce RegionSplitRestriction that restricts the pattern of the split point
[ https://issues.apache.org/jira/browse/HBASE-25766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toshihiro Suzuki updated HBASE-25766: - Description: As discussed in HBASE-25706, we can introduce RegionPointRestriction that restricts the pattern of the split point. See the following comment for the details: https://issues.apache.org/jira/browse/HBASE-25706?focusedCommentId=17310190=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17310190 CC: [~zhangduo] [~stack] was: As discussed in HBASE-25706, we can introduce RegionSplitPointRestriction that restricts the pattern of the split point. See the following comment for the details: https://issues.apache.org/jira/browse/HBASE-25706?focusedCommentId=17310190=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17310190 CC: [~zhangduo] [~stack] > Introduce RegionSplitRestriction that restricts the pattern of the split point > -- > > Key: HBASE-25766 > URL: https://issues.apache.org/jira/browse/HBASE-25766 > Project: HBase > Issue Type: Improvement >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Major > Fix For: 3.0.0-alpha-1, 2.4.3 > > > As discussed in HBASE-25706, we can introduce RegionPointRestriction that > restricts the pattern of the split point. > See the following comment for the details: > https://issues.apache.org/jira/browse/HBASE-25706?focusedCommentId=17310190=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17310190 > CC: [~zhangduo] [~stack] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-25766) Introduce RegionSplitRestriction that restricts the pattern of the split point
[
https://issues.apache.org/jira/browse/HBASE-25766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Toshihiro Suzuki updated HBASE-25766:
-
Release Note:
After HBASE-25766, we can specify a split restriction, "KeyPrefix" or
"DelimitedKeyPrefix", to a table with
"hbase.regionserver.region.split_restriction.type" property. The "KeyPrefix"
split restriction groups rows by a prefix of the row-key. And the
"DelimitedKeyPrefix" split restriction groups rows by a prefix of the row-key
with a delimiter.
For example:
```
# Create a table with a "KeyPrefix" split restriction, where the prefix length
is 2 bytes
hbase> create 'tbl1', 'fam', {CONFIGURATION =>
{'hbase.regionserver.region.split_restriction.type' => 'KeyPrefix',
'hbase.regionserver.region.split_restriction.prefix_length' => '2'}}
# Create a table with a "DelimitedKeyPrefix" split restriction, where the
delimiter is a comma (,)
hbase> create 'tbl2', 'fam', {CONFIGURATION =>
{'hbase.regionserver.region.split_restriction.type' => 'DelimitedKeyPrefix',
'hbase.regionserver.region.split_restriction.delimiter' => ','}}
```
Instead of specifying a split restriction to a table directly, we can also set
the properties in hbase-site.xml. In this case, the specified split restriction
is applied for all the tables.
was:
After HBASE-25766, we can specify a split point restriction, "KeyPrefix" or
"DelimitedKeyPrefix", to a table with
"hbase.regionserver.region.split_point_restriction.type" property. The
"KeyPrefix" split point restriction groups rows by a prefix of the row-key. And
the "DelimitedKeyPrefix" split point restriction groups rows by a prefix of the
row-key with a delimiter.
For example:
```
# Create a table with a "KeyPrefix" split point restriction, where the prefix
length is 2 bytes
hbase> create 'tbl1', 'fam', {CONFIGURATION =>
{'hbase.regionserver.region.split_point_restriction.type' => 'KeyPrefix',
'hbase.regionserver.region.split_point_restriction.prefix_length' => '2'}}
# Create a table with a "DelimitedKeyPrefix" split point restriction, where the
delimiter is a comma (,)
hbase> create 'tbl2', 'fam', {CONFIGURATION =>
{'hbase.regionserver.region.split_point_restriction.type' =>
'DelimitedKeyPrefix',
'hbase.regionserver.region.split_point_restriction.delimiter' => ','}}
```
Instead of specifying a split point restriction to a table directly, we can
also set the properties in hbase-site.xml. In this case, the specified split
point restriction is applied for all the tables.
> Introduce RegionSplitRestriction that restricts the pattern of the split point
> --
>
> Key: HBASE-25766
> URL: https://issues.apache.org/jira/browse/HBASE-25766
> Project: HBase
> Issue Type: Improvement
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Major
> Fix For: 3.0.0-alpha-1, 2.4.3
>
>
> As discussed in HBASE-25706, we can introduce RegionSplitPointRestriction
> that restricts the pattern of the split point.
> See the following comment for the details:
> https://issues.apache.org/jira/browse/HBASE-25706?focusedCommentId=17310190=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17310190
> CC: [~zhangduo] [~stack]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (HBASE-25766) Introduce RegionSplitRestriction that restricts the pattern of the split point
[ https://issues.apache.org/jira/browse/HBASE-25766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toshihiro Suzuki updated HBASE-25766: - Description: As discussed in HBASE-25706, we can introduce RegionSplitRestriction that restricts the pattern of the split point. See the following comment for the details: https://issues.apache.org/jira/browse/HBASE-25706?focusedCommentId=17310190=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17310190 CC: [~zhangduo] [~stack] was: As discussed in HBASE-25706, we can introduce RegionPointRestriction that restricts the pattern of the split point. See the following comment for the details: https://issues.apache.org/jira/browse/HBASE-25706?focusedCommentId=17310190=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17310190 CC: [~zhangduo] [~stack] > Introduce RegionSplitRestriction that restricts the pattern of the split point > -- > > Key: HBASE-25766 > URL: https://issues.apache.org/jira/browse/HBASE-25766 > Project: HBase > Issue Type: Improvement >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Major > Fix For: 3.0.0-alpha-1, 2.4.3 > > > As discussed in HBASE-25706, we can introduce RegionSplitRestriction that > restricts the pattern of the split point. > See the following comment for the details: > https://issues.apache.org/jira/browse/HBASE-25706?focusedCommentId=17310190=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17310190 > CC: [~zhangduo] [~stack] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-25766) Introduce RegionSplitRestriction that restricts the pattern of the split point
[ https://issues.apache.org/jira/browse/HBASE-25766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toshihiro Suzuki updated HBASE-25766: - Summary: Introduce RegionSplitRestriction that restricts the pattern of the split point (was: Introduce RegionSplitPointRestriction that restricts the pattern of the split point) > Introduce RegionSplitRestriction that restricts the pattern of the split point > -- > > Key: HBASE-25766 > URL: https://issues.apache.org/jira/browse/HBASE-25766 > Project: HBase > Issue Type: Improvement >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Major > Fix For: 3.0.0-alpha-1, 2.4.3 > > > As discussed in HBASE-25706, we can introduce RegionSplitPointRestriction > that restricts the pattern of the split point. > See the following comment for the details: > https://issues.apache.org/jira/browse/HBASE-25706?focusedCommentId=17310190=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17310190 > CC: [~zhangduo] [~stack] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-25766) Introduce RegionSplitPointRestriction that restricts the pattern of the split point
[ https://issues.apache.org/jira/browse/HBASE-25766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17325390#comment-17325390 ] Toshihiro Suzuki commented on HBASE-25766: -- [~stack] Can you please take a look at the PR? Thanks. > Introduce RegionSplitPointRestriction that restricts the pattern of the split > point > --- > > Key: HBASE-25766 > URL: https://issues.apache.org/jira/browse/HBASE-25766 > Project: HBase > Issue Type: Improvement >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Major > Fix For: 3.0.0-alpha-1, 2.4.3 > > > As discussed in HBASE-25706, we can introduce RegionSplitPointRestriction > that restricts the pattern of the split point. > See the following comment for the details: > https://issues.apache.org/jira/browse/HBASE-25706?focusedCommentId=17310190=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17310190 > CC: [~zhangduo] [~stack] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-25766) Introduce RegionSplitPointRestriction that restricts the pattern of the split point
[
https://issues.apache.org/jira/browse/HBASE-25766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Toshihiro Suzuki updated HBASE-25766:
-
Release Note:
After HBASE-25766, we can specify a split point restriction, "KeyPrefix" or
"DelimitedKeyPrefix", to a table with
"hbase.regionserver.region.split_point_restriction.type" property. The
"KeyPrefix" split point restriction groups rows by a prefix of the row-key. And
the "DelimitedKeyPrefix" split point restriction groups rows by a prefix of the
row-key with a delimiter.
For example:
```
# Create a table with a "KeyPrefix" split point restriction, where the prefix
length is 2 bytes
hbase> create 'tbl1', 'fam', {CONFIGURATION =>
{'hbase.regionserver.region.split_point_restriction.type' => 'KeyPrefix',
'hbase.regionserver.region.split_point_restriction.prefix_length' => '2'}}
# Create a table with a "DelimitedKeyPrefix" split point restriction, where the
delimiter is a comma (,)
hbase> create 'tbl2', 'fam', {CONFIGURATION =>
{'hbase.regionserver.region.split_point_restriction.type' =>
'DelimitedKeyPrefix',
'hbase.regionserver.region.split_point_restriction.delimiter' => ','}}
```
Instead of specifying a split point restriction to a table directly, we can
also set the properties in hbase-site.xml. In this case, the specified split
point restriction is applied for all the tables.
was:
After HBASE-25766, we can specify a split point restriction, "KeyPrefix" or
"DelimitedKeyPrefix", to a table with
"hbase.regionserver.region.split_point_restriction.type" property. The
"KeyPrefix" split point restriction groups rows by a prefix of the row-key. And
the "DelimitedKeyPrefix" split point restriction groups rows by a prefix of the
row-key with a delimiter.
For example:
```
# Create a table with a "KeyPrefix" split point restriction, where the prefix
length is 2 bytes
create 'tbl1', 'fam', {CONFIGURATION =>
{'hbase.regionserver.region.split_point_restriction.type' => 'KeyPrefix',
'hbase.regionserver.region.split_point_restriction.prefix_length' => '2'}}
# Create a table with a "DelimitedKeyPrefix" split point restriction, where the
delimiter is a comma (,)
create 'tbl2', 'fam', {CONFIGURATION =>
{'hbase.regionserver.region.split_point_restriction.type' =>
'DelimitedKeyPrefix',
'hbase.regionserver.region.split_point_restriction.delimiter' => ','}}
```
Instead of specifying a split point restriction to a table directly, we can
also set the properties in hbase-site.xml. In this case, the specified split
point restriction is applied for all the tables.
> Introduce RegionSplitPointRestriction that restricts the pattern of the split
> point
> ---
>
> Key: HBASE-25766
> URL: https://issues.apache.org/jira/browse/HBASE-25766
> Project: HBase
> Issue Type: Improvement
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Major
> Fix For: 3.0.0-alpha-1, 2.4.3
>
>
> As discussed in HBASE-25706, we can introduce RegionSplitPointRestriction
> that restricts the pattern of the split point.
> See the following comment for the details:
> https://issues.apache.org/jira/browse/HBASE-25706?focusedCommentId=17310190=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17310190
> CC: [~zhangduo] [~stack]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (HBASE-25766) Introduce RegionSplitPointRestriction that restricts the pattern of the split point
[
https://issues.apache.org/jira/browse/HBASE-25766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Toshihiro Suzuki updated HBASE-25766:
-
Release Note:
After HBASE-25766, we can specify a split point restriction, "KeyPrefix" or
"DelimitedKeyPrefix", to a table with
"hbase.regionserver.region.split_point_restriction.type" property. The
"KeyPrefix" split point restriction groups rows by a prefix of the row-key. And
the "DelimitedKeyPrefix" split point restriction groups rows by a prefix of the
row-key with a delimiter.
For example:
```
# Create a table with a "KeyPrefix" split point restriction, where the prefix
length is 2 bytes
create 'tbl1', 'fam', {CONFIGURATION =>
{'hbase.regionserver.region.split_point_restriction.type' => 'KeyPrefix',
'hbase.regionserver.region.split_point_restriction.prefix_length' => '2'}}
# Create a table with a "DelimitedKeyPrefix" split point restriction, where the
delimiter is a comma (,)
create 'tbl2', 'fam', {CONFIGURATION =>
{'hbase.regionserver.region.split_point_restriction.type' =>
'DelimitedKeyPrefix',
'hbase.regionserver.region.split_point_restriction.delimiter' => ','}}
```
Instead of specifying a split point restriction to a table directly, we can
also set the properties in hbase-site.xml. In this case, the specified split
point restriction is applied for all the tables.
> Introduce RegionSplitPointRestriction that restricts the pattern of the split
> point
> ---
>
> Key: HBASE-25766
> URL: https://issues.apache.org/jira/browse/HBASE-25766
> Project: HBase
> Issue Type: Improvement
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Major
> Fix For: 3.0.0-alpha-1, 2.4.3
>
>
> As discussed in HBASE-25706, we can introduce RegionSplitPointRestriction
> that restricts the pattern of the split point.
> See the following comment for the details:
> https://issues.apache.org/jira/browse/HBASE-25706?focusedCommentId=17310190=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17310190
> CC: [~zhangduo] [~stack]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (HBASE-25706) Support specifying a base split policy class in KeyPrefixRegionSplitPolicy and DelimitedKeyPrefixRegionSplitPolicy
[ https://issues.apache.org/jira/browse/HBASE-25706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toshihiro Suzuki resolved HBASE-25706. -- Resolution: Won't Fix Closing this Jira and opened a new Jira HBASE-25766 to introduce RegionSplitPointRestriction. > Support specifying a base split policy class in KeyPrefixRegionSplitPolicy > and DelimitedKeyPrefixRegionSplitPolicy > -- > > Key: HBASE-25706 > URL: https://issues.apache.org/jira/browse/HBASE-25706 > Project: HBase > Issue Type: Improvement >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Major > > Basically, I think we can use KeyPrefixRegionSplitPolicy and > DelimitedKeyPrefixRegionSplitPolicy along with other split policies. In this > Jira, we will support specifying a base split policy class in > KeyPrefixRegionSplitPolicy and DelimitedKeyPrefixRegionSplitPolicy to use > them with different split policies. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (HBASE-25766) Introduce RegionSplitPointRestriction that restricts the pattern of the split point
Toshihiro Suzuki created HBASE-25766: Summary: Introduce RegionSplitPointRestriction that restricts the pattern of the split point Key: HBASE-25766 URL: https://issues.apache.org/jira/browse/HBASE-25766 Project: HBase Issue Type: Improvement Reporter: Toshihiro Suzuki Assignee: Toshihiro Suzuki Fix For: 3.0.0-alpha-1, 2.4.3 As discussed in HBASE-25706, we can introduce RegionSplitPointRestriction that restricts the pattern of the split point. See the following comment for the details: https://issues.apache.org/jira/browse/HBASE-25706?focusedCommentId=17310190=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17310190 CC: [~zhangduo] [~stack] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-25703) Support conditional update in MultiRowMutationEndpoint
[ https://issues.apache.org/jira/browse/HBASE-25703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17311549#comment-17311549 ] Toshihiro Suzuki commented on HBASE-25703: -- Pushed to branch-2 and branch-2.4. Thank you for reviewing this! [~stack] > Support conditional update in MultiRowMutationEndpoint > -- > > Key: HBASE-25703 > URL: https://issues.apache.org/jira/browse/HBASE-25703 > Project: HBase > Issue Type: Improvement > Components: Coprocessors >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Major > Fix For: 3.0.0-alpha-1, 2.5.0, 2.4.3 > > > In some use cases, I think it will be useful that we can perform conditional > update in MultiRowMutationEndpoint. In this Jira, we can add support > conditional update in MultiRowMutationEndpoint. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (HBASE-25703) Support conditional update in MultiRowMutationEndpoint
[ https://issues.apache.org/jira/browse/HBASE-25703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toshihiro Suzuki resolved HBASE-25703. -- Hadoop Flags: Reviewed Resolution: Fixed > Support conditional update in MultiRowMutationEndpoint > -- > > Key: HBASE-25703 > URL: https://issues.apache.org/jira/browse/HBASE-25703 > Project: HBase > Issue Type: Improvement > Components: Coprocessors >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Major > Fix For: 3.0.0-alpha-1, 2.5.0, 2.4.3 > > > In some use cases, I think it will be useful that we can perform conditional > update in MultiRowMutationEndpoint. In this Jira, we can add support > conditional update in MultiRowMutationEndpoint. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (HBASE-25703) Support conditional update in MultiRowMutationEndpoint
[ https://issues.apache.org/jira/browse/HBASE-25703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17311189#comment-17311189 ] Toshihiro Suzuki edited comment on HBASE-25703 at 3/30/21, 6:51 AM: Pushed to master, and created another PR for branch-2. was (Author: brfrn169): Pushed to master, and created a PR for branch-2. > Support conditional update in MultiRowMutationEndpoint > -- > > Key: HBASE-25703 > URL: https://issues.apache.org/jira/browse/HBASE-25703 > Project: HBase > Issue Type: Improvement > Components: Coprocessors >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Major > Fix For: 3.0.0-alpha-1, 2.5.0, 2.4.3 > > > In some use cases, I think it will be useful that we can perform conditional > update in MultiRowMutationEndpoint. In this Jira, we can add support > conditional update in MultiRowMutationEndpoint. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-25703) Support conditional update in MultiRowMutationEndpoint
[ https://issues.apache.org/jira/browse/HBASE-25703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17311189#comment-17311189 ] Toshihiro Suzuki commented on HBASE-25703: -- Pushed to master, and created a PR for branch-2. > Support conditional update in MultiRowMutationEndpoint > -- > > Key: HBASE-25703 > URL: https://issues.apache.org/jira/browse/HBASE-25703 > Project: HBase > Issue Type: Improvement > Components: Coprocessors >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Major > Fix For: 3.0.0-alpha-1, 2.5.0, 2.4.3 > > > In some use cases, I think it will be useful that we can perform conditional > update in MultiRowMutationEndpoint. In this Jira, we can add support > conditional update in MultiRowMutationEndpoint. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-25706) Support specifying a base split policy class in KeyPrefixRegionSplitPolicy and DelimitedKeyPrefixRegionSplitPolicy
[ https://issues.apache.org/jira/browse/HBASE-25706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17310311#comment-17310311 ] Toshihiro Suzuki commented on HBASE-25706: -- [~zhangduo] Thank you for reviewing this! Yes, it sounds like a better abstraction, and we should introduce the splitPointRestriction config rather than extend the existing KeyPrefixRegionSplitPolicy and DelimitedKeyPrefixRegionSplitPolicy. I will deprecate them, but can we keep the changes to use them along with other split policies until we introduce the splitPointRestriction config? What do you think? I don't think the changes break the original behavior. > Support specifying a base split policy class in KeyPrefixRegionSplitPolicy > and DelimitedKeyPrefixRegionSplitPolicy > -- > > Key: HBASE-25706 > URL: https://issues.apache.org/jira/browse/HBASE-25706 > Project: HBase > Issue Type: Improvement >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Major > > Basically, I think we can use KeyPrefixRegionSplitPolicy and > DelimitedKeyPrefixRegionSplitPolicy along with other split policies. In this > Jira, we will support specifying a base split policy class in > KeyPrefixRegionSplitPolicy and DelimitedKeyPrefixRegionSplitPolicy to use > them with different split policies. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-25706) Support specifying a base split policy class in KeyPrefixRegionSplitPolicy and DelimitedKeyPrefixRegionSplitPolicy
[ https://issues.apache.org/jira/browse/HBASE-25706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toshihiro Suzuki updated HBASE-25706: - Description: Basically, I think we can use KeyPrefixRegionSplitPolicy and DelimitedKeyPrefixRegionSplitPolicy along with other split policies. In this Jira, we will support specifying a base split policy class in KeyPrefixRegionSplitPolicy and DelimitedKeyPrefixRegionSplitPolicy to use them with different split policies. (was: Basically, I think we can use KeyPrefixRegionSplitPolicy along with other split policies. In this Jira, we will support specifying a base split policy class in KeyPrefixRegionSplitPolicy to use it with different split policies.) > Support specifying a base split policy class in KeyPrefixRegionSplitPolicy > and DelimitedKeyPrefixRegionSplitPolicy > -- > > Key: HBASE-25706 > URL: https://issues.apache.org/jira/browse/HBASE-25706 > Project: HBase > Issue Type: Improvement >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Major > > Basically, I think we can use KeyPrefixRegionSplitPolicy and > DelimitedKeyPrefixRegionSplitPolicy along with other split policies. In this > Jira, we will support specifying a base split policy class in > KeyPrefixRegionSplitPolicy and DelimitedKeyPrefixRegionSplitPolicy to use > them with different split policies. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-25706) Support specifying a base split policy class in KeyPrefixRegionSplitPolicy and DelimitedKeyPrefixRegionSplitPolicy
[ https://issues.apache.org/jira/browse/HBASE-25706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toshihiro Suzuki updated HBASE-25706: - Summary: Support specifying a base split policy class in KeyPrefixRegionSplitPolicy and DelimitedKeyPrefixRegionSplitPolicy (was: Support specifying a base split policy class in KeyPrefixRegionSplitPolicy to make it more useful) > Support specifying a base split policy class in KeyPrefixRegionSplitPolicy > and DelimitedKeyPrefixRegionSplitPolicy > -- > > Key: HBASE-25706 > URL: https://issues.apache.org/jira/browse/HBASE-25706 > Project: HBase > Issue Type: Improvement >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Major > > Basically, I think we can use KeyPrefixRegionSplitPolicy along with other > split policies. In this Jira, we will support specifying a base split policy > class in KeyPrefixRegionSplitPolicy to use it with different split policies. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (HBASE-25706) Support specifying a base split policy class in KeyPrefixRegionSplitPolicy to make it more useful
Toshihiro Suzuki created HBASE-25706: Summary: Support specifying a base split policy class in KeyPrefixRegionSplitPolicy to make it more useful Key: HBASE-25706 URL: https://issues.apache.org/jira/browse/HBASE-25706 Project: HBase Issue Type: Improvement Reporter: Toshihiro Suzuki Assignee: Toshihiro Suzuki Basically, I think we can use KeyPrefixRegionSplitPolicy along with other split policies. In this Jira, we will support specifying a base split policy class in KeyPrefixRegionSplitPolicy to use it with different split policies. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (HBASE-25702) Remove RowProcessor
[ https://issues.apache.org/jira/browse/HBASE-25702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toshihiro Suzuki resolved HBASE-25702. -- Hadoop Flags: Reviewed Resolution: Fixed > Remove RowProcessor > --- > > Key: HBASE-25702 > URL: https://issues.apache.org/jira/browse/HBASE-25702 > Project: HBase > Issue Type: Improvement >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Major > Fix For: 3.0.0-alpha-1 > > > As RowProcessor is deprecated, we can remove it in this Jira. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-25702) Remove RowProcessor
[ https://issues.apache.org/jira/browse/HBASE-25702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17310089#comment-17310089 ] Toshihiro Suzuki commented on HBASE-25702: -- Pushed to master. Thank you for taking a look at this! [~zhangduo] > Remove RowProcessor > --- > > Key: HBASE-25702 > URL: https://issues.apache.org/jira/browse/HBASE-25702 > Project: HBase > Issue Type: Improvement >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Major > Fix For: 3.0.0-alpha-1 > > > As RowProcessor is deprecated, we can remove it in this Jira. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (HBASE-25704) Support conditional update in MultiRowMutationEndpoint
[ https://issues.apache.org/jira/browse/HBASE-25704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toshihiro Suzuki resolved HBASE-25704. -- Resolution: Duplicate > Support conditional update in MultiRowMutationEndpoint > -- > > Key: HBASE-25704 > URL: https://issues.apache.org/jira/browse/HBASE-25704 > Project: HBase > Issue Type: Improvement > Components: Coprocessors >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Major > Fix For: 3.0.0-alpha-1, 2.5.0, 2.4.3 > > > In some use cases, I think it will be useful that we can perform conditional > update in MultiRowMutationEndpoint. In this Jira, we can add support > conditional update in MultiRowMutationEndpoint. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (HBASE-25703) Support conditional update in MultiRowMutationEndpoint
Toshihiro Suzuki created HBASE-25703: Summary: Support conditional update in MultiRowMutationEndpoint Key: HBASE-25703 URL: https://issues.apache.org/jira/browse/HBASE-25703 Project: HBase Issue Type: Improvement Components: Coprocessors Reporter: Toshihiro Suzuki Assignee: Toshihiro Suzuki Fix For: 3.0.0-alpha-1, 2.5.0, 2.4.3 In some use cases, I think it will be useful that we can perform conditional update in MultiRowMutationEndpoint. In this Jira, we can add support conditional update in MultiRowMutationEndpoint. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (HBASE-25704) Support conditional update in MultiRowMutationEndpoint
Toshihiro Suzuki created HBASE-25704: Summary: Support conditional update in MultiRowMutationEndpoint Key: HBASE-25704 URL: https://issues.apache.org/jira/browse/HBASE-25704 Project: HBase Issue Type: Improvement Components: Coprocessors Reporter: Toshihiro Suzuki Assignee: Toshihiro Suzuki Fix For: 3.0.0-alpha-1, 2.5.0, 2.4.3 In some use cases, I think it will be useful that we can perform conditional update in MultiRowMutationEndpoint. In this Jira, we can add support conditional update in MultiRowMutationEndpoint. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-25686) [hbtop] Add some javadoc
[ https://issues.apache.org/jira/browse/HBASE-25686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17309900#comment-17309900 ] Toshihiro Suzuki commented on HBASE-25686: -- Pushed to master, branch-2 and branch-1. Thank you for reviewing this! [~weichiu] > [hbtop] Add some javadoc > > > Key: HBASE-25686 > URL: https://issues.apache.org/jira/browse/HBASE-25686 > Project: HBase > Issue Type: Improvement > Components: hbtop >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Minor > Fix For: 3.0.0-alpha-1, 1.7.0, 2.5.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (HBASE-25686) [hbtop] Add some javadoc
[ https://issues.apache.org/jira/browse/HBASE-25686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toshihiro Suzuki resolved HBASE-25686. -- Hadoop Flags: Reviewed Resolution: Fixed > [hbtop] Add some javadoc > > > Key: HBASE-25686 > URL: https://issues.apache.org/jira/browse/HBASE-25686 > Project: HBase > Issue Type: Improvement > Components: hbtop >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Minor > Fix For: 3.0.0-alpha-1, 1.7.0, 2.5.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (HBASE-25702) Remove RowProcessor
Toshihiro Suzuki created HBASE-25702: Summary: Remove RowProcessor Key: HBASE-25702 URL: https://issues.apache.org/jira/browse/HBASE-25702 Project: HBase Issue Type: Improvement Reporter: Toshihiro Suzuki Assignee: Toshihiro Suzuki Fix For: 3.0.0-alpha-1 As RowProcessor is deprecated, we can remove it in this Jira. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (HBASE-25686) [hbtop] Add some javadoc
[ https://issues.apache.org/jira/browse/HBASE-25686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toshihiro Suzuki reassigned HBASE-25686: Assignee: Toshihiro Suzuki > [hbtop] Add some javadoc > > > Key: HBASE-25686 > URL: https://issues.apache.org/jira/browse/HBASE-25686 > Project: HBase > Issue Type: Improvement > Components: hbtop >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Minor > Fix For: 3.0.0-alpha-1, 1.7.0, 2.5.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (HBASE-25678) Support nonce operations for Increment/Append in RowMutations and CheckAndMutate
[ https://issues.apache.org/jira/browse/HBASE-25678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toshihiro Suzuki resolved HBASE-25678. -- Hadoop Flags: Reviewed Resolution: Fixed > Support nonce operations for Increment/Append in RowMutations and > CheckAndMutate > > > Key: HBASE-25678 > URL: https://issues.apache.org/jira/browse/HBASE-25678 > Project: HBase > Issue Type: Improvement >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Major > Fix For: 3.0.0-alpha-1, 2.5.0, 2.4.3 > > > Currently, we support nonce operations for single Increment/Append operations > but don't support for Increment/Append in RowMutations and CheckAndMutate. We > should support it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-25678) Support nonce operations for Increment/Append in RowMutations and CheckAndMutate
[ https://issues.apache.org/jira/browse/HBASE-25678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17305693#comment-17305693 ] Toshihiro Suzuki commented on HBASE-25678: -- Pushed to branch-2 and branch-2.4. Thank you for reviewing this! [~stack] > Support nonce operations for Increment/Append in RowMutations and > CheckAndMutate > > > Key: HBASE-25678 > URL: https://issues.apache.org/jira/browse/HBASE-25678 > Project: HBase > Issue Type: Improvement >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Major > Fix For: 3.0.0-alpha-1, 2.5.0, 2.4.3 > > > Currently, we support nonce operations for single Increment/Append operations > but don't support for Increment/Append in RowMutations and CheckAndMutate. We > should support it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-25686) [hbtop] Add some javadoc
[ https://issues.apache.org/jira/browse/HBASE-25686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toshihiro Suzuki updated HBASE-25686: - Fix Version/s: 1.7.0 > [hbtop] Add some javadoc > > > Key: HBASE-25686 > URL: https://issues.apache.org/jira/browse/HBASE-25686 > Project: HBase > Issue Type: Improvement > Components: hbtop >Reporter: Toshihiro Suzuki >Priority: Minor > Fix For: 3.0.0-alpha-1, 1.7.0, 2.5.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-25686) [hbtop] Add some javadoc
[ https://issues.apache.org/jira/browse/HBASE-25686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toshihiro Suzuki updated HBASE-25686: - Fix Version/s: 2.5.0 3.0.0-alpha-1 > [hbtop] Add some javadoc > > > Key: HBASE-25686 > URL: https://issues.apache.org/jira/browse/HBASE-25686 > Project: HBase > Issue Type: Improvement > Components: hbtop >Reporter: Toshihiro Suzuki >Priority: Minor > Fix For: 3.0.0-alpha-1, 2.5.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-25686) [hbtop] Add some javadoc
[ https://issues.apache.org/jira/browse/HBASE-25686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toshihiro Suzuki updated HBASE-25686: - Priority: Minor (was: Major) > [hbtop] Add some javadoc > > > Key: HBASE-25686 > URL: https://issues.apache.org/jira/browse/HBASE-25686 > Project: HBase > Issue Type: Improvement > Components: hbtop >Reporter: Toshihiro Suzuki >Priority: Minor > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-25576) Should not use a byte array as a key of HashMap or an element of HashSet
[
https://issues.apache.org/jira/browse/HBASE-25576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17305581#comment-17305581
]
Toshihiro Suzuki commented on HBASE-25576:
--
[~swaroopa] Thank you for your interest in this!
I just modified the description and added one example there to make it clearer.
If it's still unclear, please let me know.
> Should not use a byte array as a key of HashMap or an element of HashSet
>
>
> Key: HBASE-25576
> URL: https://issues.apache.org/jira/browse/HBASE-25576
> Project: HBase
> Issue Type: Bug
>Reporter: Toshihiro Suzuki
>Assignee: Swaroopa Kadam
>Priority: Major
> Labels: beginner
>
> I sometimes face the code where we use a byte array as a key of HashMap
> (ConcurrentHashMap) or an element of HashSet, which could cause very
> confusing bugs.
> The following code is an example where we use a byte array as a key of
> HashMap:
> https://github.com/apache/hbase/blob/326835e8372cc83092e0ec127650438ff153476a/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/wal/SequenceIdAccounting.java#L94
> In Java, we can't use a byte array as a key of HashMap or an element of
> HashSet directly. One solution for it is to use TreeMap
> (ConcurrentSkipListMap) or TreeSet (ConcurrentSkipListSet) with
> Bytes.BYTES_COMPARATOR instead of HashMap and HashSet as follows:
> {code}
> Map map1 = new TreeMap<>(Bytes.BYTES_COMPARATOR);
> Map map2 = new
> ConcurrentSkipListMap<>(Bytes.BYTES_COMPARATOR);
> Set set1 = new TreeSet<>(Bytes.BYTES_COMPARATOR);
> Set set2 = new ConcurrentSkipListSet<>(Bytes.BYTES_COMPARATOR);
> {code}
> We should fix the existing ones in this Jira.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (HBASE-25576) Should not use a byte array as a key of HashMap or an element of HashSet
[
https://issues.apache.org/jira/browse/HBASE-25576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Toshihiro Suzuki updated HBASE-25576:
-
Summary: Should not use a byte array as a key of HashMap or an element of
HashSet (was: Should not use HashMap (ConcurrentHashMap) or HashSet when using
byte[] as a key of Map or an element of Set)
> Should not use a byte array as a key of HashMap or an element of HashSet
>
>
> Key: HBASE-25576
> URL: https://issues.apache.org/jira/browse/HBASE-25576
> Project: HBase
> Issue Type: Bug
>Reporter: Toshihiro Suzuki
>Assignee: Swaroopa Kadam
>Priority: Major
> Labels: beginner
>
> I sometimes face the code using HashMap (ConcurrentHashMap) or HashSet when
> using byte[] as a key of Map or an element of Set in the HBase code, which
> could cause very confusing bugs.
> We should use TreeMap (ConcurrentSkipListMap) or TreeSet
> (ConcurrentSkipListSet) with Bytes.BYTES_COMPARATOR when using byte[] as a
> key of Map or an element of Set as follows:
> {code}
> Map map1 = new TreeMap<>(Bytes.BYTES_COMPARATOR);
> Map map2 = new
> ConcurrentSkipListMap<>(Bytes.BYTES_COMPARATOR);
> Set set1 = new TreeSet<>(Bytes.BYTES_COMPARATOR);
> Set set2 = new ConcurrentSkipListSet<>(Bytes.BYTES_COMPARATOR);
> {code}
> We should fix the existing ones in this Jira.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (HBASE-25576) Should not use a byte array as a key of HashMap or an element of HashSet
[
https://issues.apache.org/jira/browse/HBASE-25576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Toshihiro Suzuki updated HBASE-25576:
-
Description:
I sometimes face the code where we use a byte array as a key of HashMap
(ConcurrentHashMap) or an element of HashSet, which could cause very confusing
bugs.
The following code is an example where we use a byte array as a key of HashMap:
https://github.com/apache/hbase/blob/326835e8372cc83092e0ec127650438ff153476a/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/wal/SequenceIdAccounting.java#L94
In Java, we can't use a byte array as a key of HashMap or an element of HashSet
directly. One solution for it is to use TreeMap (ConcurrentSkipListMap) or
TreeSet (ConcurrentSkipListSet) with Bytes.BYTES_COMPARATOR instead of HashMap
and HashSet as follows:
{code}
Map map1 = new TreeMap<>(Bytes.BYTES_COMPARATOR);
Map map2 = new ConcurrentSkipListMap<>(Bytes.BYTES_COMPARATOR);
Set set1 = new TreeSet<>(Bytes.BYTES_COMPARATOR);
Set set2 = new ConcurrentSkipListSet<>(Bytes.BYTES_COMPARATOR);
{code}
We should fix the existing ones in this Jira.
was:
I sometimes face the code using HashMap (ConcurrentHashMap) or HashSet when
using byte[] as a key of Map or an element of Set in the HBase code, which
could cause very confusing bugs.
We should use TreeMap (ConcurrentSkipListMap) or TreeSet
(ConcurrentSkipListSet) with Bytes.BYTES_COMPARATOR when using byte[] as a key
of Map or an element of Set as follows:
{code}
Map map1 = new TreeMap<>(Bytes.BYTES_COMPARATOR);
Map map2 = new ConcurrentSkipListMap<>(Bytes.BYTES_COMPARATOR);
Set set1 = new TreeSet<>(Bytes.BYTES_COMPARATOR);
Set set2 = new ConcurrentSkipListSet<>(Bytes.BYTES_COMPARATOR);
{code}
We should fix the existing ones in this Jira.
> Should not use a byte array as a key of HashMap or an element of HashSet
>
>
> Key: HBASE-25576
> URL: https://issues.apache.org/jira/browse/HBASE-25576
> Project: HBase
> Issue Type: Bug
>Reporter: Toshihiro Suzuki
>Assignee: Swaroopa Kadam
>Priority: Major
> Labels: beginner
>
> I sometimes face the code where we use a byte array as a key of HashMap
> (ConcurrentHashMap) or an element of HashSet, which could cause very
> confusing bugs.
> The following code is an example where we use a byte array as a key of
> HashMap:
> https://github.com/apache/hbase/blob/326835e8372cc83092e0ec127650438ff153476a/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/wal/SequenceIdAccounting.java#L94
> In Java, we can't use a byte array as a key of HashMap or an element of
> HashSet directly. One solution for it is to use TreeMap
> (ConcurrentSkipListMap) or TreeSet (ConcurrentSkipListSet) with
> Bytes.BYTES_COMPARATOR instead of HashMap and HashSet as follows:
> {code}
> Map map1 = new TreeMap<>(Bytes.BYTES_COMPARATOR);
> Map map2 = new
> ConcurrentSkipListMap<>(Bytes.BYTES_COMPARATOR);
> Set set1 = new TreeSet<>(Bytes.BYTES_COMPARATOR);
> Set set2 = new ConcurrentSkipListSet<>(Bytes.BYTES_COMPARATOR);
> {code}
> We should fix the existing ones in this Jira.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (HBASE-25686) [hbtop] Add some javadoc
Toshihiro Suzuki created HBASE-25686: Summary: [hbtop] Add some javadoc Key: HBASE-25686 URL: https://issues.apache.org/jira/browse/HBASE-25686 Project: HBase Issue Type: Improvement Components: hbtop Reporter: Toshihiro Suzuki -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (HBASE-25258) Backport HBASE-24776 "[hbtop] Support Batch mode" to branch-1
[ https://issues.apache.org/jira/browse/HBASE-25258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toshihiro Suzuki resolved HBASE-25258. -- Fix Version/s: 1.7.0 Hadoop Flags: Reviewed Resolution: Fixed > Backport HBASE-24776 "[hbtop] Support Batch mode" to branch-1 > - > > Key: HBASE-25258 > URL: https://issues.apache.org/jira/browse/HBASE-25258 > Project: HBase > Issue Type: Sub-task >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Major > Fix For: 1.7.0 > > > Backport parent issue to branch-1. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-25258) Backport HBASE-24776 "[hbtop] Support Batch mode" to branch-1
[ https://issues.apache.org/jira/browse/HBASE-25258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17305279#comment-17305279 ] Toshihiro Suzuki commented on HBASE-25258: -- Pushed to branch-1. Thank you for reviewing this! [~stack] > Backport HBASE-24776 "[hbtop] Support Batch mode" to branch-1 > - > > Key: HBASE-25258 > URL: https://issues.apache.org/jira/browse/HBASE-25258 > Project: HBase > Issue Type: Sub-task >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Major > > Backport parent issue to branch-1. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-25678) Support nonce operations for Increment/Append in RowMutations and CheckAndMutate
[ https://issues.apache.org/jira/browse/HBASE-25678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17305266#comment-17305266 ] Toshihiro Suzuki commented on HBASE-25678: -- Pushed to master. I will create a PR for branch-2. > Support nonce operations for Increment/Append in RowMutations and > CheckAndMutate > > > Key: HBASE-25678 > URL: https://issues.apache.org/jira/browse/HBASE-25678 > Project: HBase > Issue Type: Improvement >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Major > Fix For: 3.0.0-alpha-1, 2.5.0, 2.4.3 > > > Currently, we support nonce operations for single Increment/Append operations > but don't support for Increment/Append in RowMutations and CheckAndMutate. We > should support it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-25678) Support nonce operations for Increment/Append in RowMutations and CheckAndMutate
[ https://issues.apache.org/jira/browse/HBASE-25678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toshihiro Suzuki updated HBASE-25678: - Fix Version/s: 2.5.0 > Support nonce operations for Increment/Append in RowMutations and > CheckAndMutate > > > Key: HBASE-25678 > URL: https://issues.apache.org/jira/browse/HBASE-25678 > Project: HBase > Issue Type: Improvement >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Major > Fix For: 3.0.0-alpha-1, 2.5.0, 2.4.3 > > > Currently, we support nonce operations for single Increment/Append operations > but don't support for Increment/Append in RowMutations and CheckAndMutate. We > should support it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (HBASE-25678) Support nonce operations for Increment/Append in RowMutations and CheckAndMutate
Toshihiro Suzuki created HBASE-25678: Summary: Support nonce operations for Increment/Append in RowMutations and CheckAndMutate Key: HBASE-25678 URL: https://issues.apache.org/jira/browse/HBASE-25678 Project: HBase Issue Type: Improvement Reporter: Toshihiro Suzuki Assignee: Toshihiro Suzuki Fix For: 3.0.0-alpha-1, 2.4.3 Currently, we support nonce operations for single Increment/Append operations but don't support for Increment/Append in RowMutations and CheckAndMutate. We should support it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (HBASE-25575) Should validate Puts in RowMutations
[ https://issues.apache.org/jira/browse/HBASE-25575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toshihiro Suzuki resolved HBASE-25575. -- Hadoop Flags: Reviewed Resolution: Fixed > Should validate Puts in RowMutations > > > Key: HBASE-25575 > URL: https://issues.apache.org/jira/browse/HBASE-25575 > Project: HBase > Issue Type: Bug > Components: Client >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Minor > Fix For: 3.0.0-alpha-1, 2.5.0, 2.4.2 > > > Currently, we don't validate the key value sizes of Puts in RowMutations. We > should do that. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-25575) Should validate Puts in RowMutations
[ https://issues.apache.org/jira/browse/HBASE-25575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17288129#comment-17288129 ] Toshihiro Suzuki commented on HBASE-25575: -- Pushed to master, branch-2 and branch-2.4. [~zhangduo] [~vjasani] Thank you for reviewing this! > Should validate Puts in RowMutations > > > Key: HBASE-25575 > URL: https://issues.apache.org/jira/browse/HBASE-25575 > Project: HBase > Issue Type: Bug > Components: Client >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Minor > Fix For: 3.0.0-alpha-1, 2.5.0, 2.4.2 > > > Currently, we don't validate the key value sizes of Puts in RowMutations. We > should do that. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-25574) Revisit put/delete/increment/append related RegionObserver methods
[ https://issues.apache.org/jira/browse/HBASE-25574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17288122#comment-17288122 ] Toshihiro Suzuki commented on HBASE-25574: -- Pushed to master, branch-2 and branch-2.4. [~zhangduo] Thank you for reviewing this! > Revisit put/delete/increment/append related RegionObserver methods > -- > > Key: HBASE-25574 > URL: https://issues.apache.org/jira/browse/HBASE-25574 > Project: HBase > Issue Type: Improvement > Components: Coprocessors >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Major > Fix For: 3.0.0-alpha-1, 2.5.0, 2.4.2 > > > After HBASE-24602, increment/append operations are performed in > HRegion.batchMutate(). Accordingly, we should make some changes for the > increment/append related RegionObserver methods. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (HBASE-25574) Revisit put/delete/increment/append related RegionObserver methods
[ https://issues.apache.org/jira/browse/HBASE-25574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toshihiro Suzuki resolved HBASE-25574. -- Hadoop Flags: Reviewed Resolution: Fixed > Revisit put/delete/increment/append related RegionObserver methods > -- > > Key: HBASE-25574 > URL: https://issues.apache.org/jira/browse/HBASE-25574 > Project: HBase > Issue Type: Improvement > Components: Coprocessors >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Major > Fix For: 3.0.0-alpha-1, 2.5.0, 2.4.2 > > > After HBASE-24602, increment/append operations are performed in > HRegion.batchMutate(). Accordingly, we should make some changes for the > increment/append related RegionObserver methods. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-25575) Should validate Puts in RowMutations
[ https://issues.apache.org/jira/browse/HBASE-25575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toshihiro Suzuki updated HBASE-25575: - Fix Version/s: 2.5.0 > Should validate Puts in RowMutations > > > Key: HBASE-25575 > URL: https://issues.apache.org/jira/browse/HBASE-25575 > Project: HBase > Issue Type: Bug > Components: Client >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Minor > Fix For: 3.0.0-alpha-1, 2.5.0, 2.4.2 > > > Currently, we don't validate the key value sizes of Puts in RowMutations. We > should do that. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-25574) Revisit put/delete/increment/append related RegionObserver methods
[ https://issues.apache.org/jira/browse/HBASE-25574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toshihiro Suzuki updated HBASE-25574: - Fix Version/s: 2.5.0 > Revisit put/delete/increment/append related RegionObserver methods > -- > > Key: HBASE-25574 > URL: https://issues.apache.org/jira/browse/HBASE-25574 > Project: HBase > Issue Type: Improvement > Components: Coprocessors >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Major > Fix For: 3.0.0-alpha-1, 2.5.0, 2.4.2 > > > After HBASE-24602, increment/append operations are performed in > HRegion.batchMutate(). Accordingly, we should make some changes for the > increment/append related RegionObserver methods. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-25574) Revisit put/delete/increment/append related RegionObserver methods
[ https://issues.apache.org/jira/browse/HBASE-25574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toshihiro Suzuki updated HBASE-25574: - Summary: Revisit put/delete/increment/append related RegionObserver methods (was: Revisit increment/append related RegionObserver methods) > Revisit put/delete/increment/append related RegionObserver methods > -- > > Key: HBASE-25574 > URL: https://issues.apache.org/jira/browse/HBASE-25574 > Project: HBase > Issue Type: Improvement > Components: Coprocessors >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Major > Fix For: 3.0.0-alpha-1, 2.4.2 > > > After HBASE-24602, increment/append operations are performed in > HRegion.batchMutate(). Accordingly, we should make some changes for the > increment/append related RegionObserver methods. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-25575) Should validate Puts in RowMutations
[ https://issues.apache.org/jira/browse/HBASE-25575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toshihiro Suzuki updated HBASE-25575: - Description: Currently, we don't validate the key value sizes of Puts in RowMutations. We should do that. (was: Currently, we don't validate Puts in RowMutations. We should do that.) > Should validate Puts in RowMutations > > > Key: HBASE-25575 > URL: https://issues.apache.org/jira/browse/HBASE-25575 > Project: HBase > Issue Type: Bug > Components: Client >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Minor > Fix For: 3.0.0-alpha-1, 2.4.2 > > > Currently, we don't validate the key value sizes of Puts in RowMutations. We > should do that. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (HBASE-25576) Should not use HashMap (ConcurrentHashMap) or HashSet when using byte[] as a key of Map or an element of Set
Toshihiro Suzuki created HBASE-25576:
Summary: Should not use HashMap (ConcurrentHashMap) or HashSet
when using byte[] as a key of Map or an element of Set
Key: HBASE-25576
URL: https://issues.apache.org/jira/browse/HBASE-25576
Project: HBase
Issue Type: Bug
Reporter: Toshihiro Suzuki
I sometimes face the code using HashMap (ConcurrentHashMap) or HashSet when
using byte[] as a key of Map or an element of Set in the HBase code, which
could cause very confusing bugs.
We should use TreeMap (ConcurrentSkipListMap) or TreeSet
(ConcurrentSkipListSet) with Bytes.BYTES_COMPARATOR when using byte[] as a key
of Map or an element of Set as follows:
{code}
Map map1 = new TreeMap<>(Bytes.BYTES_COMPARATOR);
Map map2 = new ConcurrentSkipListMap<>(Bytes.BYTES_COMPARATOR);
Set set1 = new TreeSet<>(Bytes.BYTES_COMPARATOR);
Set set2 = new ConcurrentSkipListSet<>(Bytes.BYTES_COMPARATOR);
{code}
We should fix the existing ones in this Jira.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (HBASE-25575) Should validate Puts in RowMutations
[ https://issues.apache.org/jira/browse/HBASE-25575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toshihiro Suzuki updated HBASE-25575: - Component/s: Client > Should validate Puts in RowMutations > > > Key: HBASE-25575 > URL: https://issues.apache.org/jira/browse/HBASE-25575 > Project: HBase > Issue Type: Bug > Components: Client >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Minor > Fix For: 3.0.0-alpha-1, 2.4.2 > > > Currently, we don't validate Puts in RowMutations. We should do that. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (HBASE-25575) Should validate Puts in RowMutations
Toshihiro Suzuki created HBASE-25575: Summary: Should validate Puts in RowMutations Key: HBASE-25575 URL: https://issues.apache.org/jira/browse/HBASE-25575 Project: HBase Issue Type: Bug Reporter: Toshihiro Suzuki Assignee: Toshihiro Suzuki Currently, we don't validate Puts in RowMutations. We should do that. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-25575) Should validate Puts in RowMutations
[ https://issues.apache.org/jira/browse/HBASE-25575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toshihiro Suzuki updated HBASE-25575: - Fix Version/s: 2.4.2 3.0.0-alpha-1 > Should validate Puts in RowMutations > > > Key: HBASE-25575 > URL: https://issues.apache.org/jira/browse/HBASE-25575 > Project: HBase > Issue Type: Bug >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Minor > Fix For: 3.0.0-alpha-1, 2.4.2 > > > Currently, we don't validate Puts in RowMutations. We should do that. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (HBASE-25574) Revisit increment/append related RegionObserver methods
Toshihiro Suzuki created HBASE-25574: Summary: Revisit increment/append related RegionObserver methods Key: HBASE-25574 URL: https://issues.apache.org/jira/browse/HBASE-25574 Project: HBase Issue Type: Improvement Components: Coprocessors Reporter: Toshihiro Suzuki Assignee: Toshihiro Suzuki Fix For: 3.0.0-alpha-1, 2.4.2 After HBASE-24602, increment/append operations are performed in HRegion.batchMutate(). Accordingly, we should make some changes for the increment/append related RegionObserver methods. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-25242) Add Increment/Append support to RowMutations
[ https://issues.apache.org/jira/browse/HBASE-25242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toshihiro Suzuki updated HBASE-25242: - Hadoop Flags: Incompatible change,Reviewed Release Note: After HBASE-25242, we can add Increment/Append operations to RowMutations and perform those operations atomically in a single row. HBASE-25242 includes an API change where the mutateRow() API returns a Result object to get the result of the Increment/Append operations. Resolution: Fixed Status: Resolved (was: Patch Available) > Add Increment/Append support to RowMutations > > > Key: HBASE-25242 > URL: https://issues.apache.org/jira/browse/HBASE-25242 > Project: HBase > Issue Type: New Feature > Components: Client, regionserver >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Critical > Fix For: 3.0.0-alpha-1, 2.4.0 > > > Currently, RowMutations supports only Put and Delete. Supporting > Increment/Append in RowMutations would be helpful for some use cases. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-25242) Add Increment/Append support to RowMutations
[ https://issues.apache.org/jira/browse/HBASE-25242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17239386#comment-17239386 ] Toshihiro Suzuki commented on HBASE-25242: -- Pushed to branch-2, too. Thank you for reviewing this! [~zhangduo] [~apurtell] > Add Increment/Append support to RowMutations > > > Key: HBASE-25242 > URL: https://issues.apache.org/jira/browse/HBASE-25242 > Project: HBase > Issue Type: New Feature > Components: Client, regionserver >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Critical > Fix For: 3.0.0-alpha-1, 2.4.0 > > > Currently, RowMutations supports only Put and Delete. Supporting > Increment/Append in RowMutations would be helpful for some use cases. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-25242) Add Increment/Append support to RowMutations
[ https://issues.apache.org/jira/browse/HBASE-25242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17239102#comment-17239102 ] Toshihiro Suzuki commented on HBASE-25242: -- Pushed to master. And I created a PR for branch-2. If its QA is okay, I will push to branch-2, too. > Add Increment/Append support to RowMutations > > > Key: HBASE-25242 > URL: https://issues.apache.org/jira/browse/HBASE-25242 > Project: HBase > Issue Type: New Feature > Components: Client, regionserver >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Critical > Fix For: 3.0.0-alpha-1, 2.4.0 > > > Currently, RowMutations supports only Put and Delete. Supporting > Increment/Append in RowMutations would be helpful for some use cases. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (HBASE-25258) Backport HBASE-24776 "[hbtop] Support Batch mode" to branch-1
Toshihiro Suzuki created HBASE-25258: Summary: Backport HBASE-24776 "[hbtop] Support Batch mode" to branch-1 Key: HBASE-25258 URL: https://issues.apache.org/jira/browse/HBASE-25258 Project: HBase Issue Type: Sub-task Reporter: Toshihiro Suzuki Assignee: Toshihiro Suzuki Backport parent issue to branch-1. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (HBASE-25242) Add Increment/Append support to RowMutations
Toshihiro Suzuki created HBASE-25242: Summary: Add Increment/Append support to RowMutations Key: HBASE-25242 URL: https://issues.apache.org/jira/browse/HBASE-25242 Project: HBase Issue Type: New Feature Reporter: Toshihiro Suzuki Assignee: Toshihiro Suzuki Fix For: 3.0.0-alpha-1, 2.4.0 Currently, RowMutations supports only Put and Delete. Supporting Increment/Append in RowMutations would be helpful for some use cases. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-24210) Add Increment, Append and CheckAndMutate support to RowMutations
[ https://issues.apache.org/jira/browse/HBASE-24210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17225851#comment-17225851 ] Toshihiro Suzuki commented on HBASE-24210: -- It looks like this change will make things too complicated and it has big side effects and incompatible changes. So I will give it up. Closing it as Won't Fix. > Add Increment, Append and CheckAndMutate support to RowMutations > > > Key: HBASE-24210 > URL: https://issues.apache.org/jira/browse/HBASE-24210 > Project: HBase > Issue Type: New Feature >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Major > Fix For: 3.0.0-alpha-1, 2.4.0 > > > Currently, RowMutations supports only Put and Delete. Supporting Increment, > Append and CheckAndMutate in RowMutations would be helpful for some use cases. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-24996) Support CheckAndMutate in Region.batchMutate()
[ https://issues.apache.org/jira/browse/HBASE-24996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17225850#comment-17225850 ] Toshihiro Suzuki commented on HBASE-24996: -- It looks like this change will make things too complicated and it has big side effects and incompatible changes. So I will give it up. Closing it as Won't Fix. > Support CheckAndMutate in Region.batchMutate() > -- > > Key: HBASE-24996 > URL: https://issues.apache.org/jira/browse/HBASE-24996 > Project: HBase > Issue Type: Sub-task >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Major > Fix For: 3.0.0-alpha-1, 2.4.0 > > > After HBASE-24602, Region.batchMutate() supports Put/Delete/Increment/Append > operations, but it doesn't support CheckAndMutate. If we support > CheckAndMutate Region.batchMutate(), we can perform > Put/Delete/Increment/Append/CheckAndMutate operations atomically, which is > very useful for some cases. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (HBASE-24210) Add Increment, Append and CheckAndMutate support to RowMutations
[ https://issues.apache.org/jira/browse/HBASE-24210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toshihiro Suzuki resolved HBASE-24210. -- Resolution: Won't Fix > Add Increment, Append and CheckAndMutate support to RowMutations > > > Key: HBASE-24210 > URL: https://issues.apache.org/jira/browse/HBASE-24210 > Project: HBase > Issue Type: New Feature >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Major > Fix For: 3.0.0-alpha-1, 2.4.0 > > > Currently, RowMutations supports only Put and Delete. Supporting Increment, > Append and CheckAndMutate in RowMutations would be helpful for some use cases. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (HBASE-24996) Support CheckAndMutate in Region.batchMutate()
[ https://issues.apache.org/jira/browse/HBASE-24996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toshihiro Suzuki resolved HBASE-24996. -- Resolution: Won't Fix > Support CheckAndMutate in Region.batchMutate() > -- > > Key: HBASE-24996 > URL: https://issues.apache.org/jira/browse/HBASE-24996 > Project: HBase > Issue Type: Sub-task >Reporter: Toshihiro Suzuki >Assignee: Toshihiro Suzuki >Priority: Major > Fix For: 3.0.0-alpha-1, 2.4.0 > > > After HBASE-24602, Region.batchMutate() supports Put/Delete/Increment/Append > operations, but it doesn't support CheckAndMutate. If we support > CheckAndMutate Region.batchMutate(), we can perform > Put/Delete/Increment/Append/CheckAndMutate operations atomically, which is > very useful for some cases. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (HBASE-25206) Data loss can happen if a cloned table loses original split region(delete table)
[
https://issues.apache.org/jira/browse/HBASE-25206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220210#comment-17220210
]
Toshihiro Suzuki edited comment on HBASE-25206 at 10/24/20, 11:19 PM:
--
{quote}
So even if snapshot cloned to new table or not, this case will cause data loss
from snapshot.
{quote}
[~anoop.hbase] Yes, this will happen even if snapshot cloned to new table or
not.
was (Author: brfrn169):
[~anoop.hbase] Yes, this will happen even if snapshot cloned to new table or
not.
> Data loss can happen if a cloned table loses original split region(delete
> table)
>
>
> Key: HBASE-25206
> URL: https://issues.apache.org/jira/browse/HBASE-25206
> Project: HBase
> Issue Type: Bug
> Components: proc-v2, Region Assignment, snapshots
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Major
> Fix For: 3.0.0-alpha-1, 2.3.3, 2.4.0, 2.2.7
>
>
> Steps to reproduce are as follows:
> 1. Create a table and put some data into the table:
> {code:java}
> create 'test1','cf'
> put 'test1','r1','cf','v1'
> put 'test1','r2','cf','v2'
> put 'test1','r3','cf','v3'
> put 'test1','r4','cf','v4'
> put 'test1','r5','cf','v5'
> {code}
> 2. Take a snapshot for the table:
> {code:java}
> snapshot 'test1','snap_test'
> {code}
> 3. Clone the snapshot to another table
> {code:java}
> clone_snapshot 'snap_test','test2'
> {code}
> 4. Split the original table
> {code:java}
> split 'test1','r3'
> {code}
> 5. Drop the original table
> {code:java}
> disable 'test1'
> drop 'test1'
> {code}
> After that, we see the error like the following in RS log when opening the
> regions of the cloned table:
> {code:java}
> 2020-10-20 13:32:18,415 WARN org.apache.hadoop.hbase.regionserver.HRegion:
> Failed initialize of region=
> test2,,1603200595702.bebdc4f740626206eeccad96b7643261., starting to roll back
> memstore
> java.io.IOException: java.io.IOException: java.io.FileNotFoundException:
> Unable to open link: org.apache.hadoop.hbase.io.HFileLink
> locations=[hdfs:// HOST>:8020/hbase/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89,
> hdfs:// HOST>:8020/hbase/.tmp/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89,
> hdfs:// HOST>:8020/hbase/mobdir/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89,
> hdfs:// HOST>:8020/hbase/archive/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89]
> at
> org.apache.hadoop.hbase.regionserver.HRegion.initializeStores(HRegion.java:1095)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.initializeRegionInternals(HRegion.java:943)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.initialize(HRegion.java:899)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:7246)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:7204)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:7176)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:7134)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:7085)
> at
> org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler.openRegion(OpenRegionHandler.java:283)
> at
> org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler.process(OpenRegionHandler.java:108)
> at
> org.apache.hadoop.hbase.executor.EventHandler.run(EventHandler.java:104)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.io.IOException: java.io.FileNotFoundException: Unable to open
> link: org.apache.hadoop.hbase.io.HFileLink locations=[hdfs:// HOST>:8020/hbase/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89,
> hdfs:// HOST>:8020/hbase/.tmp/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89,
> hdfs:// HOST>:8020/hbase/mobdir/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89,
> hdfs:// HOST>:8020/hbase/archive/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89]
> at
> org.apache.hadoop.hbase.regionserver.HStore.openStoreFiles(HStore.java:590)
> at
> org.apache.hadoop.hbase.regionserver.HStore.loadStoreFiles(HStore.java:557)
> at org.apache.hadoop.hbase.regionserver.HStore.(HStore.java:303)
> at
>
[jira] [Commented] (HBASE-25206) Data loss can happen if a cloned table loses original split region(delete table)
[
https://issues.apache.org/jira/browse/HBASE-25206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220211#comment-17220211
]
Toshihiro Suzuki commented on HBASE-25206:
--
[~zhangduo] Thank you for reviewing and committing this!
> Data loss can happen if a cloned table loses original split region(delete
> table)
>
>
> Key: HBASE-25206
> URL: https://issues.apache.org/jira/browse/HBASE-25206
> Project: HBase
> Issue Type: Bug
> Components: proc-v2, Region Assignment, snapshots
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Major
> Fix For: 3.0.0-alpha-1, 2.3.3, 2.4.0, 2.2.7
>
>
> Steps to reproduce are as follows:
> 1. Create a table and put some data into the table:
> {code:java}
> create 'test1','cf'
> put 'test1','r1','cf','v1'
> put 'test1','r2','cf','v2'
> put 'test1','r3','cf','v3'
> put 'test1','r4','cf','v4'
> put 'test1','r5','cf','v5'
> {code}
> 2. Take a snapshot for the table:
> {code:java}
> snapshot 'test1','snap_test'
> {code}
> 3. Clone the snapshot to another table
> {code:java}
> clone_snapshot 'snap_test','test2'
> {code}
> 4. Split the original table
> {code:java}
> split 'test1','r3'
> {code}
> 5. Drop the original table
> {code:java}
> disable 'test1'
> drop 'test1'
> {code}
> After that, we see the error like the following in RS log when opening the
> regions of the cloned table:
> {code:java}
> 2020-10-20 13:32:18,415 WARN org.apache.hadoop.hbase.regionserver.HRegion:
> Failed initialize of region=
> test2,,1603200595702.bebdc4f740626206eeccad96b7643261., starting to roll back
> memstore
> java.io.IOException: java.io.IOException: java.io.FileNotFoundException:
> Unable to open link: org.apache.hadoop.hbase.io.HFileLink
> locations=[hdfs:// HOST>:8020/hbase/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89,
> hdfs:// HOST>:8020/hbase/.tmp/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89,
> hdfs:// HOST>:8020/hbase/mobdir/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89,
> hdfs:// HOST>:8020/hbase/archive/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89]
> at
> org.apache.hadoop.hbase.regionserver.HRegion.initializeStores(HRegion.java:1095)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.initializeRegionInternals(HRegion.java:943)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.initialize(HRegion.java:899)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:7246)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:7204)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:7176)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:7134)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:7085)
> at
> org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler.openRegion(OpenRegionHandler.java:283)
> at
> org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler.process(OpenRegionHandler.java:108)
> at
> org.apache.hadoop.hbase.executor.EventHandler.run(EventHandler.java:104)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.io.IOException: java.io.FileNotFoundException: Unable to open
> link: org.apache.hadoop.hbase.io.HFileLink locations=[hdfs:// HOST>:8020/hbase/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89,
> hdfs:// HOST>:8020/hbase/.tmp/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89,
> hdfs:// HOST>:8020/hbase/mobdir/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89,
> hdfs:// HOST>:8020/hbase/archive/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89]
> at
> org.apache.hadoop.hbase.regionserver.HStore.openStoreFiles(HStore.java:590)
> at
> org.apache.hadoop.hbase.regionserver.HStore.loadStoreFiles(HStore.java:557)
> at org.apache.hadoop.hbase.regionserver.HStore.(HStore.java:303)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.instantiateHStore(HRegion.java:5731)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$1.call(HRegion.java:1059)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$1.call(HRegion.java:1056)
> at
[jira] [Comment Edited] (HBASE-25206) Data loss can happen if a cloned table loses original split region(delete table)
[
https://issues.apache.org/jira/browse/HBASE-25206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220210#comment-17220210
]
Toshihiro Suzuki edited comment on HBASE-25206 at 10/24/20, 11:18 PM:
--
[~anoop.hbase] Yes, this will happen even if snapshot cloned to new table or
not.
was (Author: brfrn169):
[~anoop.hbase] Yes, This will happen even if snapshot cloned to new table or
not.
> Data loss can happen if a cloned table loses original split region(delete
> table)
>
>
> Key: HBASE-25206
> URL: https://issues.apache.org/jira/browse/HBASE-25206
> Project: HBase
> Issue Type: Bug
> Components: proc-v2, Region Assignment, snapshots
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Major
> Fix For: 3.0.0-alpha-1, 2.3.3, 2.4.0, 2.2.7
>
>
> Steps to reproduce are as follows:
> 1. Create a table and put some data into the table:
> {code:java}
> create 'test1','cf'
> put 'test1','r1','cf','v1'
> put 'test1','r2','cf','v2'
> put 'test1','r3','cf','v3'
> put 'test1','r4','cf','v4'
> put 'test1','r5','cf','v5'
> {code}
> 2. Take a snapshot for the table:
> {code:java}
> snapshot 'test1','snap_test'
> {code}
> 3. Clone the snapshot to another table
> {code:java}
> clone_snapshot 'snap_test','test2'
> {code}
> 4. Split the original table
> {code:java}
> split 'test1','r3'
> {code}
> 5. Drop the original table
> {code:java}
> disable 'test1'
> drop 'test1'
> {code}
> After that, we see the error like the following in RS log when opening the
> regions of the cloned table:
> {code:java}
> 2020-10-20 13:32:18,415 WARN org.apache.hadoop.hbase.regionserver.HRegion:
> Failed initialize of region=
> test2,,1603200595702.bebdc4f740626206eeccad96b7643261., starting to roll back
> memstore
> java.io.IOException: java.io.IOException: java.io.FileNotFoundException:
> Unable to open link: org.apache.hadoop.hbase.io.HFileLink
> locations=[hdfs:// HOST>:8020/hbase/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89,
> hdfs:// HOST>:8020/hbase/.tmp/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89,
> hdfs:// HOST>:8020/hbase/mobdir/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89,
> hdfs:// HOST>:8020/hbase/archive/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89]
> at
> org.apache.hadoop.hbase.regionserver.HRegion.initializeStores(HRegion.java:1095)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.initializeRegionInternals(HRegion.java:943)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.initialize(HRegion.java:899)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:7246)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:7204)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:7176)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:7134)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:7085)
> at
> org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler.openRegion(OpenRegionHandler.java:283)
> at
> org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler.process(OpenRegionHandler.java:108)
> at
> org.apache.hadoop.hbase.executor.EventHandler.run(EventHandler.java:104)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.io.IOException: java.io.FileNotFoundException: Unable to open
> link: org.apache.hadoop.hbase.io.HFileLink locations=[hdfs:// HOST>:8020/hbase/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89,
> hdfs:// HOST>:8020/hbase/.tmp/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89,
> hdfs:// HOST>:8020/hbase/mobdir/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89,
> hdfs:// HOST>:8020/hbase/archive/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89]
> at
> org.apache.hadoop.hbase.regionserver.HStore.openStoreFiles(HStore.java:590)
> at
> org.apache.hadoop.hbase.regionserver.HStore.loadStoreFiles(HStore.java:557)
> at org.apache.hadoop.hbase.regionserver.HStore.(HStore.java:303)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.instantiateHStore(HRegion.java:5731)
> at
>
[jira] [Commented] (HBASE-25206) Data loss can happen if a cloned table loses original split region(delete table)
[
https://issues.apache.org/jira/browse/HBASE-25206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220210#comment-17220210
]
Toshihiro Suzuki commented on HBASE-25206:
--
[~anoop.hbase] Yes, This will happens even if snapshot cloned to new table or
not.
> Data loss can happen if a cloned table loses original split region(delete
> table)
>
>
> Key: HBASE-25206
> URL: https://issues.apache.org/jira/browse/HBASE-25206
> Project: HBase
> Issue Type: Bug
> Components: proc-v2, Region Assignment, snapshots
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Major
> Fix For: 3.0.0-alpha-1, 2.3.3, 2.4.0, 2.2.7
>
>
> Steps to reproduce are as follows:
> 1. Create a table and put some data into the table:
> {code:java}
> create 'test1','cf'
> put 'test1','r1','cf','v1'
> put 'test1','r2','cf','v2'
> put 'test1','r3','cf','v3'
> put 'test1','r4','cf','v4'
> put 'test1','r5','cf','v5'
> {code}
> 2. Take a snapshot for the table:
> {code:java}
> snapshot 'test1','snap_test'
> {code}
> 3. Clone the snapshot to another table
> {code:java}
> clone_snapshot 'snap_test','test2'
> {code}
> 4. Split the original table
> {code:java}
> split 'test1','r3'
> {code}
> 5. Drop the original table
> {code:java}
> disable 'test1'
> drop 'test1'
> {code}
> After that, we see the error like the following in RS log when opening the
> regions of the cloned table:
> {code:java}
> 2020-10-20 13:32:18,415 WARN org.apache.hadoop.hbase.regionserver.HRegion:
> Failed initialize of region=
> test2,,1603200595702.bebdc4f740626206eeccad96b7643261., starting to roll back
> memstore
> java.io.IOException: java.io.IOException: java.io.FileNotFoundException:
> Unable to open link: org.apache.hadoop.hbase.io.HFileLink
> locations=[hdfs:// HOST>:8020/hbase/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89,
> hdfs:// HOST>:8020/hbase/.tmp/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89,
> hdfs:// HOST>:8020/hbase/mobdir/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89,
> hdfs:// HOST>:8020/hbase/archive/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89]
> at
> org.apache.hadoop.hbase.regionserver.HRegion.initializeStores(HRegion.java:1095)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.initializeRegionInternals(HRegion.java:943)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.initialize(HRegion.java:899)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:7246)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:7204)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:7176)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:7134)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:7085)
> at
> org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler.openRegion(OpenRegionHandler.java:283)
> at
> org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler.process(OpenRegionHandler.java:108)
> at
> org.apache.hadoop.hbase.executor.EventHandler.run(EventHandler.java:104)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.io.IOException: java.io.FileNotFoundException: Unable to open
> link: org.apache.hadoop.hbase.io.HFileLink locations=[hdfs:// HOST>:8020/hbase/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89,
> hdfs:// HOST>:8020/hbase/.tmp/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89,
> hdfs:// HOST>:8020/hbase/mobdir/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89,
> hdfs:// HOST>:8020/hbase/archive/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89]
> at
> org.apache.hadoop.hbase.regionserver.HStore.openStoreFiles(HStore.java:590)
> at
> org.apache.hadoop.hbase.regionserver.HStore.loadStoreFiles(HStore.java:557)
> at org.apache.hadoop.hbase.regionserver.HStore.(HStore.java:303)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.instantiateHStore(HRegion.java:5731)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$1.call(HRegion.java:1059)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$1.call(HRegion.java:1056)
> at
[jira] [Comment Edited] (HBASE-25206) Data loss can happen if a cloned table loses original split region(delete table)
[
https://issues.apache.org/jira/browse/HBASE-25206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220210#comment-17220210
]
Toshihiro Suzuki edited comment on HBASE-25206 at 10/24/20, 11:18 PM:
--
[~anoop.hbase] Yes, This will happen even if snapshot cloned to new table or
not.
was (Author: brfrn169):
[~anoop.hbase] Yes, This will happens even if snapshot cloned to new table or
not.
> Data loss can happen if a cloned table loses original split region(delete
> table)
>
>
> Key: HBASE-25206
> URL: https://issues.apache.org/jira/browse/HBASE-25206
> Project: HBase
> Issue Type: Bug
> Components: proc-v2, Region Assignment, snapshots
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Major
> Fix For: 3.0.0-alpha-1, 2.3.3, 2.4.0, 2.2.7
>
>
> Steps to reproduce are as follows:
> 1. Create a table and put some data into the table:
> {code:java}
> create 'test1','cf'
> put 'test1','r1','cf','v1'
> put 'test1','r2','cf','v2'
> put 'test1','r3','cf','v3'
> put 'test1','r4','cf','v4'
> put 'test1','r5','cf','v5'
> {code}
> 2. Take a snapshot for the table:
> {code:java}
> snapshot 'test1','snap_test'
> {code}
> 3. Clone the snapshot to another table
> {code:java}
> clone_snapshot 'snap_test','test2'
> {code}
> 4. Split the original table
> {code:java}
> split 'test1','r3'
> {code}
> 5. Drop the original table
> {code:java}
> disable 'test1'
> drop 'test1'
> {code}
> After that, we see the error like the following in RS log when opening the
> regions of the cloned table:
> {code:java}
> 2020-10-20 13:32:18,415 WARN org.apache.hadoop.hbase.regionserver.HRegion:
> Failed initialize of region=
> test2,,1603200595702.bebdc4f740626206eeccad96b7643261., starting to roll back
> memstore
> java.io.IOException: java.io.IOException: java.io.FileNotFoundException:
> Unable to open link: org.apache.hadoop.hbase.io.HFileLink
> locations=[hdfs:// HOST>:8020/hbase/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89,
> hdfs:// HOST>:8020/hbase/.tmp/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89,
> hdfs:// HOST>:8020/hbase/mobdir/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89,
> hdfs:// HOST>:8020/hbase/archive/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89]
> at
> org.apache.hadoop.hbase.regionserver.HRegion.initializeStores(HRegion.java:1095)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.initializeRegionInternals(HRegion.java:943)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.initialize(HRegion.java:899)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:7246)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:7204)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:7176)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:7134)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:7085)
> at
> org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler.openRegion(OpenRegionHandler.java:283)
> at
> org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler.process(OpenRegionHandler.java:108)
> at
> org.apache.hadoop.hbase.executor.EventHandler.run(EventHandler.java:104)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.io.IOException: java.io.FileNotFoundException: Unable to open
> link: org.apache.hadoop.hbase.io.HFileLink locations=[hdfs:// HOST>:8020/hbase/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89,
> hdfs:// HOST>:8020/hbase/.tmp/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89,
> hdfs:// HOST>:8020/hbase/mobdir/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89,
> hdfs:// HOST>:8020/hbase/archive/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89]
> at
> org.apache.hadoop.hbase.regionserver.HStore.openStoreFiles(HStore.java:590)
> at
> org.apache.hadoop.hbase.regionserver.HStore.loadStoreFiles(HStore.java:557)
> at org.apache.hadoop.hbase.regionserver.HStore.(HStore.java:303)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.instantiateHStore(HRegion.java:5731)
> at
>
[jira] [Comment Edited] (HBASE-25206) Data loss can happen if a cloned table loses original split region(delete table)
[
https://issues.apache.org/jira/browse/HBASE-25206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17219440#comment-17219440
]
Toshihiro Suzuki edited comment on HBASE-25206 at 10/23/20, 3:38 AM:
-
[~anoop.hbase] Sorry. I just noticed your comment.
This issue happens because when deleting a table, DeleteTableProcedure archives
only online regions of the table (that don't include OFFLINE or SPLIT regions).
The timeline of this issue is as follows:
1. Create a table that has RegionA
{code:java}
Original table:
RegionA
{code}
2. Take a snapshot for the table
{code:java}
Original table:
RegionA
Snapshot:
Reference to RegionA
{code}
3. Clone the snapshot to another table
{code:java}
Original table:
RegionA
Cloned table:
Reference to RegionA
Snapshot:
Reference to RegionA
{code}
4. Split the original table. The state of RegionA becomes SPLIT, and RegionB
and RegionC are the daughter regions of RegionA:
{code:java}
Original table:
RegionA <- SPLIT state
RegionB
RegionC
Cloned table:
Reference to RegionA
Snapshot:
Reference to RegionA
{code}
5. Drop the original table. However, only RegionB and RegionC are archived due
to the bug. As a result, the cloned table gets data lost. Also the snapshot
gets corrupted:
{code:java}
Cloned table:
Reference to RegionA
Snapshot:
Reference to RegionA
Archive:
RegionB
RegionC
{code}
was (Author: brfrn169):
[~anoop.hbase] Sorry. I just noticed your comment.
This issue happens because when deleting a table, DeleteTableProcedure archives
only online regions of the table (that don't include OFFLINE or SPLITTING
regions).
The timeline of this issue is as follows:
1. Create a table that has RegionA
{code:java}
Original table:
RegionA
{code}
2. Take a snapshot for the table
{code:java}
Original table:
RegionA
Snapshot:
Reference to RegionA
{code}
3. Clone the snapshot to another table
{code:java}
Original table:
RegionA
Cloned table:
Reference to RegionA
Snapshot:
Reference to RegionA
{code}
4. Split the original table. The state of RegionA becomes SPLIT, and RegionB
and RegionC are the daughter regions of RegionA:
{code:java}
Original table:
RegionA <- SPLIT state
RegionB
RegionC
Cloned table:
Reference to RegionA
Snapshot:
Reference to RegionA
{code}
5. Drop the original table. However, only RegionB and RegionC are archived due
to the bug. As a result, the cloned table gets data lost. Also the snapshot
gets corrupted:
{code:java}
Cloned table:
Reference to RegionA
Snapshot:
Reference to RegionA
Archive:
RegionB
RegionC
{code}
> Data loss can happen if a cloned table loses original split region(delete
> table)
>
>
> Key: HBASE-25206
> URL: https://issues.apache.org/jira/browse/HBASE-25206
> Project: HBase
> Issue Type: Bug
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Major
>
> Steps to reproduce are as follows:
> 1. Create a table and put some data into the table:
> {code:java}
> create 'test1','cf'
> put 'test1','r1','cf','v1'
> put 'test1','r2','cf','v2'
> put 'test1','r3','cf','v3'
> put 'test1','r4','cf','v4'
> put 'test1','r5','cf','v5'
> {code}
> 2. Take a snapshot for the table:
> {code:java}
> snapshot 'test1','snap_test'
> {code}
> 3. Clone the snapshot to another table
> {code:java}
> clone_snapshot 'snap_test','test2'
> {code}
> 4. Split the original table
> {code:java}
> split 'test1','r3'
> {code}
> 5. Drop the original table
> {code:java}
> disable 'test1'
> drop 'test1'
> {code}
> After that, we see the error like the following in RS log when opening the
> regions of the cloned table:
> {code:java}
> 2020-10-20 13:32:18,415 WARN org.apache.hadoop.hbase.regionserver.HRegion:
> Failed initialize of region=
> test2,,1603200595702.bebdc4f740626206eeccad96b7643261., starting to roll back
> memstore
> java.io.IOException: java.io.IOException: java.io.FileNotFoundException:
> Unable to open link: org.apache.hadoop.hbase.io.HFileLink
> locations=[hdfs:// HOST>:8020/hbase/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89,
> hdfs:// HOST>:8020/hbase/.tmp/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89,
> hdfs:// HOST>:8020/hbase/mobdir/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89,
> hdfs:// HOST>:8020/hbase/archive/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89]
> at
> org.apache.hadoop.hbase.regionserver.HRegion.initializeStores(HRegion.java:1095)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.initializeRegionInternals(HRegion.java:943)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.initialize(HRegion.java:899)
> at
>
[jira] [Commented] (HBASE-25206) Data loss can happen if a cloned table loses original split region(delete table)
[
https://issues.apache.org/jira/browse/HBASE-25206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17219440#comment-17219440
]
Toshihiro Suzuki commented on HBASE-25206:
--
[~anoop.hbase] Sorry. I just noticed your comment.
This issue happens because when deleting a table, DeleteTableProcedure archives
only online regions of the table (that don't include OFFLINE or SPLITTING
regions).
The timeline of this issue is as follows:
1. Create a table that has RegionA
{code:java}
Original table:
RegionA
{code}
2. Take a snapshot for the table
{code:java}
Original table:
RegionA
Snapshot:
Reference to RegionA
{code}
3. Clone the snapshot to another table
{code:java}
Original table:
RegionA
Cloned table:
Reference to RegionA
Snapshot:
Reference to RegionA
{code}
4. Split the original table. The state of RegionA becomes SPLIT, and RegionB
and RegionC are the daughter regions of RegionA:
{code:java}
Original table:
RegionA <- SPLIT state
RegionB
RegionC
Cloned table:
Reference to RegionA
Snapshot:
Reference to RegionA
{code}
5. Drop the original table. However, only RegionB and RegionC are archived due
to the bug. As a result, the cloned table gets data lost. Also the snapshot
gets corrupted:
{code:java}
Cloned table:
Reference to RegionA
Snapshot:
Reference to RegionA
Archive:
RegionB
RegionC
{code}
> Data loss can happen if a cloned table loses original split region(delete
> table)
>
>
> Key: HBASE-25206
> URL: https://issues.apache.org/jira/browse/HBASE-25206
> Project: HBase
> Issue Type: Bug
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Major
>
> Steps to reproduce are as follows:
> 1. Create a table and put some data into the table:
> {code:java}
> create 'test1','cf'
> put 'test1','r1','cf','v1'
> put 'test1','r2','cf','v2'
> put 'test1','r3','cf','v3'
> put 'test1','r4','cf','v4'
> put 'test1','r5','cf','v5'
> {code}
> 2. Take a snapshot for the table:
> {code:java}
> snapshot 'test1','snap_test'
> {code}
> 3. Clone the snapshot to another table
> {code:java}
> clone_snapshot 'snap_test','test2'
> {code}
> 4. Split the original table
> {code:java}
> split 'test1','r3'
> {code}
> 5. Drop the original table
> {code:java}
> disable 'test1'
> drop 'test1'
> {code}
> After that, we see the error like the following in RS log when opening the
> regions of the cloned table:
> {code:java}
> 2020-10-20 13:32:18,415 WARN org.apache.hadoop.hbase.regionserver.HRegion:
> Failed initialize of region=
> test2,,1603200595702.bebdc4f740626206eeccad96b7643261., starting to roll back
> memstore
> java.io.IOException: java.io.IOException: java.io.FileNotFoundException:
> Unable to open link: org.apache.hadoop.hbase.io.HFileLink
> locations=[hdfs:// HOST>:8020/hbase/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89,
> hdfs:// HOST>:8020/hbase/.tmp/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89,
> hdfs:// HOST>:8020/hbase/mobdir/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89,
> hdfs:// HOST>:8020/hbase/archive/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89]
> at
> org.apache.hadoop.hbase.regionserver.HRegion.initializeStores(HRegion.java:1095)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.initializeRegionInternals(HRegion.java:943)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.initialize(HRegion.java:899)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:7246)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:7204)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:7176)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:7134)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:7085)
> at
> org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler.openRegion(OpenRegionHandler.java:283)
> at
> org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler.process(OpenRegionHandler.java:108)
> at
> org.apache.hadoop.hbase.executor.EventHandler.run(EventHandler.java:104)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.io.IOException: java.io.FileNotFoundException: Unable to open
> link: org.apache.hadoop.hbase.io.HFileLink locations=[hdfs://
[jira] [Updated] (HBASE-25206) Data loss can happen if a cloned table loses original split region(delete table)
[
https://issues.apache.org/jira/browse/HBASE-25206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Toshihiro Suzuki updated HBASE-25206:
-
Description:
Steps to reproduce are as follows:
1. Create a table and put some data into the table:
{code:java}
create 'test1','cf'
put 'test1','r1','cf','v1'
put 'test1','r2','cf','v2'
put 'test1','r3','cf','v3'
put 'test1','r4','cf','v4'
put 'test1','r5','cf','v5'
{code}
2. Take a snapshot for the table:
{code:java}
snapshot 'test1','snap_test'
{code}
3. Clone the snapshot to another table
{code:java}
clone_snapshot 'snap_test','test2'
{code}
4. Split the original table
{code:java}
split 'test1','r3'
{code}
5. Drop the original table
{code:java}
disable 'test1'
drop 'test1'
{code}
After that, we see the error like the following in RS log when opening the
regions of the cloned table:
{code:java}
2020-10-20 13:32:18,415 WARN org.apache.hadoop.hbase.regionserver.HRegion:
Failed initialize of region=
test2,,1603200595702.bebdc4f740626206eeccad96b7643261., starting to roll back
memstore
java.io.IOException: java.io.IOException: java.io.FileNotFoundException: Unable
to open link: org.apache.hadoop.hbase.io.HFileLink locations=[hdfs://:8020/hbase/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89,
hdfs://:8020/hbase/.tmp/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89,
hdfs://:8020/hbase/mobdir/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89,
hdfs://:8020/hbase/archive/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89]
at
org.apache.hadoop.hbase.regionserver.HRegion.initializeStores(HRegion.java:1095)
at
org.apache.hadoop.hbase.regionserver.HRegion.initializeRegionInternals(HRegion.java:943)
at
org.apache.hadoop.hbase.regionserver.HRegion.initialize(HRegion.java:899)
at
org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:7246)
at
org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:7204)
at
org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:7176)
at
org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:7134)
at
org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:7085)
at
org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler.openRegion(OpenRegionHandler.java:283)
at
org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler.process(OpenRegionHandler.java:108)
at
org.apache.hadoop.hbase.executor.EventHandler.run(EventHandler.java:104)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.io.IOException: java.io.FileNotFoundException: Unable to open
link: org.apache.hadoop.hbase.io.HFileLink locations=[hdfs://:8020/hbase/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89,
hdfs://:8020/hbase/.tmp/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89,
hdfs://:8020/hbase/mobdir/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89,
hdfs://:8020/hbase/archive/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89]
at
org.apache.hadoop.hbase.regionserver.HStore.openStoreFiles(HStore.java:590)
at
org.apache.hadoop.hbase.regionserver.HStore.loadStoreFiles(HStore.java:557)
at org.apache.hadoop.hbase.regionserver.HStore.(HStore.java:303)
at
org.apache.hadoop.hbase.regionserver.HRegion.instantiateHStore(HRegion.java:5731)
at
org.apache.hadoop.hbase.regionserver.HRegion$1.call(HRegion.java:1059)
at
org.apache.hadoop.hbase.regionserver.HRegion$1.call(HRegion.java:1056)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
... 3 more
Caused by: java.io.FileNotFoundException: Unable to open link:
org.apache.hadoop.hbase.io.HFileLink locations=[hdfs://:8020/hbase/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89,
hdfs://:8020/hbase/.tmp/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89,
hdfs://:8020/hbase/mobdir/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89,
hdfs://:8020/hbase/archive/data/default/test1/349b766b1b38e21f627ed4e441ae643c/cf/b6e39865710345c8998dec0bcc94cc89]
at
org.apache.hadoop.hbase.io.FileLink$FileLinkInputStream.tryOpen(FileLink.java:322)
at
