[jira] [Commented] (HBASE-18637) Update the link of "Bending time in HBase"
[
https://issues.apache.org/jira/browse/HBASE-18637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16134790#comment-16134790
]
Hadoop QA commented on HBASE-18637:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
19s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
36s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
42s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m
33s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
32s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
40s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
34m 28s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m
49s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}110m 28s{color}
| {color:red} root in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
26s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}161m 46s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Timed out junit tests |
org.apache.hadoop.hbase.master.procedure.TestDisableTableProcedure |
| | org.apache.hadoop.hbase.master.procedure.TestModifyTableProcedure |
| | org.apache.hadoop.hbase.master.procedure.TestCreateTableProcedure |
| | org.apache.hadoop.hbase.master.procedure.TestEnableTableProcedure |
| | org.apache.hadoop.hbase.master.procedure.TestServerCrashProcedure |
| | org.apache.hadoop.hbase.master.procedure.TestDeleteTableProcedure |
| | org.apache.hadoop.hbase.master.TestGetLastFlushedSequenceId |
| | org.apache.hadoop.hbase.master.balancer.TestStochasticLoadBalancer2 |
| | org.apache.hadoop.hbase.master.TestAssignmentManagerMetrics |
| | org.apache.hadoop.hbase.namespace.TestNamespaceAuditor |
| | org.apache.hadoop.hbase.TestHBaseTestingUtility |
| | org.apache.hadoop.hbase.mapred.TestTableInputFormat |
| | org.apache.hadoop.hbase.TestMultiVersions |
| | org.apache.hadoop.hbase.quotas.TestQuotaStatusRPCs |
| |
org.apache.hadoop.hbase.security.visibility.TestVisibilityLablesWithGroups |
| | org.apache.hadoop.hbase.client.TestAsyncNonMetaRegionLocator |
| | org.apache.hadoop.hbase.security.access.TestAccessController2 |
| | org.apache.hadoop.hbase.mapred.TestTableMapReduceUtil |
| | org.apache.hadoop.hbase.quotas.TestMasterSpaceQuotaObserver |
| | org.apache.hadoop.hbase.client.TestAsyncRegionLocatorTimeout |
| | org.apache.hadoop.hbase.master.TestAssignmentListener |
| | org.apache.hadoop.hbase.master.TestMasterFailoverBalancerPersistence |
| | org.apache.hadoop.hbase.constraint.TestConstraint |
| | org.apache.hadoop.hbase.master.cleaner.TestSnapshotFromMaster |
| | org.apache.hadoop.hbase.client.TestMultiRespectsLimits |
| | org.apache.hadoop.hbase.quotas.TestRegionSizeUse |
| |
org.apache.hadoop.hbase.security.visibility.TestVisibilityLabelsWithDefaultVisLabelService
|
| | org.apache.hadoop.hbase.client.TestMetaWithReplicas |
| |
org.apache.hadoop.hbase.master.normalizer.TestSimpleRegionNormalizerOnCluster |
| | org.apache.hadoop.hbase.master.TestTableStateManager |
| | org.apache.hadoop.hbase.master.cleaner.TestReplicationZKNodeCleaner |
| | org.apache.hadoop.hbase.master.assignment.TestAssignmentOnRSCrash |
| |
org.apache.hadoop.hbase.security.visibility.TestVisibilityLabelsWithCustomVisLabService
|
| | org.apache.hadoop.hbase.master.TestSplitLogManager |
| | org.apache.hadoop.hbase.master.procedure.TestWALProced
[jira] [Commented] (HBASE-18640) Move mapreduce out of hbase-server into separate hbase-mapreduce moduel
[ https://issues.apache.org/jira/browse/HBASE-18640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16134755#comment-16134755 ] Appy commented on HBASE-18640: -- i have strong gut feeling of having two module: hbase-mapreduce-util (independent of hbase-server) and hbase-mapreduce, but the our current state of things don't make it easy. So the reasons: For: - we have 60 or so classes which don't need hbase-server. Having them separate from the 20 which need hbase-server, feels great right? Against: - tests for many of these 60 classes use HBTU, which means their test will have to remain in either hbase-server (yuk!) or the other module (yuk again!). But these are tests and internal stuff only, so maybe we okay with this situation - need tying the two modules together for yetus precommits However, i still feel that two modules will definitely be a better organization for long term. And we can move the tests back to right module once testing util is split apart. > Move mapreduce out of hbase-server into separate hbase-mapreduce moduel > --- > > Key: HBASE-18640 > URL: https://issues.apache.org/jira/browse/HBASE-18640 > Project: HBase > Issue Type: Bug >Reporter: Appy >Assignee: Appy > Attachments: HBASE-18640.master.001.patch, > HBASE-18640.master.002.patch > > > (Couldn't find another dedicated jira, so creating new one). > Uploaded patch which is moving ~60 files to the new module. Few notes: > - The classes remaining in hbase-server are the ones which are intensively > coupled with visibility labels/wal/filesystem/hfile. These can not be > migrated to new module until corresponding subcomponents are untangled out of > hbase-server into their own separate modules. > - Almost all mapreduce tests uses HBaseTestingUtil, so they can't be moved to > hbase-mapreduce module. Given these dependency constraints, one way would be > having a separate module for tests: > hbase-mapreduce < hbase-server <--- hbase-mapreduce-tests > Imo, this makes sense and looks fine. > The only issue is - yetus' pre-commit. It won't run tests in > hbase-mapreduce-tests module if something changed in just hbase-mapreduce. > However, yetus' limitation shouldn't warrant against the idea. > So i'd say that we should go that way, unless there are better suggestions. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18448) Added support for refreshing HFiles through API and shell
[
https://issues.apache.org/jira/browse/HBASE-18448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16134731#comment-16134731
]
Hadoop QA commented on HBASE-18448:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
24s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 2 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
24s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
49s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
5s{color} | {color:green} branch-1 passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
19s{color} | {color:green} branch-1 passed with JDK v1.7.0_131 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 13m
45s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
19s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 8m
2s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
24s{color} | {color:green} branch-1 passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
46s{color} | {color:green} branch-1 passed with JDK v1.7.0_131 {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
12s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
19s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
2s{color} | {color:green} the patch passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 1m
2s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
18s{color} | {color:green} hbase-protocol in the patch passed with JDK
v1.8.0_144. {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
31s{color} | {color:green} hbase-server-jdk1.8.0_144 with JDK v1.8.0_144
generated 0 new + 5 unchanged - 5 fixed = 5 total (was 10) {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
13s{color} | {color:green} hbase-examples in the patch passed with JDK
v1.8.0_144. {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
10s{color} | {color:green} the patch passed with JDK v1.7.0_131 {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 1m
10s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
20s{color} | {color:green} hbase-protocol in the patch passed with JDK
v1.7.0_131. {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
34s{color} | {color:green} hbase-server-jdk1.7.0_131 with JDK v1.7.0_131
generated 0 new + 5 unchanged - 5 fixed = 5 total (was 10) {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
16s{color} | {color:green} hbase-examples in the patch passed with JDK
v1.7.0_131. {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 6m
54s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
39s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m
1s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
15m 17s{color} | {color:green} The patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color}
[jira] [Commented] (HBASE-18638) The old cells will return to client if the new cells are deleted
[ https://issues.apache.org/jira/browse/HBASE-18638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16134719#comment-16134719 ] Anoop Sam John commented on HBASE-18638: So this is because of the way we handle the deletes and versions. When the latest version was deleted, this is not getting counted under the versions. So the old cell alone is getting exposed to versions and that it count as the 1st version and given back to client. There is an issue with handling of filtered out data and versions check. So with deleted data vs versions also same issue? ! > The old cells will return to client if the new cells are deleted > > > Key: HBASE-18638 > URL: https://issues.apache.org/jira/browse/HBASE-18638 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.1, 1.2.6, 2.0.0-alpha-1 >Reporter: Chia-Ping Tsai >Assignee: Chia-Ping Tsai >Priority: Critical > Fix For: 2.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7 > > Attachments: HBASE-18638-ut.patch, HBASE-18638-ut.patch > > > |put_0(t0)| > |put_1(t1)| <-- the latest cell > If we call get, the put_1 will return. That is good. > If we call get after a delete, the put_0 will return. That is weird. The > put_0 is old data, and it should be dropped in flush. For client, put_0 > should not exist after the put_1 happen. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18638) The old cells will return to client if the new cells are deleted
[ https://issues.apache.org/jira/browse/HBASE-18638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16134716#comment-16134716 ] Anoop Sam John commented on HBASE-18638: Oh wait.. So u mean there was no in btw flush at all.. ? > The old cells will return to client if the new cells are deleted > > > Key: HBASE-18638 > URL: https://issues.apache.org/jira/browse/HBASE-18638 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.1, 1.2.6, 2.0.0-alpha-1 >Reporter: Chia-Ping Tsai >Assignee: Chia-Ping Tsai >Priority: Critical > Fix For: 2.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7 > > Attachments: HBASE-18638-ut.patch, HBASE-18638-ut.patch > > > |put_0(t0)| > |put_1(t1)| <-- the latest cell > If we call get, the put_1 will return. That is good. > If we call get after a delete, the put_0 will return. That is weird. The > put_0 is old data, and it should be dropped in flush. For client, put_0 > should not exist after the put_1 happen. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18638) The old cells will return to client if the new cells are deleted
[ https://issues.apache.org/jira/browse/HBASE-18638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16134715#comment-16134715 ] Anoop Sam John commented on HBASE-18638: So here the versions for the CF is 1. Yes as per theory then the old should never get returned. But this is a known issue in HBase. The result depends on whether a compaction happened or not. Before the delete, if a compaction had happened, then u would have seen the expected result (no Cell). There was some jira to overcome this (and some other) known issues of this type. > The old cells will return to client if the new cells are deleted > > > Key: HBASE-18638 > URL: https://issues.apache.org/jira/browse/HBASE-18638 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.1, 1.2.6, 2.0.0-alpha-1 >Reporter: Chia-Ping Tsai >Assignee: Chia-Ping Tsai >Priority: Critical > Fix For: 2.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7 > > Attachments: HBASE-18638-ut.patch, HBASE-18638-ut.patch > > > |put_0(t0)| > |put_1(t1)| <-- the latest cell > If we call get, the put_1 will return. That is good. > If we call get after a delete, the put_0 will return. That is weird. The > put_0 is old data, and it should be dropped in flush. For client, put_0 > should not exist after the put_1 happen. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18375) The pool chunks from ChunkCreator are deallocated while in pool because there is no reference to them
[ https://issues.apache.org/jira/browse/HBASE-18375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16134698#comment-16134698 ] Anoop Sam John commented on HBASE-18375: You mean you pushed patch to master branch alone? We need this in 2.0 also. Pls push to branch-2 > The pool chunks from ChunkCreator are deallocated while in pool because there > is no reference to them > - > > Key: HBASE-18375 > URL: https://issues.apache.org/jira/browse/HBASE-18375 > Project: HBase > Issue Type: Sub-task >Affects Versions: 2.0.0-alpha-1 >Reporter: Anastasia Braginsky >Assignee: Anastasia Braginsky >Priority: Critical > Fix For: 2.0.0 > > Attachments: HBASE-18375-V01.patch, HBASE-18375-V02.patch, > HBASE-18375-V03.patch, HBASE-18375-V04.patch, HBASE-18375-V05.patch, > HBASE-18375-V06.patch, HBASE-18375-V07.patch, HBASE-18375-V08.patch, > HBASE-18375-V09.patch, HBASE-18375-V10.patch, HBASE-18375-V11.patch > > > Because MSLAB list of chunks was changed to list of chunk IDs, the chunks > returned back to pool can be deallocated by JVM because there is no reference > to them. The solution is to protect pool chunks from GC by the strong map of > ChunkCreator introduced by HBASE-18010. Will prepare the patch today. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18477) Umbrella JIRA for HBase Read Replica clusters
[ https://issues.apache.org/jira/browse/HBASE-18477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16134693#comment-16134693 ] Ashish Singhi commented on HBASE-18477: --- One more point, is this feature targeted for only cloud users ? Because the read-only clusters will be badly hit with read performance as there will be not be any data locality on those clusters. > Umbrella JIRA for HBase Read Replica clusters > - > > Key: HBASE-18477 > URL: https://issues.apache.org/jira/browse/HBASE-18477 > Project: HBase > Issue Type: New Feature >Reporter: Zach York >Assignee: Zach York > Attachments: HBase Read-Replica Clusters Scope doc.docx, HBase > Read-Replica Clusters Scope doc.pdf > > > Recently, changes (such as HBASE-17437) have unblocked HBase to run with a > root directory external to the cluster (such as in Amazon S3). This means > that the data is stored outside of the cluster and can be accessible after > the cluster has been terminated. One use case that is often asked about is > pointing multiple clusters to one root directory (sharing the data) to have > read resiliency in the case of a cluster failure. > > This JIRA is an umbrella JIRA to contain all the tasks necessary to create a > read-replica HBase cluster that is pointed at the same root directory. > > This requires making the Read-Replica cluster Read-Only (no metadata > operation or data operations). > Separating the hbase:meta table for each cluster (Otherwise HBase gets > confused with multiple clusters trying to update the meta table with their ip > addresses) > Adding refresh functionality for the meta table to ensure new metadata is > picked up on the read replica cluster. > Adding refresh functionality for HFiles for a given table to ensure new data > is picked up on the read replica cluster. > > This can be used with any existing cluster that is backed by an external > filesystem. > > Please note that this feature is still quite manual (with the potential for > automation later). > > More information on this particular feature can be found here: > https://aws.amazon.com/blogs/big-data/setting-up-read-replica-clusters-with-hbase-on-amazon-s3/ -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18640) Move mapreduce out of hbase-server into separate hbase-mapreduce moduel
[ https://issues.apache.org/jira/browse/HBASE-18640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Appy updated HBASE-18640: - Status: Patch Available (was: Open) > Move mapreduce out of hbase-server into separate hbase-mapreduce moduel > --- > > Key: HBASE-18640 > URL: https://issues.apache.org/jira/browse/HBASE-18640 > Project: HBase > Issue Type: Bug >Reporter: Appy >Assignee: Appy > Attachments: HBASE-18640.master.001.patch, > HBASE-18640.master.002.patch > > > (Couldn't find another dedicated jira, so creating new one). > Uploaded patch which is moving ~60 files to the new module. Few notes: > - The classes remaining in hbase-server are the ones which are intensively > coupled with visibility labels/wal/filesystem/hfile. These can not be > migrated to new module until corresponding subcomponents are untangled out of > hbase-server into their own separate modules. > - Almost all mapreduce tests uses HBaseTestingUtil, so they can't be moved to > hbase-mapreduce module. Given these dependency constraints, one way would be > having a separate module for tests: > hbase-mapreduce < hbase-server <--- hbase-mapreduce-tests > Imo, this makes sense and looks fine. > The only issue is - yetus' pre-commit. It won't run tests in > hbase-mapreduce-tests module if something changed in just hbase-mapreduce. > However, yetus' limitation shouldn't warrant against the idea. > So i'd say that we should go that way, unless there are better suggestions. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18638) The old cells will return to client if the new cells are deleted
[ https://issues.apache.org/jira/browse/HBASE-18638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai updated HBASE-18638: --- Status: Open (was: Patch Available) > The old cells will return to client if the new cells are deleted > > > Key: HBASE-18638 > URL: https://issues.apache.org/jira/browse/HBASE-18638 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0-alpha-1, 1.2.6, 1.3.1 >Reporter: Chia-Ping Tsai >Assignee: Chia-Ping Tsai >Priority: Critical > Fix For: 2.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7 > > Attachments: HBASE-18638-ut.patch, HBASE-18638-ut.patch > > > |put_0(t0)| > |put_1(t1)| <-- the latest cell > If we call get, the put_1 will return. That is good. > If we call get after a delete, the put_0 will return. That is weird. The > put_0 is old data, and it should be dropped in flush. For client, put_0 > should not exist after the put_1 happen. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18638) The old cells will return to client if the new cells are deleted
[ https://issues.apache.org/jira/browse/HBASE-18638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai updated HBASE-18638: --- Attachment: HBASE-18638-ut.patch > The old cells will return to client if the new cells are deleted > > > Key: HBASE-18638 > URL: https://issues.apache.org/jira/browse/HBASE-18638 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.1, 1.2.6, 2.0.0-alpha-1 >Reporter: Chia-Ping Tsai >Assignee: Chia-Ping Tsai >Priority: Critical > Fix For: 2.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7 > > Attachments: HBASE-18638-ut.patch, HBASE-18638-ut.patch > > > |put_0(t0)| > |put_1(t1)| <-- the latest cell > If we call get, the put_1 will return. That is good. > If we call get after a delete, the put_0 will return. That is weird. The > put_0 is old data, and it should be dropped in flush. For client, put_0 > should not exist after the put_1 happen. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18638) The old cells will return to client if the new cells are deleted
[ https://issues.apache.org/jira/browse/HBASE-18638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai updated HBASE-18638: --- Status: Patch Available (was: Open) > The old cells will return to client if the new cells are deleted > > > Key: HBASE-18638 > URL: https://issues.apache.org/jira/browse/HBASE-18638 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0-alpha-1, 1.2.6, 1.3.1 >Reporter: Chia-Ping Tsai >Assignee: Chia-Ping Tsai >Priority: Critical > Fix For: 2.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7 > > Attachments: HBASE-18638-ut.patch, HBASE-18638-ut.patch > > > |put_0(t0)| > |put_1(t1)| <-- the latest cell > If we call get, the put_1 will return. That is good. > If we call get after a delete, the put_0 will return. That is weird. The > put_0 is old data, and it should be dropped in flush. For client, put_0 > should not exist after the put_1 happen. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18637) Update the link of "Bending time in HBase"
[
https://issues.apache.org/jira/browse/HBASE-18637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai updated HBASE-18637:
---
Status: Patch Available (was: Open)
> Update the link of "Bending time in HBase"
> --
>
> Key: HBASE-18637
> URL: https://issues.apache.org/jira/browse/HBASE-18637
> Project: HBase
> Issue Type: Bug
> Components: documentation
>Reporter: Chia-Ping Tsai
>Assignee: Jan Hentschel
>Priority: Trivial
> Labels: beginner
> Fix For: 2.0.0
>
> Attachments: HBASE-18637.master.001.patch
>
>
> {code:title=datamodel.adoc}
> link:http://outerthought.org/blog/417-ot.html[Bending time in HBase]
> {code}
> The link is changed to "https://www.ngdata.com/bending-time-in-hbase/";
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18637) Update the link of "Bending time in HBase"
[
https://issues.apache.org/jira/browse/HBASE-18637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16134676#comment-16134676
]
Chia-Ping Tsai commented on HBASE-18637:
lgtm
> Update the link of "Bending time in HBase"
> --
>
> Key: HBASE-18637
> URL: https://issues.apache.org/jira/browse/HBASE-18637
> Project: HBase
> Issue Type: Bug
> Components: documentation
>Reporter: Chia-Ping Tsai
>Assignee: Jan Hentschel
>Priority: Trivial
> Labels: beginner
> Fix For: 2.0.0
>
> Attachments: HBASE-18637.master.001.patch
>
>
> {code:title=datamodel.adoc}
> link:http://outerthought.org/blog/417-ot.html[Bending time in HBase]
> {code}
> The link is changed to "https://www.ngdata.com/bending-time-in-hbase/";
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18233) We shouldn't wait for readlock in doMiniBatchMutation in case of deadlock
[ https://issues.apache.org/jira/browse/HBASE-18233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16134652#comment-16134652 ] Yu Li commented on HBASE-18233: --- Checked UT failures and they should be irrelative to change here. I guess the patch is ready to launch? Please correct me if I'm wrong, but it seems this one should go to all branches except branch-1.1? Thanks. > We shouldn't wait for readlock in doMiniBatchMutation in case of deadlock > - > > Key: HBASE-18233 > URL: https://issues.apache.org/jira/browse/HBASE-18233 > Project: HBase > Issue Type: Bug >Affects Versions: 1.2.7 >Reporter: Allan Yang >Assignee: Allan Yang >Priority: Blocker > Fix For: 2.0.0, 1.4.0, 1.3.2, 1.2.7 > > Attachments: HBASE-18233-branch-1.2.patch, > HBASE-18233-branch-1.2.v2.patch, HBASE-18233-branch-1.2.v3.patch, > HBASE-18233-branch-1.2.v4.patch > > > Please refer to the discuss in HBASE-18144 > https://issues.apache.org/jira/browse/HBASE-18144?focusedCommentId=16051701&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16051701 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18477) Umbrella JIRA for HBase Read Replica clusters
[ https://issues.apache.org/jira/browse/HBASE-18477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16134649#comment-16134649 ] Sean Busbey commented on HBASE-18477: - This would be a good addition to the scope document. How will cell level visibility labels get handled? since they live in a system table, are they propagated similarly to changes in namespaces? > Umbrella JIRA for HBase Read Replica clusters > - > > Key: HBASE-18477 > URL: https://issues.apache.org/jira/browse/HBASE-18477 > Project: HBase > Issue Type: New Feature >Reporter: Zach York >Assignee: Zach York > Attachments: HBase Read-Replica Clusters Scope doc.docx, HBase > Read-Replica Clusters Scope doc.pdf > > > Recently, changes (such as HBASE-17437) have unblocked HBase to run with a > root directory external to the cluster (such as in Amazon S3). This means > that the data is stored outside of the cluster and can be accessible after > the cluster has been terminated. One use case that is often asked about is > pointing multiple clusters to one root directory (sharing the data) to have > read resiliency in the case of a cluster failure. > > This JIRA is an umbrella JIRA to contain all the tasks necessary to create a > read-replica HBase cluster that is pointed at the same root directory. > > This requires making the Read-Replica cluster Read-Only (no metadata > operation or data operations). > Separating the hbase:meta table for each cluster (Otherwise HBase gets > confused with multiple clusters trying to update the meta table with their ip > addresses) > Adding refresh functionality for the meta table to ensure new metadata is > picked up on the read replica cluster. > Adding refresh functionality for HFiles for a given table to ensure new data > is picked up on the read replica cluster. > > This can be used with any existing cluster that is backed by an external > filesystem. > > Please note that this feature is still quite manual (with the potential for > automation later). > > More information on this particular feature can be found here: > https://aws.amazon.com/blogs/big-data/setting-up-read-replica-clusters-with-hbase-on-amazon-s3/ -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18640) Move mapreduce out of hbase-server into separate hbase-mapreduce moduel
[ https://issues.apache.org/jira/browse/HBASE-18640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16134633#comment-16134633 ] Sean Busbey commented on HBASE-18640: - or! what if we break the mapreduce stuff into two modules, one that just needs stuff found in hbase-client and one that needs internals that are in hbase-server? > Move mapreduce out of hbase-server into separate hbase-mapreduce moduel > --- > > Key: HBASE-18640 > URL: https://issues.apache.org/jira/browse/HBASE-18640 > Project: HBase > Issue Type: Bug >Reporter: Appy >Assignee: Appy > Attachments: HBASE-18640.master.001.patch, > HBASE-18640.master.002.patch > > > (Couldn't find another dedicated jira, so creating new one). > Uploaded patch which is moving ~60 files to the new module. Few notes: > - The classes remaining in hbase-server are the ones which are intensively > coupled with visibility labels/wal/filesystem/hfile. These can not be > migrated to new module until corresponding subcomponents are untangled out of > hbase-server into their own separate modules. > - Almost all mapreduce tests uses HBaseTestingUtil, so they can't be moved to > hbase-mapreduce module. Given these dependency constraints, one way would be > having a separate module for tests: > hbase-mapreduce < hbase-server <--- hbase-mapreduce-tests > Imo, this makes sense and looks fine. > The only issue is - yetus' pre-commit. It won't run tests in > hbase-mapreduce-tests module if something changed in just hbase-mapreduce. > However, yetus' limitation shouldn't warrant against the idea. > So i'd say that we should go that way, unless there are better suggestions. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18640) Move mapreduce out of hbase-server into separate hbase-mapreduce moduel
[ https://issues.apache.org/jira/browse/HBASE-18640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16134631#comment-16134631 ] Sean Busbey commented on HBASE-18640: - HBaseTestingUtility should probably move into its own module since we tell downstream folks to use it. Then couldn't we do: * hbase-testing-utility * hbase-server (test dep on h-t-u) * hbase-mapreduce (dep on hbase-server, test on h-t-u) That would allow all the mapreduce stuff to go into the module, even if it depends on hbase-server internals. We could undo the dependency on hbase-server as other things move into new modules. bq. The only issue is - yetus' pre-commit. It won't run tests in hbase-mapreduce-tests module if something changed in just hbase-mapreduce. However, yetus' limitation shouldn't warrant against the idea. We can handle this in our personality and make it so h-m-t are run if something changes in h-m. (but see above for why I don't think we need to) > Move mapreduce out of hbase-server into separate hbase-mapreduce moduel > --- > > Key: HBASE-18640 > URL: https://issues.apache.org/jira/browse/HBASE-18640 > Project: HBase > Issue Type: Bug >Reporter: Appy >Assignee: Appy > Attachments: HBASE-18640.master.001.patch, > HBASE-18640.master.002.patch > > > (Couldn't find another dedicated jira, so creating new one). > Uploaded patch which is moving ~60 files to the new module. Few notes: > - The classes remaining in hbase-server are the ones which are intensively > coupled with visibility labels/wal/filesystem/hfile. These can not be > migrated to new module until corresponding subcomponents are untangled out of > hbase-server into their own separate modules. > - Almost all mapreduce tests uses HBaseTestingUtil, so they can't be moved to > hbase-mapreduce module. Given these dependency constraints, one way would be > having a separate module for tests: > hbase-mapreduce < hbase-server <--- hbase-mapreduce-tests > Imo, this makes sense and looks fine. > The only issue is - yetus' pre-commit. It won't run tests in > hbase-mapreduce-tests module if something changed in just hbase-mapreduce. > However, yetus' limitation shouldn't warrant against the idea. > So i'd say that we should go that way, unless there are better suggestions. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-17442) Move most of the replication related classes to hbase-server package
[
https://issues.apache.org/jira/browse/HBASE-17442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16134627#comment-16134627
]
Hadoop QA commented on HBASE-17442:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
20s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
16s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
31s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 4m
14s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
13s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 2m
5s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source: . {color}
|
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
45s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m
17s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
9s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
4s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 4m
24s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 4m
24s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
37s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 2m
18s{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
4s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
32m 12s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source: . {color}
|
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m
3s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m
28s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
45s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
11s{color} | {color:green} hbase-replication in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}110m
0s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}106m 39s{color}
| {color:red} root in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 1m
24s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}295m 38s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Timed out junit tests |
org.apache.hadoop.hbase.master.procedure.TestDisableTableProcedure |
| | org.apache.hadoop.hbase.master.procedure.TestModifyTableProcedure |
|
[jira] [Updated] (HBASE-18640) Move mapreduce out of hbase-server into separate hbase-mapreduce moduel
[ https://issues.apache.org/jira/browse/HBASE-18640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Appy updated HBASE-18640: - Attachment: HBASE-18640.master.002.patch > Move mapreduce out of hbase-server into separate hbase-mapreduce moduel > --- > > Key: HBASE-18640 > URL: https://issues.apache.org/jira/browse/HBASE-18640 > Project: HBase > Issue Type: Bug >Reporter: Appy >Assignee: Appy > Attachments: HBASE-18640.master.001.patch, > HBASE-18640.master.002.patch > > > (Couldn't find another dedicated jira, so creating new one). > Uploaded patch which is moving ~60 files to the new module. Few notes: > - The classes remaining in hbase-server are the ones which are intensively > coupled with visibility labels/wal/filesystem/hfile. These can not be > migrated to new module until corresponding subcomponents are untangled out of > hbase-server into their own separate modules. > - Almost all mapreduce tests uses HBaseTestingUtil, so they can't be moved to > hbase-mapreduce module. Given these dependency constraints, one way would be > having a separate module for tests: > hbase-mapreduce < hbase-server <--- hbase-mapreduce-tests > Imo, this makes sense and looks fine. > The only issue is - yetus' pre-commit. It won't run tests in > hbase-mapreduce-tests module if something changed in just hbase-mapreduce. > However, yetus' limitation shouldn't warrant against the idea. > So i'd say that we should go that way, unless there are better suggestions. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18640) Move mapreduce out of hbase-server into separate hbase-mapreduce moduel
[ https://issues.apache.org/jira/browse/HBASE-18640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Appy updated HBASE-18640: - Description: (Couldn't find another dedicated jira, so creating new one). Uploaded patch which is moving ~60 files to the new module. Few notes: - The classes remaining in hbase-server are the ones which are intensively coupled with visibility labels/wal/filesystem/hfile. These can not be migrated to new module until corresponding subcomponents are untangled out of hbase-server into their own separate modules. - Almost all mapreduce tests uses HBaseTestingUtil, so they can't be moved to hbase-mapreduce module. Given these dependency constraints, one way would be having a separate module for tests: hbase-mapreduce < hbase-server <--- hbase-mapreduce-tests Imo, this makes sense and looks fine. The only issue is - yetus' pre-commit. It won't run tests in hbase-mapreduce-tests module if something changed in just hbase-mapreduce. However, yetus' limitation shouldn't warrant against the idea. So i'd say that we should go that way, unless there are better suggestions. was:(Couldn't find another dedicated jira, so creating new one). > Move mapreduce out of hbase-server into separate hbase-mapreduce moduel > --- > > Key: HBASE-18640 > URL: https://issues.apache.org/jira/browse/HBASE-18640 > Project: HBase > Issue Type: Bug >Reporter: Appy >Assignee: Appy > Attachments: HBASE-18640.master.001.patch > > > (Couldn't find another dedicated jira, so creating new one). > Uploaded patch which is moving ~60 files to the new module. Few notes: > - The classes remaining in hbase-server are the ones which are intensively > coupled with visibility labels/wal/filesystem/hfile. These can not be > migrated to new module until corresponding subcomponents are untangled out of > hbase-server into their own separate modules. > - Almost all mapreduce tests uses HBaseTestingUtil, so they can't be moved to > hbase-mapreduce module. Given these dependency constraints, one way would be > having a separate module for tests: > hbase-mapreduce < hbase-server <--- hbase-mapreduce-tests > Imo, this makes sense and looks fine. > The only issue is - yetus' pre-commit. It won't run tests in > hbase-mapreduce-tests module if something changed in just hbase-mapreduce. > However, yetus' limitation shouldn't warrant against the idea. > So i'd say that we should go that way, unless there are better suggestions. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18640) Move mapreduce out of hbase-server into separate hbase-mapreduce moduel
[ https://issues.apache.org/jira/browse/HBASE-18640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Appy updated HBASE-18640: - Description: (Couldn't find another dedicated jira, so creating new one). > Move mapreduce out of hbase-server into separate hbase-mapreduce moduel > --- > > Key: HBASE-18640 > URL: https://issues.apache.org/jira/browse/HBASE-18640 > Project: HBase > Issue Type: Bug >Reporter: Appy >Assignee: Appy > Attachments: HBASE-18640.master.001.patch > > > (Couldn't find another dedicated jira, so creating new one). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18640) Move mapreduce out of hbase-server into separate hbase-mapreduce moduel
[ https://issues.apache.org/jira/browse/HBASE-18640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Appy updated HBASE-18640: - Attachment: HBASE-18640.master.001.patch > Move mapreduce out of hbase-server into separate hbase-mapreduce moduel > --- > > Key: HBASE-18640 > URL: https://issues.apache.org/jira/browse/HBASE-18640 > Project: HBase > Issue Type: Bug >Reporter: Appy >Assignee: Appy > Attachments: HBASE-18640.master.001.patch > > > (Couldn't find another dedicated jira, so creating new one). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-18640) Move mapreduce out of hbase-server into separate hbase-mapreduce moduel
Appy created HBASE-18640: Summary: Move mapreduce out of hbase-server into separate hbase-mapreduce moduel Key: HBASE-18640 URL: https://issues.apache.org/jira/browse/HBASE-18640 Project: HBase Issue Type: Bug Reporter: Appy Assignee: Appy -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18448) Added support for refreshing HFiles through API and shell
[ https://issues.apache.org/jira/browse/HBASE-18448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ajay Jadhav updated HBASE-18448: Status: Patch Available (was: Open) > Added support for refreshing HFiles through API and shell > - > > Key: HBASE-18448 > URL: https://issues.apache.org/jira/browse/HBASE-18448 > Project: HBase > Issue Type: Sub-task >Affects Versions: 1.3.1, 2.0.0 >Reporter: Ajay Jadhav >Assignee: Ajay Jadhav >Priority: Minor > Fix For: 1.4.0 > > Attachments: HBASE-18448.branch-1.001.patch, > HBASE-18448.branch-1.002.patch, HBASE-18448.branch-1.003.patch, > HBASE-18448.branch-1.004.patch, HBASE-18448.branch-1.005.patch, > HBASE-18448.branch-1.006.patch > > > In the case where multiple HBase clusters are sharing a common rootDir, even > after flushing the data from > one cluster doesn't mean that other clusters (replicas) will automatically > pick the new HFile. Through this patch, > we are exposing the refresh HFiles API which when issued from a replica will > update the in-memory file handle list > with the newly added file. > This allows replicas to be consistent with the data written through the > primary cluster. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18448) Added support for refreshing HFiles through API and shell
[ https://issues.apache.org/jira/browse/HBASE-18448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16134614#comment-16134614 ] Ajay Jadhav commented on HBASE-18448: - Thanks Ted. I have moved both the RefreshHFiles.proto and RefreshHFilesClient.java under hbase-examples module. > Added support for refreshing HFiles through API and shell > - > > Key: HBASE-18448 > URL: https://issues.apache.org/jira/browse/HBASE-18448 > Project: HBase > Issue Type: Sub-task >Affects Versions: 2.0.0, 1.3.1 >Reporter: Ajay Jadhav >Assignee: Ajay Jadhav >Priority: Minor > Fix For: 1.4.0 > > Attachments: HBASE-18448.branch-1.001.patch, > HBASE-18448.branch-1.002.patch, HBASE-18448.branch-1.003.patch, > HBASE-18448.branch-1.004.patch, HBASE-18448.branch-1.005.patch, > HBASE-18448.branch-1.006.patch > > > In the case where multiple HBase clusters are sharing a common rootDir, even > after flushing the data from > one cluster doesn't mean that other clusters (replicas) will automatically > pick the new HFile. Through this patch, > we are exposing the refresh HFiles API which when issued from a replica will > update the in-memory file handle list > with the newly added file. > This allows replicas to be consistent with the data written through the > primary cluster. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18448) Added support for refreshing HFiles through API and shell
[ https://issues.apache.org/jira/browse/HBASE-18448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ajay Jadhav updated HBASE-18448: Attachment: HBASE-18448.branch-1.006.patch > Added support for refreshing HFiles through API and shell > - > > Key: HBASE-18448 > URL: https://issues.apache.org/jira/browse/HBASE-18448 > Project: HBase > Issue Type: Sub-task >Affects Versions: 2.0.0, 1.3.1 >Reporter: Ajay Jadhav >Assignee: Ajay Jadhav >Priority: Minor > Fix For: 1.4.0 > > Attachments: HBASE-18448.branch-1.001.patch, > HBASE-18448.branch-1.002.patch, HBASE-18448.branch-1.003.patch, > HBASE-18448.branch-1.004.patch, HBASE-18448.branch-1.005.patch, > HBASE-18448.branch-1.006.patch > > > In the case where multiple HBase clusters are sharing a common rootDir, even > after flushing the data from > one cluster doesn't mean that other clusters (replicas) will automatically > pick the new HFile. Through this patch, > we are exposing the refresh HFiles API which when issued from a replica will > update the in-memory file handle list > with the newly added file. > This allows replicas to be consistent with the data written through the > primary cluster. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18448) Added support for refreshing HFiles through API and shell
[ https://issues.apache.org/jira/browse/HBASE-18448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ajay Jadhav updated HBASE-18448: Status: Open (was: Patch Available) > Added support for refreshing HFiles through API and shell > - > > Key: HBASE-18448 > URL: https://issues.apache.org/jira/browse/HBASE-18448 > Project: HBase > Issue Type: Sub-task >Affects Versions: 1.3.1, 2.0.0 >Reporter: Ajay Jadhav >Assignee: Ajay Jadhav >Priority: Minor > Fix For: 1.4.0 > > Attachments: HBASE-18448.branch-1.001.patch, > HBASE-18448.branch-1.002.patch, HBASE-18448.branch-1.003.patch, > HBASE-18448.branch-1.004.patch, HBASE-18448.branch-1.005.patch, > HBASE-18448.branch-1.006.patch > > > In the case where multiple HBase clusters are sharing a common rootDir, even > after flushing the data from > one cluster doesn't mean that other clusters (replicas) will automatically > pick the new HFile. Through this patch, > we are exposing the refresh HFiles API which when issued from a replica will > update the in-memory file handle list > with the newly added file. > This allows replicas to be consistent with the data written through the > primary cluster. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18631) Allow configuration of ChaosMonkey properties via hbase-site
[ https://issues.apache.org/jira/browse/HBASE-18631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16134604#comment-16134604 ] Hudson commented on HBASE-18631: FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #3567 (See [https://builds.apache.org/job/HBase-Trunk_matrix/3567/]) HBASE-18631 Allow ChaosMonkey properties to be specified in hbase-site (elserj: rev 13028d71576eebda3f5a831903e2a2e6d5f97ff4) * (edit) hbase-it/src/test/java/org/apache/hadoop/hbase/IntegrationTestBase.java * (edit) hbase-it/src/test/java/org/apache/hadoop/hbase/chaos/factories/MonkeyConstants.java * (add) hbase-it/src/test/java/org/apache/hadoop/hbase/TestIntegrationTestBase.java > Allow configuration of ChaosMonkey properties via hbase-site > > > Key: HBASE-18631 > URL: https://issues.apache.org/jira/browse/HBASE-18631 > Project: HBase > Issue Type: Improvement > Components: integration tests >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Minor > Fix For: 2.0.0, 1.4.0, 1.3.2, 1.2.7, 1.1.13 > > Attachments: HBASE-18631.001.patch > > > I noticed in some internal test automation that the code was attempting to > configure some of the chaos-monkey actions via hbase-site.xml, but these > weren't taking effect. > After reading the code, I found that these can only be specified via a > special properties file otherwise specified. It would be nice to also allow > configuration via hbase-site. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18477) Umbrella JIRA for HBase Read Replica clusters
[ https://issues.apache.org/jira/browse/HBASE-18477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16134601#comment-16134601 ] Ajay Jadhav commented on HBASE-18477: - [~ashish singhi]: Yes, primary and read-only replicas have their own ZK and any ACL, quota related updates on primary will not be automatically forwarded to replicas. Currently, the way to ensure that these policies are consistent across clusters sharing a common rootDir/ S3 bucket, is to individually update them. We are looking at ways to automate this. > Umbrella JIRA for HBase Read Replica clusters > - > > Key: HBASE-18477 > URL: https://issues.apache.org/jira/browse/HBASE-18477 > Project: HBase > Issue Type: New Feature >Reporter: Zach York >Assignee: Zach York > Attachments: HBase Read-Replica Clusters Scope doc.docx, HBase > Read-Replica Clusters Scope doc.pdf > > > Recently, changes (such as HBASE-17437) have unblocked HBase to run with a > root directory external to the cluster (such as in Amazon S3). This means > that the data is stored outside of the cluster and can be accessible after > the cluster has been terminated. One use case that is often asked about is > pointing multiple clusters to one root directory (sharing the data) to have > read resiliency in the case of a cluster failure. > > This JIRA is an umbrella JIRA to contain all the tasks necessary to create a > read-replica HBase cluster that is pointed at the same root directory. > > This requires making the Read-Replica cluster Read-Only (no metadata > operation or data operations). > Separating the hbase:meta table for each cluster (Otherwise HBase gets > confused with multiple clusters trying to update the meta table with their ip > addresses) > Adding refresh functionality for the meta table to ensure new metadata is > picked up on the read replica cluster. > Adding refresh functionality for HFiles for a given table to ensure new data > is picked up on the read replica cluster. > > This can be used with any existing cluster that is backed by an external > filesystem. > > Please note that this feature is still quite manual (with the potential for > automation later). > > More information on this particular feature can be found here: > https://aws.amazon.com/blogs/big-data/setting-up-read-replica-clusters-with-hbase-on-amazon-s3/ -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18631) Allow configuration of ChaosMonkey properties via hbase-site
[ https://issues.apache.org/jira/browse/HBASE-18631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16134598#comment-16134598 ] Hudson commented on HBASE-18631: SUCCESS: Integrated in Jenkins build HBase-1.1-JDK7 #1903 (See [https://builds.apache.org/job/HBase-1.1-JDK7/1903/]) HBASE-18631 Allow ChaosMonkey properties to be specified in hbase-site (elserj: rev e391bb047ed9416b9592ac4c87195ed52f7cbc22) * (add) hbase-it/src/test/java/org/apache/hadoop/hbase/TestIntegrationTestBase.java * (edit) hbase-it/src/test/java/org/apache/hadoop/hbase/chaos/factories/MonkeyConstants.java * (edit) hbase-it/src/test/java/org/apache/hadoop/hbase/IntegrationTestBase.java > Allow configuration of ChaosMonkey properties via hbase-site > > > Key: HBASE-18631 > URL: https://issues.apache.org/jira/browse/HBASE-18631 > Project: HBase > Issue Type: Improvement > Components: integration tests >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Minor > Fix For: 2.0.0, 1.4.0, 1.3.2, 1.2.7, 1.1.13 > > Attachments: HBASE-18631.001.patch > > > I noticed in some internal test automation that the code was attempting to > configure some of the chaos-monkey actions via hbase-site.xml, but these > weren't taking effect. > After reading the code, I found that these can only be specified via a > special properties file otherwise specified. It would be nice to also allow > configuration via hbase-site. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18631) Allow configuration of ChaosMonkey properties via hbase-site
[ https://issues.apache.org/jira/browse/HBASE-18631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16134585#comment-16134585 ] Hudson commented on HBASE-18631: SUCCESS: Integrated in Jenkins build HBase-1.4 #872 (See [https://builds.apache.org/job/HBase-1.4/872/]) HBASE-18631 Allow ChaosMonkey properties to be specified in hbase-site (elserj: rev b2eb09aa2369fb88a1b4d8c22678453933e7c3db) * (edit) hbase-it/src/test/java/org/apache/hadoop/hbase/chaos/factories/MonkeyConstants.java * (edit) hbase-it/src/test/java/org/apache/hadoop/hbase/IntegrationTestBase.java * (add) hbase-it/src/test/java/org/apache/hadoop/hbase/TestIntegrationTestBase.java > Allow configuration of ChaosMonkey properties via hbase-site > > > Key: HBASE-18631 > URL: https://issues.apache.org/jira/browse/HBASE-18631 > Project: HBase > Issue Type: Improvement > Components: integration tests >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Minor > Fix For: 2.0.0, 1.4.0, 1.3.2, 1.2.7, 1.1.13 > > Attachments: HBASE-18631.001.patch > > > I noticed in some internal test automation that the code was attempting to > configure some of the chaos-monkey actions via hbase-site.xml, but these > weren't taking effect. > After reading the code, I found that these can only be specified via a > special properties file otherwise specified. It would be nice to also allow > configuration via hbase-site. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18631) Allow configuration of ChaosMonkey properties via hbase-site
[ https://issues.apache.org/jira/browse/HBASE-18631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16134580#comment-16134580 ] Hudson commented on HBASE-18631: SUCCESS: Integrated in Jenkins build HBase-1.1-JDK8 #1987 (See [https://builds.apache.org/job/HBase-1.1-JDK8/1987/]) HBASE-18631 Allow ChaosMonkey properties to be specified in hbase-site (elserj: rev e391bb047ed9416b9592ac4c87195ed52f7cbc22) * (edit) hbase-it/src/test/java/org/apache/hadoop/hbase/IntegrationTestBase.java * (edit) hbase-it/src/test/java/org/apache/hadoop/hbase/chaos/factories/MonkeyConstants.java * (add) hbase-it/src/test/java/org/apache/hadoop/hbase/TestIntegrationTestBase.java > Allow configuration of ChaosMonkey properties via hbase-site > > > Key: HBASE-18631 > URL: https://issues.apache.org/jira/browse/HBASE-18631 > Project: HBase > Issue Type: Improvement > Components: integration tests >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Minor > Fix For: 2.0.0, 1.4.0, 1.3.2, 1.2.7, 1.1.13 > > Attachments: HBASE-18631.001.patch > > > I noticed in some internal test automation that the code was attempting to > configure some of the chaos-monkey actions via hbase-site.xml, but these > weren't taking effect. > After reading the code, I found that these can only be specified via a > special properties file otherwise specified. It would be nice to also allow > configuration via hbase-site. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18631) Allow configuration of ChaosMonkey properties via hbase-site
[ https://issues.apache.org/jira/browse/HBASE-18631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16134576#comment-16134576 ] Hudson commented on HBASE-18631: FAILURE: Integrated in Jenkins build HBase-1.2-JDK8 #194 (See [https://builds.apache.org/job/HBase-1.2-JDK8/194/]) HBASE-18631 Allow ChaosMonkey properties to be specified in hbase-site (elserj: rev 5bf83cc14ee53bded53bba5e940cff81f82d15c3) * (edit) hbase-it/src/test/java/org/apache/hadoop/hbase/IntegrationTestBase.java * (add) hbase-it/src/test/java/org/apache/hadoop/hbase/TestIntegrationTestBase.java * (edit) hbase-it/src/test/java/org/apache/hadoop/hbase/chaos/factories/MonkeyConstants.java > Allow configuration of ChaosMonkey properties via hbase-site > > > Key: HBASE-18631 > URL: https://issues.apache.org/jira/browse/HBASE-18631 > Project: HBase > Issue Type: Improvement > Components: integration tests >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Minor > Fix For: 2.0.0, 1.4.0, 1.3.2, 1.2.7, 1.1.13 > > Attachments: HBASE-18631.001.patch > > > I noticed in some internal test automation that the code was attempting to > configure some of the chaos-monkey actions via hbase-site.xml, but these > weren't taking effect. > After reading the code, I found that these can only be specified via a > special properties file otherwise specified. It would be nice to also allow > configuration via hbase-site. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18631) Allow configuration of ChaosMonkey properties via hbase-site
[ https://issues.apache.org/jira/browse/HBASE-18631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16134574#comment-16134574 ] Hudson commented on HBASE-18631: FAILURE: Integrated in Jenkins build HBase-1.5 #19 (See [https://builds.apache.org/job/HBase-1.5/19/]) HBASE-18631 Allow ChaosMonkey properties to be specified in hbase-site (elserj: rev 00a4e0697a464192c817a0de89e99017e65d3b44) * (edit) hbase-it/src/test/java/org/apache/hadoop/hbase/chaos/factories/MonkeyConstants.java * (edit) hbase-it/src/test/java/org/apache/hadoop/hbase/IntegrationTestBase.java * (add) hbase-it/src/test/java/org/apache/hadoop/hbase/TestIntegrationTestBase.java > Allow configuration of ChaosMonkey properties via hbase-site > > > Key: HBASE-18631 > URL: https://issues.apache.org/jira/browse/HBASE-18631 > Project: HBase > Issue Type: Improvement > Components: integration tests >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Minor > Fix For: 2.0.0, 1.4.0, 1.3.2, 1.2.7, 1.1.13 > > Attachments: HBASE-18631.001.patch > > > I noticed in some internal test automation that the code was attempting to > configure some of the chaos-monkey actions via hbase-site.xml, but these > weren't taking effect. > After reading the code, I found that these can only be specified via a > special properties file otherwise specified. It would be nice to also allow > configuration via hbase-site. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (HBASE-18637) Update the link of "Bending time in HBase"
[
https://issues.apache.org/jira/browse/HBASE-18637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Hentschel reassigned HBASE-18637:
-
Assignee: Jan Hentschel
> Update the link of "Bending time in HBase"
> --
>
> Key: HBASE-18637
> URL: https://issues.apache.org/jira/browse/HBASE-18637
> Project: HBase
> Issue Type: Bug
> Components: documentation
>Reporter: Chia-Ping Tsai
>Assignee: Jan Hentschel
>Priority: Trivial
> Labels: beginner
> Fix For: 2.0.0
>
> Attachments: HBASE-18637.master.001.patch
>
>
> {code:title=datamodel.adoc}
> link:http://outerthought.org/blog/417-ot.html[Bending time in HBase]
> {code}
> The link is changed to "https://www.ngdata.com/bending-time-in-hbase/";
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (HBASE-18635) Fix asciidoc warnings
[
https://issues.apache.org/jira/browse/HBASE-18635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Hentschel reassigned HBASE-18635:
-
Assignee: Jan Hentschel
> Fix asciidoc warnings
> -
>
> Key: HBASE-18635
> URL: https://issues.apache.org/jira/browse/HBASE-18635
> Project: HBase
> Issue Type: Bug
>Reporter: Misty Stanley-Jones
>Assignee: Jan Hentschel
> Attachments: HBASE-18635.master.001.patch
>
>
> When building docs, I noticed:
> {code}
> Failed to parse formatted text: To supply filters to the Scanner object or
> configure the Scanner in any other way, you can create a text file and add
> your filter to the file. For example, to return only rows for which keys
> start with u123 and use a batch size of 100, the
> filter file would look like this:
> { "type": "PrefixFilter",
> "value": "u123" }
> {code}
> Working hypthesis is that we should either be using proper codeblocks rather
> than pre tags. Otherwise we may need to do something to escape curly braces.
> Asciidoctor is probably trying to interpret them as Liquid tags.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18637) Update the link of "Bending time in HBase"
[
https://issues.apache.org/jira/browse/HBASE-18637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Hentschel updated HBASE-18637:
--
Attachment: HBASE-18637.master.001.patch
> Update the link of "Bending time in HBase"
> --
>
> Key: HBASE-18637
> URL: https://issues.apache.org/jira/browse/HBASE-18637
> Project: HBase
> Issue Type: Bug
> Components: documentation
>Reporter: Chia-Ping Tsai
>Priority: Trivial
> Labels: beginner
> Fix For: 2.0.0
>
> Attachments: HBASE-18637.master.001.patch
>
>
> {code:title=datamodel.adoc}
> link:http://outerthought.org/blog/417-ot.html[Bending time in HBase]
> {code}
> The link is changed to "https://www.ngdata.com/bending-time-in-hbase/";
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18635) Fix asciidoc warnings
[
https://issues.apache.org/jira/browse/HBASE-18635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Hentschel updated HBASE-18635:
--
Attachment: HBASE-18635.master.001.patch
> Fix asciidoc warnings
> -
>
> Key: HBASE-18635
> URL: https://issues.apache.org/jira/browse/HBASE-18635
> Project: HBase
> Issue Type: Bug
>Reporter: Misty Stanley-Jones
> Attachments: HBASE-18635.master.001.patch
>
>
> When building docs, I noticed:
> {code}
> Failed to parse formatted text: To supply filters to the Scanner object or
> configure the Scanner in any other way, you can create a text file and add
> your filter to the file. For example, to return only rows for which keys
> start with u123 and use a batch size of 100, the
> filter file would look like this:
> { "type": "PrefixFilter",
> "value": "u123" }
> {code}
> Working hypthesis is that we should either be using proper codeblocks rather
> than pre tags. Otherwise we may need to do something to escape curly braces.
> Asciidoctor is probably trying to interpret them as Liquid tags.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18631) Allow configuration of ChaosMonkey properties via hbase-site
[ https://issues.apache.org/jira/browse/HBASE-18631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16134571#comment-16134571 ] Hudson commented on HBASE-18631: FAILURE: Integrated in Jenkins build HBase-2.0 #366 (See [https://builds.apache.org/job/HBase-2.0/366/]) HBASE-18631 Allow ChaosMonkey properties to be specified in hbase-site (elserj: rev 95e1fa30b086eb709f2ab57ef7781537fde1533c) * (add) hbase-it/src/test/java/org/apache/hadoop/hbase/TestIntegrationTestBase.java * (edit) hbase-it/src/test/java/org/apache/hadoop/hbase/IntegrationTestBase.java * (edit) hbase-it/src/test/java/org/apache/hadoop/hbase/chaos/factories/MonkeyConstants.java > Allow configuration of ChaosMonkey properties via hbase-site > > > Key: HBASE-18631 > URL: https://issues.apache.org/jira/browse/HBASE-18631 > Project: HBase > Issue Type: Improvement > Components: integration tests >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Minor > Fix For: 2.0.0, 1.4.0, 1.3.2, 1.2.7, 1.1.13 > > Attachments: HBASE-18631.001.patch > > > I noticed in some internal test automation that the code was attempting to > configure some of the chaos-monkey actions via hbase-site.xml, but these > weren't taking effect. > After reading the code, I found that these can only be specified via a > special properties file otherwise specified. It would be nice to also allow > configuration via hbase-site. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-17442) Move most of the replication related classes to hbase-server package
[ https://issues.apache.org/jira/browse/HBASE-17442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Appy updated HBASE-17442: - Attachment: HBASE-17442.master.002.patch > Move most of the replication related classes to hbase-server package > > > Key: HBASE-17442 > URL: https://issues.apache.org/jira/browse/HBASE-17442 > Project: HBase > Issue Type: Sub-task > Components: build, Replication >Affects Versions: 2.0.0 >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang >Priority: Critical > Fix For: 2.0.0-alpha-3 > > Attachments: 0001-hbase-replication-module.patch, > HBASE-17442.branch-2.001.patch, HBASE-17442.branch-2.001.patch, > HBASE-17442.master.001.patch, HBASE-17442.master.001.patch, > HBASE-17442.master.002.patch, HBASE-17442.v1.patch, HBASE-17442.v2.patch, > HBASE-17442.v2.patch, HBASE-17442.v3.patch > > > After the replication requests are routed through master, replication > implementation details didn't need be exposed to client. We should move most > of the replication related classes to hbase-server package. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18631) Allow configuration of ChaosMonkey properties via hbase-site
[ https://issues.apache.org/jira/browse/HBASE-18631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16134563#comment-16134563 ] Hudson commented on HBASE-18631: SUCCESS: Integrated in Jenkins build HBase-1.2-IT #935 (See [https://builds.apache.org/job/HBase-1.2-IT/935/]) HBASE-18631 Allow ChaosMonkey properties to be specified in hbase-site (elserj: rev 5bf83cc14ee53bded53bba5e940cff81f82d15c3) * (edit) hbase-it/src/test/java/org/apache/hadoop/hbase/IntegrationTestBase.java * (edit) hbase-it/src/test/java/org/apache/hadoop/hbase/chaos/factories/MonkeyConstants.java * (add) hbase-it/src/test/java/org/apache/hadoop/hbase/TestIntegrationTestBase.java > Allow configuration of ChaosMonkey properties via hbase-site > > > Key: HBASE-18631 > URL: https://issues.apache.org/jira/browse/HBASE-18631 > Project: HBase > Issue Type: Improvement > Components: integration tests >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Minor > Fix For: 2.0.0, 1.4.0, 1.3.2, 1.2.7, 1.1.13 > > Attachments: HBASE-18631.001.patch > > > I noticed in some internal test automation that the code was attempting to > configure some of the chaos-monkey actions via hbase-site.xml, but these > weren't taking effect. > After reading the code, I found that these can only be specified via a > special properties file otherwise specified. It would be nice to also allow > configuration via hbase-site. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18631) Allow configuration of ChaosMonkey properties via hbase-site
[ https://issues.apache.org/jira/browse/HBASE-18631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16134562#comment-16134562 ] Hudson commented on HBASE-18631: SUCCESS: Integrated in Jenkins build HBase-1.3-IT #178 (See [https://builds.apache.org/job/HBase-1.3-IT/178/]) HBASE-18631 Allow ChaosMonkey properties to be specified in hbase-site (elserj: rev d1bd883593803bbc5f017d97f0959568dd1ae3aa) * (edit) hbase-it/src/test/java/org/apache/hadoop/hbase/chaos/factories/MonkeyConstants.java * (edit) hbase-it/src/test/java/org/apache/hadoop/hbase/IntegrationTestBase.java * (add) hbase-it/src/test/java/org/apache/hadoop/hbase/TestIntegrationTestBase.java > Allow configuration of ChaosMonkey properties via hbase-site > > > Key: HBASE-18631 > URL: https://issues.apache.org/jira/browse/HBASE-18631 > Project: HBase > Issue Type: Improvement > Components: integration tests >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Minor > Fix For: 2.0.0, 1.4.0, 1.3.2, 1.2.7, 1.1.13 > > Attachments: HBASE-18631.001.patch > > > I noticed in some internal test automation that the code was attempting to > configure some of the chaos-monkey actions via hbase-site.xml, but these > weren't taking effect. > After reading the code, I found that these can only be specified via a > special properties file otherwise specified. It would be nice to also allow > configuration via hbase-site. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18631) Allow configuration of ChaosMonkey properties via hbase-site
[ https://issues.apache.org/jira/browse/HBASE-18631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16134561#comment-16134561 ] Hudson commented on HBASE-18631: FAILURE: Integrated in Jenkins build HBase-1.2-JDK7 #199 (See [https://builds.apache.org/job/HBase-1.2-JDK7/199/]) HBASE-18631 Allow ChaosMonkey properties to be specified in hbase-site (elserj: rev 5bf83cc14ee53bded53bba5e940cff81f82d15c3) * (edit) hbase-it/src/test/java/org/apache/hadoop/hbase/chaos/factories/MonkeyConstants.java * (edit) hbase-it/src/test/java/org/apache/hadoop/hbase/IntegrationTestBase.java * (add) hbase-it/src/test/java/org/apache/hadoop/hbase/TestIntegrationTestBase.java > Allow configuration of ChaosMonkey properties via hbase-site > > > Key: HBASE-18631 > URL: https://issues.apache.org/jira/browse/HBASE-18631 > Project: HBase > Issue Type: Improvement > Components: integration tests >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Minor > Fix For: 2.0.0, 1.4.0, 1.3.2, 1.2.7, 1.1.13 > > Attachments: HBASE-18631.001.patch > > > I noticed in some internal test automation that the code was attempting to > configure some of the chaos-monkey actions via hbase-site.xml, but these > weren't taking effect. > After reading the code, I found that these can only be specified via a > special properties file otherwise specified. It would be nice to also allow > configuration via hbase-site. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18631) Allow configuration of ChaosMonkey properties via hbase-site
[ https://issues.apache.org/jira/browse/HBASE-18631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16134559#comment-16134559 ] Hudson commented on HBASE-18631: FAILURE: Integrated in Jenkins build HBase-1.3-JDK7 #245 (See [https://builds.apache.org/job/HBase-1.3-JDK7/245/]) HBASE-18631 Allow ChaosMonkey properties to be specified in hbase-site (elserj: rev d1bd883593803bbc5f017d97f0959568dd1ae3aa) * (add) hbase-it/src/test/java/org/apache/hadoop/hbase/TestIntegrationTestBase.java * (edit) hbase-it/src/test/java/org/apache/hadoop/hbase/chaos/factories/MonkeyConstants.java * (edit) hbase-it/src/test/java/org/apache/hadoop/hbase/IntegrationTestBase.java > Allow configuration of ChaosMonkey properties via hbase-site > > > Key: HBASE-18631 > URL: https://issues.apache.org/jira/browse/HBASE-18631 > Project: HBase > Issue Type: Improvement > Components: integration tests >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Minor > Fix For: 2.0.0, 1.4.0, 1.3.2, 1.2.7, 1.1.13 > > Attachments: HBASE-18631.001.patch > > > I noticed in some internal test automation that the code was attempting to > configure some of the chaos-monkey actions via hbase-site.xml, but these > weren't taking effect. > After reading the code, I found that these can only be specified via a > special properties file otherwise specified. It would be nice to also allow > configuration via hbase-site. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18639) nightly jobs that need to do jdk7 + jdk8 need more than 6 hours
[ https://issues.apache.org/jira/browse/HBASE-18639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16134554#comment-16134554 ] Sean Busbey commented on HBASE-18639: - it seems like maybe 8 or 9 is a good number to pick, until we can get a body of successful runs to use for judging. > nightly jobs that need to do jdk7 + jdk8 need more than 6 hours > --- > > Key: HBASE-18639 > URL: https://issues.apache.org/jira/browse/HBASE-18639 > Project: HBase > Issue Type: Task > Components: test >Reporter: Sean Busbey > Labels: beginner > Fix For: 1.3.2, 1.4.1, 1.5.0, 1.2.7 > > > looks like the branches that need to do 2 jdks will need more than 6 hours, > at least until we can parallelize things. > e.g. > * > [branch-1.2|https://builds.apache.org/view/H-L/view/HBase/job/HBase%20Nightly/job/branch-1.2/buildTimeTrend] > * > [branch-1.3|https://builds.apache.org/view/H-L/view/HBase/job/HBase%20Nightly/job/branch-1.3/buildTimeTrend] > branch-1.4 and branch-1 are failing in jdk7 checks, so they don't go that > long yet, but once we get those tests fixed presumably they'll need the time > as well. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18631) Allow configuration of ChaosMonkey properties via hbase-site
[ https://issues.apache.org/jira/browse/HBASE-18631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated HBASE-18631: --- Resolution: Fixed Hadoop Flags: Reviewed Release Note: This change invalidates the need for a separate Java properties file to configure the ChaosMonkey included with HBase. These properties can be provided directly in hbase-site.xml. If configuration in provided in both locations, the Java properties file takes precendence. Status: Resolved (was: Patch Available) Thanks for the review, Ted! Committed around the horn. > Allow configuration of ChaosMonkey properties via hbase-site > > > Key: HBASE-18631 > URL: https://issues.apache.org/jira/browse/HBASE-18631 > Project: HBase > Issue Type: Improvement > Components: integration tests >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Minor > Fix For: 2.0.0, 1.4.0, 1.3.2, 1.2.7, 1.1.13 > > Attachments: HBASE-18631.001.patch > > > I noticed in some internal test automation that the code was attempting to > configure some of the chaos-monkey actions via hbase-site.xml, but these > weren't taking effect. > After reading the code, I found that these can only be specified via a > special properties file otherwise specified. It would be nice to also allow > configuration via hbase-site. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-18639) nightly jobs that need to do jdk7 + jdk8 need more than 6 hours
Sean Busbey created HBASE-18639: --- Summary: nightly jobs that need to do jdk7 + jdk8 need more than 6 hours Key: HBASE-18639 URL: https://issues.apache.org/jira/browse/HBASE-18639 Project: HBase Issue Type: Task Components: test Reporter: Sean Busbey Fix For: 1.3.2, 1.4.1, 1.5.0, 1.2.7 looks like the branches that need to do 2 jdks will need more than 6 hours, at least until we can parallelize things. e.g. * [branch-1.2|https://builds.apache.org/view/H-L/view/HBase/job/HBase%20Nightly/job/branch-1.2/buildTimeTrend] * [branch-1.3|https://builds.apache.org/view/H-L/view/HBase/job/HBase%20Nightly/job/branch-1.3/buildTimeTrend] branch-1.4 and branch-1 are failing in jdk7 checks, so they don't go that long yet, but once we get those tests fixed presumably they'll need the time as well. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18638) The old cells will return to client if the new cells are deleted
[
https://issues.apache.org/jira/browse/HBASE-18638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16134529#comment-16134529
]
Hadoop QA commented on HBASE-18638:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
17s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
14s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
49s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
55s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
19s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
54s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
36s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
57s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
50s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
50s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
56s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
19s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
38m 1s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
1s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
37s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 80m 42s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
30s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}138m 20s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.client.TestFromClientSide3 |
| Timed out junit tests |
org.apache.hadoop.hbase.master.procedure.TestDisableTableProcedure |
| | org.apache.hadoop.hbase.master.procedure.TestEnableTableProcedure |
| | org.apache.hadoop.hbase.master.procedure.TestDeleteTableProcedure |
| | org.apache.hadoop.hbase.master.procedure.TestModifyTableProcedure |
| | org.apache.hadoop.hbase.master.procedure.TestCreateTableProcedure |
| | org.apache.hadoop.hbase.master.procedure.TestServerCrashProcedure |
| | org.apache.hadoop.hbase.regionserver.TestRowTooBig |
| | org.apache.hadoop.hbase.regionserver.TestSplitLogWorker |
| | org.apache.hadoop.hbase.mapreduce.TestWALPlayer |
| | org.apache.hadoop.hbase.regionserver.compactions.TestFIFOCompactionPolicy
|
| | org.apache.hadoop.hbase.mapreduce.TestTableInputFormat |
| | org.apache.hadoop.hbase.mapreduce.TestHRegionPartitioner |
| | org.apache.hadoop.hbase.master.TestGetLastFlushedSequenceId |
| | org.apache.hadoop.hbase.master.procedure.TestSafemodeBringsDownMaster |
| | org.apache.hadoop.hbase.regionserver.wal.TestFSHLog |
| | org.apache.hadoop.hbase.regionserver.TestCompaction |
| | org.apache.hadoop.hbase.trace.TestHTraceHooks |
| | org.apache.hadoop.hbase.master.balancer.TestStochasticLoadBalancer2 |
| | org.apache.hadoop.hbase.regionserver.TestRegionServerMetrics |
| | org.apache.hadoop.hbase.regionserver.TestRemoveRegionMetrics |
| | org.apache.hadoop.hbase.snapshot.
[jira] [Commented] (HBASE-17823) Migrate to Apache Yetus Audience Annotations
[ https://issues.apache.org/jira/browse/HBASE-17823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16134526#comment-16134526 ] Misty Stanley-Jones commented on HBASE-17823: - That would work, or just keep the doc changes in a separate commit during PR review (you can review each commit separately) and then squash them before push. > Migrate to Apache Yetus Audience Annotations > > > Key: HBASE-17823 > URL: https://issues.apache.org/jira/browse/HBASE-17823 > Project: HBase > Issue Type: Improvement > Components: API >Affects Versions: 2.0.0 >Reporter: Sean Busbey >Assignee: Sean Busbey > Fix For: 2.0.0 > > Attachments: HBASE-17823.0.patch > > > Migrate from our own audience annotation handling to apache yetus' > implementation. > [discussion thread on > dev@hbase|https://lists.apache.org/thread.html/5a83d37c9c763b3fc4114231489a073167ac69dbade9774af5ca4fb4@%3Cdev.hbase.apache.org%3E] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18638) The old cells will return to client if the new cells are deleted
[ https://issues.apache.org/jira/browse/HBASE-18638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai updated HBASE-18638: --- Status: Patch Available (was: Open) > The old cells will return to client if the new cells are deleted > > > Key: HBASE-18638 > URL: https://issues.apache.org/jira/browse/HBASE-18638 > Project: HBase > Issue Type: Bug >Reporter: Chia-Ping Tsai >Priority: Critical > Fix For: 2.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7 > > Attachments: HBASE-18638-ut.patch > > > |put_0(t0)| > |put_1(t1)| <-- the latest cell > If we call get, the put_1 will return. That is good. > If we call get after a delete, the put_0 will return. That is weird. The > put_0 is old data, and it should be dropped in flush. For client, put_0 > should not exist after the put_1 happen. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (HBASE-18638) The old cells will return to client if the new cells are deleted
[ https://issues.apache.org/jira/browse/HBASE-18638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai reassigned HBASE-18638: -- Assignee: Chia-Ping Tsai > The old cells will return to client if the new cells are deleted > > > Key: HBASE-18638 > URL: https://issues.apache.org/jira/browse/HBASE-18638 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.1, 1.2.6, 2.0.0-alpha-1 >Reporter: Chia-Ping Tsai >Assignee: Chia-Ping Tsai >Priority: Critical > Fix For: 2.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7 > > Attachments: HBASE-18638-ut.patch > > > |put_0(t0)| > |put_1(t1)| <-- the latest cell > If we call get, the put_1 will return. That is good. > If we call get after a delete, the put_0 will return. That is weird. The > put_0 is old data, and it should be dropped in flush. For client, put_0 > should not exist after the put_1 happen. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18638) The old cells will return to client if the new cells are deleted
[ https://issues.apache.org/jira/browse/HBASE-18638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai updated HBASE-18638: --- Affects Version/s: 1.3.1 1.2.6 2.0.0-alpha-1 > The old cells will return to client if the new cells are deleted > > > Key: HBASE-18638 > URL: https://issues.apache.org/jira/browse/HBASE-18638 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.1, 1.2.6, 2.0.0-alpha-1 >Reporter: Chia-Ping Tsai >Assignee: Chia-Ping Tsai >Priority: Critical > Fix For: 2.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7 > > Attachments: HBASE-18638-ut.patch > > > |put_0(t0)| > |put_1(t1)| <-- the latest cell > If we call get, the put_1 will return. That is good. > If we call get after a delete, the put_0 will return. That is weird. The > put_0 is old data, and it should be dropped in flush. For client, put_0 > should not exist after the put_1 happen. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18638) The old cells will return to client if the new cells are deleted
[ https://issues.apache.org/jira/browse/HBASE-18638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai updated HBASE-18638: --- Attachment: HBASE-18638-ut.patch see client.TestFromClientSide3#testDeleteOldVersion for more information. > The old cells will return to client if the new cells are deleted > > > Key: HBASE-18638 > URL: https://issues.apache.org/jira/browse/HBASE-18638 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.1, 1.2.6, 2.0.0-alpha-1 >Reporter: Chia-Ping Tsai >Priority: Critical > Fix For: 2.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7 > > Attachments: HBASE-18638-ut.patch > > > |put_0(t0)| > |put_1(t1)| <-- the latest cell > If we call get, the put_1 will return. That is good. > If we call get after a delete, the put_0 will return. That is weird. The > put_0 is old data, and it should be dropped in flush. For client, put_0 > should not exist after the put_1 happen. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18638) The old cells will return to client if the new cells are deleted
[ https://issues.apache.org/jira/browse/HBASE-18638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai updated HBASE-18638: --- Fix Version/s: 1.2.7 1.5.0 1.3.2 1.4.0 2.0.0 > The old cells will return to client if the new cells are deleted > > > Key: HBASE-18638 > URL: https://issues.apache.org/jira/browse/HBASE-18638 > Project: HBase > Issue Type: Bug >Reporter: Chia-Ping Tsai >Priority: Critical > Fix For: 2.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7 > > > |put_0(t0)| > |put_1(t1)| <-- the latest cell > If we call get, the put_1 will return. That is good. > If we call get after a delete, the put_0 will return. That is weird. The > put_0 is old data, and it should be dropped in flush. For client, put_0 > should not exist after the put_1 happen. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18638) The old cells will return to client if the new cells are deleted
[ https://issues.apache.org/jira/browse/HBASE-18638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai updated HBASE-18638: --- Description: |put_0(t0)| |put_1(t1)| <-- the latest cell If we call get, the put_1 will return. That is good. If we call get after a delete, the put_0 will return. That is weird. The put_0 is old data, and it should be dropped in flush. For client, put_0 should not exist after the put_1 happen. was: |put_0(t0)| |put_1(t1)| <-- the latest cell If we call get, the put_1 will return. That is good. If we call get after a delete, the put_0 will return. That is weird. The put_0 is old data, and it should be dropped in flush. For client, put_0 should not exist after the put_1 happen. > The old cells will return to client if the new cells are deleted > > > Key: HBASE-18638 > URL: https://issues.apache.org/jira/browse/HBASE-18638 > Project: HBase > Issue Type: Bug >Reporter: Chia-Ping Tsai >Priority: Critical > > |put_0(t0)| > |put_1(t1)| <-- the latest cell > If we call get, the put_1 will return. That is good. > If we call get after a delete, the put_0 will return. That is weird. The > put_0 is old data, and it should be dropped in flush. For client, put_0 > should not exist after the put_1 happen. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-18638) The old cells will return to client if the new cells are deleted
Chia-Ping Tsai created HBASE-18638: -- Summary: The old cells will return to client if the new cells are deleted Key: HBASE-18638 URL: https://issues.apache.org/jira/browse/HBASE-18638 Project: HBase Issue Type: Bug Reporter: Chia-Ping Tsai Priority: Critical |put_0(t0)| |put_1(t1)| <-- the latest cell If we call get, the put_1 will return. That is good. If we call get after a delete, the put_0 will return. That is weird. The put_0 is old data, and it should be dropped in flush. For client, put_0 should not exist after the put_1 happen. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18637) Update the link of "Bending time in HBase"
[
https://issues.apache.org/jira/browse/HBASE-18637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai updated HBASE-18637:
---
Priority: Trivial (was: Major)
> Update the link of "Bending time in HBase"
> --
>
> Key: HBASE-18637
> URL: https://issues.apache.org/jira/browse/HBASE-18637
> Project: HBase
> Issue Type: Bug
> Components: documentation
>Reporter: Chia-Ping Tsai
>Priority: Trivial
> Labels: beginner
> Fix For: 2.0.0
>
>
> {code:title=datamodel.adoc}
> link:http://outerthought.org/blog/417-ot.html[Bending time in HBase]
> {code}
> The link is changed to "https://www.ngdata.com/bending-time-in-hbase/";
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (HBASE-18637) Update the link of "Bending time in HBase"
Chia-Ping Tsai created HBASE-18637:
--
Summary: Update the link of "Bending time in HBase"
Key: HBASE-18637
URL: https://issues.apache.org/jira/browse/HBASE-18637
Project: HBase
Issue Type: Bug
Components: documentation
Reporter: Chia-Ping Tsai
Fix For: 2.0.0
{code:title=datamodel.adoc}
link:http://outerthought.org/blog/417-ot.html[Bending time in HBase]
{code}
The link is changed to "https://www.ngdata.com/bending-time-in-hbase/";
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18631) Allow configuration of ChaosMonkey properties via hbase-site
[ https://issues.apache.org/jira/browse/HBASE-18631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16134466#comment-16134466 ] Ted Yu commented on HBASE-18631: lgtm > Allow configuration of ChaosMonkey properties via hbase-site > > > Key: HBASE-18631 > URL: https://issues.apache.org/jira/browse/HBASE-18631 > Project: HBase > Issue Type: Improvement > Components: integration tests >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Minor > Fix For: 2.0.0, 1.4.0, 1.3.2, 1.2.7, 1.1.13 > > Attachments: HBASE-18631.001.patch > > > I noticed in some internal test automation that the code was attempting to > configure some of the chaos-monkey actions via hbase-site.xml, but these > weren't taking effect. > After reading the code, I found that these can only be specified via a > special properties file otherwise specified. It would be nice to also allow > configuration via hbase-site. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18634) Fix client.TestClientClusterStatus
[
https://issues.apache.org/jira/browse/HBASE-18634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16134350#comment-16134350
]
Hadoop QA commented on HBASE-18634:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
24s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
36s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
46s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
51s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
16s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
17s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
30s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
53s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
41s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
41s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
48s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
15s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
33m 4s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
12s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
29s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}111m
58s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
16s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}163m 39s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:bdc94b1 |
| JIRA Issue | HBASE-18634 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12882763/HBASE-18634.v0.patch |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux 2be48d19c0ac 3.13.0-119-generic #166-Ubuntu SMP Wed May 3
12:18:55 UTC 2017 x86_64 x86_64 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 / b932d38 |
| Default Java | 1.8.0_144 |
| findbugs | v3.1.0-RC3 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/8181/testReport/ |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/8181/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
This message was automatically generated.
> Fix client.TestClientClusterStatus
> --
>
> Key: HBASE-18634
> URL: https://issues.apache.org/jira/browse/HBASE-18634
> Project: HBase
> Issue Type: Bug
> Components: test
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
> Fix For: 2.0.0
>
> Attachments: HBASE-18634.v0.patch, HBASE-18634.v0.patch
>
>
> After HBASE-18511, th
[jira] [Commented] (HBASE-17442) Move most of the replication related classes to hbase-server package
[
https://issues.apache.org/jira/browse/HBASE-17442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16134320#comment-16134320
]
Hadoop QA commented on HBASE-17442:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
19s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
8s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
33s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
55s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 4m
52s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 2m
3s{color} | {color:green} branch-2 passed {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source: . {color}
|
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
18s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m
58s{color} | {color:green} branch-2 passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
8s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
32s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 4m
25s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 4m
25s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
47s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 2m
30s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m
0s{color} | {color:red} The patch has 1 line(s) that end in whitespace. Use git
apply --whitespace=fix <>. Refer https://git-scm.com/docs/git-apply
{color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m
4s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 0m
31s{color} | {color:red} The patch causes 16 errors with Hadoop v2.4.0. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 0m
58s{color} | {color:red} The patch causes 16 errors with Hadoop v2.4.1. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 1m
24s{color} | {color:red} The patch causes 16 errors with Hadoop v2.5.0. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 1m
50s{color} | {color:red} The patch causes 16 errors with Hadoop v2.5.1. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 2m
15s{color} | {color:red} The patch causes 16 errors with Hadoop v2.5.2. {color}
|
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source: . {color}
|
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
34s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m
19s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
43s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
10s{color} | {color:green} hbase-replication in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}107m
11s{color} | {co
