[jira] [Commented] (HBASE-17739) BucketCache is inefficient/wasteful/dumb in its bucket allocations
[ https://issues.apache.org/jira/browse/HBASE-17739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15934111#comment-15934111 ] Anoop Sam John commented on HBASE-17739: bq.Heap overhead is close to 500 bytes per block. You mean the Backing map entry per block right? BucketEntry if I see, having an overhead of 47 bytes per object and BucketCacheKey 17 bytes per object. So per entry size is below 100 only? What was ur math V? > BucketCache is inefficient/wasteful/dumb in its bucket allocations > -- > > Key: HBASE-17739 > URL: https://issues.apache.org/jira/browse/HBASE-17739 > Project: HBase > Issue Type: Sub-task > Components: BucketCache >Reporter: stack > > By default we allocate 14 buckets with sizes from 5K to 513K. If lots of heap > given over to bucketcache and say no allocattions made for a particular > bucket size, this means we have a bunch of the bucketcache that just goes > idle/unused. > For example, say heap is 100G. We'll divide it up among the sizes. If say we > only ever do 5k records, then most of the cache will go unused while the > allocation for 5k objects will see churn. > Here is an old note of [~anoop.hbase]'s' from a conversation on bucket cache > we had offlist that describes the issue: > "By default we have those 14 buckets with size range of 5K to 513K. > All sizes will have one bucket (with size 513*4) each except the > last size.. ie. 513K sized many buckets will be there. If we keep on > writing only same sized blocks, we may loose all in btw sized buckets. > Say we write only 4K sized blocks. We will 1st fill the bucket in 5K > size. There is only one such bucket. Once this is filled, we will try > to grab a complete free bucket from other sizes.. But we can not take > it from 9K... 385K sized ones as there is only ONE bucket for these > sizes. We will take only from 513 size.. There are many in that... > So we will eventually take all the buckets from 513 except the last > one.. Ya it has to keep at least one in evey size.. So we will > loose these much size.. They are of no use." > We should set the size type on the fly as the records come in. > Or better, we should choose record size on the fly. Here is another comment > from [~anoop.hbase]: > "The second is the biggest contributor. Suppose instead of 4K > sized blocks, the user has 2 K sized blocks.. When we write a block to > bucket slot, we will reserve size equal to the allocated size for that block. > So when we write 2K sized blocks (may be actual size a bit more than > 2K ) we will take 5K with each of the block. So u can see that we are > loosing ~3K with every block. Means we are loosing more than half." > He goes on: "If am 100% sure that all my table having 2K HFile block size, I > need to give this config a value 3 * 1024 (Exact 2 K if I give there may be > again problem! That is another story we need to see how we can give > more guarantee for the block size restriction HBASE-15248).. So here also > ~1K loose for every 2K.. So some thing like a 30% loose !!! :-(“" > So, we should figure the record sizes ourselves on the fly. > Anything less has us wasting loads of cache space, nvm inefficiences lost > because of how we serialize base types to cache. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (HBASE-17814) Move hbasecon site to hbase.apache.org
stack created HBASE-17814: - Summary: Move hbasecon site to hbase.apache.org Key: HBASE-17814 URL: https://issues.apache.org/jira/browse/HBASE-17814 Project: HBase Issue Type: Bug Reporter: stack Moving our hbasecon pages from a site that Cloudera sponsored. We want to be able to point hbasecon our new hosts for this year (and keep around links to the old content which while it is all up on youtube and slideshare, the hbasecon archive pages have the pointers). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17806) TestRSGroups#testMoveServersAndTables is flaky in master branch
[
https://issues.apache.org/jira/browse/HBASE-17806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15934061#comment-15934061
]
Guangxu Cheng commented on HBASE-17806:
---
Thanks all for the patience reviews. [~yuzhih...@gmail.com][~apurtell]
> TestRSGroups#testMoveServersAndTables is flaky in master branch
> ---
>
> Key: HBASE-17806
> URL: https://issues.apache.org/jira/browse/HBASE-17806
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
>Assignee: Guangxu Cheng
> Fix For: 2.0
>
> Attachments: HBASE-17806-v1.patch
>
>
> According to https://builds.apache.org/job/HBASE-Flaky-Tests ,
> TestRSGroups#testMoveServersAndTables is the top flaky test.
> Recent test failure:
> https://builds.apache.org/job/HBASE-Flaky-Tests/14062/testReport/junit/org.apache.hadoop.hbase.rsgroup/TestRSGroups/testMoveServersAndTables/
> {code}
> java.lang.AssertionError: expected:<4> but was:<5>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at
> org.apache.hadoop.hbase.rsgroup.TestRSGroupsBase.testMoveServersAndTables(TestRSGroupsBase.java:747)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-17798) RpcServer.Listener.Reader can abort due to CancelledKeyException
[
https://issues.apache.org/jira/browse/HBASE-17798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15934036#comment-15934036
]
Hadoop QA commented on HBASE-17798:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 21s
{color} | {color:blue} Docker mode activated. {color} |
| {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
17s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 37s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
49s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
14s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
43s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 28s
{color} | {color:green} master passed {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 36s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 36s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
47s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
14s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
27m 9s {color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha2. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
52s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 27s
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 100m 49s
{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
16s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 140m 42s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:8d52d23 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12859685/17798-master-v2.patch
|
| JIRA Issue | HBASE-17798 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux e71a85eb1e35 3.13.0-107-generic #154-Ubuntu SMP Tue Dec 20
09:57:27 UTC 2016 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 / a41b185 |
| Default Java | 1.8.0_121 |
| findbugs | v3.0.0 |
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/6177/artifact/patchprocess/patch-unit-hbase-server.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/6177/testReport/ |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/6177/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> RpcServer.Listener.Reader can abort due to CancelledKeyException
>
>
> Key: HBASE-17798
> URL: https://issues.apache.org/jira/browse/HBASE-17798
>
[jira] [Commented] (HBASE-15583) Discuss mutable vs immutable HTableDescriptor
[ https://issues.apache.org/jira/browse/HBASE-15583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15934035#comment-15934035 ] stack commented on HBASE-15583: --- Yes. It has been deprecated for a whole major version. Go for it. Thanks [~chia7712] > Discuss mutable vs immutable HTableDescriptor > - > > Key: HBASE-15583 > URL: https://issues.apache.org/jira/browse/HBASE-15583 > Project: HBase > Issue Type: Sub-task >Affects Versions: 2.0.0 >Reporter: Gabor Liptak >Assignee: Chia-Ping Tsai >Priority: Minor > Labels: beginner > Fix For: 2.0.0 > > > From [~enis] in https://issues.apache.org/jira/browse/HBASE-15505: > PS Should UnmodifyableHTableDescriptor be renamed to > UnmodifiableHTableDescriptor? > It should be named ImmutableHTableDescriptor to be consistent with > collections naming. Let's do this as a subtask of the parent jira, not here. > Thinking about it though, why would we return an Immutable HTD in > HTable.getTableDescriptor() versus a mutable HTD in > Admin.getTableDescriptor(). It does not make sense. Should we just get rid of > the Immutable ones? > We also have UnmodifyableHRegionInfo which is not used at the moment it > seems. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-13395) Remove HTableInterface
[ https://issues.apache.org/jira/browse/HBASE-13395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15934026#comment-15934026 ] Chia-Ping Tsai commented on HBASE-13395: Am +1 [~mantonov] if you are fine, could you commit it? > Remove HTableInterface > -- > > Key: HBASE-13395 > URL: https://issues.apache.org/jira/browse/HBASE-13395 > Project: HBase > Issue Type: Sub-task > Components: API >Affects Versions: 2.0.0 >Reporter: Mikhail Antonov >Assignee: Jan Hentschel > Fix For: 2.0.0 > > Attachments: HBASE-13395.master.001.patch, > HBASE-13395.master.002.patch, HBASE-13395.master.003.patch, > HBASE-13395.master.004.patch > > > This class is marked as deprecated, probably can remove it, and if any > methods from this specific class are in active use, need to decide what to do > on callers' side. Should be able to replace with just Table interface usage. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17809) cleanup unused class
[ https://issues.apache.org/jira/browse/HBASE-17809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai updated HBASE-17809: --- Status: Patch Available (was: Open) > cleanup unused class > > > Key: HBASE-17809 > URL: https://issues.apache.org/jira/browse/HBASE-17809 > Project: HBase > Issue Type: Sub-task >Affects Versions: 2.0.0 >Reporter: Chia-Ping Tsai >Assignee: Chia-Ping Tsai > Fix For: 2.0.0 > > Attachments: HBASE-17809.v0.patch, HBASE-17809.v0.patch > > > inspired by HBASE-17805. We had left a lot of orphan class due to a bunch of > commits. We shall remove them. > ||class||last meeting||why||line count| > |LruHashMap|HBASE-1822|get rid of|1100| > |ScannerTimeoutException|HBASE-16266|get rid of|45| > |SortedCopyOnWriteSet|HBASE-12748|get rid of|178| > |TestSortedCopyOnWriteSet|HBASE-12748|get rid of|107| > |DelegatingRetryingCallable|HBASE-9049|create but never used|65| > |LockTimeoutException|HBASE-16786|get rid of|44| > |OperationConflictException|HBASE-9899|get rid of|50| > |InvalidQuotaSettingsException|HBASE-11598|create but never used|33| > |ShareableMemory|HBASE-15735|get rid of|40| > |BoundedArrayQueue|HBASE-14860|get rid of|82| > |TestBoundedArrayQueue|HBASE-14860|get rid of|61| > |ChecksumFactory|HBASE-11927|get rid of|100| > |TokenDepthComparator|HBASE-4676|create but never used|65| > |RegionMergeTransaction|HBASE-17470|get rid of|249| > |MetaUtils|HBASE-1822|get rid of|156| -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17809) cleanup unused class
[ https://issues.apache.org/jira/browse/HBASE-17809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai updated HBASE-17809: --- Attachment: HBASE-17809.v0.patch > cleanup unused class > > > Key: HBASE-17809 > URL: https://issues.apache.org/jira/browse/HBASE-17809 > Project: HBase > Issue Type: Sub-task >Affects Versions: 2.0.0 >Reporter: Chia-Ping Tsai >Assignee: Chia-Ping Tsai > Fix For: 2.0.0 > > Attachments: HBASE-17809.v0.patch, HBASE-17809.v0.patch > > > inspired by HBASE-17805. We had left a lot of orphan class due to a bunch of > commits. We shall remove them. > ||class||last meeting||why||line count| > |LruHashMap|HBASE-1822|get rid of|1100| > |ScannerTimeoutException|HBASE-16266|get rid of|45| > |SortedCopyOnWriteSet|HBASE-12748|get rid of|178| > |TestSortedCopyOnWriteSet|HBASE-12748|get rid of|107| > |DelegatingRetryingCallable|HBASE-9049|create but never used|65| > |LockTimeoutException|HBASE-16786|get rid of|44| > |OperationConflictException|HBASE-9899|get rid of|50| > |InvalidQuotaSettingsException|HBASE-11598|create but never used|33| > |ShareableMemory|HBASE-15735|get rid of|40| > |BoundedArrayQueue|HBASE-14860|get rid of|82| > |TestBoundedArrayQueue|HBASE-14860|get rid of|61| > |ChecksumFactory|HBASE-11927|get rid of|100| > |TokenDepthComparator|HBASE-4676|create but never used|65| > |RegionMergeTransaction|HBASE-17470|get rid of|249| > |MetaUtils|HBASE-1822|get rid of|156| -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17809) cleanup unused class
[ https://issues.apache.org/jira/browse/HBASE-17809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai updated HBASE-17809: --- Status: Open (was: Patch Available) All failed tests pass locally. retry > cleanup unused class > > > Key: HBASE-17809 > URL: https://issues.apache.org/jira/browse/HBASE-17809 > Project: HBase > Issue Type: Sub-task >Affects Versions: 2.0.0 >Reporter: Chia-Ping Tsai >Assignee: Chia-Ping Tsai > Fix For: 2.0.0 > > Attachments: HBASE-17809.v0.patch > > > inspired by HBASE-17805. We had left a lot of orphan class due to a bunch of > commits. We shall remove them. > ||class||last meeting||why||line count| > |LruHashMap|HBASE-1822|get rid of|1100| > |ScannerTimeoutException|HBASE-16266|get rid of|45| > |SortedCopyOnWriteSet|HBASE-12748|get rid of|178| > |TestSortedCopyOnWriteSet|HBASE-12748|get rid of|107| > |DelegatingRetryingCallable|HBASE-9049|create but never used|65| > |LockTimeoutException|HBASE-16786|get rid of|44| > |OperationConflictException|HBASE-9899|get rid of|50| > |InvalidQuotaSettingsException|HBASE-11598|create but never used|33| > |ShareableMemory|HBASE-15735|get rid of|40| > |BoundedArrayQueue|HBASE-14860|get rid of|82| > |TestBoundedArrayQueue|HBASE-14860|get rid of|61| > |ChecksumFactory|HBASE-11927|get rid of|100| > |TokenDepthComparator|HBASE-4676|create but never used|65| > |RegionMergeTransaction|HBASE-17470|get rid of|249| > |MetaUtils|HBASE-1822|get rid of|156| -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (HBASE-15583) Discuss mutable vs immutable HTableDescriptor
[ https://issues.apache.org/jira/browse/HBASE-15583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai reassigned HBASE-15583: -- Assignee: Chia-Ping Tsai > Discuss mutable vs immutable HTableDescriptor > - > > Key: HBASE-15583 > URL: https://issues.apache.org/jira/browse/HBASE-15583 > Project: HBase > Issue Type: Sub-task >Affects Versions: 2.0.0 >Reporter: Gabor Liptak >Assignee: Chia-Ping Tsai >Priority: Minor > Labels: beginner > Fix For: 2.0.0 > > > From [~enis] in https://issues.apache.org/jira/browse/HBASE-15505: > PS Should UnmodifyableHTableDescriptor be renamed to > UnmodifiableHTableDescriptor? > It should be named ImmutableHTableDescriptor to be consistent with > collections naming. Let's do this as a subtask of the parent jira, not here. > Thinking about it though, why would we return an Immutable HTD in > HTable.getTableDescriptor() versus a mutable HTD in > Admin.getTableDescriptor(). It does not make sense. Should we just get rid of > the Immutable ones? > We also have UnmodifyableHRegionInfo which is not used at the moment it > seems. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-15583) Discuss mutable vs immutable HTableDescriptor
[
https://issues.apache.org/jira/browse/HBASE-15583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15934008#comment-15934008
]
Chia-Ping Tsai commented on HBASE-15583:
bq. Could we change the returned type to be ImmutableHTD in Table and Admin
leaving the APIs as they are. If client tries to modify the IHTD, they'll get
an exception the first time they try. The javadoc says we return an immurable
(least I thought it did).
copy that. I will address your comment.
The HTD has a swath of deprecated methods...Firstly, we need to refactor HTD.
{noformat}
/**
* Default constructor which constructs an empty object.
* For deserializing an HTableDescriptor instance only.
* @deprecated As of release 0.96 (https://issues.apache.org/jira/browse/HBASE-5453;>HBASE-5453).
* This was made protected in 2.0.0 and will be removed in HBase
3.0.0.
* Used by Writables and Writables are going away.
*/
@Deprecated
protected HTableDescriptor() {
super();
}
{noformat}
The construction is deprecated in 1.0.0 (HBASE-5453). Could we remove it in
2.0? I can't see the point of “This was made protected in 2.0.0 and will be
removed in HBase 3.0.0."
> Discuss mutable vs immutable HTableDescriptor
> -
>
> Key: HBASE-15583
> URL: https://issues.apache.org/jira/browse/HBASE-15583
> Project: HBase
> Issue Type: Sub-task
>Affects Versions: 2.0.0
>Reporter: Gabor Liptak
>Priority: Minor
> Labels: beginner
> Fix For: 2.0.0
>
>
> From [~enis] in https://issues.apache.org/jira/browse/HBASE-15505:
> PS Should UnmodifyableHTableDescriptor be renamed to
> UnmodifiableHTableDescriptor?
> It should be named ImmutableHTableDescriptor to be consistent with
> collections naming. Let's do this as a subtask of the parent jira, not here.
> Thinking about it though, why would we return an Immutable HTD in
> HTable.getTableDescriptor() versus a mutable HTD in
> Admin.getTableDescriptor(). It does not make sense. Should we just get rid of
> the Immutable ones?
> We also have UnmodifyableHRegionInfo which is not used at the moment it
> seems.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (HBASE-17812) Remove RpcConnection from pool in AbstractRpcClient.cancelConnections
[ https://issues.apache.org/jira/browse/HBASE-17812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-17812: -- Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Pushed to master. Thanks [~stack] for reviewing. > Remove RpcConnection from pool in AbstractRpcClient.cancelConnections > - > > Key: HBASE-17812 > URL: https://issues.apache.org/jira/browse/HBASE-17812 > Project: HBase > Issue Type: Bug > Components: Client, rpc >Affects Versions: 2.0.0 >Reporter: Duo Zhang >Assignee: Duo Zhang > Labels: trivial > Fix For: 2.0.0 > > Attachments: HBASE-17812.patch > > > Found it when backporting the new rpc implementation to branch-1 in > HBASE-16584. It will cause TestHCM fail on branch-1 as on branch-1 the > default rpc implementation is BlockingRpcClient which is not always > reconnectable after shutdown. On master TestHCM will not fail as > NettyRpcConnection is always reconnectable. But we still need to fix it as it > is a bug. Only a trivial one line patch. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17805) We should remove BoundedByteBufferPool because it is replaced by ByteBufferPool
[ https://issues.apache.org/jira/browse/HBASE-17805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai updated HBASE-17805: --- Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Thanks for the reviews. [~stack] > We should remove BoundedByteBufferPool because it is replaced by > ByteBufferPool > --- > > Key: HBASE-17805 > URL: https://issues.apache.org/jira/browse/HBASE-17805 > Project: HBase > Issue Type: Sub-task >Affects Versions: 2.0.0 >Reporter: Chia-Ping Tsai >Assignee: Chia-Ping Tsai >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-17805.v0.patch, HBASE-17805.v1.patch > > > Follow the discussion in HBASE-15525. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-16014) Get and Put constructor argument lists are divergent
[
https://issues.apache.org/jira/browse/HBASE-16014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai updated HBASE-16014:
---
Resolution: Fixed
Hadoop Flags: Reviewed
Status: Resolved (was: Patch Available)
Thanks for the patch. [~brandboat]
> Get and Put constructor argument lists are divergent
>
>
> Key: HBASE-16014
> URL: https://issues.apache.org/jira/browse/HBASE-16014
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: Nick Dimiduk
>Assignee: brandboat
> Fix For: 2.0.0
>
> Attachments: HBASE-16014.master.001.patch, HBASE-16014_v0.patch,
> HBASE-16014_v1.patch, HBASE-16014_v2.patch
>
>
> API for construing Get and Put objects for a specific rowkey is quite
> different.
> [Put|http://hbase.apache.org/apidocs/org/apache/hadoop/hbase/client/Put.html#constructor_summary]
> supports many more variations for specifying the target rowkey and timestamp
> compared to
> [Get|http://hbase.apache.org/apidocs/org/apache/hadoop/hbase/client/Get.html#constructor_summary].
> Notably lacking are {{Get(byte[], int, int)}} and {{Get(ByteBuffer)}}
> variations.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-17175) backport HBASE-17127 to 1.3.1
[ https://issues.apache.org/jira/browse/HBASE-17175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933945#comment-15933945 ] Hudson commented on HBASE-17175: SUCCESS: Integrated in Jenkins build HBase-1.3-JDK7 #128 (See [https://builds.apache.org/job/HBase-1.3-JDK7/128/]) HBASE-17175 backport HBASE-17127 (Locate region should fail fast if (liyu: rev 98b5d2cd4b0badef5f576cb35c8c8f1df1c88899) * (edit) hbase-client/src/test/java/org/apache/hadoop/hbase/client/TestClientNoCluster.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/ConnectionManager.java > backport HBASE-17127 to 1.3.1 > - > > Key: HBASE-17175 > URL: https://issues.apache.org/jira/browse/HBASE-17175 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.0 >Reporter: Yu Li >Assignee: Yu Li > Fix For: 1.3.1 > > Attachments: HBASE-17175.branch-1.3.patch > > > branch-1.3 is currently freeze for 1.3.0 release, need to backport > HBASE-17127 later -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17127) Locate region should fail fast if underlying Connection already closed
[
https://issues.apache.org/jira/browse/HBASE-17127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933946#comment-15933946
]
Hudson commented on HBASE-17127:
SUCCESS: Integrated in Jenkins build HBase-1.3-JDK7 #128 (See
[https://builds.apache.org/job/HBase-1.3-JDK7/128/])
HBASE-17175 backport HBASE-17127 (Locate region should fail fast if (liyu: rev
98b5d2cd4b0badef5f576cb35c8c8f1df1c88899)
* (edit)
hbase-client/src/main/java/org/apache/hadoop/hbase/client/ConnectionManager.java
* (edit)
hbase-client/src/test/java/org/apache/hadoop/hbase/client/TestClientNoCluster.java
> Locate region should fail fast if underlying Connection already closed
> --
>
> Key: HBASE-17127
> URL: https://issues.apache.org/jira/browse/HBASE-17127
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.1.7, 1.2.4
>Reporter: Yu Li
>Assignee: Yu Li
> Fix For: 2.0.0, 1.4.0, 1.2.5, 0.98.24, 1.1.8
>
> Attachments: HBASE-17127.patch
>
>
> Currently if try to locate region when underlying connection is closed, we
> will retry and wait at least 10s for each round until exhausted (refer to the
> catch clause of {{RpcRetryingCallerImpl#callWithRetries}} and
> {{RegionServerCallable#sleep}} for more details), which is unnecessary and
> time-costing.
> The issue is caused by user incorrectly manipulating connection, which shows
> the disadvantage of force user to handle connection life cycle and proves the
> necessity to support auto-managed connection as we did before, as indicated
> in HBASE-17009
> In this JIRA we will make it fail fast in the above case.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (HBASE-17798) RpcServer.Listener.Reader can abort due to CancelledKeyException
[
https://issues.apache.org/jira/browse/HBASE-17798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-17798:
---
Attachment: 17798-master-v2.patch
> RpcServer.Listener.Reader can abort due to CancelledKeyException
>
>
> Key: HBASE-17798
> URL: https://issues.apache.org/jira/browse/HBASE-17798
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0, 1.3.0, 1.2.4, 0.98.24
>Reporter: Guangxu Cheng
> Attachments: 17798-master-v2.patch, connections.png,
> HBASE-17798-0.98-v1.patch, HBASE-17798-0.98-v2.patch,
> HBASE-17798-branch-1-v1.patch, HBASE-17798-branch-1-v2.patch,
> HBASE-17798-master-v1.patch, HBASE-17798-master-v2.patch
>
>
> In our production cluster(0.98), some of the requests were unacceptable
> because RpcServer.Listener.Reader were aborted.
> getReader() will return the next reader to deal with request.
> The implementation of getReader() as below：
> {code:title=RpcServer.java|borderStyle=solid}
> // The method that will return the next reader to work with
> // Simplistic implementation of round robin for now
> Reader getReader() {
> currentReader = (currentReader + 1) % readers.length;
> return readers[currentReader];
> }
> {code}
> If one of the readers abort, then it will lead to fall on the reader's
> request will never be dealt with.
> Why does RpcServer.Listener.Reader abort?We add the debug log to get it.
> After a while, we got the following exception:
> {code}
> 2017-03-10 08:05:13,247 ERROR [RpcServer.reader=3,port=60020] ipc.RpcServer:
> RpcServer.listener,port=60020: unexpectedly error in Reader(Throwable)
> java.nio.channels.CancelledKeyException
> at sun.nio.ch.SelectionKeyImpl.ensureValid(SelectionKeyImpl.java:73)
> at sun.nio.ch.SelectionKeyImpl.readyOps(SelectionKeyImpl.java:87)
> at java.nio.channels.SelectionKey.isReadable(SelectionKey.java:289)
> at
> org.apache.hadoop.hbase.ipc.RpcServer$Listener$Reader.doRunLoop(RpcServer.java:592)
> at
> org.apache.hadoop.hbase.ipc.RpcServer$Listener$Reader.run(RpcServer.java:566)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> So, when deal with the request in reader, we should handle
> CanceledKeyException.
> --
> versions 1.x and 2.0 will log and retrun when dealing with the
> InterruptedException in Reader#doRunLoop after HBASE-10521. It will lead to
> the same problem.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-17798) RpcServer.Listener.Reader can abort due to CancelledKeyException
[
https://issues.apache.org/jira/browse/HBASE-17798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933933#comment-15933933
]
Ted Yu commented on HBASE-17798:
In the future, when you have image and patch to attach, attach patch last.
Otherwise:
{code}
https://issues.apache.org/jira/secure/attachment/12859422/connections.png ->
Downloaded
ERROR: Unsure how to process HBASE-17798.
{code}
> RpcServer.Listener.Reader can abort due to CancelledKeyException
>
>
> Key: HBASE-17798
> URL: https://issues.apache.org/jira/browse/HBASE-17798
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0, 1.3.0, 1.2.4, 0.98.24
>Reporter: Guangxu Cheng
> Attachments: 17798-master-v2.patch, connections.png,
> HBASE-17798-0.98-v1.patch, HBASE-17798-0.98-v2.patch,
> HBASE-17798-branch-1-v1.patch, HBASE-17798-branch-1-v2.patch,
> HBASE-17798-master-v1.patch, HBASE-17798-master-v2.patch
>
>
> In our production cluster(0.98), some of the requests were unacceptable
> because RpcServer.Listener.Reader were aborted.
> getReader() will return the next reader to deal with request.
> The implementation of getReader() as below：
> {code:title=RpcServer.java|borderStyle=solid}
> // The method that will return the next reader to work with
> // Simplistic implementation of round robin for now
> Reader getReader() {
> currentReader = (currentReader + 1) % readers.length;
> return readers[currentReader];
> }
> {code}
> If one of the readers abort, then it will lead to fall on the reader's
> request will never be dealt with.
> Why does RpcServer.Listener.Reader abort?We add the debug log to get it.
> After a while, we got the following exception:
> {code}
> 2017-03-10 08:05:13,247 ERROR [RpcServer.reader=3,port=60020] ipc.RpcServer:
> RpcServer.listener,port=60020: unexpectedly error in Reader(Throwable)
> java.nio.channels.CancelledKeyException
> at sun.nio.ch.SelectionKeyImpl.ensureValid(SelectionKeyImpl.java:73)
> at sun.nio.ch.SelectionKeyImpl.readyOps(SelectionKeyImpl.java:87)
> at java.nio.channels.SelectionKey.isReadable(SelectionKey.java:289)
> at
> org.apache.hadoop.hbase.ipc.RpcServer$Listener$Reader.doRunLoop(RpcServer.java:592)
> at
> org.apache.hadoop.hbase.ipc.RpcServer$Listener$Reader.run(RpcServer.java:566)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> So, when deal with the request in reader, we should handle
> CanceledKeyException.
> --
> versions 1.x and 2.0 will log and retrun when dealing with the
> InterruptedException in Reader#doRunLoop after HBASE-10521. It will lead to
> the same problem.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-17175) backport HBASE-17127 to 1.3.1
[ https://issues.apache.org/jira/browse/HBASE-17175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933930#comment-15933930 ] Hudson commented on HBASE-17175: SUCCESS: Integrated in Jenkins build HBase-1.3-JDK8 #138 (See [https://builds.apache.org/job/HBase-1.3-JDK8/138/]) HBASE-17175 backport HBASE-17127 (Locate region should fail fast if (liyu: rev 98b5d2cd4b0badef5f576cb35c8c8f1df1c88899) * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/ConnectionManager.java * (edit) hbase-client/src/test/java/org/apache/hadoop/hbase/client/TestClientNoCluster.java > backport HBASE-17127 to 1.3.1 > - > > Key: HBASE-17175 > URL: https://issues.apache.org/jira/browse/HBASE-17175 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.0 >Reporter: Yu Li >Assignee: Yu Li > Fix For: 1.3.1 > > Attachments: HBASE-17175.branch-1.3.patch > > > branch-1.3 is currently freeze for 1.3.0 release, need to backport > HBASE-17127 later -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17127) Locate region should fail fast if underlying Connection already closed
[
https://issues.apache.org/jira/browse/HBASE-17127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933931#comment-15933931
]
Hudson commented on HBASE-17127:
SUCCESS: Integrated in Jenkins build HBase-1.3-JDK8 #138 (See
[https://builds.apache.org/job/HBase-1.3-JDK8/138/])
HBASE-17175 backport HBASE-17127 (Locate region should fail fast if (liyu: rev
98b5d2cd4b0badef5f576cb35c8c8f1df1c88899)
* (edit)
hbase-client/src/main/java/org/apache/hadoop/hbase/client/ConnectionManager.java
* (edit)
hbase-client/src/test/java/org/apache/hadoop/hbase/client/TestClientNoCluster.java
> Locate region should fail fast if underlying Connection already closed
> --
>
> Key: HBASE-17127
> URL: https://issues.apache.org/jira/browse/HBASE-17127
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.1.7, 1.2.4
>Reporter: Yu Li
>Assignee: Yu Li
> Fix For: 2.0.0, 1.4.0, 1.2.5, 0.98.24, 1.1.8
>
> Attachments: HBASE-17127.patch
>
>
> Currently if try to locate region when underlying connection is closed, we
> will retry and wait at least 10s for each round until exhausted (refer to the
> catch clause of {{RpcRetryingCallerImpl#callWithRetries}} and
> {{RegionServerCallable#sleep}} for more details), which is unnecessary and
> time-costing.
> The issue is caused by user incorrectly manipulating connection, which shows
> the disadvantage of force user to handle connection life cycle and proves the
> necessity to support auto-managed connection as we did before, as indicated
> in HBASE-17009
> In this JIRA we will make it fail fast in the above case.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-16755) Honor flush policy under global memstore pressure
[ https://issues.apache.org/jira/browse/HBASE-16755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933885#comment-15933885 ] Duo Zhang commented on HBASE-16755: --- Oh this issue is still pending. I'm fine on committing the patch here first. The suggestions above are just TODOs. We can open other issues to track them. Thanks. > Honor flush policy under global memstore pressure > - > > Key: HBASE-16755 > URL: https://issues.apache.org/jira/browse/HBASE-16755 > Project: HBase > Issue Type: Improvement > Components: regionserver >Reporter: Ashu Pachauri >Assignee: Ashu Pachauri > Fix For: 1.3.1 > > Attachments: HBASE-16755.v0.patch > > > When global memstore reaches the low water mark, we pick the best flushable > region and flush all column families for it. This is a suboptimal approach in > the sense that it leads to an unnecessarily high file creation rate and IO > amplification due to compactions. We should still try to honor the underlying > FlushPolicy. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-16755) Honor flush policy under global memstore pressure
[ https://issues.apache.org/jira/browse/HBASE-16755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933867#comment-15933867 ] Gary Helmling commented on HBASE-16755: --- [~enis], [~Apache9] -- how about the following approach: * branch-1.3: commit the current patch. All of our existing FlushPolicy implementations will flush something, but this won't enforce that something has been flushed by any possible FlushPolicy implementation. * branch-1 & master: in addition, make one of the changes Ashu described to allow the flusher to enforce that something has always flushed, regardless of the FlushPolicy implementation. Does this seem reasonable, or are there concerns about the current patch going in to 1.3.1? > Honor flush policy under global memstore pressure > - > > Key: HBASE-16755 > URL: https://issues.apache.org/jira/browse/HBASE-16755 > Project: HBase > Issue Type: Improvement > Components: regionserver >Reporter: Ashu Pachauri >Assignee: Ashu Pachauri > Fix For: 1.3.1 > > Attachments: HBASE-16755.v0.patch > > > When global memstore reaches the low water mark, we pick the best flushable > region and flush all column families for it. This is a suboptimal approach in > the sense that it leads to an unnecessarily high file creation rate and IO > amplification due to compactions. We should still try to honor the underlying > FlushPolicy. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17070) backport HBASE-17020 to 1.3.1
[
https://issues.apache.org/jira/browse/HBASE-17070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933849#comment-15933849
]
Hadoop QA commented on HBASE-17070:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 19s
{color} | {color:blue} Docker mode activated. {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 2 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
47s {color} | {color:green} branch-1.3 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 29s
{color} | {color:green} branch-1.3 passed with JDK v1.8.0_121 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 35s
{color} | {color:green} branch-1.3 passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
54s {color} | {color:green} branch-1.3 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
16s {color} | {color:green} branch-1.3 passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
50s {color} | {color:green} branch-1.3 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 25s
{color} | {color:green} branch-1.3 passed with JDK v1.8.0_121 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 33s
{color} | {color:green} branch-1.3 passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
45s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 29s
{color} | {color:green} the patch passed with JDK v1.8.0_121 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 29s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 33s
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 33s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
54s {color} | {color:green} the patch passed {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} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
15m 57s {color} | {color:green} The 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} hbaseprotoc {color} | {color:green} 0m
14s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m 7s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 24s
{color} | {color:green} the patch passed with JDK v1.8.0_121 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 32s
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 78m 53s
{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
14s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 109m 1s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:66fbe99 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12859662/HBASE-17070.branch-1.3.patch
|
| JIRA Issue | HBASE-17070 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux a4682c6c974b 3.13.0-106-generic #153-Ubuntu SMP Tue Dec 6
15:44:32 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | /testptch/patchprocess/precommit/personality/hbase.sh |
| git revision | branch-1.3 / 98b5d2c |
| Default Java | 1.7.0_80 |
| Multi-JDK versions | /usr/lib/jvm/java-8-oracle:1.8.0_121
[jira] [Commented] (HBASE-17800) [C++] handle exceptions in client RPC
[
https://issues.apache.org/jira/browse/HBASE-17800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933835#comment-15933835
]
Enis Soztutar commented on HBASE-17800:
---
Thanks for the patch.
- Remove this:
{code}
+private:
+
private:
{code}
- In RemoteException, you might as well carry the whole PB object, and not deal
with setting individual fields.
- Why not return a string here?
{code}
const char* what()
{code}
- Exceptions can be raised from the server side, where it gets re-thrown as
RemoteExceptions or ServiceExceptions in the rpc layer, however, in the
retrying callers, these get un-wrapped and rethrown again as the cause of the
exception. That is why we rely on the DoNotRetryException in the exception
hierarchy. Will we need to be able to throw DoNotRetryExceptions from purely
the client side? I think so (like for example when operation timeouts or
something). In this case, maybe we should instead do something like this: all
exceptions in HBase client side will be instances of IOException or
HBaseException or something. We add the {{do_not_retry()}} method there which
returns false by default, and we get rid of DoNotRetryException.
RemoteException just returns the do_not_retry() from the server side. In this
case, we will not need to depend on exception hierarchy like we do on the java
side.
- You have both {{remoteException}} and {{remote_exception}} which is pretty
confusing. Better to not allocate objects by new.
> [C++] handle exceptions in client RPC
> -
>
> Key: HBASE-17800
> URL: https://issues.apache.org/jira/browse/HBASE-17800
> Project: HBase
> Issue Type: Sub-task
>Reporter: Xiaobing Zhou
>Assignee: Xiaobing Zhou
> Attachments: HBASE-17800-HBASE-14850.000.patch
>
>
> Exceptions are ignored in current client RPC. They should be handled properly
> to be consumed by RPC retry or propagated up to APIs.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-16084) Clean up the stale references in javadoc
[ https://issues.apache.org/jira/browse/HBASE-16084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933814#comment-15933814 ] Hudson commented on HBASE-16084: SUCCESS: Integrated in Jenkins build HBase-Trunk_matrix #2709 (See [https://builds.apache.org/job/HBase-Trunk_matrix/2709/]) HBASE-16084 Cleaned up the stale references in Javadoc (tedyu: rev 55d6dcaf877cc5223e679736eb613173229c18be) * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreFileReader.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/wal/SyncFuture.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/constraint/Constraint.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/util/MultiThreadedAction.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/HTableDescriptor.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/filter/TestFirstKeyValueMatchingQualifiersFilter.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/zookeeper/RecoverableZooKeeper.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestRegionMergeTransactionOnCluster.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/HFileBlock.java * (edit) hbase-procedure/src/main/java/org/apache/hadoop/hbase/procedure2/store/wal/ProcedureWALFormatReader.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/TestPartialResultsFromClientSide.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/MasterCallable.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/balancer/StochasticLoadBalancer.java * (edit) hbase-common/src/main/java/org/apache/hadoop/hbase/util/OrderedBytes.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/wal/SequenceIdAccounting.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/CompoundBloomFilterWriter.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/ConnectionFactory.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHFileOutputFormat2.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/DataBlockEncodingTool.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/TableNamespaceManager.java * (edit) hbase-prefix-tree/src/main/java/org/apache/hadoop/hbase/codec/prefixtree/scanner/CellSearcher.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/TableAuthManager.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/coprocessor/package-info.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/OOMERegionServer.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestMultipleTimestamps.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/backup/util/RestoreTool.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/ServerRpcController.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/util/LoadTestTool.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/filter/FirstKeyValueMatchingQualifiersFilter.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/wal/FSHLog.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/TestWarmupRegion.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/TestSerialization.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/backup/example/HFileArchiveManager.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/RowCounter.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/AsyncProcess.java * (edit) hbase-common/src/test/java/org/apache/hadoop/hbase/HBaseCommonTestingUtility.java * (edit) hbase-common/src/main/java/org/apache/hadoop/hbase/nio/ByteBuff.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/CoprocessorWhitelistMasterObserver.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/HFileBlockIndex.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/MiniBatchOperationInProgress.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/TestMetaTableLocator.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/mapreduce/TestImportExport.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/backup/HFileArchiver.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/HBaseTestingUtility.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/procedure/TestProcedureMember.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/Query.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/io/hfile/TestSeekTo.java * (edit)
[jira] [Commented] (HBASE-15236) Inconsistent cell reads over multiple bulk-loaded HFiles
[
https://issues.apache.org/jira/browse/HBASE-15236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933816#comment-15933816
]
Hudson commented on HBASE-15236:
SUCCESS: Integrated in Jenkins build HBase-Trunk_matrix #2709 (See
[https://builds.apache.org/job/HBase-Trunk_matrix/2709/])
HBASE-17582 Fix broken drop page cache hint (broken by HBASE-15236). (appy: rev
e39e0e634a2252a352ad799bc2957c72e8d2d2e9)
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreFileScanner.java
> Inconsistent cell reads over multiple bulk-loaded HFiles
>
>
> Key: HBASE-15236
> URL: https://issues.apache.org/jira/browse/HBASE-15236
> Project: HBase
> Issue Type: Bug
>Reporter: Appy
>Assignee: Appy
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-15236-branch-1.2-v1.patch,
> HBASE-15236-branch-1.2-v2.patch, HBASE-15236-branch-1.3-v1.patch,
> HBASE-15236-branch-1-v1.patch, HBASE-15236-master-v2.patch,
> HBASE-15236-master-v3.patch, HBASE-15236-master-v4.patch,
> HBASE-15236-master-v5.patch, HBASE-15236-master-v6.patch,
> HBASE-15236-master-v7.patch, HBASE-15236-master-v8.patch,
> HBASE-15236-master-v9.patch, HBASE-15236.patch, tables_data.zip,
> TestWithSingleHRegion.java
>
>
> If there are two bulkloaded hfiles in a region with same seqID, same
> timestamps and duplicate keys*, get and scan may return different values for
> a key. Not sure how this would happen, but one of our customer uploaded a
> dataset with 2 files in a single region and both having same bulk load
> timestamp. These files are small ~50M (I couldn't find any setting for max
> file size that could lead to 2 files). The range of keys in two hfiles are
> overlapping to some extent, but not fully (so the two files are because of
> region merge).
> In such a case, depending on file sizes (used in
> StoreFile.Comparators.SEQ_ID), we may get different values for the same cell
> (say "r", "cf:50") depending on what we call: get "r" "cf:50" or get "r"
> "cf:".
> To replicate this, i ran ImportTsv twice with 2 different csv files but same
> timestamp (-Dimporttsv.timestamp=1). Collected two resulting hfiles in a
> single directory and loaded with LoadIncrementalHFiles. Here are the commands.
> {noformat}
> //CSV files should be in hdfs:///user/hbase/tmp
> sudo -u hbase hbase org.apache.hadoop.hbase.mapreduce.ImportTsv
> -Dimporttsv.columns=HBASE_ROW_KEY,c:1,c:2,c:3,c:4,c:5,c:6
> -Dimporttsv.separator='|' -Dimporttsv.timestamp=1
> -Dimporttsv.bulk.output=hdfs:///user/hbase/1 t tmp
> {noformat}
> tables_data.zip contains three tables: t, t2, and t3.
> To load these tables and test with them, use the attached
> TestWithSingleHRegion.java. (Change ROOT_DIR and TABLE_NAME variables
> appropriately)
> Hfiles for table 't':
> 1) 07922ac90208445883b2ddc89c424c89 : length = 1094: KVs = (c:5, 55) (c:6, 66)
> 2) 143137fa4fa84625b4e8d1d84a494f08 : length = 1192: KVs = (c:1, 1) (c:2, 2)
> (c:3, 3) (c:4, 4) (c:5, 5) (c:6, 6)
> Get returns 5 where as Scan returns 55.
> On the other hand if I make the first hfile, the one with values 55 and 66
> bigger in size than second hfile, then:
> Get returns 55 where as Scan returns 55.
> This can be seen in table 't2'.
> Weird things:
> 1. Get consistently returns values from larger hfile.
> 2. Scan consistently returns 55.
> Reason:
> Explanation 1: We add StoreFileScanners to heap by iterating over list of
> store files which is kept sorted in DefaultStoreFileManger using
> StoreFile.Comparators.SEQ_ID. It sorts the file first by increasing seq id,
> then by decreasing filesize. So our larger files sizes are always in the
> start.
> Explanation 2: In KeyValueHeap.next(), if both current and this.heap.peek()
> scanners (type is StoreFileScanner in this case) point to KVs which compare
> as equal, we put back the current scanner into heap, and call pollRealKV() to
> get new one. While inserting, KVScannerComparator is used which compares the
> two (one already in heap and the one being inserted) as equal and inserts it
> after the existing one. \[1\]
> Say s1 is scanner over first hfile and s2 over second.
> 1. We scan with s2 to get values 1, 2, 3, 4
> 2. see that both scanners have c:5 as next key, put current scanner s2 back
> in heap, take s1 out
> 4. return 55, advance s1 to key c:6
> 5. compare c:6 to c:5, put back s2 in heap since it has larger key, take out
> s1
> 6. ignore it's value (there is code for that too), advance s2 to c:6
> Go back to step 2 with both scanners having c:6 as next key
> This is wrong because if we add a key between c:4 and c:5 to first hfile, say
> (c:44, foo) which makes s1 as the 'current' scanner when we hit step 2, then
> we'll get the values - 1, 2, 3, 4, foo, 5, 6.
> (try table t3)
> Fix:
> Assign priority ids to
[jira] [Commented] (HBASE-17582) Drop page cache hint is broken
[ https://issues.apache.org/jira/browse/HBASE-17582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933815#comment-15933815 ] Hudson commented on HBASE-17582: SUCCESS: Integrated in Jenkins build HBase-Trunk_matrix #2709 (See [https://builds.apache.org/job/HBase-Trunk_matrix/2709/]) HBASE-17582 Fix broken drop page cache hint (broken by HBASE-15236). (appy: rev e39e0e634a2252a352ad799bc2957c72e8d2d2e9) * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreFileScanner.java > Drop page cache hint is broken > -- > > Key: HBASE-17582 > URL: https://issues.apache.org/jira/browse/HBASE-17582 > Project: HBase > Issue Type: Bug > Components: Compaction, io >Affects Versions: 2.0.0 >Reporter: Ashu Pachauri >Assignee: Appy >Priority: Critical > Fix For: 2.0.0 > > Attachments: HBASE-17582.master.001.patch, > HBASE-17582.master.002.patch > > > We pass a boolean for pass page cache drop hint while creating store file > scanners and writers. > The hint is not passed on down the stack by StoreFileWriter and > StoreFileScanner in the master branch. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (HBASE-17753) Update QuotaObserverChore to include computed snapshot sizes
[ https://issues.apache.org/jira/browse/HBASE-17753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser reassigned HBASE-17753: -- Assignee: Josh Elser > Update QuotaObserverChore to include computed snapshot sizes > > > Key: HBASE-17753 > URL: https://issues.apache.org/jira/browse/HBASE-17753 > Project: HBase > Issue Type: Sub-task >Reporter: Josh Elser >Assignee: Josh Elser > > Need to update QuotaObserverChore to include the new snapshot size > computations that were implemented in HBASE-17749 so that the quota > utilizations are accurate. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17070) backport HBASE-17020 to 1.3.1
[ https://issues.apache.org/jira/browse/HBASE-17070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yu Li updated HBASE-17070: -- Attachment: HBASE-17070.branch-1.3.patch > backport HBASE-17020 to 1.3.1 > - > > Key: HBASE-17070 > URL: https://issues.apache.org/jira/browse/HBASE-17070 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.0 >Reporter: Yu Li >Assignee: Yu Li > Fix For: 1.3.1 > > Attachments: HBASE-17070.branch-1.3.patch, > HBASE-17070.branch-1.3.patch, HBASE-17070.branch-1.3.patch > > > As titled, backport HBASE-17020 after 1.3.0 got released. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17060) backport HBASE-16570 to 1.3.1
[ https://issues.apache.org/jira/browse/HBASE-17060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933735#comment-15933735 ] Yu Li commented on HBASE-17060: --- The failure of TestMultiTableSnapshotInputFormat is tracked by HBASE-17813. And failure of TestAcidGuarantees is tracked by HBASE-16075 So should be no blocking issue here, will commit soon if no objections. > backport HBASE-16570 to 1.3.1 > - > > Key: HBASE-17060 > URL: https://issues.apache.org/jira/browse/HBASE-17060 > Project: HBase > Issue Type: Sub-task >Affects Versions: 1.3.0 >Reporter: Yu Li >Assignee: binlijin > Fix For: 1.3.1 > > Attachments: HBASE-17060.branch-1.3.v1.patch, > HBASE-17060.branch-1.3.v1.patch, HBASE-17060.branch-1.3.v1.patch > > > Need some backport after 1.3.0 got released -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17059) backport HBASE-17039 to 1.3.1
[
https://issues.apache.org/jira/browse/HBASE-17059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933727#comment-15933727
]
Yu Li commented on HBASE-17059:
---
Checking the report, we could see {{TestMultiTableSnapshotInputFormat}} failed
complaining about "Unable to create region directory", which is resolved by
HBASE-16983 and just created HBASE-17813 to do the backport.
So should be no issue blocking us here (a direct cherry-pick from branch-1
where the patch was carefully reviewed, and no UT issue). Plan to commit this
soon if no objections.
> backport HBASE-17039 to 1.3.1
> -
>
> Key: HBASE-17059
> URL: https://issues.apache.org/jira/browse/HBASE-17059
> Project: HBase
> Issue Type: Bug
> Components: Balancer
>Affects Versions: 1.3.0
>Reporter: Yu Li
>Assignee: Yu Li
> Fix For: 1.3.1
>
> Attachments: HBASE-17059.branch-1.3.patch,
> HBASE-17059.branch-1.3.patch
>
>
> Currently branch-1.3 codes are freezing for 1.3.0 release, need to backport
> HBASE-17039 to 1.3.1 afterwards.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-17127) Locate region should fail fast if underlying Connection already closed
[
https://issues.apache.org/jira/browse/HBASE-17127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933712#comment-15933712
]
Hudson commented on HBASE-17127:
SUCCESS: Integrated in Jenkins build HBase-1.3-IT #10 (See
[https://builds.apache.org/job/HBase-1.3-IT/10/])
HBASE-17175 backport HBASE-17127 (Locate region should fail fast if (liyu: rev
98b5d2cd4b0badef5f576cb35c8c8f1df1c88899)
* (edit)
hbase-client/src/test/java/org/apache/hadoop/hbase/client/TestClientNoCluster.java
* (edit)
hbase-client/src/main/java/org/apache/hadoop/hbase/client/ConnectionManager.java
> Locate region should fail fast if underlying Connection already closed
> --
>
> Key: HBASE-17127
> URL: https://issues.apache.org/jira/browse/HBASE-17127
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.1.7, 1.2.4
>Reporter: Yu Li
>Assignee: Yu Li
> Fix For: 2.0.0, 1.4.0, 1.2.5, 0.98.24, 1.1.8
>
> Attachments: HBASE-17127.patch
>
>
> Currently if try to locate region when underlying connection is closed, we
> will retry and wait at least 10s for each round until exhausted (refer to the
> catch clause of {{RpcRetryingCallerImpl#callWithRetries}} and
> {{RegionServerCallable#sleep}} for more details), which is unnecessary and
> time-costing.
> The issue is caused by user incorrectly manipulating connection, which shows
> the disadvantage of force user to handle connection life cycle and proves the
> necessity to support auto-managed connection as we did before, as indicated
> in HBASE-17009
> In this JIRA we will make it fail fast in the above case.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-17175) backport HBASE-17127 to 1.3.1
[ https://issues.apache.org/jira/browse/HBASE-17175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933711#comment-15933711 ] Hudson commented on HBASE-17175: SUCCESS: Integrated in Jenkins build HBase-1.3-IT #10 (See [https://builds.apache.org/job/HBase-1.3-IT/10/]) HBASE-17175 backport HBASE-17127 (Locate region should fail fast if (liyu: rev 98b5d2cd4b0badef5f576cb35c8c8f1df1c88899) * (edit) hbase-client/src/test/java/org/apache/hadoop/hbase/client/TestClientNoCluster.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/ConnectionManager.java > backport HBASE-17127 to 1.3.1 > - > > Key: HBASE-17175 > URL: https://issues.apache.org/jira/browse/HBASE-17175 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.0 >Reporter: Yu Li >Assignee: Yu Li > Fix For: 1.3.1 > > Attachments: HBASE-17175.branch-1.3.patch > > > branch-1.3 is currently freeze for 1.3.0 release, need to backport > HBASE-17127 later -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17813) backport HBASE-16983 to branch-1.3
[ https://issues.apache.org/jira/browse/HBASE-17813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yu Li updated HBASE-17813: -- Labels: unit-test (was: ) Fix Version/s: 1.3.1 Affects Version/s: 1.3.0 Status: Patch Available (was: Open) Submit for HadoopQA. [~mantonov] I guess this one is ok to go into 1.3.1 since simply some UT fixes? Please let me know if any objection, thanks. > backport HBASE-16983 to branch-1.3 > -- > > Key: HBASE-17813 > URL: https://issues.apache.org/jira/browse/HBASE-17813 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.0 >Reporter: Yu Li >Assignee: Yu Li > Labels: unit-test > Fix For: 1.3.1 > > Attachments: HBASE-17813.branch-1.3.patch > > > From [recent UT > report|https://builds.apache.org/job/PreCommit-HBASE-Build/6170/testReport/] > of branch-1.3, we could see the same issue "Unable to create region > directory..." as described by HBASE-16983, so we should backport the JIRA to > fix this intermittent failure and avoid it blocking new commits. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17813) backport HBASE-16983 to branch-1.3
[ https://issues.apache.org/jira/browse/HBASE-17813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yu Li updated HBASE-17813: -- Attachment: HBASE-17813.branch-1.3.patch Uploading the initial patch, which is a squash of two direct-cherry-picked commits from branch-1 (SHA: b3ddea9fc4 and a70f73c1e1) > backport HBASE-16983 to branch-1.3 > -- > > Key: HBASE-17813 > URL: https://issues.apache.org/jira/browse/HBASE-17813 > Project: HBase > Issue Type: Bug >Reporter: Yu Li >Assignee: Yu Li > Attachments: HBASE-17813.branch-1.3.patch > > > From [recent UT > report|https://builds.apache.org/job/PreCommit-HBASE-Build/6170/testReport/] > of branch-1.3, we could see the same issue "Unable to create region > directory..." as described by HBASE-16983, so we should backport the JIRA to > fix this intermittent failure and avoid it blocking new commits. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (HBASE-17800) [C++] handle exceptions in client RPC
[ https://issues.apache.org/jira/browse/HBASE-17800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933697#comment-15933697 ] Xiaobing Zhou edited comment on HBASE-17800 at 3/20/17 10:16 PM: - posted v0 patch. It basically defines RemoteException and its subclass DoNotRetryIOException to map ExceptionResponse in proto. RemoteException is wrapped in hbase::Response. In the pipeline, ClientDispatcher::read will return Future with either hbase::Response or std::exception (RemoteException as its subclass). The std::exception will be propagated up to RPCConnection and AsyncSingleRequestRpcRetryingCaller where the retry handlers are triggered. was (Author: xiaobingo): posted v0 patch. > [C++] handle exceptions in client RPC > - > > Key: HBASE-17800 > URL: https://issues.apache.org/jira/browse/HBASE-17800 > Project: HBase > Issue Type: Sub-task >Reporter: Xiaobing Zhou >Assignee: Xiaobing Zhou > Attachments: HBASE-17800-HBASE-14850.000.patch > > > Exceptions are ignored in current client RPC. They should be handled properly > to be consumed by RPC retry or propagated up to APIs. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (HBASE-17813) backport HBASE-16983 to branch-1.3
Yu Li created HBASE-17813: - Summary: backport HBASE-16983 to branch-1.3 Key: HBASE-17813 URL: https://issues.apache.org/jira/browse/HBASE-17813 Project: HBase Issue Type: Bug Reporter: Yu Li Assignee: Yu Li >From [recent UT >report|https://builds.apache.org/job/PreCommit-HBASE-Build/6170/testReport/] >of branch-1.3, we could see the same issue "Unable to create region >directory..." as described by HBASE-16983, so we should backport the JIRA to >fix this intermittent failure and avoid it blocking new commits. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17800) [C++] handle exceptions in client RPC
[ https://issues.apache.org/jira/browse/HBASE-17800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaobing Zhou updated HBASE-17800: -- Attachment: HBASE-17800-HBASE-14850.000.patch posted v0 patch. > [C++] handle exceptions in client RPC > - > > Key: HBASE-17800 > URL: https://issues.apache.org/jira/browse/HBASE-17800 > Project: HBase > Issue Type: Sub-task >Reporter: Xiaobing Zhou >Assignee: Xiaobing Zhou > Attachments: HBASE-17800-HBASE-14850.000.patch > > > Exceptions are ignored in current client RPC. They should be handled properly > to be consumed by RPC retry or propagated up to APIs. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17175) backport HBASE-17127 to 1.3.1
[ https://issues.apache.org/jira/browse/HBASE-17175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yu Li updated HBASE-17175: -- Resolution: Fixed Status: Resolved (was: Patch Available) Pushed to branch-1.3, closing issue. > backport HBASE-17127 to 1.3.1 > - > > Key: HBASE-17175 > URL: https://issues.apache.org/jira/browse/HBASE-17175 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.0 >Reporter: Yu Li >Assignee: Yu Li > Fix For: 1.3.1 > > Attachments: HBASE-17175.branch-1.3.patch > > > branch-1.3 is currently freeze for 1.3.0 release, need to backport > HBASE-17127 later -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17576) [C++] Implement request retry mechanism over RPC for Multi calls.
[
https://issues.apache.org/jira/browse/HBASE-17576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933661#comment-15933661
]
Enis Soztutar commented on HBASE-17576:
---
- You should not stop the cpu executor when Batch caller is destructed. Cpu
executor is owned by a higher level (client), so the client is responsible for
stopping that.
{code}
+ ~AsyncBatchRpcRetryingCaller() { cpu_executor->stop(); }
{code}
- Probably need to rebase, and bring the code in-line with the most recent
version of the AsyncRpcRetryingCallerFactory. Get rid of the {{CONN }} template
and use {{AsyncConnection}}, and also change the names and fields to be inline
with the Single caller ( {{pause}}, {{set_pause()}}, etc).
- The answer is yes to below, you can optionally obtain it from the rpc client
or AsyncConnection.
{code}
// TODO we need to have this as a constructor parameter
{code}
- I think you can return the vector by value here since you are creating it in
this method. Or return the existing field by const &.
{code}
+ std::unique_ptr Call() {
{code}
- [~xiaobingo] the rettry wheel timer should be obtained from the higher level.
In this patch and in the Single caller patch, it is created in the callers. How
come it does not cause segfault when we are trying to do the retry in the
timers? We should fix this in a different issue.
- {{LocationCache::LocateRegion}} already returns a Future, why do you need to
call {{folly::makeFuture}} below?
{code}
+ locs.push_back(folly::makeFutureWith([&] {
+return location_cache_->LocateRegion(*table_name_,
action->action()->row()).get();
{code}
- Do not iterate over the servers list like this, since you already have a map
from server to actions:
{code}
+ for (auto itr = actions_by_server.begin(); itr !=
actions_by_server.end(); ++itr) {
+if (region_loc->server_name().host_name() ==
itr->first->host_name()) {
{code}
Probably, we would want to use ServerName as the equals-comparison, not the
hostname. We need all three of hostname, port and startcode for the comparison.
- This seems correct, thanks for changing:
{code}
+folly::collectAll(locs)
+.then([this, tries, , _by_server,
{code}
- No action is added to the locate_failed map. When the location lookup Future
completes with an exception, you want to add it to the list so that the second
then() action to the uber-Future will send the retries. Do not worry too much
about handling the DonotRetryException yet. That will come in [~xiaobingo]'s
patch for HBASE-17800. In the other case (where it is not a do not retry
exception), you should not call FailOne, but instead add the action to the
location_failed list.
- If you look at FailAll, it calls FailOne with each item in the list. You
should not create a Promise here, the promise should have already been created
elsewhere:
{code}
+ // TODO
+ PromiseResult promise;
{code}
You can just do the same thing that FailAll calls FailOne so that we do not
duplicate logic.
- I've noticed that in a couple of places you are using {{std::for_each()}} for
iterating over the maps or lists, like we do in the java code. The thing is
that using Java-8 lambdas, the code is much more compact and understandable.
However, C++ lambdas are very explicit and (IMO) not very readable. You do not
have to follow the Java code whenever it does not make sense. Just iterate over
the maps / lists the usual way instead of using for_each and sending a closure
with tons of local capture and argument list.
> [C++] Implement request retry mechanism over RPC for Multi calls.
> -
>
> Key: HBASE-17576
> URL: https://issues.apache.org/jira/browse/HBASE-17576
> Project: HBase
> Issue Type: Sub-task
>Reporter: Sudeep Sunthankar
>Assignee: Sudeep Sunthankar
> Attachments: HBASE-17576.HBASE-14850.v1.patch,
> HBASE-17576.HBASE-14850.v2.patch, HBASE-17576.HBASE-14850.v3.patch,
> HBASE-17576.HBASE-14850.v4.patch, HBASE-17576.HBASE-14850.v5.patch,
> HBASE-17576.HBASE-14850.v6.patch
>
>
> This work is based on top of HBASE-17465. Multi Calls will be based on this.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (HBASE-17811) TestThriftHttpServer.testRunThriftServerWithHeaderBufferLength is broken in "branch-1"
[ https://issues.apache.org/jira/browse/HBASE-17811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser resolved HBASE-17811. Resolution: Invalid > TestThriftHttpServer.testRunThriftServerWithHeaderBufferLength is broken in > "branch-1" > -- > > Key: HBASE-17811 > URL: https://issues.apache.org/jira/browse/HBASE-17811 > Project: HBase > Issue Type: Bug > Components: Thrift >Affects Versions: 2.0.0 > Environment: OS: Ubuntu 14.04 > Arch:x86_64 >Reporter: Anup Halarnkar > Fix For: 2.0.0 > > > Module Thrift fails with this output: > Results : > Failed tests: > TestThriftHttpServer.testRunThriftServerWithHeaderBufferLength > Expected: (an instance of org.apache.thrift.transport.TTransportException and > exception with message a string containing "HTTP Response code: 413") > but: exception with message a string containing "HTTP Response code: > 413" message was "java.net.ConnectException: Connection refused (Connection > refused)" > Stacktrace was: org.apache.thrift.transport.TTransportException: > java.net.ConnectException: Connection refused (Connection refused) > at org.apache.thrift.transport.THttpClient.flush(THttpClient.java:356) > at org.apache.thrift.TServiceClient.sendBase(TServiceClient.java:73) > at org.apache.thrift.TServiceClient.sendBase(TServiceClient.java:62) > at > org.apache.hadoop.hbase.thrift.generated.Hbase$Client.send_getTableNames(Hbase.java:901) > at > org.apache.hadoop.hbase.thrift.generated.Hbase$Client.getTableNames(Hbase.java:894) > at > org.apache.hadoop.hbase.thrift.TestThriftServer.checkTableList(TestThriftServer.java:248) > at > org.apache.hadoop.hbase.thrift.TestThriftHttpServer.talkToThriftServer(TestThriftHttpServer.java:187) > at > org.apache.hadoop.hbase.thrift.TestThriftHttpServer.runThriftServer(TestThriftHttpServer.java:147) > at > org.apache.hadoop.hbase.thrift.TestThriftHttpServer.testRunThriftServerWithHeaderBufferLength(TestThriftHttpServer.java:121) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at > org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:298) > at > org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:292) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.net.ConnectException: Connection refused (Connection refused) > at java.net.PlainSocketImpl.socketConnect(Native Method) > at > java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) > at > java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) > at > java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) > at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) > at java.net.Socket.connect(Socket.java:589) > at java.net.Socket.connect(Socket.java:538) > at sun.net.NetworkClient.doConnect(NetworkClient.java:180) > at sun.net.www.http.HttpClient.openServer(HttpClient.java:432) > at sun.net.www.http.HttpClient.openServer(HttpClient.java:527) > at sun.net.www.http.HttpClient.(HttpClient.java:211) > at sun.net.www.http.HttpClient.New(HttpClient.java:308) > at sun.net.www.http.HttpClient.New(HttpClient.java:326) > at > sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1202) > at > sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1138) > at > sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:1032) > at > sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:966) > at org.apache.thrift.transport.THttpClient.flush(THttpClient.java:344) > ... 20 more > Tests run: 88, Failures: 1, Errors: 0, Skipped: 0 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17811) TestThriftHttpServer.testRunThriftServerWithHeaderBufferLength is broken in "branch-1"
[ https://issues.apache.org/jira/browse/HBASE-17811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933626#comment-15933626 ] Josh Elser commented on HBASE-17811: [~anuphal] this passes locally on branch-1 for me. Looks like your local networking isn't set up properly? This test is also passing on Jenkins: https://builds.apache.org/job/HBase-1.4/ I'm going to close this as Invalid. Please feel free to re-open if you think this is a test issue and you can provide more context as to the problem. > TestThriftHttpServer.testRunThriftServerWithHeaderBufferLength is broken in > "branch-1" > -- > > Key: HBASE-17811 > URL: https://issues.apache.org/jira/browse/HBASE-17811 > Project: HBase > Issue Type: Bug > Components: Thrift >Affects Versions: 2.0.0 > Environment: OS: Ubuntu 14.04 > Arch:x86_64 >Reporter: Anup Halarnkar > Fix For: 2.0.0 > > > Module Thrift fails with this output: > Results : > Failed tests: > TestThriftHttpServer.testRunThriftServerWithHeaderBufferLength > Expected: (an instance of org.apache.thrift.transport.TTransportException and > exception with message a string containing "HTTP Response code: 413") > but: exception with message a string containing "HTTP Response code: > 413" message was "java.net.ConnectException: Connection refused (Connection > refused)" > Stacktrace was: org.apache.thrift.transport.TTransportException: > java.net.ConnectException: Connection refused (Connection refused) > at org.apache.thrift.transport.THttpClient.flush(THttpClient.java:356) > at org.apache.thrift.TServiceClient.sendBase(TServiceClient.java:73) > at org.apache.thrift.TServiceClient.sendBase(TServiceClient.java:62) > at > org.apache.hadoop.hbase.thrift.generated.Hbase$Client.send_getTableNames(Hbase.java:901) > at > org.apache.hadoop.hbase.thrift.generated.Hbase$Client.getTableNames(Hbase.java:894) > at > org.apache.hadoop.hbase.thrift.TestThriftServer.checkTableList(TestThriftServer.java:248) > at > org.apache.hadoop.hbase.thrift.TestThriftHttpServer.talkToThriftServer(TestThriftHttpServer.java:187) > at > org.apache.hadoop.hbase.thrift.TestThriftHttpServer.runThriftServer(TestThriftHttpServer.java:147) > at > org.apache.hadoop.hbase.thrift.TestThriftHttpServer.testRunThriftServerWithHeaderBufferLength(TestThriftHttpServer.java:121) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at > org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:298) > at > org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:292) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.net.ConnectException: Connection refused (Connection refused) > at java.net.PlainSocketImpl.socketConnect(Native Method) > at > java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) > at > java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) > at > java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) > at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) > at java.net.Socket.connect(Socket.java:589) > at java.net.Socket.connect(Socket.java:538) > at sun.net.NetworkClient.doConnect(NetworkClient.java:180) > at sun.net.www.http.HttpClient.openServer(HttpClient.java:432) > at sun.net.www.http.HttpClient.openServer(HttpClient.java:527) > at sun.net.www.http.HttpClient.(HttpClient.java:211) > at sun.net.www.http.HttpClient.New(HttpClient.java:308) > at sun.net.www.http.HttpClient.New(HttpClient.java:326) > at > sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1202) > at > sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1138) > at >
[jira] [Commented] (HBASE-17749) Create Master Chore to compute the size of each Snapshot against a table with a quota
[
https://issues.apache.org/jira/browse/HBASE-17749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933608#comment-15933608
]
Hadoop QA commented on HBASE-17749:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 17s
{color} | {color:blue} Docker mode activated. {color} |
| {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 5 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 1m 53s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
51s {color} | {color:green} HBASE-16961 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 13s
{color} | {color:green} HBASE-16961 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
32s {color} | {color:green} HBASE-16961 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
56s {color} | {color:green} HBASE-16961 passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
59s {color} | {color:green} HBASE-16961 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 5s
{color} | {color:green} HBASE-16961 passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 10s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 0m 9s
{color} | {color:red} hbase-hadoop2-compat in the patch failed. {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m 10s
{color} | {color:red} hbase-hadoop2-compat in the patch failed. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 10s {color}
| {color:red} hbase-hadoop2-compat in the patch failed. {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
29s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
41s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m 0s
{color} | {color:red} The patch has 2 line(s) that end in whitespace. Use git
apply --whitespace=fix. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 0m 50s
{color} | {color:red} The patch causes 14 errors with Hadoop v2.4.0. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 1m 40s
{color} | {color:red} The patch causes 14 errors with Hadoop v2.4.1. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 2m 29s
{color} | {color:red} The patch causes 14 errors with Hadoop v2.5.0. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 3m 18s
{color} | {color:red} The patch causes 14 errors with Hadoop v2.5.1. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 4m 9s
{color} | {color:red} The patch causes 14 errors with Hadoop v2.5.2. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 5m 2s
{color} | {color:red} The patch causes 14 errors with Hadoop v2.6.1. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 5m 52s
{color} | {color:red} The patch causes 14 errors with Hadoop v2.6.2. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 6m 42s
{color} | {color:red} The patch causes 14 errors with Hadoop v2.6.3. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 7m 34s
{color} | {color:red} The patch causes 14 errors with Hadoop v2.6.4. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 8m 24s
{color} | {color:red} The patch causes 14 errors with Hadoop v2.6.5. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 9m 16s
{color} | {color:red} The patch causes 14 errors with Hadoop v2.7.1. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 10m 5s
{color} | {color:red} The patch causes 14 errors with Hadoop v2.7.2. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 10m 55s
{color} | {color:red} The patch causes 14 errors with Hadoop
[jira] [Updated] (HBASE-17447) Automatically delete quota when table is deleted
[ https://issues.apache.org/jira/browse/HBASE-17447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated HBASE-17447: --- Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Thanks again for the review, Ted. > Automatically delete quota when table is deleted > > > Key: HBASE-17447 > URL: https://issues.apache.org/jira/browse/HBASE-17447 > Project: HBase > Issue Type: Sub-task >Reporter: Josh Elser >Assignee: Josh Elser > Fix For: HBASE-16961 > > Attachments: HBASE-17447.001.HBASE-16961.patch, > HBASE-17447.002.HBASE-16961.patch > > > If a table has a space quota defined on it, we can delete that quota when the > table is deleted. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17447) Automatically delete quota when table is deleted
[ https://issues.apache.org/jira/browse/HBASE-17447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933548#comment-15933548 ] Josh Elser commented on HBASE-17447: bq. For MasterSpaceQuotaObserver, add annotation for audience. Bah, some day I'll remember to do this. Will fix up on the commit. > Automatically delete quota when table is deleted > > > Key: HBASE-17447 > URL: https://issues.apache.org/jira/browse/HBASE-17447 > Project: HBase > Issue Type: Sub-task >Reporter: Josh Elser >Assignee: Josh Elser > Fix For: HBASE-16961 > > Attachments: HBASE-17447.001.HBASE-16961.patch, > HBASE-17447.002.HBASE-16961.patch > > > If a table has a space quota defined on it, we can delete that quota when the > table is deleted. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-16417) In-Memory MemStore Policy for Flattening and Compactions
[ https://issues.apache.org/jira/browse/HBASE-16417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933509#comment-15933509 ] Edward Bortnikov commented on HBASE-16417: -- Okay agreed - BASIC will include merge. We'll update the docs, too. Regarding parallelism - a promising direction, but we should be careful here. More threads might come at someone else's expense (write throughput maybe), so need more scrutiny. If all we do is run a bunch of binary searches in parallel - might not be worth the synchronization. Worth checking. > In-Memory MemStore Policy for Flattening and Compactions > > > Key: HBASE-16417 > URL: https://issues.apache.org/jira/browse/HBASE-16417 > Project: HBase > Issue Type: Sub-task >Reporter: Anastasia Braginsky >Assignee: Eshcar Hillel > Fix For: 2.0.0 > > Attachments: HBASE-16417-benchmarkresults-20161101.pdf, > HBASE-16417-benchmarkresults-20161110.pdf, > HBASE-16417-benchmarkresults-20161123.pdf, > HBASE-16417-benchmarkresults-20161205.pdf, > HBASE-16417-benchmarkresults-20170309.pdf, > HBASE-16417-benchmarkresults-20170317.pdf > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17809) cleanup unused class
[ https://issues.apache.org/jira/browse/HBASE-17809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933470#comment-15933470 ] stack commented on HBASE-17809: --- +1 on sentiment. Not sure why the test failures? > cleanup unused class > > > Key: HBASE-17809 > URL: https://issues.apache.org/jira/browse/HBASE-17809 > Project: HBase > Issue Type: Sub-task >Affects Versions: 2.0.0 >Reporter: Chia-Ping Tsai >Assignee: Chia-Ping Tsai > Fix For: 2.0.0 > > Attachments: HBASE-17809.v0.patch > > > inspired by HBASE-17805. We had left a lot of orphan class due to a bunch of > commits. We shall remove them. > ||class||last meeting||why||line count| > |LruHashMap|HBASE-1822|get rid of|1100| > |ScannerTimeoutException|HBASE-16266|get rid of|45| > |SortedCopyOnWriteSet|HBASE-12748|get rid of|178| > |TestSortedCopyOnWriteSet|HBASE-12748|get rid of|107| > |DelegatingRetryingCallable|HBASE-9049|create but never used|65| > |LockTimeoutException|HBASE-16786|get rid of|44| > |OperationConflictException|HBASE-9899|get rid of|50| > |InvalidQuotaSettingsException|HBASE-11598|create but never used|33| > |ShareableMemory|HBASE-15735|get rid of|40| > |BoundedArrayQueue|HBASE-14860|get rid of|82| > |TestBoundedArrayQueue|HBASE-14860|get rid of|61| > |ChecksumFactory|HBASE-11927|get rid of|100| > |TokenDepthComparator|HBASE-4676|create but never used|65| > |RegionMergeTransaction|HBASE-17470|get rid of|249| > |MetaUtils|HBASE-1822|get rid of|156| -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17806) TestRSGroups#testMoveServersAndTables is flaky in master branch
[
https://issues.apache.org/jira/browse/HBASE-17806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933411#comment-15933411
]
Hudson commented on HBASE-17806:
FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #2708 (See
[https://builds.apache.org/job/HBase-Trunk_matrix/2708/])
HBASE-17806 TestRSGroups#testMoveServersAndTables is flaky in master (tedyu:
rev 4088f822a449acc39c2408a287f820ec26acabf4)
* (edit)
hbase-common/src/main/java/org/apache/hadoop/hbase/rsgroup/RSGroupInfo.java
* (edit)
hbase-rsgroup/src/test/java/org/apache/hadoop/hbase/rsgroup/TestRSGroupsBase.java
> TestRSGroups#testMoveServersAndTables is flaky in master branch
> ---
>
> Key: HBASE-17806
> URL: https://issues.apache.org/jira/browse/HBASE-17806
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
>Assignee: Guangxu Cheng
> Fix For: 2.0
>
> Attachments: HBASE-17806-v1.patch
>
>
> According to https://builds.apache.org/job/HBASE-Flaky-Tests ,
> TestRSGroups#testMoveServersAndTables is the top flaky test.
> Recent test failure:
> https://builds.apache.org/job/HBASE-Flaky-Tests/14062/testReport/junit/org.apache.hadoop.hbase.rsgroup/TestRSGroups/testMoveServersAndTables/
> {code}
> java.lang.AssertionError: expected:<4> but was:<5>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at
> org.apache.hadoop.hbase.rsgroup.TestRSGroupsBase.testMoveServersAndTables(TestRSGroupsBase.java:747)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-17809) cleanup unused class
[
https://issues.apache.org/jira/browse/HBASE-17809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933399#comment-15933399
]
Hadoop QA commented on HBASE-17809:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 18s
{color} | {color:blue} Docker mode activated. {color} |
| {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 5 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 1m 18s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
31s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 4m 36s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
54s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 2m
29s {color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m 0s
{color} | {color:blue} Skipped patched modules with no Java source: . {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 0m 22s
{color} | {color:red} hbase-prefix-tree in master has 1 extant Findbugs
warnings. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m 56s
{color} | {color:green} master passed {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} 4m
44s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 4m 32s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 4m 32s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
48s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 2m
8s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m 1s
{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
30m 17s {color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha2. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m 0s
{color} | {color:blue} Skipped patched modules with no Java source: . {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
12s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m 13s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 47s
{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m 14s
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 20s
{color} | {color:green} hbase-prefix-tree in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 121m 55s
{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 113m 4s {color}
| {color:red} root in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 1m
4s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 316m 37s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.regionserver.TestRegionReplicaFailover |
| | hadoop.hbase.regionserver.TestRegionReplicaFailover |
[jira] [Commented] (HBASE-17447) Automatically delete quota when table is deleted
[ https://issues.apache.org/jira/browse/HBASE-17447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933391#comment-15933391 ] Ted Yu commented on HBASE-17447: lgtm For MasterSpaceQuotaObserver, add annotation for audience. > Automatically delete quota when table is deleted > > > Key: HBASE-17447 > URL: https://issues.apache.org/jira/browse/HBASE-17447 > Project: HBase > Issue Type: Sub-task >Reporter: Josh Elser >Assignee: Josh Elser > Fix For: HBASE-16961 > > Attachments: HBASE-17447.001.HBASE-16961.patch, > HBASE-17447.002.HBASE-16961.patch > > > If a table has a space quota defined on it, we can delete that quota when the > table is deleted. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17060) backport HBASE-16570 to 1.3.1
[
https://issues.apache.org/jira/browse/HBASE-17060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933363#comment-15933363
]
Hadoop QA commented on HBASE-17060:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 22s
{color} | {color:blue} Docker mode activated. {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} 7m
4s {color} | {color:green} branch-1.3 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 31s
{color} | {color:green} branch-1.3 passed with JDK v1.8.0_121 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 33s
{color} | {color:green} branch-1.3 passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
6s {color} | {color:green} branch-1.3 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
21s {color} | {color:green} branch-1.3 passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
51s {color} | {color:green} branch-1.3 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 32s
{color} | {color:green} branch-1.3 passed with JDK v1.8.0_121 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 33s
{color} | {color:green} branch-1.3 passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
45s {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.8.0_121 {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} compile {color} | {color:green} 0m 34s
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 34s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
55s {color} | {color:green} the patch passed {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} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
15m 52s {color} | {color:green} The 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} hbaseprotoc {color} | {color:green} 0m
15s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m 3s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 25s
{color} | {color:green} the patch passed with JDK v1.8.0_121 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 33s
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 79m 20s {color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
25s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 115m 23s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.TestAcidGuarantees |
| | hadoop.hbase.mapreduce.TestMultiTableSnapshotInputFormat |
| | hadoop.hbase.mapred.TestMultiTableSnapshotInputFormat |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.11.2 Server=1.11.2 Image:yetus/hbase:66fbe99 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12859598/HBASE-17060.branch-1.3.v1.patch
|
| JIRA Issue | HBASE-17060 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux 8c004f11a657 3.13.0-103-generic #150-Ubuntu SMP Thu Nov 24
10:34:17 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
|
[jira] [Commented] (HBASE-17059) backport HBASE-17039 to 1.3.1
[
https://issues.apache.org/jira/browse/HBASE-17059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933357#comment-15933357
]
Hadoop QA commented on HBASE-17059:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 21s
{color} | {color:blue} Docker mode activated. {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} 2m
19s {color} | {color:green} branch-1.3 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 38s
{color} | {color:green} branch-1.3 passed with JDK v1.8.0_121 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 38s
{color} | {color:green} branch-1.3 passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
58s {color} | {color:green} branch-1.3 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
17s {color} | {color:green} branch-1.3 passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m 3s
{color} | {color:green} branch-1.3 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 28s
{color} | {color:green} branch-1.3 passed with JDK v1.8.0_121 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 32s
{color} | {color:green} branch-1.3 passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
49s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 34s
{color} | {color:green} the patch passed with JDK v1.8.0_121 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 34s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 37s
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 37s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
56s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
17s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
16m 10s {color} | {color:green} The 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} hbaseprotoc {color} | {color:green} 0m
15s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m 6s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 25s
{color} | {color:green} the patch passed with JDK v1.8.0_121 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 33s
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 78m 2s {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} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 109m 45s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.mapreduce.TestMultiTableSnapshotInputFormat
|
| | hadoop.hbase.mapred.TestMultiTableSnapshotInputFormat |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:66fbe99 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12859597/HBASE-17059.branch-1.3.patch
|
| JIRA Issue | HBASE-17059 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux 7d58fbdd74e7 3.13.0-106-generic #153-Ubuntu SMP Tue
[jira] [Commented] (HBASE-17749) Create Master Chore to compute the size of each Snapshot against a table with a quota
[ https://issues.apache.org/jira/browse/HBASE-17749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933344#comment-15933344 ] Josh Elser commented on HBASE-17749: Will trigger HadoopQA, but not intending to land on HBASE-16961 (hoping to start merge there). Will cut another branch for this phase 2 work. > Create Master Chore to compute the size of each Snapshot against a table with > a quota > - > > Key: HBASE-17749 > URL: https://issues.apache.org/jira/browse/HBASE-17749 > Project: HBase > Issue Type: Sub-task >Reporter: Josh Elser >Assignee: Josh Elser > Attachments: HBASE-17749.001.HBASE-16961.patch > > > See design doc in the umbrella (HBASE-17748) as to how the size of a snapshot > is defined. > For each table that has a quota (either set directly or "inherited" from its > namespace), we need to compute the size of that snapshot. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17749) Create Master Chore to compute the size of each Snapshot against a table with a quota
[ https://issues.apache.org/jira/browse/HBASE-17749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated HBASE-17749: --- Status: Patch Available (was: Open) > Create Master Chore to compute the size of each Snapshot against a table with > a quota > - > > Key: HBASE-17749 > URL: https://issues.apache.org/jira/browse/HBASE-17749 > Project: HBase > Issue Type: Sub-task >Reporter: Josh Elser >Assignee: Josh Elser > Attachments: HBASE-17749.001.HBASE-16961.patch > > > See design doc in the umbrella (HBASE-17748) as to how the size of a snapshot > is defined. > For each table that has a quota (either set directly or "inherited" from its > namespace), we need to compute the size of that snapshot. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17749) Create Master Chore to compute the size of each Snapshot against a table with a quota
[ https://issues.apache.org/jira/browse/HBASE-17749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated HBASE-17749: --- Attachment: HBASE-17749.001.HBASE-16961.patch .001 A first-stab a chore to periodically compute the size of each snapshot relative to the tables. > Create Master Chore to compute the size of each Snapshot against a table with > a quota > - > > Key: HBASE-17749 > URL: https://issues.apache.org/jira/browse/HBASE-17749 > Project: HBase > Issue Type: Sub-task >Reporter: Josh Elser >Assignee: Josh Elser > Attachments: HBASE-17749.001.HBASE-16961.patch > > > See design doc in the umbrella (HBASE-17748) as to how the size of a snapshot > is defined. > For each table that has a quota (either set directly or "inherited" from its > namespace), we need to compute the size of that snapshot. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17003) Update book for filesystem use quotas
[ https://issues.apache.org/jira/browse/HBASE-17003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated HBASE-17003: --- Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Pushed to the feature branch. Thanks for the review, Ted! > Update book for filesystem use quotas > - > > Key: HBASE-17003 > URL: https://issues.apache.org/jira/browse/HBASE-17003 > Project: HBase > Issue Type: Sub-task > Components: documentation >Reporter: Josh Elser >Assignee: Josh Elser > Fix For: HBASE-16961 > > Attachments: book.html, HBASE-17003.001.HBASE-16961.patch, > HBASE-17003.002.HBASE-16961.patch > > > Need to make sure that the book's section on quotas reflect the final > implementation of the filesystem-use quota support. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17794) Remove lingering "violation" in favor of the accurate "snapshot"
[ https://issues.apache.org/jira/browse/HBASE-17794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated HBASE-17794: --- Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Pushed to the feature branch. Thanks, Ted! > Remove lingering "violation" in favor of the accurate "snapshot" > > > Key: HBASE-17794 > URL: https://issues.apache.org/jira/browse/HBASE-17794 > Project: HBase > Issue Type: Sub-task >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Trivial > Fix For: HBASE-16961 > > Attachments: HBASE-17794.001.HBASE-16961.patch > > > Previously, quota violations used to be stored in the quota table. > Eventually, I realized that I needed to actually persist the utilization of > each table/NS, not just the violation state. > I know there are cases in the code where "violation" is incorrectly > describing things (it should be "snapshot"). Clean these up for clarity. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-14417) Incremental backup and bulk loading
[ https://issues.apache.org/jira/browse/HBASE-14417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-14417: --- Description: Currently, incremental backup is based on WAL files. Bulk data loading bypasses WALs for obvious reasons, breaking incremental backups. The only way to continue backups after bulk loading is to create new full backup of a table. This may not be feasible for customers who do bulk loading regularly (say, every day). Here is the review board (out of date): https://reviews.apache.org/r/54258/ In order not to miss the hfiles which are loaded into region directories in a situation where postBulkLoadHFile() hook is not called (bulk load being interrupted), we record hfile names thru preCommitStoreFile() hook. At time of incremental backup, we check the presence of such hfiles. If they are present, they become part of the incremental backup image. Here is review board: https://reviews.apache.org/r/57790/ Google doc for design: https://docs.google.com/document/d/1ACCLsecHDvzVSasORgqqRNrloGx4mNYIbvAU7lq5lJE was: Currently, incremental backup is based on WAL files. Bulk data loading bypasses WALs for obvious reasons, breaking incremental backups. The only way to continue backups after bulk loading is to create new full backup of a table. This may not be feasible for customers who do bulk loading regularly (say, every day). Here is the review board (out of date): https://reviews.apache.org/r/54258/ In order not to miss the hfiles which are loaded into region directories in a situation where postBulkLoadHFile() hook is not called (bulk load being interrupted), we record hfile names thru preCommitStoreFile() hook. At time of incremental backup, we check the presence of such hfiles. If they are present, they become part of the incremental backup image. Google doc for design: https://docs.google.com/document/d/1ACCLsecHDvzVSasORgqqRNrloGx4mNYIbvAU7lq5lJE > Incremental backup and bulk loading > --- > > Key: HBASE-14417 > URL: https://issues.apache.org/jira/browse/HBASE-14417 > Project: HBase > Issue Type: New Feature >Reporter: Vladimir Rodionov >Assignee: Ted Yu >Priority: Blocker > Labels: backup > Fix For: 2.0 > > Attachments: 14417-tbl-ext.v10.txt, 14417-tbl-ext.v11.txt, > 14417-tbl-ext.v14.txt, 14417-tbl-ext.v18.txt, 14417-tbl-ext.v19.txt, > 14417-tbl-ext.v20.txt, 14417-tbl-ext.v21.txt, 14417-tbl-ext.v9.txt, > 14417.v11.txt, 14417.v13.txt, 14417.v1.txt, 14417.v21.txt, 14417.v23.txt, > 14417.v24.txt, 14417.v25.txt, 14417.v2.txt, 14417.v6.txt > > > Currently, incremental backup is based on WAL files. Bulk data loading > bypasses WALs for obvious reasons, breaking incremental backups. The only way > to continue backups after bulk loading is to create new full backup of a > table. This may not be feasible for customers who do bulk loading regularly > (say, every day). > Here is the review board (out of date): > https://reviews.apache.org/r/54258/ > In order not to miss the hfiles which are loaded into region directories in a > situation where postBulkLoadHFile() hook is not called (bulk load being > interrupted), we record hfile names thru preCommitStoreFile() hook. > At time of incremental backup, we check the presence of such hfiles. If they > are present, they become part of the incremental backup image. > Here is review board: > https://reviews.apache.org/r/57790/ > Google doc for design: > https://docs.google.com/document/d/1ACCLsecHDvzVSasORgqqRNrloGx4mNYIbvAU7lq5lJE -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-15583) Discuss mutable vs immutable HTableDescriptor
[ https://issues.apache.org/jira/browse/HBASE-15583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933290#comment-15933290 ] stack commented on HBASE-15583: --- bq. Shell we avoid the obscure immutable HTableDescriptor ? Yes. The idea was when we pass out an HTD, that it would be read-only. We'd do this in case application/client changed HTD and either expected the HTD change to ripple through to the cluster or, their change messed up the current connection because it was operating with an alternate view to what the cluster was running with. Lets not change the API to return ImmutableHTD. While that is explicit about what is being handed back, it is too much work to back-fill. Could we change the returned type to be ImmutableHTD in Table and Admin leaving the APIs as they are. If client tries to modify the IHTD, they'll get an exception the first time they try. The javadoc says we return an immurable (least I thought it did). > Discuss mutable vs immutable HTableDescriptor > - > > Key: HBASE-15583 > URL: https://issues.apache.org/jira/browse/HBASE-15583 > Project: HBase > Issue Type: Sub-task >Affects Versions: 2.0.0 >Reporter: Gabor Liptak >Priority: Minor > Labels: beginner > Fix For: 2.0.0 > > > From [~enis] in https://issues.apache.org/jira/browse/HBASE-15505: > PS Should UnmodifyableHTableDescriptor be renamed to > UnmodifiableHTableDescriptor? > It should be named ImmutableHTableDescriptor to be consistent with > collections naming. Let's do this as a subtask of the parent jira, not here. > Thinking about it though, why would we return an Immutable HTD in > HTable.getTableDescriptor() versus a mutable HTD in > Admin.getTableDescriptor(). It does not make sense. Should we just get rid of > the Immutable ones? > We also have UnmodifyableHRegionInfo which is not used at the moment it > seems. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-14417) Incremental backup and bulk loading
[ https://issues.apache.org/jira/browse/HBASE-14417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933289#comment-15933289 ] Vladimir Rodionov commented on HBASE-14417: --- [~te...@apache.org], can you submit the patch to RB? > Incremental backup and bulk loading > --- > > Key: HBASE-14417 > URL: https://issues.apache.org/jira/browse/HBASE-14417 > Project: HBase > Issue Type: New Feature >Reporter: Vladimir Rodionov >Assignee: Ted Yu >Priority: Blocker > Labels: backup > Fix For: 2.0 > > Attachments: 14417-tbl-ext.v10.txt, 14417-tbl-ext.v11.txt, > 14417-tbl-ext.v14.txt, 14417-tbl-ext.v18.txt, 14417-tbl-ext.v19.txt, > 14417-tbl-ext.v20.txt, 14417-tbl-ext.v21.txt, 14417-tbl-ext.v9.txt, > 14417.v11.txt, 14417.v13.txt, 14417.v1.txt, 14417.v21.txt, 14417.v23.txt, > 14417.v24.txt, 14417.v25.txt, 14417.v2.txt, 14417.v6.txt > > > Currently, incremental backup is based on WAL files. Bulk data loading > bypasses WALs for obvious reasons, breaking incremental backups. The only way > to continue backups after bulk loading is to create new full backup of a > table. This may not be feasible for customers who do bulk loading regularly > (say, every day). > Here is the review board (out of date): > https://reviews.apache.org/r/54258/ > In order not to miss the hfiles which are loaded into region directories in a > situation where postBulkLoadHFile() hook is not called (bulk load being > interrupted), we record hfile names thru preCommitStoreFile() hook. > At time of incremental backup, we check the presence of such hfiles. If they > are present, they become part of the incremental backup image. > Google doc for design: > https://docs.google.com/document/d/1ACCLsecHDvzVSasORgqqRNrloGx4mNYIbvAU7lq5lJE -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17739) BucketCache is inefficient/wasteful/dumb in its bucket allocations
[ https://issues.apache.org/jira/browse/HBASE-17739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933266#comment-15933266 ] Vladimir Rodionov commented on HBASE-17739: --- BucketCache has two major design/implementation issues: # It keeps all meta (block locations and block list per file) on Java heap # It is not write friendly for SSDs. All write operations are random. The implications are two-fold: decreased SSD life span due to huge write amplification and decreased write performance when SSD is close to full Both are very serious problems, which prevents BucketCache going big. Heap overhead is close to 500 bytes per block. Do your math. 10M blocks require 5GB. If block size with compression 20Kb it translates to 200GB cache. For 1TB cache you will need 25GB of Java heap only to keep blocks meta. > BucketCache is inefficient/wasteful/dumb in its bucket allocations > -- > > Key: HBASE-17739 > URL: https://issues.apache.org/jira/browse/HBASE-17739 > Project: HBase > Issue Type: Sub-task > Components: BucketCache >Reporter: stack > > By default we allocate 14 buckets with sizes from 5K to 513K. If lots of heap > given over to bucketcache and say no allocattions made for a particular > bucket size, this means we have a bunch of the bucketcache that just goes > idle/unused. > For example, say heap is 100G. We'll divide it up among the sizes. If say we > only ever do 5k records, then most of the cache will go unused while the > allocation for 5k objects will see churn. > Here is an old note of [~anoop.hbase]'s' from a conversation on bucket cache > we had offlist that describes the issue: > "By default we have those 14 buckets with size range of 5K to 513K. > All sizes will have one bucket (with size 513*4) each except the > last size.. ie. 513K sized many buckets will be there. If we keep on > writing only same sized blocks, we may loose all in btw sized buckets. > Say we write only 4K sized blocks. We will 1st fill the bucket in 5K > size. There is only one such bucket. Once this is filled, we will try > to grab a complete free bucket from other sizes.. But we can not take > it from 9K... 385K sized ones as there is only ONE bucket for these > sizes. We will take only from 513 size.. There are many in that... > So we will eventually take all the buckets from 513 except the last > one.. Ya it has to keep at least one in evey size.. So we will > loose these much size.. They are of no use." > We should set the size type on the fly as the records come in. > Or better, we should choose record size on the fly. Here is another comment > from [~anoop.hbase]: > "The second is the biggest contributor. Suppose instead of 4K > sized blocks, the user has 2 K sized blocks.. When we write a block to > bucket slot, we will reserve size equal to the allocated size for that block. > So when we write 2K sized blocks (may be actual size a bit more than > 2K ) we will take 5K with each of the block. So u can see that we are > loosing ~3K with every block. Means we are loosing more than half." > He goes on: "If am 100% sure that all my table having 2K HFile block size, I > need to give this config a value 3 * 1024 (Exact 2 K if I give there may be > again problem! That is another story we need to see how we can give > more guarantee for the block size restriction HBASE-15248).. So here also > ~1K loose for every 2K.. So some thing like a 30% loose !!! :-(“" > So, we should figure the record sizes ourselves on the fly. > Anything less has us wasting loads of cache space, nvm inefficiences lost > because of how we serialize base types to cache. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17582) Drop page cache hint is broken
[ https://issues.apache.org/jira/browse/HBASE-17582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Appy updated HBASE-17582: - Resolution: Fixed Status: Resolved (was: Patch Available) > Drop page cache hint is broken > -- > > Key: HBASE-17582 > URL: https://issues.apache.org/jira/browse/HBASE-17582 > Project: HBase > Issue Type: Bug > Components: Compaction, io >Affects Versions: 2.0.0 >Reporter: Ashu Pachauri >Assignee: Appy >Priority: Critical > Fix For: 2.0.0 > > Attachments: HBASE-17582.master.001.patch, > HBASE-17582.master.002.patch > > > We pass a boolean for pass page cache drop hint while creating store file > scanners and writers. > The hint is not passed on down the stack by StoreFileWriter and > StoreFileScanner in the master branch. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (HBASE-17582) Drop page cache hint is broken
[ https://issues.apache.org/jira/browse/HBASE-17582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933239#comment-15933239 ] Appy edited comment on HBASE-17582 at 3/20/17 6:27 PM: --- unrelated test failures, committing. Bug is only in 2.0. was (Author: appy): unrelated test failures, committing. > Drop page cache hint is broken > -- > > Key: HBASE-17582 > URL: https://issues.apache.org/jira/browse/HBASE-17582 > Project: HBase > Issue Type: Bug > Components: Compaction, io >Affects Versions: 2.0.0 >Reporter: Ashu Pachauri >Assignee: Appy >Priority: Critical > Fix For: 2.0.0 > > Attachments: HBASE-17582.master.001.patch, > HBASE-17582.master.002.patch > > > We pass a boolean for pass page cache drop hint while creating store file > scanners and writers. > The hint is not passed on down the stack by StoreFileWriter and > StoreFileScanner in the master branch. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17582) Drop page cache hint is broken
[ https://issues.apache.org/jira/browse/HBASE-17582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Appy updated HBASE-17582: - Fix Version/s: 2.0.0 > Drop page cache hint is broken > -- > > Key: HBASE-17582 > URL: https://issues.apache.org/jira/browse/HBASE-17582 > Project: HBase > Issue Type: Bug > Components: Compaction, io >Affects Versions: 2.0.0 >Reporter: Ashu Pachauri >Assignee: Appy >Priority: Critical > Fix For: 2.0.0 > > Attachments: HBASE-17582.master.001.patch, > HBASE-17582.master.002.patch > > > We pass a boolean for pass page cache drop hint while creating store file > scanners and writers. > The hint is not passed on down the stack by StoreFileWriter and > StoreFileScanner in the master branch. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17812) Remove RpcConnection from pool in AbstractRpcClient.cancelConnections
[ https://issues.apache.org/jira/browse/HBASE-17812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933243#comment-15933243 ] stack commented on HBASE-17812: --- +1 > Remove RpcConnection from pool in AbstractRpcClient.cancelConnections > - > > Key: HBASE-17812 > URL: https://issues.apache.org/jira/browse/HBASE-17812 > Project: HBase > Issue Type: Bug > Components: Client, rpc >Affects Versions: 2.0.0 >Reporter: Duo Zhang >Assignee: Duo Zhang > Labels: trivial > Fix For: 2.0.0 > > Attachments: HBASE-17812.patch > > > Found it when backporting the new rpc implementation to branch-1 in > HBASE-16584. It will cause TestHCM fail on branch-1 as on branch-1 the > default rpc implementation is BlockingRpcClient which is not always > reconnectable after shutdown. On master TestHCM will not fail as > NettyRpcConnection is always reconnectable. But we still need to fix it as it > is a bug. Only a trivial one line patch. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17582) Drop page cache hint is broken
[ https://issues.apache.org/jira/browse/HBASE-17582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933239#comment-15933239 ] Appy commented on HBASE-17582: -- unrelated test failures, committing. > Drop page cache hint is broken > -- > > Key: HBASE-17582 > URL: https://issues.apache.org/jira/browse/HBASE-17582 > Project: HBase > Issue Type: Bug > Components: Compaction, io >Affects Versions: 2.0.0 >Reporter: Ashu Pachauri >Assignee: Appy >Priority: Critical > Attachments: HBASE-17582.master.001.patch, > HBASE-17582.master.002.patch > > > We pass a boolean for pass page cache drop hint while creating store file > scanners and writers. > The hint is not passed on down the stack by StoreFileWriter and > StoreFileScanner in the master branch. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17655) Removing MemStoreScanner and SnapshotScanner
[ https://issues.apache.org/jira/browse/HBASE-17655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933196#comment-15933196 ] stack commented on HBASE-17655: --- I just went over rb. Left a few comments. Nothing important that can't be addressed in follow-on (and seems like this last patch seems to have addressed some of them). I put a +1 over in RB. This is a nice cleanup. Seems like we are retaining CP compat? If not, mark incompatible and I'll add this to the list of things to address as part of 2.0 upgrade. > Removing MemStoreScanner and SnapshotScanner > > > Key: HBASE-17655 > URL: https://issues.apache.org/jira/browse/HBASE-17655 > Project: HBase > Issue Type: Improvement > Components: Scanners >Affects Versions: 2.0.0 >Reporter: Eshcar Hillel >Assignee: Eshcar Hillel > Attachments: HBASE-17655-V01.patch, HBASE-17655-V02.patch, > HBASE-17655-V03.patch, HBASE-17655-V04.patch, HBASE-17655-V05.patch, > HBASE-17655-V05.patch, HBASE-17655-V06.patch, HBASE-17655-V07.patch, > HBASE-17655-V08.patch > > > With CompactingMemstore becoming the new default, a store comprises multiple > memory segments and not just 1-2. MemStoreScanner encapsulates the scanning > of segments in the memory part of the store. SnapshotScanner is used to scan > the snapshot segment upon flush to disk. > Having the logic of scanners scattered in multiple classes (StoreScanner, > SegmentScanner, MemStoreScanner, SnapshotScanner) makes maintainance and > debugging challenging tasks, not always for a good reason. > For example, MemStoreScanner has a KeyValueHeap (KVH). When creating the > store scanner which also has a KVH, this makes a KVH inside a KVH. Reasoning > about the correctness of the methods supported by the scanner (seek, next, > hasNext, peek, etc.) is hard and debugging them is cumbersome. > In addition, by removing the MemStoreScanner layer we allow store scanner to > filter out each one of the memory scanners instead of either taking them all > (in most cases) or discarding them all (rarely). > SnapshotScanner is a simplified version of SegmentScanner as it is used only > in a specific context. However it is an additional implementation of the same > logic with no real advantage of improved performance. > Therefore, I suggest removing both MemStoreScanner and SnapshotScanner. The > code is adjusted to handle the list of segment scanners they encapsulate. > This fits well with the current code since in most cases at some point a list > of scanner is expected, so passing the actual list of segment scanners is > more natural than wrapping a single (high level) scanner with > Collections.singeltonList(...). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (HBASE-12579) Move obtainAuthTokenForJob() methods out of User
[
https://issues.apache.org/jira/browse/HBASE-12579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Helmling resolved HBASE-12579.
---
Resolution: Duplicate
The methods were deprecated and the existing usage was removed as part of
HBASE-12493. I guess I left this open for the final removal of the deprecated
methods from the next major release. The removal was done as part of
HBASE-14208.
> Move obtainAuthTokenForJob() methods out of User
>
>
> Key: HBASE-12579
> URL: https://issues.apache.org/jira/browse/HBASE-12579
> Project: HBase
> Issue Type: Improvement
> Components: security
>Reporter: Gary Helmling
>
> The {{User}} class currently contains some utility methods to obtain HBase
> authentication tokens for the given user. However, these methods initiate an
> RPC to the {{TokenProvider}} coprocessor endpoint, an action which should not
> be part of the User class' responsibilities.
> This leads to a couple of problems:
> # The way the methods are currently structured, it is impossible to integrate
> them with normal connection management for the cluster (the TokenUtil class
> constructs its own HTable instance internally).
> # The User class is logically part of the hbase-common module, but uses the
> TokenUtil class (part of hbase-server, though it should probably be moved to
> hbase-client) through reflection, leading to a hidden dependency.
> The {{obtainAuthTokenForJob()}} methods should be deprecated and the process
> of obtaining authentication tokens should be moved to use the normal
> connection lifecycle.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (HBASE-16084) Clean up the stale references in javadoc
[
https://issues.apache.org/jira/browse/HBASE-16084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-16084:
---
Resolution: Fixed
Hadoop Flags: Reviewed
Fix Version/s: 2.0.0
Status: Resolved (was: Patch Available)
Thanks for the patch, Jan.
> Clean up the stale references in javadoc
>
>
> Key: HBASE-16084
> URL: https://issues.apache.org/jira/browse/HBASE-16084
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Jan Hentschel
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-16084.master.001.patch,
> HBASE-16084.master.002.patch, HBASE-16084.master.003.patch
>
>
> From TestHFileOutputFormat2 , e.g.:
> {code}
> * Simple test for {@link CellSortReducer} and {@link HFileOutputFormat2}.
> {code}
> CellSortReducer doesn't exist.
> From TestSerialization.java :
> {code}
>* Create a table of name name with {@link COLUMNS} for
> {code}
> COLUMNS cannot be found.
> This issue is to clean up the stale references in javadoc.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-16084) Clean up the stale references in javadoc
[
https://issues.apache.org/jira/browse/HBASE-16084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933177#comment-15933177
]
Hadoop QA commented on HBASE-16084:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 20s
{color} | {color:blue} Docker mode activated. {color} |
| {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 18 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 1m 18s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
30s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 42s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
51s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
10s {color} | {color:green} master passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 0m 22s
{color} | {color:red} hbase-prefix-tree in master has 1 extant Findbugs
warnings. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 36s
{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 12s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
54s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 41s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 41s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
52s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
54s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
31m 5s {color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha2. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m 2s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 18s
{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 12s
{color} | {color:green} hbase-procedure in the patch passed. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 18s
{color} | {color:green} hbase-client generated 0 new + 1 unchanged - 12 fixed =
1 total (was 13) {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 11s
{color} | {color:green} hbase-prefix-tree generated 0 new + 0 unchanged - 5
fixed = 0 total (was 5) {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 30s
{color} | {color:green} hbase-server generated 0 new + 0 unchanged - 1 fixed =
0 total (was 1) {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 57s
{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m 49s
{color} | {color:green} hbase-procedure in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m 26s
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 23s
{color} | {color:green} hbase-prefix-tree in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 123m 45s
{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 1m
26s {color} | {color:green} The patch does not generate ASF License
[jira] [Commented] (HBASE-17765) Reviving the merge possibility in the CompactingMemStore
[
https://issues.apache.org/jira/browse/HBASE-17765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933143#comment-15933143
]
Hadoop QA commented on HBASE-17765:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 28s
{color} | {color:blue} Docker mode activated. {color} |
| {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} 6m
49s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 41s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
57s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
20s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m 1s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 40s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
49s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 42s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 42s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
47s {color} | {color:green} the patch passed {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} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
30m 43s {color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha2. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
15s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 39s
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 131m 1s {color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
21s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 180m 2s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.13.1 Server=1.13.1 Image:yetus/hbase:8d52d23 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12859552/HBASE-17765-V02.patch
|
| JIRA Issue | HBASE-17765 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux 954f7a031d47 3.13.0-106-generic #153-Ubuntu SMP Tue Dec 6
15:44:32 UTC 2016 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 / 5b4bb82 |
| Default Java | 1.8.0_121 |
| findbugs | v3.0.0 |
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/6165/artifact/patchprocess/patch-unit-hbase-server.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/6165/testReport/ |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/6165/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> Reviving the merge possibility in the CompactingMemStore
>
>
> Key: HBASE-17765
> URL: https://issues.apache.org/jira/browse/HBASE-17765
> Project: HBase
> Issue Type: Sub-task
>Reporter: Anastasia Braginsky
>Assignee: Anastasia Braginsky
>
[jira] [Commented] (HBASE-13395) Remove HTableInterface
[
https://issues.apache.org/jira/browse/HBASE-13395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933137#comment-15933137
]
Hadoop QA commented on HBASE-13395:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 12s
{color} | {color:blue} Docker mode activated. {color} |
| {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 16s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
23s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m 26s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
47s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
33s {color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m 0s
{color} | {color:blue} Skipped patched modules with no Java source: . {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
56s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 39s
{color} | {color:green} master passed {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
42s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m 24s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 3m 24s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
47s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
33s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
28m 52s {color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha2. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m 0s
{color} | {color:blue} Skipped patched modules with no Java source: . {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
55s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 15s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m 14s
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 121m 49s
{color} | {color:red} root in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
37s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 179m 59s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Timed out junit tests |
org.apache.hadoop.hbase.client.TestAvoidCellReferencesIntoShippedBlocks |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.11.2 Server=1.11.2 Image:yetus/hbase:8d52d23 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12859554/HBASE-13395.master.004.patch
|
| JIRA Issue | HBASE-13395 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux 6ad85d55265a 3.13.0-103-generic #150-Ubuntu SMP Thu Nov 24
10:34:17 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
[jira] [Commented] (HBASE-17175) backport HBASE-17127 to 1.3.1
[ https://issues.apache.org/jira/browse/HBASE-17175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933120#comment-15933120 ] Yu Li commented on HBASE-17175: --- Reviewed in HBASE-17127, direct cherry-pick w/o UT failure, will commit soon if no objections. > backport HBASE-17127 to 1.3.1 > - > > Key: HBASE-17175 > URL: https://issues.apache.org/jira/browse/HBASE-17175 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.0 >Reporter: Yu Li >Assignee: Yu Li > Fix For: 1.3.1 > > Attachments: HBASE-17175.branch-1.3.patch > > > branch-1.3 is currently freeze for 1.3.0 release, need to backport > HBASE-17127 later -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17655) Removing MemStoreScanner and SnapshotScanner
[
https://issues.apache.org/jira/browse/HBASE-17655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933131#comment-15933131
]
Hadoop QA commented on HBASE-17655:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 22s
{color} | {color:blue} Docker mode activated. {color} |
| {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 9 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 1m 18s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
37s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 52s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
26s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
42s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
13s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 49s
{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 14s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
6s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 0s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 0s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
44s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
31s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
30m 42s {color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha2. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
41s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 44s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 122m 22s
{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 30s
{color} | {color:green} hbase-examples in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
29s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 174m 56s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.13.1 Server=1.13.1 Image:yetus/hbase:8d52d23 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12859558/HBASE-17655-V08.patch
|
| JIRA Issue | HBASE-17655 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux e3707687c51e 3.13.0-106-generic #153-Ubuntu SMP Tue Dec 6
15:44:32 UTC 2016 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 / 5b4bb82 |
| Default Java | 1.8.0_121 |
| findbugs | v3.0.0 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/6164/testReport/ |
| modules | C: hbase-server hbase-examples U: . |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/6164/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> Removing MemStoreScanner and SnapshotScanner
[jira] [Updated] (HBASE-17060) backport HBASE-16570 to 1.3.1
[ https://issues.apache.org/jira/browse/HBASE-17060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yu Li updated HBASE-17060: -- Attachment: HBASE-17060.branch-1.3.v1.patch Checked UT failures and confirmed irrelative to change here, retry. > backport HBASE-16570 to 1.3.1 > - > > Key: HBASE-17060 > URL: https://issues.apache.org/jira/browse/HBASE-17060 > Project: HBase > Issue Type: Sub-task >Affects Versions: 1.3.0 >Reporter: Yu Li >Assignee: binlijin > Fix For: 1.3.1 > > Attachments: HBASE-17060.branch-1.3.v1.patch, > HBASE-17060.branch-1.3.v1.patch, HBASE-17060.branch-1.3.v1.patch > > > Need some backport after 1.3.0 got released -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17059) backport HBASE-17039 to 1.3.1
[ https://issues.apache.org/jira/browse/HBASE-17059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yu Li updated HBASE-17059: -- Attachment: HBASE-17059.branch-1.3.patch Checked UT failures and confirmed irrelative to change here, retry. > backport HBASE-17039 to 1.3.1 > - > > Key: HBASE-17059 > URL: https://issues.apache.org/jira/browse/HBASE-17059 > Project: HBase > Issue Type: Bug > Components: Balancer >Affects Versions: 1.3.0 >Reporter: Yu Li >Assignee: Yu Li > Fix For: 1.3.1 > > Attachments: HBASE-17059.branch-1.3.patch, > HBASE-17059.branch-1.3.patch > > > Currently branch-1.3 codes are freezing for 1.3.0 release, need to backport > HBASE-17039 to 1.3.1 afterwards. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17070) backport HBASE-17020 to 1.3.1
[ https://issues.apache.org/jira/browse/HBASE-17070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yu Li updated HBASE-17070: -- Attachment: HBASE-17070.branch-1.3.patch Checked UT failures and confirmed irrelative to change here, retry. > backport HBASE-17020 to 1.3.1 > - > > Key: HBASE-17070 > URL: https://issues.apache.org/jira/browse/HBASE-17070 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.0 >Reporter: Yu Li >Assignee: Yu Li > Fix For: 1.3.1 > > Attachments: HBASE-17070.branch-1.3.patch, > HBASE-17070.branch-1.3.patch > > > As titled, backport HBASE-17020 after 1.3.0 got released. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17691) Add ScanMetrics support for async scan
[ https://issues.apache.org/jira/browse/HBASE-17691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933126#comment-15933126 ] Hudson commented on HBASE-17691: SUCCESS: Integrated in Jenkins build HBase-Trunk_matrix #2707 (See [https://builds.apache.org/job/HBase-Trunk_matrix/2707/]) HBASE-17691 Add ScanMetrics support for async scan (zhangduo: rev 5b4bb8217dd4327a89fa29c93ac37bc887d96c2c) * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestRawAsyncTableScan.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/AsyncClientScanner.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestAsyncTableScan.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/AsyncRpcRetryingCallerFactory.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/AsyncTableResultScanner.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/ReversedScannerCallable.java * (add) hbase-server/src/test/java/org/apache/hadoop/hbase/client/SimpleRawScanResultConsumer.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/AsyncScanSingleRegionRpcRetryingCaller.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/ConnectionUtils.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/ScanResultConsumer.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/ScannerCallable.java * (add) hbase-server/src/test/java/org/apache/hadoop/hbase/client/SimpleScanResultConsumer.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/ClientScanner.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/AsyncTableBase.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/RawScanResultConsumer.java * (add) hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestAsyncTableScanMetrics.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/AsyncTableImpl.java > Add ScanMetrics support for async scan > -- > > Key: HBASE-17691 > URL: https://issues.apache.org/jira/browse/HBASE-17691 > Project: HBase > Issue Type: Sub-task > Components: Client >Reporter: Duo Zhang >Assignee: Duo Zhang > Fix For: 2.0.0 > > Attachments: HBASE-17691.patch, HBASE-17691-v1.patch > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17669) Implement async mergeRegion/splitRegion methods.
[
https://issues.apache.org/jira/browse/HBASE-17669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933111#comment-15933111
]
Hadoop QA commented on HBASE-17669:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 16m 56s
{color} | {color:blue} Docker mode activated. {color} |
| {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:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 1m 29s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
22s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 59s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
50s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
38s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
44s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 49s
{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 12s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
2s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 56s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 56s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
46s {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} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
31m 58s {color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha2. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
25s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 56s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m 25s
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 92m 59s {color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
30s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 166m 7s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.util.TestHBaseFsckReplicas |
| | hadoop.hbase.security.access.TestCoprocessorWhitelistMasterObserver |
| | hadoop.hbase.util.TestHBaseFsckTwoRS |
| Timed out junit tests |
org.apache.hadoop.hbase.regionserver.TestCorruptedRegionStoreFile |
| |
org.apache.hadoop.hbase.regionserver.throttle.TestCompactionWithThroughputController
|
| |
org.apache.hadoop.hbase.regionserver.throttle.TestFlushWithThroughputController
|
| | org.apache.hadoop.hbase.util.TestHBaseFsckTwoRS |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.03.0-ce Server=17.03.0-ce Image:yetus/hbase:8d52d23 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12859569/HBASE-17669.v5.patch |
| JIRA Issue | HBASE-17669 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux 1e8b0bf75743 3.13.0-107-generic #154-Ubuntu SMP Tue Dec 20
09:57:27 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
[jira] [Commented] (HBASE-16417) In-Memory MemStore Policy for Flattening and Compactions
[ https://issues.apache.org/jira/browse/HBASE-16417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933096#comment-15933096 ] stack commented on HBASE-16417: --- Thank you [~eshcar] for digging in on my question. Sounds like we can simplify here if we get parallelism in here (I'm not sure why it is not parallel already -- it may just be cruft) and if we do the simplification, then we might be able to do w/o the merge. Suggest we open new perf issue to dig in on why NOT parallel but meantime, keep this issue moving forward but now BASIC includes merge. > In-Memory MemStore Policy for Flattening and Compactions > > > Key: HBASE-16417 > URL: https://issues.apache.org/jira/browse/HBASE-16417 > Project: HBase > Issue Type: Sub-task >Reporter: Anastasia Braginsky >Assignee: Eshcar Hillel > Fix For: 2.0.0 > > Attachments: HBASE-16417-benchmarkresults-20161101.pdf, > HBASE-16417-benchmarkresults-20161110.pdf, > HBASE-16417-benchmarkresults-20161123.pdf, > HBASE-16417-benchmarkresults-20161205.pdf, > HBASE-16417-benchmarkresults-20170309.pdf, > HBASE-16417-benchmarkresults-20170317.pdf > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17584) Expose ScanMetrics with ResultScanner rather than Scan
[ https://issues.apache.org/jira/browse/HBASE-17584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933012#comment-15933012 ] Hudson commented on HBASE-17584: FAILURE: Integrated in Jenkins build HBase-1.4 #677 (See [https://builds.apache.org/job/HBase-1.4/677/]) HBASE-17584 Expose ScanMetrics with ResultScanner rather than Scan (zhangduo: rev b973d3fd467b4382198aefc35d2c4e9b4c41ee6d) * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/ClientScanner.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/protobuf/ProtobufUtil.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/client/ClientSideRegionScanner.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/TableRecordReaderImpl.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/ResultScanner.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/Scan.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/AbstractClientScanner.java * (edit) hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/client/RemoteHTable.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/metrics/ServerSideScanMetrics.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/TestServerSideScanMetricsFromClientSide.java > Expose ScanMetrics with ResultScanner rather than Scan > -- > > Key: HBASE-17584 > URL: https://issues.apache.org/jira/browse/HBASE-17584 > Project: HBase > Issue Type: Sub-task > Components: Client, mapreduce, scan >Affects Versions: 2.0.0 >Reporter: Duo Zhang >Assignee: Duo Zhang > Fix For: 2.0.0 > > Attachments: HBASE-17584-branch-1.patch, HBASE-17584.patch, > HBASE-17584-v1.patch > > > I think this have been discussed many times... It is a bad practice to > directly modify the Scan object passed in when calling getScanner. The reason > that we can not use a copy is we need to use the Scan object to expose scan > metrics. So we need to find another way to expose the metrics. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17806) TestRSGroups#testMoveServersAndTables is flaky in master branch
[
https://issues.apache.org/jira/browse/HBASE-17806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-17806:
---
Resolution: Fixed
Hadoop Flags: Reviewed
Fix Version/s: 2.0
Status: Resolved (was: Patch Available)
Thanks for the patch, Guangxu
> TestRSGroups#testMoveServersAndTables is flaky in master branch
> ---
>
> Key: HBASE-17806
> URL: https://issues.apache.org/jira/browse/HBASE-17806
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
>Assignee: Guangxu Cheng
> Fix For: 2.0
>
> Attachments: HBASE-17806-v1.patch
>
>
> According to https://builds.apache.org/job/HBASE-Flaky-Tests ,
> TestRSGroups#testMoveServersAndTables is the top flaky test.
> Recent test failure:
> https://builds.apache.org/job/HBASE-Flaky-Tests/14062/testReport/junit/org.apache.hadoop.hbase.rsgroup/TestRSGroups/testMoveServersAndTables/
> {code}
> java.lang.AssertionError: expected:<4> but was:<5>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at
> org.apache.hadoop.hbase.rsgroup.TestRSGroupsBase.testMoveServersAndTables(TestRSGroupsBase.java:747)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (HBASE-17806) TestRSGroups#testMoveServersAndTables is flaky in master branch
[
https://issues.apache.org/jira/browse/HBASE-17806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu reassigned HBASE-17806:
--
Assignee: Guangxu Cheng
> TestRSGroups#testMoveServersAndTables is flaky in master branch
> ---
>
> Key: HBASE-17806
> URL: https://issues.apache.org/jira/browse/HBASE-17806
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
>Assignee: Guangxu Cheng
> Fix For: 2.0
>
> Attachments: HBASE-17806-v1.patch
>
>
> According to https://builds.apache.org/job/HBASE-Flaky-Tests ,
> TestRSGroups#testMoveServersAndTables is the top flaky test.
> Recent test failure:
> https://builds.apache.org/job/HBASE-Flaky-Tests/14062/testReport/junit/org.apache.hadoop.hbase.rsgroup/TestRSGroups/testMoveServersAndTables/
> {code}
> java.lang.AssertionError: expected:<4> but was:<5>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at
> org.apache.hadoop.hbase.rsgroup.TestRSGroupsBase.testMoveServersAndTables(TestRSGroupsBase.java:747)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-17806) TestRSGroups#testMoveServersAndTables is flaky in master branch
[
https://issues.apache.org/jira/browse/HBASE-17806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15932956#comment-15932956
]
Hadoop QA commented on HBASE-17806:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 20s
{color} | {color:blue} Docker mode activated. {color} |
| {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:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 12s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
50s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 38s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
47s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
25s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 2s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 29s
{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 12s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
33s {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 {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} 0m
43s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
23s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
27m 20s {color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha2. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
19s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 30s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 50s
{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m 42s
{color} | {color:green} hbase-rsgroup in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
13s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 44m 29s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:8d52d23 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12859507/HBASE-17806-v1.patch |
| JIRA Issue | HBASE-17806 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux 6fc6a7a27c48 3.13.0-106-generic #153-Ubuntu SMP Tue Dec 6
15:44:32 UTC 2016 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 / 5b4bb82 |
| Default Java | 1.8.0_121 |
| findbugs | v3.0.0 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/6169/testReport/ |
| modules | C: hbase-common hbase-rsgroup U: . |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/6169/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> TestRSGroups#testMoveServersAndTables is flaky in
[jira] [Commented] (HBASE-16179) Fix compilation errors when building hbase-spark against Spark 2.0
[ https://issues.apache.org/jira/browse/HBASE-16179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15932918#comment-15932918 ] Sean Busbey commented on HBASE-16179: - Personally I think all of the artifacts needed to use any of our "supported" combinations should be in the binary tarball, just properly kept out of the classpath for general HBase uses and their proper use documented. A dev list discussion would be fine, but I'd be surprised if we get much more participation. > Fix compilation errors when building hbase-spark against Spark 2.0 > -- > > Key: HBASE-16179 > URL: https://issues.apache.org/jira/browse/HBASE-16179 > Project: HBase > Issue Type: Bug > Components: spark >Reporter: Ted Yu >Assignee: Ted Yu >Priority: Critical > Fix For: 2.0.0 > > Attachments: 16179.v0.txt, 16179.v10.txt, 16179.v11.txt, > 16179.v12.txt, 16179.v12.txt, 16179.v12.txt, 16179.v13.txt, 16179.v15.txt, > 16179.v16.txt, 16179.v18.txt, 16179.v19.txt, 16179.v19.txt, 16179.v1.txt, > 16179.v1.txt, 16179.v20.txt, 16179.v22.txt, 16179.v23.txt, 16179.v24.txt, > 16179.v25.txt, 16179.v26.txt, 16179.v4.txt, 16179.v5.txt, 16179.v7.txt, > 16179.v8.txt, 16179.v9.txt > > > I tried building hbase-spark module against Spark-2.0 snapshot and got the > following compilation errors: > http://pastebin.com/bg3w247a > Some Spark classes such as DataTypeParser and Logging are no longer > accessible to downstream projects. > hbase-spark module should not depend on such classes. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (HBASE-15181) A simple implementation of date based tiered compaction
[ https://issues.apache.org/jira/browse/HBASE-15181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15932909#comment-15932909 ] Dave Latham edited comment on HBASE-15181 at 3/20/17 4:02 PM: -- I don't know enough about the details of the data schema that opentsdb uses to say if it will benefit. was (Author: davelatham): I don't know enough about the details of the data schema that opentsdb to say if it will benefit. > A simple implementation of date based tiered compaction > --- > > Key: HBASE-15181 > URL: https://issues.apache.org/jira/browse/HBASE-15181 > Project: HBase > Issue Type: New Feature > Components: Compaction >Reporter: Clara Xiong >Assignee: Clara Xiong > Fix For: 2.0.0, 1.3.0, 0.98.18 > > Attachments: HBASE-15181-0.98-ADD.patch, HBASE-15181-0.98.patch, > HBASE-15181-0.98.v4.patch, HBASE-15181-98.patch, HBASE-15181-ADD.patch, > HBASE-15181-branch-1.patch, HBASE-15181-master-v1.patch, > HBASE-15181-master-v2.patch, HBASE-15181-master-v3.patch, > HBASE-15181-master-v4.patch, HBASE-15181-v1.patch, HBASE-15181-v2.patch > > > This is a simple implementation of date-based tiered compaction similar to > Cassandra's for the following benefits: > 1. Improve date-range-based scan by structuring store files in date-based > tiered layout. > 2. Reduce compaction overhead. > 3. Improve TTL efficiency. > Perfect fit for the use cases that: > 1. has mostly date-based date write and scan and a focus on the most recent > data. > 2. never or rarely deletes data. > Out-of-order writes are handled gracefully. Time range overlapping among > store files is tolerated and the performance impact is minimized. > Configuration can be set at hbase-site.xml or overriden at per-table or > per-column-famly level by hbase shell. > Design spec is at > https://docs.google.com/document/d/1_AmlNb2N8Us1xICsTeGDLKIqL6T-oHoRLZ323MG_uy8/edit?usp=sharing > Results in our production is at > https://docs.google.com/document/d/1GqRtQZMMkTEWOijZc8UCTqhACNmdxBSjtAQSYIWsmGU/edit# -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17794) Remove lingering "violation" in favor of the accurate "snapshot"
[ https://issues.apache.org/jira/browse/HBASE-17794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15932880#comment-15932880 ] Ted Yu commented on HBASE-17794: lgtm > Remove lingering "violation" in favor of the accurate "snapshot" > > > Key: HBASE-17794 > URL: https://issues.apache.org/jira/browse/HBASE-17794 > Project: HBase > Issue Type: Sub-task >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Trivial > Fix For: HBASE-16961 > > Attachments: HBASE-17794.001.HBASE-16961.patch > > > Previously, quota violations used to be stored in the quota table. > Eventually, I realized that I needed to actually persist the utilization of > each table/NS, not just the violation state. > I know there are cases in the code where "violation" is incorrectly > describing things (it should be "snapshot"). Clean these up for clarity. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-15181) A simple implementation of date based tiered compaction
[ https://issues.apache.org/jira/browse/HBASE-15181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15932909#comment-15932909 ] Dave Latham commented on HBASE-15181: - I don't know enough about the details of the data schema that opentsdb to say if it will benefit. > A simple implementation of date based tiered compaction > --- > > Key: HBASE-15181 > URL: https://issues.apache.org/jira/browse/HBASE-15181 > Project: HBase > Issue Type: New Feature > Components: Compaction >Reporter: Clara Xiong >Assignee: Clara Xiong > Fix For: 2.0.0, 1.3.0, 0.98.18 > > Attachments: HBASE-15181-0.98-ADD.patch, HBASE-15181-0.98.patch, > HBASE-15181-0.98.v4.patch, HBASE-15181-98.patch, HBASE-15181-ADD.patch, > HBASE-15181-branch-1.patch, HBASE-15181-master-v1.patch, > HBASE-15181-master-v2.patch, HBASE-15181-master-v3.patch, > HBASE-15181-master-v4.patch, HBASE-15181-v1.patch, HBASE-15181-v2.patch > > > This is a simple implementation of date-based tiered compaction similar to > Cassandra's for the following benefits: > 1. Improve date-range-based scan by structuring store files in date-based > tiered layout. > 2. Reduce compaction overhead. > 3. Improve TTL efficiency. > Perfect fit for the use cases that: > 1. has mostly date-based date write and scan and a focus on the most recent > data. > 2. never or rarely deletes data. > Out-of-order writes are handled gracefully. Time range overlapping among > store files is tolerated and the performance impact is minimized. > Configuration can be set at hbase-site.xml or overriden at per-table or > per-column-famly level by hbase shell. > Design spec is at > https://docs.google.com/document/d/1_AmlNb2N8Us1xICsTeGDLKIqL6T-oHoRLZ323MG_uy8/edit?usp=sharing > Results in our production is at > https://docs.google.com/document/d/1GqRtQZMMkTEWOijZc8UCTqhACNmdxBSjtAQSYIWsmGU/edit# -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17003) Update book for filesystem use quotas
[ https://issues.apache.org/jira/browse/HBASE-17003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15932878#comment-15932878 ] Ted Yu commented on HBASE-17003: lgtm > Update book for filesystem use quotas > - > > Key: HBASE-17003 > URL: https://issues.apache.org/jira/browse/HBASE-17003 > Project: HBase > Issue Type: Sub-task > Components: documentation >Reporter: Josh Elser >Assignee: Josh Elser > Fix For: HBASE-16961 > > Attachments: book.html, HBASE-17003.001.HBASE-16961.patch, > HBASE-17003.002.HBASE-16961.patch > > > Need to make sure that the book's section on quotas reflect the final > implementation of the filesystem-use quota support. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-15181) A simple implementation of date based tiered compaction
[ https://issues.apache.org/jira/browse/HBASE-15181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15932869#comment-15932869 ] Tianying Chang commented on HBASE-15181: [~enis] that is a great point. [~davelatham] I am wondering will opentsdb benefit from it thought since I assume it set startRow/stoprow with start/stop time encoded in it. That should have already excluded all unnecessary data? > A simple implementation of date based tiered compaction > --- > > Key: HBASE-15181 > URL: https://issues.apache.org/jira/browse/HBASE-15181 > Project: HBase > Issue Type: New Feature > Components: Compaction >Reporter: Clara Xiong >Assignee: Clara Xiong > Fix For: 2.0.0, 1.3.0, 0.98.18 > > Attachments: HBASE-15181-0.98-ADD.patch, HBASE-15181-0.98.patch, > HBASE-15181-0.98.v4.patch, HBASE-15181-98.patch, HBASE-15181-ADD.patch, > HBASE-15181-branch-1.patch, HBASE-15181-master-v1.patch, > HBASE-15181-master-v2.patch, HBASE-15181-master-v3.patch, > HBASE-15181-master-v4.patch, HBASE-15181-v1.patch, HBASE-15181-v2.patch > > > This is a simple implementation of date-based tiered compaction similar to > Cassandra's for the following benefits: > 1. Improve date-range-based scan by structuring store files in date-based > tiered layout. > 2. Reduce compaction overhead. > 3. Improve TTL efficiency. > Perfect fit for the use cases that: > 1. has mostly date-based date write and scan and a focus on the most recent > data. > 2. never or rarely deletes data. > Out-of-order writes are handled gracefully. Time range overlapping among > store files is tolerated and the performance impact is minimized. > Configuration can be set at hbase-site.xml or overriden at per-table or > per-column-famly level by hbase shell. > Design spec is at > https://docs.google.com/document/d/1_AmlNb2N8Us1xICsTeGDLKIqL6T-oHoRLZ323MG_uy8/edit?usp=sharing > Results in our production is at > https://docs.google.com/document/d/1GqRtQZMMkTEWOijZc8UCTqhACNmdxBSjtAQSYIWsmGU/edit# -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-16179) Fix compilation errors when building hbase-spark against Spark 2.0
[ https://issues.apache.org/jira/browse/HBASE-16179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15932839#comment-15932839 ] Jerry He commented on HBASE-16179: -- Hi, Ted and Sean I think it will as well be a good topic to bring it up to the dev and user lists for a discussion and awareness. > Fix compilation errors when building hbase-spark against Spark 2.0 > -- > > Key: HBASE-16179 > URL: https://issues.apache.org/jira/browse/HBASE-16179 > Project: HBase > Issue Type: Bug > Components: spark >Reporter: Ted Yu >Assignee: Ted Yu >Priority: Critical > Fix For: 2.0.0 > > Attachments: 16179.v0.txt, 16179.v10.txt, 16179.v11.txt, > 16179.v12.txt, 16179.v12.txt, 16179.v12.txt, 16179.v13.txt, 16179.v15.txt, > 16179.v16.txt, 16179.v18.txt, 16179.v19.txt, 16179.v19.txt, 16179.v1.txt, > 16179.v1.txt, 16179.v20.txt, 16179.v22.txt, 16179.v23.txt, 16179.v24.txt, > 16179.v25.txt, 16179.v26.txt, 16179.v4.txt, 16179.v5.txt, 16179.v7.txt, > 16179.v8.txt, 16179.v9.txt > > > I tried building hbase-spark module against Spark-2.0 snapshot and got the > following compilation errors: > http://pastebin.com/bg3w247a > Some Spark classes such as DataTypeParser and Logging are no longer > accessible to downstream projects. > hbase-spark module should not depend on such classes. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17806) TestRSGroups#testMoveServersAndTables is flaky in master branch
[
https://issues.apache.org/jira/browse/HBASE-17806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-17806:
---
Status: Patch Available (was: Open)
> TestRSGroups#testMoveServersAndTables is flaky in master branch
> ---
>
> Key: HBASE-17806
> URL: https://issues.apache.org/jira/browse/HBASE-17806
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
> Attachments: HBASE-17806-v1.patch
>
>
> According to https://builds.apache.org/job/HBASE-Flaky-Tests ,
> TestRSGroups#testMoveServersAndTables is the top flaky test.
> Recent test failure:
> https://builds.apache.org/job/HBASE-Flaky-Tests/14062/testReport/junit/org.apache.hadoop.hbase.rsgroup/TestRSGroups/testMoveServersAndTables/
> {code}
> java.lang.AssertionError: expected:<4> but was:<5>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at
> org.apache.hadoop.hbase.rsgroup.TestRSGroupsBase.testMoveServersAndTables(TestRSGroupsBase.java:747)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-16179) Fix compilation errors when building hbase-spark against Spark 2.0
[ https://issues.apache.org/jira/browse/HBASE-16179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15932812#comment-15932812 ] Ted Yu commented on HBASE-16179: [~busbey]: What do you think of Jerry's suggestion above ? > Fix compilation errors when building hbase-spark against Spark 2.0 > -- > > Key: HBASE-16179 > URL: https://issues.apache.org/jira/browse/HBASE-16179 > Project: HBase > Issue Type: Bug > Components: spark >Reporter: Ted Yu >Assignee: Ted Yu >Priority: Critical > Fix For: 2.0.0 > > Attachments: 16179.v0.txt, 16179.v10.txt, 16179.v11.txt, > 16179.v12.txt, 16179.v12.txt, 16179.v12.txt, 16179.v13.txt, 16179.v15.txt, > 16179.v16.txt, 16179.v18.txt, 16179.v19.txt, 16179.v19.txt, 16179.v1.txt, > 16179.v1.txt, 16179.v20.txt, 16179.v22.txt, 16179.v23.txt, 16179.v24.txt, > 16179.v25.txt, 16179.v26.txt, 16179.v4.txt, 16179.v5.txt, 16179.v7.txt, > 16179.v8.txt, 16179.v9.txt > > > I tried building hbase-spark module against Spark-2.0 snapshot and got the > following compilation errors: > http://pastebin.com/bg3w247a > Some Spark classes such as DataTypeParser and Logging are no longer > accessible to downstream projects. > hbase-spark module should not depend on such classes. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17812) Remove RpcConnection from pool in AbstractRpcClient.cancelConnections
[
https://issues.apache.org/jira/browse/HBASE-17812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15932802#comment-15932802
]
Hadoop QA commented on HBASE-17812:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 15s
{color} | {color:blue} Docker mode activated. {color} |
| {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
21s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 18s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
24s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
10s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
56s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 17s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
18s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 20s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 20s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
26s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
9s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
30m 16s {color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha2. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 4s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 17s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m 19s
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
7s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 41m 14s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.11.2 Server=1.11.2 Image:yetus/hbase:8d52d23 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12859557/HBASE-17812.patch |
| JIRA Issue | HBASE-17812 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux 60474e83d30c 3.13.0-103-generic #150-Ubuntu SMP Thu Nov 24
10:34:17 UTC 2016 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 / 5b4bb82 |
| Default Java | 1.8.0_121 |
| findbugs | v3.0.0 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/6162/testReport/ |
| modules | C: hbase-client U: hbase-client |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/6162/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> Remove RpcConnection from pool in AbstractRpcClient.cancelConnections
> -
>
> Key: HBASE-17812
> URL: https://issues.apache.org/jira/browse/HBASE-17812
> Project: HBase
> Issue Type: Bug
> Components: Client, rpc
>Affects Versions:
[jira] [Updated] (HBASE-17669) Implement async mergeRegion/splitRegion methods.
[ https://issues.apache.org/jira/browse/HBASE-17669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-17669: - Attachment: HBASE-17669.v5.patch patch v5: 1. use Bytes.toBytes instead of xx.getBytes() 2. introduce a new private method named checkRegionsAndGetTableName to save local variables. 3. use CompletableFuture.allOf to save code. > Implement async mergeRegion/splitRegion methods. > > > Key: HBASE-17669 > URL: https://issues.apache.org/jira/browse/HBASE-17669 > Project: HBase > Issue Type: Sub-task > Components: Admin, asyncclient, Client >Affects Versions: 2.0.0 >Reporter: Zheng Hu >Assignee: Zheng Hu > Fix For: 2.0.0 > > Attachments: HBASE-17669.v1.patch, HBASE-17669.v2.patch, > HBASE-17669.v3.patch, HBASE-17669.v3.patch, HBASE-17669.v4.patch, > HBASE-17669.v5.patch > > > RT -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17809) cleanup unused class
[ https://issues.apache.org/jira/browse/HBASE-17809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai updated HBASE-17809: --- Status: Patch Available (was: Open) > cleanup unused class > > > Key: HBASE-17809 > URL: https://issues.apache.org/jira/browse/HBASE-17809 > Project: HBase > Issue Type: Sub-task >Affects Versions: 2.0.0 >Reporter: Chia-Ping Tsai >Assignee: Chia-Ping Tsai > Fix For: 2.0.0 > > Attachments: HBASE-17809.v0.patch > > > inspired by HBASE-17805. We had left a lot of orphan class due to a bunch of > commits. We shall remove them. > ||class||last meeting||why||line count| > |LruHashMap|HBASE-1822|get rid of|1100| > |ScannerTimeoutException|HBASE-16266|get rid of|45| > |SortedCopyOnWriteSet|HBASE-12748|get rid of|178| > |TestSortedCopyOnWriteSet|HBASE-12748|get rid of|107| > |DelegatingRetryingCallable|HBASE-9049|create but never used|65| > |LockTimeoutException|HBASE-16786|get rid of|44| > |OperationConflictException|HBASE-9899|get rid of|50| > |InvalidQuotaSettingsException|HBASE-11598|create but never used|33| > |ShareableMemory|HBASE-15735|get rid of|40| > |BoundedArrayQueue|HBASE-14860|get rid of|82| > |TestBoundedArrayQueue|HBASE-14860|get rid of|61| > |ChecksumFactory|HBASE-11927|get rid of|100| > |TokenDepthComparator|HBASE-4676|create but never used|65| > |RegionMergeTransaction|HBASE-17470|get rid of|249| > |MetaUtils|HBASE-1822|get rid of|156| -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17809) cleanup unused class
[ https://issues.apache.org/jira/browse/HBASE-17809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai updated HBASE-17809: --- Attachment: HBASE-17809.v0.patch > cleanup unused class > > > Key: HBASE-17809 > URL: https://issues.apache.org/jira/browse/HBASE-17809 > Project: HBase > Issue Type: Sub-task >Affects Versions: 2.0.0 >Reporter: Chia-Ping Tsai >Assignee: Chia-Ping Tsai > Fix For: 2.0.0 > > Attachments: HBASE-17809.v0.patch > > > inspired by HBASE-17805. We had left a lot of orphan class due to a bunch of > commits. We shall remove them. > ||class||last meeting||why||line count| > |LruHashMap|HBASE-1822|get rid of|1100| > |ScannerTimeoutException|HBASE-16266|get rid of|45| > |SortedCopyOnWriteSet|HBASE-12748|get rid of|178| > |TestSortedCopyOnWriteSet|HBASE-12748|get rid of|107| > |DelegatingRetryingCallable|HBASE-9049|create but never used|65| > |LockTimeoutException|HBASE-16786|get rid of|44| > |OperationConflictException|HBASE-9899|get rid of|50| > |InvalidQuotaSettingsException|HBASE-11598|create but never used|33| > |ShareableMemory|HBASE-15735|get rid of|40| > |BoundedArrayQueue|HBASE-14860|get rid of|82| > |TestBoundedArrayQueue|HBASE-14860|get rid of|61| > |ChecksumFactory|HBASE-11927|get rid of|100| > |TokenDepthComparator|HBASE-4676|create but never used|65| > |RegionMergeTransaction|HBASE-17470|get rid of|249| > |MetaUtils|HBASE-1822|get rid of|156| -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17655) Removing MemStoreScanner and SnapshotScanner
[ https://issues.apache.org/jira/browse/HBASE-17655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eshcar Hillel updated HBASE-17655: -- Attachment: HBASE-17655-V08.patch > Removing MemStoreScanner and SnapshotScanner > > > Key: HBASE-17655 > URL: https://issues.apache.org/jira/browse/HBASE-17655 > Project: HBase > Issue Type: Improvement > Components: Scanners >Affects Versions: 2.0.0 >Reporter: Eshcar Hillel >Assignee: Eshcar Hillel > Attachments: HBASE-17655-V01.patch, HBASE-17655-V02.patch, > HBASE-17655-V03.patch, HBASE-17655-V04.patch, HBASE-17655-V05.patch, > HBASE-17655-V05.patch, HBASE-17655-V06.patch, HBASE-17655-V07.patch, > HBASE-17655-V08.patch > > > With CompactingMemstore becoming the new default, a store comprises multiple > memory segments and not just 1-2. MemStoreScanner encapsulates the scanning > of segments in the memory part of the store. SnapshotScanner is used to scan > the snapshot segment upon flush to disk. > Having the logic of scanners scattered in multiple classes (StoreScanner, > SegmentScanner, MemStoreScanner, SnapshotScanner) makes maintainance and > debugging challenging tasks, not always for a good reason. > For example, MemStoreScanner has a KeyValueHeap (KVH). When creating the > store scanner which also has a KVH, this makes a KVH inside a KVH. Reasoning > about the correctness of the methods supported by the scanner (seek, next, > hasNext, peek, etc.) is hard and debugging them is cumbersome. > In addition, by removing the MemStoreScanner layer we allow store scanner to > filter out each one of the memory scanners instead of either taking them all > (in most cases) or discarding them all (rarely). > SnapshotScanner is a simplified version of SegmentScanner as it is used only > in a specific context. However it is an additional implementation of the same > logic with no real advantage of improved performance. > Therefore, I suggest removing both MemStoreScanner and SnapshotScanner. The > code is adjusted to handle the list of segment scanners they encapsulate. > This fits well with the current code since in most cases at some point a list > of scanner is expected, so passing the actual list of segment scanners is > more natural than wrapping a single (high level) scanner with > Collections.singeltonList(...). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17812) Remove RpcConnection from pool in AbstractRpcClient.cancelConnections
[ https://issues.apache.org/jira/browse/HBASE-17812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-17812: -- Status: Patch Available (was: Open) > Remove RpcConnection from pool in AbstractRpcClient.cancelConnections > - > > Key: HBASE-17812 > URL: https://issues.apache.org/jira/browse/HBASE-17812 > Project: HBase > Issue Type: Bug > Components: Client, rpc >Affects Versions: 2.0.0 >Reporter: Duo Zhang >Assignee: Duo Zhang > Labels: trivial > Fix For: 2.0.0 > > Attachments: HBASE-17812.patch > > > Found it when backporting the new rpc implementation to branch-1 in > HBASE-16584. It will cause TestHCM fail on branch-1 as on branch-1 the > default rpc implementation is BlockingRpcClient which is not always > reconnectable after shutdown. On master TestHCM will not fail as > NettyRpcConnection is always reconnectable. But we still need to fix it as it > is a bug. Only a trivial one line patch. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17812) Remove RpcConnection from pool in AbstractRpcClient.cancelConnections
[ https://issues.apache.org/jira/browse/HBASE-17812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-17812: -- Attachment: HBASE-17812.patch > Remove RpcConnection from pool in AbstractRpcClient.cancelConnections > - > > Key: HBASE-17812 > URL: https://issues.apache.org/jira/browse/HBASE-17812 > Project: HBase > Issue Type: Bug > Components: Client, rpc >Affects Versions: 2.0.0 >Reporter: Duo Zhang >Assignee: Duo Zhang > Labels: trivial > Fix For: 2.0.0 > > Attachments: HBASE-17812.patch > > > Found it when backporting the new rpc implementation to branch-1 in > HBASE-16584. It will cause TestHCM fail on branch-1 as on branch-1 the > default rpc implementation is BlockingRpcClient which is not always > reconnectable after shutdown. On master TestHCM will not fail as > NettyRpcConnection is always reconnectable. But we still need to fix it as it > is a bug. Only a trivial one line patch. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
