[jira] [Commented] (HBASE-16264) Figure how to deal with endpoints and shaded pb
[ https://issues.apache.org/jira/browse/HBASE-16264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411393#comment-15411393 ] ramkrishna.s.vasudevan commented on HBASE-16264: bq.At the moment having copies of base HBase Protos +1 bq.so corps are standalone Sorry. Corps in the sense? > Figure how to deal with endpoints and shaded pb > --- > > Key: HBASE-16264 > URL: https://issues.apache.org/jira/browse/HBASE-16264 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors, Protobufs >Reporter: stack >Assignee: stack > > Come up w/ a migration plan for coprocessor endpoints when our pb is shaded. > Would be sweet if could make it so all just worked. At worst, come up w/ a > prescription for how to migrate existing CPs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-9465) Push entries to peer clusters serially
[ https://issues.apache.org/jira/browse/HBASE-9465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411369#comment-15411369 ] Duo Zhang commented on HBASE-9465: -- Good. Thanks for reviewing. Will commit shortly. > Push entries to peer clusters serially > -- > > Key: HBASE-9465 > URL: https://issues.apache.org/jira/browse/HBASE-9465 > Project: HBase > Issue Type: New Feature > Components: regionserver, Replication >Reporter: Honghua Feng >Assignee: Phil Yang > Attachments: HBASE-9465-branch-1-v1.patch, > HBASE-9465-branch-1-v1.patch, HBASE-9465-branch-1-v2.patch, > HBASE-9465-branch-1-v3.patch, HBASE-9465-v1.patch, HBASE-9465-v2.patch, > HBASE-9465-v2.patch, HBASE-9465-v3.patch, HBASE-9465-v4.patch, > HBASE-9465-v5.patch, HBASE-9465-v6.patch, HBASE-9465.pdf > > > When region-move or RS failure occurs in master cluster, the hlog entries > that are not pushed before region-move or RS-failure will be pushed by > original RS(for region move) or another RS which takes over the remained hlog > of dead RS(for RS failure), and the new entries for the same region(s) will > be pushed by the RS which now serves the region(s), but they push the hlog > entries of a same region concurrently without coordination. > This treatment can possibly lead to data inconsistency between master and > peer clusters: > 1. there are put and then delete written to master cluster > 2. due to region-move / RS-failure, they are pushed by different > replication-source threads to peer cluster > 3. if delete is pushed to peer cluster before put, and flush and > major-compact occurs in peer cluster before put is pushed to peer cluster, > the delete is collected and the put remains in peer cluster > In this scenario, the put remains in peer cluster, but in master cluster the > put is masked by the delete, hence data inconsistency between master and peer > clusters -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12770) Don't transfer all the queued hlogs of a dead server to the same alive server
[ https://issues.apache.org/jira/browse/HBASE-12770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Yang updated HBASE-12770: -- Attachment: HBASE-12770-branch-1-v3.patch > Don't transfer all the queued hlogs of a dead server to the same alive server > - > > Key: HBASE-12770 > URL: https://issues.apache.org/jira/browse/HBASE-12770 > Project: HBase > Issue Type: Improvement > Components: Replication >Reporter: Jianwei Cui >Assignee: Phil Yang >Priority: Minor > Attachments: HBASE-12770-branch-1-v1.patch, > HBASE-12770-branch-1-v2.patch, HBASE-12770-branch-1-v3.patch, > HBASE-12770-branch-1-v3.patch, HBASE-12770-branch-1-v3.patch, > HBASE-12770-branch-1-v3.patch, HBASE-12770-trunk.patch, HBASE-12770-v1.patch, > HBASE-12770-v2.patch, HBASE-12770-v3.patch, HBASE-12770-v3.patch > > > When a region server is down(or the cluster restart), all the hlog queues > will be transferred by the same alive region server. In a shared cluster, we > might create several peers replicating data to different peer clusters. There > might be lots of hlogs queued for these peers caused by several reasons, such > as some peers might be disabled, or errors from peer cluster might prevent > the replication, or the replication sources may fail to read some hlog > because of hdfs problem. Then, if the server is down or restarted, another > alive server will take all the replication jobs of the dead server, this > might bring a big pressure to resources(network/disk read) of the alive > server and also is not fast enough to replicate the queued hlogs. And if the > alive server is down, all the replication jobs including that takes from > other dead servers will once again be totally transferred to another alive > server, this might cause a server have a large number of queued hlogs(in our > shared cluster, we find one server might have thousands of queued hlogs for > replication). As an optional way, is it reasonable that the alive server only > transfer one peer's hlogs from the dead server one time? Then, other alive > region servers might have the opportunity to transfer the hlogs of rest > peers. This may also help the queued hlogs be processed more fast. Any > discussion is welcome. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12770) Don't transfer all the queued hlogs of a dead server to the same alive server
[
https://issues.apache.org/jira/browse/HBASE-12770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411358#comment-15411358
]
Hadoop QA commented on HBASE-12770:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 11s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 2 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 19s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
51s {color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 45s
{color} | {color:green} branch-1 passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 50s
{color} | {color:green} branch-1 passed with JDK v1.7.0_101 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
53s {color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
27s {color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
50s {color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 40s
{color} | {color:green} branch-1 passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 54s
{color} | {color:green} branch-1 passed with JDK v1.7.0_101 {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 10s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
4s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 44s
{color} | {color:green} the patch passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 44s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 51s
{color} | {color:green} the patch passed with JDK v1.7.0_101 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 51s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
53s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
27s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
16m 5s {color} | {color:green} The patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green} 0m
25s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
16s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 39s
{color} | {color:green} the patch passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 53s
{color} | {color:green} the patch passed with JDK v1.7.0_101 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 34s
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 16m 10s {color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
20s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 53m 55s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.quotas.TestRateLimiter |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.11.2 Server=1.11.2 Image:yetus/hbase:date2016-08-08 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12822510/HBASE-
[jira] [Commented] (HBASE-9465) Push entries to peer clusters serially
[ https://issues.apache.org/jira/browse/HBASE-9465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411354#comment-15411354 ] Ashish Singhi commented on HBASE-9465: -- No. > Push entries to peer clusters serially > -- > > Key: HBASE-9465 > URL: https://issues.apache.org/jira/browse/HBASE-9465 > Project: HBase > Issue Type: New Feature > Components: regionserver, Replication >Reporter: Honghua Feng >Assignee: Phil Yang > Attachments: HBASE-9465-branch-1-v1.patch, > HBASE-9465-branch-1-v1.patch, HBASE-9465-branch-1-v2.patch, > HBASE-9465-branch-1-v3.patch, HBASE-9465-v1.patch, HBASE-9465-v2.patch, > HBASE-9465-v2.patch, HBASE-9465-v3.patch, HBASE-9465-v4.patch, > HBASE-9465-v5.patch, HBASE-9465-v6.patch, HBASE-9465.pdf > > > When region-move or RS failure occurs in master cluster, the hlog entries > that are not pushed before region-move or RS-failure will be pushed by > original RS(for region move) or another RS which takes over the remained hlog > of dead RS(for RS failure), and the new entries for the same region(s) will > be pushed by the RS which now serves the region(s), but they push the hlog > entries of a same region concurrently without coordination. > This treatment can possibly lead to data inconsistency between master and > peer clusters: > 1. there are put and then delete written to master cluster > 2. due to region-move / RS-failure, they are pushed by different > replication-source threads to peer cluster > 3. if delete is pushed to peer cluster before put, and flush and > major-compact occurs in peer cluster before put is pushed to peer cluster, > the delete is collected and the put remains in peer cluster > In this scenario, the put remains in peer cluster, but in master cluster the > put is masked by the delete, hence data inconsistency between master and peer > clusters -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16091) Canary takes lot more time when there are delete markers in the table
[ https://issues.apache.org/jira/browse/HBASE-16091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411353#comment-15411353 ] Vishal Khandelwal commented on HBASE-16091: --- Wanted to comment for a different JIRA. deleting this. > Canary takes lot more time when there are delete markers in the table > - > > Key: HBASE-16091 > URL: https://issues.apache.org/jira/browse/HBASE-16091 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0 >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal > Fix For: 2.0.0, 1.4.0, 0.98.21 > > Attachments: HBASE-16091.00.patch, HBASE-16091.01.patch, > HBASE-16091.02.patch > > > We have a table which has lot of delete markers and we running Canary test on > a regular interval sometimes tests are timing out because to reading first > row would skip all these delete markers. Since purpose of Canary is to find > health of the region, i think keeping raw=true would not defeat the purpose > but provide good perf improvement. > Following are the example of one such scan where > without changing code it took 62.3 sec for onre region scan > 2016-06-23 08:49:11,670 INFO [pool-2-thread-1] tool.Canary - read from > region . column family 0 in 62338ms > whereas after setting raw=true, it reduced to 58ms > 2016-06-23 08:45:20,259 INFO [pool-2-thread-1] tests.Canary - read from > region . column family 0 in 58ms > Taking this over multiple tables , with multiple region would be a good > performance gain. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (HBASE-16091) Canary takes lot more time when there are delete markers in the table
[ https://issues.apache.org/jira/browse/HBASE-16091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Khandelwal updated HBASE-16091: -- Comment: was deleted (was: Wanted to comment for a different JIRA. deleting this.) > Canary takes lot more time when there are delete markers in the table > - > > Key: HBASE-16091 > URL: https://issues.apache.org/jira/browse/HBASE-16091 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0 >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal > Fix For: 2.0.0, 1.4.0, 0.98.21 > > Attachments: HBASE-16091.00.patch, HBASE-16091.01.patch, > HBASE-16091.02.patch > > > We have a table which has lot of delete markers and we running Canary test on > a regular interval sometimes tests are timing out because to reading first > row would skip all these delete markers. Since purpose of Canary is to find > health of the region, i think keeping raw=true would not defeat the purpose > but provide good perf improvement. > Following are the example of one such scan where > without changing code it took 62.3 sec for onre region scan > 2016-06-23 08:49:11,670 INFO [pool-2-thread-1] tool.Canary - read from > region . column family 0 in 62338ms > whereas after setting raw=true, it reduced to 58ms > 2016-06-23 08:45:20,259 INFO [pool-2-thread-1] tests.Canary - read from > region . column family 0 in 58ms > Taking this over multiple tables , with multiple region would be a good > performance gain. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (HBASE-16091) Canary takes lot more time when there are delete markers in the table
[ https://issues.apache.org/jira/browse/HBASE-16091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Khandelwal updated HBASE-16091: -- Comment: was deleted (was: [~apurtell]: Looks this this made it to 0.98 due to some integration issue. Let me know if i should re-create the patch.) > Canary takes lot more time when there are delete markers in the table > - > > Key: HBASE-16091 > URL: https://issues.apache.org/jira/browse/HBASE-16091 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0 >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal > Fix For: 2.0.0, 1.4.0, 0.98.21 > > Attachments: HBASE-16091.00.patch, HBASE-16091.01.patch, > HBASE-16091.02.patch > > > We have a table which has lot of delete markers and we running Canary test on > a regular interval sometimes tests are timing out because to reading first > row would skip all these delete markers. Since purpose of Canary is to find > health of the region, i think keeping raw=true would not defeat the purpose > but provide good perf improvement. > Following are the example of one such scan where > without changing code it took 62.3 sec for onre region scan > 2016-06-23 08:49:11,670 INFO [pool-2-thread-1] tool.Canary - read from > region . column family 0 in 62338ms > whereas after setting raw=true, it reduced to 58ms > 2016-06-23 08:45:20,259 INFO [pool-2-thread-1] tests.Canary - read from > region . column family 0 in 58ms > Taking this over multiple tables , with multiple region would be a good > performance gain. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16091) Canary takes lot more time when there are delete markers in the table
[ https://issues.apache.org/jira/browse/HBASE-16091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411350#comment-15411350 ] Vishal Khandelwal commented on HBASE-16091: --- [~apurtell]: Looks this this made it to 0.98 due to some integration issue. Let me know if i should re-create the patch. > Canary takes lot more time when there are delete markers in the table > - > > Key: HBASE-16091 > URL: https://issues.apache.org/jira/browse/HBASE-16091 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0 >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal > Fix For: 2.0.0, 1.4.0, 0.98.21 > > Attachments: HBASE-16091.00.patch, HBASE-16091.01.patch, > HBASE-16091.02.patch > > > We have a table which has lot of delete markers and we running Canary test on > a regular interval sometimes tests are timing out because to reading first > row would skip all these delete markers. Since purpose of Canary is to find > health of the region, i think keeping raw=true would not defeat the purpose > but provide good perf improvement. > Following are the example of one such scan where > without changing code it took 62.3 sec for onre region scan > 2016-06-23 08:49:11,670 INFO [pool-2-thread-1] tool.Canary - read from > region . column family 0 in 62338ms > whereas after setting raw=true, it reduced to 58ms > 2016-06-23 08:45:20,259 INFO [pool-2-thread-1] tests.Canary - read from > region . column family 0 in 58ms > Taking this over multiple tables , with multiple region would be a good > performance gain. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-9465) Push entries to peer clusters serially
[ https://issues.apache.org/jira/browse/HBASE-9465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411348#comment-15411348 ] Ashish Singhi commented on HBASE-9465: -- OK. > Push entries to peer clusters serially > -- > > Key: HBASE-9465 > URL: https://issues.apache.org/jira/browse/HBASE-9465 > Project: HBase > Issue Type: New Feature > Components: regionserver, Replication >Reporter: Honghua Feng >Assignee: Phil Yang > Attachments: HBASE-9465-branch-1-v1.patch, > HBASE-9465-branch-1-v1.patch, HBASE-9465-branch-1-v2.patch, > HBASE-9465-branch-1-v3.patch, HBASE-9465-v1.patch, HBASE-9465-v2.patch, > HBASE-9465-v2.patch, HBASE-9465-v3.patch, HBASE-9465-v4.patch, > HBASE-9465-v5.patch, HBASE-9465-v6.patch, HBASE-9465.pdf > > > When region-move or RS failure occurs in master cluster, the hlog entries > that are not pushed before region-move or RS-failure will be pushed by > original RS(for region move) or another RS which takes over the remained hlog > of dead RS(for RS failure), and the new entries for the same region(s) will > be pushed by the RS which now serves the region(s), but they push the hlog > entries of a same region concurrently without coordination. > This treatment can possibly lead to data inconsistency between master and > peer clusters: > 1. there are put and then delete written to master cluster > 2. due to region-move / RS-failure, they are pushed by different > replication-source threads to peer cluster > 3. if delete is pushed to peer cluster before put, and flush and > major-compact occurs in peer cluster before put is pushed to peer cluster, > the delete is collected and the put remains in peer cluster > In this scenario, the put remains in peer cluster, but in master cluster the > put is masked by the delete, hence data inconsistency between master and peer > clusters -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16264) Figure how to deal with endpoints and shaded pb
[ https://issues.apache.org/jira/browse/HBASE-16264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411335#comment-15411335 ] Anoop Sam John commented on HBASE-16264: So we will need hbase.proto , cell.proto etc for the CPEPs? May be not all defn in that.. So all the required defn may be we can copy to new file and make it as base for CPEPs. Ya copy may look ugly but what to do ! +1 > Figure how to deal with endpoints and shaded pb > --- > > Key: HBASE-16264 > URL: https://issues.apache.org/jira/browse/HBASE-16264 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors, Protobufs >Reporter: stack >Assignee: stack > > Come up w/ a migration plan for coprocessor endpoints when our pb is shaded. > Would be sweet if could make it so all just worked. At worst, come up w/ a > prescription for how to migrate existing CPs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-9465) Push entries to peer clusters serially
[ https://issues.apache.org/jira/browse/HBASE-9465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411314#comment-15411314 ] Duo Zhang commented on HBASE-9465: -- [~ashish singhi] Any other concerns? Thanks, > Push entries to peer clusters serially > -- > > Key: HBASE-9465 > URL: https://issues.apache.org/jira/browse/HBASE-9465 > Project: HBase > Issue Type: New Feature > Components: regionserver, Replication >Reporter: Honghua Feng >Assignee: Phil Yang > Attachments: HBASE-9465-branch-1-v1.patch, > HBASE-9465-branch-1-v1.patch, HBASE-9465-branch-1-v2.patch, > HBASE-9465-branch-1-v3.patch, HBASE-9465-v1.patch, HBASE-9465-v2.patch, > HBASE-9465-v2.patch, HBASE-9465-v3.patch, HBASE-9465-v4.patch, > HBASE-9465-v5.patch, HBASE-9465-v6.patch, HBASE-9465.pdf > > > When region-move or RS failure occurs in master cluster, the hlog entries > that are not pushed before region-move or RS-failure will be pushed by > original RS(for region move) or another RS which takes over the remained hlog > of dead RS(for RS failure), and the new entries for the same region(s) will > be pushed by the RS which now serves the region(s), but they push the hlog > entries of a same region concurrently without coordination. > This treatment can possibly lead to data inconsistency between master and > peer clusters: > 1. there are put and then delete written to master cluster > 2. due to region-move / RS-failure, they are pushed by different > replication-source threads to peer cluster > 3. if delete is pushed to peer cluster before put, and flush and > major-compact occurs in peer cluster before put is pushed to peer cluster, > the delete is collected and the put remains in peer cluster > In this scenario, the put remains in peer cluster, but in master cluster the > put is masked by the delete, hence data inconsistency between master and peer > clusters -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12770) Don't transfer all the queued hlogs of a dead server to the same alive server
[ https://issues.apache.org/jira/browse/HBASE-12770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Yang updated HBASE-12770: -- Attachment: HBASE-12770-branch-1-v3.patch > Don't transfer all the queued hlogs of a dead server to the same alive server > - > > Key: HBASE-12770 > URL: https://issues.apache.org/jira/browse/HBASE-12770 > Project: HBase > Issue Type: Improvement > Components: Replication >Reporter: Jianwei Cui >Assignee: Phil Yang >Priority: Minor > Attachments: HBASE-12770-branch-1-v1.patch, > HBASE-12770-branch-1-v2.patch, HBASE-12770-branch-1-v3.patch, > HBASE-12770-branch-1-v3.patch, HBASE-12770-branch-1-v3.patch, > HBASE-12770-trunk.patch, HBASE-12770-v1.patch, HBASE-12770-v2.patch, > HBASE-12770-v3.patch, HBASE-12770-v3.patch > > > When a region server is down(or the cluster restart), all the hlog queues > will be transferred by the same alive region server. In a shared cluster, we > might create several peers replicating data to different peer clusters. There > might be lots of hlogs queued for these peers caused by several reasons, such > as some peers might be disabled, or errors from peer cluster might prevent > the replication, or the replication sources may fail to read some hlog > because of hdfs problem. Then, if the server is down or restarted, another > alive server will take all the replication jobs of the dead server, this > might bring a big pressure to resources(network/disk read) of the alive > server and also is not fast enough to replicate the queued hlogs. And if the > alive server is down, all the replication jobs including that takes from > other dead servers will once again be totally transferred to another alive > server, this might cause a server have a large number of queued hlogs(in our > shared cluster, we find one server might have thousands of queued hlogs for > replication). As an optional way, is it reasonable that the alive server only > transfer one peer's hlogs from the dead server one time? Then, other alive > region servers might have the opportunity to transfer the hlogs of rest > peers. This may also help the queued hlogs be processed more fast. Any > discussion is welcome. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12770) Don't transfer all the queued hlogs of a dead server to the same alive server
[
https://issues.apache.org/jira/browse/HBASE-12770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411285#comment-15411285
]
Hadoop QA commented on HBASE-12770:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 10s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 4 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 13s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
2s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 46s
{color} | {color:green} master passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 53s
{color} | {color:green} master passed with JDK v1.7.0_101 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
48s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
27s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
51s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 40s
{color} | {color:green} master passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 53s
{color} | {color:green} master passed with JDK v1.7.0_101 {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 11s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
6s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 48s
{color} | {color:green} the patch passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 48s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 52s
{color} | {color:green} the patch passed with JDK v1.7.0_101 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 52s
{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
28s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
27m 20s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green} 0m
26s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
21s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 39s
{color} | {color:green} the patch passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 52s
{color} | {color:green} the patch passed with JDK v1.7.0_101 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 59s
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 89m 41s
{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
32s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 139m 28s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.11.2 Server=1.11.2 Image:yetus/hbase:date2016-08-08 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12822498/HBASE-12770-v3.patch |
| JIRA Issue | HBASE-12770 |
| Optional Tests | asflicense javac javadoc unit
[jira] [Commented] (HBASE-16370) Exclude jdk tools.jar from Bytecode Version enforcer
[
https://issues.apache.org/jira/browse/HBASE-16370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411263#comment-15411263
]
Jerry He commented on HBASE-16370:
--
hbase-annotations has a dependency on the jdk tools.jar.
Exactly, we don't ship it. There is no need to check it for bytecode version,
at least not from the original purpose of the Bytecode Version enforcer.
The Bytecode Version enforcer's purpose is not for checking API compatibility
either, right?
On the other hand, my argument or incentive to do this change is not persuasive
probably?
> Exclude jdk tools.jar from Bytecode Version enforcer
>
>
> Key: HBASE-16370
> URL: https://issues.apache.org/jira/browse/HBASE-16370
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 1.2.2
>Reporter: Jerry He
>Assignee: Jerry He
>Priority: Minor
> Fix For: 2.0.0, 1.3.0, 1.4.0, 1.2.3
>
> Attachments: HBASE-16370.patch
>
>
> Getting this message trying to do a build with -Prelease:
> {noformat}
> [INFO] Restricted to JDK 1.7 yet jdk.tools:jdk.tools:jar:1.8:system contains
> org/relaxng/datatype/DatatypeLibrary.class targeted to JDK 1.8
> [WARNING] Rule 3: org.apache.maven.plugins.enforcer.EnforceBytecodeVersion
> failed with message:
> HBase has unsupported dependencies.
> HBase requires that all dependencies be compiled with version 1.7 or earlier
> of the JDK to properly build from source. You appear to be using a newer
> dependency. You can use
> either "mvn -version" or "mvn enforcer:display-info" to verify what version
> is active.
> Non-release builds can temporarily build with a newer JDK version by
> setting the
> 'compileSource' property (eg. mvn -DcompileSource=1.8 clean package).
> Found Banned Dependency: jdk.tools:jdk.tools:jar:1.8
> Use 'mvn dependency:tree' to locate the source of the banned dependencies.
> [INFO]
>
> {noformat}
> My JDK is 1.8. But I wanted to build to target 1.7. So I didn't' have the
> -DcompileSource=1.8.
> The enforcer checks the jdk tools.jar and causes the error because the system
> JDK is 1.8.
> This is a valid build/release use case as long as we support both 1.8 and 1.7.
> We should exclude jdk tools.jar from the enforcer.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (HBASE-16299) Update REST API scanner with ability to do reverse scan
[ https://issues.apache.org/jira/browse/HBASE-16299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411260#comment-15411260 ] Minwoo Kang edited comment on HBASE-16299 at 8/8/16 4:30 AM: - Hi, I create a patch for branch-1.3. Here is [Review board | https://reviews.apache.org/r/50883/]. was (Author: minwoo.kang): Hi, I create a patch for branch-1.3. Here is [Review board](https://reviews.apache.org/r/50883/). > Update REST API scanner with ability to do reverse scan > --- > > Key: HBASE-16299 > URL: https://issues.apache.org/jira/browse/HBASE-16299 > Project: HBase > Issue Type: Improvement > Components: REST >Affects Versions: 1.1.2 > Environment: Not environment specific (tested on HDP 2.4.2) >Reporter: Bjorn Olsen >Assignee: Minwoo Kang >Priority: Minor > Attachments: HBASE-16299.branch-1.3.001.patch, > HBASE-16299.master.001.patch > > > HBASE-4811 "Support reverse scan" was implemented from version 0.98.0, and is > available in the Java API. > However this functionality is not yet exposed via REST. > Example of expected API call: > http://server:port/table/*?startrow=1&endrow=10&reversed=true"; > (Returns rows ordered by key in reverse, eg from 9*** to 1*** ) > Based on my (limited) understanding this should be simple to add. > See org.apach.hadoop.hbase.rest.TableResource.getScanResource > This function creates a Scan object with parameters passed in from the REST > API (I assume). > Adding this functionality may be as simple as adding a "reversed" parameter > to the REST API which passes down to where the Scan object is created in > TableResource.getScanResource. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16299) Update REST API scanner with ability to do reverse scan
[ https://issues.apache.org/jira/browse/HBASE-16299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411260#comment-15411260 ] Minwoo Kang commented on HBASE-16299: - Hi, I create a patch for branch-1.3. Here is [Review board](https://reviews.apache.org/r/50883/). > Update REST API scanner with ability to do reverse scan > --- > > Key: HBASE-16299 > URL: https://issues.apache.org/jira/browse/HBASE-16299 > Project: HBase > Issue Type: Improvement > Components: REST >Affects Versions: 1.1.2 > Environment: Not environment specific (tested on HDP 2.4.2) >Reporter: Bjorn Olsen >Assignee: Minwoo Kang >Priority: Minor > Attachments: HBASE-16299.branch-1.3.001.patch, > HBASE-16299.master.001.patch > > > HBASE-4811 "Support reverse scan" was implemented from version 0.98.0, and is > available in the Java API. > However this functionality is not yet exposed via REST. > Example of expected API call: > http://server:port/table/*?startrow=1&endrow=10&reversed=true"; > (Returns rows ordered by key in reverse, eg from 9*** to 1*** ) > Based on my (limited) understanding this should be simple to add. > See org.apach.hadoop.hbase.rest.TableResource.getScanResource > This function creates a Scan object with parameters passed in from the REST > API (I assume). > Adding this functionality may be as simple as adding a "reversed" parameter > to the REST API which passes down to where the Scan object is created in > TableResource.getScanResource. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16299) Update REST API scanner with ability to do reverse scan
[ https://issues.apache.org/jira/browse/HBASE-16299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Minwoo Kang updated HBASE-16299: Attachment: HBASE-16299.branch-1.3.001.patch > Update REST API scanner with ability to do reverse scan > --- > > Key: HBASE-16299 > URL: https://issues.apache.org/jira/browse/HBASE-16299 > Project: HBase > Issue Type: Improvement > Components: REST >Affects Versions: 1.1.2 > Environment: Not environment specific (tested on HDP 2.4.2) >Reporter: Bjorn Olsen >Assignee: Minwoo Kang >Priority: Minor > Attachments: HBASE-16299.branch-1.3.001.patch, > HBASE-16299.master.001.patch > > > HBASE-4811 "Support reverse scan" was implemented from version 0.98.0, and is > available in the Java API. > However this functionality is not yet exposed via REST. > Example of expected API call: > http://server:port/table/*?startrow=1&endrow=10&reversed=true"; > (Returns rows ordered by key in reverse, eg from 9*** to 1*** ) > Based on my (limited) understanding this should be simple to add. > See org.apach.hadoop.hbase.rest.TableResource.getScanResource > This function creates a Scan object with parameters passed in from the REST > API (I assume). > Adding this functionality may be as simple as adding a "reversed" parameter > to the REST API which passes down to where the Scan object is created in > TableResource.getScanResource. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (HBASE-16303) FilterList with MUST_PASS_ONE optimization
[ https://issues.apache.org/jira/browse/HBASE-16303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan resolved HBASE-16303. Resolution: Fixed Fix Version/s: 1.4.0 > FilterList with MUST_PASS_ONE optimization > -- > > Key: HBASE-16303 > URL: https://issues.apache.org/jira/browse/HBASE-16303 > Project: HBase > Issue Type: Bug > Components: Filters >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0, 1.4.0 > > Attachments: HBASE-16303.patch, HBASE-16303.patch, > HBASE-16303_1.patch, HBASE-16303_1.patch > > > This JIRA was created to add @Test tag for all the filter related tests. > After doing that one such test failed in > TestFilterList#testFilterListTwoFiltersMustPassOne. > The test assumes that when a PrefixFilter is added to a filterlist once the > given prefix is passed we should SKIP all other rows. But the impl in > FilterList for MUST_PASS_ONE filter is such that once the filter in the list > sees that filterAllRemaining is true we don't use that to decide if to to > SEE_NEXT_USING_HINT or not. This patch tries to handle that case where if for > a filter FilterAllRemaining is true then SEEK_NEXT_USING_HINT need not be > done. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16303) FilterList with MUST_PASS_ONE optimization
[ https://issues.apache.org/jira/browse/HBASE-16303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411247#comment-15411247 ] ramkrishna.s.vasudevan commented on HBASE-16303: I am not marking this JIRA for 1.3.0 because it means we only have @Test tag added to the tests. > FilterList with MUST_PASS_ONE optimization > -- > > Key: HBASE-16303 > URL: https://issues.apache.org/jira/browse/HBASE-16303 > Project: HBase > Issue Type: Bug > Components: Filters >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: HBASE-16303.patch, HBASE-16303.patch, > HBASE-16303_1.patch, HBASE-16303_1.patch > > > This JIRA was created to add @Test tag for all the filter related tests. > After doing that one such test failed in > TestFilterList#testFilterListTwoFiltersMustPassOne. > The test assumes that when a PrefixFilter is added to a filterlist once the > given prefix is passed we should SKIP all other rows. But the impl in > FilterList for MUST_PASS_ONE filter is such that once the filter in the list > sees that filterAllRemaining is true we don't use that to decide if to to > SEE_NEXT_USING_HINT or not. This patch tries to handle that case where if for > a filter FilterAllRemaining is true then SEEK_NEXT_USING_HINT need not be > done. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16303) FilterList with MUST_PASS_ONE optimization
[ https://issues.apache.org/jira/browse/HBASE-16303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411246#comment-15411246 ] ramkrishna.s.vasudevan commented on HBASE-16303: bq.please check compilation before committing. This is the most basic of checks a committer can do. It shouldn't be necessary to ask! Sorry about this. I should not have done that. Will see to that I compile the code before committing. I expected this bug to be in latest branch-1. And hence in branch-1.3 also. My bad. The addendum was not necessary there only the patch would have been enough. Thanks [~busbey] - And sorry for the trouble. > FilterList with MUST_PASS_ONE optimization > -- > > Key: HBASE-16303 > URL: https://issues.apache.org/jira/browse/HBASE-16303 > Project: HBase > Issue Type: Bug > Components: Filters >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: HBASE-16303.patch, HBASE-16303.patch, > HBASE-16303_1.patch, HBASE-16303_1.patch > > > This JIRA was created to add @Test tag for all the filter related tests. > After doing that one such test failed in > TestFilterList#testFilterListTwoFiltersMustPassOne. > The test assumes that when a PrefixFilter is added to a filterlist once the > given prefix is passed we should SKIP all other rows. But the impl in > FilterList for MUST_PASS_ONE filter is such that once the filter in the list > sees that filterAllRemaining is true we don't use that to decide if to to > SEE_NEXT_USING_HINT or not. This patch tries to handle that case where if for > a filter FilterAllRemaining is true then SEEK_NEXT_USING_HINT need not be > done. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16303) FilterList with MUST_PASS_ONE optimization
[ https://issues.apache.org/jira/browse/HBASE-16303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-16303: --- Fix Version/s: (was: 1.3.0) > FilterList with MUST_PASS_ONE optimization > -- > > Key: HBASE-16303 > URL: https://issues.apache.org/jira/browse/HBASE-16303 > Project: HBase > Issue Type: Bug > Components: Filters >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: HBASE-16303.patch, HBASE-16303.patch, > HBASE-16303_1.patch, HBASE-16303_1.patch > > > This JIRA was created to add @Test tag for all the filter related tests. > After doing that one such test failed in > TestFilterList#testFilterListTwoFiltersMustPassOne. > The test assumes that when a PrefixFilter is added to a filterlist once the > given prefix is passed we should SKIP all other rows. But the impl in > FilterList for MUST_PASS_ONE filter is such that once the filter in the list > sees that filterAllRemaining is true we don't use that to decide if to to > SEE_NEXT_USING_HINT or not. This patch tries to handle that case where if for > a filter FilterAllRemaining is true then SEEK_NEXT_USING_HINT need not be > done. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-9899) for idempotent operation dups, return the result instead of throwing conflict exception
[ https://issues.apache.org/jira/browse/HBASE-9899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411214#comment-15411214 ] Guanghao Zhang commented on HBASE-9899: --- I run the ut TestClusterId based branch-1 and it failed too. The build history in https://builds.apache.org/job/HBase-1.4/ shows that TestClusterId always failed. > for idempotent operation dups, return the result instead of throwing conflict > exception > --- > > Key: HBASE-9899 > URL: https://issues.apache.org/jira/browse/HBASE-9899 > Project: HBase > Issue Type: Improvement >Reporter: Sergey Shelukhin >Assignee: Guanghao Zhang > Fix For: 2.0.0 > > Attachments: HBASE-9899-addendum.patch, HBASE-9899-branch-1.patch, > HBASE-9899-branch-1.patch, HBASE-9899-branch-1.patch, HBASE-9899-v1.patch, > HBASE-9899-v2.patch, HBASE-9899-v3.patch, HBASE-9899-v3.patch, > HBASE-9899-v4.patch, HBASE-9899-v4.patch > > > After HBASE-3787, we could store mvcc in operation context, and use it to > convert the modification request into read on dups instead of throwing > OperationConflictException. > MVCC tracking will have to be aware of such MVCC numbers present. Given that > scanners are usually relatively short-lived, that would prevent low watermark > from advancing for quite a bit more time -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12770) Don't transfer all the queued hlogs of a dead server to the same alive server
[ https://issues.apache.org/jira/browse/HBASE-12770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Yang updated HBASE-12770: -- Attachment: HBASE-12770-v3.patch retry > Don't transfer all the queued hlogs of a dead server to the same alive server > - > > Key: HBASE-12770 > URL: https://issues.apache.org/jira/browse/HBASE-12770 > Project: HBase > Issue Type: Improvement > Components: Replication >Reporter: Jianwei Cui >Assignee: Phil Yang >Priority: Minor > Attachments: HBASE-12770-branch-1-v1.patch, > HBASE-12770-branch-1-v2.patch, HBASE-12770-branch-1-v3.patch, > HBASE-12770-branch-1-v3.patch, HBASE-12770-trunk.patch, HBASE-12770-v1.patch, > HBASE-12770-v2.patch, HBASE-12770-v3.patch, HBASE-12770-v3.patch > > > When a region server is down(or the cluster restart), all the hlog queues > will be transferred by the same alive region server. In a shared cluster, we > might create several peers replicating data to different peer clusters. There > might be lots of hlogs queued for these peers caused by several reasons, such > as some peers might be disabled, or errors from peer cluster might prevent > the replication, or the replication sources may fail to read some hlog > because of hdfs problem. Then, if the server is down or restarted, another > alive server will take all the replication jobs of the dead server, this > might bring a big pressure to resources(network/disk read) of the alive > server and also is not fast enough to replicate the queued hlogs. And if the > alive server is down, all the replication jobs including that takes from > other dead servers will once again be totally transferred to another alive > server, this might cause a server have a large number of queued hlogs(in our > shared cluster, we find one server might have thousands of queued hlogs for > replication). As an optional way, is it reasonable that the alive server only > transfer one peer's hlogs from the dead server one time? Then, other alive > region servers might have the opportunity to transfer the hlogs of rest > peers. This may also help the queued hlogs be processed more fast. Any > discussion is welcome. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16308) Contain protobuf references
[
https://issues.apache.org/jira/browse/HBASE-16308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411163#comment-15411163
]
Hadoop QA commented on HBASE-16308:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 11s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 9 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 10s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
19s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 47s
{color} | {color:green} master passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m 16s
{color} | {color:green} master passed with JDK v1.7.0_101 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
28s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
56s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
18s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 4s
{color} | {color:green} master passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 23s
{color} | {color:green} master passed with JDK v1.7.0_101 {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 11s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
32s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 46s
{color} | {color:green} the patch passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 46s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m 16s
{color} | {color:green} the patch passed with JDK v1.7.0_101 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m 16s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
28s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
55s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
27m 26s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green} 0m
52s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m
11s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 21s
{color} | {color:green} the patch passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 24s
{color} | {color:green} the patch passed with JDK v1.7.0_101 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 42s
{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 59s
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 95m 4s {color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 16s
{color} | {color:green} hbase-spark in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 1m
5s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 163m 41s {color}
| {color:black} {color} |
\\
\\
|| Reaso
[jira] [Commented] (HBASE-16347) Unevaluated expressions in book
[
https://issues.apache.org/jira/browse/HBASE-16347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411157#comment-15411157
]
Dima Spivak commented on HBASE-16347:
-
Hey [~ndimiduk]/[~misty], would one of you mind pushing the website so that the
change could take effect? [The
website|http://hbase.apache.org/book.html#quickstart] still shows the pre-fixed
code block.
> Unevaluated expressions in book
> ---
>
> Key: HBASE-16347
> URL: https://issues.apache.org/jira/browse/HBASE-16347
> Project: HBase
> Issue Type: Bug
> Components: documentation, site
>Reporter: Nick Dimiduk
>Assignee: Dima Spivak
> Fix For: 2.0.0
>
> Attachments: HBASE-16347.patch, after-patch.png
>
>
> Have a look at the [quickstart
> guide|http://hbase.apache.org/book.html#quickstart], step two
> {noformat}
> $ tar xzvf hbase--bin.tar.gz
> $ cd hbase-/
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (HBASE-16321) Ensure findbugs jsr305 jar isn't present
[
https://issues.apache.org/jira/browse/HBASE-16321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell resolved HBASE-16321.
Resolution: Fixed
> Ensure findbugs jsr305 jar isn't present
>
>
> Key: HBASE-16321
> URL: https://issues.apache.org/jira/browse/HBASE-16321
> Project: HBase
> Issue Type: Sub-task
> Components: dependencies
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Blocker
> Fix For: 2.0.0, 1.3.0, 1.4.0, 1.1.6, 1.2.3, 0.98.21
>
> Attachments: 16321-amend.txt, HBASE-16131-0.98-addendum-2.patch,
> HBASE-16321.1.patch, HBASE-16321.2.patch
>
>
> we should be using
> {code}
>
>
> com.github.stephenc.findbugs
> findbugs-annotations
> ${findbugs-annotations}
> compile
>
> {code}
> to ensure we don't have a prohibited dependency, but it looks like we're
> still bringing in
> {code}
>
> com.google.code.findbugs
> jsr305
> ${jsr305.version}
>
> {code}
> remove the findbugs version (even though the maven central pom claims the
> license is ALv2, that doesn't line up with the referenced project sites).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-16321) Ensure findbugs jsr305 jar isn't present
[
https://issues.apache.org/jira/browse/HBASE-16321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated HBASE-16321:
---
Attachment: HBASE-16131-0.98-addendum-2.patch
Attaching what I committed to fix the issue with 0.98 builds. Just removed the
offending replacement annotations, only a handful of changes.
> Ensure findbugs jsr305 jar isn't present
>
>
> Key: HBASE-16321
> URL: https://issues.apache.org/jira/browse/HBASE-16321
> Project: HBase
> Issue Type: Sub-task
> Components: dependencies
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Blocker
> Fix For: 2.0.0, 1.3.0, 1.4.0, 1.1.6, 0.98.21, 1.2.3
>
> Attachments: 16321-amend.txt, HBASE-16131-0.98-addendum-2.patch,
> HBASE-16321.1.patch, HBASE-16321.2.patch
>
>
> we should be using
> {code}
>
>
> com.github.stephenc.findbugs
> findbugs-annotations
> ${findbugs-annotations}
> compile
>
> {code}
> to ensure we don't have a prohibited dependency, but it looks like we're
> still bringing in
> {code}
>
> com.google.code.findbugs
> jsr305
> ${jsr305.version}
>
> {code}
> remove the findbugs version (even though the maven central pom claims the
> license is ALv2, that doesn't line up with the referenced project sites).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (HBASE-16321) Ensure findbugs jsr305 jar isn't present
[
https://issues.apache.org/jira/browse/HBASE-16321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411139#comment-15411139
]
Andrew Purtell edited comment on HBASE-16321 at 8/8/16 12:44 AM:
-
It's the {{NonNull}}, {{CheckForNull}}, and {{Nullable}} annotations.
If I remove it from hbase-common when we get to hbase-client we can see the
problem. I was wrong about class file version, but still close:
{noformat}
[ERROR]
edu/umd/cs/findbugs/annotations/Nullable.class(edu/umd/cs/findbugs/annotations:Nullable.class):
warning: Cannot find annotation method 'when()' in type
'javax.annotation.Nonnull': class file for javax.annotation.Nonnull not found
[ERROR] An exception has occurred in the compiler (1.6.0_45). Please file a bug
at the Java Developer Connection (http://java.sun.com/webapps/bugreport) after
checking the Bug Parade for duplicates. Include your program and the following
diagnostic in your report. Thank you.
{noformat}
was (Author: apurtell):
It's the {{NonNull}} and {{Nullable}} annotations.
If I remove it from hbase-common when we get to hbase-client we can see the
problem. I was wrong about class file version, but still close:
{noformat}
[ERROR]
edu/umd/cs/findbugs/annotations/Nullable.class(edu/umd/cs/findbugs/annotations:Nullable.class):
warning: Cannot find annotation method 'when()' in type
'javax.annotation.Nonnull': class file for javax.annotation.Nonnull not found
[ERROR] An exception has occurred in the compiler (1.6.0_45). Please file a bug
at the Java Developer Connection (http://java.sun.com/webapps/bugreport) after
checking the Bug Parade for duplicates. Include your program and the following
diagnostic in your report. Thank you.
{noformat}
> Ensure findbugs jsr305 jar isn't present
>
>
> Key: HBASE-16321
> URL: https://issues.apache.org/jira/browse/HBASE-16321
> Project: HBase
> Issue Type: Sub-task
> Components: dependencies
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Blocker
> Fix For: 2.0.0, 1.3.0, 1.4.0, 1.1.6, 0.98.21, 1.2.3
>
> Attachments: 16321-amend.txt, HBASE-16321.1.patch, HBASE-16321.2.patch
>
>
> we should be using
> {code}
>
>
> com.github.stephenc.findbugs
> findbugs-annotations
> ${findbugs-annotations}
> compile
>
> {code}
> to ensure we don't have a prohibited dependency, but it looks like we're
> still bringing in
> {code}
>
> com.google.code.findbugs
> jsr305
> ${jsr305.version}
>
> {code}
> remove the findbugs version (even though the maven central pom claims the
> license is ALv2, that doesn't line up with the referenced project sites).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (HBASE-16321) Ensure findbugs jsr305 jar isn't present
[
https://issues.apache.org/jira/browse/HBASE-16321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411139#comment-15411139
]
Andrew Purtell edited comment on HBASE-16321 at 8/8/16 12:38 AM:
-
It's the {{NonNull}} and {{Nullable}} annotations.
If I remove it from hbase-common when we get to hbase-client we can see the
problem. I was wrong about class file version, but still close:
{noformat}
[ERROR]
edu/umd/cs/findbugs/annotations/Nullable.class(edu/umd/cs/findbugs/annotations:Nullable.class):
warning: Cannot find annotation method 'when()' in type
'javax.annotation.Nonnull': class file for javax.annotation.Nonnull not found
[ERROR] An exception has occurred in the compiler (1.6.0_45). Please file a bug
at the Java Developer Connection (http://java.sun.com/webapps/bugreport) after
checking the Bug Parade for duplicates. Include your program and the following
diagnostic in your report. Thank you.
{noformat}
was (Author: apurtell):
It's the {{NonNull}} and {{Nullable} annotations.
If I remove it from hbase-common when we get to hbase-client we can see the
problem. I was wrong about class file version, but still close:
{noformat}
[ERROR]
edu/umd/cs/findbugs/annotations/Nullable.class(edu/umd/cs/findbugs/annotations:Nullable.class):
warning: Cannot find annotation method 'when()' in type
'javax.annotation.Nonnull': class file for javax.annotation.Nonnull not found
[ERROR] An exception has occurred in the compiler (1.6.0_45). Please file a bug
at the Java Developer Connection (http://java.sun.com/webapps/bugreport) after
checking the Bug Parade for duplicates. Include your program and the following
diagnostic in your report. Thank you.
{noformat}
> Ensure findbugs jsr305 jar isn't present
>
>
> Key: HBASE-16321
> URL: https://issues.apache.org/jira/browse/HBASE-16321
> Project: HBase
> Issue Type: Sub-task
> Components: dependencies
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Blocker
> Fix For: 2.0.0, 1.3.0, 1.4.0, 1.1.6, 0.98.21, 1.2.3
>
> Attachments: 16321-amend.txt, HBASE-16321.1.patch, HBASE-16321.2.patch
>
>
> we should be using
> {code}
>
>
> com.github.stephenc.findbugs
> findbugs-annotations
> ${findbugs-annotations}
> compile
>
> {code}
> to ensure we don't have a prohibited dependency, but it looks like we're
> still bringing in
> {code}
>
> com.google.code.findbugs
> jsr305
> ${jsr305.version}
>
> {code}
> remove the findbugs version (even though the maven central pom claims the
> license is ALv2, that doesn't line up with the referenced project sites).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16321) Ensure findbugs jsr305 jar isn't present
[
https://issues.apache.org/jira/browse/HBASE-16321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411139#comment-15411139
]
Andrew Purtell commented on HBASE-16321:
It's the {{NonNull}} annotation.
If I remove it from hbase-common when we get to hbase-client we can see the
problem. I was wrong about class file version, but still close:
{noformat}
[ERROR]
edu/umd/cs/findbugs/annotations/Nullable.class(edu/umd/cs/findbugs/annotations:Nullable.class):
warning: Cannot find annotation method 'when()' in type
'javax.annotation.Nonnull': class file for javax.annotation.Nonnull not found
[ERROR] An exception has occurred in the compiler (1.6.0_45). Please file a bug
at the Java Developer Connection (http://java.sun.com/webapps/bugreport) after
checking the Bug Parade for duplicates. Include your program and the following
diagnostic in your report. Thank you.
{noformat}
> Ensure findbugs jsr305 jar isn't present
>
>
> Key: HBASE-16321
> URL: https://issues.apache.org/jira/browse/HBASE-16321
> Project: HBase
> Issue Type: Sub-task
> Components: dependencies
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Blocker
> Fix For: 2.0.0, 1.3.0, 1.4.0, 1.1.6, 0.98.21, 1.2.3
>
> Attachments: 16321-amend.txt, HBASE-16321.1.patch, HBASE-16321.2.patch
>
>
> we should be using
> {code}
>
>
> com.github.stephenc.findbugs
> findbugs-annotations
> ${findbugs-annotations}
> compile
>
> {code}
> to ensure we don't have a prohibited dependency, but it looks like we're
> still bringing in
> {code}
>
> com.google.code.findbugs
> jsr305
> ${jsr305.version}
>
> {code}
> remove the findbugs version (even though the maven central pom claims the
> license is ALv2, that doesn't line up with the referenced project sites).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (HBASE-16321) Ensure findbugs jsr305 jar isn't present
[
https://issues.apache.org/jira/browse/HBASE-16321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411139#comment-15411139
]
Andrew Purtell edited comment on HBASE-16321 at 8/8/16 12:38 AM:
-
It's the {{NonNull}} and {{Nullable} annotations.
If I remove it from hbase-common when we get to hbase-client we can see the
problem. I was wrong about class file version, but still close:
{noformat}
[ERROR]
edu/umd/cs/findbugs/annotations/Nullable.class(edu/umd/cs/findbugs/annotations:Nullable.class):
warning: Cannot find annotation method 'when()' in type
'javax.annotation.Nonnull': class file for javax.annotation.Nonnull not found
[ERROR] An exception has occurred in the compiler (1.6.0_45). Please file a bug
at the Java Developer Connection (http://java.sun.com/webapps/bugreport) after
checking the Bug Parade for duplicates. Include your program and the following
diagnostic in your report. Thank you.
{noformat}
was (Author: apurtell):
It's the {{NonNull}} annotation.
If I remove it from hbase-common when we get to hbase-client we can see the
problem. I was wrong about class file version, but still close:
{noformat}
[ERROR]
edu/umd/cs/findbugs/annotations/Nullable.class(edu/umd/cs/findbugs/annotations:Nullable.class):
warning: Cannot find annotation method 'when()' in type
'javax.annotation.Nonnull': class file for javax.annotation.Nonnull not found
[ERROR] An exception has occurred in the compiler (1.6.0_45). Please file a bug
at the Java Developer Connection (http://java.sun.com/webapps/bugreport) after
checking the Bug Parade for duplicates. Include your program and the following
diagnostic in your report. Thank you.
{noformat}
> Ensure findbugs jsr305 jar isn't present
>
>
> Key: HBASE-16321
> URL: https://issues.apache.org/jira/browse/HBASE-16321
> Project: HBase
> Issue Type: Sub-task
> Components: dependencies
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Blocker
> Fix For: 2.0.0, 1.3.0, 1.4.0, 1.1.6, 0.98.21, 1.2.3
>
> Attachments: 16321-amend.txt, HBASE-16321.1.patch, HBASE-16321.2.patch
>
>
> we should be using
> {code}
>
>
> com.github.stephenc.findbugs
> findbugs-annotations
> ${findbugs-annotations}
> compile
>
> {code}
> to ensure we don't have a prohibited dependency, but it looks like we're
> still bringing in
> {code}
>
> com.google.code.findbugs
> jsr305
> ${jsr305.version}
>
> {code}
> remove the findbugs version (even though the maven central pom claims the
> license is ALv2, that doesn't line up with the referenced project sites).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16321) Ensure findbugs jsr305 jar isn't present
[
https://issues.apache.org/jira/browse/HBASE-16321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411138#comment-15411138
]
Andrew Purtell commented on HBASE-16321:
Ok, I'm going to try to be more surgical than proposed above because the scope
of this commit is smaller. Must be something in there...
> Ensure findbugs jsr305 jar isn't present
>
>
> Key: HBASE-16321
> URL: https://issues.apache.org/jira/browse/HBASE-16321
> Project: HBase
> Issue Type: Sub-task
> Components: dependencies
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Blocker
> Fix For: 2.0.0, 1.3.0, 1.4.0, 1.1.6, 0.98.21, 1.2.3
>
> Attachments: 16321-amend.txt, HBASE-16321.1.patch, HBASE-16321.2.patch
>
>
> we should be using
> {code}
>
>
> com.github.stephenc.findbugs
> findbugs-annotations
> ${findbugs-annotations}
> compile
>
> {code}
> to ensure we don't have a prohibited dependency, but it looks like we're
> still bringing in
> {code}
>
> com.google.code.findbugs
> jsr305
> ${jsr305.version}
>
> {code}
> remove the findbugs version (even though the maven central pom claims the
> license is ALv2, that doesn't line up with the referenced project sites).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (HBASE-16321) Ensure findbugs jsr305 jar isn't present
[
https://issues.apache.org/jira/browse/HBASE-16321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411123#comment-15411123
]
Andrew Purtell edited comment on HBASE-16321 at 8/8/16 12:22 AM:
-
I need to partially revert and amend this change.
With 0.98, where we require Java 6 to build, this change causes the build to
inexplicably fail in compilation of hbase-common. Although the failure is
silent, it is because the class file versions of the replacement jsr305
annotations are too recent.
What I am going to do to fix this in 0.98 is keep the enforcement ban and
exclusions in place, but remove all instances of findbugs annotations. And not
specify the replacement jsr305 dependency either.
was (Author: apurtell):
I need to partially revert and amend this change.
With 0.98, where we require Java 6 to build, this change causes the build to
inexplicably fail in compilation of hbase-common. Although the failure is
silent, it is because the class file versions of the replacement jsr305 classes
are too recent.
What I am going to do to fix this in 0.98 is keep the enforcement ban and
exclusions in place, but remove all instances of findbugs annotations. And not
specify the replacement jsr305 dependency either.
> Ensure findbugs jsr305 jar isn't present
>
>
> Key: HBASE-16321
> URL: https://issues.apache.org/jira/browse/HBASE-16321
> Project: HBase
> Issue Type: Sub-task
> Components: dependencies
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Blocker
> Fix For: 2.0.0, 1.3.0, 1.4.0, 1.1.6, 0.98.21, 1.2.3
>
> Attachments: 16321-amend.txt, HBASE-16321.1.patch, HBASE-16321.2.patch
>
>
> we should be using
> {code}
>
>
> com.github.stephenc.findbugs
> findbugs-annotations
> ${findbugs-annotations}
> compile
>
> {code}
> to ensure we don't have a prohibited dependency, but it looks like we're
> still bringing in
> {code}
>
> com.google.code.findbugs
> jsr305
> ${jsr305.version}
>
> {code}
> remove the findbugs version (even though the maven central pom claims the
> license is ALv2, that doesn't line up with the referenced project sites).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (HBASE-16321) Ensure findbugs jsr305 jar isn't present
[
https://issues.apache.org/jira/browse/HBASE-16321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411123#comment-15411123
]
Andrew Purtell edited comment on HBASE-16321 at 8/8/16 12:04 AM:
-
I need to partially revert and amend this change.
With 0.98, where we require Java 6 to build, this change causes the build to
inexplicably fail in compilation of hbase-common. Although the failure is
silent, it is because the class file versions of the replacement jsr305 classes
are too recent.
What I am going to do to fix this in 0.98 is keep the enforcement ban and
exclusions in place, but remove all instances of findbugs annotations. And not
specify the replacement jsr305 dependency either.
was (Author: apurtell):
I need to partially revert and amend this change.
With 0.98, where we require Java 6 to build, this change causes the build to
inexplicably fail in compilation of hbase-common. Although the failure is
silent, it is because the class file versions of the replacement jsr305 classes
are too recent.
What I am going to do to fix this in 0.98 is keep the enforcement ban and
exclusions in place, but remove all instances of findbugs annotations.
> Ensure findbugs jsr305 jar isn't present
>
>
> Key: HBASE-16321
> URL: https://issues.apache.org/jira/browse/HBASE-16321
> Project: HBase
> Issue Type: Sub-task
> Components: dependencies
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Blocker
> Fix For: 2.0.0, 1.3.0, 1.4.0, 1.1.6, 0.98.21, 1.2.3
>
> Attachments: 16321-amend.txt, HBASE-16321.1.patch, HBASE-16321.2.patch
>
>
> we should be using
> {code}
>
>
> com.github.stephenc.findbugs
> findbugs-annotations
> ${findbugs-annotations}
> compile
>
> {code}
> to ensure we don't have a prohibited dependency, but it looks like we're
> still bringing in
> {code}
>
> com.google.code.findbugs
> jsr305
> ${jsr305.version}
>
> {code}
> remove the findbugs version (even though the maven central pom claims the
> license is ALv2, that doesn't line up with the referenced project sites).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (HBASE-16321) Ensure findbugs jsr305 jar isn't present
[
https://issues.apache.org/jira/browse/HBASE-16321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell reopened HBASE-16321:
I need to partially revert and amend this change.
With 0.98, where we require Java 6 to build, this change causes the build to
inexplicably fail in compilation of hbase-common. Although the failure is
silent, it is because the class file versions of the replacement jsr305 classes
are too recent.
What I am going to do to fix this in 0.98 is keep the enforcement ban and
exclusions in place, but remove all instances of findbugs annotations.
> Ensure findbugs jsr305 jar isn't present
>
>
> Key: HBASE-16321
> URL: https://issues.apache.org/jira/browse/HBASE-16321
> Project: HBase
> Issue Type: Sub-task
> Components: dependencies
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Blocker
> Fix For: 2.0.0, 1.3.0, 1.4.0, 1.1.6, 0.98.21, 1.2.3
>
> Attachments: 16321-amend.txt, HBASE-16321.1.patch, HBASE-16321.2.patch
>
>
> we should be using
> {code}
>
>
> com.github.stephenc.findbugs
> findbugs-annotations
> ${findbugs-annotations}
> compile
>
> {code}
> to ensure we don't have a prohibited dependency, but it looks like we're
> still bringing in
> {code}
>
> com.google.code.findbugs
> jsr305
> ${jsr305.version}
>
> {code}
> remove the findbugs version (even though the maven central pom claims the
> license is ALv2, that doesn't line up with the referenced project sites).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-16308) Contain protobuf references
[ https://issues.apache.org/jira/browse/HBASE-16308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-16308: -- Status: Patch Available (was: Reopened) > Contain protobuf references > --- > > Key: HBASE-16308 > URL: https://issues.apache.org/jira/browse/HBASE-16308 > Project: HBase > Issue Type: Sub-task > Components: Protobufs >Reporter: stack >Assignee: stack > Fix For: 2.0.0 > > Attachments: HBASE-16308.master.001.patch, > HBASE-16308.master.002.patch, HBASE-16308.master.003.patch, > HBASE-16308.master.004.patch, HBASE-16308.master.005.patch, > HBASE-16308.master.006.patch, HBASE-16308.master.006.patch, > HBASE-16308.master.007.patch > > > Clean up our protobuf references so contained to just a few classes rather > than being spread about the codebase. Doing this work will make it easier > landing the parent issue and will make it more clear where the division > between shaded protobuf and unshaded protobuf lies (we need to continue with > unshaded protobuf for HDFS references by AsyncWAL and probably EndPoint > Coprocessors) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16308) Contain protobuf references
[ https://issues.apache.org/jira/browse/HBASE-16308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411107#comment-15411107 ] stack commented on HBASE-16308: --- New patch fixes the increment nonce issue. The test is new. It came in with the HBASE_9899 commit. Came at about same time that this patch was going in so it did not show during qa builds. The test found a legit issue w/ my refactoring of nonce around increment. We need the [~zghaobac] fixup done below for append and increment done for all checkAnd* operations... its a nice one: commit 975f0dd958debcdd842a95f8e9f7458689414fbf Author: stack Date: Thu Aug 4 12:40:19 2016 -0700 HBASE-9899 for idempotent operation dups, return the result instead of throwing conflict exception (Guanghao Zhang) Lets see how the new patch does. > Contain protobuf references > --- > > Key: HBASE-16308 > URL: https://issues.apache.org/jira/browse/HBASE-16308 > Project: HBase > Issue Type: Sub-task > Components: Protobufs >Reporter: stack >Assignee: stack > Fix For: 2.0.0 > > Attachments: HBASE-16308.master.001.patch, > HBASE-16308.master.002.patch, HBASE-16308.master.003.patch, > HBASE-16308.master.004.patch, HBASE-16308.master.005.patch, > HBASE-16308.master.006.patch, HBASE-16308.master.006.patch, > HBASE-16308.master.007.patch > > > Clean up our protobuf references so contained to just a few classes rather > than being spread about the codebase. Doing this work will make it easier > landing the parent issue and will make it more clear where the division > between shaded protobuf and unshaded protobuf lies (we need to continue with > unshaded protobuf for HDFS references by AsyncWAL and probably EndPoint > Coprocessors) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16308) Contain protobuf references
[ https://issues.apache.org/jira/browse/HBASE-16308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-16308: -- Attachment: HBASE-16308.master.007.patch > Contain protobuf references > --- > > Key: HBASE-16308 > URL: https://issues.apache.org/jira/browse/HBASE-16308 > Project: HBase > Issue Type: Sub-task > Components: Protobufs >Reporter: stack >Assignee: stack > Fix For: 2.0.0 > > Attachments: HBASE-16308.master.001.patch, > HBASE-16308.master.002.patch, HBASE-16308.master.003.patch, > HBASE-16308.master.004.patch, HBASE-16308.master.005.patch, > HBASE-16308.master.006.patch, HBASE-16308.master.006.patch, > HBASE-16308.master.007.patch > > > Clean up our protobuf references so contained to just a few classes rather > than being spread about the codebase. Doing this work will make it easier > landing the parent issue and will make it more clear where the division > between shaded protobuf and unshaded protobuf lies (we need to continue with > unshaded protobuf for HDFS references by AsyncWAL and probably EndPoint > Coprocessors) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14345) Consolidate printUsage in IntegrationTestLoadAndVerify
[
https://issues.apache.org/jira/browse/HBASE-14345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411091#comment-15411091
]
Hadoop QA commented on HBASE-14345:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 15m 19s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 4 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 16m
58s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 14s
{color} | {color:green} master passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 16s
{color} | {color:green} master passed with JDK v1.7.0_101 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
44s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
9s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m 0s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 24s
{color} | {color:green} master passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 9s
{color} | {color:green} master passed with JDK v1.7.0_101 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
16s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 12s
{color} | {color:green} the patch passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 12s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 16s
{color} | {color:green} the patch passed with JDK v1.7.0_101 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 16s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
10s {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}
26m 50s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green} 0m
12s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m 0s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 6s
{color} | {color:green} the patch passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 8s
{color} | {color:green} the patch passed with JDK v1.7.0_101 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 16s
{color} | {color:green} hbase-it in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
13s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 64m 23s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.11.2 Server=1.11.2 Image:yetus/hbase:date2016-08-07 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12822464/HBASE-14345.master.002.patch
|
| JIRA Issue | HBASE-14345 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux e88b5c1f4bee 3.13.0-92-generic #139-Ubuntu SMP Tue Jun 28
20:42:26 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / 30d7eea |
| Default Java | 1.7.0_101 |
| Multi-JDK versions | /usr/lib/jvm/ja
[jira] [Created] (HBASE-16371) when excluding tests in precommit, provide a link in the report summary to the list of excluded tests
Sean Busbey created HBASE-16371: --- Summary: when excluding tests in precommit, provide a link in the report summary to the list of excluded tests Key: HBASE-16371 URL: https://issues.apache.org/jira/browse/HBASE-16371 Project: HBase Issue Type: Improvement Components: build Reporter: Sean Busbey now that we're excluding some tests from precommit runs, we should be sure to include a way to find out what tests were excluded from a given test run in the report that gets posted to JIRA. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16370) Exclude jdk tools.jar from Bytecode Version enforcer
[
https://issues.apache.org/jira/browse/HBASE-16370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411085#comment-15411085
]
Sean Busbey commented on HBASE-16370:
-
where does this failure happen? the jdk tools jar shouldn't be in our
dependency list, since we can't ship it under the terms of the jdk.
> Exclude jdk tools.jar from Bytecode Version enforcer
>
>
> Key: HBASE-16370
> URL: https://issues.apache.org/jira/browse/HBASE-16370
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 1.2.2
>Reporter: Jerry He
>Assignee: Jerry He
>Priority: Minor
> Fix For: 2.0.0, 1.3.0, 1.4.0, 1.2.3
>
> Attachments: HBASE-16370.patch
>
>
> Getting this message trying to do a build with -Prelease:
> {noformat}
> [INFO] Restricted to JDK 1.7 yet jdk.tools:jdk.tools:jar:1.8:system contains
> org/relaxng/datatype/DatatypeLibrary.class targeted to JDK 1.8
> [WARNING] Rule 3: org.apache.maven.plugins.enforcer.EnforceBytecodeVersion
> failed with message:
> HBase has unsupported dependencies.
> HBase requires that all dependencies be compiled with version 1.7 or earlier
> of the JDK to properly build from source. You appear to be using a newer
> dependency. You can use
> either "mvn -version" or "mvn enforcer:display-info" to verify what version
> is active.
> Non-release builds can temporarily build with a newer JDK version by
> setting the
> 'compileSource' property (eg. mvn -DcompileSource=1.8 clean package).
> Found Banned Dependency: jdk.tools:jdk.tools:jar:1.8
> Use 'mvn dependency:tree' to locate the source of the banned dependencies.
> [INFO]
>
> {noformat}
> My JDK is 1.8. But I wanted to build to target 1.7. So I didn't' have the
> -DcompileSource=1.8.
> The enforcer checks the jdk tools.jar and causes the error because the system
> JDK is 1.8.
> This is a valid build/release use case as long as we support both 1.8 and 1.7.
> We should exclude jdk tools.jar from the enforcer.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16370) Exclude jdk tools.jar from Bytecode Version enforcer
[
https://issues.apache.org/jira/browse/HBASE-16370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411082#comment-15411082
]
Sean Busbey commented on HBASE-16370:
-
please don't merge this change, it's part of how we make sure we ship the
correct jdk support for releases. building using jdk8 with a target of jdk7
only creates jdk7 compatible bytecode, it doesn't ensure we only use correct
APIs.
> Exclude jdk tools.jar from Bytecode Version enforcer
>
>
> Key: HBASE-16370
> URL: https://issues.apache.org/jira/browse/HBASE-16370
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 1.2.2
>Reporter: Jerry He
>Assignee: Jerry He
>Priority: Minor
> Fix For: 2.0.0, 1.3.0, 1.4.0, 1.2.3
>
> Attachments: HBASE-16370.patch
>
>
> Getting this message trying to do a build with -Prelease:
> {noformat}
> [INFO] Restricted to JDK 1.7 yet jdk.tools:jdk.tools:jar:1.8:system contains
> org/relaxng/datatype/DatatypeLibrary.class targeted to JDK 1.8
> [WARNING] Rule 3: org.apache.maven.plugins.enforcer.EnforceBytecodeVersion
> failed with message:
> HBase has unsupported dependencies.
> HBase requires that all dependencies be compiled with version 1.7 or earlier
> of the JDK to properly build from source. You appear to be using a newer
> dependency. You can use
> either "mvn -version" or "mvn enforcer:display-info" to verify what version
> is active.
> Non-release builds can temporarily build with a newer JDK version by
> setting the
> 'compileSource' property (eg. mvn -DcompileSource=1.8 clean package).
> Found Banned Dependency: jdk.tools:jdk.tools:jar:1.8
> Use 'mvn dependency:tree' to locate the source of the banned dependencies.
> [INFO]
>
> {noformat}
> My JDK is 1.8. But I wanted to build to target 1.7. So I didn't' have the
> -DcompileSource=1.8.
> The enforcer checks the jdk tools.jar and causes the error because the system
> JDK is 1.8.
> This is a valid build/release use case as long as we support both 1.8 and 1.7.
> We should exclude jdk tools.jar from the enforcer.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14932) bulkload fails because file not found
[
https://issues.apache.org/jira/browse/HBASE-14932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411081#comment-15411081
]
Hadoop QA commented on HBASE-14932:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s
{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 12m
43s {color} | {color:green} 0.98 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 32s
{color} | {color:green} 0.98 passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 31s
{color} | {color:green} 0.98 passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
42s {color} | {color:green} 0.98 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
34s {color} | {color:green} 0.98 passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 1m 41s
{color} | {color:red} hbase-server in 0.98 has 85 extant Findbugs warnings.
{color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 0m 31s
{color} | {color:red} hbase-server in 0.98 failed with JDK v1.8.0. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 28s
{color} | {color:green} 0.98 passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
36s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 33s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 33s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 31s
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 31s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
16s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
16s {color} | {color:green} the patch passed {color} |
| {color: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. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 7m 7s
{color} | {color:red} The patch causes 11 errors with Hadoop v2.6.1. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 8m 14s
{color} | {color:red} The patch causes 11 errors with Hadoop v2.6.2. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 9m 21s
{color} | {color:red} The patch causes 11 errors with Hadoop v2.6.3. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 10m 29s
{color} | {color:red} The patch causes 11 errors with Hadoop v2.7.1. {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green} 0m
24s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
58s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 0m 26s
{color} | {color:red} hbase-server in the patch failed with JDK v1.8.0. {color}
|
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 30s
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 121m 10s
{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
31s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 157m 48s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.TestZooKeeper |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12789142/HBASE-14932-0.98.patch
|
| JIRA Issue | HBASE-14932 |
| Optional Tests | asf
[jira] [Commented] (HBASE-15454) Archive store files older than max age
[
https://issues.apache.org/jira/browse/HBASE-15454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411079#comment-15411079
]
Hadoop QA commented on HBASE-15454:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 6 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 15m
23s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 41s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 35s
{color} | {color:green} master passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
28s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
36s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
58s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 51s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 32s
{color} | {color:green} master passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
46s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 40s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 40s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 36s
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 36s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
54s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
21s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
30m 36s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green} 0m
17s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
11s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 26s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 32s
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 91m 22s
{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
38s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 151m 49s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12800944/HBASE-15454-v7.patch |
| JIRA Issue | HBASE-15454 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux asf900.gq1.ygridcore.net 3.13.0-92-generic #139-Ubuntu SMP Tue
Jun 28 20:42:26 UTC 2016 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 / 30d7eea |
| Default Java | 1.7.0_80 |
| Multi-JDK versions | /usr/local/jenkins/java/jdk1.8.0:1.8.0
/usr/local/asfpackages/java/jdk1.7.0_80:1.7.0_80 |
| findbugs | v3.0.0 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/2987/testReport/ |
| modules | C: hbase-se
[jira] [Commented] (HBASE-15866) Split hbase.rpc.timeout into *.read.timeout and *.write.timeout
[
https://issues.apache.org/jira/browse/HBASE-15866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411060#comment-15411060
]
Hadoop QA commented on HBASE-15866:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s
{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 5s {color}
| {color:red} HBASE-15866 does not apply to branch-1. Rebase required? Wrong
Branch? See https://yetus.apache.org/documentation/0.3.0/precommit-patchnames
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12822440/HBASE-15866-branch-1.patch
|
| JIRA Issue | HBASE-15866 |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/2990/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> Split hbase.rpc.timeout into *.read.timeout and *.write.timeout
> ---
>
> Key: HBASE-15866
> URL: https://issues.apache.org/jira/browse/HBASE-15866
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: Andrew Purtell
>Assignee: Vivek Koppuru
> Labels: newbie, patch
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-15866-branch-1.patch, HBASE-15866.patch,
> HBASE-15866.patch, HBASE-15866.patch, HBASE-15866.patch, HBASE-15866.patch,
> read-write-rpc-timeouts.patch, read-write-rpc.v1.patch
>
>
> We have a single tunable for the RPC timeout interval - hbase.rpc.timeout.
> This is fine for the general case but there are use cases where it would be
> advantageous to set two separate timeouts for reads (gets, scans, perhaps
> with significant server side filtering - although the new scanner heartbeat
> feature mitigates where available) and mutations (fail fast under tight SLA,
> resubmit or take mitigating action).
> I propose we refer to a configuration setting "hbase.rpc.read.timeout" when
> handling read operations and "hbase.rpc.write.timeout" when handling write
> operations. If those values are not set in the configuration, fall back to
> the value of "hbase.rpc.timeout" or its default.
> So for example in HTable instead of one global timeout for each RPC
> (rpcTimeout), there would be a readRpcTimeout and writeRpcTimeout also set up
> in HTable#finishSetup. Then wherever we set up RPC with
> RpcRetryingCallerFactory#newCaller(int rpcTimeout) we pass in the read or
> write timeout depending on what the op is.
> In general I don't like the idea of adding configuration parameters to our
> already heavyweight set, but I think the inability to control timeouts
> separately for reads and writes is an operational deficit.
> See also PHOENIX-2916.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-16370) Exclude jdk tools.jar from Bytecode Version enforcer
[
https://issues.apache.org/jira/browse/HBASE-16370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jerry He updated HBASE-16370:
-
Status: Patch Available (was: Open)
> Exclude jdk tools.jar from Bytecode Version enforcer
>
>
> Key: HBASE-16370
> URL: https://issues.apache.org/jira/browse/HBASE-16370
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 1.2.2
>Reporter: Jerry He
>Assignee: Jerry He
>Priority: Minor
> Fix For: 2.0.0, 1.3.0, 1.4.0, 1.2.3
>
> Attachments: HBASE-16370.patch
>
>
> Getting this message trying to do a build with -Prelease:
> {noformat}
> [INFO] Restricted to JDK 1.7 yet jdk.tools:jdk.tools:jar:1.8:system contains
> org/relaxng/datatype/DatatypeLibrary.class targeted to JDK 1.8
> [WARNING] Rule 3: org.apache.maven.plugins.enforcer.EnforceBytecodeVersion
> failed with message:
> HBase has unsupported dependencies.
> HBase requires that all dependencies be compiled with version 1.7 or earlier
> of the JDK to properly build from source. You appear to be using a newer
> dependency. You can use
> either "mvn -version" or "mvn enforcer:display-info" to verify what version
> is active.
> Non-release builds can temporarily build with a newer JDK version by
> setting the
> 'compileSource' property (eg. mvn -DcompileSource=1.8 clean package).
> Found Banned Dependency: jdk.tools:jdk.tools:jar:1.8
> Use 'mvn dependency:tree' to locate the source of the banned dependencies.
> [INFO]
>
> {noformat}
> My JDK is 1.8. But I wanted to build to target 1.7. So I didn't' have the
> -DcompileSource=1.8.
> The enforcer checks the jdk tools.jar and causes the error because the system
> JDK is 1.8.
> This is a valid build/release use case as long as we support both 1.8 and 1.7.
> We should exclude jdk tools.jar from the enforcer.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-16370) Exclude jdk tools.jar from Bytecode Version enforcer
[
https://issues.apache.org/jira/browse/HBASE-16370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jerry He updated HBASE-16370:
-
Attachment: HBASE-16370.patch
> Exclude jdk tools.jar from Bytecode Version enforcer
>
>
> Key: HBASE-16370
> URL: https://issues.apache.org/jira/browse/HBASE-16370
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 1.2.2
>Reporter: Jerry He
>Assignee: Jerry He
>Priority: Minor
> Fix For: 2.0.0, 1.3.0, 1.4.0, 1.2.3
>
> Attachments: HBASE-16370.patch
>
>
> Getting this message trying to do a build with -Prelease:
> {noformat}
> [INFO] Restricted to JDK 1.7 yet jdk.tools:jdk.tools:jar:1.8:system contains
> org/relaxng/datatype/DatatypeLibrary.class targeted to JDK 1.8
> [WARNING] Rule 3: org.apache.maven.plugins.enforcer.EnforceBytecodeVersion
> failed with message:
> HBase has unsupported dependencies.
> HBase requires that all dependencies be compiled with version 1.7 or earlier
> of the JDK to properly build from source. You appear to be using a newer
> dependency. You can use
> either "mvn -version" or "mvn enforcer:display-info" to verify what version
> is active.
> Non-release builds can temporarily build with a newer JDK version by
> setting the
> 'compileSource' property (eg. mvn -DcompileSource=1.8 clean package).
> Found Banned Dependency: jdk.tools:jdk.tools:jar:1.8
> Use 'mvn dependency:tree' to locate the source of the banned dependencies.
> [INFO]
>
> {noformat}
> My JDK is 1.8. But I wanted to build to target 1.7. So I didn't' have the
> -DcompileSource=1.8.
> The enforcer checks the jdk tools.jar and causes the error because the system
> JDK is 1.8.
> This is a valid build/release use case as long as we support both 1.8 and 1.7.
> We should exclude jdk tools.jar from the enforcer.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (HBASE-16370) Exclude jdk tools.jar from Bytecode Version enforcer
Jerry He created HBASE-16370:
Summary: Exclude jdk tools.jar from Bytecode Version enforcer
Key: HBASE-16370
URL: https://issues.apache.org/jira/browse/HBASE-16370
Project: HBase
Issue Type: Improvement
Affects Versions: 1.2.2
Reporter: Jerry He
Assignee: Jerry He
Priority: Minor
Fix For: 2.0.0, 1.3.0, 1.4.0, 1.2.3
Getting this message trying to do a build with -Prelease:
{noformat}
[INFO] Restricted to JDK 1.7 yet jdk.tools:jdk.tools:jar:1.8:system contains
org/relaxng/datatype/DatatypeLibrary.class targeted to JDK 1.8
[WARNING] Rule 3: org.apache.maven.plugins.enforcer.EnforceBytecodeVersion
failed with message:
HBase has unsupported dependencies.
HBase requires that all dependencies be compiled with version 1.7 or earlier
of the JDK to properly build from source. You appear to be using a newer
dependency. You can use
either "mvn -version" or "mvn enforcer:display-info" to verify what version
is active.
Non-release builds can temporarily build with a newer JDK version by setting
the
'compileSource' property (eg. mvn -DcompileSource=1.8 clean package).
Found Banned Dependency: jdk.tools:jdk.tools:jar:1.8
Use 'mvn dependency:tree' to locate the source of the banned dependencies.
[INFO]
{noformat}
My JDK is 1.8. But I wanted to build to target 1.7. So I didn't' have the
-DcompileSource=1.8.
The enforcer checks the jdk tools.jar and causes the error because the system
JDK is 1.8.
This is a valid build/release use case as long as we support both 1.8 and 1.7.
We should exclude jdk tools.jar from the enforcer.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16303) FilterList with MUST_PASS_ONE optimization
[ https://issues.apache.org/jira/browse/HBASE-16303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411034#comment-15411034 ] Andrew Purtell commented on HBASE-16303: [~ramkrishna.s.vasude...@gmail.com], please check *compilation* before committing. This is the most basic of checks a committer can do. It shouldn't be necessary to ask! > FilterList with MUST_PASS_ONE optimization > -- > > Key: HBASE-16303 > URL: https://issues.apache.org/jira/browse/HBASE-16303 > Project: HBase > Issue Type: Bug > Components: Filters >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-16303.patch, HBASE-16303.patch, > HBASE-16303_1.patch, HBASE-16303_1.patch > > > This JIRA was created to add @Test tag for all the filter related tests. > After doing that one such test failed in > TestFilterList#testFilterListTwoFiltersMustPassOne. > The test assumes that when a PrefixFilter is added to a filterlist once the > given prefix is passed we should SKIP all other rows. But the impl in > FilterList for MUST_PASS_ONE filter is such that once the filter in the list > sees that filterAllRemaining is true we don't use that to decide if to to > SEE_NEXT_USING_HINT or not. This patch tries to handle that case where if for > a filter FilterAllRemaining is true then SEEK_NEXT_USING_HINT need not be > done. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14276) NPE when setting up stub for connection to master if secure connect is refused
[
https://issues.apache.org/jira/browse/HBASE-14276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated HBASE-14276:
---
Fix Version/s: (was: 0.98.21)
0.98.22
> NPE when setting up stub for connection to master if secure connect is refused
> --
>
> Key: HBASE-14276
> URL: https://issues.apache.org/jira/browse/HBASE-14276
> Project: HBase
> Issue Type: Bug
>Reporter: Andrew Purtell
>Priority: Minor
> Fix For: 0.98.22
>
>
> If an insecure client contacts a secure cluster we can get an NPE when
> setting up the stub for the master connection. We should throw an IOException
> with a clear message, and not retry if possible to distinguish this case.
> Found in 0.98 but might be relevant for later branches
> {noformat}
> Aug 20, 2015 12:04:31 AM
> org.apache.hadoop.hbase.zookeeper.RecoverableZooKeeper
> INFO: Process identifier=hconnection-0x3c1e23ff connecting to ZooKeeper
> ensemble=x.x.x.x:2181,x.x.x.x:2181,x.x.x.x:2181
> Aug 20, 2015 12:04:31 AM
> org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation
> makeStub
> INFO: getMaster attempt 1 of 35 failed; retrying after sleep of 100,
> exception=com.google.protobuf.ServiceException: java.lang.NullPointerException
> Aug 20, 2015 12:04:31 AM
> org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation
> makeStub
> INFO: getMaster attempt 2 of 35 failed; retrying after sleep of 200,
> exception=com.google.protobuf.ServiceException: java.io.IOException: Call to
> /x.x.x.x:6 failed on local exception: java.io.EOFException
> Aug 20, 2015 12:04:31 AM
> org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation
> makeStub
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-14049) SnapshotHFileCleaner should optionally clean up after failed snapshots
[ https://issues.apache.org/jira/browse/HBASE-14049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-14049: --- Fix Version/s: (was: 0.98.21) 0.98.22 > SnapshotHFileCleaner should optionally clean up after failed snapshots > -- > > Key: HBASE-14049 > URL: https://issues.apache.org/jira/browse/HBASE-14049 > Project: HBase > Issue Type: Bug >Affects Versions: 0.98.13 >Reporter: Andrew Purtell > Fix For: 2.0.0, 1.4.0, 0.98.22 > > > SnapshotHFileCleaner should optionally clean up after failed snapshots rather > than just complain. Add a configuration option that, if set to true > (defaulting to false), instructs SnapshotHFileCleaner to recursively remove > failed snapshot temporary directories. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15982) Interface ReplicationEndpoint extends Guava's Service
[
https://issues.apache.org/jira/browse/HBASE-15982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated HBASE-15982:
---
Fix Version/s: (was: 0.98.21)
0.98.22
> Interface ReplicationEndpoint extends Guava's Service
> -
>
> Key: HBASE-15982
> URL: https://issues.apache.org/jira/browse/HBASE-15982
> Project: HBase
> Issue Type: Bug
>Reporter: Andrew Purtell
> Fix For: 2.0.0, 1.4.0, 0.98.22
>
>
> We have Guava's Service leaking into the LimitedPrivate interface
> ReplicationEndpoint:
> {code}
> public interface ReplicationEndpoint extends Service,
> ReplicationPeerConfigListener
> {code}
> This required a private patch when I updated Guava for our internal
> deployments. This is going to be a problem for us for long term maintenance
> and implenters of pluggable replication endpoints. LP is only less than
> public by a degree. We shouldn't leak types from third part code into either
> Public or LP APIs in my opinion. Let's fix.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15454) Archive store files older than max age
[ https://issues.apache.org/jira/browse/HBASE-15454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-15454: --- Fix Version/s: (was: 0.98.21) 0.98.22 > Archive store files older than max age > -- > > Key: HBASE-15454 > URL: https://issues.apache.org/jira/browse/HBASE-15454 > Project: HBase > Issue Type: Sub-task > Components: Compaction >Affects Versions: 2.0.0, 1.3.0, 0.98.18, 1.4.0 >Reporter: Duo Zhang >Assignee: Duo Zhang > Fix For: 2.0.0, 1.4.0, 0.98.22 > > Attachments: HBASE-15454-v1.patch, HBASE-15454-v2.patch, > HBASE-15454-v3.patch, HBASE-15454-v4.patch, HBASE-15454-v5.patch, > HBASE-15454-v6.patch, HBASE-15454-v7.patch, HBASE-15454.patch > > > In date tiered compaction, the store files older than max age are never > touched by minor compactions. Here we introduce a 'freeze window' operation, > which does the follow things: > 1. Find all store files that contains cells whose timestamp are in the give > window. > 2. Compaction all these files and output one file for each window that these > files covered. > After the compaction, we will have only one in the give window, and all cells > whose timestamp are in the give window are in the only file. And if you do > not write new cells with an older timestamp in this window, the file will > never be changed. This makes it easier to do erasure coding on the freezed > file to reduce redundence. And also, it makes it possible to check > consistency between master and peer cluster incrementally. > And why use the word 'freeze'? > Because there is already an 'HFileArchiver' class. I want to use a different > word to prevent confusing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14927) Backport HBASE-13014 and HBASE-14749 to branch-1 and 0.98
[ https://issues.apache.org/jira/browse/HBASE-14927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-14927: --- Fix Version/s: (was: 0.98.21) 0.98.22 > Backport HBASE-13014 and HBASE-14749 to branch-1 and 0.98 > - > > Key: HBASE-14927 > URL: https://issues.apache.org/jira/browse/HBASE-14927 > Project: HBase > Issue Type: Improvement >Reporter: Abhishek Singh Chouhan >Assignee: Abhishek Singh Chouhan > Fix For: 1.4.0, 0.98.22 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15983) Replication improperly discards data from end-of-wal in some cases.
[ https://issues.apache.org/jira/browse/HBASE-15983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-15983: --- Fix Version/s: (was: 0.98.21) 0.98.22 > Replication improperly discards data from end-of-wal in some cases. > --- > > Key: HBASE-15983 > URL: https://issues.apache.org/jira/browse/HBASE-15983 > Project: HBase > Issue Type: Bug > Components: Replication >Affects Versions: 0.98.0, 1.0.0, 1.1.0, 1.2.0 >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Critical > Fix For: 2.0.0, 1.0.4, 1.4.0, 1.3.1, 1.2.3, 0.98.22, 1.1.7 > > > In some particular deployments, the Replication code believes it has > reached EOF for a WAL prior to successfully parsing all bytes known to > exist in a cleanly closed file. > The underlying issue is that several different underlying problems with a WAL > reader are all treated as end-of-file by the code in ReplicationSource that > decides if a given WAL is completed or needs to be retried. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14932) bulkload fails because file not found
[ https://issues.apache.org/jira/browse/HBASE-14932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-14932: --- Fix Version/s: (was: 0.98.21) 0.98.22 > bulkload fails because file not found > - > > Key: HBASE-14932 > URL: https://issues.apache.org/jira/browse/HBASE-14932 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 0.98.10 >Reporter: Shuaifeng Zhou > Fix For: 0.98.22 > > Attachments: HBASE-14932-0.98.patch > > > When make a dobulkload call, one call may contain sevel hfiles to load, but > the call may timeout during regionserver load files, and client will retry to > load. > But when client doing retry call, regionserver may continue doing load > operation, if somefiles success, the retry call will throw filenotfound > exception, and this will cause client retry again and again until retry > exhausted, and bulkload fails. > When this happening, actually, some files are loaded successfully, that's a > inconsistent status. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14845) hbase-server leaks jdk.tools dependency to mapreduce consumers
[ https://issues.apache.org/jira/browse/HBASE-14845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-14845: --- Fix Version/s: (was: 0.98.21) 0.98.22 > hbase-server leaks jdk.tools dependency to mapreduce consumers > -- > > Key: HBASE-14845 > URL: https://issues.apache.org/jira/browse/HBASE-14845 > Project: HBase > Issue Type: Bug > Components: build, dependencies >Affects Versions: 2.0.0, 0.98.14, 1.2.0, 1.1.2, 1.3.0, 1.0.3 >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Critical > Fix For: 2.0.0, 1.0.4, 1.4.0, 1.3.1, 1.2.3, 0.98.22, 1.1.7 > > Attachments: HBASE-14845.1.patch > > > HBASE-13963 / HBASE-14844 take care of removing leaks of our dependency on > jdk-tools. > Until we move the mapreduce support classes out of hbase-server > (HBASE-11843), we need to also avoid leaking the dependency from that module. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14945) Backport HBASE-13153 (Bulk loaded HFile replication) to 0.98
[ https://issues.apache.org/jira/browse/HBASE-14945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-14945: --- Fix Version/s: (was: 0.98.21) 0.98.22 > Backport HBASE-13153 (Bulk loaded HFile replication) to 0.98 > > > Key: HBASE-14945 > URL: https://issues.apache.org/jira/browse/HBASE-14945 > Project: HBase > Issue Type: New Feature >Reporter: Andrew Purtell > Fix For: 0.98.22 > > > HBASE-13153 (Bulk loaded HFile replication) looks like a good candidate to > backport to 0.98. It would address an important functional gap in replication > (bulk loads don't replicate) for 0.98 users, is a new feature toggled with a > new configuration parameter that is by default off, and does not change any > interfaces not marked as Private. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16043) Backport SPNEGO support to 0.98
[ https://issues.apache.org/jira/browse/HBASE-16043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-16043: --- Fix Version/s: (was: 0.98.21) 0.98.22 > Backport SPNEGO support to 0.98 > --- > > Key: HBASE-16043 > URL: https://issues.apache.org/jira/browse/HBASE-16043 > Project: HBase > Issue Type: Sub-task > Components: master, regionserver, security >Reporter: Josh Elser >Assignee: Josh Elser > Fix For: 0.98.22 > > > The initial backport work of the parent issue to 0.98 was more difficult than > I expected. 0.98 uses Hadoop's HttpServer whereas >=1.x uses a copied variant > of that HttpServer class (that has significantly diverged since the copy). > Initial testing showed problems with the default configuration -- need to > figure out what the difference is between the two (or just not backport this > to 0.98). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14792) Latest docs fail to build when packaging 0.98
[
https://issues.apache.org/jira/browse/HBASE-14792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated HBASE-14792:
---
Fix Version/s: (was: 0.98.21)
0.98.22
> Latest docs fail to build when packaging 0.98
> -
>
> Key: HBASE-14792
> URL: https://issues.apache.org/jira/browse/HBASE-14792
> Project: HBase
> Issue Type: Bug
>Reporter: Andrew Purtell
>Assignee: Andrew Purtell
>Priority: Minor
> Fix For: 0.98.22
>
> Attachments: HBASE-14792-0.98.patch
>
>
> For releasing 0.98 we typically copy back the latest docs from master and
> then build.
> When I try generating the latest docs, I get:
> {noformat}
> [INFO]
>
> [INFO] Forking Apache HBase - Assembly 0.98.16-hadoop2
> [INFO]
>
> [INFO]
> [INFO] --- maven-enforcer-plugin:1.0.1:enforce (enforce) @ hbase-assembly ---
> [INFO]
> [INFO] --- buildnumber-maven-plugin:1.3:create-timestamp (default) @
> hbase-assembly ---
> [INFO]
> [INFO] <<< maven-javadoc-plugin:2.9.1:aggregate (report:aggregate) <
> generate-sources @ hbase <<<
> [INFO] configuring report plugin
> org.apache.maven.plugins:maven-checkstyle-plugin:2.13
> [INFO] Parent project loaded from repository: org.apache:apache:pom:12
> [INFO] Relativizing decoration links with respect to project URL:
> http://hbase.apache.org
> [INFO] Rendering site with org.apache.maven.skins:maven-fluido-skin:jar:1.4
> skin.
> [INFO] Skipped "About" report, file "index.html" already exists for the
> English version.
> [INFO] Skipped "Source Xref" report, file "xref/index.html" already exists
> for the English version.
> [INFO] Skipped "Test Source Xref" report, file "xref-test/index.html" already
> exists for the English version.
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on project
> hbase: Error during page generation: Could not find the template
> 'META-INF/maven/site.vm: Encountered "source" at META-INF/maven/site.vm[line
> 1162, column 52]
> [ERROR] Was expecting one of:
> [ERROR] "," ...
> [ERROR] ")" ...
> [ERROR] ...
> {noformat}
> Do I need to make POM updates?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-11290) Unlock RegionStates
[ https://issues.apache.org/jira/browse/HBASE-11290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-11290: --- Fix Version/s: (was: 0.98.21) 0.98.22 > Unlock RegionStates > --- > > Key: HBASE-11290 > URL: https://issues.apache.org/jira/browse/HBASE-11290 > Project: HBase > Issue Type: Sub-task >Affects Versions: 1.2.0, 1.3.0 >Reporter: Francis Liu >Assignee: Francis Liu > Fix For: 2.0.0, 1.4.0, 0.98.22 > > Attachments: HBASE-11290-0.98.patch, HBASE-11290-0.98_v2.patch, > HBASE-11290.01.branch-1.patch, HBASE-11290.02.patch, HBASE-11290.03.patch, > HBASE-11290.draft.patch, HBASE-11290_trunk.patch > > > Even though RegionStates is a highly accessed data structure in HMaster. Most > of it's methods are synchronized. Which limits concurrency. Even simply > making some of the getters non-synchronized by using concurrent data > structures has helped with region assignments. We can go as simple as this > approach or create locks per region or a bucket lock per region bucket. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14546) Backport stub DNS re-resolution options to 0.98
[ https://issues.apache.org/jira/browse/HBASE-14546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-14546: --- Fix Version/s: (was: 0.98.21) 0.98.22 > Backport stub DNS re-resolution options to 0.98 > --- > > Key: HBASE-14546 > URL: https://issues.apache.org/jira/browse/HBASE-14546 > Project: HBase > Issue Type: Task >Reporter: Andrew Purtell >Priority: Minor > Fix For: 0.98.22 > > > HBASE-12943 and HBASE-13067 addresses infinite caching preventing servers > from rejoining a cluster using the same hostname but a different IP address. > HBASE-14544 modifies this to be optional. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15924) Enhance hbase services autorestart capability to hbase-daemon.sh
[ https://issues.apache.org/jira/browse/HBASE-15924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-15924: --- Fix Version/s: (was: 0.98.21) 0.98.22 > Enhance hbase services autorestart capability to hbase-daemon.sh > - > > Key: HBASE-15924 > URL: https://issues.apache.org/jira/browse/HBASE-15924 > Project: HBase > Issue Type: Improvement >Affects Versions: 0.98.19 >Reporter: Loknath Priyatham Teja Singamsetty >Assignee: Loknath Priyatham Teja Singamsetty > Fix For: 0.98.22 > > > As part of HBASE-5939, the autorestart for hbase services has been added to > deal with scenarios where hbase services (master/regionserver/master-backup) > gets killed or goes down leading to unplanned outages. The changes were made > to hbase-daemon.sh to support autorestart option. > However, the autorestart implementation doesn't work in standalone mode and > other than that have few gaps with the implementation as per release notes of > HBASE-5939. Here is an attempt to re-design and fix the functionality > considering all possible usecases with hbase service operations. > Release Notes of HBASE-5939: > -- > When launched with autorestart, HBase processes will automatically restart if > they are not properly terminated, either by a "stop" command or by a cluster > stop. To ensure that it does not overload the system when the server itself > is corrupted and the process cannot be restarted, the server sleeps for 5 > minutes before restarting if it was already started 5 minutes ago previously. > To use it, launch the process with "bin/start-hbase autorestart". This option > is not fully compatible with the existing "restart" command: if you ask for a > restart on a server launched with autorestart, the server will restart but > the next server instance won't be automatically restarted. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12148) Remove TimeRangeTracker as point of contention when many threads writing a Store
[ https://issues.apache.org/jira/browse/HBASE-12148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-12148: --- Fix Version/s: (was: 0.98.21) 0.98.22 > Remove TimeRangeTracker as point of contention when many threads writing a > Store > > > Key: HBASE-12148 > URL: https://issues.apache.org/jira/browse/HBASE-12148 > Project: HBase > Issue Type: Sub-task > Components: Performance >Affects Versions: 2.0.0, 0.99.1 >Reporter: stack >Assignee: Walter Koetke > Fix For: 2.0.0, 1.3.1, 0.98.22 > > Attachments: > 0001-In-AtomicUtils-change-updateMin-and-updateMax-to-ret.patch, > 12148.addendum.txt, 12148.min_and_max_run_independent.patch, 12148.txt, > 12148.txt, 12148v2.txt, 12148v2.txt, 12148v4.patch, HBASE-12148-V3.patch, > HBASE-12148-V3.patch, HBASE-12148.branch-1.v5.patch, > HBASE-12148.branch-1.v5.patch, HBASE-12148.txt, HBASE-12148V2.txt, Screen > Shot 2014-10-01 at 3.39.46 PM.png, Screen Shot 2014-10-01 at 3.41.07 PM.png, > Screen Shot 2016-04-13 at 1.49.30 PM.png, Screen Shot 2016-04-13 at 2.02.22 > PM.png, Screen Shot 2016-05-18 at 10.21.53 PM.png, TimeRangeTracker.tiff > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15258) Clean up javadoc warnings and errors on 0.98 branch
[ https://issues.apache.org/jira/browse/HBASE-15258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-15258: --- Fix Version/s: (was: 0.98.21) 0.98.22 > Clean up javadoc warnings and errors on 0.98 branch > --- > > Key: HBASE-15258 > URL: https://issues.apache.org/jira/browse/HBASE-15258 > Project: HBase > Issue Type: Task >Reporter: Andrew Purtell >Priority: Minor > Fix For: 0.98.22 > > > Clean up javadoc warnings and errors on 0.98 branch so issues reported in > precommit build results are more meaningful and actionable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15130) Backport 0.98 Scan different TimeRange for each column family
[ https://issues.apache.org/jira/browse/HBASE-15130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-15130: --- Fix Version/s: (was: 0.98.21) 0.98.22 > Backport 0.98 Scan different TimeRange for each column family > -- > > Key: HBASE-15130 > URL: https://issues.apache.org/jira/browse/HBASE-15130 > Project: HBase > Issue Type: Bug > Components: Client, regionserver, Scanners >Affects Versions: 0.98.17 >Reporter: churro morales >Assignee: churro morales > Fix For: 0.98.22 > > Attachments: HBASE-15130-0.98.patch, HBASE-15130-0.98.v1.patch, > HBASE-15130-0.98.v1.patch, HBASE-15130-0.98.v2.patch, > HBASE-15130-0.98.v3.patch, HBASE-15130-0.98.v4.patch > > > branch 98 version backport for HBASE-14355 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15984) Given failure to parse a given WAL that was closed cleanly, replay the WAL.
[ https://issues.apache.org/jira/browse/HBASE-15984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-15984: --- Fix Version/s: (was: 0.98.21) 0.98.22 > Given failure to parse a given WAL that was closed cleanly, replay the WAL. > --- > > Key: HBASE-15984 > URL: https://issues.apache.org/jira/browse/HBASE-15984 > Project: HBase > Issue Type: Sub-task > Components: Replication >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Critical > Fix For: 2.0.0, 1.0.4, 1.4.0, 1.3.1, 1.2.3, 0.98.22, 1.1.7 > > Attachments: HBASE-15984.1.patch > > > subtask for a general work around for "underlying reader failed / is in a bad > state" just for the case where a WAL 1) was closed cleanly and 2) we can tell > that our current offset ought not be the end of parseable entries. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15635) Mean age of Blocks in cache (seconds) on webUI should be greater than zero
[ https://issues.apache.org/jira/browse/HBASE-15635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-15635: --- Fix Version/s: (was: 0.98.21) 0.98.22 > Mean age of Blocks in cache (seconds) on webUI should be greater than zero > -- > > Key: HBASE-15635 > URL: https://issues.apache.org/jira/browse/HBASE-15635 > Project: HBase > Issue Type: Bug >Affects Versions: 0.98.17 >Reporter: Heng Chen >Assignee: Heng Chen > Fix For: 2.0.0, 1.4.0, 1.0.5, 1.3.1, 1.2.3, 0.98.22, 1.1.7 > > Attachments: 7BFFAF68-0807-400C-853F-706B498449E1.png, > HBASE-15635.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15257) Clean up findbugs warnings on 0.98 branch
[ https://issues.apache.org/jira/browse/HBASE-15257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-15257: --- Fix Version/s: (was: 0.98.21) 0.98.22 > Clean up findbugs warnings on 0.98 branch > - > > Key: HBASE-15257 > URL: https://issues.apache.org/jira/browse/HBASE-15257 > Project: HBase > Issue Type: Task >Reporter: Andrew Purtell >Priority: Minor > Fix For: 0.98.22 > > > Findbugs reports from precommit builds against 0.98 branch will be much more > useful if we make a pass over the existing significant warnings and fix them, > and add annotations for warnings we expect. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15580) Tag coprocessor limitedprivate scope to StoreFile.Reader
[
https://issues.apache.org/jira/browse/HBASE-15580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated HBASE-15580:
---
Fix Version/s: (was: 0.98.21)
0.98.22
> Tag coprocessor limitedprivate scope to StoreFile.Reader
>
>
> Key: HBASE-15580
> URL: https://issues.apache.org/jira/browse/HBASE-15580
> Project: HBase
> Issue Type: Improvement
>Reporter: Rajeshbabu Chintaguntla
>Assignee: Rajeshbabu Chintaguntla
> Fix For: 2.0.0, 1.0.4, 1.2.3, 0.98.22, 1.1.7
>
> Attachments: HBASE-15580.patch, HBASE-15580_branch-1.0.patch
>
>
> For phoenix local indexing we need to have custom storefile reader
> constructor(IndexHalfStoreFileReader) to distinguish from other storefile
> readers. So wanted to mark StoreFile.Reader scope as
> InterfaceAudience.LimitedPrivate("Coprocessor")
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16321) Ensure findbugs jsr305 jar isn't present
[
https://issues.apache.org/jira/browse/HBASE-16321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411001#comment-15411001
]
Hudson commented on HBASE-16321:
FAILURE: Integrated in HBase-0.98-on-Hadoop-1.1 #1256 (See
[https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/1256/])
HBASE-16321 ammendment; allow compilation with Hadoop 2.7.2. (larsh: rev
e23fa866d110602331be73f23514c4fba97ef141)
* pom.xml
> Ensure findbugs jsr305 jar isn't present
>
>
> Key: HBASE-16321
> URL: https://issues.apache.org/jira/browse/HBASE-16321
> Project: HBase
> Issue Type: Sub-task
> Components: dependencies
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Blocker
> Fix For: 2.0.0, 1.3.0, 1.4.0, 1.1.6, 0.98.21, 1.2.3
>
> Attachments: 16321-amend.txt, HBASE-16321.1.patch, HBASE-16321.2.patch
>
>
> we should be using
> {code}
>
>
> com.github.stephenc.findbugs
> findbugs-annotations
> ${findbugs-annotations}
> compile
>
> {code}
> to ensure we don't have a prohibited dependency, but it looks like we're
> still bringing in
> {code}
>
> com.google.code.findbugs
> jsr305
> ${jsr305.version}
>
> {code}
> remove the findbugs version (even though the maven central pom claims the
> license is ALv2, that doesn't line up with the referenced project sites).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16321) Ensure findbugs jsr305 jar isn't present
[
https://issues.apache.org/jira/browse/HBASE-16321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15410982#comment-15410982
]
Hudson commented on HBASE-16321:
FAILURE: Integrated in HBase-0.98-matrix #384 (See
[https://builds.apache.org/job/HBase-0.98-matrix/384/])
HBASE-16321 ammendment; allow compilation with Hadoop 2.7.2. (larsh: rev
e23fa866d110602331be73f23514c4fba97ef141)
* pom.xml
> Ensure findbugs jsr305 jar isn't present
>
>
> Key: HBASE-16321
> URL: https://issues.apache.org/jira/browse/HBASE-16321
> Project: HBase
> Issue Type: Sub-task
> Components: dependencies
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Blocker
> Fix For: 2.0.0, 1.3.0, 1.4.0, 1.1.6, 0.98.21, 1.2.3
>
> Attachments: 16321-amend.txt, HBASE-16321.1.patch, HBASE-16321.2.patch
>
>
> we should be using
> {code}
>
>
> com.github.stephenc.findbugs
> findbugs-annotations
> ${findbugs-annotations}
> compile
>
> {code}
> to ensure we don't have a prohibited dependency, but it looks like we're
> still bringing in
> {code}
>
> com.google.code.findbugs
> jsr305
> ${jsr305.version}
>
> {code}
> remove the findbugs version (even though the maven central pom claims the
> license is ALv2, that doesn't line up with the referenced project sites).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-16367) Race between master and region server initialization may lead to premature server abort
[
https://issues.apache.org/jira/browse/HBASE-16367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-16367:
---
Hadoop Flags: Reviewed
Fix Version/s: 1.4.0
2.0.0
Thanks, Heng.
Planning to commit Monday morning.
> Race between master and region server initialization may lead to premature
> server abort
> ---
>
> Key: HBASE-16367
> URL: https://issues.apache.org/jira/browse/HBASE-16367
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.1.2
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 2.0.0, 1.4.0
>
> Attachments: 16367.v1.txt, 16367.v2.txt, 16367.v3.txt,
> 63908-master.log
>
>
> I was troubleshooting a case where hbase (1.1.2) master always dies shortly
> after start - see attached master log snippet.
> It turned out that master initialization thread was racing with
> HRegionServer#preRegistrationInitialization() (initializeZooKeeper, actually)
> since HMaster extends HRegionServer.
> Through additional logging in master:
> {code}
> this.oldLogDir = createInitialFileSystemLayout();
> HFileSystem.addLocationsOrderInterceptor(conf);
> LOG.info("creating splitLogManager");
> {code}
> I found that execution didn't reach the last log line before region server
> declared cluster Id being null.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16367) Race between master and region server initialization may lead to premature server abort
[
https://issues.apache.org/jira/browse/HBASE-16367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15410977#comment-15410977
]
Heng Chen commented on HBASE-16367:
---
+1
> Race between master and region server initialization may lead to premature
> server abort
> ---
>
> Key: HBASE-16367
> URL: https://issues.apache.org/jira/browse/HBASE-16367
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.1.2
>Reporter: Ted Yu
>Assignee: Ted Yu
> Attachments: 16367.v1.txt, 16367.v2.txt, 16367.v3.txt,
> 63908-master.log
>
>
> I was troubleshooting a case where hbase (1.1.2) master always dies shortly
> after start - see attached master log snippet.
> It turned out that master initialization thread was racing with
> HRegionServer#preRegistrationInitialization() (initializeZooKeeper, actually)
> since HMaster extends HRegionServer.
> Through additional logging in master:
> {code}
> this.oldLogDir = createInitialFileSystemLayout();
> HFileSystem.addLocationsOrderInterceptor(conf);
> LOG.info("creating splitLogManager");
> {code}
> I found that execution didn't reach the last log line before region server
> declared cluster Id being null.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16367) Race between master and region server initialization may lead to premature server abort
[
https://issues.apache.org/jira/browse/HBASE-16367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15410922#comment-15410922
]
Hadoop QA commented on HBASE-16367:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} patch {color} | {color:blue} 0m 2s
{color} | {color:blue} The patch file was not named according to hbase's naming
conventions. Please see
https://yetus.apache.org/documentation/0.3.0/precommit-patchnames for
instructions. {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
28s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 41s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 37s
{color} | {color:green} master passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
53s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
21s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
59s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 28s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 33s
{color} | {color:green} master passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
47s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 40s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 40s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 37s
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 37s {color}
| {color:red} hbase-server-jdk1.7.0_80 with JDK v1.7.0_80 generated 2 new + 4
unchanged - 2 fixed = 6 total (was 6) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
54s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
21s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
31m 1s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green} 0m
18s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 2m 15s
{color} | {color:red} hbase-server generated 1 new + 0 unchanged - 0 fixed = 1
total (was 0) {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 28s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 34s
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 93m 5s
{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} 140m 39s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| FindBugs | module:hbase-server |
| | Return value of java.util.concurrent.CountDownLatch.await(long, TimeUnit)
ignored in
org.apache.hadoop.hbase.regionserver.HRegionServer.initializeZooKeeper() At
HRegionServer.java:ignored in
org.apache.hadoop.hbase.regionserver.HRegionServer.initializeZooKeeper() At
HRegionServer.
[jira] [Updated] (HBASE-16367) Race between master and region server initialization may lead to premature server abort
[
https://issues.apache.org/jira/browse/HBASE-16367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-16367:
---
Attachment: 16367.v3.txt
Patch v3 tries to suppress findbugs warning:
if the latch doesn't reach zero within timeout, server would abort.
> Race between master and region server initialization may lead to premature
> server abort
> ---
>
> Key: HBASE-16367
> URL: https://issues.apache.org/jira/browse/HBASE-16367
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.1.2
>Reporter: Ted Yu
>Assignee: Ted Yu
> Attachments: 16367.v1.txt, 16367.v2.txt, 16367.v3.txt,
> 63908-master.log
>
>
> I was troubleshooting a case where hbase (1.1.2) master always dies shortly
> after start - see attached master log snippet.
> It turned out that master initialization thread was racing with
> HRegionServer#preRegistrationInitialization() (initializeZooKeeper, actually)
> since HMaster extends HRegionServer.
> Through additional logging in master:
> {code}
> this.oldLogDir = createInitialFileSystemLayout();
> HFileSystem.addLocationsOrderInterceptor(conf);
> LOG.info("creating splitLogManager");
> {code}
> I found that execution didn't reach the last log line before region server
> declared cluster Id being null.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16367) Race between master and region server initialization may lead to premature server abort
[
https://issues.apache.org/jira/browse/HBASE-16367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15410844#comment-15410844
]
Hadoop QA commented on HBASE-16367:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} patch {color} | {color:blue} 0m 1s
{color} | {color:blue} The patch file was not named according to hbase's naming
conventions. Please see
https://yetus.apache.org/documentation/0.3.0/precommit-patchnames for
instructions. {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} 11m
51s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 41s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 37s
{color} | {color:green} master passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
17s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
38s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
59s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 52s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 34s
{color} | {color:green} master passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
47s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 39s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 39s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 36s
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 36s {color}
| {color:red} hbase-server-jdk1.7.0_80 with JDK v1.7.0_80 generated 2 new + 4
unchanged - 2 fixed = 6 total (was 6) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
52s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
22s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
31m 15s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green} 0m
17s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 2m 17s
{color} | {color:red} hbase-server generated 1 new + 0 unchanged - 0 fixed = 1
total (was 0) {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 26s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 34s
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 94m 45s
{color} | {color:green} hbase-server in the patch passed. {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} 152m 14s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| FindBugs | module:hbase-server |
| | Return value of java.util.concurrent.CountDownLatch.await(long, TimeUnit)
ignored in
org.apache.hadoop.hbase.regionserver.HRegionServer.initializeZooKeeper() At
HRegionServer.java:ignored in
org.apache.hadoop.hbase.regionserver.HRegionServer.initializeZooKeeper() At
HRegionServ
[jira] [Commented] (HBASE-14345) Consolidate printUsage in IntegrationTestLoadAndVerify
[
https://issues.apache.org/jira/browse/HBASE-14345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15410843#comment-15410843
]
Hadoop QA commented on HBASE-14345:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 4 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 11m
38s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 27s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 19s
{color} | {color:green} master passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
32s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
54s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m 0s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 22s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 9s
{color} | {color:green} master passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
20s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 25s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 25s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 18s
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 18s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
9s {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}
31m 9s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green} 0m
14s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m 0s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 17s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 9s
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 19s
{color} | {color:green} hbase-it in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
13s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 48m 27s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12822464/HBASE-14345.master.002.patch
|
| JIRA Issue | HBASE-14345 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux asf901.gq1.ygridcore.net 3.13.0-36-lowlatency #63-Ubuntu SMP
PREEMPT Wed Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / 30d7eea |
| Default Java | 1.7.0_80 |
| Multi-JDK versions | /usr/local/jenkins/java/jdk1.8.0:1.8.0
/usr/local/asfpackages/java/jdk1.7.0_80:1.7.0_80 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/2983/testReport/ |
| modules | C: hbase-it U: hbase-it |
| C
