[jira] [Commented] (HBASE-15536) Make AsyncFSWAL as our default WAL
[ https://issues.apache.org/jira/browse/HBASE-15536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15263592#comment-15263592 ] stack commented on HBASE-15536: --- [~carp84] you did no wrong. There was a regression... just not an important one (smile). We also learned some stuff from the experience. > Make AsyncFSWAL as our default WAL > -- > > Key: HBASE-15536 > URL: https://issues.apache.org/jira/browse/HBASE-15536 > Project: HBase > Issue Type: Sub-task >Affects Versions: 2.0.0 >Reporter: Duo Zhang >Assignee: Duo Zhang > Fix For: 2.0.0 > > Attachments: HBASE-15536-v1.patch, HBASE-15536-v2.patch, > HBASE-15536.patch > > > As it should be predicated on passing basic cluster ITBLL -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15635) Mean age of Blocks in cache (seconds) on webUI should be greater than zero
[ https://issues.apache.org/jira/browse/HBASE-15635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15263583#comment-15263583 ] Heng Chen commented on HBASE-15635: --- suggestions? > Mean age of Blocks in cache (seconds) on webUI should be greater than zero > -- > > Key: HBASE-15635 > URL: https://issues.apache.org/jira/browse/HBASE-15635 > Project: HBase > Issue Type: Bug >Affects Versions: 0.98.17 >Reporter: Heng Chen >Assignee: Heng Chen > Fix For: 2.0.0, 1.3.0, 1.4.0, 1.1.5, 1.2.2, 0.98.20, 1.0.5 > > Attachments: 7BFFAF68-0807-400C-853F-706B498449E1.png, > HBASE-15635.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15714) We are calling checkRow() twice in doMiniBatchMutation()
[
https://issues.apache.org/jira/browse/HBASE-15714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15263579#comment-15263579
]
Hadoop QA commented on HBASE-15714:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s
{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
3s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 38s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 31s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 4m
31s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
15s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
53s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 28s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 33s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
39s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 40s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 40s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 30s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 30s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 4m
15s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
15s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
25m 28s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m 9s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 26s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 35s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 90m 37s {color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
15s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 138m 14s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.security.access.TestAccessController3 |
| Timed out junit tests |
org.apache.hadoop.hbase.regionserver.TestAtomicOperation |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12801373/HBASE-15714_v1.patch |
| JIRA Issue | HBASE-15714 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux asf901.gq1.ygridcore.net 3.13.0-36-lowlatency #63-Ubuntu SMP
PREEMPT Wed Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git
[jira] [Commented] (HBASE-15536) Make AsyncFSWAL as our default WAL
[
https://issues.apache.org/jira/browse/HBASE-15536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15263566#comment-15263566
]
Sean Busbey commented on HBASE-15536:
-
{quote}
bq. Maybe add a note on commit to the DefaultWALProvider about this 'odd' fact.
I think we could change the name of DefaultWALProvider to a more reasonable
name, but still map 'o.a.h.h.regionserver.wal.DefaultWALProvider' to the
renamed class. This does not break the config compatibility.
{quote}
We shouldn't need to do this. One motivating factor for having config enums,
like the wal provider names, is so that the names of Classes aren't in our
config compatibility. Folks relying on a classname should already know they're
taking an unsupported route.
> Make AsyncFSWAL as our default WAL
> --
>
> Key: HBASE-15536
> URL: https://issues.apache.org/jira/browse/HBASE-15536
> Project: HBase
> Issue Type: Sub-task
>Affects Versions: 2.0.0
>Reporter: Duo Zhang
>Assignee: Duo Zhang
> Fix For: 2.0.0
>
> Attachments: HBASE-15536-v1.patch, HBASE-15536-v2.patch,
> HBASE-15536.patch
>
>
> As it should be predicated on passing basic cluster ITBLL
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15609) Remove PB references from Result, DoubleColumnInterpreter and any such public facing class for 2.0
[ https://issues.apache.org/jira/browse/HBASE-15609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-15609: --- Status: Patch Available (was: Open) Submitting for QA. > Remove PB references from Result, DoubleColumnInterpreter and any such public > facing class for 2.0 > -- > > Key: HBASE-15609 > URL: https://issues.apache.org/jira/browse/HBASE-15609 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan >Priority: Blocker > Fix For: 2.0.0 > > Attachments: HBASE-15609.patch > > > This is a sub-task for HBASE-15174. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15536) Make AsyncFSWAL as our default WAL
[ https://issues.apache.org/jira/browse/HBASE-15536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15263554#comment-15263554 ] Yu Li commented on HBASE-15536: --- bq. How many WALs per RS in this test? 4WALs with PCIe-SSD, will share more details in a new JIRA later. Will do more confirmation that it's a generous problem instead of anything caused by our private backports, don't want to give misleading message like ever did in HBASE-15619 any more... :-) > Make AsyncFSWAL as our default WAL > -- > > Key: HBASE-15536 > URL: https://issues.apache.org/jira/browse/HBASE-15536 > Project: HBase > Issue Type: Sub-task >Affects Versions: 2.0.0 >Reporter: Duo Zhang >Assignee: Duo Zhang > Fix For: 2.0.0 > > Attachments: HBASE-15536-v1.patch, HBASE-15536-v2.patch, > HBASE-15536.patch > > > As it should be predicated on passing basic cluster ITBLL -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15278) AsyncRPCClient hangs if Connection closes before RPC call response
[ https://issues.apache.org/jira/browse/HBASE-15278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15263542#comment-15263542 ] Heng Chen commented on HBASE-15278: --- Sound good. > AsyncRPCClient hangs if Connection closes before RPC call response > --- > > Key: HBASE-15278 > URL: https://issues.apache.org/jira/browse/HBASE-15278 > Project: HBase > Issue Type: Bug >Reporter: Enis Soztutar >Priority: Blocker > Fix For: 2.0.0 > > Attachments: HBASE-15278.patch, HBASE-15278_v1.patch, > hbase-15278_v00.patch > > > The test for HBASE-15212 discovered an issue with Async RPC Client. > In that test, we are closing the connection if an RPC call writes a call > larger than max allowed size, the server closes the connection. However the > async client does not seem to handle connection closes with outstanding RPC > calls. The client just hangs. > Marking this blocker against 2.0 since it is default there. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15278) AsyncRPCClient hangs if Connection closes before RPC call response
[ https://issues.apache.org/jira/browse/HBASE-15278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Heng Chen updated HBASE-15278: -- Attachment: HBASE-15278_v1.patch Can't see unexpection exception anymore, Let QA check the patch > AsyncRPCClient hangs if Connection closes before RPC call response > --- > > Key: HBASE-15278 > URL: https://issues.apache.org/jira/browse/HBASE-15278 > Project: HBase > Issue Type: Bug >Reporter: Enis Soztutar >Priority: Blocker > Fix For: 2.0.0 > > Attachments: HBASE-15278.patch, HBASE-15278_v1.patch, > hbase-15278_v00.patch > > > The test for HBASE-15212 discovered an issue with Async RPC Client. > In that test, we are closing the connection if an RPC call writes a call > larger than max allowed size, the server closes the connection. However the > async client does not seem to handle connection closes with outstanding RPC > calls. The client just hangs. > Marking this blocker against 2.0 since it is default there. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15278) AsyncRPCClient hangs if Connection closes before RPC call response
[
https://issues.apache.org/jira/browse/HBASE-15278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15263534#comment-15263534
]
Duo Zhang commented on HBASE-15278:
---
{quote}
The changes in AsyncRpcChannel is just to ensure close be called when
connection closed.
{quote}
Then we could just remove the channelInactive method in
AsyncServerResponseHandler I think.
> AsyncRPCClient hangs if Connection closes before RPC call response
> ---
>
> Key: HBASE-15278
> URL: https://issues.apache.org/jira/browse/HBASE-15278
> Project: HBase
> Issue Type: Bug
>Reporter: Enis Soztutar
>Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: HBASE-15278.patch, hbase-15278_v00.patch
>
>
> The test for HBASE-15212 discovered an issue with Async RPC Client.
> In that test, we are closing the connection if an RPC call writes a call
> larger than max allowed size, the server closes the connection. However the
> async client does not seem to handle connection closes with outstanding RPC
> calls. The client just hangs.
> Marking this blocker against 2.0 since it is default there.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15600) Add provision for adding mutations to memstore or able to write to same region in batchMutate coprocessor hooks
[
https://issues.apache.org/jira/browse/HBASE-15600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15263530#comment-15263530
]
Anoop Sam John commented on HBASE-15600:
bq.acquiredRowLocks.add(getRowLock(mutation.getRow(), true));
If the other jira can committed 1st, we can change here to use
getRowLockInternal?
Also abt the inconsistent ops in doMiniBatch and mutateRows() u plan to raise a
Jira? We can handle that there.
> Add provision for adding mutations to memstore or able to write to same
> region in batchMutate coprocessor hooks
> ---
>
> Key: HBASE-15600
> URL: https://issues.apache.org/jira/browse/HBASE-15600
> Project: HBase
> Issue Type: Improvement
>Reporter: Rajeshbabu Chintaguntla
>Assignee: Rajeshbabu Chintaguntla
> Fix For: 2.0.0, 1.3.0, 1.4.0, 0.98.20
>
> Attachments: HBASE-15600.patch, HBASE-15600_v1.patch,
> HBASE-15600_v2.patch, hbase-15600_v3.patch, hbase-15600_v4.patch,
> hbase-15600_v5.patch
>
>
> As part of PHOENIX-1734 we need to write the index updates to same region
> from coprocessors but writing from batchMutate API is not allowed because of
> mvcc.
> Raised PHOENIX-2742 to discuss any alternative way to write to the same
> region directly or not but not having any proper solution there.
> Currently we have provision to write wal edits from coprocessors. We can set
> wal edits in MiniBatchOperationInProgress.
> {noformat}
> /**
>* Sets the walEdit for the operation(Mutation) at the specified position.
>* @param index
>* @param walEdit
>*/
> public void setWalEdit(int index, WALEdit walEdit) {
> this.walEditsFromCoprocessors[getAbsoluteIndex(index)] = walEdit;
> }
> {noformat}
> Similarly we can allow to write mutations from coprocessors to memstore as
> well. Or else we should provide the batch mutation API allow write in batch
> mutate coprocessors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15703) Deadline scheduler needs to return to the client info about skipped calls, not just drop them
[ https://issues.apache.org/jira/browse/HBASE-15703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15263529#comment-15263529 ] Mikhail Antonov commented on HBASE-15703: - yeah, noticed after i uploaded the patch... > Deadline scheduler needs to return to the client info about skipped calls, > not just drop them > - > > Key: HBASE-15703 > URL: https://issues.apache.org/jira/browse/HBASE-15703 > Project: HBase > Issue Type: Bug > Components: IPC/RPC >Affects Versions: 1.3.0 >Reporter: Mikhail Antonov >Assignee: Mikhail Antonov >Priority: Critical > Fix For: 1.3.0 > > Attachments: HBASE-15703-branch-1.3.v1.patch > > > In AdaptiveLifoCodelCallQueue we drop the calls when we think we're > overloaded, we should instead return CallDroppedException to the cleent or > something. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15600) Add provision for adding mutations to memstore or able to write to same region in batchMutate coprocessor hooks
[
https://issues.apache.org/jira/browse/HBASE-15600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15263528#comment-15263528
]
Anoop Sam John commented on HBASE-15600:
{code}
// we pass (i - firstIndex) below since the call expects a relative index
3128if (miniBatchOp.getOperationsFromCoprocessors(i -
firstIndex) == null) {
3129 continue;
3130}
3131// Else Coprocessor added more Mutations corresponding to
the Mutation at this index.
3132for (int j = 0; j <
miniBatchOp.getOperationsFromCoprocessors(i).length; j++) {
{code}
U changed the index in 1st place but missed the second
"miniBatchOp.getOperationsFromCoprocessors(i)."
Better take this miniBatchOp.getOperationsFromCoprocessors(i - firstIndex)
into a local variable and use that.. Else there is always a chance to miss one
place :-)
> Add provision for adding mutations to memstore or able to write to same
> region in batchMutate coprocessor hooks
> ---
>
> Key: HBASE-15600
> URL: https://issues.apache.org/jira/browse/HBASE-15600
> Project: HBase
> Issue Type: Improvement
>Reporter: Rajeshbabu Chintaguntla
>Assignee: Rajeshbabu Chintaguntla
> Fix For: 2.0.0, 1.3.0, 1.4.0, 0.98.20
>
> Attachments: HBASE-15600.patch, HBASE-15600_v1.patch,
> HBASE-15600_v2.patch, hbase-15600_v3.patch, hbase-15600_v4.patch,
> hbase-15600_v5.patch
>
>
> As part of PHOENIX-1734 we need to write the index updates to same region
> from coprocessors but writing from batchMutate API is not allowed because of
> mvcc.
> Raised PHOENIX-2742 to discuss any alternative way to write to the same
> region directly or not but not having any proper solution there.
> Currently we have provision to write wal edits from coprocessors. We can set
> wal edits in MiniBatchOperationInProgress.
> {noformat}
> /**
>* Sets the walEdit for the operation(Mutation) at the specified position.
>* @param index
>* @param walEdit
>*/
> public void setWalEdit(int index, WALEdit walEdit) {
> this.walEditsFromCoprocessors[getAbsoluteIndex(index)] = walEdit;
> }
> {noformat}
> Similarly we can allow to write mutations from coprocessors to memstore as
> well. Or else we should provide the batch mutation API allow write in batch
> mutate coprocessors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15536) Make AsyncFSWAL as our default WAL
[ https://issues.apache.org/jira/browse/HBASE-15536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15263527#comment-15263527 ] Anoop Sam John commented on HBASE-15536: +1 bq.Recently we observed performance downgrade when using multiwal How many WALs per RS in this test? > Make AsyncFSWAL as our default WAL > -- > > Key: HBASE-15536 > URL: https://issues.apache.org/jira/browse/HBASE-15536 > Project: HBase > Issue Type: Sub-task >Affects Versions: 2.0.0 >Reporter: Duo Zhang >Assignee: Duo Zhang > Fix For: 2.0.0 > > Attachments: HBASE-15536-v1.patch, HBASE-15536-v2.patch, > HBASE-15536.patch > > > As it should be predicated on passing basic cluster ITBLL -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15278) AsyncRPCClient hangs if Connection closes before RPC call response
[
https://issues.apache.org/jira/browse/HBASE-15278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15263525#comment-15263525
]
Heng Chen commented on HBASE-15278:
---
{quote}
Seems the latest patch still modifies AsyncRpcChannel?
{quote}
The changes in AsyncRpcChannel is just to ensure close be called when
connection closed.
{quote}
Could you explain why we can get a exception other than the injected one?
{quote}
It seems like close(null) which i added in AsyncRpcChannel was called before
AsyncServerResponseHandler.exceptionCaught.
But it couldn't reproduced now on my machine, Let me check the logic again.
> AsyncRPCClient hangs if Connection closes before RPC call response
> ---
>
> Key: HBASE-15278
> URL: https://issues.apache.org/jira/browse/HBASE-15278
> Project: HBase
> Issue Type: Bug
>Reporter: Enis Soztutar
>Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: HBASE-15278.patch, hbase-15278_v00.patch
>
>
> The test for HBASE-15212 discovered an issue with Async RPC Client.
> In that test, we are closing the connection if an RPC call writes a call
> larger than max allowed size, the server closes the connection. However the
> async client does not seem to handle connection closes with outstanding RPC
> calls. The client just hangs.
> Marking this blocker against 2.0 since it is default there.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15703) Deadline scheduler needs to return to the client info about skipped calls, not just drop them
[
https://issues.apache.org/jira/browse/HBASE-15703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15263523#comment-15263523
]
Hadoop QA commented on HBASE-15703:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s
{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 14s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
37s {color} | {color:green} branch-1.3 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 39s
{color} | {color:green} branch-1.3 passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 56s
{color} | {color:green} branch-1.3 passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
15s {color} | {color:green} branch-1.3 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
28s {color} | {color:green} branch-1.3 passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
21s {color} | {color:green} branch-1.3 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 29s
{color} | {color:green} branch-1.3 passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 29s
{color} | {color:green} branch-1.3 passed with JDK v1.7.0_79 {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 13s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
29s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 38s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 38s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 10s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 10s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
16s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
33s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
17m 30s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m 1s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 16s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 13s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 56s
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 111m 31s
{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
26s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 156m 39s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12801367/HBASE-15703-branch-1.3.v1.patch
|
| JIRA Issue | HBASE-15703 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
[jira] [Commented] (HBASE-15702) Improve PerClientRandomNonceGenerator
[
https://issues.apache.org/jira/browse/HBASE-15702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15263521#comment-15263521
]
Hadoop QA commented on HBASE-15702:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s
{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
8s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 47s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 21s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
12s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
13s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 4s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 37s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 22s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
21s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 39s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 39s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 17s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 17s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
51s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
11s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
33m 18s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 1m 44s
{color} | {color:red} hbase-client generated 1 new + 0 unchanged - 0 fixed = 1
total (was 0) {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 56s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 29s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 46s
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
32s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 53m 25s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| FindBugs | module:hbase-client |
| | Write to static field
org.apache.hadoop.hbase.client.ConnectionImplementation.nonceGenerator from
instance method new
org.apache.hadoop.hbase.client.ConnectionImplementation(Configuration,
ExecutorService, User) At ConnectionImplementation.java:from instance method
new org.apache.hadoop.hbase.client.ConnectionImplementation(Configuration,
ExecutorService, User) At ConnectionImplementation.java:[line 204] |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12801376/HBASE-15702_v3.patch |
| JIRA Issue | HBASE-15702 |
| Optional Tests | asflicense javac javadoc unit findbugs
[jira] [Updated] (HBASE-15607) Remove PB references from Admin for 2.0
[ https://issues.apache.org/jira/browse/HBASE-15607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-15607: --- Status: Patch Available (was: Open) Sumitting for QA. > Remove PB references from Admin for 2.0 > --- > > Key: HBASE-15607 > URL: https://issues.apache.org/jira/browse/HBASE-15607 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan >Priority: Blocker > Fix For: 2.0.0 > > Attachments: HBASE-15607.patch, HBASE-15607_1.patch, > HBASE-15607_2.patch, HBASE-15607_3.patch, HBASE-15607_3.patch > > > This is a sub-task for HBASE-15174. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15721) Optimization in cloning cells into MSLAB
[
https://issues.apache.org/jira/browse/HBASE-15721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anoop Sam John updated HBASE-15721:
---
Attachment: HBASE-15721_V2.patch
Patch fixing comments from Ram and Ted.
> Optimization in cloning cells into MSLAB
>
>
> Key: HBASE-15721
> URL: https://issues.apache.org/jira/browse/HBASE-15721
> Project: HBase
> Issue Type: Sub-task
> Components: regionserver
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
> Fix For: 2.0.0
>
> Attachments: HBASE-15721.patch, HBASE-15721_V2.patch
>
>
> Before cells added to memstore CSLM, there is a clone of cell after copying
> it to MSLAB chunk area. This is done not in an efficient way.
> {code}
> public static int appendToByteArray(final Cell cell, final byte[] output,
> final int offset) {
> int pos = offset;
> pos = Bytes.putInt(output, pos, keyLength(cell));
> pos = Bytes.putInt(output, pos, cell.getValueLength());
> pos = appendKeyTo(cell, output, pos);
> pos = CellUtil.copyValueTo(cell, output, pos);
> if ((cell.getTagsLength() > 0)) {
> pos = Bytes.putAsShort(output, pos, cell.getTagsLength());
> pos = CellUtil.copyTagTo(cell, output, pos);
> }
> return pos;
> }
> {code}
> Copied in 9 steps and we end up parsing all lengths. When the cell
> implementation is backed by a single byte[] (Like KeyValue) this can be done
> in single step copy.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15703) Deadline scheduler needs to return to the client info about skipped calls, not just drop them
[ https://issues.apache.org/jira/browse/HBASE-15703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15263512#comment-15263512 ] Elliott Clark commented on HBASE-15703: --- Need to add the new exception to the client exceptions util. > Deadline scheduler needs to return to the client info about skipped calls, > not just drop them > - > > Key: HBASE-15703 > URL: https://issues.apache.org/jira/browse/HBASE-15703 > Project: HBase > Issue Type: Bug > Components: IPC/RPC >Affects Versions: 1.3.0 >Reporter: Mikhail Antonov >Assignee: Mikhail Antonov >Priority: Critical > Fix For: 1.3.0 > > Attachments: HBASE-15703-branch-1.3.v1.patch > > > In AdaptiveLifoCodelCallQueue we drop the calls when we think we're > overloaded, we should instead return CallDroppedException to the cleent or > something. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15536) Make AsyncFSWAL as our default WAL
[ https://issues.apache.org/jira/browse/HBASE-15536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15263496#comment-15263496 ] Yu Li commented on HBASE-15536: --- Ah I see, thanks for the note, then I think we also need a solution because our current *from* version don't have HBASE-14949 for sure... Good enough to know that currently no backport work in progress, will get necessary work done and grab some perf number before filing any JIRA. > Make AsyncFSWAL as our default WAL > -- > > Key: HBASE-15536 > URL: https://issues.apache.org/jira/browse/HBASE-15536 > Project: HBase > Issue Type: Sub-task >Affects Versions: 2.0.0 >Reporter: Duo Zhang >Assignee: Duo Zhang > Fix For: 2.0.0 > > Attachments: HBASE-15536-v1.patch, HBASE-15536-v2.patch, > HBASE-15536.patch > > > As it should be predicated on passing basic cluster ITBLL -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15706) HFilePrettyPrinter should print out nicely formatted tags
[
https://issues.apache.org/jira/browse/HBASE-15706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anoop Sam John updated HBASE-15706:
---
Resolution: Fixed
Hadoop Flags: Reviewed
Fix Version/s: 2.0.0
Status: Resolved (was: Patch Available)
Pushed to master. Thanks for the patch.
> HFilePrettyPrinter should print out nicely formatted tags
> -
>
> Key: HBASE-15706
> URL: https://issues.apache.org/jira/browse/HBASE-15706
> Project: HBase
> Issue Type: Improvement
> Components: HFile
>Affects Versions: 2.0.0
>Reporter: huaxiang sun
>Assignee: huaxiang sun
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-15706-v001.patch, HBASE-15706-v002.patch
>
>
> When I was using HFile to print out a rows with tags, the output is like:
> {code}
> hsun-MBP:hbase-2.0.0-SNAPSHOT hsun$ hbase
> org.apache.hadoop.hbase.io.hfile.HFile -f
> /tmp/71afa45b1cb94ea1858a99f31197274f -p
> 2016-04-25 11:40:40,409 WARN [main] util.NativeCodeLoader: Unable to load
> native-hadoop library for your platform... using builtin-java classes where
> applicable
> 2016-04-25 11:40:40,580 INFO [main] hfile.CacheConfig: CacheConfig:disabled
> K: b/b:b/1461608231279/Maximum/vlen=0/seqid=0 V:
> K: b/b:b/1461608231278/Put/vlen=1/seqid=0 V: b T[0]: �
> Scanned kv count -> 2
> {code}
> With attached patch, the print is now like:
> {code}
> 2016-04-25 11:57:05,849 INFO [main] hfile.CacheConfig: CacheConfig:disabled
> K: b/b:b/1461609876838/Maximum/vlen=0/seqid=0 V:
> K: b/b:b/1461609876837/Put/vlen=1/seqid=0 V: b T[0]: [Tag type : 8, value :
> \x00\x0E\xEE\xEE]
> Scanned kv count -> 2
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15732) hbase-rsgroups should be in the assembly
[
https://issues.apache.org/jira/browse/HBASE-15732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15263492#comment-15263492
]
Hudson commented on HBASE-15732:
FAILURE: Integrated in HBase-Trunk_matrix #879 (See
[https://builds.apache.org/job/HBase-Trunk_matrix/879/])
HBASE-15732 hbase-rsgroups should be in the assembly (enis: rev
91291e37803e193b39c1f86219d53ec2d44f0fb1)
* hbase-assembly/pom.xml
* hbase-assembly/src/main/assembly/components.xml
* hbase-assembly/src/main/assembly/hadoop-two-compat.xml
* pom.xml
* hbase-assembly/src/main/assembly/src.xml
> hbase-rsgroups should be in the assembly
> -
>
> Key: HBASE-15732
> URL: https://issues.apache.org/jira/browse/HBASE-15732
> Project: HBase
> Issue Type: Bug
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Fix For: 2.0.0
>
> Attachments: hbase-15732_v1.patch
>
>
> {{hbase-rsgroup}} is a new module that does not appear in the assembly. The
> binary tarball still contains the jars through dependencies, but we need the
> test-jar as well for running the IntegrationTestRSGroup.
> [~toffer] can you take a quick look.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15706) HFilePrettyPrinter should print out nicely formatted tags
[
https://issues.apache.org/jira/browse/HBASE-15706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anoop Sam John updated HBASE-15706:
---
Assignee: huaxiang sun
> HFilePrettyPrinter should print out nicely formatted tags
> -
>
> Key: HBASE-15706
> URL: https://issues.apache.org/jira/browse/HBASE-15706
> Project: HBase
> Issue Type: Improvement
> Components: HFile
>Affects Versions: 2.0.0
>Reporter: huaxiang sun
>Assignee: huaxiang sun
>Priority: Minor
> Attachments: HBASE-15706-v001.patch, HBASE-15706-v002.patch
>
>
> When I was using HFile to print out a rows with tags, the output is like:
> {code}
> hsun-MBP:hbase-2.0.0-SNAPSHOT hsun$ hbase
> org.apache.hadoop.hbase.io.hfile.HFile -f
> /tmp/71afa45b1cb94ea1858a99f31197274f -p
> 2016-04-25 11:40:40,409 WARN [main] util.NativeCodeLoader: Unable to load
> native-hadoop library for your platform... using builtin-java classes where
> applicable
> 2016-04-25 11:40:40,580 INFO [main] hfile.CacheConfig: CacheConfig:disabled
> K: b/b:b/1461608231279/Maximum/vlen=0/seqid=0 V:
> K: b/b:b/1461608231278/Put/vlen=1/seqid=0 V: b T[0]: �
> Scanned kv count -> 2
> {code}
> With attached patch, the print is now like:
> {code}
> 2016-04-25 11:57:05,849 INFO [main] hfile.CacheConfig: CacheConfig:disabled
> K: b/b:b/1461609876838/Maximum/vlen=0/seqid=0 V:
> K: b/b:b/1461609876837/Put/vlen=1/seqid=0 V: b T[0]: [Tag type : 8, value :
> \x00\x0E\xEE\xEE]
> Scanned kv count -> 2
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15706) HFilePrettyPrinter should print out nicely formatted tags
[
https://issues.apache.org/jira/browse/HBASE-15706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15263490#comment-15263490
]
Anoop Sam John commented on HBASE-15706:
+1
> HFilePrettyPrinter should print out nicely formatted tags
> -
>
> Key: HBASE-15706
> URL: https://issues.apache.org/jira/browse/HBASE-15706
> Project: HBase
> Issue Type: Improvement
> Components: HFile
>Affects Versions: 2.0.0
>Reporter: huaxiang sun
>Priority: Minor
> Attachments: HBASE-15706-v001.patch, HBASE-15706-v002.patch
>
>
> When I was using HFile to print out a rows with tags, the output is like:
> {code}
> hsun-MBP:hbase-2.0.0-SNAPSHOT hsun$ hbase
> org.apache.hadoop.hbase.io.hfile.HFile -f
> /tmp/71afa45b1cb94ea1858a99f31197274f -p
> 2016-04-25 11:40:40,409 WARN [main] util.NativeCodeLoader: Unable to load
> native-hadoop library for your platform... using builtin-java classes where
> applicable
> 2016-04-25 11:40:40,580 INFO [main] hfile.CacheConfig: CacheConfig:disabled
> K: b/b:b/1461608231279/Maximum/vlen=0/seqid=0 V:
> K: b/b:b/1461608231278/Put/vlen=1/seqid=0 V: b T[0]: �
> Scanned kv count -> 2
> {code}
> With attached patch, the print is now like:
> {code}
> 2016-04-25 11:57:05,849 INFO [main] hfile.CacheConfig: CacheConfig:disabled
> K: b/b:b/1461609876838/Maximum/vlen=0/seqid=0 V:
> K: b/b:b/1461609876837/Put/vlen=1/seqid=0 V: b T[0]: [Tag type : 8, value :
> \x00\x0E\xEE\xEE]
> Scanned kv count -> 2
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15702) Improve PerClientRandomNonceGenerator
[ https://issues.apache.org/jira/browse/HBASE-15702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Heng Chen updated HBASE-15702: -- Attachment: HBASE-15702_v3.patch Address Ikeda comments about static field. Looks more clean now. > Improve PerClientRandomNonceGenerator > - > > Key: HBASE-15702 > URL: https://issues.apache.org/jira/browse/HBASE-15702 > Project: HBase > Issue Type: Improvement >Reporter: Hiroshi Ikeda >Priority: Trivial > Fix For: 2.0.0 > > Attachments: HBASE-15702.patch, HBASE-15702_v1.patch, > HBASE-15702_v2.patch, HBASE-15702_v3.patch > > > PerClientRandomNonceGenerator can be exposed to all the threads via the > static field ConnectionManager.nonceGenerator, but > PerClientRandomNonceGenerator uses Random, which should be ThreadLocalRandom > or something. (See javadoc of Random.) > Moreover, ConnectionManager creates or refers the singleton instance of > PerClientThreadLocalRandom with a lock or volatile, but it should be created > as a static final field in PerClientThreadLocalRandom itself, and the > creation will be postponed until the field is actually refereed and the class > is being initialized. > The same can be said for ConnectionManager.NoNonceGenerator. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15714) We are calling checkRow() twice in doMiniBatchMutation()
[
https://issues.apache.org/jira/browse/HBASE-15714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Heng Chen updated HBASE-15714:
--
Status: Patch Available (was: Open)
> We are calling checkRow() twice in doMiniBatchMutation()
>
>
> Key: HBASE-15714
> URL: https://issues.apache.org/jira/browse/HBASE-15714
> Project: HBase
> Issue Type: Bug
>Reporter: Enis Soztutar
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-15714.patch, HBASE-15714_v1.patch
>
>
> In {{multi()}} -> {{doMiniBatchMutation()}} code path, we end up calling
> {{checkRow()}} twice, once from {{checkBatchOp()}} and once from
> {{getRowLock()}}.
> See [~anoop.hbase]'s comments at
> https://issues.apache.org/jira/browse/HBASE-15600?focusedCommentId=15257636=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15257636.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15714) We are calling checkRow() twice in doMiniBatchMutation()
[
https://issues.apache.org/jira/browse/HBASE-15714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Heng Chen updated HBASE-15714:
--
Attachment: HBASE-15714_v1.patch
address enis comments.
> We are calling checkRow() twice in doMiniBatchMutation()
>
>
> Key: HBASE-15714
> URL: https://issues.apache.org/jira/browse/HBASE-15714
> Project: HBase
> Issue Type: Bug
>Reporter: Enis Soztutar
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-15714.patch, HBASE-15714_v1.patch
>
>
> In {{multi()}} -> {{doMiniBatchMutation()}} code path, we end up calling
> {{checkRow()}} twice, once from {{checkBatchOp()}} and once from
> {{getRowLock()}}.
> See [~anoop.hbase]'s comments at
> https://issues.apache.org/jira/browse/HBASE-15600?focusedCommentId=15257636=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15257636.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15731) Add on a connection pool
[
https://issues.apache.org/jira/browse/HBASE-15731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15263467#comment-15263467
]
Hadoop QA commented on HBASE-15731:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 4s {color}
| {color:red} HBASE-15731 does not apply to master. Rebase required? Wrong
Branch? See https://yetus.apache.org/documentation/0.2.1/precommit-patchnames
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12801370/HBASE-15731.patch |
| JIRA Issue | HBASE-15731 |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/1663/console |
| Powered by | Apache Yetus 0.2.1 http://yetus.apache.org |
This message was automatically generated.
> Add on a connection pool
>
>
> Key: HBASE-15731
> URL: https://issues.apache.org/jira/browse/HBASE-15731
> Project: HBase
> Issue Type: Sub-task
>Reporter: Elliott Clark
>Assignee: Elliott Clark
> Attachments: HBASE-15731.patch
>
>
> We need to reuse connections so we need a pool
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15600) Add provision for adding mutations to memstore or able to write to same region in batchMutate coprocessor hooks
[
https://issues.apache.org/jira/browse/HBASE-15600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15263466#comment-15263466
]
Hadoop QA commented on HBASE-15600:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
8s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 41s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 32s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 4m
18s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
16s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
52s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 28s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 32s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
42s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 38s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 38s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 32s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 32s
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 4m 41s
{color} | {color:red} hbase-server: patch generated 1 new + 217 unchanged - 1
fixed = 218 total (was 218) {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
16s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
25m 57s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
11s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 29s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 34s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 111m 19s
{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:red}-1{color} | {color:red} asflicense {color} | {color:red} 0m 20s
{color} | {color:red} Patch generated 1 ASF License warnings. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 159m 51s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12801355/hbase-15600_v5.patch |
| JIRA Issue | HBASE-15600 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux asf905.gq1.ygridcore.net 3.13.0-36-lowlatency #63-Ubuntu SMP
PREEMPT Wed Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / 91291e3 |
| Default Java | 1.7.0_79 |
| Multi-JDK versions | /home/jenkins/tools/java/jdk1.8.0:1.8.0
/usr/local/jenkins/java/jdk1.7.0_79:1.7.0_79 |
| findbugs | v3.0.0 |
| checkstyle |
[jira] [Updated] (HBASE-15731) Add on a connection pool
[ https://issues.apache.org/jira/browse/HBASE-15731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark updated HBASE-15731: -- Status: Patch Available (was: Open) https://reviews.facebook.net/D57411 Added on a connection pool using a read write lock. Since most operations will be a read operation this is probably a good enough start. > Add on a connection pool > > > Key: HBASE-15731 > URL: https://issues.apache.org/jira/browse/HBASE-15731 > Project: HBase > Issue Type: Sub-task >Reporter: Elliott Clark >Assignee: Elliott Clark > Attachments: HBASE-15731.patch > > > We need to reuse connections so we need a pool -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15536) Make AsyncFSWAL as our default WAL
[ https://issues.apache.org/jira/browse/HBASE-15536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15263462#comment-15263462 ] Duo Zhang commented on HBASE-15536: --- There is no plan to backport it to branch-1 currently because of the compatibility issues. As said in HBASE-14949, if you want to do rolling upgrade to use AsyncFSWAL, then the from and to versions must both have HBASE-14949 in it, otherwise we may lose data. So it will break the compatibility guarantee if we backport AsyncFSWAL to branch-1... I think you can file a backport issue to see what others think of it. Thanks. > Make AsyncFSWAL as our default WAL > -- > > Key: HBASE-15536 > URL: https://issues.apache.org/jira/browse/HBASE-15536 > Project: HBase > Issue Type: Sub-task >Affects Versions: 2.0.0 >Reporter: Duo Zhang >Assignee: Duo Zhang > Fix For: 2.0.0 > > Attachments: HBASE-15536-v1.patch, HBASE-15536-v2.patch, > HBASE-15536.patch > > > As it should be predicated on passing basic cluster ITBLL -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15536) Make AsyncFSWAL as our default WAL
[ https://issues.apache.org/jira/browse/HBASE-15536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15263454#comment-15263454 ] Yu Li commented on HBASE-15536: --- +1 (non-binding) to make AsyncFSWAL as default in 2.0 [~Apache9] Any plan to backport the great work here to branch-1? We're planning to use AsyncFSWAL online by July (well, I'd say the perf number is really attractive. :-D) and will start the work soon but duplicated work is no good, so please let me know if you already got anything in progress for the backport work. Thanks. :-) OTOH, it would be great if there could be some perf number on multiwal in comparison to single-wal with AsyncFSWAL. Recently we observed performance downgrade when using multiwal (with FSHLog) in branch-1 and now trying hard to locate the root cause (will open another JIRA to tell the details), so I'm a little bit concerned about the multiwal part. > Make AsyncFSWAL as our default WAL > -- > > Key: HBASE-15536 > URL: https://issues.apache.org/jira/browse/HBASE-15536 > Project: HBase > Issue Type: Sub-task >Affects Versions: 2.0.0 >Reporter: Duo Zhang >Assignee: Duo Zhang > Fix For: 2.0.0 > > Attachments: HBASE-15536-v1.patch, HBASE-15536-v2.patch, > HBASE-15536.patch > > > As it should be predicated on passing basic cluster ITBLL -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15731) Add on a connection pool
[ https://issues.apache.org/jira/browse/HBASE-15731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark updated HBASE-15731: -- Attachment: HBASE-15731.patch > Add on a connection pool > > > Key: HBASE-15731 > URL: https://issues.apache.org/jira/browse/HBASE-15731 > Project: HBase > Issue Type: Sub-task >Reporter: Elliott Clark >Assignee: Elliott Clark > Attachments: HBASE-15731.patch > > > We need to reuse connections so we need a pool -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15675) Add more details about region on table.jsp
[ https://issues.apache.org/jira/browse/HBASE-15675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15263423#comment-15263423 ] Yu Li commented on HBASE-15675: --- Ping [~stack], [~enis] and [~eclark], ok for me to commit this one? Will wait for one more day and get it in if no objections, thanks. :-) > Add more details about region on table.jsp > -- > > Key: HBASE-15675 > URL: https://issues.apache.org/jira/browse/HBASE-15675 > Project: HBase > Issue Type: Sub-task >Reporter: Yu Li >Assignee: Yu Li > Attachments: HBASE-15675.patch, HBASE-15675_v2.patch, > HBASE-15675_v3.patch, HBASE-15675_v4.patch, new_table_jsp.png, > new_table_jsp_v2.png, new_table_jsp_v3.png, region server screenshot.jpg > > > After this JIRA, more information would be displayed on table.jsp or say > table details page, including: RegionSize, MemSize, FileNum, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15711) Add client side property to allow logging details for batch errors
[
https://issues.apache.org/jira/browse/HBASE-15711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yu Li updated HBASE-15711:
--
Resolution: Fixed
Hadoop Flags: Reviewed
Fix Version/s: 1.4.0
2.0.0
Status: Resolved (was: Patch Available)
Pushed commit into master and branch-1
> Add client side property to allow logging details for batch errors
> --
>
> Key: HBASE-15711
> URL: https://issues.apache.org/jira/browse/HBASE-15711
> Project: HBase
> Issue Type: Bug
>Reporter: Yu Li
>Assignee: Yu Li
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-15711.patch
>
>
> Recently we observed below error message on client side when put process
> blocked:
> {noformat}
> 2016-04-26 10:27:11,707 ERROR [Sink: Unnamed (1/1)]
> com.alibaba.search.blink.streaming.connector.hbase.HBaseOutputFormat: Doing
> mutation failed
> org.apache.hadoop.hbase.client.RetriesExhaustedWithDetailsException: Failed 1
> action: IOException: 1 time,
> at
> org.apache.hadoop.hbase.client.AsyncProcess$BatchErrors.makeException(AsyncProcess.java:228)
> at
> org.apache.hadoop.hbase.client.AsyncProcess$BatchErrors.access$1700(AsyncProcess.java:208)
> at
> org.apache.hadoop.hbase.client.AsyncProcess.waitForAllPreviousOpsAndReset(AsyncProcess.java:1694)
> at
> org.apache.hadoop.hbase.client.BufferedMutatorImpl.backgroundFlushCommits(BufferedMutatorImpl.java:208)
> at
> org.apache.hadoop.hbase.client.BufferedMutatorImpl.flush(BufferedMutatorImpl.java:183)
> {noformat}
> And checking RS logs we found nothing noticable. After adding some logging to
> show the detailed exception, it turns out something went wrong in one of our
> coprocessors:
> {noformat}
> 2016-04-26 12:03:13,776 ERROR [Sink: Unnamed (1/1)]
> org.apache.hadoop.hbase.client.AsyncProcess: Exception occurred! Exception
> details: [java.io.IOException: java.io.IOException: notify meta has not load
> success.
> at
> com.taobao.kart.coprocessor.server.CoprocessorNotifyMeta.checkMetaLoadSuccess(CoprocessorNotifyMeta.java:38)
> at
> com.taobao.kart.coprocessor.server.NotifyQualifySetter.updatePut(NotifyQualifySetter.java:47)
> at
> com.taobao.kart.coprocessor.server.NotifyQualifySetter.updatePut(NotifyQualifySetter.java:39)
> at
> com.taobao.kart.coprocessor.server.KartCoprocessor.prePut(KartCoprocessor.java:176)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost$30.call(RegionCoprocessorHost.java:902)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost$RegionOperation.call(RegionCoprocessorHost.java:1673)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.execOperation(RegionCoprocessorHost.java:1748)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.execOperation(RegionCoprocessorHost.java:1705)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.prePut(RegionCoprocessorHost.java:898)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.doPreMutationHook(HRegion.java:2890)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.batchMutate(HRegion.java:2865)
> {noformat}
> So in this JIRA we propose to add a property to allow logging detailed
> exception stacktrace rather than statistics for batch errors, and I believe
> this would be useful for debugging in some cases.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15536) Make AsyncFSWAL as our default WAL
[
https://issues.apache.org/jira/browse/HBASE-15536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15263410#comment-15263410
]
Duo Zhang commented on HBASE-15536:
---
{quote}
Maybe add a note on commit to the DefaultWALProvider about this 'odd' fact.
{quote}
I think we could change the name of DefaultWALProvider to a more reasonable
name, but still map 'o.a.h.h.regionserver.wal.DefaultWALProvider' to the
renamed class. This does not break the config compatibility.
{quote}
Any place you know where we are missing coverage? Any secure deploy type? Or a
deploy type that needs more testing? Could file an issue for such 'weak' areas.
{quote}
Two things I can tell right now.
First is what if the whole HDFS crashes. Of course we can say that if HDFS
crashes then we can not guarantee much since we heavily rely on HDFS. But if
the behavior is changed then the end users may need to change their maintain
guide of how to deal with HDFS crash.
Second is the performance of secure output.
Thanks.
> Make AsyncFSWAL as our default WAL
> --
>
> Key: HBASE-15536
> URL: https://issues.apache.org/jira/browse/HBASE-15536
> Project: HBase
> Issue Type: Sub-task
>Affects Versions: 2.0.0
>Reporter: Duo Zhang
>Assignee: Duo Zhang
> Fix For: 2.0.0
>
> Attachments: HBASE-15536-v1.patch, HBASE-15536-v2.patch,
> HBASE-15536.patch
>
>
> As it should be predicated on passing basic cluster ITBLL
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15711) Add client side property to allow logging details for batch errors
[
https://issues.apache.org/jira/browse/HBASE-15711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yu Li updated HBASE-15711:
--
Release Note: In HBASE-15711 a new client side property
hbase.client.log.batcherrors.details is introduced to allow logging full
stacktrace of exceptions for batch error. It's disabled by default and set the
property to true will enable it.
Add some document in release note.
> Add client side property to allow logging details for batch errors
> --
>
> Key: HBASE-15711
> URL: https://issues.apache.org/jira/browse/HBASE-15711
> Project: HBase
> Issue Type: Bug
>Reporter: Yu Li
>Assignee: Yu Li
> Attachments: HBASE-15711.patch
>
>
> Recently we observed below error message on client side when put process
> blocked:
> {noformat}
> 2016-04-26 10:27:11,707 ERROR [Sink: Unnamed (1/1)]
> com.alibaba.search.blink.streaming.connector.hbase.HBaseOutputFormat: Doing
> mutation failed
> org.apache.hadoop.hbase.client.RetriesExhaustedWithDetailsException: Failed 1
> action: IOException: 1 time,
> at
> org.apache.hadoop.hbase.client.AsyncProcess$BatchErrors.makeException(AsyncProcess.java:228)
> at
> org.apache.hadoop.hbase.client.AsyncProcess$BatchErrors.access$1700(AsyncProcess.java:208)
> at
> org.apache.hadoop.hbase.client.AsyncProcess.waitForAllPreviousOpsAndReset(AsyncProcess.java:1694)
> at
> org.apache.hadoop.hbase.client.BufferedMutatorImpl.backgroundFlushCommits(BufferedMutatorImpl.java:208)
> at
> org.apache.hadoop.hbase.client.BufferedMutatorImpl.flush(BufferedMutatorImpl.java:183)
> {noformat}
> And checking RS logs we found nothing noticable. After adding some logging to
> show the detailed exception, it turns out something went wrong in one of our
> coprocessors:
> {noformat}
> 2016-04-26 12:03:13,776 ERROR [Sink: Unnamed (1/1)]
> org.apache.hadoop.hbase.client.AsyncProcess: Exception occurred! Exception
> details: [java.io.IOException: java.io.IOException: notify meta has not load
> success.
> at
> com.taobao.kart.coprocessor.server.CoprocessorNotifyMeta.checkMetaLoadSuccess(CoprocessorNotifyMeta.java:38)
> at
> com.taobao.kart.coprocessor.server.NotifyQualifySetter.updatePut(NotifyQualifySetter.java:47)
> at
> com.taobao.kart.coprocessor.server.NotifyQualifySetter.updatePut(NotifyQualifySetter.java:39)
> at
> com.taobao.kart.coprocessor.server.KartCoprocessor.prePut(KartCoprocessor.java:176)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost$30.call(RegionCoprocessorHost.java:902)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost$RegionOperation.call(RegionCoprocessorHost.java:1673)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.execOperation(RegionCoprocessorHost.java:1748)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.execOperation(RegionCoprocessorHost.java:1705)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.prePut(RegionCoprocessorHost.java:898)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.doPreMutationHook(HRegion.java:2890)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.batchMutate(HRegion.java:2865)
> {noformat}
> So in this JIRA we propose to add a property to allow logging detailed
> exception stacktrace rather than statistics for batch errors, and I believe
> this would be useful for debugging in some cases.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15703) Deadline scheduler needs to return to the client info about skipped calls, not just drop them
[ https://issues.apache.org/jira/browse/HBASE-15703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15263407#comment-15263407 ] Mikhail Antonov commented on HBASE-15703: - obviously, CDE shouldn't clear meta cache, will update patch > Deadline scheduler needs to return to the client info about skipped calls, > not just drop them > - > > Key: HBASE-15703 > URL: https://issues.apache.org/jira/browse/HBASE-15703 > Project: HBase > Issue Type: Bug > Components: IPC/RPC >Affects Versions: 1.3.0 >Reporter: Mikhail Antonov >Assignee: Mikhail Antonov >Priority: Critical > Fix For: 1.3.0 > > Attachments: HBASE-15703-branch-1.3.v1.patch > > > In AdaptiveLifoCodelCallQueue we drop the calls when we think we're > overloaded, we should instead return CallDroppedException to the cleent or > something. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15703) Deadline scheduler needs to return to the client info about skipped calls, not just drop them
[ https://issues.apache.org/jira/browse/HBASE-15703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Antonov updated HBASE-15703: Status: Patch Available (was: Open) > Deadline scheduler needs to return to the client info about skipped calls, > not just drop them > - > > Key: HBASE-15703 > URL: https://issues.apache.org/jira/browse/HBASE-15703 > Project: HBase > Issue Type: Bug > Components: IPC/RPC >Affects Versions: 1.3.0 >Reporter: Mikhail Antonov >Assignee: Mikhail Antonov >Priority: Critical > Fix For: 1.3.0 > > Attachments: HBASE-15703-branch-1.3.v1.patch > > > In AdaptiveLifoCodelCallQueue we drop the calls when we think we're > overloaded, we should instead return CallDroppedException to the cleent or > something. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15703) Deadline scheduler needs to return to the client info about skipped calls, not just drop them
[ https://issues.apache.org/jira/browse/HBASE-15703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Antonov updated HBASE-15703: Attachment: HBASE-15703-branch-1.3.v1.patch > Deadline scheduler needs to return to the client info about skipped calls, > not just drop them > - > > Key: HBASE-15703 > URL: https://issues.apache.org/jira/browse/HBASE-15703 > Project: HBase > Issue Type: Bug > Components: IPC/RPC >Affects Versions: 1.3.0 >Reporter: Mikhail Antonov >Assignee: Mikhail Antonov >Priority: Critical > Fix For: 1.3.0 > > Attachments: HBASE-15703-branch-1.3.v1.patch > > > In AdaptiveLifoCodelCallQueue we drop the calls when we think we're > overloaded, we should instead return CallDroppedException to the cleent or > something. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15551) Make call queue too big exception use servername
[
https://issues.apache.org/jira/browse/HBASE-15551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15263351#comment-15263351
]
Hadoop QA commented on HBASE-15551:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s
{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
34s {color} | {color:green} branch-1.3 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 58s
{color} | {color:green} branch-1.3 passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 45s
{color} | {color:green} branch-1.3 passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
21s {color} | {color:green} branch-1.3 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
27s {color} | {color:green} branch-1.3 passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
38s {color} | {color:green} branch-1.3 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 52s
{color} | {color:green} branch-1.3 passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 48s
{color} | {color:green} branch-1.3 passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
59s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 57s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 57s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 45s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 45s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
16s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
20s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
16m 54s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 3m 12s
{color} | {color:red} hbase-server generated 1 new + 0 unchanged - 0 fixed = 1
total (was 0) {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 44s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 47s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 105m 53s
{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
28s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 144m 21s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| FindBugs | module:hbase-server |
| | Dead store to address in
org.apache.hadoop.hbase.ipc.RpcServer$Connection.processRequest(ByteBuffer) At
RpcServer.java:org.apache.hadoop.hbase.ipc.RpcServer$Connection.processRequest(ByteBuffer)
At RpcServer.java:[line 1866] |
| Failed junit tests | hadoop.hbase.regionserver.TestAtomicOperation |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12801335/HBASE-15551-branch-1.3.v1.patch
|
| JIRA Issue | HBASE-15551 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux
[jira] [Updated] (HBASE-15600) Add provision for adding mutations to memstore or able to write to same region in batchMutate coprocessor hooks
[
https://issues.apache.org/jira/browse/HBASE-15600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Enis Soztutar updated HBASE-15600:
--
Attachment: hbase-15600_v5.patch
v5 patch. Fixes the bug reported by Anoop, and addresses Ram's comment.
> Add provision for adding mutations to memstore or able to write to same
> region in batchMutate coprocessor hooks
> ---
>
> Key: HBASE-15600
> URL: https://issues.apache.org/jira/browse/HBASE-15600
> Project: HBase
> Issue Type: Improvement
>Reporter: Rajeshbabu Chintaguntla
>Assignee: Rajeshbabu Chintaguntla
> Fix For: 2.0.0, 1.3.0, 1.4.0, 0.98.20
>
> Attachments: HBASE-15600.patch, HBASE-15600_v1.patch,
> HBASE-15600_v2.patch, hbase-15600_v3.patch, hbase-15600_v4.patch,
> hbase-15600_v5.patch
>
>
> As part of PHOENIX-1734 we need to write the index updates to same region
> from coprocessors but writing from batchMutate API is not allowed because of
> mvcc.
> Raised PHOENIX-2742 to discuss any alternative way to write to the same
> region directly or not but not having any proper solution there.
> Currently we have provision to write wal edits from coprocessors. We can set
> wal edits in MiniBatchOperationInProgress.
> {noformat}
> /**
>* Sets the walEdit for the operation(Mutation) at the specified position.
>* @param index
>* @param walEdit
>*/
> public void setWalEdit(int index, WALEdit walEdit) {
> this.walEditsFromCoprocessors[getAbsoluteIndex(index)] = walEdit;
> }
> {noformat}
> Similarly we can allow to write mutations from coprocessors to memstore as
> well. Or else we should provide the batch mutation API allow write in batch
> mutate coprocessors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15600) Add provision for adding mutations to memstore or able to write to same region in batchMutate coprocessor hooks
[
https://issues.apache.org/jira/browse/HBASE-15600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15263323#comment-15263323
]
Enis Soztutar commented on HBASE-15600:
---
bq. So the added mutations are or no use. Ya thing is we can avoid the not
useful work of this merge. Chances are less user will do such things
You are right, we do not seem to be needing this for correctness. Added the
check in v5 at the start of the iteration just to avoid potential double work.
> Add provision for adding mutations to memstore or able to write to same
> region in batchMutate coprocessor hooks
> ---
>
> Key: HBASE-15600
> URL: https://issues.apache.org/jira/browse/HBASE-15600
> Project: HBase
> Issue Type: Improvement
>Reporter: Rajeshbabu Chintaguntla
>Assignee: Rajeshbabu Chintaguntla
> Fix For: 2.0.0, 1.3.0, 1.4.0, 0.98.20
>
> Attachments: HBASE-15600.patch, HBASE-15600_v1.patch,
> HBASE-15600_v2.patch, hbase-15600_v3.patch, hbase-15600_v4.patch
>
>
> As part of PHOENIX-1734 we need to write the index updates to same region
> from coprocessors but writing from batchMutate API is not allowed because of
> mvcc.
> Raised PHOENIX-2742 to discuss any alternative way to write to the same
> region directly or not but not having any proper solution there.
> Currently we have provision to write wal edits from coprocessors. We can set
> wal edits in MiniBatchOperationInProgress.
> {noformat}
> /**
>* Sets the walEdit for the operation(Mutation) at the specified position.
>* @param index
>* @param walEdit
>*/
> public void setWalEdit(int index, WALEdit walEdit) {
> this.walEditsFromCoprocessors[getAbsoluteIndex(index)] = walEdit;
> }
> {noformat}
> Similarly we can allow to write mutations from coprocessors to memstore as
> well. Or else we should provide the batch mutation API allow write in batch
> mutate coprocessors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15732) hbase-rsgroups should be in the assembly
[
https://issues.apache.org/jira/browse/HBASE-15732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Enis Soztutar updated HBASE-15732:
--
Resolution: Fixed
Hadoop Flags: Reviewed
Status: Resolved (was: Patch Available)
Committed. Thanks Francis for taking a look. Agreed on the branch-1 backport.
> hbase-rsgroups should be in the assembly
> -
>
> Key: HBASE-15732
> URL: https://issues.apache.org/jira/browse/HBASE-15732
> Project: HBase
> Issue Type: Bug
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Fix For: 2.0.0
>
> Attachments: hbase-15732_v1.patch
>
>
> {{hbase-rsgroup}} is a new module that does not appear in the assembly. The
> binary tarball still contains the jars through dependencies, but we need the
> test-jar as well for running the IntegrationTestRSGroup.
> [~toffer] can you take a quick look.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (HBASE-15734) Propagate exception in table backup procedures
Ted Yu created HBASE-15734:
--
Summary: Propagate exception in table backup procedures
Key: HBASE-15734
URL: https://issues.apache.org/jira/browse/HBASE-15734
Project: HBase
Issue Type: Bug
Reporter: Ted Yu
Assignee: Ted Yu
Attachments: 15734.v1.txt
Currently we have the following in XXTableBackupProcedure:
{code}
} catch (Exception e) {
// fail the overall backup and return
failBackup(env, backupInfo, backupManager, e, "Unexpected
BackupException : ",
BackupType.FULL, conf);
return Flow.NO_MORE_STATE;
{code}
However, failBackup() doesn't propagate the exception to procedure V2.
This issue is to add setFailure() calls for the propagation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15734) Propagate exception in table backup procedures
[
https://issues.apache.org/jira/browse/HBASE-15734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-15734:
---
Attachment: 15734.v1.txt
> Propagate exception in table backup procedures
> --
>
> Key: HBASE-15734
> URL: https://issues.apache.org/jira/browse/HBASE-15734
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Labels: backup
> Attachments: 15734.v1.txt
>
>
> Currently we have the following in XXTableBackupProcedure:
> {code}
> } catch (Exception e) {
> // fail the overall backup and return
> failBackup(env, backupInfo, backupManager, e, "Unexpected
> BackupException : ",
> BackupType.FULL, conf);
> return Flow.NO_MORE_STATE;
> {code}
> However, failBackup() doesn't propagate the exception to procedure V2.
> This issue is to add setFailure() calls for the propagation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15551) Make call queue too big exception use servername
[ https://issues.apache.org/jira/browse/HBASE-15551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15263236#comment-15263236 ] Gary Helmling commented on HBASE-15551: --- +1 if you fix that up on commit > Make call queue too big exception use servername > > > Key: HBASE-15551 > URL: https://issues.apache.org/jira/browse/HBASE-15551 > Project: HBase > Issue Type: Improvement >Affects Versions: 1.2.0 >Reporter: Elliott Clark >Assignee: Mikhail Antonov >Priority: Minor > Fix For: 1.3.0 > > Attachments: HBASE-15551-branch-1.3.v1.patch > > > If the rpc server is listening to something other than the hostname ( 0.0.0.0 > for example ) then the exception thrown isn't very helpful. We should make > that more helpful. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15281) Allow the FileSystem inside HFileSystem to be wrapped
[ https://issues.apache.org/jira/browse/HBASE-15281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15263231#comment-15263231 ] Mikhail Antonov commented on HBASE-15281: - Skimmed, looks good to me; will look more (maybe move constant out) and commit later unless objections. > Allow the FileSystem inside HFileSystem to be wrapped > - > > Key: HBASE-15281 > URL: https://issues.apache.org/jira/browse/HBASE-15281 > Project: HBase > Issue Type: New Feature > Components: Filesystem Integration, hbase >Affects Versions: 2.0.0, 1.2.0 >Reporter: Rajesh Nishtala >Assignee: Rajesh Nishtala > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-15281-v1.patch > > > It would be very useful for us to be able to wrap the filesystems > encapsulated by HFileSystem with other FilterFileSystems. This allows for > more detailed logging of the operations to the DFS. Internally, the data > logged from this method has allowed us to show application engineers where > there schemas are inefficient and inducing too much IO. This patch will just > allow the filesystem to be pluggable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15281) Allow the FileSystem inside HFileSystem to be wrapped
[
https://issues.apache.org/jira/browse/HBASE-15281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15263217#comment-15263217
]
Hadoop QA commented on HBASE-15281:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s
{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
0s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 57s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 37s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 4m
41s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
17s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
18s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 39s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 45s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
56s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 2s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 2s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 44s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 44s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 5m
38s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
19s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
34m 56s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m 8s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 53s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 48s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 140m 3s {color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
19s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 203m 34s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Timed out junit tests |
org.apache.hadoop.hbase.snapshot.TestMobFlushSnapshotFromClient |
| | org.apache.hadoop.hbase.snapshot.TestFlushSnapshotFromClient |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12788276/HBASE-15281-v1.patch |
| JIRA Issue | HBASE-15281 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux asf910.gq1.ygridcore.net 3.13.0-36-lowlatency #63-Ubuntu SMP
PREEMPT Wed Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git
[jira] [Commented] (HBASE-15551) Make call queue too big exception use servername
[
https://issues.apache.org/jira/browse/HBASE-15551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15263215#comment-15263215
]
Gary Helmling commented on HBASE-15551:
---
I think you can drop this line as well:
{code}
InetSocketAddress address = getListenerAddress();
{code}
> Make call queue too big exception use servername
>
>
> Key: HBASE-15551
> URL: https://issues.apache.org/jira/browse/HBASE-15551
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 1.2.0
>Reporter: Elliott Clark
>Assignee: Mikhail Antonov
>Priority: Minor
> Fix For: 1.3.0
>
> Attachments: HBASE-15551-branch-1.3.v1.patch
>
>
> If the rpc server is listening to something other than the hostname ( 0.0.0.0
> for example ) then the exception thrown isn't very helpful. We should make
> that more helpful.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15686) Add override mechanism for the exempt classes when dynamically loading table coprocessor
[
https://issues.apache.org/jira/browse/HBASE-15686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15263181#comment-15263181
]
Hudson commented on HBASE-15686:
SUCCESS: Integrated in HBase-1.4 #124 (See
[https://builds.apache.org/job/HBase-1.4/124/])
HBASE-15686 Add override mechanism for the exempt classes when (tedyu: rev
c512750914bb3e7075bd61b9ea4d911da662be38)
*
hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/CoprocessorHost.java
*
hbase-common/src/main/java/org/apache/hadoop/hbase/util/CoprocessorClassLoader.java
* hbase-common/src/main/java/org/apache/hadoop/hbase/HConstants.java
> Add override mechanism for the exempt classes when dynamically loading table
> coprocessor
>
>
> Key: HBASE-15686
> URL: https://issues.apache.org/jira/browse/HBASE-15686
> Project: HBase
> Issue Type: Improvement
> Components: Coprocessors
>Affects Versions: 1.0.1
>Reporter: Sangjin Lee
>Assignee: Ted Yu
> Fix For: 2.0.0, 1.4.0
>
> Attachments: 15686.v2.txt, 15686.v3.txt, 15686.v4.txt, 15686.v5.txt,
> 15686.v6.txt, 15686.wip
>
>
> As part of Hadoop's Timeline Service v.2 (YARN-2928), we're adding a table
> coprocessor (YARN-4062). However, we're finding that the coprocessor cannot
> be loaded dynamically. A relevant snippet for the exception:
> {noformat}
> java.io.IOException: Class
> org.apache.hadoop.yarn.server.timelineservice.storage.flow.FlowRunCoprocessor
> cannot be loaded
> at
> org.apache.hadoop.hbase.master.HMaster.sanityCheckTableDescriptor(HMaster.java:1329)
> at org.apache.hadoop.hbase.master.HMaster.createTable(HMaster.java:1269)
> at
> org.apache.hadoop.hbase.master.MasterRpcServices.createTable(MasterRpcServices.java:398)
> at
> org.apache.hadoop.hbase.protobuf.generated.MasterProtos$MasterService$2.callBlockingMethod(MasterProtos.java:42436)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2031)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:107)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(RpcExecutor.java:130)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$1.run(RpcExecutor.java:107)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.io.IOException: Class
> org.apache.hadoop.yarn.server.timelineservice.storage.flow.FlowRunCoprocessor
> cannot be loaded
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.testTableCoprocessorAttrs(RegionCoprocessorHost.java:324)
> at
> org.apache.hadoop.hbase.master.HMaster.checkClassLoading(HMaster.java:1483)
> at
> org.apache.hadoop.hbase.master.HMaster.sanityCheckTableDescriptor(HMaster.java:1327)
> ... 8 more
> Caused by: java.lang.ClassNotFoundException:
> org.apache.hadoop.yarn.server.timelineservice.storage.flow.FlowRunCoprocessor
> at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> at
> org.apache.hadoop.hbase.util.CoprocessorClassLoader.loadClass(CoprocessorClassLoader.java:275)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.testTableCoprocessorAttrs(RegionCoprocessorHost.java:322)
> ... 10 more
> {noformat}
> We tracked it down to the fact that {{CoprocessorClassLoader}} regarding all
> hadoop classes as exempt from loading from the coprocessor jar. Since our
> coprocessor sits in the coprocessor jar, and yet the loading of this class is
> delegated to the parent which does not have this jar, the classloading fails.
> What would be nice is the ability to exclude certain classes from the exempt
> classes so that they can be loaded via table coprocessor classloader. See
> hadoop's {{ApplicationClassLoader}} for a similar feature.
> Is there any other way to load this coprocessor at the table scope?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15706) HFilePrettyPrinter should print out nicely formatted tags
[
https://issues.apache.org/jira/browse/HBASE-15706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15263173#comment-15263173
]
Hadoop QA commented on HBASE-15706:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s
{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 11s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
54s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 3s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 49s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
16s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
24s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
34s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 50s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 48s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 10s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
58s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 6s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 6s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 50s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 50s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
18s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
24s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
28m 23s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m 7s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 50s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 49s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 43s
{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 101m 18s
{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
27s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 155m 0s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.security.access.TestNamespaceCommands |
| | hadoop.hbase.security.access.TestAccessController3 |
| Timed out junit tests |
org.apache.hadoop.hbase.snapshot.TestMobFlushSnapshotFromClient |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
[jira] [Commented] (HBASE-15732) hbase-rsgroups should be in the assembly
[
https://issues.apache.org/jira/browse/HBASE-15732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15263160#comment-15263160
]
Hadoop QA commented on HBASE-15732:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s
{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 37s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
1s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m 46s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m 45s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
12s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m 41s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 51s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 11s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
53s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 4m 2s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 4m 2s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m 33s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m 33s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
13s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m 2s
{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
26m 44s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 42s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 29s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 14s
{color} | {color:green} hbase-assembly in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 102m 48s
{color} | {color:red} root in the patch failed. {color} |
| {color:red}-1{color} | {color:red} asflicense {color} | {color:red} 0m 33s
{color} | {color:red} Patch generated 1 ASF License warnings. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 164m 34s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.security.access.TestNamespaceCommands |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12801293/hbase-15732_v1.patch |
| JIRA Issue | HBASE-15732 |
| Optional Tests | asflicense javac javadoc unit xml compile |
| uname | Linux pietas.apache.org 3.13.0-36-lowlatency #63-Ubuntu SMP PREEMPT
Wed Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / 8a28c23 |
| Default Java | 1.7.0_79 |
| Multi-JDK versions | /home/jenkins/tools/java/jdk1.8.0:1.8.0
/usr/local/jenkins/java/jdk1.7.0_79:1.7.0_79 |
| unit |
[jira] [Updated] (HBASE-15551) Make call queue too big exception use servername
[ https://issues.apache.org/jira/browse/HBASE-15551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Antonov updated HBASE-15551: Status: Patch Available (was: Open) > Make call queue too big exception use servername > > > Key: HBASE-15551 > URL: https://issues.apache.org/jira/browse/HBASE-15551 > Project: HBase > Issue Type: Improvement >Affects Versions: 1.2.0 >Reporter: Elliott Clark >Assignee: Mikhail Antonov >Priority: Minor > Fix For: 1.3.0 > > Attachments: HBASE-15551-branch-1.3.v1.patch > > > If the rpc server is listening to something other than the hostname ( 0.0.0.0 > for example ) then the exception thrown isn't very helpful. We should make > that more helpful. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (HBASE-15551) Make call queue too big exception use servername
[ https://issues.apache.org/jira/browse/HBASE-15551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Antonov reassigned HBASE-15551: --- Assignee: Mikhail Antonov > Make call queue too big exception use servername > > > Key: HBASE-15551 > URL: https://issues.apache.org/jira/browse/HBASE-15551 > Project: HBase > Issue Type: Improvement >Affects Versions: 1.2.0 >Reporter: Elliott Clark >Assignee: Mikhail Antonov >Priority: Minor > Fix For: 1.3.0 > > Attachments: HBASE-15551-branch-1.3.v1.patch > > > If the rpc server is listening to something other than the hostname ( 0.0.0.0 > for example ) then the exception thrown isn't very helpful. We should make > that more helpful. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15551) Make call queue too big exception use servername
[ https://issues.apache.org/jira/browse/HBASE-15551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Antonov updated HBASE-15551: Attachment: HBASE-15551-branch-1.3.v1.patch > Make call queue too big exception use servername > > > Key: HBASE-15551 > URL: https://issues.apache.org/jira/browse/HBASE-15551 > Project: HBase > Issue Type: Improvement >Affects Versions: 1.2.0 >Reporter: Elliott Clark >Assignee: Mikhail Antonov >Priority: Minor > Fix For: 1.3.0 > > Attachments: HBASE-15551-branch-1.3.v1.patch > > > If the rpc server is listening to something other than the hostname ( 0.0.0.0 > for example ) then the exception thrown isn't very helpful. We should make > that more helpful. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15551) Make call queue too big exception use servername
[ https://issues.apache.org/jira/browse/HBASE-15551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Antonov updated HBASE-15551: Fix Version/s: 1.3.0 > Make call queue too big exception use servername > > > Key: HBASE-15551 > URL: https://issues.apache.org/jira/browse/HBASE-15551 > Project: HBase > Issue Type: Improvement >Affects Versions: 1.2.0 >Reporter: Elliott Clark >Priority: Minor > Fix For: 1.3.0 > > > If the rpc server is listening to something other than the hostname ( 0.0.0.0 > for example ) then the exception thrown isn't very helpful. We should make > that more helpful. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13979) Move out the lowReplication roll form FSHLog to be reusable
[ https://issues.apache.org/jira/browse/HBASE-13979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matteo Bertozzi updated HBASE-13979: Fix Version/s: (was: 1.3.0) > Move out the lowReplication roll form FSHLog to be reusable > --- > > Key: HBASE-13979 > URL: https://issues.apache.org/jira/browse/HBASE-13979 > Project: HBase > Issue Type: Improvement >Affects Versions: 1.2.0 >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi >Priority: Trivial > Fix For: 2.0.0 > > Attachments: HBASE-13979-v0.patch > > > I'd like to reuse the low-replication detection and log roll logic used in > the FSHLog. most of that logic doesn't know about Region or WALEdits, so we > can move it out. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15607) Remove PB references from Admin for 2.0
[ https://issues.apache.org/jira/browse/HBASE-15607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15263049#comment-15263049 ] Enis Soztutar commented on HBASE-15607: --- lgtm. > Remove PB references from Admin for 2.0 > --- > > Key: HBASE-15607 > URL: https://issues.apache.org/jira/browse/HBASE-15607 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan >Priority: Blocker > Fix For: 2.0.0 > > Attachments: HBASE-15607.patch, HBASE-15607_1.patch, > HBASE-15607_2.patch, HBASE-15607_3.patch, HBASE-15607_3.patch > > > This is a sub-task for HBASE-15174. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15691) Port HBASE-10205 (ConcurrentModificationException in BucketAllocator) to branch-1
[ https://issues.apache.org/jira/browse/HBASE-15691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15262987#comment-15262987 ] deepankar commented on HBASE-15691: --- Oh ok thanks for clarifying. > Port HBASE-10205 (ConcurrentModificationException in BucketAllocator) to > branch-1 > - > > Key: HBASE-15691 > URL: https://issues.apache.org/jira/browse/HBASE-15691 > Project: HBase > Issue Type: Sub-task >Affects Versions: 1.3.0 >Reporter: Andrew Purtell >Assignee: Andrew Purtell > Fix For: 1.3.0, 1.2.2 > > Attachments: HBASE-15691-branch-1.patch > > > HBASE-10205 was committed to trunk and 0.98 branches only. To preserve > continuity we should commit it to branch-1. The change requires more than > nontrivial fixups so I will attach a backport of the change from trunk to > current branch-1 here. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-15733) Forward port some fixes/tweaks fined in branch-1 backport
Francis Liu created HBASE-15733:
---
Summary: Forward port some fixes/tweaks fined in branch-1 backport
Key: HBASE-15733
URL: https://issues.apache.org/jira/browse/HBASE-15733
Project: HBase
Issue Type: Sub-task
Reporter: Francis Liu
Assignee: Francis Liu
Main thing that was found broken is a small typo in get_rsgroup cli command.
Till it's fixed the cli command won't work.
Other small fixes are:
- maven dependency cleanup in hbase-rsgroup module
- Removing a try{} catch block in AM since the exception is handled properly by
callers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15631) Backport Regionserver Groups (HBASE-6721) to branch-1
[ https://issues.apache.org/jira/browse/HBASE-15631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15262952#comment-15262952 ] Francis Liu commented on HBASE-15631: - Need to include maven build fixes addressed in : HBASE-15732 > Backport Regionserver Groups (HBASE-6721) to branch-1 > -- > > Key: HBASE-15631 > URL: https://issues.apache.org/jira/browse/HBASE-15631 > Project: HBase > Issue Type: New Feature >Affects Versions: 1.4.0 >Reporter: Francis Liu >Assignee: Francis Liu > Attachments: HBASE-15631.02.branch-1.patch, > HBASE-15631.branch-1.1.patch, HBASE-15631.branch-1.patch, HBASE-15631.patch, > HBASE-15631_1_branch-1.patch > > > Based on dev list discussion backporting region server group should not be an > issue as it does not: 1. destabilize the code. 2. cause backward > incompatibility. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15732) hbase-rsgroups should be in the assembly
[
https://issues.apache.org/jira/browse/HBASE-15732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15262951#comment-15262951
]
Francis Liu commented on HBASE-15732:
-
+1
Thanks for catching this. Will need to include this in backport.
> hbase-rsgroups should be in the assembly
> -
>
> Key: HBASE-15732
> URL: https://issues.apache.org/jira/browse/HBASE-15732
> Project: HBase
> Issue Type: Bug
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Fix For: 2.0.0
>
> Attachments: hbase-15732_v1.patch
>
>
> {{hbase-rsgroup}} is a new module that does not appear in the assembly. The
> binary tarball still contains the jars through dependencies, but we need the
> test-jar as well for running the IntegrationTestRSGroup.
> [~toffer] can you take a quick look.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14140) HBase Backup/Restore Phase 3: Enhance HBaseAdmin API to include backup/restore - related API
[ https://issues.apache.org/jira/browse/HBASE-14140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15262948#comment-15262948 ] Ted Yu commented on HBASE-14140: Looks like test failures were introduced after HBASE-14123 got checked in. They should have been fixed earlier. > HBase Backup/Restore Phase 3: Enhance HBaseAdmin API to include > backup/restore - related API > > > Key: HBASE-14140 > URL: https://issues.apache.org/jira/browse/HBASE-14140 > Project: HBase > Issue Type: New Feature >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Attachments: HBASE-14140-v1.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15691) Port HBASE-10205 (ConcurrentModificationException in BucketAllocator) to branch-1
[ https://issues.apache.org/jira/browse/HBASE-15691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15262924#comment-15262924 ] Andrew Purtell commented on HBASE-15691: bq. Is there a reason why we are changing back to linked lists? The reason is this patch was applied to only master and 0.98, leaving a discontinuity in history and the code base. If someone who knows more about the block cache ([~stack] ?) tells me "it doesn't matter" than fine. bq. I am still seeing LinkedMaps on the master, moving back to linkedLists will probably undo the optimizations done in HBASE-14624. This is a backport issue so we could make another version of the patch that includes the changes in HBASE-14624. > Port HBASE-10205 (ConcurrentModificationException in BucketAllocator) to > branch-1 > - > > Key: HBASE-15691 > URL: https://issues.apache.org/jira/browse/HBASE-15691 > Project: HBase > Issue Type: Sub-task >Affects Versions: 1.3.0 >Reporter: Andrew Purtell >Assignee: Andrew Purtell > Fix For: 1.3.0, 1.2.2 > > Attachments: HBASE-15691-branch-1.patch > > > HBASE-10205 was committed to trunk and 0.98 branches only. To preserve > continuity we should commit it to branch-1. The change requires more than > nontrivial fixups so I will attach a backport of the change from trunk to > current branch-1 here. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15727) Canary Tool for Zookeeper
[ https://issues.apache.org/jira/browse/HBASE-15727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15262886#comment-15262886 ] Ted Yu commented on HBASE-15727: Can you share experience using this new mode on a cluster ? Thanks > Canary Tool for Zookeeper > - > > Key: HBASE-15727 > URL: https://issues.apache.org/jira/browse/HBASE-15727 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: churro morales >Assignee: churro morales > Attachments: HBASE-15727.patch > > > It would be nice to have the canary tool also monitor zookeeper. Something > simple like doing a getData() call on zookeeper.znode.parent > It would be nice to create clients for every instance in the quorum such that > you could monitor overloaded or poor behaving instances. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15337) Document FIFO and date tiered compaction in the book
[ https://issues.apache.org/jira/browse/HBASE-15337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15262867#comment-15262867 ] Clara Xiong commented on HBASE-15337: - I can give it a try over the weekend. Thank you [~enis] > Document FIFO and date tiered compaction in the book > > > Key: HBASE-15337 > URL: https://issues.apache.org/jira/browse/HBASE-15337 > Project: HBase > Issue Type: Sub-task > Components: documentation >Reporter: Enis Soztutar > Fix For: 2.0.0, 1.3.0 > > > We have two new compaction algorithms FIFO and Date tiered that are for time > series data. We should document how to use them in the book. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15686) Add override mechanism for the exempt classes when dynamically loading table coprocessor
[
https://issues.apache.org/jira/browse/HBASE-15686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15262855#comment-15262855
]
Hudson commented on HBASE-15686:
FAILURE: Integrated in HBase-Trunk_matrix #878 (See
[https://builds.apache.org/job/HBase-Trunk_matrix/878/])
HBASE-15686 Add override mechanism for the exempt classes when (tedyu: rev
8a28c234318f86afb017f163375c9b05340f1aea)
*
hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/CoprocessorHost.java
* hbase-common/src/main/java/org/apache/hadoop/hbase/HConstants.java
*
hbase-common/src/main/java/org/apache/hadoop/hbase/util/CoprocessorClassLoader.java
> Add override mechanism for the exempt classes when dynamically loading table
> coprocessor
>
>
> Key: HBASE-15686
> URL: https://issues.apache.org/jira/browse/HBASE-15686
> Project: HBase
> Issue Type: Improvement
> Components: Coprocessors
>Affects Versions: 1.0.1
>Reporter: Sangjin Lee
>Assignee: Ted Yu
> Fix For: 2.0.0, 1.4.0
>
> Attachments: 15686.v2.txt, 15686.v3.txt, 15686.v4.txt, 15686.v5.txt,
> 15686.v6.txt, 15686.wip
>
>
> As part of Hadoop's Timeline Service v.2 (YARN-2928), we're adding a table
> coprocessor (YARN-4062). However, we're finding that the coprocessor cannot
> be loaded dynamically. A relevant snippet for the exception:
> {noformat}
> java.io.IOException: Class
> org.apache.hadoop.yarn.server.timelineservice.storage.flow.FlowRunCoprocessor
> cannot be loaded
> at
> org.apache.hadoop.hbase.master.HMaster.sanityCheckTableDescriptor(HMaster.java:1329)
> at org.apache.hadoop.hbase.master.HMaster.createTable(HMaster.java:1269)
> at
> org.apache.hadoop.hbase.master.MasterRpcServices.createTable(MasterRpcServices.java:398)
> at
> org.apache.hadoop.hbase.protobuf.generated.MasterProtos$MasterService$2.callBlockingMethod(MasterProtos.java:42436)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2031)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:107)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(RpcExecutor.java:130)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$1.run(RpcExecutor.java:107)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.io.IOException: Class
> org.apache.hadoop.yarn.server.timelineservice.storage.flow.FlowRunCoprocessor
> cannot be loaded
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.testTableCoprocessorAttrs(RegionCoprocessorHost.java:324)
> at
> org.apache.hadoop.hbase.master.HMaster.checkClassLoading(HMaster.java:1483)
> at
> org.apache.hadoop.hbase.master.HMaster.sanityCheckTableDescriptor(HMaster.java:1327)
> ... 8 more
> Caused by: java.lang.ClassNotFoundException:
> org.apache.hadoop.yarn.server.timelineservice.storage.flow.FlowRunCoprocessor
> at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> at
> org.apache.hadoop.hbase.util.CoprocessorClassLoader.loadClass(CoprocessorClassLoader.java:275)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.testTableCoprocessorAttrs(RegionCoprocessorHost.java:322)
> ... 10 more
> {noformat}
> We tracked it down to the fact that {{CoprocessorClassLoader}} regarding all
> hadoop classes as exempt from loading from the coprocessor jar. Since our
> coprocessor sits in the coprocessor jar, and yet the loading of this class is
> delegated to the parent which does not have this jar, the classloading fails.
> What would be nice is the ability to exclude certain classes from the exempt
> classes so that they can be loaded via table coprocessor classloader. See
> hadoop's {{ApplicationClassLoader}} for a similar feature.
> Is there any other way to load this coprocessor at the table scope?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15706) HFilePrettyPrinter should print out nicely formatted tags
[
https://issues.apache.org/jira/browse/HBASE-15706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
huaxiang sun updated HBASE-15706:
-
Attachment: HBASE-15706-v002.patch
Upload v2 patch, which addresses [~anoop.hbase]'s comments.
> HFilePrettyPrinter should print out nicely formatted tags
> -
>
> Key: HBASE-15706
> URL: https://issues.apache.org/jira/browse/HBASE-15706
> Project: HBase
> Issue Type: Improvement
> Components: HFile
>Affects Versions: 2.0.0
>Reporter: huaxiang sun
>Priority: Minor
> Attachments: HBASE-15706-v001.patch, HBASE-15706-v002.patch
>
>
> When I was using HFile to print out a rows with tags, the output is like:
> {code}
> hsun-MBP:hbase-2.0.0-SNAPSHOT hsun$ hbase
> org.apache.hadoop.hbase.io.hfile.HFile -f
> /tmp/71afa45b1cb94ea1858a99f31197274f -p
> 2016-04-25 11:40:40,409 WARN [main] util.NativeCodeLoader: Unable to load
> native-hadoop library for your platform... using builtin-java classes where
> applicable
> 2016-04-25 11:40:40,580 INFO [main] hfile.CacheConfig: CacheConfig:disabled
> K: b/b:b/1461608231279/Maximum/vlen=0/seqid=0 V:
> K: b/b:b/1461608231278/Put/vlen=1/seqid=0 V: b T[0]: �
> Scanned kv count -> 2
> {code}
> With attached patch, the print is now like:
> {code}
> 2016-04-25 11:57:05,849 INFO [main] hfile.CacheConfig: CacheConfig:disabled
> K: b/b:b/1461609876838/Maximum/vlen=0/seqid=0 V:
> K: b/b:b/1461609876837/Put/vlen=1/seqid=0 V: b T[0]: [Tag type : 8, value :
> \x00\x0E\xEE\xEE]
> Scanned kv count -> 2
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15691) Port HBASE-10205 (ConcurrentModificationException in BucketAllocator) to branch-1
[ https://issues.apache.org/jira/browse/HBASE-15691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15262800#comment-15262800 ] deepankar commented on HBASE-15691: --- Took a look at the patch, Is there a reason why we are changing back to linked lists?, I am still seeing LinkedMaps on the master, moving back to linkedLists will probably undo the optimizations done in HBASE-14624. > Port HBASE-10205 (ConcurrentModificationException in BucketAllocator) to > branch-1 > - > > Key: HBASE-15691 > URL: https://issues.apache.org/jira/browse/HBASE-15691 > Project: HBase > Issue Type: Sub-task >Affects Versions: 1.3.0 >Reporter: Andrew Purtell >Assignee: Andrew Purtell > Fix For: 1.3.0, 1.2.2 > > Attachments: HBASE-15691-branch-1.patch > > > HBASE-10205 was committed to trunk and 0.98 branches only. To preserve > continuity we should commit it to branch-1. The change requires more than > nontrivial fixups so I will attach a backport of the change from trunk to > current branch-1 here. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14140) HBase Backup/Restore Phase 3: Enhance HBaseAdmin API to include backup/restore - related API
[ https://issues.apache.org/jira/browse/HBASE-14140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15262791#comment-15262791 ] Vladimir Rodionov commented on HBASE-14140: --- Ted, can you open sub task for failing tests? > HBase Backup/Restore Phase 3: Enhance HBaseAdmin API to include > backup/restore - related API > > > Key: HBASE-14140 > URL: https://issues.apache.org/jira/browse/HBASE-14140 > Project: HBase > Issue Type: New Feature >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Attachments: HBASE-14140-v1.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15727) Canary Tool for Zookeeper
[ https://issues.apache.org/jira/browse/HBASE-15727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15262765#comment-15262765 ] churro morales commented on HBASE-15727: oh yeah, my bad. I'll get rid of it and use the commons one. Always forget which one is StopWatch and Stopwatch. Any other comments, concerns before I put up a new patch? Good catch Ted. > Canary Tool for Zookeeper > - > > Key: HBASE-15727 > URL: https://issues.apache.org/jira/browse/HBASE-15727 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: churro morales >Assignee: churro morales > Attachments: HBASE-15727.patch > > > It would be nice to have the canary tool also monitor zookeeper. Something > simple like doing a getData() call on zookeeper.znode.parent > It would be nice to create clients for every instance in the quorum such that > you could monitor overloaded or poor behaving instances. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-6633) Adding new hooks to the split flow - For roll backs and one final hook after split is completed either successfully or failed
[ https://issues.apache.org/jira/browse/HBASE-6633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15262772#comment-15262772 ] Stephen Yuan Jiang commented on HBASE-6633: --- I am not sure better or worse. I just worry about that someone is using postSplit would lost functionality when we remove it in 3.0. Another thing I think is that we should really separate successful and failed split - for now, postCompletedSplit is called no matter when it is success or failure. I think in failure situation, postRollbackSplit should take care of it; the postCompleteSplit only deal with success situation. > Adding new hooks to the split flow - For roll backs and one final hook after > split is completed either successfully or failed > - > > Key: HBASE-6633 > URL: https://issues.apache.org/jira/browse/HBASE-6633 > Project: HBase > Issue Type: Improvement > Components: Coprocessors >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Labels: coprocessors > Fix For: 0.95.0 > > Attachments: HBASE-6633.patch > > > Currently we have two hooks in the split flow of a region. PreSplit() and > postSplit(). But not always these are helpful in case i have a problem in > preSplit() or postSplit() i need to do a rollback of the current region or > the region that i am handling thro the hooks. > So its better if we have a hook in the rollback code and also one final hook > say postCompleteSplit() so that CP can take any corrective action. > Pls do suggest if i can provide a patch for this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15136) Explore different queuing behaviors while busy
[ https://issues.apache.org/jira/browse/HBASE-15136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Antonov updated HBASE-15136: Release Note: Previously RPC request scheduler in HBase had 2 modes in could operate in: - simple FIFO - "partial" deadline, where deadline constraints are only imposed on long-running scan requests. This patch adds new type of scheduler to HBase, based on the research around controlled delay (CoDel) algorithm [1], used in networking to combat bufferbloat, as well as some analysis on generalizing it to generic request queues [2]. The purpose of that work is to prevent long standing call queues caused by discrepancy between request rate and available throughput, caused by kernel/disk IO/networking stalls. New RPC scheduler could be enabled by setting hbase.ipc.server.callqueue.type=codel in configuration. Several additional params allow to configure algorithm behavior - hbase.ipc.server.callqueue.codel.target.delay hbase.ipc.server.callqueue.codel.interval hbase.ipc.server.callqueue.codel.lifo.threshold [1] Controlling Queue Delay / A modern AQM is just one piece of the solution to bufferbloat. http://queue.acm.org/detail.cfm?id=2209336 [2] Fail at Scale / Reliability in the face of rapid change. http://queue.acm.org/detail.cfm?id=2839461 was: Previously RPC request scheduler in HBase had 2 modes in could operate in: - simple FIFO - "partial" deadline, where deadline constraints are only imposed on long-running scan requests. This patch adds new type of scheduler to HBase, based on the research around controlled delay (CoDel) algorithm [1], used in networking to combat bufferbloat, as well as some analysis on generalizing it to generic request queues [2]. The purpose of that work is to prevent long standing call queues caused by discrepancy between request rate and available throughput, caused by kernel/disk IO/networking stalls. New RPC scheduler could be enabled by setting hbase.ipc.server.callqueue.type=codel in configuration. Several additional params allows to configure algorithm behavior - hbase.ipc.server.callqueue.codel.target.delay hbase.ipc.server.callqueue.codel.interval hbase.ipc.server.callqueue.codel.lifo.threshold [1] Controlling Queue Delay / A modern AQM is just one piece of the solution to bufferbloat. http://queue.acm.org/detail.cfm?id=2209336 [2] Fail at Scale / Reliability in the face of rapid change. http://queue.acm.org/detail.cfm?id=2839461 > Explore different queuing behaviors while busy > -- > > Key: HBASE-15136 > URL: https://issues.apache.org/jira/browse/HBASE-15136 > Project: HBase > Issue Type: New Feature > Components: IPC/RPC >Reporter: Elliott Clark >Assignee: Mikhail Antonov > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-15136-1.2.v1.patch, HBASE-15136-v2.patch, > deadline_scheduler_v_0_2.patch > > > http://queue.acm.org/detail.cfm?id=2839461 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15281) Allow the FileSystem inside HFileSystem to be wrapped
[ https://issues.apache.org/jira/browse/HBASE-15281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Antonov updated HBASE-15281: Priority: Major (was: Minor) > Allow the FileSystem inside HFileSystem to be wrapped > - > > Key: HBASE-15281 > URL: https://issues.apache.org/jira/browse/HBASE-15281 > Project: HBase > Issue Type: New Feature > Components: Filesystem Integration, hbase >Affects Versions: 2.0.0, 1.2.0 >Reporter: Rajesh Nishtala >Assignee: Rajesh Nishtala > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-15281-v1.patch > > > It would be very useful for us to be able to wrap the filesystems > encapsulated by HFileSystem with other FilterFileSystems. This allows for > more detailed logging of the operations to the DFS. Internally, the data > logged from this method has allowed us to show application engineers where > there schemas are inefficient and inducing too much IO. This patch will just > allow the filesystem to be pluggable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15732) hbase-rsgroups should be in the assembly
[
https://issues.apache.org/jira/browse/HBASE-15732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Enis Soztutar updated HBASE-15732:
--
Status: Patch Available (was: Open)
> hbase-rsgroups should be in the assembly
> -
>
> Key: HBASE-15732
> URL: https://issues.apache.org/jira/browse/HBASE-15732
> Project: HBase
> Issue Type: Bug
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Fix For: 2.0.0
>
> Attachments: hbase-15732_v1.patch
>
>
> {{hbase-rsgroup}} is a new module that does not appear in the assembly. The
> binary tarball still contains the jars through dependencies, but we need the
> test-jar as well for running the IntegrationTestRSGroup.
> [~toffer] can you take a quick look.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15732) hbase-rsgroups should be in the assembly
[
https://issues.apache.org/jira/browse/HBASE-15732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Enis Soztutar updated HBASE-15732:
--
Attachment: hbase-15732_v1.patch
Simple patch.
> hbase-rsgroups should be in the assembly
> -
>
> Key: HBASE-15732
> URL: https://issues.apache.org/jira/browse/HBASE-15732
> Project: HBase
> Issue Type: Bug
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Fix For: 2.0.0
>
> Attachments: hbase-15732_v1.patch
>
>
> {{hbase-rsgroup}} is a new module that does not appear in the assembly. The
> binary tarball still contains the jars through dependencies, but we need the
> test-jar as well for running the IntegrationTestRSGroup.
> [~toffer] can you take a quick look.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (HBASE-15732) hbase-rsgroups should be in the assembly
Enis Soztutar created HBASE-15732:
-
Summary: hbase-rsgroups should be in the assembly
Key: HBASE-15732
URL: https://issues.apache.org/jira/browse/HBASE-15732
Project: HBase
Issue Type: Bug
Reporter: Enis Soztutar
Assignee: Enis Soztutar
Fix For: 2.0.0
{{hbase-rsgroup}} is a new module that does not appear in the assembly. The
binary tarball still contains the jars through dependencies, but we need the
test-jar as well for running the IntegrationTestRSGroup.
[~toffer] can you take a quick look.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15714) We are calling checkRow() twice in doMiniBatchMutation()
[
https://issues.apache.org/jira/browse/HBASE-15714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15262704#comment-15262704
]
Enis Soztutar commented on HBASE-15714:
---
getRowLock() is called from
(1) HRegion.doMiniBatchMutate()
(2) HRegion.doCheckAndRowMutate()
(3) HRegion.doDelta()
(4) HRegion.processRowsWithLocks()
I like the approach of doing the getRowLockInternal() since getRowLock() is
exposed in Region interface. So it is better to have the version with the check
exposed. However, for this patch, let's change all the paths (2), (3) and (4)
to skip the check. (1), (3) and (4) already calls checkRow(). We can add an
explicit {{checkRow()}} to (2) and switch that to use the getRowLockInternal()
as well, to be similar to the other calls.
> We are calling checkRow() twice in doMiniBatchMutation()
>
>
> Key: HBASE-15714
> URL: https://issues.apache.org/jira/browse/HBASE-15714
> Project: HBase
> Issue Type: Bug
>Reporter: Enis Soztutar
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-15714.patch
>
>
> In {{multi()}} -> {{doMiniBatchMutation()}} code path, we end up calling
> {{checkRow()}} twice, once from {{checkBatchOp()}} and once from
> {{getRowLock()}}.
> See [~anoop.hbase]'s comments at
> https://issues.apache.org/jira/browse/HBASE-15600?focusedCommentId=15257636=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15257636.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15691) Port HBASE-10205 (ConcurrentModificationException in BucketAllocator) to branch-1
[ https://issues.apache.org/jira/browse/HBASE-15691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15262688#comment-15262688 ] Mikhail Antonov commented on HBASE-15691: - [~apurtell] (sorry, in my comment above I meant "did not look at the patch yet", a typo) Yeah, I think it sounds good. > Port HBASE-10205 (ConcurrentModificationException in BucketAllocator) to > branch-1 > - > > Key: HBASE-15691 > URL: https://issues.apache.org/jira/browse/HBASE-15691 > Project: HBase > Issue Type: Sub-task >Affects Versions: 1.3.0 >Reporter: Andrew Purtell >Assignee: Andrew Purtell > Fix For: 1.3.0, 1.2.2 > > Attachments: HBASE-15691-branch-1.patch > > > HBASE-10205 was committed to trunk and 0.98 branches only. To preserve > continuity we should commit it to branch-1. The change requires more than > nontrivial fixups so I will attach a backport of the change from trunk to > current branch-1 here. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (HBASE-14970) Backport HBASE-13082 and its sub-jira to branch-1
[ https://issues.apache.org/jira/browse/HBASE-14970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Antonov resolved HBASE-14970. - Resolution: Fixed resolving as discussed > Backport HBASE-13082 and its sub-jira to branch-1 > - > > Key: HBASE-14970 > URL: https://issues.apache.org/jira/browse/HBASE-14970 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.0 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 1.3.0 > > Attachments: HBASE-13082-branch-1.patch, > HBASE-14970_6.branch-1.patch, HBASE-14970_7.branch-1.patch, > HBASE-14970_8.branch-1.patch, HBASE-14970_9.branch-1.patch, > HBASE-14970_branch-1.patch, HBASE-14970_branch-1.patch, > HBASE-14970_branch-1.patch, HBASE-14970_branch-1_1.patch, > HBASE-14970_branch-1_2.patch, HBASE-14970_branch-1_4.patch, > HBASE-14970_branch-1_5.patch, HBASE-14970_branch-1_6.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-11290) Unlock RegionStates
[
https://issues.apache.org/jira/browse/HBASE-11290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15262682#comment-15262682
]
Francis Liu commented on HBASE-11290:
-
{quote}
If we could have up-to-date patches for both trunk and branch-1 that would be
great! It seems a useful change where a lot of effort went in (both in writing
the code and in reviewing different versions of the patch), pity if that keeps
sitting around...
{quote}
I see great, let me rebase then.
{quote}
Do you happen to have any numbers on performance improvement here?
{quote}
We did do perf testing and if I remember correctly it went from not being able
to assign 1M regions (took hours and still not done) to being able to assign
them in 10s of minutes. Because of lock thrashing which resulted in high cpu,
even refreshing master page was blocked. That was sometime ago, I'll see if I
can dig it up.
> Unlock RegionStates
> ---
>
> Key: HBASE-11290
> URL: https://issues.apache.org/jira/browse/HBASE-11290
> Project: HBase
> Issue Type: Sub-task
>Affects Versions: 1.2.0, 1.3.0
>Reporter: Francis Liu
>Assignee: Francis Liu
> Fix For: 2.0.0, 1.4.0, 0.98.20
>
> Attachments: HBASE-11290-0.98.patch, HBASE-11290-0.98_v2.patch,
> HBASE-11290.draft.patch, HBASE-11290_trunk.patch
>
>
> Even though RegionStates is a highly accessed data structure in HMaster. Most
> of it's methods are synchronized. Which limits concurrency. Even simply
> making some of the getters non-synchronized by using concurrent data
> structures has helped with region assignments. We can go as simple as this
> approach or create locks per region or a bucket lock per region bucket.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (HBASE-15727) Canary Tool for Zookeeper
[
https://issues.apache.org/jira/browse/HBASE-15727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15262678#comment-15262678
]
Ted Yu edited comment on HBASE-15727 at 4/28/16 6:25 PM:
-
{code}
44 import com.google.common.base.Stopwatch;
{code}
Can you avoid dependence on Google's Stopwatch ? See HBASE-14963
{code}
107 * outputs some information about failure of latency.
{code}
of -> or
was (Author: yuzhih...@gmail.com):
{code}
44 import com.google.common.base.Stopwatch;
{code}
Can you avoid dependence on Google's Stopwatch ?
{code}
107 * outputs some information about failure of latency.
{code}
of -> or
> Canary Tool for Zookeeper
> -
>
> Key: HBASE-15727
> URL: https://issues.apache.org/jira/browse/HBASE-15727
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 2.0.0
>Reporter: churro morales
>Assignee: churro morales
> Attachments: HBASE-15727.patch
>
>
> It would be nice to have the canary tool also monitor zookeeper. Something
> simple like doing a getData() call on zookeeper.znode.parent
> It would be nice to create clients for every instance in the quorum such that
> you could monitor overloaded or poor behaving instances.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15727) Canary Tool for Zookeeper
[
https://issues.apache.org/jira/browse/HBASE-15727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15262678#comment-15262678
]
Ted Yu commented on HBASE-15727:
{code}
44 import com.google.common.base.Stopwatch;
{code}
Can you avoid dependence on Google's Stopwatch ?
{code}
107 * outputs some information about failure of latency.
{code}
of -> or
> Canary Tool for Zookeeper
> -
>
> Key: HBASE-15727
> URL: https://issues.apache.org/jira/browse/HBASE-15727
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 2.0.0
>Reporter: churro morales
>Assignee: churro morales
> Attachments: HBASE-15727.patch
>
>
> It would be nice to have the canary tool also monitor zookeeper. Something
> simple like doing a getData() call on zookeeper.znode.parent
> It would be nice to create clients for every instance in the quorum such that
> you could monitor overloaded or poor behaving instances.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-11290) Unlock RegionStates
[ https://issues.apache.org/jira/browse/HBASE-11290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15262668#comment-15262668 ] Mikhail Antonov commented on HBASE-11290: - That's the MultiLock class in the patch to the jira I mentioned. The approach I used there trying to optimize concurrent meta lookups doesn't look feasible, but the implementation of the lock might be useful to someone. If we could have up-to-date patches for both trunk and branch-1 that would be great! It seems a useful change where a lot of effort went in (both in writing the code and in reviewing different versions of the patch), pity if that keeps sitting around... > Unlock RegionStates > --- > > Key: HBASE-11290 > URL: https://issues.apache.org/jira/browse/HBASE-11290 > Project: HBase > Issue Type: Sub-task >Affects Versions: 1.2.0, 1.3.0 >Reporter: Francis Liu >Assignee: Francis Liu > Fix For: 2.0.0, 1.4.0, 0.98.20 > > Attachments: HBASE-11290-0.98.patch, HBASE-11290-0.98_v2.patch, > HBASE-11290.draft.patch, HBASE-11290_trunk.patch > > > Even though RegionStates is a highly accessed data structure in HMaster. Most > of it's methods are synchronized. Which limits concurrency. Even simply > making some of the getters non-synchronized by using concurrent data > structures has helped with region assignments. We can go as simple as this > approach or create locks per region or a bucket lock per region bucket. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14970) Backport HBASE-13082 and its sub-jira to branch-1
[ https://issues.apache.org/jira/browse/HBASE-14970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15262666#comment-15262666 ] Mikhail Antonov commented on HBASE-14970: - Yeah that what I think > Backport HBASE-13082 and its sub-jira to branch-1 > - > > Key: HBASE-14970 > URL: https://issues.apache.org/jira/browse/HBASE-14970 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.0 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 1.3.0 > > Attachments: HBASE-13082-branch-1.patch, > HBASE-14970_6.branch-1.patch, HBASE-14970_7.branch-1.patch, > HBASE-14970_8.branch-1.patch, HBASE-14970_9.branch-1.patch, > HBASE-14970_branch-1.patch, HBASE-14970_branch-1.patch, > HBASE-14970_branch-1.patch, HBASE-14970_branch-1_1.patch, > HBASE-14970_branch-1_2.patch, HBASE-14970_branch-1_4.patch, > HBASE-14970_branch-1_5.patch, HBASE-14970_branch-1_6.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-11290) Unlock RegionStates
[ https://issues.apache.org/jira/browse/HBASE-11290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15262660#comment-15262660 ] Francis Liu commented on HBASE-11290: - [~mantonov] At the moment we just need it to get into branch-1 no worries about not getting it into 1.3. With that I'd be happy to update this patch if you're still up for reviewing it this weekend (tho you don't have to)? BTW the current patch I have is for trunk are you asking me to rebase onto trunk? Or create patches for both trunk and 1.x? What's the name of the lock? I can take a look. Tho if it's usable maybe we can just replace Idlock once HBASE-15648 goes in? > Unlock RegionStates > --- > > Key: HBASE-11290 > URL: https://issues.apache.org/jira/browse/HBASE-11290 > Project: HBase > Issue Type: Sub-task >Affects Versions: 1.2.0, 1.3.0 >Reporter: Francis Liu >Assignee: Francis Liu > Fix For: 2.0.0, 1.4.0, 0.98.20 > > Attachments: HBASE-11290-0.98.patch, HBASE-11290-0.98_v2.patch, > HBASE-11290.draft.patch, HBASE-11290_trunk.patch > > > Even though RegionStates is a highly accessed data structure in HMaster. Most > of it's methods are synchronized. Which limits concurrency. Even simply > making some of the getters non-synchronized by using concurrent data > structures has helped with region assignments. We can go as simple as this > approach or create locks per region or a bucket lock per region bucket. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14970) Backport HBASE-13082 and its sub-jira to branch-1
[ https://issues.apache.org/jira/browse/HBASE-14970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15262656#comment-15262656 ] Andrew Purtell commented on HBASE-14970: Yes I think this can be resolved. > Backport HBASE-13082 and its sub-jira to branch-1 > - > > Key: HBASE-14970 > URL: https://issues.apache.org/jira/browse/HBASE-14970 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.0 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 1.3.0 > > Attachments: HBASE-13082-branch-1.patch, > HBASE-14970_6.branch-1.patch, HBASE-14970_7.branch-1.patch, > HBASE-14970_8.branch-1.patch, HBASE-14970_9.branch-1.patch, > HBASE-14970_branch-1.patch, HBASE-14970_branch-1.patch, > HBASE-14970_branch-1.patch, HBASE-14970_branch-1_1.patch, > HBASE-14970_branch-1_2.patch, HBASE-14970_branch-1_4.patch, > HBASE-14970_branch-1_5.patch, HBASE-14970_branch-1_6.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (HBASE-15691) Port HBASE-10205 (ConcurrentModificationException in BucketAllocator) to branch-1
[ https://issues.apache.org/jira/browse/HBASE-15691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15262652#comment-15262652 ] Andrew Purtell edited comment on HBASE-15691 at 4/28/16 6:12 PM: - I don't think it's a release blocker. The code doesn't implicate any user facing API and branch-1 is humming along fine without the change apparently. That said I hope we can commit this and then revisit the BC allocator before making any next release. was (Author: apurtell): I don't think it's a release blocker. The code doesn't implicate any user facing API and branch-1 is humming along fine without the change apparently. > Port HBASE-10205 (ConcurrentModificationException in BucketAllocator) to > branch-1 > - > > Key: HBASE-15691 > URL: https://issues.apache.org/jira/browse/HBASE-15691 > Project: HBase > Issue Type: Sub-task >Affects Versions: 1.3.0 >Reporter: Andrew Purtell >Assignee: Andrew Purtell > Fix For: 1.3.0, 1.2.2 > > Attachments: HBASE-15691-branch-1.patch > > > HBASE-10205 was committed to trunk and 0.98 branches only. To preserve > continuity we should commit it to branch-1. The change requires more than > nontrivial fixups so I will attach a backport of the change from trunk to > current branch-1 here. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15691) Port HBASE-10205 (ConcurrentModificationException in BucketAllocator) to branch-1
[ https://issues.apache.org/jira/browse/HBASE-15691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15262652#comment-15262652 ] Andrew Purtell commented on HBASE-15691: I don't think it's a release blocker. The code doesn't implicate any user facing API and branch-1 is humming along fine without the change apparently. > Port HBASE-10205 (ConcurrentModificationException in BucketAllocator) to > branch-1 > - > > Key: HBASE-15691 > URL: https://issues.apache.org/jira/browse/HBASE-15691 > Project: HBase > Issue Type: Sub-task >Affects Versions: 1.3.0 >Reporter: Andrew Purtell >Assignee: Andrew Purtell > Fix For: 1.3.0, 1.2.2 > > Attachments: HBASE-15691-branch-1.patch > > > HBASE-10205 was committed to trunk and 0.98 branches only. To preserve > continuity we should commit it to branch-1. The change requires more than > nontrivial fixups so I will attach a backport of the change from trunk to > current branch-1 here. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-11290) Unlock RegionStates
[ https://issues.apache.org/jira/browse/HBASE-11290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15262635#comment-15262635 ] Mikhail Antonov commented on HBASE-11290: - [~toffer] btw, in the WIP patch to HBASE-15648 I had an implementation of multi-lock similar to IdLock, but re-entrant and allowing to synchronize on any objects, not just longs. Would it be useful? > Unlock RegionStates > --- > > Key: HBASE-11290 > URL: https://issues.apache.org/jira/browse/HBASE-11290 > Project: HBase > Issue Type: Sub-task >Affects Versions: 1.2.0, 1.3.0 >Reporter: Francis Liu >Assignee: Francis Liu > Fix For: 2.0.0, 1.4.0, 0.98.20 > > Attachments: HBASE-11290-0.98.patch, HBASE-11290-0.98_v2.patch, > HBASE-11290.draft.patch, HBASE-11290_trunk.patch > > > Even though RegionStates is a highly accessed data structure in HMaster. Most > of it's methods are synchronized. Which limits concurrency. Even simply > making some of the getters non-synchronized by using concurrent data > structures has helped with region assignments. We can go as simple as this > approach or create locks per region or a bucket lock per region bucket. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-11290) Unlock RegionStates
[ https://issues.apache.org/jira/browse/HBASE-11290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15262628#comment-15262628 ] Mikhail Antonov commented on HBASE-11290: - [~toffer] I'm not sure we can pull it in 1.3 now, but we totally should look to get it in branch-1. If you could please rebase current branch-1 version, I'll try to get a review on the weekend. Do you happen to have any numbers on performance improvement here? [~stack] what do you think about it in branch-1 / branch-1.3? would be good to get several reviewers on this code.. > Unlock RegionStates > --- > > Key: HBASE-11290 > URL: https://issues.apache.org/jira/browse/HBASE-11290 > Project: HBase > Issue Type: Sub-task >Affects Versions: 1.2.0, 1.3.0 >Reporter: Francis Liu >Assignee: Francis Liu > Fix For: 2.0.0, 1.4.0, 0.98.20 > > Attachments: HBASE-11290-0.98.patch, HBASE-11290-0.98_v2.patch, > HBASE-11290.draft.patch, HBASE-11290_trunk.patch > > > Even though RegionStates is a highly accessed data structure in HMaster. Most > of it's methods are synchronized. Which limits concurrency. Even simply > making some of the getters non-synchronized by using concurrent data > structures has helped with region assignments. We can go as simple as this > approach or create locks per region or a bucket lock per region bucket. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14140) HBase Backup/Restore Phase 3: Enhance HBaseAdmin API to include backup/restore - related API
[
https://issues.apache.org/jira/browse/HBASE-14140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15262620#comment-15262620
]
Ted Yu commented on HBASE-14140:
Some failed unit tests with latest patch on HBASE-7912 branch:
{code}
testArchiveOnTableFamilyDelete(org.apache.hadoop.hbase.backup.TestHFileArchiving)
Time elapsed: 35.012 sec <<< ERROR!
java.io.IOException: Filesystem closed
at
org.apache.hadoop.hbase.backup.TestHFileArchiving.getAllFileNames(TestHFileArchiving.java:430)
at
org.apache.hadoop.hbase.backup.TestHFileArchiving.assertArchiveFiles(TestHFileArchiving.java:278)
at
org.apache.hadoop.hbase.backup.TestHFileArchiving.testArchiveOnTableFamilyDelete(TestHFileArchiving.java:346)
...
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.005 sec <<<
FAILURE! - in
org.apache.hadoop.hbase.security.visibility.TestVisibilityLabelsWithACL
org.apache.hadoop.hbase.security.visibility.TestVisibilityLabelsWithACL Time
elapsed: 0.005 sec <<< FAILURE!
java.lang.AssertionError: Waiting timed out after [10,000] msec
at
org.apache.hadoop.hbase.security.visibility.TestVisibilityLabelsWithACL.setupBeforeClass(TestVisibilityLabelsWithACL.java:103)
...
verifyReservedNS(org.apache.hadoop.hbase.TestNamespace) Time elapsed: 0.074
sec <<< FAILURE!
java.lang.AssertionError: expected:<2> but was:<3>
at
org.apache.hadoop.hbase.TestNamespace.verifyReservedNS(TestNamespace.java:118)
...
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 14.289 sec <<<
FAILURE! - in org.apache.hadoop.hbase.util.hbck.TestOfflineMetaRebuildOverlap
testMetaRebuildOverlapFail(org.apache.hadoop.hbase.util.hbck.TestOfflineMetaRebuildOverlap)
Time elapsed: 14.15 sec <<< FAILURE!
java.lang.AssertionError: expected:<5> but was:<6>
Running org.apache.hadoop.hbase.util.hbck.TestOfflineMetaRebuildHole
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 14.322 sec <<<
FAILURE! - in org.apache.hadoop.hbase.util.hbck.TestOfflineMetaRebuildBase
testMetaRebuild(org.apache.hadoop.hbase.util.hbck.TestOfflineMetaRebuildBase)
Time elapsed: 14.187 sec <<< FAILURE!
java.lang.AssertionError: expected:<5> but was:<6>
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 14.592 sec <<<
FAILURE! - in org.apache.hadoop.hbase.util.hbck.TestOfflineMetaRebuildHole
testMetaRebuildHoleFail(org.apache.hadoop.hbase.util.hbck.TestOfflineMetaRebuildHole)
Time elapsed: 14.541 sec <<< FAILURE!
java.lang.AssertionError: expected:<5> but was:<6>
...
testClusterRestart(org.apache.hadoop.hbase.master.TestRestartCluster) Time
elapsed: 10.537 sec <<< FAILURE!
java.lang.AssertionError: expected:<4> but was:<5>
at
org.apache.hadoop.hbase.master.TestRestartCluster.testClusterRestart(TestRestartCluster.java:78)
...
testForCheckingIfEnableAndDisableWorksFineAfterSwitch(org.apache.hadoop.hbase.master.TestMasterRestartAfterDisablingTable)
Time elapsed: 13.81 sec <<< FAILURE!
java.lang.AssertionError: The number of regions for the table tableRestart
should be 0 and onlythe catalog and namespace tables should be present.
expected:<2> but was:<3>
at
org.apache.hadoop.hbase.master.TestMasterRestartAfterDisablingTable.testForCheckingIfEnableAndDisableWorksFineAfterSwitch(TestMasterRestartAfterDisablingTable.java:82)
...
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 14.462 sec <<<
FAILURE! - in org.apache.hadoop.hbase.master.TestRollingRestart
testBasicRollingRestart(org.apache.hadoop.hbase.master.TestRollingRestart)
Time elapsed: 14.379 sec <<< FAILURE!
java.lang.AssertionError: expected:<2> but was:<3>
at
org.apache.hadoop.hbase.master.TestRollingRestart.testBasicRollingRestart(TestRollingRestart.java:96)
Tests run: 18, Failures: 2, Errors: 0, Skipped: 15, Time elapsed: 28.084 sec
<<< FAILURE! - in org.apache.hadoop.hbase.master.TestDistributedLogSplitting
testReadWriteSeqIdFiles(org.apache.hadoop.hbase.master.TestDistributedLogSplitting)
Time elapsed: 9.755 sec <<< FAILURE!
java.lang.AssertionError: expected:<2> but was:<3>
at
org.apache.hadoop.hbase.master.TestDistributedLogSplitting.installTable(TestDistributedLogSplitting.java:1502)
at
org.apache.hadoop.hbase.master.TestDistributedLogSplitting.installTable(TestDistributedLogSplitting.java:1473)
at
org.apache.hadoop.hbase.master.TestDistributedLogSplitting.testReadWriteSeqIdFiles(TestDistributedLogSplitting.java:1442)
testThreeRSAbort(org.apache.hadoop.hbase.master.TestDistributedLogSplitting)
Time elapsed: 10.159 sec <<< FAILURE!
java.lang.AssertionError: expected:<2> but was:<3>
at
org.apache.hadoop.hbase.master.TestDistributedLogSplitting.installTable(TestDistributedLogSplitting.java:1502)
at
org.apache.hadoop.hbase.master.TestDistributedLogSplitting.installTable(TestDistributedLogSplitting.java:1473)
at
org.apache.hadoop.hbase.master.TestDistributedLogSplitting.testThreeRSAbort(TestDistributedLogSplitting.java:1074)
...
[jira] [Commented] (HBASE-11290) Unlock RegionStates
[ https://issues.apache.org/jira/browse/HBASE-11290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15262565#comment-15262565 ] Francis Liu commented on HBASE-11290: - No worries Mikhail. If anyone has time to help review this. I'll make sure turnarounds are quick. FWIW, we've been running a 0.98 version this on all our clusters roughly since this jira was opened. > Unlock RegionStates > --- > > Key: HBASE-11290 > URL: https://issues.apache.org/jira/browse/HBASE-11290 > Project: HBase > Issue Type: Sub-task >Affects Versions: 1.2.0, 1.3.0 >Reporter: Francis Liu >Assignee: Francis Liu > Fix For: 2.0.0, 1.4.0, 0.98.20 > > Attachments: HBASE-11290-0.98.patch, HBASE-11290-0.98_v2.patch, > HBASE-11290.draft.patch, HBASE-11290_trunk.patch > > > Even though RegionStates is a highly accessed data structure in HMaster. Most > of it's methods are synchronized. Which limits concurrency. Even simply > making some of the getters non-synchronized by using concurrent data > structures has helped with region assignments. We can go as simple as this > approach or create locks per region or a bucket lock per region bucket. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15720) Print row locks at the debug dump page
[ https://issues.apache.org/jira/browse/HBASE-15720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15262561#comment-15262561 ] Hudson commented on HBASE-15720: FAILURE: Integrated in HBase-0.98-on-Hadoop-1.1 #1209 (See [https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/1209/]) HBASE-15720 Print row locks at the debug dump page (chenheng: rev 716ca48a7491ecf561efba532fb7a5ff3f7a5e57) * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RSDumpServlet.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java > Print row locks at the debug dump page > -- > > Key: HBASE-15720 > URL: https://issues.apache.org/jira/browse/HBASE-15720 > Project: HBase > Issue Type: Improvement >Reporter: Enis Soztutar >Assignee: Heng Chen > Fix For: 2.0.0, 1.3.0, 1.4.0, 1.1.5, 1.2.2, 0.98.20, 1.0.5 > > Attachments: 4742C21D-B9CE-4921-9B32-CC319488EC64.png, > HBASE-15720.patch > > > We had to debug cases where some handlers are holding row locks for an > extended time (and maybe leak) and other handlers are getting timeouts for > obtaining row locks. > We should add row lock information at the debug page at the RS UI to be able > to live-debug such cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15670) Add missing Snapshot.proto to the maven profile for compiling protobuf
[
https://issues.apache.org/jira/browse/HBASE-15670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15262562#comment-15262562
]
Hudson commented on HBASE-15670:
FAILURE: Integrated in HBase-0.98-on-Hadoop-1.1 #1209 (See
[https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/1209/])
HBASE-15670 Add missing Snapshot.proto to the maven profile for (apurtell: rev
df5ba75c6f37113094a914d7646e0ee0efb7992e)
*
hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/protobuf/generated/ColumnAggregationWithErrorsProtos.java
*
hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/TestBatchCoprocessorEndpoint.java
*
hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/protobuf/generated/ColumnAggregationWithNullResponseProtos.java
*
hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/ColumnAggregationEndpointNullResponse.java
* hbase-server/src/test/protobuf/ColumnAggregationNullResponseProtocol.proto
*
hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/ColumnAggregationEndpointWithErrors.java
* hbase-server/src/test/protobuf/ColumnAggregationWithErrorsProtocol.proto
* hbase-server/pom.xml
* hbase-protocol/pom.xml
> Add missing Snapshot.proto to the maven profile for compiling protobuf
> --
>
> Key: HBASE-15670
> URL: https://issues.apache.org/jira/browse/HBASE-15670
> Project: HBase
> Issue Type: Bug
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Fix For: 2.0.0, 1.3.0, 1.4.0, 1.1.5, 1.2.2
>
> Attachments: hbase-15670_v1.patch, hbase-15670_v2.patch,
> hbase-15670_v2.patch, hbase-15670_v2.patch
>
>
> We had to debug an issue that resulted in mis-generated protobuf code in
> backported patches. It turns out that Snapshot.proto is not in
> hbase-protocol/pom.xml which results in the corresponding java code to be
> skipped when you do:
> {code}
> mvn compile -Pcompile-protobuf
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15607) Remove PB references from Admin for 2.0
[ https://issues.apache.org/jira/browse/HBASE-15607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-15607: --- Attachment: HBASE-15607_3.patch Updated patch. Failed test case seems to run. Submitting for QA,. > Remove PB references from Admin for 2.0 > --- > > Key: HBASE-15607 > URL: https://issues.apache.org/jira/browse/HBASE-15607 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan >Priority: Blocker > Fix For: 2.0.0 > > Attachments: HBASE-15607.patch, HBASE-15607_1.patch, > HBASE-15607_2.patch, HBASE-15607_3.patch, HBASE-15607_3.patch > > > This is a sub-task for HBASE-15174. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12116) Hot contention spots; writing
[ https://issues.apache.org/jira/browse/HBASE-12116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-12116: -- Component/s: Performance > Hot contention spots; writing > - > > Key: HBASE-12116 > URL: https://issues.apache.org/jira/browse/HBASE-12116 > Project: HBase > Issue Type: Improvement > Components: Performance >Reporter: stack >Assignee: stack > Fix For: 2.0.0 > > Attachments: 12116.checkForReplicas.txt, > 12116.stringify.and.cache.scanner.maxsize.txt, 12116.txt, Screen Shot > 2014-09-29 at 5.12.51 PM.png, Screen Shot 2014-09-30 at 10.39.34 PM.png, > Screen Shot 2015-04-13 at 2.03.05 PM.png, perf.write3.svg, perf.write4.svg > > > Playing with flight recorder, here are some write-time contentious > synchronizations/locks (picture coming) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15607) Remove PB references from Admin for 2.0
[ https://issues.apache.org/jira/browse/HBASE-15607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-15607: --- Status: Open (was: Patch Available) > Remove PB references from Admin for 2.0 > --- > > Key: HBASE-15607 > URL: https://issues.apache.org/jira/browse/HBASE-15607 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan >Priority: Blocker > Fix For: 2.0.0 > > Attachments: HBASE-15607.patch, HBASE-15607_1.patch, > HBASE-15607_2.patch, HBASE-15607_3.patch > > > This is a sub-task for HBASE-15174. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15716) HRegion#RegionScannerImpl scannerReadPoints synchronization constrains random read
[
https://issues.apache.org/jira/browse/HBASE-15716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15262473#comment-15262473
]
Hadoop QA commented on HBASE-15716:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 3s {color}
| {color:red} HBASE-15716 does not apply to master. Rebase required? Wrong
Branch? See https://yetus.apache.org/documentation/0.2.1/precommit-patchnames
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12801270/15716.wip.more_to_be_done.patch
|
| JIRA Issue | HBASE-15716 |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/1656/console |
| Powered by | Apache Yetus 0.2.1 http://yetus.apache.org |
This message was automatically generated.
> HRegion#RegionScannerImpl scannerReadPoints synchronization constrains random
> read
> --
>
> Key: HBASE-15716
> URL: https://issues.apache.org/jira/browse/HBASE-15716
> Project: HBase
> Issue Type: Bug
> Components: Performance
>Reporter: stack
>Assignee: stack
> Attachments: 15716.prune.synchronizations.patch,
> 15716.prune.synchronizations.v3.patch, 15716.prune.synchronizations.v4.patch,
> 15716.prune.synchronizations.v4.patch, 15716.wip.more_to_be_done.patch,
> Screen Shot 2016-04-26 at 2.05.45 PM.png, Screen Shot 2016-04-26 at 2.06.14
> PM.png, Screen Shot 2016-04-26 at 2.07.06 PM.png, Screen Shot 2016-04-26 at
> 2.25.26 PM.png, Screen Shot 2016-04-26 at 6.02.29 PM.png, Screen Shot
> 2016-04-27 at 9.49.35 AM.png,
> current-branch-1.vs.NoSynchronization.vs.Patch.png, hits.png,
> remove_cslm.patch
>
>
> Here is a [~lhofhansl] special.
> When we construct the region scanner, we get our read point and then store it
> with the scanner instance in a Region scoped CSLM. This is done under a
> synchronize on the CSLM.
> This synchronize on a region-scoped Map creating region scanners is the
> outstanding point of lock contention according to flight recorder (My work
> load is workload c, random reads).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
