[jira] [Commented] (HBASE-17947) Location of Examples.proto is wrong in comment of RowCountEndPoint.java
[
https://issues.apache.org/jira/browse/HBASE-17947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15980712#comment-15980712
]
Xiang Li commented on HBASE-17947:
--
Thanks the comment from [~jingcheng.du]!
Patch 001 for master branch is uploaded to address Jingcheng's comment! The
JIRA meant to change the incorrect patch only, while the removal of "located
under" was only trying to make it feel better when reading. Either is ok for
me.
> Location of Examples.proto is wrong in comment of RowCountEndPoint.java
> ---
>
> Key: HBASE-17947
> URL: https://issues.apache.org/jira/browse/HBASE-17947
> Project: HBase
> Issue Type: Bug
> Components: Coprocessors
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Trivial
> Labels: easyfix
> Fix For: 2.0.0
>
> Attachments: HBASE-17947.master.000.patch,
> HBASE-17947.master.001.patch
>
>
> In the comment of RowCountEndpoint.java
> {code}
> /**
> * Sample coprocessor endpoint exposing a Service interface for counting rows
> and key values.
> *
> *
> * For the protocol buffer definition of the RowCountService, see the source
> file located under
> * hbase-server/src/main/protobuf/Examples.proto.
> *
> */
> {code}
> Examples.proto is not under hbase-server/src/main/protobuf/, but under
> hbase-examples/src/main/protobuf/
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (HBASE-17947) Location of Examples.proto is wrong in comment of RowCountEndPoint.java
[
https://issues.apache.org/jira/browse/HBASE-17947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xiang Li updated HBASE-17947:
-
Status: Open (was: Patch Available)
> Location of Examples.proto is wrong in comment of RowCountEndPoint.java
> ---
>
> Key: HBASE-17947
> URL: https://issues.apache.org/jira/browse/HBASE-17947
> Project: HBase
> Issue Type: Bug
> Components: Coprocessors
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Trivial
> Labels: easyfix
> Fix For: 2.0.0
>
> Attachments: HBASE-17947.master.000.patch,
> HBASE-17947.master.001.patch
>
>
> In the comment of RowCountEndpoint.java
> {code}
> /**
> * Sample coprocessor endpoint exposing a Service interface for counting rows
> and key values.
> *
> *
> * For the protocol buffer definition of the RowCountService, see the source
> file located under
> * hbase-server/src/main/protobuf/Examples.proto.
> *
> */
> {code}
> Examples.proto is not under hbase-server/src/main/protobuf/, but under
> hbase-examples/src/main/protobuf/
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (HBASE-17947) Location of Examples.proto is wrong in comment of RowCountEndPoint.java
[
https://issues.apache.org/jira/browse/HBASE-17947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xiang Li updated HBASE-17947:
-
Attachment: HBASE-17947.master.001.patch
> Location of Examples.proto is wrong in comment of RowCountEndPoint.java
> ---
>
> Key: HBASE-17947
> URL: https://issues.apache.org/jira/browse/HBASE-17947
> Project: HBase
> Issue Type: Bug
> Components: Coprocessors
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Trivial
> Labels: easyfix
> Fix For: 2.0.0
>
> Attachments: HBASE-17947.master.000.patch,
> HBASE-17947.master.001.patch
>
>
> In the comment of RowCountEndpoint.java
> {code}
> /**
> * Sample coprocessor endpoint exposing a Service interface for counting rows
> and key values.
> *
> *
> * For the protocol buffer definition of the RowCountService, see the source
> file located under
> * hbase-server/src/main/protobuf/Examples.proto.
> *
> */
> {code}
> Examples.proto is not under hbase-server/src/main/protobuf/, but under
> hbase-examples/src/main/protobuf/
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-9899) for idempotent operation dups, return the result instead of throwing conflict exception
[
https://issues.apache.org/jira/browse/HBASE-9899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15980709#comment-15980709
]
Hadoop QA commented on HBASE-9899:
--
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s
{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 12s {color}
| {color:red} HBASE-9899 does not apply to master. Rebase required? Wrong
Branch? See https://yetus.apache.org/documentation/0.3.0/precommit-patchnames
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12864699/HBASE-9899-addendum-branch-1.patch
|
| JIRA Issue | HBASE-9899 |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/6539/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> for idempotent operation dups, return the result instead of throwing conflict
> exception
> ---
>
> Key: HBASE-9899
> URL: https://issues.apache.org/jira/browse/HBASE-9899
> Project: HBase
> Issue Type: Improvement
>Reporter: Sergey Shelukhin
>Assignee: Guanghao Zhang
> Fix For: 2.0.0, 1.3.0, 1.4.0
>
> Attachments: HBASE-9899-addendum-branch-1.patch,
> HBASE-9899-addendum.patch, HBASE-9899-branch-1.patch,
> HBASE-9899-branch-1.patch, HBASE-9899-branch-1.patch, HBASE-9899-v1.patch,
> HBASE-9899-v2.patch, HBASE-9899-v3.patch, HBASE-9899-v3.patch,
> HBASE-9899-v4.patch, HBASE-9899-v4.patch
>
>
> After HBASE-3787, we could store mvcc in operation context, and use it to
> convert the modification request into read on dups instead of throwing
> OperationConflictException.
> MVCC tracking will have to be aware of such MVCC numbers present. Given that
> scanners are usually relatively short-lived, that would prevent low watermark
> from advancing for quite a bit more time
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-17947) Location of Examples.proto is wrong in comment of RowCountEndPoint.java
[
https://issues.apache.org/jira/browse/HBASE-17947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15980700#comment-15980700
]
Jingcheng Du commented on HBASE-17947:
--
Thanks for the patch [~water].
It is better only change the incorrect path not to change other statement.
+1 after the comment is addressed.
> Location of Examples.proto is wrong in comment of RowCountEndPoint.java
> ---
>
> Key: HBASE-17947
> URL: https://issues.apache.org/jira/browse/HBASE-17947
> Project: HBase
> Issue Type: Bug
> Components: Coprocessors
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Trivial
> Labels: easyfix
> Fix For: 2.0.0
>
> Attachments: HBASE-17947.master.000.patch
>
>
> In the comment of RowCountEndpoint.java
> {code}
> /**
> * Sample coprocessor endpoint exposing a Service interface for counting rows
> and key values.
> *
> *
> * For the protocol buffer definition of the RowCountService, see the source
> file located under
> * hbase-server/src/main/protobuf/Examples.proto.
> *
> */
> {code}
> Examples.proto is not under hbase-server/src/main/protobuf/, but under
> hbase-examples/src/main/protobuf/
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-17124) HFileInputFormat can help user read hbase table with HFile way,more effective
[ https://issues.apache.org/jira/browse/HBASE-17124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15980696#comment-15980696 ] Guangxu Cheng commented on HBASE-17124: --- HFileInputFormat has been implemented after HBASE-14123 > HFileInputFormat can help user read hbase table with HFile way,more effective > - > > Key: HBASE-17124 > URL: https://issues.apache.org/jira/browse/HBASE-17124 > Project: HBase > Issue Type: New Feature > Components: HFile >Reporter: Yuan Kang >Assignee: Yuan Kang > Attachments: HFileInputFormat.java > > > When we need to read large amount of data from hbase,usually we use > tableinputformat to query hbase table. but hfileInputFormat way is more > effective -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-9899) for idempotent operation dups, return the result instead of throwing conflict exception
[ https://issues.apache.org/jira/browse/HBASE-9899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15980681#comment-15980681 ] Chia-Ping Tsai commented on HBASE-9899: --- LGTM > for idempotent operation dups, return the result instead of throwing conflict > exception > --- > > Key: HBASE-9899 > URL: https://issues.apache.org/jira/browse/HBASE-9899 > Project: HBase > Issue Type: Improvement >Reporter: Sergey Shelukhin >Assignee: Guanghao Zhang > Fix For: 2.0.0, 1.3.0, 1.4.0 > > Attachments: HBASE-9899-addendum-branch-1.patch, > HBASE-9899-addendum.patch, HBASE-9899-branch-1.patch, > HBASE-9899-branch-1.patch, HBASE-9899-branch-1.patch, HBASE-9899-v1.patch, > HBASE-9899-v2.patch, HBASE-9899-v3.patch, HBASE-9899-v3.patch, > HBASE-9899-v4.patch, HBASE-9899-v4.patch > > > After HBASE-3787, we could store mvcc in operation context, and use it to > convert the modification request into read on dups instead of throwing > OperationConflictException. > MVCC tracking will have to be aware of such MVCC numbers present. Given that > scanners are usually relatively short-lived, that would prevent low watermark > from advancing for quite a bit more time -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17877) Replace/improve HBase's byte[] comparator
[ https://issues.apache.org/jira/browse/HBASE-17877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15980678#comment-15980678 ] Duo Zhang commented on HBASE-17877: --- OK. Got it. No other questions. Thanks. > Replace/improve HBase's byte[] comparator > - > > Key: HBASE-17877 > URL: https://issues.apache.org/jira/browse/HBASE-17877 > Project: HBase > Issue Type: Bug >Reporter: Lars Hofhansl >Assignee: Vikas Vishwakarma > Attachments: 17877-1.2.patch, 17877-v2-1.3.patch, 17877-v3-1.3.patch, > 17877-v4-1.3.patch, ByteComparatorJiraHBASE-17877.pdf, > HBASE-17877.branch-1.3.001.patch, HBASE-17877.branch-1.3.002.patch, > HBASE-17877.master.001.patch, HBASE-17877.master.002.patch > > > [~vik.karma] did some extensive tests and found that Hadoop's version is > faster - dramatically faster in some cases. > Patch forthcoming. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-9899) for idempotent operation dups, return the result instead of throwing conflict exception
[ https://issues.apache.org/jira/browse/HBASE-9899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guanghao Zhang updated HBASE-9899: -- Attachment: HBASE-9899-addendum-branch-1.patch > for idempotent operation dups, return the result instead of throwing conflict > exception > --- > > Key: HBASE-9899 > URL: https://issues.apache.org/jira/browse/HBASE-9899 > Project: HBase > Issue Type: Improvement >Reporter: Sergey Shelukhin >Assignee: Guanghao Zhang > Fix For: 2.0.0, 1.3.0, 1.4.0 > > Attachments: HBASE-9899-addendum-branch-1.patch, > HBASE-9899-addendum.patch, HBASE-9899-branch-1.patch, > HBASE-9899-branch-1.patch, HBASE-9899-branch-1.patch, HBASE-9899-v1.patch, > HBASE-9899-v2.patch, HBASE-9899-v3.patch, HBASE-9899-v3.patch, > HBASE-9899-v4.patch, HBASE-9899-v4.patch > > > After HBASE-3787, we could store mvcc in operation context, and use it to > convert the modification request into read on dups instead of throwing > OperationConflictException. > MVCC tracking will have to be aware of such MVCC numbers present. Given that > scanners are usually relatively short-lived, that would prevent low watermark > from advancing for quite a bit more time -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-9899) for idempotent operation dups, return the result instead of throwing conflict exception
[ https://issues.apache.org/jira/browse/HBASE-9899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guanghao Zhang updated HBASE-9899: -- Status: Patch Available (was: Reopened) > for idempotent operation dups, return the result instead of throwing conflict > exception > --- > > Key: HBASE-9899 > URL: https://issues.apache.org/jira/browse/HBASE-9899 > Project: HBase > Issue Type: Improvement >Reporter: Sergey Shelukhin >Assignee: Guanghao Zhang > Fix For: 2.0.0, 1.4.0, 1.3.0 > > Attachments: HBASE-9899-addendum-branch-1.patch, > HBASE-9899-addendum.patch, HBASE-9899-branch-1.patch, > HBASE-9899-branch-1.patch, HBASE-9899-branch-1.patch, HBASE-9899-v1.patch, > HBASE-9899-v2.patch, HBASE-9899-v3.patch, HBASE-9899-v3.patch, > HBASE-9899-v4.patch, HBASE-9899-v4.patch > > > After HBASE-3787, we could store mvcc in operation context, and use it to > convert the modification request into read on dups instead of throwing > OperationConflictException. > MVCC tracking will have to be aware of such MVCC numbers present. Given that > scanners are usually relatively short-lived, that would prevent low watermark > from advancing for quite a bit more time -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Reopened] (HBASE-9899) for idempotent operation dups, return the result instead of throwing conflict exception
[ https://issues.apache.org/jira/browse/HBASE-9899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guanghao Zhang reopened HBASE-9899: --- Reopen for forget to pass nonce for scanner in branch-1. > for idempotent operation dups, return the result instead of throwing conflict > exception > --- > > Key: HBASE-9899 > URL: https://issues.apache.org/jira/browse/HBASE-9899 > Project: HBase > Issue Type: Improvement >Reporter: Sergey Shelukhin >Assignee: Guanghao Zhang > Fix For: 2.0.0, 1.3.0, 1.4.0 > > Attachments: HBASE-9899-addendum.patch, HBASE-9899-branch-1.patch, > HBASE-9899-branch-1.patch, HBASE-9899-branch-1.patch, HBASE-9899-v1.patch, > HBASE-9899-v2.patch, HBASE-9899-v3.patch, HBASE-9899-v3.patch, > HBASE-9899-v4.patch, HBASE-9899-v4.patch > > > After HBASE-3787, we could store mvcc in operation context, and use it to > convert the modification request into read on dups instead of throwing > OperationConflictException. > MVCC tracking will have to be aware of such MVCC numbers present. Given that > scanners are usually relatively short-lived, that would prevent low watermark > from advancing for quite a bit more time -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17877) Replace/improve HBase's byte[] comparator
[ https://issues.apache.org/jira/browse/HBASE-17877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15980674#comment-15980674 ] Vikas Vishwakarma commented on HBASE-17877: --- yes, I was trying to avoid that but it is a fixed cost. The benchmarks without randomizing or having a fixed diff between the arrays was coming out quiet strange and not even varying much with byte array size which it should ideally because as the size increases we will have that many long iterations. > Replace/improve HBase's byte[] comparator > - > > Key: HBASE-17877 > URL: https://issues.apache.org/jira/browse/HBASE-17877 > Project: HBase > Issue Type: Bug >Reporter: Lars Hofhansl >Assignee: Vikas Vishwakarma > Attachments: 17877-1.2.patch, 17877-v2-1.3.patch, 17877-v3-1.3.patch, > 17877-v4-1.3.patch, ByteComparatorJiraHBASE-17877.pdf, > HBASE-17877.branch-1.3.001.patch, HBASE-17877.branch-1.3.002.patch, > HBASE-17877.master.001.patch, HBASE-17877.master.002.patch > > > [~vik.karma] did some extensive tests and found that Hadoop's version is > faster - dramatically faster in some cases. > Patch forthcoming. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17877) Replace/improve HBase's byte[] comparator
[ https://issues.apache.org/jira/browse/HBASE-17877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15980667#comment-15980667 ] Duo Zhang commented on HBASE-17877: --- Will the two Random.nextInt calls impact the performance? > Replace/improve HBase's byte[] comparator > - > > Key: HBASE-17877 > URL: https://issues.apache.org/jira/browse/HBASE-17877 > Project: HBase > Issue Type: Bug >Reporter: Lars Hofhansl >Assignee: Vikas Vishwakarma > Attachments: 17877-1.2.patch, 17877-v2-1.3.patch, 17877-v3-1.3.patch, > 17877-v4-1.3.patch, ByteComparatorJiraHBASE-17877.pdf, > HBASE-17877.branch-1.3.001.patch, HBASE-17877.branch-1.3.002.patch, > HBASE-17877.master.001.patch, HBASE-17877.master.002.patch > > > [~vik.karma] did some extensive tests and found that Hadoop's version is > faster - dramatically faster in some cases. > Patch forthcoming. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17877) Replace/improve HBase's byte[] comparator
[
https://issues.apache.org/jira/browse/HBASE-17877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15980656#comment-15980656
]
Vikas Vishwakarma commented on HBASE-17877:
---
[~Apache9] , I am copying the code below:
{code}
public class MyBenchmark {
static byte[] ba1_8;
static byte[] ba2_8;
...
static {
Random r = new Random();
ba1_8 = new byte[8];
ba2_8 = new byte[8];
r.nextBytes(ba1_8);
r.nextBytes(ba2_8);
}
@GenerateMicroBenchmark
@Fork(1)
@BenchmarkMode(Mode.Throughput)
@Warmup(iterations = 20, time = 1, timeUnit = TimeUnit.SECONDS)
@Measurement(iterations = 50, time = 1, timeUnit = TimeUnit.SECONDS)
public void testHBaseComparator8(BlackHole b) {
// place your benchmarked code here
b.consume(ByteArrayComparator.compareToHbase(ba1_8, 0, ba1_8.length,
ba2_8, 0, ba2_8.length));
}
...
//Similarly for HBase/Hadoop/Guava101 for byte array size from 4 to 16K
int compareToHbase(byte[] buffer1, int offset1, int length1,
byte[] buffer2, int offset2, int length2) {
final int minLength = Math.min(length1, length2);
// Changing input random index using random byte before running
compare
int indx = r.nextInt(minLength);
int cindx = r.nextInt(byteArrLen);
buffer1[indx] = byteArr[cindx];
buffer2[indx] = byteArr[cindx];
//Remaining HBase comparator code
}
}
{code}
> Replace/improve HBase's byte[] comparator
> -
>
> Key: HBASE-17877
> URL: https://issues.apache.org/jira/browse/HBASE-17877
> Project: HBase
> Issue Type: Bug
>Reporter: Lars Hofhansl
>Assignee: Vikas Vishwakarma
> Attachments: 17877-1.2.patch, 17877-v2-1.3.patch, 17877-v3-1.3.patch,
> 17877-v4-1.3.patch, ByteComparatorJiraHBASE-17877.pdf,
> HBASE-17877.branch-1.3.001.patch, HBASE-17877.branch-1.3.002.patch,
> HBASE-17877.master.001.patch, HBASE-17877.master.002.patch
>
>
> [~vik.karma] did some extensive tests and found that Hadoop's version is
> faster - dramatically faster in some cases.
> Patch forthcoming.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-17928) Shell tool to clear compact queues
[ https://issues.apache.org/jira/browse/HBASE-17928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15980641#comment-15980641 ] Guangxu Cheng commented on HBASE-17928: --- Patch v4: Delete the update to Admin.proto in hbase-protocol. > Shell tool to clear compact queues > -- > > Key: HBASE-17928 > URL: https://issues.apache.org/jira/browse/HBASE-17928 > Project: HBase > Issue Type: New Feature >Reporter: Guangxu Cheng >Assignee: Guangxu Cheng > Fix For: 2.0.0 > > Attachments: HBASE-17928-v1.patch, HBASE-17928-v2.patch, > HBASE-17928-v3.patch, HBASE-17928-v4.patch > > > scenarioļ¼ > 1. Compact a table by mistake > 2. Compact is not completed within the specified time period > In this case, clearing the queue is a better choice, so as not to affect the > stability of the cluster -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17928) Shell tool to clear compact queues
[ https://issues.apache.org/jira/browse/HBASE-17928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guangxu Cheng updated HBASE-17928: -- Attachment: HBASE-17928-v4.patch > Shell tool to clear compact queues > -- > > Key: HBASE-17928 > URL: https://issues.apache.org/jira/browse/HBASE-17928 > Project: HBase > Issue Type: New Feature >Reporter: Guangxu Cheng >Assignee: Guangxu Cheng > Fix For: 2.0.0 > > Attachments: HBASE-17928-v1.patch, HBASE-17928-v2.patch, > HBASE-17928-v3.patch, HBASE-17928-v4.patch > > > scenarioļ¼ > 1. Compact a table by mistake > 2. Compact is not completed within the specified time period > In this case, clearing the queue is a better choice, so as not to affect the > stability of the cluster -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17877) Replace/improve HBase's byte[] comparator
[ https://issues.apache.org/jira/browse/HBASE-17877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15980617#comment-15980617 ] Duo Zhang commented on HBASE-17877: --- +1. But I still want to see the final jmh benchmark code. I do not think the jvm optimization could impact the result when you use a static byte array if you implement the benchmark correctly using BlackHole. > Replace/improve HBase's byte[] comparator > - > > Key: HBASE-17877 > URL: https://issues.apache.org/jira/browse/HBASE-17877 > Project: HBase > Issue Type: Bug >Reporter: Lars Hofhansl >Assignee: Vikas Vishwakarma > Attachments: 17877-1.2.patch, 17877-v2-1.3.patch, 17877-v3-1.3.patch, > 17877-v4-1.3.patch, ByteComparatorJiraHBASE-17877.pdf, > HBASE-17877.branch-1.3.001.patch, HBASE-17877.branch-1.3.002.patch, > HBASE-17877.master.001.patch, HBASE-17877.master.002.patch > > > [~vik.karma] did some extensive tests and found that Hadoop's version is > faster - dramatically faster in some cases. > Patch forthcoming. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17263) Netty based rpc server impl
[ https://issues.apache.org/jira/browse/HBASE-17263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15980615#comment-15980615 ] Duo Zhang commented on HBASE-17263: --- Skimmed on RB. No big questions. I think we can commit it first and then optimize it. Thanks. > Netty based rpc server impl > - > > Key: HBASE-17263 > URL: https://issues.apache.org/jira/browse/HBASE-17263 > Project: HBase > Issue Type: Sub-task > Components: Performance, rpc >Reporter: binlijin >Assignee: binlijin > Fix For: 2.0.0 > > Attachments: HBASE-17263.patch, HBASE-17263_v2.patch, > HBASE-17263_v3.patch, HBASE-17263_v4.patch, HBASE-17263_v5.patch, > HBASE-17263_v6.patch, HBASE-17263_v7.patch, HBASE-17263_v8.patch > > > An RPC server with Netty4 implementation, which provide better performance. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17302) The region flush request disappeared from flushQueue
[
https://issues.apache.org/jira/browse/HBASE-17302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15980518#comment-15980518
]
Hudson commented on HBASE-17302:
FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #2903 (See
[https://builds.apache.org/job/HBase-Trunk_matrix/2903/])
HBASE-17302 The region flush request disappeared from flushQueue - (tedyu: rev
435104af70232076145df4211da297c9235cd58f)
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/MemStoreFlusher.java
> The region flush request disappeared from flushQueue
>
>
> Key: HBASE-17302
> URL: https://issues.apache.org/jira/browse/HBASE-17302
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0, 0.98.23, 1.2.4
>Reporter: Guangxu Cheng
>Assignee: Guangxu Cheng
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-17302-branch-1.2-v1.patch,
> HBASE-17302-branch-1-addendum.patch, HBASE-17302-branch-1-addendum-v1.patch,
> HBASE-17302-branch-master-v1.patch, HBASE-17302-master-addendum.patch,
> HBASE-17302-master-addendum-v1.patch
>
>
> Region has too many store files delaying flush up to blockingWaitTime ms, and
> the region flush request is requeued into the flushQueue.
> When the region flush request is requeued into the flushQueue frequently, the
> request is inexplicably disappeared sometimes.
> But regionsInQueue still contains the information of the region request,
> which leads to new flush request can not be inserted into the flushQueue.
> Then, the region will not do flush anymore.
> In order to locate the problem, I added a lot of log in the code.
> {code:title=MemStoreFlusher.java|borderStyle=solid}
> private boolean flushRegion(final HRegion region, final boolean
> emergencyFlush) {
> long startTime = 0;
> synchronized (this.regionsInQueue) {
> FlushRegionEntry fqe = this.regionsInQueue.remove(region);
> // Use the start time of the FlushRegionEntry if available
> if (fqe != null) {
> startTime = fqe.createTime;
> }
> if (fqe != null && emergencyFlush) {
> // Need to remove from region from delay queue. When NOT an
> // emergencyFlush, then item was removed via a flushQueue.poll.
> flushQueue.remove(fqe);
> }
> }
> {code}
> When encountered emergencyFlush, the region flusher will be removed from the
> flushQueue.
> By comparing the flushQueue content before and after remove, RegionA should
> have been removed, it is possible to remove RegionB.
> {code:title=MemStoreFlusher.java|borderStyle=solid}
> public boolean equals(Object obj) {
> if (this == obj) {
> return true;
> }
> if (obj == null || getClass() != obj.getClass()) {
> return false;
> }
> Delayed other = (Delayed) obj;
> return compareTo(other) == 0;
> }
> {code}
> FlushRegionEntry in achieving the equals function, only comparison of the
> delay time, if different regions of the same delay time, it is possible that
> A wrong B.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-16314) Retry on table snapshot failure during full backup
[ https://issues.apache.org/jira/browse/HBASE-16314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15980461#comment-15980461 ] Hudson commented on HBASE-16314: FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #2902 (See [https://builds.apache.org/job/HBase-Trunk_matrix/2902/]) HBASE-16314 Retry on table snapshot failure during full backup (Vladimir (tedyu: rev e95cf479c7615ae160a6ba963cc7689f3b440efd) * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/backup/impl/FullTableBackupClient.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/backup/BackupRestoreConstants.java > Retry on table snapshot failure during full backup > -- > > Key: HBASE-16314 > URL: https://issues.apache.org/jira/browse/HBASE-16314 > Project: HBase > Issue Type: Sub-task >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Labels: backup > Fix For: 2.0.0 > > Attachments: HBASE-16314-v1.patch, HBASE-16314-v2.patch, > HBASE-16314-v3.patch, HBASE-16314-v4.patch, HBASE-16314-v5.patch, > HBASE-16314-v6.patch > > > Table snapshot (during full backup) can fail with NotServingRegionException > (splits, AM region moves). We need to add retry logic here. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17943) The in-memory flush size is different for each CompactingMemStore located in the same region
[
https://issues.apache.org/jira/browse/HBASE-17943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15980462#comment-15980462
]
Hudson commented on HBASE-17943:
FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #2902 (See
[https://builds.apache.org/job/HBase-Trunk_matrix/2902/])
HBASE-17943 Addendum increases the threshold value of in-memory (chia7712: rev
9053ec6fe6505eba4f14adfdd83329511e4a77f0)
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestWalAndCompactingMemStoreFlush.java
> The in-memory flush size is different for each CompactingMemStore located in
> the same region
> -
>
> Key: HBASE-17943
> URL: https://issues.apache.org/jira/browse/HBASE-17943
> Project: HBase
> Issue Type: Bug
> Components: regionserver
>Affects Versions: 2.0.0
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
> Fix For: 2.0.0
>
> Attachments: HBASE-17943.addendum.patch, HBASE-17943.v0.patch
>
>
> {noformat}
> private void initInmemoryFlushSize(Configuration conf) {
> long memstoreFlushSize = getRegionServices().getMemstoreFlushSize();
> int numStores = getRegionServices().getNumStores();
> if (numStores <= 1) {
> // Family number might also be zero in some of our unit test case
> numStores = 1;
> }
> inmemoryFlushSize = memstoreFlushSize / numStores;
> {noformat}
> We initialize each store in parallel, so the return value from getNumStores()
> may be different for each CompactingMemStore.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-17302) The region flush request disappeared from flushQueue
[
https://issues.apache.org/jira/browse/HBASE-17302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15980403#comment-15980403
]
Chia-Ping Tsai commented on HBASE-17302:
[~yuzhih...@gmail.com] Would you please also commit the addendum to trunk ?
Thanks.
> The region flush request disappeared from flushQueue
>
>
> Key: HBASE-17302
> URL: https://issues.apache.org/jira/browse/HBASE-17302
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0, 0.98.23, 1.2.4
>Reporter: Guangxu Cheng
>Assignee: Guangxu Cheng
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-17302-branch-1.2-v1.patch,
> HBASE-17302-branch-1-addendum.patch, HBASE-17302-branch-1-addendum-v1.patch,
> HBASE-17302-branch-master-v1.patch, HBASE-17302-master-addendum.patch,
> HBASE-17302-master-addendum-v1.patch
>
>
> Region has too many store files delaying flush up to blockingWaitTime ms, and
> the region flush request is requeued into the flushQueue.
> When the region flush request is requeued into the flushQueue frequently, the
> request is inexplicably disappeared sometimes.
> But regionsInQueue still contains the information of the region request,
> which leads to new flush request can not be inserted into the flushQueue.
> Then, the region will not do flush anymore.
> In order to locate the problem, I added a lot of log in the code.
> {code:title=MemStoreFlusher.java|borderStyle=solid}
> private boolean flushRegion(final HRegion region, final boolean
> emergencyFlush) {
> long startTime = 0;
> synchronized (this.regionsInQueue) {
> FlushRegionEntry fqe = this.regionsInQueue.remove(region);
> // Use the start time of the FlushRegionEntry if available
> if (fqe != null) {
> startTime = fqe.createTime;
> }
> if (fqe != null && emergencyFlush) {
> // Need to remove from region from delay queue. When NOT an
> // emergencyFlush, then item was removed via a flushQueue.poll.
> flushQueue.remove(fqe);
> }
> }
> {code}
> When encountered emergencyFlush, the region flusher will be removed from the
> flushQueue.
> By comparing the flushQueue content before and after remove, RegionA should
> have been removed, it is possible to remove RegionB.
> {code:title=MemStoreFlusher.java|borderStyle=solid}
> public boolean equals(Object obj) {
> if (this == obj) {
> return true;
> }
> if (obj == null || getClass() != obj.getClass()) {
> return false;
> }
> Delayed other = (Delayed) obj;
> return compareTo(other) == 0;
> }
> {code}
> FlushRegionEntry in achieving the equals function, only comparison of the
> delay time, if different regions of the same delay time, it is possible that
> A wrong B.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
