[jira] [Commented] (HBASE-22072) High read/write intensive regions may cause long crash recovery
[ https://issues.apache.org/jira/browse/HBASE-22072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808390#comment-16808390 ] ramkrishna.s.vasudevan commented on HBASE-22072: May be we should have a lock for closing and the updateReader() should try to get that lock before trying to update the scanners? If already closing is done then don't do it? > High read/write intensive regions may cause long crash recovery > --- > > Key: HBASE-22072 > URL: https://issues.apache.org/jira/browse/HBASE-22072 > Project: HBase > Issue Type: Bug > Components: Performance, Recovery >Affects Versions: 2.1.2 >Reporter: Pavel >Priority: Major > > Compaction of high read loaded region may leave compacted files undeleted > because of existing scan references: > INFO org.apache.hadoop.hbase.regionserver.HStore - Can't archive compacted > file hdfs://hdfs-ha/hbase... because of either isCompactedAway=true or file > has reference, isReferencedInReads=true, refCount=1, skipping for now > If region is either high write loaded this happens quite often and region may > have few storefiles and tons of undeleted compacted hdfs files. > Region keeps all that files (in my case thousands) untill graceful region > closing procedure, which ignores existing references and drop obsolete files. > It works fine unless consuming some extra hdfs space, but only in case of > normal region closing. If region server crashes than new region server, > responsible for that overfiling region, reads hdfs folder and try to deal > with all undeleted files, producing tons of storefiles, compaction tasks and > consuming abnormal amount of memory, wich may lead to OutOfMemory Exception > and further region servers crash. This stops writing to region because number > of storefiles reach *hbase.hstore.blockingStoreFiles* limit, forces high GC > duty and may take hours to compact all files into working set of files. > Workaround is a periodically check hdfs folders files count and force region > assign for ones with too many files. > It could be nice if regionserver had a setting similar to > hbase.hstore.blockingStoreFiles and invoke attempt to drop undeleted > compacted files if number of files reaches this setting. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (HBASE-21903) Backport major compaction tool HBASE-19528 from to 1.4 and 1.3
[ https://issues.apache.org/jira/browse/HBASE-21903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808363#comment-16808363 ] Francis Liu edited comment on HBASE-21903 at 4/3/19 4:49 AM: - [~busbey] are you suggesting we create a branch-1 in operator tools and put this in there? It seems more intuitive to keep this in the hbase repo given that this tool is already in branch-1.5? was (Author: toffer): [~busbey] are you suggesting we create a branch-1 in operator tools and put this in there? > Backport major compaction tool HBASE-19528 from to 1.4 and 1.3 > -- > > Key: HBASE-21903 > URL: https://issues.apache.org/jira/browse/HBASE-21903 > Project: HBase > Issue Type: Task > Components: Client, Compaction, tooling >Affects Versions: 1.3.3, 1.4.9 >Reporter: Thiruvel Thirumoolan >Assignee: Thiruvel Thirumoolan >Priority: Major > Fix For: 1.4.10, 1.3.4 > > Attachments: HBASE-21903-branch-1.3-addendum.patch > > > Our internal deployments are based on branch-1.3. We will be using the major > compaction tool HBASE-19528 from [~churromorales] and the enhancements on top > of it HBASE-21883 on our 1.3 clusters. I would like to backport HBASE-19528 > to 1.3 and hence 1.4 as well. Since its a standalone tool without any other > dependency or code changes, I believe that should be ok. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21903) Backport major compaction tool HBASE-19528 from to 1.4 and 1.3
[ https://issues.apache.org/jira/browse/HBASE-21903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808363#comment-16808363 ] Francis Liu commented on HBASE-21903: - [~busbey] are you suggesting we create a branch-1 in operator tools and put this in there? > Backport major compaction tool HBASE-19528 from to 1.4 and 1.3 > -- > > Key: HBASE-21903 > URL: https://issues.apache.org/jira/browse/HBASE-21903 > Project: HBase > Issue Type: Task > Components: Client, Compaction, tooling >Affects Versions: 1.3.3, 1.4.9 >Reporter: Thiruvel Thirumoolan >Assignee: Thiruvel Thirumoolan >Priority: Major > Fix For: 1.4.10, 1.3.4 > > Attachments: HBASE-21903-branch-1.3-addendum.patch > > > Our internal deployments are based on branch-1.3. We will be using the major > compaction tool HBASE-19528 from [~churromorales] and the enhancements on top > of it HBASE-21883 on our 1.3 clusters. I would like to backport HBASE-19528 > to 1.3 and hence 1.4 as well. Since its a standalone tool without any other > dependency or code changes, I believe that should be ok. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22155) Move 2.2.0 on to hbase-thirdparty-2.2.0
[
https://issues.apache.org/jira/browse/HBASE-22155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808357#comment-16808357
]
Hadoop QA commented on HBASE-22155:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
0s{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 10s{color}
| {color:red} HBASE-22155 does not apply to 2. Rebase required? Wrong Branch?
See https://yetus.apache.org/documentation/0.8.0/precommit-patchnames for help.
{color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HBASE-22155 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12964658/HBASE-22155.branch-2.2.001.patch
|
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/16623/console |
| Powered by | Apache Yetus 0.8.0 http://yetus.apache.org |
This message was automatically generated.
> Move 2.2.0 on to hbase-thirdparty-2.2.0
> ---
>
> Key: HBASE-22155
> URL: https://issues.apache.org/jira/browse/HBASE-22155
> Project: HBase
> Issue Type: Sub-task
> Components: thirdparty
>Reporter: stack
>Assignee: stack
>Priority: Major
> Fix For: 3.0.0, 2.2.0
>
> Attachments: HBASE-22155.branch-2.2.001.patch
>
>
> hbase-thirdparty-2.2.0 was just released. The 2.2.0 RM ([~zghaobac]) gave his
> blessing in parent issue that 2.2.0 should use thirdparty 2.2.0.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-22155) Move 2.2.0 on to hbase-thirdparty-2.2.0
[ https://issues.apache.org/jira/browse/HBASE-22155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-22155: -- Fix Version/s: 3.0.0 > Move 2.2.0 on to hbase-thirdparty-2.2.0 > --- > > Key: HBASE-22155 > URL: https://issues.apache.org/jira/browse/HBASE-22155 > Project: HBase > Issue Type: Sub-task > Components: thirdparty >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 3.0.0, 2.2.0 > > Attachments: HBASE-22155.branch-2.2.001.patch > > > hbase-thirdparty-2.2.0 was just released. The 2.2.0 RM ([~zghaobac]) gave his > blessing in parent issue that 2.2.0 should use thirdparty 2.2.0. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22155) Move 2.2.0 on to hbase-thirdparty-2.2.0
[ https://issues.apache.org/jira/browse/HBASE-22155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-22155: -- Status: Patch Available (was: Open) Running via hadoopqa just in case. > Move 2.2.0 on to hbase-thirdparty-2.2.0 > --- > > Key: HBASE-22155 > URL: https://issues.apache.org/jira/browse/HBASE-22155 > Project: HBase > Issue Type: Sub-task > Components: thirdparty >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 2.2.0 > > Attachments: HBASE-22155.branch-2.2.001.patch > > > hbase-thirdparty-2.2.0 was just released. The 2.2.0 RM ([~zghaobac]) gave his > blessing in parent issue that 2.2.0 should use thirdparty 2.2.0. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22155) Move 2.2.0 on to hbase-thirdparty-2.2.0
[ https://issues.apache.org/jira/browse/HBASE-22155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-22155: -- Attachment: HBASE-22155.branch-2.2.001.patch > Move 2.2.0 on to hbase-thirdparty-2.2.0 > --- > > Key: HBASE-22155 > URL: https://issues.apache.org/jira/browse/HBASE-22155 > Project: HBase > Issue Type: Sub-task > Components: thirdparty >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 2.2.0 > > Attachments: HBASE-22155.branch-2.2.001.patch > > > hbase-thirdparty-2.2.0 was just released. The 2.2.0 RM ([~zghaobac]) gave his > blessing in parent issue that 2.2.0 should use thirdparty 2.2.0. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-22155) Move 2.2.0 on to hbase-thirdparty-2.2.0
stack created HBASE-22155: - Summary: Move 2.2.0 on to hbase-thirdparty-2.2.0 Key: HBASE-22155 URL: https://issues.apache.org/jira/browse/HBASE-22155 Project: HBase Issue Type: Sub-task Components: thirdparty Reporter: stack Assignee: stack Fix For: 2.2.0 hbase-thirdparty-2.2.0 was just released. The 2.2.0 RM ([~zghaobac]) gave his blessing in parent issue that 2.2.0 should use thirdparty 2.2.0. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (HBASE-22136) [hbase-thirdparty] Push out 2.2.0 release
[ https://issues.apache.org/jira/browse/HBASE-22136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-22136. --- Resolution: Fixed Fix Version/s: thirdparty-2.2.0 Resolving. Just pushed out 2.2.0 thirdparty. Tagged it w/ rel/2.2.0. "We've just made a new release of the Apache HBase Thirdparty project. This project is used by the Apache HBase project to encapsulate a number of core dependencies that HBase relies upon ensuring that they are properly isolated from HBase downstream users, e.g. Google Protocol Buffers, Google Guava, and a few others. This 2.2.0 release contains a number of updates in support of the upcoming Apache HBase 2.2.0 release. The release is available as source at dist.apache.org[1] and as artifacts up in Maven central[2]. Release notes and Changes can be found at [1]. The release was tagged rel/2.2.0. It was signed with my key 'st...@duboce.net' which can be found here: https://dist.apache.org/repos/dist/release/hbase/KEYS - Your Release Manager [1] https://dist.apache.org/repos/dist/release/hbase/hbase-thirdparty-2.2.0/ [2] https://repository.apache.org/service/local/repositories/releases/content/org/apache/hbase/thirdparty/hbase-thirdparty/2.2.0/ " > [hbase-thirdparty] Push out 2.2.0 release > - > > Key: HBASE-22136 > URL: https://issues.apache.org/jira/browse/HBASE-22136 > Project: HBase > Issue Type: Sub-task > Components: rm >Affects Versions: 2.2.0 >Reporter: stack >Assignee: stack >Priority: Major > Fix For: thirdparty-2.2.0 > > > FYI [~zghaobac] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (HBASE-22154) Facing issue with HA of HBase
[ https://issues.apache.org/jira/browse/HBASE-22154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allan Yang resolved HBASE-22154. Resolution: Not A Problem > Facing issue with HA of HBase > - > > Key: HBASE-22154 > URL: https://issues.apache.org/jira/browse/HBASE-22154 > Project: HBase > Issue Type: Test >Reporter: James >Priority: Critical > Labels: /hbase-1.2.6.1 > > Hi Team, > I have set up HA Hadoop cluster and same for HBase. > When my Active name node is going down, Stand by name node is becoming active > name node however as same time my backup hbase master is not becoming active > HMaster(Active HMaster and Region server goes down). > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22154) Facing issue with HA of HBase
[ https://issues.apache.org/jira/browse/HBASE-22154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808349#comment-16808349 ] Allan Yang commented on HBASE-22154: Please send a E-mail to u...@hbase.apache.org to address your question so more people can help you. Jira is a place to file issue, not to ask questions. Thank you very much. > Facing issue with HA of HBase > - > > Key: HBASE-22154 > URL: https://issues.apache.org/jira/browse/HBASE-22154 > Project: HBase > Issue Type: Test >Reporter: James >Priority: Critical > Labels: /hbase-1.2.6.1 > > Hi Team, > I have set up HA Hadoop cluster and same for HBase. > When my Active name node is going down, Stand by name node is becoming active > name node however as same time my backup hbase master is not becoming active > HMaster(Active HMaster and Region server goes down). > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22154) Facing issue with HA of HBase
[ https://issues.apache.org/jira/browse/HBASE-22154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808347#comment-16808347 ] Reid Chan commented on HBASE-22154: --- I'll recommend emailing to user at hbase.apache.org at first, this doesn't quite suit JIRA, IMO. > Facing issue with HA of HBase > - > > Key: HBASE-22154 > URL: https://issues.apache.org/jira/browse/HBASE-22154 > Project: HBase > Issue Type: Test >Reporter: James >Priority: Critical > Labels: /hbase-1.2.6.1 > > Hi Team, > I have set up HA Hadoop cluster and same for HBase. > When my Active name node is going down, Stand by name node is becoming active > name node however as same time my backup hbase master is not becoming active > HMaster(Active HMaster and Region server goes down). > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22153) Fix the flaky TestRestartCluster
[ https://issues.apache.org/jira/browse/HBASE-22153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-22153: - Description: I guess it's related to HBASE-21565 or HBASE-21588 Log can be see here: https://builds.apache.org/job/HBase-Flaky-Tests/job/master/2902/artifact/hbase-server/target/surefire-reports/org.apache.hadoop.hbase.master.TestRestartCluster-output.txt was:I guess it's related to HBASE-21565 or HBASE-21588 > Fix the flaky TestRestartCluster > > > Key: HBASE-22153 > URL: https://issues.apache.org/jira/browse/HBASE-22153 > Project: HBase > Issue Type: Sub-task >Reporter: Zheng Hu >Assignee: Zheng Hu >Priority: Major > > I guess it's related to HBASE-21565 or HBASE-21588 > Log can be see here: > https://builds.apache.org/job/HBase-Flaky-Tests/job/master/2902/artifact/hbase-server/target/surefire-reports/org.apache.hadoop.hbase.master.TestRestartCluster-output.txt -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22154) Facing issue with HA of HBase
[ https://issues.apache.org/jira/browse/HBASE-22154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James updated HBASE-22154: -- Labels: /hbase-1.2.6.1 (was: ) > Facing issue with HA of HBase > - > > Key: HBASE-22154 > URL: https://issues.apache.org/jira/browse/HBASE-22154 > Project: HBase > Issue Type: Test >Reporter: James >Priority: Critical > Labels: /hbase-1.2.6.1 > > Hi Team, > I have set up HA Hadoop cluster and same for HBase. > When my Active name node is going down, Stand by name node is becoming active > name node however as same time my backup hbase master is not becoming active > HMaster(Active HMaster and Region server goes down). > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22154) Facing issue with HA of HBase
[
https://issues.apache.org/jira/browse/HBASE-22154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808344#comment-16808344
]
James commented on HBASE-22154:
---
In second log we are observing below error
{code}
ATAL org.apache.hadoop.hbase.master.HMaster - Failed to become active master
org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.ipc.StandbyException):
Operation category READ is not supported in state standby. Visit
{code}
> Facing issue with HA of HBase
> -
>
> Key: HBASE-22154
> URL: https://issues.apache.org/jira/browse/HBASE-22154
> Project: HBase
> Issue Type: Test
>Reporter: James
>Priority: Critical
>
> Hi Team,
> I have set up HA Hadoop cluster and same for HBase.
> When my Active name node is going down, Stand by name node is becoming active
> name node however as same time my backup hbase master is not becoming active
> HMaster(Active HMaster and Region server goes down).
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22154) Facing issue with HA of HBase
[ https://issues.apache.org/jira/browse/HBASE-22154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808345#comment-16808345 ] James commented on HBASE-22154: --- Please let us know if there is something wrong with config or something else. > Facing issue with HA of HBase > - > > Key: HBASE-22154 > URL: https://issues.apache.org/jira/browse/HBASE-22154 > Project: HBase > Issue Type: Test >Reporter: James >Priority: Critical > > Hi Team, > I have set up HA Hadoop cluster and same for HBase. > When my Active name node is going down, Stand by name node is becoming active > name node however as same time my backup hbase master is not becoming active > HMaster(Active HMaster and Region server goes down). > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22154) Facing issue with HA of HBase
[
https://issues.apache.org/jira/browse/HBASE-22154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808342#comment-16808342
]
James commented on HBASE-22154:
---
In first log message, We are observing
{code}
java.io.IOException: Can't get master address from ZooKeeper; znode data == null
org.apache.hadoop.hbase.client.RetriesExhaustedException: Failed after
attempts=1, exceptions:
{code}
> Facing issue with HA of HBase
> -
>
> Key: HBASE-22154
> URL: https://issues.apache.org/jira/browse/HBASE-22154
> Project: HBase
> Issue Type: Test
>Reporter: James
>Priority: Critical
>
> Hi Team,
> I have set up HA Hadoop cluster and same for HBase.
> When my Active name node is going down, Stand by name node is becoming active
> name node however as same time my backup hbase master is not becoming active
> HMaster(Active HMaster and Region server goes down).
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22154) Facing issue with HA of HBase
[
https://issues.apache.org/jira/browse/HBASE-22154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808341#comment-16808341
]
James commented on HBASE-22154:
---
Another logs
{code}
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=128m;
support was removed in 8.0
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=128m;
support was removed in 8.0
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in
[jar:file:/home/hadoop/hbase/hbase-1.2.6.1/lib/phoenix-4.13.1-HBase-1.2-client.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in
[jar:file:/home/hadoop/hbase/hbase-1.2.6.1/lib/phoenix-4.13.1-HBase-1.2-hive.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in
[jar:file:/home/hadoop/hbase/hbase-1.2.6.1/lib/phoenix-4.13.1-HBase-1.2-pig.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in
[jar:file:/home/hadoop/hbase/hbase-1.2.6.1/lib/phoenix-4.13.1-HBase-1.2-thin-client.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in
[jar:file:/home/hadoop/hbase/hbase-1.2.6.1/lib/slf4j-log4j12-1.7.5.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in
[jar:file:/home/hadoop/hadoop-2.9.0/share/hadoop/common/lib/slf4j-log4j12-1.7.25.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
3 [StandbyHbase:16000.activeMasterManager] FATAL
org.apache.hadoop.hbase.master.HMaster - Failed to become active master
org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.ipc.StandbyException):
Operation category READ is not supported in state standby. Visit
https://s.apache.org/sbnn-error
at
org.apache.hadoop.hdfs.server.namenode.ha.StandbyState.checkOperation(StandbyState.java:88)
at
org.apache.hadoop.hdfs.server.namenode.NameNode$NameNodeHAContext.checkOperation(NameNode.java:1983)
at
org.apache.hadoop.hdfs.server.namenode.FSNamesystem.checkOperation(FSNamesystem.java:1382)
at
org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getFileInfo(FSNamesystem.java:2934)
at
org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.getFileInfo(NameNodeRpcServer.java:1124)
at
org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolServerSideTranslatorPB.getFileInfo(ClientNamenodeProtocolServerSideTranslatorPB.java:873)
at
org.apache.hadoop.hdfs.protocol.proto.ClientNamenodeProtocolProtos$ClientNamenodeProtocol$2.callBlockingMethod(ClientNamenodeProtocolProtos.java)
at
org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:503)
at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:989)
at org.apache.hadoop.ipc.Server$RpcCall.run(Server.java:868)
at org.apache.hadoop.ipc.Server$RpcCall.run(Server.java:814)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:422)
at
org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1886)
at org.apache.hadoop.ipc.Server$Handler.run(Server.java:2603)
at org.apache.hadoop.ipc.Client.call(Client.java:1411)
at org.apache.hadoop.ipc.Client.call(Client.java:1364)
at
org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:206)
at com.sun.proxy.$Proxy15.getFileInfo(Unknown Source)
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.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:187)
at
org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:102)
at com.sun.proxy.$Proxy15.getFileInfo(Unknown Source)
at
org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolTranslatorPB.getFileInfo(ClientNamenodeProtocolTranslatorPB.java:707)
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.apache.hadoop.hbase.fs.HFileSystem$1.invoke(HFileSystem.java:279)
at com.sun.proxy.$Proxy16.getFileInfo(Unknown Source)
at org.apache.hadoop.hdfs.DFSClient.getFileInfo(DFSClient.java:1785)
at
org.apache.hadoop.hdfs.DistributedFileSystem$17.doCall(DistributedFileSystem.java:1068)
at
org.apache.hadoop.hdfs.DistributedFileSystem$17.doCall(DistributedFileSystem.java:1064)
at
org.apache.hadoop.fs.FileSystemLinkResolver.resolve(FileSystemLinkResolver.java:81)
at
org.apache.hadoop.hdfs.DistributedFileSystem.getFileStatus(DistributedFileSystem.java:1064)
at org.apache.hadoop.fs.FileSystem.exists(FileSystem.java:1398)
at
[jira] [Commented] (HBASE-22154) Facing issue with HA of HBase
[
https://issues.apache.org/jira/browse/HBASE-22154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808340#comment-16808340
]
James commented on HBASE-22154:
---
I am getting below error
{code}
/home/hadoop/hbase/hbase-1.2.6.1/bin/hbase-daemon.sh: line 226: 125348 Killed
nice -n $HBASE_NICENESS "$HBASE_HOME"/bin/hbase --config "${HBASE_CONF_DIR}"
$command "$@" start >> ${HBASE_LOGOUT} 2>&1
nding in
[jar:file:/home/hadoop/hbase/hbase-1.2.6.1/lib/phoenix-4.13.1-HBase-1.2-hive.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in
[jar:file:/home/hadoop/hbase/hbase-1.2.6.1/lib/phoenix-4.13.1-HBase-1.2-pig.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in
[jar:file:/home/hadoop/hbase/hbase-1.2.6.1/lib/phoenix-4.13.1-HBase-1.2-thin-client.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in
[jar:file:/home/hadoop/hbase/hbase-1.2.6.1/lib/slf4j-log4j12-1.7.5.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in
[jar:file:/home/hadoop/hadoop-2.9.0/share/hadoop/common/lib/slf4j-log4j12-1.7.25.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
0 [main] ERROR org.apache.hadoop.hbase.master.HMasterCommandLine - Got
IOException: Failed after attempts=1, exceptions:
Sun Mar 24 20:48:33 IST 2019, RpcRetryingCaller\{globalStartTime=1553440713743,
pause=100, retries=1}, org.apache.hadoop.hbase.MasterNotRunningException:
java.io.IOException: Can't get master address from ZooKeeper; znode data == null
org.apache.hadoop.hbase.client.RetriesExhaustedException: Failed after
attempts=1, exceptions:
Sun Mar 24 20:48:33 IST 2019, RpcRetryingCaller\{globalStartTime=1553440713743,
pause=100, retries=1}, org.apache.hadoop.hbase.MasterNotRunningException:
java.io.IOException: Can't get master address from ZooKeeper; znode data == null
at
org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithRetries(RpcRetryingCaller.java:157)
at
org.apache.hadoop.hbase.client.HBaseAdmin.executeCallable(HBaseAdmin.java:4297)
at
org.apache.hadoop.hbase.client.HBaseAdmin.executeCallable(HBaseAdmin.java:4289)
at org.apache.hadoop.hbase.client.HBaseAdmin.shutdown(HBaseAdmin.java:2856)
at
org.apache.hadoop.hbase.master.HMasterCommandLine.stopMaster(HMasterCommandLine.java:256)
at
org.apache.hadoop.hbase.master.HMasterCommandLine.run(HMasterCommandLine.java:139)
at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:70)
at
org.apache.hadoop.hbase.util.ServerCommandLine.doMain(ServerCommandLine.java:126)
at org.apache.hadoop.hbase.master.HMaster.main(HMaster.java:2522)
Caused by: org.apache.hadoop.hbase.MasterNotRunningException:
java.io.IOException: Can't get master address from ZooKeeper; znode data == null
at
org.apache.hadoop.hbase.client.ConnectionManager$HConnectionImplementation$StubMaker.makeStub(ConnectionManager.java:1561)
at
org.apache.hadoop.hbase.client.ConnectionManager$HConnectionImplementation$MasterServiceStubMaker.makeStub(ConnectionManager.java:1581)
at
org.apache.hadoop.hbase.client.ConnectionManager$HConnectionImplementation.getKeepAliveMasterService(ConnectionManager.java:1738)
at
org.apache.hadoop.hbase.client.MasterCallable.prepare(MasterCallable.java:38)
at
org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithRetries(RpcRetryingCaller.java:134)
... 8 more
Caused by: java.io.IOException: Can't get master address from ZooKeeper; znode
data == null
at
org.apache.hadoop.hbase.zookeeper.MasterAddressTracker.getMasterAddress(MasterAddressTracker.java:154)
at
org.apache.hadoop.hbase.client.ConnectionManager$HConnectionImplementation$StubMaker.makeStubNoRetries(ConnectionManager.java:1511)
at
org.apache.hadoop.hbase.client.ConnectionManager$HConnectionImplementation$StubMaker.makeStub(ConnectionManager.java:1552)
{code}
> Facing issue with HA of HBase
> -
>
> Key: HBASE-22154
> URL: https://issues.apache.org/jira/browse/HBASE-22154
> Project: HBase
> Issue Type: Test
>Reporter: James
>Priority: Critical
>
> Hi Team,
> I have set up HA Hadoop cluster and same for HBase.
> When my Active name node is going down, Stand by name node is becoming active
> name node however as same time my backup hbase master is not becoming active
> HMaster(Active HMaster and Region server goes down).
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HBASE-22154) Facing issue with HA of HBase
James created HBASE-22154: - Summary: Facing issue with HA of HBase Key: HBASE-22154 URL: https://issues.apache.org/jira/browse/HBASE-22154 Project: HBase Issue Type: Test Reporter: James Hi Team, I have set up HA Hadoop cluster and same for HBase. When my Active name node is going down, Stand by name node is becoming active name node however as same time my backup hbase master is not becoming active HMaster(Active HMaster and Region server goes down). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22153) Fix the flaky TestRestartCluster
[ https://issues.apache.org/jira/browse/HBASE-22153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-22153: - Description: I guess it's related to HBASE-21565 or HBASE-21588 > Fix the flaky TestRestartCluster > > > Key: HBASE-22153 > URL: https://issues.apache.org/jira/browse/HBASE-22153 > Project: HBase > Issue Type: Sub-task >Reporter: Zheng Hu >Assignee: Zheng Hu >Priority: Major > > I guess it's related to HBASE-21565 or HBASE-21588 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-22153) Fix the flaky TestRestartCluster
Zheng Hu created HBASE-22153: Summary: Fix the flaky TestRestartCluster Key: HBASE-22153 URL: https://issues.apache.org/jira/browse/HBASE-22153 Project: HBase Issue Type: Sub-task Reporter: Zheng Hu Assignee: Zheng Hu -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22128) Move namespace region then master crashed make deadlock
[ https://issues.apache.org/jira/browse/HBASE-22128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bing Xiao updated HBASE-22128: -- Attachment: HBASE-22128-branch-2.1-v5.patch > Move namespace region then master crashed make deadlock > --- > > Key: HBASE-22128 > URL: https://issues.apache.org/jira/browse/HBASE-22128 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.5, 2.1.4 >Reporter: Bing Xiao >Assignee: Bing Xiao >Priority: Critical > Fix For: 2.0.6, 2.1.5 > > Attachments: HBASE-22128-branch-2.1-v1.patch, > HBASE-22128-branch-2.1-v2.patch, HBASE-22128-branch-2.1-v3.patch, > HBASE-22128-branch-2.1-v4.patch, HBASE-22128-branch-2.1-v5.patch > > > When move namespace region start unassign produre, after unassign procedure > finished namespace region will be offline. At the same time master crashed > then reboot will stuck, because master init is block by waiting namespace > table online ,at same time master init not finish so move region procedure > can not go on, make deadlock. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22128) Move namespace region then master crashed make deadlock
[ https://issues.apache.org/jira/browse/HBASE-22128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bing Xiao updated HBASE-22128: -- Attachment: (was: HBASE-22128-branch-2.1-v5.patch) > Move namespace region then master crashed make deadlock > --- > > Key: HBASE-22128 > URL: https://issues.apache.org/jira/browse/HBASE-22128 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.5, 2.1.4 >Reporter: Bing Xiao >Assignee: Bing Xiao >Priority: Critical > Fix For: 2.0.6, 2.1.5 > > Attachments: HBASE-22128-branch-2.1-v1.patch, > HBASE-22128-branch-2.1-v2.patch, HBASE-22128-branch-2.1-v3.patch, > HBASE-22128-branch-2.1-v4.patch > > > When move namespace region start unassign produre, after unassign procedure > finished namespace region will be offline. At the same time master crashed > then reboot will stuck, because master init is block by waiting namespace > table online ,at same time master init not finish so move region procedure > can not go on, make deadlock. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22149) HBOSS: A FileSystem implementation to provide HBase's required semantics
[ https://issues.apache.org/jira/browse/HBASE-22149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808315#comment-16808315 ] Allan Yang commented on HBASE-22149: Sorry, I still don't get the point of how to handle the atomic rename. Since the FileSystem provided by hadoop-aws (based on s3) does not provide atomic rename API. > HBOSS: A FileSystem implementation to provide HBase's required semantics > > > Key: HBASE-22149 > URL: https://issues.apache.org/jira/browse/HBASE-22149 > Project: HBase > Issue Type: New Feature > Components: Filesystem Integration >Reporter: Sean Mackrory >Assignee: Sean Mackrory >Priority: Critical > Attachments: HBASE-22149-hadoop.patch > > > (Have been using the name HBOSS for HBase / Object Store Semantics) > I've had some thoughts about how to solve the problem of running HBase on > object stores. There has been some thought in the past about adding the > required semantics to S3Guard, but I have some concerns about that. First, > it's mixing complicated solutions to different problems (bridging the gap > between a flat namespace and a hierarchical namespace vs. solving > inconsistency). Second, it's S3-specific, whereas other objects stores could > use virtually identical solutions. And third, we can't do things like atomic > renames in a true sense. There would have to be some trade-offs specific to > HBase's needs and it's better if we can solve that in an HBase-specific > module without mixing all that logic in with the rest of S3A. > Ideas to solve this above the FileSystem layer have been proposed and > considered (HBASE-20431, for one), and maybe that's the right way forward > long-term, but it certainly seems to be a hard problem and hasn't been done > yet. But I don't know enough of all the internal considerations to make much > of a judgment on that myself. > I propose a FileSystem implementation that wraps another FileSystem instance > and provides locking of FileSystem operations to ensure correct semantics. > Locking could quite possibly be done on the same ZooKeeper ensemble as an > HBase cluster already uses (I'm sure there are some performance > considerations here that deserve more attention). I've put together a > proof-of-concept on which I've tested some aspects of atomic renames and > atomic file creates. Both of these tests fail reliably on a naked s3a > instance. I've also done a small YCSB run against a small cluster to sanity > check other functionality and was successful. I will post the patch, and my > laundry list of things that still need work. The WAL is still placed on HDFS, > but the HBase root directory is otherwise on S3. > Note that my prototype is built on Hadoop's source tree right now. That's > purely for my convenience in putting it together quickly, as that's where I > mostly work. I actually think long-term, if this is accepted as a good > solution, it makes sense to live in HBase (or it's own repository). It only > depends on stable, public APIs in Hadoop and is targeted entirely at HBase's > needs, so it should be able to iterate on the HBase community's terms alone. > Another idea [~ste...@apache.org] proposed to me is that of an inode-based > FileSystem that keeps hierarchical metadata in a more appropriate store that > would allow the required transactions (maybe a special table in HBase could > provide that store itself for other tables), and stores the underlying files > with unique identifiers on S3. This allows renames to actually become fast > instead of just large atomic operations. It does however place a strong > dependency on the metadata store. I have not explored this idea much. My > current proof-of-concept has been pleasantly simple, so I think it's the > right solution unless it proves unable to provide the required performance > characteristics. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22151) hbase-backup should specify hadoop-hdfs-client version for Hadoop 3
[
https://issues.apache.org/jira/browse/HBASE-22151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wei-Chiu Chuang updated HBASE-22151:
Resolution: Invalid
Status: Resolved (was: Patch Available)
> hbase-backup should specify hadoop-hdfs-client version for Hadoop 3
> ---
>
> Key: HBASE-22151
> URL: https://issues.apache.org/jira/browse/HBASE-22151
> Project: HBase
> Issue Type: Bug
> Components: backuprestore
>Affects Versions: 2.0.0
> Environment: Hadoop 3.2.0
>Reporter: Wei-Chiu Chuang
>Assignee: Wei-Chiu Chuang
>Priority: Major
> Attachments: HBASE-22151.master.001.patch
>
>
> {code}
> mvn test -P runAllTests -fn -Dhadoop.profile=3.0 -Dhadoop-three.version=3.2.0
> -Dtest=TestIncrementalBackupWithBulkLoad
> {code}
>
> Despite hadoop 3 version is specified, the test always use hadoop-hdfs-client
> 3.0.3, and will fail on Hadoop 3.2.0 because it can't find a new class.
>
> {noformat}
> Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 709.323 s <<<
> FAILURE! - in org.apache.hadoop.hbase.backup.TestIncrementalBackupWithBulkLoad
> TestIncBackupDeleteTable(org.apache.hadoop.hbase.backup.TestIncrementalBackupWithBulkLoad)
> Time elapsed: 1.907 s <<< ERROR!
> java.lang.NoClassDefFoundError:
> org/apache/hadoop/hdfs/protocol/HdfsConstants$StoragePolicySatisfierMode
> Caused by: java.lang.ClassNotFoundException:
> org.apache.hadoop.hdfs.protocol.HdfsConstants$StoragePolicySatisfierMode{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22150) rssStub in HRegionServer is not thread safe and should not directly be used
[
https://issues.apache.org/jira/browse/HBASE-22150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808301#comment-16808301
]
Hadoop QA commented on HBASE-22150:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
16s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {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:orange}-0{color} | {color:orange} test4tests {color} | {color:orange}
0m 0s{color} | {color:orange} 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:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
12s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
37s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
2s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 3m
56s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
20s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
27s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
36s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
33s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m
33s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
0s{color} | {color:red} hbase-server: The patch generated 1 new + 70 unchanged
- 1 fixed = 71 total (was 71) {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} shadedjars {color} | {color:green} 3m
56s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
8m 9s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
36s{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:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}125m
54s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
24s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}163m 55s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b |
| JIRA Issue | HBASE-22150 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12964629/rssStub-is-not-thread-safe-hence-should-not-be-accessed-directly.patch
|
| Optional Tests | dupname asflicense javac javadoc unit findbugs
shadedjars hadoopcheck hbaseanti checkstyle compile |
| uname | Linux bd823e858983 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2
17:16:02 UTC 2018 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 / cd2374a7f0 |
| maven | version: Apache Maven 3.5.4
(1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) |
| Default Java | 1.8.0_181 |
| findbugs | v3.1.11 |
| checkstyle |
https://builds.apache.org/job/PreCommit-HBASE-Build/16619/artifact/patchprocess/diff-checkstyle-hbase-server.txt
|
| Test Results |
[jira] [Commented] (HBASE-22147) Integrate the github pull request with hadoop QA.
[ https://issues.apache.org/jira/browse/HBASE-22147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808286#comment-16808286 ] Duo Zhang commented on HBASE-22147: --- Create a sub task for creating the jenkinsfile for yetus. I think we can create a branch and try it. Once we are done, we can commit the jenkins file to master. > Integrate the github pull request with hadoop QA. > - > > Key: HBASE-22147 > URL: https://issues.apache.org/jira/browse/HBASE-22147 > Project: HBase > Issue Type: Umbrella >Reporter: Zheng Hu >Assignee: Zheng Hu >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-22152) Create a jenkins file for yetus to processing GitHub PR
Duo Zhang created HBASE-22152: - Summary: Create a jenkins file for yetus to processing GitHub PR Key: HBASE-22152 URL: https://issues.apache.org/jira/browse/HBASE-22152 Project: HBase Issue Type: Sub-task Components: build Reporter: Duo Zhang I think we can just copy the jenkinsfile from the hadoop project. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22147) Integrate the github pull request with hadoop QA.
[ https://issues.apache.org/jira/browse/HBASE-22147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-22147: -- Issue Type: Umbrella (was: Task) > Integrate the github pull request with hadoop QA. > - > > Key: HBASE-22147 > URL: https://issues.apache.org/jira/browse/HBASE-22147 > Project: HBase > Issue Type: Umbrella >Reporter: Zheng Hu >Assignee: Zheng Hu >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22108) Avoid passing null in Admin methods
[ https://issues.apache.org/jira/browse/HBASE-22108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-22108: -- Attachment: HBASE-22108-branch-2.patch > Avoid passing null in Admin methods > --- > > Key: HBASE-22108 > URL: https://issues.apache.org/jira/browse/HBASE-22108 > Project: HBase > Issue Type: Task > Components: Admin >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.2.0, 2.3.0 > > Attachments: HBASE-22108-branch-2.patch, HBASE-22108-branch-2.patch, > HBASE-22108-v1.patch, HBASE-22108.patch > > > For some methods we must pass null if we want specific behaviors, for > example, move region to a random server, split region without providing an > explicit split point, etc. > We should provide methods without some parameters so user do not need to pass > null. > So in the future users do not need to guess whether a method accept null > parameters, the answer is always no. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21883) Enhancements to Major Compaction tool from HBASE-19528
[ https://issues.apache.org/jira/browse/HBASE-21883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808270#comment-16808270 ] Thiruvel Thirumoolan commented on HBASE-21883: -- [~apurtell] I have a master patch up, pls let me know if you have any feedback, thanks! > Enhancements to Major Compaction tool from HBASE-19528 > -- > > Key: HBASE-21883 > URL: https://issues.apache.org/jira/browse/HBASE-21883 > Project: HBase > Issue Type: Improvement > Components: Client, Compaction, tooling >Reporter: Thiruvel Thirumoolan >Assignee: Thiruvel Thirumoolan >Priority: Minor > Fix For: 3.0.0, 2.3.0, 1.5.1 > > Attachments: HBASE-21883.branch-1.001.patch, > HBASE-21883.branch-1.002.patch, HBASE-21883.master.001.patch, > HBASE-21883.master.002.patch > > > I would like to add new compaction tools based on [~churromorales]'s tool at > HBASE-19528. > We internally have tools that pick and compact regions based on multiple > criteria. Since Rahul already has a version in community, we would like to > build on top of it instead of pushing yet another tool. > With this jira, I would like to add a tool which looks at regions beyond TTL > and compacts them in a rsgroup. We have time series data and those regions > will become dead after a while, so we compact those regions to save disk > space. We also merge those empty regions to reduce load, but that tool comes > later. > Will prep a patch for 2.x once 1.5 gets in. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22151) hbase-backup should specify hadoop-hdfs-client version for Hadoop 3
[
https://issues.apache.org/jira/browse/HBASE-22151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808254#comment-16808254
]
Hadoop QA commented on HBASE-22151:
---
| (/) *{color:green}+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:brown} Prechecks {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:orange}-0{color} | {color:orange} test4tests {color} | {color:orange}
0m 0s{color} | {color:orange} 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:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
9s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
34s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 3m
56s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
17s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
40s{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 {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} 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} shadedjars {color} | {color:green} 3m
57s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
7m 39s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
12s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 12m
46s{color} | {color:green} hbase-backup in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
11s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 38m 22s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b |
| JIRA Issue | HBASE-22151 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12964632/HBASE-22151.master.001.patch
|
| Optional Tests | dupname asflicense javac javadoc unit shadedjars
hadoopcheck xml compile |
| uname | Linux 6584f86611fd 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2
17:16:02 UTC 2018 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build@2/component/dev-support/hbase-personality.sh
|
| git revision | master / cd2374a7f0 |
| maven | version: Apache Maven 3.5.4
(1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) |
| Default Java | 1.8.0_181 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/16620/testReport/ |
| Max. process+thread count | 4629 (vs. ulimit of 1) |
| modules | C: hbase-backup U: hbase-backup |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/16620/console |
| Powered by | Apache Yetus 0.8.0 http://yetus.apache.org |
This message was automatically generated.
> hbase-backup should specify hadoop-hdfs-client version for Hadoop 3
> ---
>
> Key: HBASE-22151
> URL: https://issues.apache.org/jira/browse/HBASE-22151
> Project: HBase
> Issue Type: Bug
> Components: backuprestore
>Affects Versions: 2.0.0
> Environment: Hadoop 3.2.0
>Reporter: Wei-Chiu Chuang
>Assignee:
[jira] [Comment Edited] (HBASE-22149) HBOSS: A FileSystem implementation to provide HBase's required semantics
[
https://issues.apache.org/jira/browse/HBASE-22149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808248#comment-16808248
]
Sean Mackrory edited comment on HBASE-22149 at 4/3/19 12:22 AM:
{quote}This code does not seem deadlock-safe?{quote}
Thanks [~vrodionov]. You're quite right - there should be a copy of all the
paths put into a single array and then sorted. I thought I had done that, but
perhaps I'm thinking of another method or I lost it while cleaning up the patch.
{quote}I would add explicit close() method{quote}
I can certainly add that, but as of right now there's no code that will use it
since it's not already part of the RemoteIterator interface (an interface that
I'm not such a big fan of) so any use of it would be HBOSS-specific right now.
One area in which I would particularly appreciate review for safety is in
TreeLockManager.treeWriteLock and treeReadLock. As I said I'll be replacing the
while(true)s and Thread.sleeps with proper retry logic that can eventually
timeout, but I don't think that will change the overall structure of those
procedures. The idea is to safely obtain locks on the specific nodes in
question, but then also ensure they're not INSIDE another lock that someone
else already obtained, etc.
was (Author: mackrorysd):
>> This code does not seem deadlock-safe?
Thanks [~vrodionov]. You're quite right - there should be a copy of all the
paths put into a single array and then sorted. I thought I had done that, but
perhaps I'm thinking of another method or I lost it while cleaning up the patch.
>> I would add explicit close() method
I can certainly add that, but as of right now there's no code that will use it
since it's not already part of the RemoteIterator interface (an interface that
I'm not such a big fan of) so any use of it would be HBOSS-specific right now.
One area in which I would particularly appreciate review for safety is in
TreeLockManager.treeWriteLock and treeReadLock. As I said I'll be replacing the
while(true)s and Thread.sleeps with proper retry logic that can eventually
timeout, but I don't think that will change the overall structure of those
procedures. The idea is to safely obtain locks on the specific nodes in
question, but then also ensure they're not INSIDE another lock that someone
else already obtained, etc.
> HBOSS: A FileSystem implementation to provide HBase's required semantics
>
>
> Key: HBASE-22149
> URL: https://issues.apache.org/jira/browse/HBASE-22149
> Project: HBase
> Issue Type: New Feature
> Components: Filesystem Integration
>Reporter: Sean Mackrory
>Assignee: Sean Mackrory
>Priority: Critical
> Attachments: HBASE-22149-hadoop.patch
>
>
> (Have been using the name HBOSS for HBase / Object Store Semantics)
> I've had some thoughts about how to solve the problem of running HBase on
> object stores. There has been some thought in the past about adding the
> required semantics to S3Guard, but I have some concerns about that. First,
> it's mixing complicated solutions to different problems (bridging the gap
> between a flat namespace and a hierarchical namespace vs. solving
> inconsistency). Second, it's S3-specific, whereas other objects stores could
> use virtually identical solutions. And third, we can't do things like atomic
> renames in a true sense. There would have to be some trade-offs specific to
> HBase's needs and it's better if we can solve that in an HBase-specific
> module without mixing all that logic in with the rest of S3A.
> Ideas to solve this above the FileSystem layer have been proposed and
> considered (HBASE-20431, for one), and maybe that's the right way forward
> long-term, but it certainly seems to be a hard problem and hasn't been done
> yet. But I don't know enough of all the internal considerations to make much
> of a judgment on that myself.
> I propose a FileSystem implementation that wraps another FileSystem instance
> and provides locking of FileSystem operations to ensure correct semantics.
> Locking could quite possibly be done on the same ZooKeeper ensemble as an
> HBase cluster already uses (I'm sure there are some performance
> considerations here that deserve more attention). I've put together a
> proof-of-concept on which I've tested some aspects of atomic renames and
> atomic file creates. Both of these tests fail reliably on a naked s3a
> instance. I've also done a small YCSB run against a small cluster to sanity
> check other functionality and was successful. I will post the patch, and my
> laundry list of things that still need work. The WAL is still placed on HDFS,
> but the HBase root directory is otherwise on S3.
> Note that my prototype is built on Hadoop's source
[jira] [Comment Edited] (HBASE-22149) HBOSS: A FileSystem implementation to provide HBase's required semantics
[
https://issues.apache.org/jira/browse/HBASE-22149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808251#comment-16808251
]
Vladimir Rodionov edited comment on HBASE-22149 at 4/3/19 12:21 AM:
{code}
public class LockedFSDataOutputStream extends FSDataOutputStream {
+
+public LockedFSDataOutputStream(FSDataOutputStream stream, AutoLock lock) {
+ super(stream, null);
+ this.stream = stream;
+ this.lock = lock;
+}
+
+private final FSDataOutputStream stream;
+private AutoLock lock;
+
+@Override
+public long getPos() {
+ return stream.getPos();
+}
+
+@Override
+public void close() throws IOException {
+ stream.close();
+ lock.close();
+}
+
{code}
Lock release must be bullet proof. If stream.close() throws IOException, lock
will never be released. Please check all your code and make sure put lock.close
into finally clause.
was (Author: vrodionov):
{code}
public class LockedFSDataOutputStream extends FSDataOutputStream {
+
+public LockedFSDataOutputStream(FSDataOutputStream stream, AutoLock lock) {
+ super(stream, null);
+ this.stream = stream;
+ this.lock = lock;
+}
+
+private final FSDataOutputStream stream;
+private AutoLock lock;
+
+@Override
+public long getPos() {
+ return stream.getPos();
+}
+
+@Override
+public void close() throws IOException {
+ stream.close();
+ lock.close();
+}
+
{code}
Lock release must be bullet proof. If stream.close() throws IOException, lock
will never be released. Please check all your code and make sure put lock.close
in finally clause.
> HBOSS: A FileSystem implementation to provide HBase's required semantics
>
>
> Key: HBASE-22149
> URL: https://issues.apache.org/jira/browse/HBASE-22149
> Project: HBase
> Issue Type: New Feature
> Components: Filesystem Integration
>Reporter: Sean Mackrory
>Assignee: Sean Mackrory
>Priority: Critical
> Attachments: HBASE-22149-hadoop.patch
>
>
> (Have been using the name HBOSS for HBase / Object Store Semantics)
> I've had some thoughts about how to solve the problem of running HBase on
> object stores. There has been some thought in the past about adding the
> required semantics to S3Guard, but I have some concerns about that. First,
> it's mixing complicated solutions to different problems (bridging the gap
> between a flat namespace and a hierarchical namespace vs. solving
> inconsistency). Second, it's S3-specific, whereas other objects stores could
> use virtually identical solutions. And third, we can't do things like atomic
> renames in a true sense. There would have to be some trade-offs specific to
> HBase's needs and it's better if we can solve that in an HBase-specific
> module without mixing all that logic in with the rest of S3A.
> Ideas to solve this above the FileSystem layer have been proposed and
> considered (HBASE-20431, for one), and maybe that's the right way forward
> long-term, but it certainly seems to be a hard problem and hasn't been done
> yet. But I don't know enough of all the internal considerations to make much
> of a judgment on that myself.
> I propose a FileSystem implementation that wraps another FileSystem instance
> and provides locking of FileSystem operations to ensure correct semantics.
> Locking could quite possibly be done on the same ZooKeeper ensemble as an
> HBase cluster already uses (I'm sure there are some performance
> considerations here that deserve more attention). I've put together a
> proof-of-concept on which I've tested some aspects of atomic renames and
> atomic file creates. Both of these tests fail reliably on a naked s3a
> instance. I've also done a small YCSB run against a small cluster to sanity
> check other functionality and was successful. I will post the patch, and my
> laundry list of things that still need work. The WAL is still placed on HDFS,
> but the HBase root directory is otherwise on S3.
> Note that my prototype is built on Hadoop's source tree right now. That's
> purely for my convenience in putting it together quickly, as that's where I
> mostly work. I actually think long-term, if this is accepted as a good
> solution, it makes sense to live in HBase (or it's own repository). It only
> depends on stable, public APIs in Hadoop and is targeted entirely at HBase's
> needs, so it should be able to iterate on the HBase community's terms alone.
> Another idea [~ste...@apache.org] proposed to me is that of an inode-based
> FileSystem that keeps hierarchical metadata in a more appropriate store that
> would allow the required transactions (maybe a special table in HBase could
> provide that store itself for other
[jira] [Comment Edited] (HBASE-22149) HBOSS: A FileSystem implementation to provide HBase's required semantics
[ https://issues.apache.org/jira/browse/HBASE-22149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808248#comment-16808248 ] Sean Mackrory edited comment on HBASE-22149 at 4/3/19 12:21 AM: >> This code does not seem deadlock-safe? Thanks [~vrodionov]. You're quite right - there should be a copy of all the paths put into a single array and then sorted. I thought I had done that, but perhaps I'm thinking of another method or I lost it while cleaning up the patch. >> I would add explicit close() method I can certainly add that, but as of right now there's no code that will use it since it's not already part of the RemoteIterator interface (an interface that I'm not such a big fan of) so any use of it would be HBOSS-specific right now. One area in which I would particularly appreciate review for safety is in TreeLockManager.treeWriteLock and treeReadLock. As I said I'll be replacing the while(true)s and Thread.sleeps with proper retry logic that can eventually timeout, but I don't think that will change the overall structure of those procedures. The idea is to safely obtain locks on the specific nodes in question, but then also ensure they're not INSIDE another lock that someone else already obtained, etc. was (Author: mackrorysd): Thanks [~vrodionov]. You're quite right - there should be a copy of all the paths put into a single array and then sorted. I thought I had done that, but perhaps I'm thinking of another method or I lost it while cleaning up the patch. One area in which I would particularly appreciate review for safety is in TreeLockManager.treeWriteLock and treeReadLock. As I said I'll be replacing the while(true)s and Thread.sleeps with proper retry logic that can eventually timeout, but I don't think that will change the overall structure of those procedures. The idea is to safely obtain locks on the specific nodes in question, but then also ensure they're not INSIDE another lock that someone else already obtained, etc. > HBOSS: A FileSystem implementation to provide HBase's required semantics > > > Key: HBASE-22149 > URL: https://issues.apache.org/jira/browse/HBASE-22149 > Project: HBase > Issue Type: New Feature > Components: Filesystem Integration >Reporter: Sean Mackrory >Assignee: Sean Mackrory >Priority: Critical > Attachments: HBASE-22149-hadoop.patch > > > (Have been using the name HBOSS for HBase / Object Store Semantics) > I've had some thoughts about how to solve the problem of running HBase on > object stores. There has been some thought in the past about adding the > required semantics to S3Guard, but I have some concerns about that. First, > it's mixing complicated solutions to different problems (bridging the gap > between a flat namespace and a hierarchical namespace vs. solving > inconsistency). Second, it's S3-specific, whereas other objects stores could > use virtually identical solutions. And third, we can't do things like atomic > renames in a true sense. There would have to be some trade-offs specific to > HBase's needs and it's better if we can solve that in an HBase-specific > module without mixing all that logic in with the rest of S3A. > Ideas to solve this above the FileSystem layer have been proposed and > considered (HBASE-20431, for one), and maybe that's the right way forward > long-term, but it certainly seems to be a hard problem and hasn't been done > yet. But I don't know enough of all the internal considerations to make much > of a judgment on that myself. > I propose a FileSystem implementation that wraps another FileSystem instance > and provides locking of FileSystem operations to ensure correct semantics. > Locking could quite possibly be done on the same ZooKeeper ensemble as an > HBase cluster already uses (I'm sure there are some performance > considerations here that deserve more attention). I've put together a > proof-of-concept on which I've tested some aspects of atomic renames and > atomic file creates. Both of these tests fail reliably on a naked s3a > instance. I've also done a small YCSB run against a small cluster to sanity > check other functionality and was successful. I will post the patch, and my > laundry list of things that still need work. The WAL is still placed on HDFS, > but the HBase root directory is otherwise on S3. > Note that my prototype is built on Hadoop's source tree right now. That's > purely for my convenience in putting it together quickly, as that's where I > mostly work. I actually think long-term, if this is accepted as a good > solution, it makes sense to live in HBase (or it's own repository). It only > depends on stable, public APIs in Hadoop and is targeted entirely at HBase's > needs, so
[jira] [Commented] (HBASE-22149) HBOSS: A FileSystem implementation to provide HBase's required semantics
[
https://issues.apache.org/jira/browse/HBASE-22149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808252#comment-16808252
]
Vladimir Rodionov commented on HBASE-22149:
---
{quote}
One area in which I would particularly appreciate review for safety is in
TreeLockManager.treeWriteLock and treeReadLock.
{quote}
Sure, this is the most interesting part :)
> HBOSS: A FileSystem implementation to provide HBase's required semantics
>
>
> Key: HBASE-22149
> URL: https://issues.apache.org/jira/browse/HBASE-22149
> Project: HBase
> Issue Type: New Feature
> Components: Filesystem Integration
>Reporter: Sean Mackrory
>Assignee: Sean Mackrory
>Priority: Critical
> Attachments: HBASE-22149-hadoop.patch
>
>
> (Have been using the name HBOSS for HBase / Object Store Semantics)
> I've had some thoughts about how to solve the problem of running HBase on
> object stores. There has been some thought in the past about adding the
> required semantics to S3Guard, but I have some concerns about that. First,
> it's mixing complicated solutions to different problems (bridging the gap
> between a flat namespace and a hierarchical namespace vs. solving
> inconsistency). Second, it's S3-specific, whereas other objects stores could
> use virtually identical solutions. And third, we can't do things like atomic
> renames in a true sense. There would have to be some trade-offs specific to
> HBase's needs and it's better if we can solve that in an HBase-specific
> module without mixing all that logic in with the rest of S3A.
> Ideas to solve this above the FileSystem layer have been proposed and
> considered (HBASE-20431, for one), and maybe that's the right way forward
> long-term, but it certainly seems to be a hard problem and hasn't been done
> yet. But I don't know enough of all the internal considerations to make much
> of a judgment on that myself.
> I propose a FileSystem implementation that wraps another FileSystem instance
> and provides locking of FileSystem operations to ensure correct semantics.
> Locking could quite possibly be done on the same ZooKeeper ensemble as an
> HBase cluster already uses (I'm sure there are some performance
> considerations here that deserve more attention). I've put together a
> proof-of-concept on which I've tested some aspects of atomic renames and
> atomic file creates. Both of these tests fail reliably on a naked s3a
> instance. I've also done a small YCSB run against a small cluster to sanity
> check other functionality and was successful. I will post the patch, and my
> laundry list of things that still need work. The WAL is still placed on HDFS,
> but the HBase root directory is otherwise on S3.
> Note that my prototype is built on Hadoop's source tree right now. That's
> purely for my convenience in putting it together quickly, as that's where I
> mostly work. I actually think long-term, if this is accepted as a good
> solution, it makes sense to live in HBase (or it's own repository). It only
> depends on stable, public APIs in Hadoop and is targeted entirely at HBase's
> needs, so it should be able to iterate on the HBase community's terms alone.
> Another idea [~ste...@apache.org] proposed to me is that of an inode-based
> FileSystem that keeps hierarchical metadata in a more appropriate store that
> would allow the required transactions (maybe a special table in HBase could
> provide that store itself for other tables), and stores the underlying files
> with unique identifiers on S3. This allows renames to actually become fast
> instead of just large atomic operations. It does however place a strong
> dependency on the metadata store. I have not explored this idea much. My
> current proof-of-concept has been pleasantly simple, so I think it's the
> right solution unless it proves unable to provide the required performance
> characteristics.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22149) HBOSS: A FileSystem implementation to provide HBase's required semantics
[
https://issues.apache.org/jira/browse/HBASE-22149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808251#comment-16808251
]
Vladimir Rodionov commented on HBASE-22149:
---
{code}
public class LockedFSDataOutputStream extends FSDataOutputStream {
+
+public LockedFSDataOutputStream(FSDataOutputStream stream, AutoLock lock) {
+ super(stream, null);
+ this.stream = stream;
+ this.lock = lock;
+}
+
+private final FSDataOutputStream stream;
+private AutoLock lock;
+
+@Override
+public long getPos() {
+ return stream.getPos();
+}
+
+@Override
+public void close() throws IOException {
+ stream.close();
+ lock.close();
+}
+
{code}
Lock release must be bullet proof. If stream.close() throws IOException, lock
will never be released. Please check all your code and make sure put lock.close
in finally clause.
> HBOSS: A FileSystem implementation to provide HBase's required semantics
>
>
> Key: HBASE-22149
> URL: https://issues.apache.org/jira/browse/HBASE-22149
> Project: HBase
> Issue Type: New Feature
> Components: Filesystem Integration
>Reporter: Sean Mackrory
>Assignee: Sean Mackrory
>Priority: Critical
> Attachments: HBASE-22149-hadoop.patch
>
>
> (Have been using the name HBOSS for HBase / Object Store Semantics)
> I've had some thoughts about how to solve the problem of running HBase on
> object stores. There has been some thought in the past about adding the
> required semantics to S3Guard, but I have some concerns about that. First,
> it's mixing complicated solutions to different problems (bridging the gap
> between a flat namespace and a hierarchical namespace vs. solving
> inconsistency). Second, it's S3-specific, whereas other objects stores could
> use virtually identical solutions. And third, we can't do things like atomic
> renames in a true sense. There would have to be some trade-offs specific to
> HBase's needs and it's better if we can solve that in an HBase-specific
> module without mixing all that logic in with the rest of S3A.
> Ideas to solve this above the FileSystem layer have been proposed and
> considered (HBASE-20431, for one), and maybe that's the right way forward
> long-term, but it certainly seems to be a hard problem and hasn't been done
> yet. But I don't know enough of all the internal considerations to make much
> of a judgment on that myself.
> I propose a FileSystem implementation that wraps another FileSystem instance
> and provides locking of FileSystem operations to ensure correct semantics.
> Locking could quite possibly be done on the same ZooKeeper ensemble as an
> HBase cluster already uses (I'm sure there are some performance
> considerations here that deserve more attention). I've put together a
> proof-of-concept on which I've tested some aspects of atomic renames and
> atomic file creates. Both of these tests fail reliably on a naked s3a
> instance. I've also done a small YCSB run against a small cluster to sanity
> check other functionality and was successful. I will post the patch, and my
> laundry list of things that still need work. The WAL is still placed on HDFS,
> but the HBase root directory is otherwise on S3.
> Note that my prototype is built on Hadoop's source tree right now. That's
> purely for my convenience in putting it together quickly, as that's where I
> mostly work. I actually think long-term, if this is accepted as a good
> solution, it makes sense to live in HBase (or it's own repository). It only
> depends on stable, public APIs in Hadoop and is targeted entirely at HBase's
> needs, so it should be able to iterate on the HBase community's terms alone.
> Another idea [~ste...@apache.org] proposed to me is that of an inode-based
> FileSystem that keeps hierarchical metadata in a more appropriate store that
> would allow the required transactions (maybe a special table in HBase could
> provide that store itself for other tables), and stores the underlying files
> with unique identifiers on S3. This allows renames to actually become fast
> instead of just large atomic operations. It does however place a strong
> dependency on the metadata store. I have not explored this idea much. My
> current proof-of-concept has been pleasantly simple, so I think it's the
> right solution unless it proves unable to provide the required performance
> characteristics.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22149) HBOSS: A FileSystem implementation to provide HBase's required semantics
[
https://issues.apache.org/jira/browse/HBASE-22149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808247#comment-16808247
]
Vladimir Rodionov commented on HBASE-22149:
---
{code}
+ public static class LockedRemoteIterator implements RemoteIterator {
+public LockedRemoteIterator(RemoteIterator iterator, AutoLock lock)
+ {
+ this.iterator = iterator;
+ this.lock = lock;
+}
+
+private RemoteIterator iterator;
+private AutoLock lock;
+
+public boolean hasNext() throws IOException {
+ if (iterator.hasNext()) {
+return true;
+ }
+ lock.close();
+ return false;
+}
+
+/**
+ * Delegates to the wrapped iterator, but will close the lock in the event
+ * of a NoSuchElementException. Some applications do not call hasNext() and
+ * simply depend on the NoSuchElementException.
+ */
+public E next() throws IOException {
+ try {
+return iterator.next();
+ } catch (NoSuchElementException e) {
+lock.close();
+throw e;
+ }
+}
+ }
{code}
I would add explicit close() method to this Iterator, since it holds lock,
which is closed only when iterator reaches end. There is no explicit way to
release lock here.
> HBOSS: A FileSystem implementation to provide HBase's required semantics
>
>
> Key: HBASE-22149
> URL: https://issues.apache.org/jira/browse/HBASE-22149
> Project: HBase
> Issue Type: New Feature
> Components: Filesystem Integration
>Reporter: Sean Mackrory
>Assignee: Sean Mackrory
>Priority: Critical
> Attachments: HBASE-22149-hadoop.patch
>
>
> (Have been using the name HBOSS for HBase / Object Store Semantics)
> I've had some thoughts about how to solve the problem of running HBase on
> object stores. There has been some thought in the past about adding the
> required semantics to S3Guard, but I have some concerns about that. First,
> it's mixing complicated solutions to different problems (bridging the gap
> between a flat namespace and a hierarchical namespace vs. solving
> inconsistency). Second, it's S3-specific, whereas other objects stores could
> use virtually identical solutions. And third, we can't do things like atomic
> renames in a true sense. There would have to be some trade-offs specific to
> HBase's needs and it's better if we can solve that in an HBase-specific
> module without mixing all that logic in with the rest of S3A.
> Ideas to solve this above the FileSystem layer have been proposed and
> considered (HBASE-20431, for one), and maybe that's the right way forward
> long-term, but it certainly seems to be a hard problem and hasn't been done
> yet. But I don't know enough of all the internal considerations to make much
> of a judgment on that myself.
> I propose a FileSystem implementation that wraps another FileSystem instance
> and provides locking of FileSystem operations to ensure correct semantics.
> Locking could quite possibly be done on the same ZooKeeper ensemble as an
> HBase cluster already uses (I'm sure there are some performance
> considerations here that deserve more attention). I've put together a
> proof-of-concept on which I've tested some aspects of atomic renames and
> atomic file creates. Both of these tests fail reliably on a naked s3a
> instance. I've also done a small YCSB run against a small cluster to sanity
> check other functionality and was successful. I will post the patch, and my
> laundry list of things that still need work. The WAL is still placed on HDFS,
> but the HBase root directory is otherwise on S3.
> Note that my prototype is built on Hadoop's source tree right now. That's
> purely for my convenience in putting it together quickly, as that's where I
> mostly work. I actually think long-term, if this is accepted as a good
> solution, it makes sense to live in HBase (or it's own repository). It only
> depends on stable, public APIs in Hadoop and is targeted entirely at HBase's
> needs, so it should be able to iterate on the HBase community's terms alone.
> Another idea [~ste...@apache.org] proposed to me is that of an inode-based
> FileSystem that keeps hierarchical metadata in a more appropriate store that
> would allow the required transactions (maybe a special table in HBase could
> provide that store itself for other tables), and stores the underlying files
> with unique identifiers on S3. This allows renames to actually become fast
> instead of just large atomic operations. It does however place a strong
> dependency on the metadata store. I have not explored this idea much. My
> current proof-of-concept has been pleasantly simple, so I think it's the
> right solution unless it proves unable to provide the required performance
>
[jira] [Commented] (HBASE-22149) HBOSS: A FileSystem implementation to provide HBase's required semantics
[ https://issues.apache.org/jira/browse/HBASE-22149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808248#comment-16808248 ] Sean Mackrory commented on HBASE-22149: --- Thanks [~vrodionov]. You're quite right - there should be a copy of all the paths put into a single array and then sorted. I thought I had done that, but perhaps I'm thinking of another method or I lost it while cleaning up the patch. One area in which I would particularly appreciate review for safety is in TreeLockManager.treeWriteLock and treeReadLock. As I said I'll be replacing the while(true)s and Thread.sleeps with proper retry logic that can eventually timeout, but I don't think that will change the overall structure of those procedures. The idea is to safely obtain locks on the specific nodes in question, but then also ensure they're not INSIDE another lock that someone else already obtained, etc. > HBOSS: A FileSystem implementation to provide HBase's required semantics > > > Key: HBASE-22149 > URL: https://issues.apache.org/jira/browse/HBASE-22149 > Project: HBase > Issue Type: New Feature > Components: Filesystem Integration >Reporter: Sean Mackrory >Assignee: Sean Mackrory >Priority: Critical > Attachments: HBASE-22149-hadoop.patch > > > (Have been using the name HBOSS for HBase / Object Store Semantics) > I've had some thoughts about how to solve the problem of running HBase on > object stores. There has been some thought in the past about adding the > required semantics to S3Guard, but I have some concerns about that. First, > it's mixing complicated solutions to different problems (bridging the gap > between a flat namespace and a hierarchical namespace vs. solving > inconsistency). Second, it's S3-specific, whereas other objects stores could > use virtually identical solutions. And third, we can't do things like atomic > renames in a true sense. There would have to be some trade-offs specific to > HBase's needs and it's better if we can solve that in an HBase-specific > module without mixing all that logic in with the rest of S3A. > Ideas to solve this above the FileSystem layer have been proposed and > considered (HBASE-20431, for one), and maybe that's the right way forward > long-term, but it certainly seems to be a hard problem and hasn't been done > yet. But I don't know enough of all the internal considerations to make much > of a judgment on that myself. > I propose a FileSystem implementation that wraps another FileSystem instance > and provides locking of FileSystem operations to ensure correct semantics. > Locking could quite possibly be done on the same ZooKeeper ensemble as an > HBase cluster already uses (I'm sure there are some performance > considerations here that deserve more attention). I've put together a > proof-of-concept on which I've tested some aspects of atomic renames and > atomic file creates. Both of these tests fail reliably on a naked s3a > instance. I've also done a small YCSB run against a small cluster to sanity > check other functionality and was successful. I will post the patch, and my > laundry list of things that still need work. The WAL is still placed on HDFS, > but the HBase root directory is otherwise on S3. > Note that my prototype is built on Hadoop's source tree right now. That's > purely for my convenience in putting it together quickly, as that's where I > mostly work. I actually think long-term, if this is accepted as a good > solution, it makes sense to live in HBase (or it's own repository). It only > depends on stable, public APIs in Hadoop and is targeted entirely at HBase's > needs, so it should be able to iterate on the HBase community's terms alone. > Another idea [~ste...@apache.org] proposed to me is that of an inode-based > FileSystem that keeps hierarchical metadata in a more appropriate store that > would allow the required transactions (maybe a special table in HBase could > provide that store itself for other tables), and stores the underlying files > with unique identifiers on S3. This allows renames to actually become fast > instead of just large atomic operations. It does however place a strong > dependency on the metadata store. I have not explored this idea much. My > current proof-of-concept has been pleasantly simple, so I think it's the > right solution unless it proves unable to provide the required performance > characteristics. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22060) postOpenDeployTasks could send OPENED region transition state to the wrong master
[
https://issues.apache.org/jira/browse/HBASE-22060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808240#comment-16808240
]
Hadoop QA commented on HBASE-22060:
---
| (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:brown} Prechecks {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 2 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
23s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
52s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
6s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
21s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
13s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {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
44s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
15s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
49s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
3s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 2m 39s{color}
| {color:red} hbase-server generated 1 new + 193 unchanged - 1 fixed = 194
total (was 194) {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m
13s{color} | {color:red} hbase-zookeeper: The patch generated 4 new + 0
unchanged - 0 fixed = 4 total (was 0) {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
8s{color} | {color:red} hbase-server: The patch generated 3 new + 79 unchanged
- 1 fixed = 82 total (was 80) {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} shadedjars {color} | {color:green} 4m
14s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
7m 53s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
0s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
38s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
44s{color} | {color:green} hbase-zookeeper in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}127m 32s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
48s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}170m 44s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests |
hadoop.hbase.replication.regionserver.TestRegionReplicaReplicationEndpoint |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b |
| JIRA Issue | HBASE-22060 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12964619/Reset-cached-rssStub-on-region-servers-as-soon-as-the-master-changes-v2.patch
|
| Optional Tests | dupname asflicense javac javadoc unit findbugs
shadedjars
[jira] [Updated] (HBASE-22151) hbase-backup should specify hadoop-hdfs-client version for Hadoop 3
[
https://issues.apache.org/jira/browse/HBASE-22151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wei-Chiu Chuang updated HBASE-22151:
Status: Patch Available (was: Open)
Submit the fix for precommit check. The test passed after the fix on Hadoop
3.2.0
> hbase-backup should specify hadoop-hdfs-client version for Hadoop 3
> ---
>
> Key: HBASE-22151
> URL: https://issues.apache.org/jira/browse/HBASE-22151
> Project: HBase
> Issue Type: Bug
> Components: backuprestore
>Affects Versions: 2.0.0
> Environment: Hadoop 3.2.0
>Reporter: Wei-Chiu Chuang
>Assignee: Wei-Chiu Chuang
>Priority: Major
> Attachments: HBASE-22151.master.001.patch
>
>
> {code}
> mvn test -P runAllTests -fn -Dhadoop.profile=3.0 -Dhadoop-three.version=3.2.0
> -Dtest=TestIncrementalBackupWithBulkLoad
> {code}
>
> Despite hadoop 3 version is specified, the test always use hadoop-hdfs-client
> 3.0.3, and will fail on Hadoop 3.2.0 because it can't find a new class.
>
> {noformat}
> Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 709.323 s <<<
> FAILURE! - in org.apache.hadoop.hbase.backup.TestIncrementalBackupWithBulkLoad
> TestIncBackupDeleteTable(org.apache.hadoop.hbase.backup.TestIncrementalBackupWithBulkLoad)
> Time elapsed: 1.907 s <<< ERROR!
> java.lang.NoClassDefFoundError:
> org/apache/hadoop/hdfs/protocol/HdfsConstants$StoragePolicySatisfierMode
> Caused by: java.lang.ClassNotFoundException:
> org.apache.hadoop.hdfs.protocol.HdfsConstants$StoragePolicySatisfierMode{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-22151) hbase-backup should specify hadoop-hdfs-client version for Hadoop 3
[
https://issues.apache.org/jira/browse/HBASE-22151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wei-Chiu Chuang updated HBASE-22151:
Attachment: HBASE-22151.master.001.patch
> hbase-backup should specify hadoop-hdfs-client version for Hadoop 3
> ---
>
> Key: HBASE-22151
> URL: https://issues.apache.org/jira/browse/HBASE-22151
> Project: HBase
> Issue Type: Bug
> Components: backuprestore
>Affects Versions: 2.0.0
> Environment: Hadoop 3.2.0
>Reporter: Wei-Chiu Chuang
>Assignee: Wei-Chiu Chuang
>Priority: Major
> Attachments: HBASE-22151.master.001.patch
>
>
> {code}
> mvn test -P runAllTests -fn -Dhadoop.profile=3.0 -Dhadoop-three.version=3.2.0
> -Dtest=TestIncrementalBackupWithBulkLoad
> {code}
>
> Despite hadoop 3 version is specified, the test always use hadoop-hdfs-client
> 3.0.3, and will fail on Hadoop 3.2.0 because it can't find a new class.
>
> {noformat}
> Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 709.323 s <<<
> FAILURE! - in org.apache.hadoop.hbase.backup.TestIncrementalBackupWithBulkLoad
> TestIncBackupDeleteTable(org.apache.hadoop.hbase.backup.TestIncrementalBackupWithBulkLoad)
> Time elapsed: 1.907 s <<< ERROR!
> java.lang.NoClassDefFoundError:
> org/apache/hadoop/hdfs/protocol/HdfsConstants$StoragePolicySatisfierMode
> Caused by: java.lang.ClassNotFoundException:
> org.apache.hadoop.hdfs.protocol.HdfsConstants$StoragePolicySatisfierMode{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-22151) hbase-backup should specify hadoop-hdfs-client version for Hadoop 3
[
https://issues.apache.org/jira/browse/HBASE-22151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wei-Chiu Chuang updated HBASE-22151:
Attachment: (was: HBASE-22151.HBASE-22103.001.patch)
> hbase-backup should specify hadoop-hdfs-client version for Hadoop 3
> ---
>
> Key: HBASE-22151
> URL: https://issues.apache.org/jira/browse/HBASE-22151
> Project: HBase
> Issue Type: Bug
> Components: backuprestore
>Affects Versions: 2.0.0
> Environment: Hadoop 3.2.0
>Reporter: Wei-Chiu Chuang
>Assignee: Wei-Chiu Chuang
>Priority: Major
>
> {code}
> mvn test -P runAllTests -fn -Dhadoop.profile=3.0 -Dhadoop-three.version=3.2.0
> -Dtest=TestIncrementalBackupWithBulkLoad
> {code}
>
> Despite hadoop 3 version is specified, the test always use hadoop-hdfs-client
> 3.0.3, and will fail on Hadoop 3.2.0 because it can't find a new class.
>
> {noformat}
> Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 709.323 s <<<
> FAILURE! - in org.apache.hadoop.hbase.backup.TestIncrementalBackupWithBulkLoad
> TestIncBackupDeleteTable(org.apache.hadoop.hbase.backup.TestIncrementalBackupWithBulkLoad)
> Time elapsed: 1.907 s <<< ERROR!
> java.lang.NoClassDefFoundError:
> org/apache/hadoop/hdfs/protocol/HdfsConstants$StoragePolicySatisfierMode
> Caused by: java.lang.ClassNotFoundException:
> org.apache.hadoop.hdfs.protocol.HdfsConstants$StoragePolicySatisfierMode{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-22151) hbase-backup should specify hadoop-hdfs-client version for Hadoop 3
[
https://issues.apache.org/jira/browse/HBASE-22151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wei-Chiu Chuang updated HBASE-22151:
Attachment: HBASE-22151.HBASE-22103.001.patch
> hbase-backup should specify hadoop-hdfs-client version for Hadoop 3
> ---
>
> Key: HBASE-22151
> URL: https://issues.apache.org/jira/browse/HBASE-22151
> Project: HBase
> Issue Type: Bug
> Components: backuprestore
>Affects Versions: 2.0.0
> Environment: Hadoop 3.2.0
>Reporter: Wei-Chiu Chuang
>Assignee: Wei-Chiu Chuang
>Priority: Major
>
> {code}
> mvn test -P runAllTests -fn -Dhadoop.profile=3.0 -Dhadoop-three.version=3.2.0
> -Dtest=TestIncrementalBackupWithBulkLoad
> {code}
>
> Despite hadoop 3 version is specified, the test always use hadoop-hdfs-client
> 3.0.3, and will fail on Hadoop 3.2.0 because it can't find a new class.
>
> {noformat}
> Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 709.323 s <<<
> FAILURE! - in org.apache.hadoop.hbase.backup.TestIncrementalBackupWithBulkLoad
> TestIncBackupDeleteTable(org.apache.hadoop.hbase.backup.TestIncrementalBackupWithBulkLoad)
> Time elapsed: 1.907 s <<< ERROR!
> java.lang.NoClassDefFoundError:
> org/apache/hadoop/hdfs/protocol/HdfsConstants$StoragePolicySatisfierMode
> Caused by: java.lang.ClassNotFoundException:
> org.apache.hadoop.hdfs.protocol.HdfsConstants$StoragePolicySatisfierMode{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HBASE-22151) hbase-backup should specify hadoop-hdfs-client version for Hadoop 3
Wei-Chiu Chuang created HBASE-22151:
---
Summary: hbase-backup should specify hadoop-hdfs-client version
for Hadoop 3
Key: HBASE-22151
URL: https://issues.apache.org/jira/browse/HBASE-22151
Project: HBase
Issue Type: Bug
Components: backuprestore
Affects Versions: 2.0.0
Environment: Hadoop 3.2.0
Reporter: Wei-Chiu Chuang
Assignee: Wei-Chiu Chuang
{code}
mvn test -P runAllTests -fn -Dhadoop.profile=3.0 -Dhadoop-three.version=3.2.0
-Dtest=TestIncrementalBackupWithBulkLoad
{code}
Despite hadoop 3 version is specified, the test always use hadoop-hdfs-client
3.0.3, and will fail on Hadoop 3.2.0 because it can't find a new class.
{noformat}
Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 709.323 s <<<
FAILURE! - in org.apache.hadoop.hbase.backup.TestIncrementalBackupWithBulkLoad
TestIncBackupDeleteTable(org.apache.hadoop.hbase.backup.TestIncrementalBackupWithBulkLoad)
Time elapsed: 1.907 s <<< ERROR!
java.lang.NoClassDefFoundError:
org/apache/hadoop/hdfs/protocol/HdfsConstants$StoragePolicySatisfierMode
Caused by: java.lang.ClassNotFoundException:
org.apache.hadoop.hdfs.protocol.HdfsConstants$StoragePolicySatisfierMode{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22060) postOpenDeployTasks could send OPENED region transition state to the wrong master
[
https://issues.apache.org/jira/browse/HBASE-22060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808237#comment-16808237
]
Bahram Chehrazy commented on HBASE-22060:
-
This patch together with a failing unit test uncovered another bug HBASE-22150,
I've updated this path and provided a separate patch for the other one, in case
this doesn't get into the community.
> postOpenDeployTasks could send OPENED region transition state to the wrong
> master
> -
>
> Key: HBASE-22060
> URL: https://issues.apache.org/jira/browse/HBASE-22060
> Project: HBase
> Issue Type: Bug
> Components: amv2, proc-v2
>Affects Versions: 3.0.0
>Reporter: Bahram Chehrazy
>Assignee: Duo Zhang
>Priority: Critical
> Attachments:
> Reset-cached-rssStub-on-region-servers-as-soon-as-the-master-changes-v2.patch,
> Reset-cached-rssStub-on-region-servers-as-soon-as-the-master-changes.patch
>
>
> As was reported in HBASE-21788, we have repeatedly seen regions getting stuck
> in OPENING after master restarts. Here is one scenario that I've observed
> recently:
>
> 1) There is a region is transit (RIT).
> 2) The active master aborts and begins shutting down.
> 3) The backup master becomes active quickly, finds the RIT, creates
> OpenRegionProcedure and send request to some server.
> 4) The server quickly opens the region and posts OPENED state transition, but
> it uses its cached master instead of the new one.
> 5) The old active master which had not completely shutdown its assignment
> manager yet, notes the OPENED state report and ignores it. Because no
> corresponding procedure can be found.
> 6) The new master waits forever for a response to its OPEN region request.
>
> This happens more often with the meta region because it's small and takes a
> few seconds to open. Below are some related logs:
> *Previous HMaster:*
> 2019-03-14 13:19:16,310 ERROR [PEWorker-1] master.HMaster: * ABORTING
> master ,17000,1552438242232: Shutting down HBase cluster: file
> system not available *
> 2019-03-14 13:19:16,310 INFO [PEWorker-1] regionserver.HRegionServer: *
> STOPPING region server ',17000,1552438242232' *
> 2019-03-14 13:20:54,358 WARN
> [RpcServer.priority.FPBQ.Fifo.handler=11,queue=1,port=17000]
> assignment.AssignmentManager: No matching procedure found for rit=OPEN,
> location=*,17020,1552561955412, table=hbase:meta,
> region=1588230740 transition to OPENED
> 2019-03-14 13:20:55,707 INFO [master/:17000]
> assignment.AssignmentManager: Stopping assignment manager
> *New HMaster logs:*
> 2019-03-14 13:19:16,907 INFO [master/:17000:becomeActiveMaster]
> master.ActiveMasterManager: Deleting ZNode for
> /HBaseServerZnodeCommonDir/**/backup-masters/,17000,1552438259871
> from backup master directory
> 2019-03-14 13:19:17,031 INFO [master/:17000:becomeActiveMaster]
> master.ActiveMasterManager: Registered as active
> master=,17000,1552438259871
> 2019-03-14 13:20:52,017 INFO [PEWorker-12] zookeeper.MetaTableLocator:
> Setting hbase:meta (replicaId=0) location in ZooKeeper as
> ,17020,1552536956826
> 2019-03-14 13:20:52,105 INFO [PEWorker-12] procedure2.ProcedureExecutor:
> Initialized subprocedures=[\{pid=178230, ppid=178229, state=RUNNABLE,
> hasLock=false; org.apache.hadoop.hbase.master.assignment.OpenRegionProcedure}]
>
> *HServer logs:*
> 2019-03-14 13:20:52,708 INFO [RS_CLOSE_META-regionserver/:17020-0]
> handler.AssignRegionHandler: Open hbase:meta,,1.1588230740
> 2019-03-14 13:20:54,353 INFO [RS_CLOSE_META-regionserver/:17020-0]
> regionserver.HRegion: Opened 1588230740; next sequenceid=229166
> 2019-03-14 13:20:54,356 INFO [RS_CLOSE_META-regionserver/:17020-0]
> regionserver.HRegionServer: Post open deploy tasks for
> hbase:meta,,1.1588230740
> 2019-03-14 13:20:54,358 INFO [RS_CLOSE_META-regionserver/:17020-0]
> handler.AssignRegionHandler: Opened hbase:meta,,1.1588230740
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (HBASE-22150) rssStub in HRegionServer is not thread safe and should not directly be used
[ https://issues.apache.org/jira/browse/HBASE-22150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bahram Chehrazy reassigned HBASE-22150: --- Assignee: Sergey Shelukhin (was: Bahram Chehrazy) > rssStub in HRegionServer is not thread safe and should not directly be used > --- > > Key: HBASE-22150 > URL: https://issues.apache.org/jira/browse/HBASE-22150 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 3.0.0, 2.2.0 >Reporter: Bahram Chehrazy >Assignee: Sergey Shelukhin >Priority: Major > Attachments: > rssStub-is-not-thread-safe-hence-should-not-be-accessed-directly.patch > > > While working on a patch for HBASE-22060, I noticed that a unit test started > failing because region server crashed with NPE during initialization and > after aborting the master. It turned out that access to the rssStub was not > synchronized. > The existing code in HRegionServer already takes care of this fact by copying > and null checking in most places, but there are a couple ones that are not so > careful. Those are in reportForDuty and abort methods. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22150) rssStub in HRegionServer is not thread safe and should not directly be used
[ https://issues.apache.org/jira/browse/HBASE-22150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bahram Chehrazy updated HBASE-22150: Attachment: rssStub-is-not-thread-safe-hence-should-not-be-accessed-directly.patch Status: Patch Available (was: Open) > rssStub in HRegionServer is not thread safe and should not directly be used > --- > > Key: HBASE-22150 > URL: https://issues.apache.org/jira/browse/HBASE-22150 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 3.0.0, 2.2.0 >Reporter: Bahram Chehrazy >Assignee: Bahram Chehrazy >Priority: Major > Attachments: > rssStub-is-not-thread-safe-hence-should-not-be-accessed-directly.patch > > > While working on a patch for HBASE-22060, I noticed that a unit test started > failing because region server crashed with NPE during initialization and > after aborting the master. It turned out that access to the rssStub was not > synchronized. > The existing code in HRegionServer already takes care of this fact by copying > and null checking in most places, but there are a couple ones that are not so > careful. Those are in reportForDuty and abort methods. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-22150) rssStub in HRegionServer is not thread safe and should not directly be used
Bahram Chehrazy created HBASE-22150: --- Summary: rssStub in HRegionServer is not thread safe and should not directly be used Key: HBASE-22150 URL: https://issues.apache.org/jira/browse/HBASE-22150 Project: HBase Issue Type: Bug Components: regionserver Affects Versions: 3.0.0, 2.2.0 Reporter: Bahram Chehrazy Assignee: Bahram Chehrazy While working on a patch for HBASE-22060, I noticed that a unit test started failing because region server crashed with NPE during initialization and after aborting the master. It turned out that access to the rssStub was not synchronized. The existing code in HRegionServer already takes care of this fact by copying and null checking in most places, but there are a couple ones that are not so careful. Those are in reportForDuty and abort methods. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (HBASE-22148) Provide an alternative to CellUtil.setTimestamp
[
https://issues.apache.org/jira/browse/HBASE-22148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808222#comment-16808222
]
Thomas D'Silva edited comment on HBASE-22148 at 4/2/19 11:17 PM:
-
Before PHOENIX-4089 we were setting the timestamp of mutations from the client
(based on when we resolved the metadata of the table to which we were writing).
We had issues where the index table was getting out of sync with the data table
when there were concurrent updates to the same row. I'm not very familiar with
the Indexing coprocessor, maybe [~vincentpoon] knows the exact reason why this
was happening?
In PHOENIX-4089 we changed this so that the timestamp of mutations gets set on
the server via the Indexer coprocessor. After all the rows in a mini batch have
been locked the timestamp of each cell of every row gets set to the same value.
The index mutations created by the Indexer coprocessor get the same timestamp
as the corresponding data table mutations.
was (Author: tdsilva):
Before PHOENIX-4089 we were setting the timestamp of mutations from the client
(based on when we resolved the metadata of the table to which we were writing).
We had issues where the index table was getting out of sync with the data table
when there were concurrent updates to the same row. I'm not very familiar with
the Indexing coprocessor, maybe [~vincentpoon] knows the exact reason why this
was happening?
In PHOENIX-4089 we changed this so that the timestamp of mutations gets set on
the server via the Indexer coprocessor. After all the rows in a mini batch have
been locked the timestamp of each cell of every row gets set to the same value.
The index mutations are created by the Indexer coprocessor get the same
timestamp as the corresponding data table mutations.
> Provide an alternative to CellUtil.setTimestamp
>
>
> Key: HBASE-22148
> URL: https://issues.apache.org/jira/browse/HBASE-22148
> Project: HBase
> Issue Type: New Feature
> Components: API, Coprocessors
>Affects Versions: 3.0.0
>Reporter: Thomas D'Silva
>Priority: Blocker
> Labels: phoenix
> Fix For: 3.0.0
>
>
> {{CellUtil.setTimestamp}} has been deprecated in 2.0 and is marked for
> removal in 3.0. Phoenix currently uses this api to set the timestamp of cells
> in its indexing coprocessor for tables that have mutable indexes. We can't
> use the CellBuilder api since this involves creating a copy of the cell which
> will be expensive.
> FYI @stack
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22149) HBOSS: A FileSystem implementation to provide HBase's required semantics
[
https://issues.apache.org/jira/browse/HBASE-22149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808228#comment-16808228
]
Vladimir Rodionov commented on HBASE-22149:
---
Nice, thanks [~mackrorysd]. I will go through your patch later on
today/tomorrow, for now one q:
{code}
+ public void concat(final Path trg, final Path[] psrcs) throws IOException {
+AutoLock[] locks = new AutoLock[psrcs.length + 1];
+try {
+ for (int i = 0; i < psrcs.length; i++) {
+locks[i] = sync.lock(psrcs[i]);
+ }
+ locks[psrcs.length] = sync.lock(trg);
+ fs.concat(trg, psrcs);
+} finally {
+ for (int i = 0; i < locks.length; i++) {
+if (locks[i] != null) {
+ locks[i].close();
+}
+ }
+}
+ }
{code}
This code does not seem deadlock-safe?
> HBOSS: A FileSystem implementation to provide HBase's required semantics
>
>
> Key: HBASE-22149
> URL: https://issues.apache.org/jira/browse/HBASE-22149
> Project: HBase
> Issue Type: New Feature
> Components: Filesystem Integration
>Reporter: Sean Mackrory
>Assignee: Sean Mackrory
>Priority: Critical
> Attachments: HBASE-22149-hadoop.patch
>
>
> (Have been using the name HBOSS for HBase / Object Store Semantics)
> I've had some thoughts about how to solve the problem of running HBase on
> object stores. There has been some thought in the past about adding the
> required semantics to S3Guard, but I have some concerns about that. First,
> it's mixing complicated solutions to different problems (bridging the gap
> between a flat namespace and a hierarchical namespace vs. solving
> inconsistency). Second, it's S3-specific, whereas other objects stores could
> use virtually identical solutions. And third, we can't do things like atomic
> renames in a true sense. There would have to be some trade-offs specific to
> HBase's needs and it's better if we can solve that in an HBase-specific
> module without mixing all that logic in with the rest of S3A.
> Ideas to solve this above the FileSystem layer have been proposed and
> considered (HBASE-20431, for one), and maybe that's the right way forward
> long-term, but it certainly seems to be a hard problem and hasn't been done
> yet. But I don't know enough of all the internal considerations to make much
> of a judgment on that myself.
> I propose a FileSystem implementation that wraps another FileSystem instance
> and provides locking of FileSystem operations to ensure correct semantics.
> Locking could quite possibly be done on the same ZooKeeper ensemble as an
> HBase cluster already uses (I'm sure there are some performance
> considerations here that deserve more attention). I've put together a
> proof-of-concept on which I've tested some aspects of atomic renames and
> atomic file creates. Both of these tests fail reliably on a naked s3a
> instance. I've also done a small YCSB run against a small cluster to sanity
> check other functionality and was successful. I will post the patch, and my
> laundry list of things that still need work. The WAL is still placed on HDFS,
> but the HBase root directory is otherwise on S3.
> Note that my prototype is built on Hadoop's source tree right now. That's
> purely for my convenience in putting it together quickly, as that's where I
> mostly work. I actually think long-term, if this is accepted as a good
> solution, it makes sense to live in HBase (or it's own repository). It only
> depends on stable, public APIs in Hadoop and is targeted entirely at HBase's
> needs, so it should be able to iterate on the HBase community's terms alone.
> Another idea [~ste...@apache.org] proposed to me is that of an inode-based
> FileSystem that keeps hierarchical metadata in a more appropriate store that
> would allow the required transactions (maybe a special table in HBase could
> provide that store itself for other tables), and stores the underlying files
> with unique identifiers on S3. This allows renames to actually become fast
> instead of just large atomic operations. It does however place a strong
> dependency on the metadata store. I have not explored this idea much. My
> current proof-of-concept has been pleasantly simple, so I think it's the
> right solution unless it proves unable to provide the required performance
> characteristics.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22148) Provide an alternative to CellUtil.setTimestamp
[
https://issues.apache.org/jira/browse/HBASE-22148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808222#comment-16808222
]
Thomas D'Silva commented on HBASE-22148:
Before PHOENIX-4089 we were setting the timestamp of mutations from the client
(based on when we resolved the metadata of the table to which we were writing).
We had issues where the index table was getting out of sync with the data table
when there were concurrent updates to the same row. I'm not very familiar with
the Indexing coprocessor, maybe [~vincentpoon] knows the exact reason why this
was happening?
In PHOENIX-4089 we changed this so that the timestamp of mutations gets set on
the server via the Indexer coprocessor. After all the rows in a mini batch have
been locked the timestamp of each cell of every row gets set to the same value.
The index mutations are created by the Indexer coprocessor get the same
timestamp as the corresponding data table mutations.
> Provide an alternative to CellUtil.setTimestamp
>
>
> Key: HBASE-22148
> URL: https://issues.apache.org/jira/browse/HBASE-22148
> Project: HBase
> Issue Type: New Feature
> Components: API, Coprocessors
>Affects Versions: 3.0.0
>Reporter: Thomas D'Silva
>Priority: Blocker
> Labels: phoenix
> Fix For: 3.0.0
>
>
> {{CellUtil.setTimestamp}} has been deprecated in 2.0 and is marked for
> removal in 3.0. Phoenix currently uses this api to set the timestamp of cells
> in its indexing coprocessor for tables that have mutable indexes. We can't
> use the CellBuilder api since this involves creating a copy of the cell which
> will be expensive.
> FYI @stack
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21718) Implement Admin based on AsyncAdmin
[
https://issues.apache.org/jira/browse/HBASE-21718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808169#comment-16808169
]
Hadoop QA commented on HBASE-21718:
---
| (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:brown} Prechecks {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 34 new or modified test
files. {color} |
|| || || || {color:brown} HBASE-21512 Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
25s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
46s{color} | {color:green} HBASE-21512 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 7m
8s{color} | {color:green} HBASE-21512 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 3m
15s{color} | {color:green} HBASE-21512 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
24s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 7m
18s{color} | {color:green} HBASE-21512 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m
9s{color} | {color:green} HBASE-21512 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
17s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
38s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 7m
15s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 3m 28s{color}
| {color:red} hbase-server generated 1 new + 193 unchanged - 1 fixed = 194
total (was 194) {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 42s{color}
| {color:red} hbase-backup generated 1 new + 51 unchanged - 1 fixed = 52 total
(was 52) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
38s{color} | {color:green} The patch passed checkstyle in hbase-client {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
23s{color} | {color:green} hbase-server: The patch generated 0 new + 381
unchanged - 1 fixed = 381 total (was 382) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
22s{color} | {color:green} The patch passed checkstyle in hbase-mapreduce
{color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
33s{color} | {color:green} The patch passed checkstyle in hbase-thrift {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
16s{color} | {color:green} The patch passed checkstyle in hbase-backup {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} shadedjars {color} | {color:green} 5m
8s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
10m 4s{color} | {color:green} Patch does not cause any errors with Hadoop
2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 8m
6s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m
9s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m
42s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}280m 6s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 24m
35s{color} | {color:green} hbase-mapreduce
[jira] [Updated] (HBASE-22060) postOpenDeployTasks could send OPENED region transition state to the wrong master
[
https://issues.apache.org/jira/browse/HBASE-22060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bahram Chehrazy updated HBASE-22060:
Attachment:
Reset-cached-rssStub-on-region-servers-as-soon-as-the-master-changes-v2.patch
> postOpenDeployTasks could send OPENED region transition state to the wrong
> master
> -
>
> Key: HBASE-22060
> URL: https://issues.apache.org/jira/browse/HBASE-22060
> Project: HBase
> Issue Type: Bug
> Components: amv2, proc-v2
>Affects Versions: 3.0.0
>Reporter: Bahram Chehrazy
>Assignee: Duo Zhang
>Priority: Critical
> Attachments:
> Reset-cached-rssStub-on-region-servers-as-soon-as-the-master-changes-v2.patch,
> Reset-cached-rssStub-on-region-servers-as-soon-as-the-master-changes.patch
>
>
> As was reported in HBASE-21788, we have repeatedly seen regions getting stuck
> in OPENING after master restarts. Here is one scenario that I've observed
> recently:
>
> 1) There is a region is transit (RIT).
> 2) The active master aborts and begins shutting down.
> 3) The backup master becomes active quickly, finds the RIT, creates
> OpenRegionProcedure and send request to some server.
> 4) The server quickly opens the region and posts OPENED state transition, but
> it uses its cached master instead of the new one.
> 5) The old active master which had not completely shutdown its assignment
> manager yet, notes the OPENED state report and ignores it. Because no
> corresponding procedure can be found.
> 6) The new master waits forever for a response to its OPEN region request.
>
> This happens more often with the meta region because it's small and takes a
> few seconds to open. Below are some related logs:
> *Previous HMaster:*
> 2019-03-14 13:19:16,310 ERROR [PEWorker-1] master.HMaster: * ABORTING
> master ,17000,1552438242232: Shutting down HBase cluster: file
> system not available *
> 2019-03-14 13:19:16,310 INFO [PEWorker-1] regionserver.HRegionServer: *
> STOPPING region server ',17000,1552438242232' *
> 2019-03-14 13:20:54,358 WARN
> [RpcServer.priority.FPBQ.Fifo.handler=11,queue=1,port=17000]
> assignment.AssignmentManager: No matching procedure found for rit=OPEN,
> location=*,17020,1552561955412, table=hbase:meta,
> region=1588230740 transition to OPENED
> 2019-03-14 13:20:55,707 INFO [master/:17000]
> assignment.AssignmentManager: Stopping assignment manager
> *New HMaster logs:*
> 2019-03-14 13:19:16,907 INFO [master/:17000:becomeActiveMaster]
> master.ActiveMasterManager: Deleting ZNode for
> /HBaseServerZnodeCommonDir/**/backup-masters/,17000,1552438259871
> from backup master directory
> 2019-03-14 13:19:17,031 INFO [master/:17000:becomeActiveMaster]
> master.ActiveMasterManager: Registered as active
> master=,17000,1552438259871
> 2019-03-14 13:20:52,017 INFO [PEWorker-12] zookeeper.MetaTableLocator:
> Setting hbase:meta (replicaId=0) location in ZooKeeper as
> ,17020,1552536956826
> 2019-03-14 13:20:52,105 INFO [PEWorker-12] procedure2.ProcedureExecutor:
> Initialized subprocedures=[\{pid=178230, ppid=178229, state=RUNNABLE,
> hasLock=false; org.apache.hadoop.hbase.master.assignment.OpenRegionProcedure}]
>
> *HServer logs:*
> 2019-03-14 13:20:52,708 INFO [RS_CLOSE_META-regionserver/:17020-0]
> handler.AssignRegionHandler: Open hbase:meta,,1.1588230740
> 2019-03-14 13:20:54,353 INFO [RS_CLOSE_META-regionserver/:17020-0]
> regionserver.HRegion: Opened 1588230740; next sequenceid=229166
> 2019-03-14 13:20:54,356 INFO [RS_CLOSE_META-regionserver/:17020-0]
> regionserver.HRegionServer: Post open deploy tasks for
> hbase:meta,,1.1588230740
> 2019-03-14 13:20:54,358 INFO [RS_CLOSE_META-regionserver/:17020-0]
> handler.AssignRegionHandler: Opened hbase:meta,,1.1588230740
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-22149) HBOSS: A FileSystem implementation to provide HBase's required semantics
[ https://issues.apache.org/jira/browse/HBASE-22149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Mackrory updated HBASE-22149: -- Description: (Have been using the name HBOSS for HBase / Object Store Semantics) I've had some thoughts about how to solve the problem of running HBase on object stores. There has been some thought in the past about adding the required semantics to S3Guard, but I have some concerns about that. First, it's mixing complicated solutions to different problems (bridging the gap between a flat namespace and a hierarchical namespace vs. solving inconsistency). Second, it's S3-specific, whereas other objects stores could use virtually identical solutions. And third, we can't do things like atomic renames in a true sense. There would have to be some trade-offs specific to HBase's needs and it's better if we can solve that in an HBase-specific module without mixing all that logic in with the rest of S3A. Ideas to solve this above the FileSystem layer have been proposed and considered (HBASE-20431, for one), and maybe that's the right way forward long-term, but it certainly seems to be a hard problem and hasn't been done yet. But I don't know enough of all the internal considerations to make much of a judgment on that myself. I propose a FileSystem implementation that wraps another FileSystem instance and provides locking of FileSystem operations to ensure correct semantics. Locking could quite possibly be done on the same ZooKeeper ensemble as an HBase cluster already uses (I'm sure there are some performance considerations here that deserve more attention). I've put together a proof-of-concept on which I've tested some aspects of atomic renames and atomic file creates. Both of these tests fail reliably on a naked s3a instance. I've also done a small YCSB run against a small cluster to sanity check other functionality and was successful. I will post the patch, and my laundry list of things that still need work. The WAL is still placed on HDFS, but the HBase root directory is otherwise on S3. Note that my prototype is built on Hadoop's source tree right now. That's purely for my convenience in putting it together quickly, as that's where I mostly work. I actually think long-term, if this is accepted as a good solution, it makes sense to live in HBase (or it's own repository). It only depends on stable, public APIs in Hadoop and is targeted entirely at HBase's needs, so it should be able to iterate on the HBase community's terms alone. Another idea [~ste...@apache.org] proposed to me is that of an inode-based FileSystem that keeps hierarchical metadata in a more appropriate store that would allow the required transactions (maybe a special table in HBase could provide that store itself for other tables), and stores the underlying files with unique identifiers on S3. This allows renames to actually become fast instead of just large atomic operations. It does however place a strong dependency on the metadata store. I have not explored this idea much. My current proof-of-concept has been pleasantly simple, so I think it's the right solution unless it proves unable to provide the required performance characteristics. was: I've had some thoughts about how to solve the problem of running HBase on object stores. There has been some thought in the past about adding the required semantics to S3Guard, but I have some concerns about that. First, it's mixing complicated solutions to different problems (bridging the gap between a flat namespace and a hierarchical namespace vs. solving inconsistency). Second, it's S3-specific, whereas other objects stores could use virtually identical solutions. And third, we can't do things like atomic renames in a true sense. There would have to be some trade-offs specific to HBase's needs and it's better if we can solve that in an HBase-specific module without mixing all that logic in with the rest of S3A. Ideas to solve this above the FileSystem layer have been proposed and considered (HBASE-20431, for one), and maybe that's the right way forward long-term, but it certainly seems to be a hard problem and hasn't been done yet. But I don't know enough of all the internal considerations to make much of a judgment on that myself. I propose a FileSystem implementation that wraps another FileSystem instance and provides locking of FileSystem operations to ensure correct semantics. Locking could quite possibly be done on the same ZooKeeper ensemble as an HBase cluster already uses (I'm sure there are some performance considerations here that deserve more attention). I've put together a proof-of-concept on which I've tested some aspects of atomic renames and atomic file creates. Both of these tests fail reliably on a naked s3a instance. I've also done a small YCSB run against a small cluster to sanity check other functionality and was
[jira] [Updated] (HBASE-22149) HBOSS: A FileSystem implementation to provide HBase's required semantics
[ https://issues.apache.org/jira/browse/HBASE-22149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-22149: Priority: Critical (was: Major) > HBOSS: A FileSystem implementation to provide HBase's required semantics > > > Key: HBASE-22149 > URL: https://issues.apache.org/jira/browse/HBASE-22149 > Project: HBase > Issue Type: New Feature >Reporter: Sean Mackrory >Assignee: Sean Mackrory >Priority: Critical > Attachments: HBASE-22149-hadoop.patch > > > I've had some thoughts about how to solve the problem of running HBase on > object stores. There has been some thought in the past about adding the > required semantics to S3Guard, but I have some concerns about that. First, > it's mixing complicated solutions to different problems (bridging the gap > between a flat namespace and a hierarchical namespace vs. solving > inconsistency). Second, it's S3-specific, whereas other objects stores could > use virtually identical solutions. And third, we can't do things like atomic > renames in a true sense. There would have to be some trade-offs specific to > HBase's needs and it's better if we can solve that in an HBase-specific > module without mixing all that logic in with the rest of S3A. > Ideas to solve this above the FileSystem layer have been proposed and > considered (HBASE-20431, for one), and maybe that's the right way forward > long-term, but it certainly seems to be a hard problem and hasn't been done > yet. But I don't know enough of all the internal considerations to make much > of a judgment on that myself. > I propose a FileSystem implementation that wraps another FileSystem instance > and provides locking of FileSystem operations to ensure correct semantics. > Locking could quite possibly be done on the same ZooKeeper ensemble as an > HBase cluster already uses (I'm sure there are some performance > considerations here that deserve more attention). I've put together a > proof-of-concept on which I've tested some aspects of atomic renames and > atomic file creates. Both of these tests fail reliably on a naked s3a > instance. I've also done a small YCSB run against a small cluster to sanity > check other functionality and was successful. I will post the patch, and my > laundry list of things that still need work. The WAL is still placed on HDFS, > but the HBase root directory is otherwise on S3. > Note that my prototype is built on Hadoop's source tree right now. That's > purely for my convenience in putting it together quickly, as that's where I > mostly work. I actually think long-term, if this is accepted as a good > solution, it makes sense to live in HBase (or it's own repository). It only > depends on stable, public APIs in Hadoop and is targeted entirely at HBase's > needs, so it should be able to iterate on the HBase community's terms alone. > Another idea [~ste...@apache.org] proposed to me is that of an inode-based > FileSystem that keeps hierarchical metadata in a more appropriate store that > would allow the required transactions (maybe a special table in HBase could > provide that store itself for other tables), and stores the underlying files > with unique identifiers on S3. This allows renames to actually become fast > instead of just large atomic operations. It does however place a strong > dependency on the metadata store. I have not explored this idea much. My > current proof-of-concept has been pleasantly simple, so I think it's the > right solution unless it proves unable to provide the required performance > characteristics. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22149) HBOSS: A FileSystem implementation to provide HBase's required semantics
[ https://issues.apache.org/jira/browse/HBASE-22149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-22149: Component/s: Filesystem Integration > HBOSS: A FileSystem implementation to provide HBase's required semantics > > > Key: HBASE-22149 > URL: https://issues.apache.org/jira/browse/HBASE-22149 > Project: HBase > Issue Type: New Feature > Components: Filesystem Integration >Reporter: Sean Mackrory >Assignee: Sean Mackrory >Priority: Critical > Attachments: HBASE-22149-hadoop.patch > > > I've had some thoughts about how to solve the problem of running HBase on > object stores. There has been some thought in the past about adding the > required semantics to S3Guard, but I have some concerns about that. First, > it's mixing complicated solutions to different problems (bridging the gap > between a flat namespace and a hierarchical namespace vs. solving > inconsistency). Second, it's S3-specific, whereas other objects stores could > use virtually identical solutions. And third, we can't do things like atomic > renames in a true sense. There would have to be some trade-offs specific to > HBase's needs and it's better if we can solve that in an HBase-specific > module without mixing all that logic in with the rest of S3A. > Ideas to solve this above the FileSystem layer have been proposed and > considered (HBASE-20431, for one), and maybe that's the right way forward > long-term, but it certainly seems to be a hard problem and hasn't been done > yet. But I don't know enough of all the internal considerations to make much > of a judgment on that myself. > I propose a FileSystem implementation that wraps another FileSystem instance > and provides locking of FileSystem operations to ensure correct semantics. > Locking could quite possibly be done on the same ZooKeeper ensemble as an > HBase cluster already uses (I'm sure there are some performance > considerations here that deserve more attention). I've put together a > proof-of-concept on which I've tested some aspects of atomic renames and > atomic file creates. Both of these tests fail reliably on a naked s3a > instance. I've also done a small YCSB run against a small cluster to sanity > check other functionality and was successful. I will post the patch, and my > laundry list of things that still need work. The WAL is still placed on HDFS, > but the HBase root directory is otherwise on S3. > Note that my prototype is built on Hadoop's source tree right now. That's > purely for my convenience in putting it together quickly, as that's where I > mostly work. I actually think long-term, if this is accepted as a good > solution, it makes sense to live in HBase (or it's own repository). It only > depends on stable, public APIs in Hadoop and is targeted entirely at HBase's > needs, so it should be able to iterate on the HBase community's terms alone. > Another idea [~ste...@apache.org] proposed to me is that of an inode-based > FileSystem that keeps hierarchical metadata in a more appropriate store that > would allow the required transactions (maybe a special table in HBase could > provide that store itself for other tables), and stores the underlying files > with unique identifiers on S3. This allows renames to actually become fast > instead of just large atomic operations. It does however place a strong > dependency on the metadata store. I have not explored this idea much. My > current proof-of-concept has been pleasantly simple, so I think it's the > right solution unless it proves unable to provide the required performance > characteristics. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22149) HBOSS: A FileSystem implementation to provide HBase's required semantics
[ https://issues.apache.org/jira/browse/HBASE-22149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-22149: Issue Type: New Feature (was: Bug) > HBOSS: A FileSystem implementation to provide HBase's required semantics > > > Key: HBASE-22149 > URL: https://issues.apache.org/jira/browse/HBASE-22149 > Project: HBase > Issue Type: New Feature >Reporter: Sean Mackrory >Assignee: Sean Mackrory >Priority: Major > Attachments: HBASE-22149-hadoop.patch > > > I've had some thoughts about how to solve the problem of running HBase on > object stores. There has been some thought in the past about adding the > required semantics to S3Guard, but I have some concerns about that. First, > it's mixing complicated solutions to different problems (bridging the gap > between a flat namespace and a hierarchical namespace vs. solving > inconsistency). Second, it's S3-specific, whereas other objects stores could > use virtually identical solutions. And third, we can't do things like atomic > renames in a true sense. There would have to be some trade-offs specific to > HBase's needs and it's better if we can solve that in an HBase-specific > module without mixing all that logic in with the rest of S3A. > Ideas to solve this above the FileSystem layer have been proposed and > considered (HBASE-20431, for one), and maybe that's the right way forward > long-term, but it certainly seems to be a hard problem and hasn't been done > yet. But I don't know enough of all the internal considerations to make much > of a judgment on that myself. > I propose a FileSystem implementation that wraps another FileSystem instance > and provides locking of FileSystem operations to ensure correct semantics. > Locking could quite possibly be done on the same ZooKeeper ensemble as an > HBase cluster already uses (I'm sure there are some performance > considerations here that deserve more attention). I've put together a > proof-of-concept on which I've tested some aspects of atomic renames and > atomic file creates. Both of these tests fail reliably on a naked s3a > instance. I've also done a small YCSB run against a small cluster to sanity > check other functionality and was successful. I will post the patch, and my > laundry list of things that still need work. The WAL is still placed on HDFS, > but the HBase root directory is otherwise on S3. > Note that my prototype is built on Hadoop's source tree right now. That's > purely for my convenience in putting it together quickly, as that's where I > mostly work. I actually think long-term, if this is accepted as a good > solution, it makes sense to live in HBase (or it's own repository). It only > depends on stable, public APIs in Hadoop and is targeted entirely at HBase's > needs, so it should be able to iterate on the HBase community's terms alone. > Another idea [~ste...@apache.org] proposed to me is that of an inode-based > FileSystem that keeps hierarchical metadata in a more appropriate store that > would allow the required transactions (maybe a special table in HBase could > provide that store itself for other tables), and stores the underlying files > with unique identifiers on S3. This allows renames to actually become fast > instead of just large atomic operations. It does however place a strong > dependency on the metadata store. I have not explored this idea much. My > current proof-of-concept has been pleasantly simple, so I think it's the > right solution unless it proves unable to provide the required performance > characteristics. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22148) Provide an alternative to CellUtil.setTimestamp
[
https://issues.apache.org/jira/browse/HBASE-22148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808130#comment-16808130
]
stack commented on HBASE-22148:
---
You are trying to ensure that each data table entry has a unique timestamp? Are
the timestamps in the index table always unique? If so, how is that done?
Each cell gets its own unique sequenceid if that'd help?
I had a look at PHOENIX-4089. The language is speculative and talks about
"...based on the locking we do, Phoenix thinks a different Put was the last one
than HBase does, leading to inconsistencies." Are we trying to reorder Cells
that have arrived at hbase by setting timestamps?
Just trying to understand.
> Provide an alternative to CellUtil.setTimestamp
>
>
> Key: HBASE-22148
> URL: https://issues.apache.org/jira/browse/HBASE-22148
> Project: HBase
> Issue Type: New Feature
> Components: API, Coprocessors
>Affects Versions: 3.0.0
>Reporter: Thomas D'Silva
>Priority: Blocker
> Labels: phoenix
> Fix For: 3.0.0
>
>
> {{CellUtil.setTimestamp}} has been deprecated in 2.0 and is marked for
> removal in 3.0. Phoenix currently uses this api to set the timestamp of cells
> in its indexing coprocessor for tables that have mutable indexes. We can't
> use the CellBuilder api since this involves creating a copy of the cell which
> will be expensive.
> FYI @stack
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22149) HBOSS: A FileSystem implementation to provide HBase's required semantics
[ https://issues.apache.org/jira/browse/HBASE-22149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808127#comment-16808127 ] Sean Mackrory commented on HBASE-22149: --- I've attached HBASE-22149-hadoop.patch, which is my proof-of-concept built on the Hadoop source tree. The while(true)s and Thread.sleeps in TreeLockManager must be replaced by more robust retry logic. And I need to add support for globStatus() operations and deleteOnExit(), as HBase does appear to use them and they aren't quite as trivial as everything else. Symlinks and PathHandle are also unsupported, but they are unused and unsupported in s3a, so I have no plans to address that. A write-lock is acquired on a path when OutputStreams are created, and they are not released until the OutputStream is closed (whereas most operations are locking & unlocking in the same method call). I haven't done this with InputStreams and I'm not sure if that's required. OutputStreams require it to ensure create() is atomic, as s3a won't actually create a file on the underlying S3 bucket until later. With the exception of InputStreams, I've generally erred on the side of locking everything in the hope of starting out with correctness. As I do performance testing and identify any bottlenecks, it may be desirable to carefully consider if some locking should be removed where HBase's usage makes it safe to do so if it would streamline a particular bottleneck. > HBOSS: A FileSystem implementation to provide HBase's required semantics > > > Key: HBASE-22149 > URL: https://issues.apache.org/jira/browse/HBASE-22149 > Project: HBase > Issue Type: Bug >Reporter: Sean Mackrory >Assignee: Sean Mackrory >Priority: Major > Attachments: HBASE-22149-hadoop.patch > > > I've had some thoughts about how to solve the problem of running HBase on > object stores. There has been some thought in the past about adding the > required semantics to S3Guard, but I have some concerns about that. First, > it's mixing complicated solutions to different problems (bridging the gap > between a flat namespace and a hierarchical namespace vs. solving > inconsistency). Second, it's S3-specific, whereas other objects stores could > use virtually identical solutions. And third, we can't do things like atomic > renames in a true sense. There would have to be some trade-offs specific to > HBase's needs and it's better if we can solve that in an HBase-specific > module without mixing all that logic in with the rest of S3A. > Ideas to solve this above the FileSystem layer have been proposed and > considered (HBASE-20431, for one), and maybe that's the right way forward > long-term, but it certainly seems to be a hard problem and hasn't been done > yet. But I don't know enough of all the internal considerations to make much > of a judgment on that myself. > I propose a FileSystem implementation that wraps another FileSystem instance > and provides locking of FileSystem operations to ensure correct semantics. > Locking could quite possibly be done on the same ZooKeeper ensemble as an > HBase cluster already uses (I'm sure there are some performance > considerations here that deserve more attention). I've put together a > proof-of-concept on which I've tested some aspects of atomic renames and > atomic file creates. Both of these tests fail reliably on a naked s3a > instance. I've also done a small YCSB run against a small cluster to sanity > check other functionality and was successful. I will post the patch, and my > laundry list of things that still need work. The WAL is still placed on HDFS, > but the HBase root directory is otherwise on S3. > Note that my prototype is built on Hadoop's source tree right now. That's > purely for my convenience in putting it together quickly, as that's where I > mostly work. I actually think long-term, if this is accepted as a good > solution, it makes sense to live in HBase (or it's own repository). It only > depends on stable, public APIs in Hadoop and is targeted entirely at HBase's > needs, so it should be able to iterate on the HBase community's terms alone. > Another idea [~ste...@apache.org] proposed to me is that of an inode-based > FileSystem that keeps hierarchical metadata in a more appropriate store that > would allow the required transactions (maybe a special table in HBase could > provide that store itself for other tables), and stores the underlying files > with unique identifiers on S3. This allows renames to actually become fast > instead of just large atomic operations. It does however place a strong > dependency on the metadata store. I have not explored this idea much. My > current proof-of-concept has been pleasantly simple, so I think it's the > right
[jira] [Updated] (HBASE-22149) HBOSS: A FileSystem implementation to provide HBase's required semantics
[ https://issues.apache.org/jira/browse/HBASE-22149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Mackrory updated HBASE-22149: -- Attachment: HBASE-22149-hadoop.patch > HBOSS: A FileSystem implementation to provide HBase's required semantics > > > Key: HBASE-22149 > URL: https://issues.apache.org/jira/browse/HBASE-22149 > Project: HBase > Issue Type: Bug >Reporter: Sean Mackrory >Assignee: Sean Mackrory >Priority: Major > Attachments: HBASE-22149-hadoop.patch > > > I've had some thoughts about how to solve the problem of running HBase on > object stores. There has been some thought in the past about adding the > required semantics to S3Guard, but I have some concerns about that. First, > it's mixing complicated solutions to different problems (bridging the gap > between a flat namespace and a hierarchical namespace vs. solving > inconsistency). Second, it's S3-specific, whereas other objects stores could > use virtually identical solutions. And third, we can't do things like atomic > renames in a true sense. There would have to be some trade-offs specific to > HBase's needs and it's better if we can solve that in an HBase-specific > module without mixing all that logic in with the rest of S3A. > Ideas to solve this above the FileSystem layer have been proposed and > considered (HBASE-20431, for one), and maybe that's the right way forward > long-term, but it certainly seems to be a hard problem and hasn't been done > yet. But I don't know enough of all the internal considerations to make much > of a judgment on that myself. > I propose a FileSystem implementation that wraps another FileSystem instance > and provides locking of FileSystem operations to ensure correct semantics. > Locking could quite possibly be done on the same ZooKeeper ensemble as an > HBase cluster already uses (I'm sure there are some performance > considerations here that deserve more attention). I've put together a > proof-of-concept on which I've tested some aspects of atomic renames and > atomic file creates. Both of these tests fail reliably on a naked s3a > instance. I've also done a small YCSB run against a small cluster to sanity > check other functionality and was successful. I will post the patch, and my > laundry list of things that still need work. The WAL is still placed on HDFS, > but the HBase root directory is otherwise on S3. > Note that my prototype is built on Hadoop's source tree right now. That's > purely for my convenience in putting it together quickly, as that's where I > mostly work. I actually think long-term, if this is accepted as a good > solution, it makes sense to live in HBase (or it's own repository). It only > depends on stable, public APIs in Hadoop and is targeted entirely at HBase's > needs, so it should be able to iterate on the HBase community's terms alone. > Another idea [~ste...@apache.org] proposed to me is that of an inode-based > FileSystem that keeps hierarchical metadata in a more appropriate store that > would allow the required transactions (maybe a special table in HBase could > provide that store itself for other tables), and stores the underlying files > with unique identifiers on S3. This allows renames to actually become fast > instead of just large atomic operations. It does however place a strong > dependency on the metadata store. I have not explored this idea much. My > current proof-of-concept has been pleasantly simple, so I think it's the > right solution unless it proves unable to provide the required performance > characteristics. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22149) HBOSS: A FileSystem implementation to provide HBase's required semantics
[ https://issues.apache.org/jira/browse/HBASE-22149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Mackrory updated HBASE-22149: -- Description: I've had some thoughts about how to solve the problem of running HBase on object stores. There has been some thought in the past about adding the required semantics to S3Guard, but I have some concerns about that. First, it's mixing complicated solutions to different problems (bridging the gap between a flat namespace and a hierarchical namespace vs. solving inconsistency). Second, it's S3-specific, whereas other objects stores could use virtually identical solutions. And third, we can't do things like atomic renames in a true sense. There would have to be some trade-offs specific to HBase's needs and it's better if we can solve that in an HBase-specific module without mixing all that logic in with the rest of S3A. Ideas to solve this above the FileSystem layer have been proposed and considered (HBASE-20431, for one), and maybe that's the right way forward long-term, but it certainly seems to be a hard problem and hasn't been done yet. But I don't know enough of all the internal considerations to make much of a judgment on that myself. I propose a FileSystem implementation that wraps another FileSystem instance and provides locking of FileSystem operations to ensure correct semantics. Locking could quite possibly be done on the same ZooKeeper ensemble as an HBase cluster already uses (I'm sure there are some performance considerations here that deserve more attention). I've put together a proof-of-concept on which I've tested some aspects of atomic renames and atomic file creates. Both of these tests fail reliably on a naked s3a instance. I've also done a small YCSB run against a small cluster to sanity check other functionality and was successful. I will post the patch, and my laundry list of things that still need work. The WAL is still placed on HDFS, but the HBase root directory is otherwise on S3. Note that my prototype is built on Hadoop's source tree right now. That's purely for my convenience in putting it together quickly, as that's where I mostly work. I actually think long-term, if this is accepted as a good solution, it makes sense to live in HBase (or it's own repository). It only depends on stable, public APIs in Hadoop and is targeted entirely at HBase's needs, so it should be able to iterate on the HBase community's terms alone. Another idea [~ste...@apache.org] proposed to me is that of an inode-based FileSystem that keeps hierarchical metadata in a more appropriate store that would allow the required transactions (maybe a special table in HBase could provide that store itself for other tables), and stores the underlying files with unique identifiers on S3. This allows renames to actually become fast instead of just large atomic operations. It does however place a strong dependency on the metadata store. I have not explored this idea much. My current proof-of-concept has been pleasantly simple, so I think it's the right solution unless it proves unable to provide the required performance characteristics. was: I've had some thoughts about how to solve the problem of running HBase on object stores. There has been some thought in the past about adding the required semantics to S3Guard, but I have some concerns about that. First, it's mixing complicated solutions to different problems (bridging the gap between a flat namespace and a hierarchical namespace vs. solving inconsistency). Second, it's S3-specific, whereas other objects stores could use virtually identical solutions. And third, we can't do things like atomic renames in a true sense. There would have to be some trade-offs specific to HBase's needs and it's better if we can solve that in an HBase-specific module without mixing all that logic in with the rest of S3A. Ideas to solve this above the FileSystem layer have been proposed and considered (HBASE-20431, for one), and maybe that's the right way forward long-term, but it certainly seems to be a hard problem and hasn't been done yet. But I don't know enough of all the internal considerations to make much of a judgment on that myself. I propose a FileSystem implementation that wraps another FileSystem instance and provides locking of FileSystem operations to ensure correct semantics. Locking could quite possibly be done on the same ZooKeeper ensemble as an HBase cluster already uses (I'm sure there are some performance considerations here that deserve more attention). I've put together a proof-of-concept one which I've tested some aspects of atomic renames and atomic file creates. Both of these tests fail on a naked s3a instance. I've also done a small YCSB run against a small cluster to sanity check other functionality and was successful. I will post the patch, and my laundry list of things that still
[jira] [Updated] (HBASE-22149) HBOSS: A FileSystem implementation to provide HBase's required semantics
[ https://issues.apache.org/jira/browse/HBASE-22149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Mackrory updated HBASE-22149: -- Description: I've had some thoughts about how to solve the problem of running HBase on object stores. There has been some thought in the past about adding the required semantics to S3Guard, but I have some concerns about that. First, it's mixing complicated solutions to different problems (bridging the gap between a flat namespace and a hierarchical namespace vs. solving inconsistency). Second, it's S3-specific, whereas other objects stores could use virtually identical solutions. And third, we can't do things like atomic renames in a true sense. There would have to be some trade-offs specific to HBase's needs and it's better if we can solve that in an HBase-specific module without mixing all that logic in with the rest of S3A. Ideas to solve this above the FileSystem layer have been proposed and considered (HBASE-20431, for one), and maybe that's the right way forward long-term, but it certainly seems to be a hard problem and hasn't been done yet. But I don't know enough of all the internal considerations to make much of a judgment on that myself. I propose a FileSystem implementation that wraps another FileSystem instance and provides locking of FileSystem operations to ensure correct semantics. Locking could quite possibly be done on the same ZooKeeper ensemble as an HBase cluster already uses (I'm sure there are some performance considerations here that deserve more attention). I've put together a proof-of-concept one which I've tested some aspects of atomic renames and atomic file creates. Both of these tests fail on a naked s3a instance. I've also done a small YCSB run against a small cluster to sanity check other functionality and was successful. I will post the patch, and my laundry list of things that still need work. The WAL is still placed on HDFS, but the HBase root directory is otherwise on S3. Note that my prototype is built on Hadoop's source tree right now. That's purely for my convenience in putting it together quickly, as that's where I mostly work. I actually think long-term, if this is accepted as a good solution, it makes sense to live in HBase (or it's own repository). It only depends on stable, public APIs in Hadoop and is targeted entirely at HBase's needs, so it should be able to iterate on the HBase community's terms alone. Another idea [~ste...@apache.org] proposed to me is that of an inode-based FileSystem that keeps hierarchical metadata in a more appropriate store that would allow the required transactions (maybe a special table in HBase could provide that store itself for other tables), and stores the underlying files with unique identifiers on S3. This allows renames to actually become fast instead of just large atomic operations. It does however place a strong dependency on the metadata store. I have not explored this idea much. My current proof-of-concept has been pleasantly simple, so I think it's the right solution unless it proves unable to provide the required performance characteristics. was: I've had some thoughts about how to solve the problem of running HBase on object stores. There has been some thought in the past about adding the required semantics to S3Guard, but I have some concerns about that. First, it's mixing complicated solutions to different problems (bridging the gap between a flat namespace and a hierarchical namespace vs. solving inconsistency). Second, it's S3-specific, whereas other objects stores could use virtually identical solutions. And third, we can't do things like atomic renames in a true sense. There would have to be some trade-offs and it's better if we can solve that in an HBase-specific module without mixing all that logic in with the rest of S3A. Ideas to solve this above the FileSystem layer have been proposed and considered (HBASE-20431, for one), and maybe that's the right way forward long-term, but it certainly seems to be a hard problem and hasn't been done yet. But I don't know enough of all the internal considerations to make much of a judgment on that myself. I propose a FileSystem implementation that wraps another FileSystem instance and provides locking of FileSystem operations to ensure correct semantics. Locking could quite possibly be done on the same ZooKeeper ensemble as an HBase cluster already uses (I'm sure there are some performance considerations here that deserve more attention). I've put together a proof-of-concept one which I've tested some aspects of atomic renames and atomic file creates. Both of these tests fail on a naked s3a instance. I've also done a small YCSB run against a small cluster to sanity check other functionality and was successful. I will post the patch, and my laundry list of things that still need work. The WAL is still placed
[jira] [Created] (HBASE-22149) HBOSS: A FileSystem implementation to provide HBase's required semantics
Sean Mackrory created HBASE-22149: - Summary: HBOSS: A FileSystem implementation to provide HBase's required semantics Key: HBASE-22149 URL: https://issues.apache.org/jira/browse/HBASE-22149 Project: HBase Issue Type: Bug Reporter: Sean Mackrory Assignee: Sean Mackrory I've had some thoughts about how to solve the problem of running HBase on object stores. There has been some thought in the past about adding the required semantics to S3Guard, but I have some concerns about that. First, it's mixing complicated solutions to different problems (bridging the gap between a flat namespace and a hierarchical namespace vs. solving inconsistency). Second, it's S3-specific, whereas other objects stores could use virtually identical solutions. And third, we can't do things like atomic renames in a true sense. There would have to be some trade-offs and it's better if we can solve that in an HBase-specific module without mixing all that logic in with the rest of S3A. Ideas to solve this above the FileSystem layer have been proposed and considered (HBASE-20431, for one), and maybe that's the right way forward long-term, but it certainly seems to be a hard problem and hasn't been done yet. But I don't know enough of all the internal considerations to make much of a judgment on that myself. I propose a FileSystem implementation that wraps another FileSystem instance and provides locking of FileSystem operations to ensure correct semantics. Locking could quite possibly be done on the same ZooKeeper ensemble as an HBase cluster already uses (I'm sure there are some performance considerations here that deserve more attention). I've put together a proof-of-concept one which I've tested some aspects of atomic renames and atomic file creates. Both of these tests fail on a naked s3a instance. I've also done a small YCSB run against a small cluster to sanity check other functionality and was successful. I will post the patch, and my laundry list of things that still need work. The WAL is still placed on HDFS, but the HBase root directory is otherwise on S3. Note that my prototype is built on Hadoop's source tree right now. That's purely for my convenience in putting it together quickly, as that's where I mostly work. I actually think long-term, if this is accepted as a good solution, it makes sense to live in HBase (or it's own repository). It only depends on stable, public APIs in Hadoop and is targeted entirely at HBase's needs, so it should be able to iterate on the HBase community's terms alone. Another idea [~ste...@apache.org] proposed to me is that of an inode-based FileSystem that keeps hierarchical metadata in a more appropriate store that would allow the required transactions (maybe a special table in HBase could provide that store itself for other tables), and stores the underlying files with unique identifiers on S3. This allows renames to actually become fast instead of just large atomic operations. It does however place a strong dependency on the metadata store. I have not explored this idea much. My current proof-of-concept has been pleasantly simple, so I think it's the right solution unless it proves unable to provide the required performance characteristics. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22108) Avoid passing null in Admin methods
[
https://issues.apache.org/jira/browse/HBASE-22108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808112#comment-16808112
]
Hadoop QA commented on HBASE-22108:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 5m
2s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {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 36 new or modified test
files. {color} |
|| || || || {color:brown} branch-2 Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
26s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
30s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 5m
38s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
38s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
14s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
59s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
43s{color} | {color:green} branch-2 passed {color} |
|| || || || {color:brown} Patch Compile Tests {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} 4m
4s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 5m
46s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 5m
46s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
33s{color} | {color:green} hbase-client: The patch generated 0 new + 163
unchanged - 4 fixed = 163 total (was 167) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
12s{color} | {color:green} The patch passed checkstyle in hbase-server {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
28s{color} | {color:green} The patch passed checkstyle in hbase-thrift {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
11s{color} | {color:green} The patch passed checkstyle in hbase-rsgroup {color}
|
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
13s{color} | {color:green} The patch passed checkstyle in hbase-it {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} shadedjars {color} | {color:green} 4m
2s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
9m 0s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m
24s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
45s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m
18s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}309m 26s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 4m
21s{color} | {color:green} hbase-thrift in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 5m
4s{color} | {color:green} hbase-rsgroup in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m
[jira] [Commented] (HBASE-22128) Move namespace region then master crashed make deadlock
[
https://issues.apache.org/jira/browse/HBASE-22128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808099#comment-16808099
]
Hadoop QA commented on HBASE-22128:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
23s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {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:brown} branch-2.1 Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
1s{color} | {color:green} branch-2.1 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
43s{color} | {color:green} branch-2.1 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
4s{color} | {color:green} branch-2.1 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 3m
41s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
9s{color} | {color:green} branch-2.1 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
30s{color} | {color:green} branch-2.1 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
16s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
37s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m
37s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
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} shadedjars {color} | {color:green} 4m
6s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
8m 27s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
16s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
29s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}256m 48s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
34s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}295m 52s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.client.TestFromClientSideWithCoprocessor |
| | hadoop.hbase.client.TestAdmin1 |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:42ca976 |
| JIRA Issue | HBASE-22128 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12964584/HBASE-22128-branch-2.1-v5.patch
|
| Optional Tests | dupname asflicense javac javadoc unit findbugs
shadedjars hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 452b980be8cf 4.4.0-139-generic #165-Ubuntu SMP Wed Oct 24
10:58:50 UTC 2018 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build@2/component/dev-support/hbase-personality.sh
|
| git revision | branch-2.1 / dd19173fbd |
| maven | version: Apache Maven 3.5.4
(1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) |
| Default Java | 1.8.0_181 |
| findbugs | v3.1.11 |
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/16617/artifact/patchprocess/patch-unit-hbase-server.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/16617/testReport/ |
| Max. process+thread count | 5041
[jira] [Commented] (HBASE-22141) Fix TestAsyncDecommissionAdminApi
[
https://issues.apache.org/jira/browse/HBASE-22141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808059#comment-16808059
]
Hudson commented on HBASE-22141:
Results for branch branch-2.2
[build #149 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/149/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/149//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/149//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/149//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Fix TestAsyncDecommissionAdminApi
> -
>
> Key: HBASE-22141
> URL: https://issues.apache.org/jira/browse/HBASE-22141
> Project: HBase
> Issue Type: Sub-task
> Components: test
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.3.0
>
> Attachments: HBASE-22141.patch
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22147) Integrate the github pull request with hadoop QA.
[ https://issues.apache.org/jira/browse/HBASE-22147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808040#comment-16808040 ] Josh Elser commented on HBASE-22147: Blah, just saw that Zheng had done this :). Will watch this and poke infra if they don't act on it shortly. > Integrate the github pull request with hadoop QA. > - > > Key: HBASE-22147 > URL: https://issues.apache.org/jira/browse/HBASE-22147 > Project: HBase > Issue Type: Task >Reporter: Zheng Hu >Assignee: Zheng Hu >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22147) Integrate the github pull request with hadoop QA.
[ https://issues.apache.org/jira/browse/HBASE-22147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808034#comment-16808034 ] Josh Elser commented on HBASE-22147: Filed INFRA-18152. The last time I was here doing something similar for another project, this was a "done in a few minutes" sort of thing. > Integrate the github pull request with hadoop QA. > - > > Key: HBASE-22147 > URL: https://issues.apache.org/jira/browse/HBASE-22147 > Project: HBase > Issue Type: Task >Reporter: Zheng Hu >Assignee: Zheng Hu >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22147) Integrate the github pull request with hadoop QA.
[ https://issues.apache.org/jira/browse/HBASE-22147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808028#comment-16808028 ] Josh Elser commented on HBASE-22147: Yep. Let me ask infra. There is some magic only they can do behind the scenes. > Integrate the github pull request with hadoop QA. > - > > Key: HBASE-22147 > URL: https://issues.apache.org/jira/browse/HBASE-22147 > Project: HBase > Issue Type: Task >Reporter: Zheng Hu >Assignee: Zheng Hu >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21512) Introduce an AsyncClusterConnection and replace the usage of ClusterConnection
[
https://issues.apache.org/jira/browse/HBASE-21512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808024#comment-16808024
]
Hudson commented on HBASE-21512:
Results for branch HBASE-21512
[build #160 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21512/160/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21512/160//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21512/160//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21512/160//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Introduce an AsyncClusterConnection and replace the usage of ClusterConnection
> --
>
> Key: HBASE-21512
> URL: https://issues.apache.org/jira/browse/HBASE-21512
> Project: HBase
> Issue Type: Umbrella
>Reporter: Duo Zhang
>Priority: Major
> Fix For: 3.0.0
>
>
> At least for the RSProcedureDispatcher, with CompletableFuture we do not need
> to set a delay and use a thread pool any more, which could reduce the
> resource usage and also the latency.
> Once this is done, I think we can remove the ClusterConnection completely,
> and start to rewrite the old sync client based on the async client, which
> could reduce the code base a lot for our client.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22148) Provide an alternative to CellUtil.setTimestamp
[
https://issues.apache.org/jira/browse/HBASE-22148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808022#comment-16808022
]
Thomas D'Silva commented on HBASE-22148:
In Phoenix index maintenance for tables that are mutable (where rows can be
updated after they are created) is handled in a coprocessor. The coprocessor
sets the timestamp of the data table mutations in order to prevent index from
getting out of sync with the data table under high concurrency. The particular
case we are trying to handle is when the same Put occurs with the same time
stamp from different clients. In order to handle this we set the timestamp of
the data table mutation on the server side after the row has been locked
(PHOENIX-4089 has more details).
We use the {{preBatchMutate}} hook to set the timestamp of the data table
mutations using {{CellUtil.setTimestamp}}
(see
https://github.com/apache/phoenix/blob/507e6b5a0f0c94cd85ed359cd04d92e849743a31/phoenix-core/src/main/java/org/apache/phoenix/hbase/index/Indexer.java#L441)
> Provide an alternative to CellUtil.setTimestamp
>
>
> Key: HBASE-22148
> URL: https://issues.apache.org/jira/browse/HBASE-22148
> Project: HBase
> Issue Type: New Feature
> Components: API, Coprocessors
>Affects Versions: 3.0.0
>Reporter: Thomas D'Silva
>Priority: Blocker
> Labels: phoenix
> Fix For: 3.0.0
>
>
> {{CellUtil.setTimestamp}} has been deprecated in 2.0 and is marked for
> removal in 3.0. Phoenix currently uses this api to set the timestamp of cells
> in its indexing coprocessor for tables that have mutable indexes. We can't
> use the CellBuilder api since this involves creating a copy of the cell which
> will be expensive.
> FYI @stack
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22141) Fix TestAsyncDecommissionAdminApi
[
https://issues.apache.org/jira/browse/HBASE-22141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808012#comment-16808012
]
Hudson commented on HBASE-22141:
Results for branch branch-2
[build #1792 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1792/]:
(/) *{color:green}+1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1792//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1792//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1792//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Fix TestAsyncDecommissionAdminApi
> -
>
> Key: HBASE-22141
> URL: https://issues.apache.org/jira/browse/HBASE-22141
> Project: HBase
> Issue Type: Sub-task
> Components: test
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.3.0
>
> Attachments: HBASE-22141.patch
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22108) Avoid passing null in Admin methods
[
https://issues.apache.org/jira/browse/HBASE-22108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807989#comment-16807989
]
Hudson commented on HBASE-22108:
Results for branch master
[build #903 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/903/]: (x)
*{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/master/903//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/903//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/903//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Avoid passing null in Admin methods
> ---
>
> Key: HBASE-22108
> URL: https://issues.apache.org/jira/browse/HBASE-22108
> Project: HBase
> Issue Type: Task
> Components: Admin
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.3.0
>
> Attachments: HBASE-22108-branch-2.patch, HBASE-22108-v1.patch,
> HBASE-22108.patch
>
>
> For some methods we must pass null if we want specific behaviors, for
> example, move region to a random server, split region without providing an
> explicit split point, etc.
> We should provide methods without some parameters so user do not need to pass
> null.
> So in the future users do not need to guess whether a method accept null
> parameters, the answer is always no.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-22148) Provide an alternative to CellUtil.setTimestamp
[
https://issues.apache.org/jira/browse/HBASE-22148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey updated HBASE-22148:
Fix Version/s: 3.0.0
> Provide an alternative to CellUtil.setTimestamp
>
>
> Key: HBASE-22148
> URL: https://issues.apache.org/jira/browse/HBASE-22148
> Project: HBase
> Issue Type: New Feature
> Components: API, Coprocessors
>Affects Versions: 3.0.0
>Reporter: Thomas D'Silva
>Priority: Blocker
> Labels: phoenix
> Fix For: 3.0.0
>
>
> {{CellUtil.setTimestamp}} has been deprecated in 2.0 and is marked for
> removal in 3.0. Phoenix currently uses this api to set the timestamp of cells
> in its indexing coprocessor for tables that have mutable indexes. We can't
> use the CellBuilder api since this involves creating a copy of the cell which
> will be expensive.
> FYI @stack
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-22148) Provide an alternative to CellUtil.setTimestamp
[
https://issues.apache.org/jira/browse/HBASE-22148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey updated HBASE-22148:
Component/s: Coprocessors
> Provide an alternative to CellUtil.setTimestamp
>
>
> Key: HBASE-22148
> URL: https://issues.apache.org/jira/browse/HBASE-22148
> Project: HBase
> Issue Type: New Feature
> Components: API, Coprocessors
>Affects Versions: 3.0.0
>Reporter: Thomas D'Silva
>Priority: Blocker
>
> {{CellUtil.setTimestamp}} has been deprecated in 2.0 and is marked for
> removal in 3.0. Phoenix currently uses this api to set the timestamp of cells
> in its indexing coprocessor for tables that have mutable indexes. We can't
> use the CellBuilder api since this involves creating a copy of the cell which
> will be expensive.
> FYI @stack
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-22148) Provide an alternative to CellUtil.setTimestamp
[
https://issues.apache.org/jira/browse/HBASE-22148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey updated HBASE-22148:
Component/s: API
> Provide an alternative to CellUtil.setTimestamp
>
>
> Key: HBASE-22148
> URL: https://issues.apache.org/jira/browse/HBASE-22148
> Project: HBase
> Issue Type: New Feature
> Components: API
>Affects Versions: 3.0.0
>Reporter: Thomas D'Silva
>Priority: Blocker
>
> {{CellUtil.setTimestamp}} has been deprecated in 2.0 and is marked for
> removal in 3.0. Phoenix currently uses this api to set the timestamp of cells
> in its indexing coprocessor for tables that have mutable indexes. We can't
> use the CellBuilder api since this involves creating a copy of the cell which
> will be expensive.
> FYI @stack
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-22148) Provide an alternative to CellUtil.setTimestamp
[
https://issues.apache.org/jira/browse/HBASE-22148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey updated HBASE-22148:
Labels: phoenix (was: )
> Provide an alternative to CellUtil.setTimestamp
>
>
> Key: HBASE-22148
> URL: https://issues.apache.org/jira/browse/HBASE-22148
> Project: HBase
> Issue Type: New Feature
> Components: API, Coprocessors
>Affects Versions: 3.0.0
>Reporter: Thomas D'Silva
>Priority: Blocker
> Labels: phoenix
>
> {{CellUtil.setTimestamp}} has been deprecated in 2.0 and is marked for
> removal in 3.0. Phoenix currently uses this api to set the timestamp of cells
> in its indexing coprocessor for tables that have mutable indexes. We can't
> use the CellBuilder api since this involves creating a copy of the cell which
> will be expensive.
> FYI @stack
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22148) Provide an alternative to CellUtil.setTimestamp
[
https://issues.apache.org/jira/browse/HBASE-22148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807968#comment-16807968
]
stack commented on HBASE-22148:
---
Whats a mutable index [~tdsilva]? How does the CP work? It takes current edits
timestamp and uses that when it writes the index Cell? The Cell in the index
table is a newly created Cell or you are reading back an existing Cell and
doing an update on it? Thanks. Detail will help.
> Provide an alternative to CellUtil.setTimestamp
>
>
> Key: HBASE-22148
> URL: https://issues.apache.org/jira/browse/HBASE-22148
> Project: HBase
> Issue Type: New Feature
>Affects Versions: 3.0.0
>Reporter: Thomas D'Silva
>Priority: Blocker
>
> {{CellUtil.setTimestamp}} has been deprecated in 2.0 and is marked for
> removal in 3.0. Phoenix currently uses this api to set the timestamp of cells
> in its indexing coprocessor for tables that have mutable indexes. We can't
> use the CellBuilder api since this involves creating a copy of the cell which
> will be expensive.
> FYI @stack
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22060) postOpenDeployTasks could send OPENED region transition state to the wrong master
[
https://issues.apache.org/jira/browse/HBASE-22060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807965#comment-16807965
]
Bahram Chehrazy commented on HBASE-22060:
-
Yes, this is not a bullet proof solution. Forgot to mention that in my previous
comment. But nevertheless, it's an improvement to the existing code which keeps
using outdated cache util it fails. Besides, from the logs, there was a window
of over 1.5 minute between master aborting and closing the assignment manager.
This bug could happen in that wide window. With this simple fix, the window
would be reduced to a few seconds, if not milliseconds. Therefore, I think it
worth having it in the community as another layer of defense.
> postOpenDeployTasks could send OPENED region transition state to the wrong
> master
> -
>
> Key: HBASE-22060
> URL: https://issues.apache.org/jira/browse/HBASE-22060
> Project: HBase
> Issue Type: Bug
> Components: amv2, proc-v2
>Affects Versions: 3.0.0
>Reporter: Bahram Chehrazy
>Assignee: Duo Zhang
>Priority: Critical
> Attachments:
> Reset-cached-rssStub-on-region-servers-as-soon-as-the-master-changes.patch
>
>
> As was reported in HBASE-21788, we have repeatedly seen regions getting stuck
> in OPENING after master restarts. Here is one scenario that I've observed
> recently:
>
> 1) There is a region is transit (RIT).
> 2) The active master aborts and begins shutting down.
> 3) The backup master becomes active quickly, finds the RIT, creates
> OpenRegionProcedure and send request to some server.
> 4) The server quickly opens the region and posts OPENED state transition, but
> it uses its cached master instead of the new one.
> 5) The old active master which had not completely shutdown its assignment
> manager yet, notes the OPENED state report and ignores it. Because no
> corresponding procedure can be found.
> 6) The new master waits forever for a response to its OPEN region request.
>
> This happens more often with the meta region because it's small and takes a
> few seconds to open. Below are some related logs:
> *Previous HMaster:*
> 2019-03-14 13:19:16,310 ERROR [PEWorker-1] master.HMaster: * ABORTING
> master ,17000,1552438242232: Shutting down HBase cluster: file
> system not available *
> 2019-03-14 13:19:16,310 INFO [PEWorker-1] regionserver.HRegionServer: *
> STOPPING region server ',17000,1552438242232' *
> 2019-03-14 13:20:54,358 WARN
> [RpcServer.priority.FPBQ.Fifo.handler=11,queue=1,port=17000]
> assignment.AssignmentManager: No matching procedure found for rit=OPEN,
> location=*,17020,1552561955412, table=hbase:meta,
> region=1588230740 transition to OPENED
> 2019-03-14 13:20:55,707 INFO [master/:17000]
> assignment.AssignmentManager: Stopping assignment manager
> *New HMaster logs:*
> 2019-03-14 13:19:16,907 INFO [master/:17000:becomeActiveMaster]
> master.ActiveMasterManager: Deleting ZNode for
> /HBaseServerZnodeCommonDir/**/backup-masters/,17000,1552438259871
> from backup master directory
> 2019-03-14 13:19:17,031 INFO [master/:17000:becomeActiveMaster]
> master.ActiveMasterManager: Registered as active
> master=,17000,1552438259871
> 2019-03-14 13:20:52,017 INFO [PEWorker-12] zookeeper.MetaTableLocator:
> Setting hbase:meta (replicaId=0) location in ZooKeeper as
> ,17020,1552536956826
> 2019-03-14 13:20:52,105 INFO [PEWorker-12] procedure2.ProcedureExecutor:
> Initialized subprocedures=[\{pid=178230, ppid=178229, state=RUNNABLE,
> hasLock=false; org.apache.hadoop.hbase.master.assignment.OpenRegionProcedure}]
>
> *HServer logs:*
> 2019-03-14 13:20:52,708 INFO [RS_CLOSE_META-regionserver/:17020-0]
> handler.AssignRegionHandler: Open hbase:meta,,1.1588230740
> 2019-03-14 13:20:54,353 INFO [RS_CLOSE_META-regionserver/:17020-0]
> regionserver.HRegion: Opened 1588230740; next sequenceid=229166
> 2019-03-14 13:20:54,356 INFO [RS_CLOSE_META-regionserver/:17020-0]
> regionserver.HRegionServer: Post open deploy tasks for
> hbase:meta,,1.1588230740
> 2019-03-14 13:20:54,358 INFO [RS_CLOSE_META-regionserver/:17020-0]
> handler.AssignRegionHandler: Opened hbase:meta,,1.1588230740
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HBASE-22148) Provide an alternative to CellUtil.setTimestamp
Thomas D'Silva created HBASE-22148:
--
Summary: Provide an alternative to CellUtil.setTimestamp
Key: HBASE-22148
URL: https://issues.apache.org/jira/browse/HBASE-22148
Project: HBase
Issue Type: New Feature
Affects Versions: 3.0.0
Reporter: Thomas D'Silva
{{CellUtil.setTimestamp}} has been deprecated in 2.0 and is marked for removal
in 3.0. Phoenix currently uses this api to set the timestamp of cells in its
indexing coprocessor for tables that have mutable indexes. We can't use the
CellBuilder api since this involves creating a copy of the cell which will be
expensive.
FYI @stack
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22128) Move namespace region then master crashed make deadlock
[ https://issues.apache.org/jira/browse/HBASE-22128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807950#comment-16807950 ] Xu Cang commented on HBASE-22128: - +1, how about master branch? > Move namespace region then master crashed make deadlock > --- > > Key: HBASE-22128 > URL: https://issues.apache.org/jira/browse/HBASE-22128 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.5, 2.1.4 >Reporter: Bing Xiao >Assignee: Bing Xiao >Priority: Critical > Fix For: 2.0.6, 2.1.5 > > Attachments: HBASE-22128-branch-2.1-v1.patch, > HBASE-22128-branch-2.1-v2.patch, HBASE-22128-branch-2.1-v3.patch, > HBASE-22128-branch-2.1-v4.patch, HBASE-22128-branch-2.1-v5.patch > > > When move namespace region start unassign produre, after unassign procedure > finished namespace region will be offline. At the same time master crashed > then reboot will stuck, because master init is block by waiting namespace > table online ,at same time master init not finish so move region procedure > can not go on, make deadlock. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22128) Move namespace region then master crashed make deadlock
[ https://issues.apache.org/jira/browse/HBASE-22128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807942#comment-16807942 ] stack commented on HBASE-22128: --- +1 > Move namespace region then master crashed make deadlock > --- > > Key: HBASE-22128 > URL: https://issues.apache.org/jira/browse/HBASE-22128 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.5, 2.1.4 >Reporter: Bing Xiao >Assignee: Bing Xiao >Priority: Critical > Fix For: 2.0.6, 2.1.5 > > Attachments: HBASE-22128-branch-2.1-v1.patch, > HBASE-22128-branch-2.1-v2.patch, HBASE-22128-branch-2.1-v3.patch, > HBASE-22128-branch-2.1-v4.patch, HBASE-22128-branch-2.1-v5.patch > > > When move namespace region start unassign produre, after unassign procedure > finished namespace region will be offline. At the same time master crashed > then reboot will stuck, because master init is block by waiting namespace > table online ,at same time master init not finish so move region procedure > can not go on, make deadlock. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22147) Integrate the github pull request with hadoop QA.
[ https://issues.apache.org/jira/browse/HBASE-22147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807941#comment-16807941 ] stack commented on HBASE-22147: --- [~elserj] might know... (You did this recently mighty Josh?) > Integrate the github pull request with hadoop QA. > - > > Key: HBASE-22147 > URL: https://issues.apache.org/jira/browse/HBASE-22147 > Project: HBase > Issue Type: Task >Reporter: Zheng Hu >Assignee: Zheng Hu >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22147) Integrate the github pull request with hadoop QA.
[ https://issues.apache.org/jira/browse/HBASE-22147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807940#comment-16807940 ] stack commented on HBASE-22147: --- I can't make settings on our repo. INFRA ticket? (IIRC, even for the new gitbox repos over in hbase-connectors, etc., I had to go via INFRA). > Integrate the github pull request with hadoop QA. > - > > Key: HBASE-22147 > URL: https://issues.apache.org/jira/browse/HBASE-22147 > Project: HBase > Issue Type: Task >Reporter: Zheng Hu >Assignee: Zheng Hu >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22072) High read/write intensive regions may cause long crash recovery
[
https://issues.apache.org/jira/browse/HBASE-22072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807912#comment-16807912
]
Anoop Sam John commented on HBASE-22072:
Yes. After that I was also mentioning
{quote}
reopenAfterFlush() -> Ideally this should open scanners on new SF and MS after
a flush. But seems it is done much before. If it was taken in this method only,
u would not have faced the issue. So not just that flushLock.lock() is enough I
guess. Because this reopenAfterFlush() method is called when the StoreScanner
was not really closed but a next or seek call happens.
{quote}
So we would need closing state check as well.. That is not been a volatile var
but I would say that has to be.
> High read/write intensive regions may cause long crash recovery
> ---
>
> Key: HBASE-22072
> URL: https://issues.apache.org/jira/browse/HBASE-22072
> Project: HBase
> Issue Type: Bug
> Components: Performance, Recovery
>Affects Versions: 2.1.2
>Reporter: Pavel
>Priority: Major
>
> Compaction of high read loaded region may leave compacted files undeleted
> because of existing scan references:
> INFO org.apache.hadoop.hbase.regionserver.HStore - Can't archive compacted
> file hdfs://hdfs-ha/hbase... because of either isCompactedAway=true or file
> has reference, isReferencedInReads=true, refCount=1, skipping for now
> If region is either high write loaded this happens quite often and region may
> have few storefiles and tons of undeleted compacted hdfs files.
> Region keeps all that files (in my case thousands) untill graceful region
> closing procedure, which ignores existing references and drop obsolete files.
> It works fine unless consuming some extra hdfs space, but only in case of
> normal region closing. If region server crashes than new region server,
> responsible for that overfiling region, reads hdfs folder and try to deal
> with all undeleted files, producing tons of storefiles, compaction tasks and
> consuming abnormal amount of memory, wich may lead to OutOfMemory Exception
> and further region servers crash. This stops writing to region because number
> of storefiles reach *hbase.hstore.blockingStoreFiles* limit, forces high GC
> duty and may take hours to compact all files into working set of files.
> Workaround is a periodically check hdfs folders files count and force region
> assign for ones with too many files.
> It could be nice if regionserver had a setting similar to
> hbase.hstore.blockingStoreFiles and invoke attempt to drop undeleted
> compacted files if number of files reaches this setting.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22127) Ensure that the block cached in the LRUBlockCache offheap is allocated from heap
[
https://issues.apache.org/jira/browse/HBASE-22127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807835#comment-16807835
]
Hadoop QA commented on HBASE-22127:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
9s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {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 7 new or modified test
files. {color} |
|| || || || {color:brown} HBASE-21879 Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
31s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
20s{color} | {color:green} HBASE-21879 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
26s{color} | {color:green} HBASE-21879 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
38s{color} | {color:green} HBASE-21879 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
35s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
7s{color} | {color:green} HBASE-21879 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
47s{color} | {color:green} HBASE-21879 passed {color} |
|| || || || {color:brown} Patch Compile Tests {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} 4m
7s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
22s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 2m 44s{color}
| {color:red} hbase-server generated 1 new + 193 unchanged - 1 fixed = 194
total (was 194) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
24s{color} | {color:green} The patch passed checkstyle in hbase-common {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
15s{color} | {color:green} hbase-server: The patch generated 0 new + 81
unchanged - 4 fixed = 81 total (was 85) {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} shadedjars {color} | {color:green} 4m
34s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
8m 47s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
20s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
47s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
31s{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}143m 44s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
47s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}193m 13s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.client.TestAsyncDecommissionAdminApi |
| | hadoop.hbase.master.TestRestartCluster |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b |
| JIRA Issue | HBASE-22127 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12964554/HBASE-22127.HBASE-21879.v2.patch
|
| Optional Tests | dupname asflicense javac javadoc unit findbugs
shadedjars hadoopcheck hbaseanti
[jira] [Updated] (HBASE-22128) Move namespace region then master crashed make deadlock
[ https://issues.apache.org/jira/browse/HBASE-22128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bing Xiao updated HBASE-22128: -- Attachment: HBASE-22128-branch-2.1-v5.patch > Move namespace region then master crashed make deadlock > --- > > Key: HBASE-22128 > URL: https://issues.apache.org/jira/browse/HBASE-22128 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.5, 2.1.4 >Reporter: Bing Xiao >Assignee: Bing Xiao >Priority: Critical > Fix For: 2.0.6, 2.1.5 > > Attachments: HBASE-22128-branch-2.1-v1.patch, > HBASE-22128-branch-2.1-v2.patch, HBASE-22128-branch-2.1-v3.patch, > HBASE-22128-branch-2.1-v4.patch, HBASE-22128-branch-2.1-v5.patch > > > When move namespace region start unassign produre, after unassign procedure > finished namespace region will be offline. At the same time master crashed > then reboot will stuck, because master init is block by waiting namespace > table online ,at same time master init not finish so move region procedure > can not go on, make deadlock. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22119) Provide functions in RSGroupInfo to check if a group is the default group
[
https://issues.apache.org/jira/browse/HBASE-22119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807823#comment-16807823
]
Xiang Li commented on HBASE-22119:
--
[~xucang] the patches for master and branch-1 are ready. Please help to review
them at your convenience. Thanks!
> Provide functions in RSGroupInfo to check if a group is the default group
> -
>
> Key: HBASE-22119
> URL: https://issues.apache.org/jira/browse/HBASE-22119
> Project: HBase
> Issue Type: Improvement
> Components: rsgroup
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Minor
> Attachments: HBASE-22119.branch-1.000.patch,
> HBASE-22119.master.000.patch
>
>
> There are several places to check if a group is the "default" group, where
> the input could be a String or a RSGroupInfo.
> It is better to provide official functions in RSGroupInfo to tell if a group
> is the default group, so as to
> * Simply the code
> * Make it more safe. It is not safe as there is no null check like
> {code}
> if (!group.getName().equals(RSGroupInfo.DEFAULT_GROUP))
> {code}
> It is more safe to check like:
> {code}
> RSGroupInfo.DEFAULT_GROUP.equals(group.getName())
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21718) Implement Admin based on AsyncAdmin
[ https://issues.apache.org/jira/browse/HBASE-21718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-21718: -- Attachment: HBASE-21718-HBASE-21512-v3.patch > Implement Admin based on AsyncAdmin > --- > > Key: HBASE-21718 > URL: https://issues.apache.org/jira/browse/HBASE-21718 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Attachments: HBASE-21718-HBASE-21512-v1.patch, > HBASE-21718-HBASE-21512-v2.patch, HBASE-21718-HBASE-21512-v3.patch, > HBASE-21718-HBASE-21512.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22143) HBCK2 setRegionState command
[
https://issues.apache.org/jira/browse/HBASE-22143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807791#comment-16807791
]
Sean Busbey commented on HBASE-22143:
-
sounds reasonable. can you review HBASE-21393 and I'll review this one?
> HBCK2 setRegionState command
>
>
> Key: HBASE-22143
> URL: https://issues.apache.org/jira/browse/HBASE-22143
> Project: HBase
> Issue Type: New Feature
> Components: hbase-operator-tools, hbck2
>Reporter: Wellington Chevreuil
>Assignee: Wellington Chevreuil
>Priority: Minor
> Attachments: HBASE-22143.master.0001.patch
>
>
> Among some of the current AMv2 issues, we faced situation where some regions
> had state as OPENING in meta, with an RS startcode that was not valid
> anymore. There was no AP running, the region stays permanently being logged
> as IN-Transition on master logs, yet no procedure is really trying to bring
> it online. Current hbck2 unassigns/assigns commands didn't work either, as
> per the exception shown, it expects regions to be in state SPLITTING, SPLIT,
> MERGING, OPEN, or CLOSING:
> {noformat}
> WARN org.apache.hadoop.hbase.master.assignment.RegionTransitionProcedure:
> Failed transition, suspend 1secs pid=7093,
> state=RUNNABLE:REGION_TRANSITION_DISPATCH, locked=true; UnassignProcedure
> table=rc_accounts, region=db85127b77fa56f7ad44e2c988e53925,
> server=server1.example.com,16020,1552682193324; rit=OPENING,
> location=server1.example.com,16020,1552682193324; waiting on rectified
> condition fixed by other Procedure or operator intervention
> org.apache.hadoop.hbase.exceptions.UnexpectedStateException: Expected
> [SPLITTING, SPLIT, MERGING, OPEN, CLOSING] so could move to CLOSING but
> current state=OPENING
> at
> org.apache.hadoop.hbase.master.assignment.RegionStates$RegionStateNode.transitionState(RegionStates.java:166)
> at
> org.apache.hadoop.hbase.master.assignment.AssignmentManager.markRegionAsClosing(AssignmentManager.java:1479)
> at
> org.apache.hadoop.hbase.master.assignment.UnassignProcedure.updateTransition(UnassignProcedure.java:212)
> at
> org.apache.hadoop.hbase.master.assignment.RegionTransitionProcedure.execute(RegionTransitionProcedure.java:369)
> at
> org.apache.hadoop.hbase.master.assignment.RegionTransitionProcedure.execute(RegionTransitionProcedure.java:97)
> at org.apache.hadoop.hbase.procedure2.Procedure.doExecute(Procedure.java:957)
> at
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor.execProcedure(ProcedureExecutor.java:1835)
> at
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor.executeProcedure(ProcedureExecutor.java:1595){noformat}
> In this specific case, since we know the region is not actually being
> operated by any proc and is not really open anywhere, it's ok to manually set
> it's state to one of those assigns/unassigns can operate on, so this jira
> proposes a new hbck2 command that allows for arbitrarily set a region to a
> given state.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21512) Introduce an AsyncClusterConnection and replace the usage of ClusterConnection
[
https://issues.apache.org/jira/browse/HBASE-21512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807776#comment-16807776
]
Hudson commented on HBASE-21512:
Results for branch HBASE-21512
[build #159 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21512/159/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21512/159//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21512/159//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21512/159//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Introduce an AsyncClusterConnection and replace the usage of ClusterConnection
> --
>
> Key: HBASE-21512
> URL: https://issues.apache.org/jira/browse/HBASE-21512
> Project: HBase
> Issue Type: Umbrella
>Reporter: Duo Zhang
>Priority: Major
> Fix For: 3.0.0
>
>
> At least for the RSProcedureDispatcher, with CompletableFuture we do not need
> to set a delay and use a thread pool any more, which could reduce the
> resource usage and also the latency.
> Once this is done, I think we can remove the ClusterConnection completely,
> and start to rewrite the old sync client based on the async client, which
> could reduce the code base a lot for our client.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-22108) Avoid passing null in Admin methods
[ https://issues.apache.org/jira/browse/HBASE-22108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-22108: -- Attachment: HBASE-22108-branch-2.patch > Avoid passing null in Admin methods > --- > > Key: HBASE-22108 > URL: https://issues.apache.org/jira/browse/HBASE-22108 > Project: HBase > Issue Type: Task > Components: Admin >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.2.0, 2.3.0 > > Attachments: HBASE-22108-branch-2.patch, HBASE-22108-v1.patch, > HBASE-22108.patch > > > For some methods we must pass null if we want specific behaviors, for > example, move region to a random server, split region without providing an > explicit split point, etc. > We should provide methods without some parameters so user do not need to pass > null. > So in the future users do not need to guess whether a method accept null > parameters, the answer is always no. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21937) Make the Compression#decompress can accept ByteBuff as input
[
https://issues.apache.org/jira/browse/HBASE-21937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807754#comment-16807754
]
Zheng Hu commented on HBASE-21937:
--
Uploaded the initial patch.v1, because I found some UT were broken by this
issue, so I raised the priority. FYI [~anoop.hbase], once the HBASE-22127 get
merged, can help to start review this patch. Thanks.
> Make the Compression#decompress can accept ByteBuff as input
> -
>
> Key: HBASE-21937
> URL: https://issues.apache.org/jira/browse/HBASE-21937
> Project: HBase
> Issue Type: Sub-task
>Reporter: Zheng Hu
>Assignee: Zheng Hu
>Priority: Major
> Attachments: HBASE-21937.HBASE-21879.v1.patch
>
>
> When decompressing an compressed block, we are also allocating
> HeapByteBuffer for the unpacked block. should allocate ByteBuff from the
> global ByteBuffAllocator, skimmed the code, the key point is, we need an
> ByteBuff decompress interface, not the following:
> {code}
> # Compression.java
> public static void decompress(byte[] dest, int destOffset,
> InputStream bufferedBoundedStream, int compressedSize,
> int uncompressedSize, Compression.Algorithm compressAlgo)
> throws IOException {
> //...
> }
> {code}
> Not very high priority, let me make the block without compression to be
> offheap firstly.
> In HBASE-22005, I ignored the unit test:
> 1. TestLoadAndSwitchEncodeOnDisk ;
> 2. TestHFileBlock#testPreviousOffset;
> Need to resolve this issue and make those UT works fine.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21937) Make the Compression#decompress can accept ByteBuff as input
[
https://issues.apache.org/jira/browse/HBASE-21937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zheng Hu updated HBASE-21937:
-
Attachment: HBASE-21937.HBASE-21879.v1.patch
> Make the Compression#decompress can accept ByteBuff as input
> -
>
> Key: HBASE-21937
> URL: https://issues.apache.org/jira/browse/HBASE-21937
> Project: HBase
> Issue Type: Sub-task
>Reporter: Zheng Hu
>Assignee: Zheng Hu
>Priority: Major
> Attachments: HBASE-21937.HBASE-21879.v1.patch
>
>
> When decompressing an compressed block, we are also allocating
> HeapByteBuffer for the unpacked block. should allocate ByteBuff from the
> global ByteBuffAllocator, skimmed the code, the key point is, we need an
> ByteBuff decompress interface, not the following:
> {code}
> # Compression.java
> public static void decompress(byte[] dest, int destOffset,
> InputStream bufferedBoundedStream, int compressedSize,
> int uncompressedSize, Compression.Algorithm compressAlgo)
> throws IOException {
> //...
> }
> {code}
> Not very high priority, let me make the block without compression to be
> offheap firstly.
> In HBASE-22005, I ignored the unit test:
> 1. TestLoadAndSwitchEncodeOnDisk ;
> 2. TestHFileBlock#testPreviousOffset;
> Need to resolve this issue and make those UT works fine.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22147) Integrate the github pull request with hadoop QA.
[ https://issues.apache.org/jira/browse/HBASE-22147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807747#comment-16807747 ] Duo Zhang commented on HBASE-22147: --- I think we can just copy the Jenkinsfile from hadoop and make use of it. I have the permission to create a jenkins job but I do not have the permission to modify the github repo to add webhooks. [~stack] Do you have permissions on the github repo? I mean, if you can see the settings tab on github? Thanks. > Integrate the github pull request with hadoop QA. > - > > Key: HBASE-22147 > URL: https://issues.apache.org/jira/browse/HBASE-22147 > Project: HBase > Issue Type: Task >Reporter: Zheng Hu >Assignee: Zheng Hu >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20662) Increasing space quota on a violated table does not remove SpaceViolationPolicy.DISABLE enforcement
[
https://issues.apache.org/jira/browse/HBASE-20662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807739#comment-16807739
]
Uma Maheswari commented on HBASE-20662:
---
HBASE-22146 is created for the issue related to Disable Violation policy not
woring in NS level
> Increasing space quota on a violated table does not remove
> SpaceViolationPolicy.DISABLE enforcement
> ---
>
> Key: HBASE-20662
> URL: https://issues.apache.org/jira/browse/HBASE-20662
> Project: HBase
> Issue Type: Bug
>Affects Versions: 3.0.0, 2.0.0
>Reporter: Nihal Jain
>Assignee: Nihal Jain
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.0.6, 2.1.5
>
> Attachments: HBASE-20662.branch-2.1.001.patch,
> HBASE-20662.master.001.patch, HBASE-20662.master.002.patch,
> HBASE-20662.master.003.patch, HBASE-20662.master.004.patch,
> HBASE-20662.master.004.patch, HBASE-20662.master.005.patch,
> HBASE-20662.master.006.patch, HBASE-20662.master.007.patch,
> HBASE-20662.master.008.patch, HBASE-20662.master.008.patch,
> HBASE-20662.master.009.patch, HBASE-20662.master.009.patch,
> HBASE-20662.master.010.patch, screenshot.png
>
>
> *Steps to reproduce*
> * Create a table and set quota with {{SpaceViolationPolicy.DISABLE}} having
> limit say 2MB
> * Now put rows until space quota is violated and table gets disabled
> * Next, increase space quota with limit say 4MB on the table
> * Now try putting a row into the table
> {code:java}
> private void testSetQuotaThenViolateAndFinallyIncreaseQuota() throws
> Exception {
> SpaceViolationPolicy policy = SpaceViolationPolicy.DISABLE;
> Put put = new Put(Bytes.toBytes("to_reject"));
> put.addColumn(Bytes.toBytes(SpaceQuotaHelperForTests.F1),
> Bytes.toBytes("to"),
> Bytes.toBytes("reject"));
> // Do puts until we violate space policy
> final TableName tn = writeUntilViolationAndVerifyViolation(policy, put);
> // Now, increase limit
> setQuotaLimit(tn, policy, 4L);
> // Put some row now: should not violate as quota limit increased
> verifyNoViolation(policy, tn, put);
> }
> {code}
> *Expected*
> We should be able to put data as long as newly set quota limit is not reached
> *Actual*
> We fail to put any new row even after increasing limit
> *Root cause*
> Increasing quota on a violated table triggers the table to be enabled, but
> since the table is already in violation, the system does not allow it to be
> enabled (may be thinking that a user is trying to enable it)
> *Relevant exception trace*
> {noformat}
> 2018-05-31 00:34:27,563 INFO [regionserver/root1-ThinkPad-T440p:0.Chore.1]
> client.HBaseAdmin$14(844): Started enable of
> testSetQuotaAndThenIncreaseQuotaWithDisable0
> 2018-05-31 00:34:27,571 DEBUG
> [RpcServer.default.FPBQ.Fifo.handler=3,queue=0,port=42525]
> ipc.CallRunner(142): callId: 11 service: MasterService methodName:
> EnableTable size: 104 connection: 127.0.0.1:38030 deadline: 1527707127568,
> exception=org.apache.hadoop.hbase.security.AccessDeniedException: Enabling
> the table 'testSetQuotaAndThenIncreaseQuotaWithDisable0' is disallowed due to
> a violated space quota.
> 2018-05-31 00:34:27,571 ERROR [regionserver/root1-ThinkPad-T440p:0.Chore.1]
> quotas.RegionServerSpaceQuotaManager(210): Failed to disable space violation
> policy for testSetQuotaAndThenIncreaseQuotaWithDisable0. This table will
> remain in violation.
> org.apache.hadoop.hbase.security.AccessDeniedException:
> org.apache.hadoop.hbase.security.AccessDeniedException: Enabling the table
> 'testSetQuotaAndThenIncreaseQuotaWithDisable0' is disallowed due to a
> violated space quota.
> at org.apache.hadoop.hbase.master.HMaster$6.run(HMaster.java:2275)
> at
> org.apache.hadoop.hbase.master.procedure.MasterProcedureUtil.submitProcedure(MasterProcedureUtil.java:131)
> at org.apache.hadoop.hbase.master.HMaster.enableTable(HMaster.java:2258)
> at
> org.apache.hadoop.hbase.master.MasterRpcServices.enableTable(MasterRpcServices.java:725)
> at
> org.apache.hadoop.hbase.shaded.protobuf.generated.MasterProtos$MasterService$2.callBlockingMethod(MasterProtos.java)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:409)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:130)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:324)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:304)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
>
[jira] [Commented] (HBASE-21879) Read HFile's block to ByteBuffer directly instead of to byte for reducing young gc purpose
[
https://issues.apache.org/jira/browse/HBASE-21879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807724#comment-16807724
]
Hudson commented on HBASE-21879:
Results for branch HBASE-21879
[build #47 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21879/47/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21879/47//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21879/47//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21879/47//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Read HFile's block to ByteBuffer directly instead of to byte for reducing
> young gc purpose
> --
>
> Key: HBASE-21879
> URL: https://issues.apache.org/jira/browse/HBASE-21879
> Project: HBase
> Issue Type: Improvement
>Reporter: Zheng Hu
>Assignee: Zheng Hu
>Priority: Major
> Fix For: 3.0.0, 2.3.0
>
> Attachments: HBASE-21879.v1.patch, HBASE-21879.v1.patch,
> QPS-latencies-before-HBASE-21879.png, gc-data-before-HBASE-21879.png
>
>
> In HFileBlock#readBlockDataInternal, we have the following:
> {code}
> @VisibleForTesting
> protected HFileBlock readBlockDataInternal(FSDataInputStream is, long offset,
> long onDiskSizeWithHeaderL, boolean pread, boolean verifyChecksum,
> boolean updateMetrics)
> throws IOException {
> // .
> // TODO: Make this ByteBuffer-based. Will make it easier to go to HDFS with
> BBPool (offheap).
> byte [] onDiskBlock = new byte[onDiskSizeWithHeader + hdrSize];
> int nextBlockOnDiskSize = readAtOffset(is, onDiskBlock, preReadHeaderSize,
> onDiskSizeWithHeader - preReadHeaderSize, true, offset +
> preReadHeaderSize, pread);
> if (headerBuf != null) {
> // ...
> }
> // ...
> }
> {code}
> In the read path, we still read the block from hfile to on-heap byte[], then
> copy the on-heap byte[] to offheap bucket cache asynchronously, and in my
> 100% get performance test, I also observed some frequent young gc, The
> largest memory footprint in the young gen should be the on-heap block byte[].
> In fact, we can read HFile's block to ByteBuffer directly instead of to
> byte[] for reducing young gc purpose. we did not implement this before,
> because no ByteBuffer reading interface in the older HDFS client, but 2.7+
> has supported this now, so we can fix this now. I think.
> Will provide an patch and some perf-comparison for this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22072) High read/write intensive regions may cause long crash recovery
[
https://issues.apache.org/jira/browse/HBASE-22072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807708#comment-16807708
]
Pavel commented on HBASE-22072:
---
[~anoop.hbase]
{noformat}
StoreScanner#close() Also taking flushLock.lock() might solve this?{noformat}
I would say no, because StoreScanner can be closed before updateReaders called:
{code:java}
for (ChangedReadersObserver o : this.changedReaderObservers) {
List memStoreScanners;
this.lock.readLock().lock();
try {
memStoreScanners = this.memstore.getScanners(o.getReadPoint());
} finally {
this.lock.readLock().unlock();
}
//o might be already closed at this point
o.updateReaders(sfs, memStoreScanners);
{code}
> High read/write intensive regions may cause long crash recovery
> ---
>
> Key: HBASE-22072
> URL: https://issues.apache.org/jira/browse/HBASE-22072
> Project: HBase
> Issue Type: Bug
> Components: Performance, Recovery
>Affects Versions: 2.1.2
>Reporter: Pavel
>Priority: Major
>
> Compaction of high read loaded region may leave compacted files undeleted
> because of existing scan references:
> INFO org.apache.hadoop.hbase.regionserver.HStore - Can't archive compacted
> file hdfs://hdfs-ha/hbase... because of either isCompactedAway=true or file
> has reference, isReferencedInReads=true, refCount=1, skipping for now
> If region is either high write loaded this happens quite often and region may
> have few storefiles and tons of undeleted compacted hdfs files.
> Region keeps all that files (in my case thousands) untill graceful region
> closing procedure, which ignores existing references and drop obsolete files.
> It works fine unless consuming some extra hdfs space, but only in case of
> normal region closing. If region server crashes than new region server,
> responsible for that overfiling region, reads hdfs folder and try to deal
> with all undeleted files, producing tons of storefiles, compaction tasks and
> consuming abnormal amount of memory, wich may lead to OutOfMemory Exception
> and further region servers crash. This stops writing to region because number
> of storefiles reach *hbase.hstore.blockingStoreFiles* limit, forces high GC
> duty and may take hours to compact all files into working set of files.
> Workaround is a periodically check hdfs folders files count and force region
> assign for ones with too many files.
> It could be nice if regionserver had a setting similar to
> hbase.hstore.blockingStoreFiles and invoke attempt to drop undeleted
> compacted files if number of files reaches this setting.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
