[jira] [Created] (HBASE-21178) Get and Scan operation with converter_class not working
Subrat Mishra created HBASE-21178:
-
Summary: Get and Scan operation with converter_class not working
Key: HBASE-21178
URL: https://issues.apache.org/jira/browse/HBASE-21178
Project: HBase
Issue Type: Bug
Reporter: Subrat Mishra
Assignee: Subrat Mishra
Consider a simple scenario:
{code:java}
create 'foo', {NAME => 'f1'}
put 'foo','r1','f1:a',1000
get 'foo','r1',{COLUMNS => ['f1:a:c(org.apache.hadoop.hbase.util.Bytes).len']}
scan 'foo',{COLUMNS => ['f1:a:c(org.apache.hadoop.hbase.util.Bytes).len']}{code}
Both get and scan fails with ERROR
{code:java}
ERROR: wrong number of arguments (3 for 1) {code}
Looks like in table.rb file converter_method expects 3 arguments [(bytes,
offset, len)] since version 2.0.0, prior to version 2.0.0 it was taking only 1
argument [(bytes)]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21172) Reimplement the retry backoff logic for ReopenTableRegionsProcedure
[ https://issues.apache.org/jira/browse/HBASE-21172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-21172: -- Attachment: HBASE-21172-v3.patch > Reimplement the retry backoff logic for ReopenTableRegionsProcedure > --- > > Key: HBASE-21172 > URL: https://issues.apache.org/jira/browse/HBASE-21172 > Project: HBase > Issue Type: Sub-task > Components: amv2, proc-v2 >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.2.0, 2.1.1, 2.0.3 > > Attachments: HBASE-21172-v1.patch, HBASE-21172-v2.patch, > HBASE-21172-v3.patch, HBASE-21172.patch > > > Now we just do a blocking sleep in the execute method, and there is no > exponential backoff. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21172) Reimplement the retry backoff logic for ReopenTableRegionsProcedure
[ https://issues.apache.org/jira/browse/HBASE-21172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16608703#comment-16608703 ] Duo Zhang commented on HBASE-21172: --- Typo. > Reimplement the retry backoff logic for ReopenTableRegionsProcedure > --- > > Key: HBASE-21172 > URL: https://issues.apache.org/jira/browse/HBASE-21172 > Project: HBase > Issue Type: Sub-task > Components: amv2, proc-v2 >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.2.0, 2.1.1, 2.0.3 > > Attachments: HBASE-21172-v1.patch, HBASE-21172-v2.patch, > HBASE-21172-v3.patch, HBASE-21172.patch > > > Now we just do a blocking sleep in the execute method, and there is no > exponential backoff. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21144) AssignmentManager.waitForAssignment is not stable
[
https://issues.apache.org/jira/browse/HBASE-21144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duo Zhang updated HBASE-21144:
--
Attachment: (was: HBASE-21172-v3.patch)
> AssignmentManager.waitForAssignment is not stable
> -
>
> Key: HBASE-21144
> URL: https://issues.apache.org/jira/browse/HBASE-21144
> Project: HBase
> Issue Type: Bug
> Components: amv2, test
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.1.1, 2.0.3
>
> Attachments: HBASE-21144-addendum.patch,
> HBASE-21144-branch-2.1.patch, HBASE-21144-v1.patch, HBASE-21144.patch
>
>
> https://builds.apache.org/job/HBase-Flaky-Tests/job/master/366/artifact/hbase-server/target/surefire-reports/org.apache.hadoop.hbase.client.TestMetaWithReplicas-output.txt/*view*/
> All replicas for meta table are on the same machine
> {noformat}
> 2018-09-02 19:49:05,486 DEBUG [RS_OPEN_META-regionserver/asf904:0-0]
> handler.OpenRegionHandler(127): Opened hbase:meta,,1.1588230740 on
> asf904.gq1.ygridcore.net,47561,1535917740998
> 2018-09-02 19:49:32,802 DEBUG [RS_OPEN_META-regionserver/asf904:0-0]
> handler.OpenRegionHandler(127): Opened hbase:meta,,1_0001.534574363 on
> asf904.gq1.ygridcore.net,55408,1535917768453
> 2018-09-02 19:49:33,496 DEBUG [RS_OPEN_META-regionserver/asf904:0-0]
> handler.OpenRegionHandler(127): Opened hbase:meta,,1_0002.1657623790 on
> asf904.gq1.ygridcore.net,55408,1535917768453
> {noformat}
> But after calling am.waitForAssignment, the region location is still null...
> {noformat}
> 2018-09-02 19:49:32,414 INFO [Time-limited test]
> client.TestMetaWithReplicas(113): HBASE:META DEPLOY:
> hbase:meta,,1_0001.534574363 on null
> 2018-09-02 19:49:32,844 INFO [Time-limited test]
> client.TestMetaWithReplicas(113): HBASE:META DEPLOY:
> hbase:meta,,1_0002.1657623790 on null
> {noformat}
> So we will not balance the replicas and cause TestMetaWithReplicas to hang
> forever...
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21144) AssignmentManager.waitForAssignment is not stable
[
https://issues.apache.org/jira/browse/HBASE-21144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duo Zhang updated HBASE-21144:
--
Attachment: HBASE-21172-v3.patch
> AssignmentManager.waitForAssignment is not stable
> -
>
> Key: HBASE-21144
> URL: https://issues.apache.org/jira/browse/HBASE-21144
> Project: HBase
> Issue Type: Bug
> Components: amv2, test
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.1.1, 2.0.3
>
> Attachments: HBASE-21144-addendum.patch,
> HBASE-21144-branch-2.1.patch, HBASE-21144-v1.patch, HBASE-21144.patch
>
>
> https://builds.apache.org/job/HBase-Flaky-Tests/job/master/366/artifact/hbase-server/target/surefire-reports/org.apache.hadoop.hbase.client.TestMetaWithReplicas-output.txt/*view*/
> All replicas for meta table are on the same machine
> {noformat}
> 2018-09-02 19:49:05,486 DEBUG [RS_OPEN_META-regionserver/asf904:0-0]
> handler.OpenRegionHandler(127): Opened hbase:meta,,1.1588230740 on
> asf904.gq1.ygridcore.net,47561,1535917740998
> 2018-09-02 19:49:32,802 DEBUG [RS_OPEN_META-regionserver/asf904:0-0]
> handler.OpenRegionHandler(127): Opened hbase:meta,,1_0001.534574363 on
> asf904.gq1.ygridcore.net,55408,1535917768453
> 2018-09-02 19:49:33,496 DEBUG [RS_OPEN_META-regionserver/asf904:0-0]
> handler.OpenRegionHandler(127): Opened hbase:meta,,1_0002.1657623790 on
> asf904.gq1.ygridcore.net,55408,1535917768453
> {noformat}
> But after calling am.waitForAssignment, the region location is still null...
> {noformat}
> 2018-09-02 19:49:32,414 INFO [Time-limited test]
> client.TestMetaWithReplicas(113): HBASE:META DEPLOY:
> hbase:meta,,1_0001.534574363 on null
> 2018-09-02 19:49:32,844 INFO [Time-limited test]
> client.TestMetaWithReplicas(113): HBASE:META DEPLOY:
> hbase:meta,,1_0002.1657623790 on null
> {noformat}
> So we will not balance the replicas and cause TestMetaWithReplicas to hang
> forever...
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21144) AssignmentManager.waitForAssignment is not stable
[
https://issues.apache.org/jira/browse/HBASE-21144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duo Zhang updated HBASE-21144:
--
Attachment: HBASE-21144-branch-2.1.patch
> AssignmentManager.waitForAssignment is not stable
> -
>
> Key: HBASE-21144
> URL: https://issues.apache.org/jira/browse/HBASE-21144
> Project: HBase
> Issue Type: Bug
> Components: amv2, test
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.1.1, 2.0.3
>
> Attachments: HBASE-21144-addendum.patch,
> HBASE-21144-branch-2.1.patch, HBASE-21144-v1.patch, HBASE-21144.patch
>
>
> https://builds.apache.org/job/HBase-Flaky-Tests/job/master/366/artifact/hbase-server/target/surefire-reports/org.apache.hadoop.hbase.client.TestMetaWithReplicas-output.txt/*view*/
> All replicas for meta table are on the same machine
> {noformat}
> 2018-09-02 19:49:05,486 DEBUG [RS_OPEN_META-regionserver/asf904:0-0]
> handler.OpenRegionHandler(127): Opened hbase:meta,,1.1588230740 on
> asf904.gq1.ygridcore.net,47561,1535917740998
> 2018-09-02 19:49:32,802 DEBUG [RS_OPEN_META-regionserver/asf904:0-0]
> handler.OpenRegionHandler(127): Opened hbase:meta,,1_0001.534574363 on
> asf904.gq1.ygridcore.net,55408,1535917768453
> 2018-09-02 19:49:33,496 DEBUG [RS_OPEN_META-regionserver/asf904:0-0]
> handler.OpenRegionHandler(127): Opened hbase:meta,,1_0002.1657623790 on
> asf904.gq1.ygridcore.net,55408,1535917768453
> {noformat}
> But after calling am.waitForAssignment, the region location is still null...
> {noformat}
> 2018-09-02 19:49:32,414 INFO [Time-limited test]
> client.TestMetaWithReplicas(113): HBASE:META DEPLOY:
> hbase:meta,,1_0001.534574363 on null
> 2018-09-02 19:49:32,844 INFO [Time-limited test]
> client.TestMetaWithReplicas(113): HBASE:META DEPLOY:
> hbase:meta,,1_0002.1657623790 on null
> {noformat}
> So we will not balance the replicas and cause TestMetaWithReplicas to hang
> forever...
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21172) Reimplement the retry backoff logic for ReopenTableRegionsProcedure
[ https://issues.apache.org/jira/browse/HBASE-21172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-21172: -- Attachment: HBASE-21172-v2.patch > Reimplement the retry backoff logic for ReopenTableRegionsProcedure > --- > > Key: HBASE-21172 > URL: https://issues.apache.org/jira/browse/HBASE-21172 > Project: HBase > Issue Type: Sub-task > Components: amv2, proc-v2 >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.2.0, 2.1.1, 2.0.3 > > Attachments: HBASE-21172-v1.patch, HBASE-21172-v2.patch, > HBASE-21172.patch > > > Now we just do a blocking sleep in the execute method, and there is no > exponential backoff. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-21177) Add per-table metrics on getTime,putTime and scanTime
xijiawen created HBASE-21177: Summary: Add per-table metrics on getTime,putTime and scanTime Key: HBASE-21177 URL: https://issues.apache.org/jira/browse/HBASE-21177 Project: HBase Issue Type: New Feature Components: metrics Affects Versions: 2.0.2 Reporter: xijiawen Fix For: HBASE-14850 Adds getTime,putTime,SscanTime to the per-table mertrics. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21159) Add shell command to switch throttle on or off
[ https://issues.apache.org/jira/browse/HBASE-21159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16608630#comment-16608630 ] Yi Mei commented on HBASE-21159: Hi [~xucang], it's a good idea to use "enable_throttle" / "disable_throttle". Thanks for your suggestions. > Add shell command to switch throttle on or off > -- > > Key: HBASE-21159 > URL: https://issues.apache.org/jira/browse/HBASE-21159 > Project: HBase > Issue Type: Sub-task >Affects Versions: 3.0.0, 2.2.0 >Reporter: Yi Mei >Assignee: Yi Mei >Priority: Major > Attachments: HBASE-21159.master.001.patch > > > Add shell command to switch throttle on or off. When throttle is off, HBase > will not throttle any request. This feature may be useful in production > environment. > We can use the following commands to switch throttle: > throttle_switch true / throttle_switch false -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (HBASE-21159) Add shell command to switch throttle on or off
[ https://issues.apache.org/jira/browse/HBASE-21159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yi Mei reassigned HBASE-21159: -- Assignee: Yi Mei > Add shell command to switch throttle on or off > -- > > Key: HBASE-21159 > URL: https://issues.apache.org/jira/browse/HBASE-21159 > Project: HBase > Issue Type: Sub-task >Affects Versions: 3.0.0, 2.2.0 >Reporter: Yi Mei >Assignee: Yi Mei >Priority: Major > Attachments: HBASE-21159.master.001.patch > > > Add shell command to switch throttle on or off. When throttle is off, HBase > will not throttle any request. This feature may be useful in production > environment. > We can use the following commands to switch throttle: > throttle_switch true / throttle_switch false -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21159) Add shell command to switch throttle on or off
[ https://issues.apache.org/jira/browse/HBASE-21159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yi Mei updated HBASE-21159: --- Attachment: HBASE-21159.master.001.patch > Add shell command to switch throttle on or off > -- > > Key: HBASE-21159 > URL: https://issues.apache.org/jira/browse/HBASE-21159 > Project: HBase > Issue Type: Sub-task >Affects Versions: 3.0.0, 2.2.0 >Reporter: Yi Mei >Priority: Major > Attachments: HBASE-21159.master.001.patch > > > Add shell command to switch throttle on or off. When throttle is off, HBase > will not throttle any request. This feature may be useful in production > environment. > We can use the following commands to switch throttle: > throttle_switch true / throttle_switch false -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-21176) HBase 2.0.1, several inconsistency issues
Oleg Galitskiy created HBASE-21176:
--
Summary: HBase 2.0.1, several inconsistency issues
Key: HBASE-21176
URL: https://issues.apache.org/jira/browse/HBASE-21176
Project: HBase
Issue Type: Bug
Reporter: Oleg Galitskiy
Faced with several inconsistency issues in HBase 2.0.1:
{code}
ERROR: Region \{ meta => null, hdfs =>
hdfs://master:50001/hbase/data/default/some_table/0646d0bee757d0fb0de1529475b5426f,
deployed =>
hbase-region,16020,1536493017073;some_table,,1534195327532.0646d0bee757d0fb0de1529475b5426f.,
replicaId => 0 } not in META, but deployed on hbase-region,16020,1536493017073
...
ERROR: hbase:namespace has no state in meta
ERROR: table1 has no state in meta
ERROR: table2 has no state in meta
2018-09-09 21:40:04,155 INFO [main] util.HBaseFsck: Handling overlap merges in
parallel. set hbasefsck.overlap.merge.parallel to false to run serially.
ERROR: There is a hole in the region chain between and . You need to create a
new .regioninfo and region dir in hdfs to plug the hole.
ERROR: Found inconsistency in table test3
{code}
BUT in 2.0.x HBAse version options _-repair, -fix, -fixHdfsHoles, etc_ was
deprecated.
How I can fix it without these options?
Thanks.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HBASE-21175) Partially initialized SnapshotHFileCleaner leads to NPE during TestHFileArchiving
Ted Yu created HBASE-21175:
--
Summary: Partially initialized SnapshotHFileCleaner leads to NPE
during TestHFileArchiving
Key: HBASE-21175
URL: https://issues.apache.org/jira/browse/HBASE-21175
Project: HBase
Issue Type: Test
Reporter: Ted Yu
TestHFileArchiving#testCleaningRace creates HFileCleaner instance within the
test.
When SnapshotHFileCleaner.init() is called, there is no master parameter passed
in {{params}}.
When the chore runs the cleaner during the test, NPE comes out of this line in
getDeletableFiles():
{code}
return cache.getUnreferencedFiles(files, master.getSnapshotManager());
{code}
since master is null.
We should either check for the null master or, pass master instance properly
when constructing the cleaner instance.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21171) [amv2] Tool to parse a directory of MasterProcWALs standalone
[
https://issues.apache.org/jira/browse/HBASE-21171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16608590#comment-16608590
]
Hudson commented on HBASE-21171:
Results for branch branch-2
[build #1226 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1226/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1226//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1226//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1226//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> [amv2] Tool to parse a directory of MasterProcWALs standalone
> -
>
> Key: HBASE-21171
> URL: https://issues.apache.org/jira/browse/HBASE-21171
> Project: HBase
> Issue Type: Bug
> Components: amv2, test
>Reporter: stack
>Assignee: stack
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.1.1
>
> Attachments: HBASE-21171.branch-2.1.001.patch,
> HBASE-21171.branch-2.1.002.patch, HBASE-21171.branch-2.1.003.patch
>
>
> I want to be able to test parsing and be able to profile a standalone parse
> and WALProcedureStore load of procedures. Adding a simple main on
> WALProcedureStore seems to be enough. I tested parsing it a dir of hundreds
> of WALs to see what is going on when we try to load. Good for figuring how to
> log, where the memory is going, etc., in this subsystem.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21171) [amv2] Tool to parse a directory of MasterProcWALs standalone
[
https://issues.apache.org/jira/browse/HBASE-21171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16608586#comment-16608586
]
Hudson commented on HBASE-21171:
Results for branch branch-2.1
[build #302 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/302/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/302//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/302//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/302//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> [amv2] Tool to parse a directory of MasterProcWALs standalone
> -
>
> Key: HBASE-21171
> URL: https://issues.apache.org/jira/browse/HBASE-21171
> Project: HBase
> Issue Type: Bug
> Components: amv2, test
>Reporter: stack
>Assignee: stack
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.1.1
>
> Attachments: HBASE-21171.branch-2.1.001.patch,
> HBASE-21171.branch-2.1.002.patch, HBASE-21171.branch-2.1.003.patch
>
>
> I want to be able to test parsing and be able to profile a standalone parse
> and WALProcedureStore load of procedures. Adding a simple main on
> WALProcedureStore seems to be enough. I tested parsing it a dir of hundreds
> of WALs to see what is going on when we try to load. Good for figuring how to
> log, where the memory is going, etc., in this subsystem.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21150) Avoid delay in first flushes due to overheads in table metrics registration
[
https://issues.apache.org/jira/browse/HBASE-21150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-21150:
---
Attachment: (was: 21150.v6.txt)
> Avoid delay in first flushes due to overheads in table metrics registration
> ---
>
> Key: HBASE-21150
> URL: https://issues.apache.org/jira/browse/HBASE-21150
> Project: HBase
> Issue Type: Improvement
>Reporter: Ted Yu
>Priority: Minor
> Attachments: 21150.v1.txt, 21150.v2.txt, 21150.v3.txt, 21150.v4.txt,
> 21150.v4.txt, 21150.v5.txt
>
>
> After HBASE-15728 is integrated, the lazy table metrics registration results
> in penalty for the first flushes.
> Excerpt from log shows delay (note the same timestamp 08:18:23,234) :
> {code:java}
> 2018-09-02 08:18:23,232 DEBUG
> [rs(hw13463.attlocal.net,52760,1535901497280)-snapshot-pool10-thread-2]
> regionserver.MetricsTableSourceImpl(124): Creating new
> MetricsTableSourceImpl for table 'testtb-1535901500805'
> 2018-09-02 08:18:23,233 DEBUG
> [rs(hw13463.attlocal.net,52760,1535901497280)-snapshot-pool10-thread-2]
> regionserver.MetricsTableSourceImpl(137): registering metrics for testtb-
> 1535901500805
> 2018-09-02 08:18:23,234 INFO
> [rs(hw13463.attlocal.net,52760,1535901497280)-snapshot-pool10-thread-1]
> regionserver.HRegion(2822): Finished flush of dataSize ~2.29 KB/2343,
> heapSize ~5.16 KB/5280, currentSize=0 B/0 for
> fa403f6a4fb8dbc1a1c389744fce2d58 in 280ms, sequenceid=5, compaction
> requested=false
> 2018-09-02 08:18:23,234 DEBUG
> [rs(hw13463.attlocal.net,52758,1535901497238)-snapshot-pool11-thread-1]
> regionserver.MetricsTableAggregateSourceImpl(84): it took 6 ms to register
> testtb-1535901500805
> Thread[rs(hw13463.attlocal.net,52758,1535901497238)-snapshot-pool11-thread-1,5,FailOnTimeoutGroup]
> 2018-09-02 08:18:23,234 DEBUG
> [rs(hw13463.attlocal.net,52760,1535901497280)-snapshot-pool10-thread-1]
> regionserver.MetricsTableAggregateSourceImpl(84): it took 0 ms to register
> testtb-1535901500805
> Thread[rs(hw13463.attlocal.net,52760,1535901497280)-snapshot-pool10-thread-1,5,FailOnTimeoutGroup]
> 2018-09-02 08:18:23,234 DEBUG
> [rs(hw13463.attlocal.net,52762,1535901497314)-snapshot-pool9-thread-1]
> regionserver.MetricsTableAggregateSourceImpl(84): it took 6 ms to register
> testtb-1535901500805
> Thread[rs(hw13463.attlocal.net,52762,1535901497314)-snapshot-pool9-thread-1,5,FailOnTimeoutGroup]
> 2018-09-02 08:18:23,234 DEBUG
> [rs(hw13463.attlocal.net,52762,1535901497314)-snapshot-pool9-thread-2]
> regionserver.MetricsTableAggregateSourceImpl(84): it took 6 ms to register
> testtb-1535901500805
> Thread[rs(hw13463.attlocal.net,52762,1535901497314)-snapshot-pool9-thread-2,5,FailOnTimeoutGroup]
> 2018-09-02 08:18:23,234 DEBUG
> [rs(hw13463.attlocal.net,52758,1535901497238)-snapshot-pool11-thread-2]
> regionserver.MetricsTableAggregateSourceImpl(84): it took 5 ms to register
> testtb-1535901500805
> Thread[rs(hw13463.attlocal.net,52758,1535901497238)-snapshot-pool11-thread-2,5,FailOnTimeoutGroup]
> 2018-09-02 08:18:23,234 DEBUG
> [rs(hw13463.attlocal.net,52760,1535901497280)-snapshot-pool10-thread-2]
> regionserver.MetricsTableAggregateSourceImpl(84): it took 6 ms to register
> testtb-1535901500805
> Thread[rs(hw13463.attlocal.net,52760,1535901497280)-snapshot-pool10-thread-2,5,FailOnTimeoutGroup]
> {code}
> This is a regression in that there were multiple (6 ms) delays before the
> flush can finish, waiting for the metrics table to be registered.
> When first region of the table is opened on region server, we can proactively
> register table metrics.
> This would avoid the penalty on first flushes for the table.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21150) Avoid delay in first flushes due to overheads in table metrics registration
[
https://issues.apache.org/jira/browse/HBASE-21150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-21150:
---
Attachment: (was: 21150.v7.txt)
> Avoid delay in first flushes due to overheads in table metrics registration
> ---
>
> Key: HBASE-21150
> URL: https://issues.apache.org/jira/browse/HBASE-21150
> Project: HBase
> Issue Type: Improvement
>Reporter: Ted Yu
>Priority: Minor
> Attachments: 21150.v1.txt, 21150.v2.txt, 21150.v3.txt, 21150.v4.txt,
> 21150.v4.txt, 21150.v5.txt
>
>
> After HBASE-15728 is integrated, the lazy table metrics registration results
> in penalty for the first flushes.
> Excerpt from log shows delay (note the same timestamp 08:18:23,234) :
> {code:java}
> 2018-09-02 08:18:23,232 DEBUG
> [rs(hw13463.attlocal.net,52760,1535901497280)-snapshot-pool10-thread-2]
> regionserver.MetricsTableSourceImpl(124): Creating new
> MetricsTableSourceImpl for table 'testtb-1535901500805'
> 2018-09-02 08:18:23,233 DEBUG
> [rs(hw13463.attlocal.net,52760,1535901497280)-snapshot-pool10-thread-2]
> regionserver.MetricsTableSourceImpl(137): registering metrics for testtb-
> 1535901500805
> 2018-09-02 08:18:23,234 INFO
> [rs(hw13463.attlocal.net,52760,1535901497280)-snapshot-pool10-thread-1]
> regionserver.HRegion(2822): Finished flush of dataSize ~2.29 KB/2343,
> heapSize ~5.16 KB/5280, currentSize=0 B/0 for
> fa403f6a4fb8dbc1a1c389744fce2d58 in 280ms, sequenceid=5, compaction
> requested=false
> 2018-09-02 08:18:23,234 DEBUG
> [rs(hw13463.attlocal.net,52758,1535901497238)-snapshot-pool11-thread-1]
> regionserver.MetricsTableAggregateSourceImpl(84): it took 6 ms to register
> testtb-1535901500805
> Thread[rs(hw13463.attlocal.net,52758,1535901497238)-snapshot-pool11-thread-1,5,FailOnTimeoutGroup]
> 2018-09-02 08:18:23,234 DEBUG
> [rs(hw13463.attlocal.net,52760,1535901497280)-snapshot-pool10-thread-1]
> regionserver.MetricsTableAggregateSourceImpl(84): it took 0 ms to register
> testtb-1535901500805
> Thread[rs(hw13463.attlocal.net,52760,1535901497280)-snapshot-pool10-thread-1,5,FailOnTimeoutGroup]
> 2018-09-02 08:18:23,234 DEBUG
> [rs(hw13463.attlocal.net,52762,1535901497314)-snapshot-pool9-thread-1]
> regionserver.MetricsTableAggregateSourceImpl(84): it took 6 ms to register
> testtb-1535901500805
> Thread[rs(hw13463.attlocal.net,52762,1535901497314)-snapshot-pool9-thread-1,5,FailOnTimeoutGroup]
> 2018-09-02 08:18:23,234 DEBUG
> [rs(hw13463.attlocal.net,52762,1535901497314)-snapshot-pool9-thread-2]
> regionserver.MetricsTableAggregateSourceImpl(84): it took 6 ms to register
> testtb-1535901500805
> Thread[rs(hw13463.attlocal.net,52762,1535901497314)-snapshot-pool9-thread-2,5,FailOnTimeoutGroup]
> 2018-09-02 08:18:23,234 DEBUG
> [rs(hw13463.attlocal.net,52758,1535901497238)-snapshot-pool11-thread-2]
> regionserver.MetricsTableAggregateSourceImpl(84): it took 5 ms to register
> testtb-1535901500805
> Thread[rs(hw13463.attlocal.net,52758,1535901497238)-snapshot-pool11-thread-2,5,FailOnTimeoutGroup]
> 2018-09-02 08:18:23,234 DEBUG
> [rs(hw13463.attlocal.net,52760,1535901497280)-snapshot-pool10-thread-2]
> regionserver.MetricsTableAggregateSourceImpl(84): it took 6 ms to register
> testtb-1535901500805
> Thread[rs(hw13463.attlocal.net,52760,1535901497280)-snapshot-pool10-thread-2,5,FailOnTimeoutGroup]
> {code}
> This is a regression in that there were multiple (6 ms) delays before the
> flush can finish, waiting for the metrics table to be registered.
> When first region of the table is opened on region server, we can proactively
> register table metrics.
> This would avoid the penalty on first flushes for the table.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-16458) Shorten backup / restore test execution time
[
https://issues.apache.org/jira/browse/HBASE-16458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16608533#comment-16608533
]
Vladimir Rodionov commented on HBASE-16458:
---
[~ted_yu], cleanup must be done after *all* unit tests. Just *mvn clean* should
work fine.
> Shorten backup / restore test execution time
>
>
> Key: HBASE-16458
> URL: https://issues.apache.org/jira/browse/HBASE-16458
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
>Assignee: Vladimir Rodionov
>Priority: Major
> Labels: backup
> Attachments: 16458-v1.patch, 16458.HBASE-7912.v3.txt,
> 16458.HBASE-7912.v4.txt, 16458.v1.txt, 16458.v2.txt, 16458.v2.txt,
> 16458.v3.txt, 16458.v4.txt, 16458.v5.txt, HBASE-16458-v1.patch,
> HBASE-16458-v2.patch
>
>
> Below was timing information for all the backup / restore tests (today's
> result):
> {code}
> Running org.apache.hadoop.hbase.backup.TestIncrementalBackup
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 576.273 sec -
> in org.apache.hadoop.hbase.backup.TestIncrementalBackup
> Running org.apache.hadoop.hbase.backup.TestBackupBoundaryTests
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 124.67 sec -
> in org.apache.hadoop.hbase.backup.TestBackupBoundaryTests
> Running org.apache.hadoop.hbase.backup.TestBackupStatusProgress
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 102.34 sec -
> in org.apache.hadoop.hbase.backup.TestBackupStatusProgress
> Running org.apache.hadoop.hbase.backup.TestBackupAdmin
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 490.251 sec -
> in org.apache.hadoop.hbase.backup.TestBackupAdmin
> Running org.apache.hadoop.hbase.backup.TestHFileArchiving
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 84.323 sec -
> in org.apache.hadoop.hbase.backup.TestHFileArchiving
> Running org.apache.hadoop.hbase.backup.TestSystemTableSnapshot
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 65.492 sec -
> in org.apache.hadoop.hbase.backup.TestSystemTableSnapshot
> Running org.apache.hadoop.hbase.backup.TestBackupDescribe
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 93.758 sec -
> in org.apache.hadoop.hbase.backup.TestBackupDescribe
> Running org.apache.hadoop.hbase.backup.TestBackupLogCleaner
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 109.187 sec -
> in org.apache.hadoop.hbase.backup.TestBackupLogCleaner
> Running org.apache.hadoop.hbase.backup.TestIncrementalBackupNoDataLoss
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 330.539 sec -
> in org.apache.hadoop.hbase.backup.TestIncrementalBackupNoDataLoss
> Running org.apache.hadoop.hbase.backup.TestRemoteBackup
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 84.371 sec -
> in org.apache.hadoop.hbase.backup.TestRemoteBackup
> Running org.apache.hadoop.hbase.backup.TestBackupSystemTable
> Tests run: 15, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 67.893 sec -
> in org.apache.hadoop.hbase.backup.TestBackupSystemTable
> Running org.apache.hadoop.hbase.backup.TestRestoreBoundaryTests
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 120.779 sec -
> in org.apache.hadoop.hbase.backup.TestRestoreBoundaryTests
> Running org.apache.hadoop.hbase.backup.TestFullBackupSetRestoreSet
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 117.815 sec -
> in org.apache.hadoop.hbase.backup.TestFullBackupSetRestoreSet
> Running org.apache.hadoop.hbase.backup.TestBackupShowHistory
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 136.517 sec -
> in org.apache.hadoop.hbase.backup.TestBackupShowHistory
> Running org.apache.hadoop.hbase.backup.TestRemoteRestore
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 91.799 sec -
> in org.apache.hadoop.hbase.backup.TestRemoteRestore
> Running org.apache.hadoop.hbase.backup.TestFullRestore
> Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 317.711 sec
> - in org.apache.hadoop.hbase.backup.TestFullRestore
> Running org.apache.hadoop.hbase.backup.TestFullBackupSet
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 87.045 sec -
> in org.apache.hadoop.hbase.backup.TestFullBackupSet
> Running org.apache.hadoop.hbase.backup.TestBackupDelete
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 86.214 sec -
> in org.apache.hadoop.hbase.backup.TestBackupDelete
> Running org.apache.hadoop.hbase.backup.TestBackupDeleteRestore
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 77.631 sec -
> in org.apache.hadoop.hbase.backup.TestBackupDeleteRestore
> Running org.apache.hadoop.hbase.backup.TestIncrementalBackupDeleteTable
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0,
[jira] [Comment Edited] (HBASE-16458) Shorten backup / restore test execution time
[
https://issues.apache.org/jira/browse/HBASE-16458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16608470#comment-16608470
]
Ted Yu edited comment on HBASE-16458 at 9/9/18 4:29 PM:
HBASE-16458-v2.patch was the last one from Vlad.
Patch v5 is from me, based on Vlad's v2.
was (Author: yuzhih...@gmail.com):
HBASE-16458-v2.patch was the last one from Vlad.
Patch v5 is from me.
> Shorten backup / restore test execution time
>
>
> Key: HBASE-16458
> URL: https://issues.apache.org/jira/browse/HBASE-16458
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
>Assignee: Vladimir Rodionov
>Priority: Major
> Labels: backup
> Attachments: 16458-v1.patch, 16458.HBASE-7912.v3.txt,
> 16458.HBASE-7912.v4.txt, 16458.v1.txt, 16458.v2.txt, 16458.v2.txt,
> 16458.v3.txt, 16458.v4.txt, 16458.v5.txt, HBASE-16458-v1.patch,
> HBASE-16458-v2.patch
>
>
> Below was timing information for all the backup / restore tests (today's
> result):
> {code}
> Running org.apache.hadoop.hbase.backup.TestIncrementalBackup
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 576.273 sec -
> in org.apache.hadoop.hbase.backup.TestIncrementalBackup
> Running org.apache.hadoop.hbase.backup.TestBackupBoundaryTests
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 124.67 sec -
> in org.apache.hadoop.hbase.backup.TestBackupBoundaryTests
> Running org.apache.hadoop.hbase.backup.TestBackupStatusProgress
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 102.34 sec -
> in org.apache.hadoop.hbase.backup.TestBackupStatusProgress
> Running org.apache.hadoop.hbase.backup.TestBackupAdmin
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 490.251 sec -
> in org.apache.hadoop.hbase.backup.TestBackupAdmin
> Running org.apache.hadoop.hbase.backup.TestHFileArchiving
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 84.323 sec -
> in org.apache.hadoop.hbase.backup.TestHFileArchiving
> Running org.apache.hadoop.hbase.backup.TestSystemTableSnapshot
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 65.492 sec -
> in org.apache.hadoop.hbase.backup.TestSystemTableSnapshot
> Running org.apache.hadoop.hbase.backup.TestBackupDescribe
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 93.758 sec -
> in org.apache.hadoop.hbase.backup.TestBackupDescribe
> Running org.apache.hadoop.hbase.backup.TestBackupLogCleaner
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 109.187 sec -
> in org.apache.hadoop.hbase.backup.TestBackupLogCleaner
> Running org.apache.hadoop.hbase.backup.TestIncrementalBackupNoDataLoss
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 330.539 sec -
> in org.apache.hadoop.hbase.backup.TestIncrementalBackupNoDataLoss
> Running org.apache.hadoop.hbase.backup.TestRemoteBackup
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 84.371 sec -
> in org.apache.hadoop.hbase.backup.TestRemoteBackup
> Running org.apache.hadoop.hbase.backup.TestBackupSystemTable
> Tests run: 15, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 67.893 sec -
> in org.apache.hadoop.hbase.backup.TestBackupSystemTable
> Running org.apache.hadoop.hbase.backup.TestRestoreBoundaryTests
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 120.779 sec -
> in org.apache.hadoop.hbase.backup.TestRestoreBoundaryTests
> Running org.apache.hadoop.hbase.backup.TestFullBackupSetRestoreSet
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 117.815 sec -
> in org.apache.hadoop.hbase.backup.TestFullBackupSetRestoreSet
> Running org.apache.hadoop.hbase.backup.TestBackupShowHistory
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 136.517 sec -
> in org.apache.hadoop.hbase.backup.TestBackupShowHistory
> Running org.apache.hadoop.hbase.backup.TestRemoteRestore
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 91.799 sec -
> in org.apache.hadoop.hbase.backup.TestRemoteRestore
> Running org.apache.hadoop.hbase.backup.TestFullRestore
> Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 317.711 sec
> - in org.apache.hadoop.hbase.backup.TestFullRestore
> Running org.apache.hadoop.hbase.backup.TestFullBackupSet
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 87.045 sec -
> in org.apache.hadoop.hbase.backup.TestFullBackupSet
> Running org.apache.hadoop.hbase.backup.TestBackupDelete
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 86.214 sec -
> in org.apache.hadoop.hbase.backup.TestBackupDelete
> Running org.apache.hadoop.hbase.backup.TestBackupDeleteRestore
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 77.631 sec -
> in
[jira] [Updated] (HBASE-21171) [amv2] Tool to parse a directory of MasterProcWALs standalone
[ https://issues.apache.org/jira/browse/HBASE-21171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-21171: -- Resolution: Fixed Hadoop Flags: Reviewed Fix Version/s: 2.1.1 2.2.0 3.0.0 Status: Resolved (was: Patch Available) Pushed to branch-2.1. Thanks for review. > [amv2] Tool to parse a directory of MasterProcWALs standalone > - > > Key: HBASE-21171 > URL: https://issues.apache.org/jira/browse/HBASE-21171 > Project: HBase > Issue Type: Bug > Components: amv2, test >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 3.0.0, 2.2.0, 2.1.1 > > Attachments: HBASE-21171.branch-2.1.001.patch, > HBASE-21171.branch-2.1.002.patch, HBASE-21171.branch-2.1.003.patch > > > I want to be able to test parsing and be able to profile a standalone parse > and WALProcedureStore load of procedures. Adding a simple main on > WALProcedureStore seems to be enough. I tested parsing it a dir of hundreds > of WALs to see what is going on when we try to load. Good for figuring how to > log, where the memory is going, etc., in this subsystem. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-16458) Shorten backup / restore test execution time
[
https://issues.apache.org/jira/browse/HBASE-16458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16608470#comment-16608470
]
Ted Yu commented on HBASE-16458:
HBASE-16458-v2.patch was the last one from Vlad.
Patch v5 is from me.
> Shorten backup / restore test execution time
>
>
> Key: HBASE-16458
> URL: https://issues.apache.org/jira/browse/HBASE-16458
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
>Assignee: Vladimir Rodionov
>Priority: Major
> Labels: backup
> Attachments: 16458-v1.patch, 16458.HBASE-7912.v3.txt,
> 16458.HBASE-7912.v4.txt, 16458.v1.txt, 16458.v2.txt, 16458.v2.txt,
> 16458.v3.txt, 16458.v4.txt, 16458.v5.txt, HBASE-16458-v1.patch,
> HBASE-16458-v2.patch
>
>
> Below was timing information for all the backup / restore tests (today's
> result):
> {code}
> Running org.apache.hadoop.hbase.backup.TestIncrementalBackup
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 576.273 sec -
> in org.apache.hadoop.hbase.backup.TestIncrementalBackup
> Running org.apache.hadoop.hbase.backup.TestBackupBoundaryTests
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 124.67 sec -
> in org.apache.hadoop.hbase.backup.TestBackupBoundaryTests
> Running org.apache.hadoop.hbase.backup.TestBackupStatusProgress
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 102.34 sec -
> in org.apache.hadoop.hbase.backup.TestBackupStatusProgress
> Running org.apache.hadoop.hbase.backup.TestBackupAdmin
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 490.251 sec -
> in org.apache.hadoop.hbase.backup.TestBackupAdmin
> Running org.apache.hadoop.hbase.backup.TestHFileArchiving
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 84.323 sec -
> in org.apache.hadoop.hbase.backup.TestHFileArchiving
> Running org.apache.hadoop.hbase.backup.TestSystemTableSnapshot
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 65.492 sec -
> in org.apache.hadoop.hbase.backup.TestSystemTableSnapshot
> Running org.apache.hadoop.hbase.backup.TestBackupDescribe
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 93.758 sec -
> in org.apache.hadoop.hbase.backup.TestBackupDescribe
> Running org.apache.hadoop.hbase.backup.TestBackupLogCleaner
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 109.187 sec -
> in org.apache.hadoop.hbase.backup.TestBackupLogCleaner
> Running org.apache.hadoop.hbase.backup.TestIncrementalBackupNoDataLoss
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 330.539 sec -
> in org.apache.hadoop.hbase.backup.TestIncrementalBackupNoDataLoss
> Running org.apache.hadoop.hbase.backup.TestRemoteBackup
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 84.371 sec -
> in org.apache.hadoop.hbase.backup.TestRemoteBackup
> Running org.apache.hadoop.hbase.backup.TestBackupSystemTable
> Tests run: 15, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 67.893 sec -
> in org.apache.hadoop.hbase.backup.TestBackupSystemTable
> Running org.apache.hadoop.hbase.backup.TestRestoreBoundaryTests
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 120.779 sec -
> in org.apache.hadoop.hbase.backup.TestRestoreBoundaryTests
> Running org.apache.hadoop.hbase.backup.TestFullBackupSetRestoreSet
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 117.815 sec -
> in org.apache.hadoop.hbase.backup.TestFullBackupSetRestoreSet
> Running org.apache.hadoop.hbase.backup.TestBackupShowHistory
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 136.517 sec -
> in org.apache.hadoop.hbase.backup.TestBackupShowHistory
> Running org.apache.hadoop.hbase.backup.TestRemoteRestore
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 91.799 sec -
> in org.apache.hadoop.hbase.backup.TestRemoteRestore
> Running org.apache.hadoop.hbase.backup.TestFullRestore
> Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 317.711 sec
> - in org.apache.hadoop.hbase.backup.TestFullRestore
> Running org.apache.hadoop.hbase.backup.TestFullBackupSet
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 87.045 sec -
> in org.apache.hadoop.hbase.backup.TestFullBackupSet
> Running org.apache.hadoop.hbase.backup.TestBackupDelete
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 86.214 sec -
> in org.apache.hadoop.hbase.backup.TestBackupDelete
> Running org.apache.hadoop.hbase.backup.TestBackupDeleteRestore
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 77.631 sec -
> in org.apache.hadoop.hbase.backup.TestBackupDeleteRestore
> Running org.apache.hadoop.hbase.backup.TestIncrementalBackupDeleteTable
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 190.358 sec -
> in
[jira] [Updated] (HBASE-16458) Shorten backup / restore test execution time
[
https://issues.apache.org/jira/browse/HBASE-16458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-16458:
---
Attachment: (was: 16458.HBASE-7912.v5.txt)
> Shorten backup / restore test execution time
>
>
> Key: HBASE-16458
> URL: https://issues.apache.org/jira/browse/HBASE-16458
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
>Assignee: Vladimir Rodionov
>Priority: Major
> Labels: backup
> Attachments: 16458-v1.patch, 16458.HBASE-7912.v3.txt,
> 16458.HBASE-7912.v4.txt, 16458.v1.txt, 16458.v2.txt, 16458.v2.txt,
> 16458.v3.txt, 16458.v4.txt, 16458.v5.txt, HBASE-16458-v1.patch,
> HBASE-16458-v2.patch
>
>
> Below was timing information for all the backup / restore tests (today's
> result):
> {code}
> Running org.apache.hadoop.hbase.backup.TestIncrementalBackup
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 576.273 sec -
> in org.apache.hadoop.hbase.backup.TestIncrementalBackup
> Running org.apache.hadoop.hbase.backup.TestBackupBoundaryTests
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 124.67 sec -
> in org.apache.hadoop.hbase.backup.TestBackupBoundaryTests
> Running org.apache.hadoop.hbase.backup.TestBackupStatusProgress
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 102.34 sec -
> in org.apache.hadoop.hbase.backup.TestBackupStatusProgress
> Running org.apache.hadoop.hbase.backup.TestBackupAdmin
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 490.251 sec -
> in org.apache.hadoop.hbase.backup.TestBackupAdmin
> Running org.apache.hadoop.hbase.backup.TestHFileArchiving
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 84.323 sec -
> in org.apache.hadoop.hbase.backup.TestHFileArchiving
> Running org.apache.hadoop.hbase.backup.TestSystemTableSnapshot
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 65.492 sec -
> in org.apache.hadoop.hbase.backup.TestSystemTableSnapshot
> Running org.apache.hadoop.hbase.backup.TestBackupDescribe
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 93.758 sec -
> in org.apache.hadoop.hbase.backup.TestBackupDescribe
> Running org.apache.hadoop.hbase.backup.TestBackupLogCleaner
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 109.187 sec -
> in org.apache.hadoop.hbase.backup.TestBackupLogCleaner
> Running org.apache.hadoop.hbase.backup.TestIncrementalBackupNoDataLoss
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 330.539 sec -
> in org.apache.hadoop.hbase.backup.TestIncrementalBackupNoDataLoss
> Running org.apache.hadoop.hbase.backup.TestRemoteBackup
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 84.371 sec -
> in org.apache.hadoop.hbase.backup.TestRemoteBackup
> Running org.apache.hadoop.hbase.backup.TestBackupSystemTable
> Tests run: 15, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 67.893 sec -
> in org.apache.hadoop.hbase.backup.TestBackupSystemTable
> Running org.apache.hadoop.hbase.backup.TestRestoreBoundaryTests
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 120.779 sec -
> in org.apache.hadoop.hbase.backup.TestRestoreBoundaryTests
> Running org.apache.hadoop.hbase.backup.TestFullBackupSetRestoreSet
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 117.815 sec -
> in org.apache.hadoop.hbase.backup.TestFullBackupSetRestoreSet
> Running org.apache.hadoop.hbase.backup.TestBackupShowHistory
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 136.517 sec -
> in org.apache.hadoop.hbase.backup.TestBackupShowHistory
> Running org.apache.hadoop.hbase.backup.TestRemoteRestore
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 91.799 sec -
> in org.apache.hadoop.hbase.backup.TestRemoteRestore
> Running org.apache.hadoop.hbase.backup.TestFullRestore
> Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 317.711 sec
> - in org.apache.hadoop.hbase.backup.TestFullRestore
> Running org.apache.hadoop.hbase.backup.TestFullBackupSet
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 87.045 sec -
> in org.apache.hadoop.hbase.backup.TestFullBackupSet
> Running org.apache.hadoop.hbase.backup.TestBackupDelete
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 86.214 sec -
> in org.apache.hadoop.hbase.backup.TestBackupDelete
> Running org.apache.hadoop.hbase.backup.TestBackupDeleteRestore
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 77.631 sec -
> in org.apache.hadoop.hbase.backup.TestBackupDeleteRestore
> Running org.apache.hadoop.hbase.backup.TestIncrementalBackupDeleteTable
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 190.358 sec -
> in org.apache.hadoop.hbase.backup.TestIncrementalBackupDeleteTable
> Running
[jira] [Commented] (HBASE-21174) [REST] Failed to parse empty qualifier in TableResource#getScanResource
[
https://issues.apache.org/jira/browse/HBASE-21174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16608469#comment-16608469
]
Ted Yu commented on HBASE-21174:
+1, pending QA
> [REST] Failed to parse empty qualifier in TableResource#getScanResource
> ---
>
> Key: HBASE-21174
> URL: https://issues.apache.org/jira/browse/HBASE-21174
> Project: HBase
> Issue Type: Bug
> Components: REST
>Affects Versions: 3.0.0, 2.2.0
>Reporter: Guangxu Cheng
>Assignee: Guangxu Cheng
>Priority: Major
> Attachments: HBASE-21174.master.001.patch
>
>
> {code:xml}
> GET /t1/*?column=f:c1=f:
> {code}
> If I want to get the values of 'f:'(empty qualifier) for all rows in the
> table by rest server, I will send the above request. However, this request
> will return all column values.
> {code:java|title=TableResource#getScanResource|borderStyle=solid}
> for (String csplit : column) {
> String[] familysplit = csplit.trim().split(":");
> if (familysplit.length == 2) {
> if (familysplit[1].length() > 0) {
> if (LOG.isTraceEnabled()) {
> LOG.trace("Scan family and column : " + familysplit[0] + " " +
> familysplit[1]);
> }
> tableScan.addColumn(Bytes.toBytes(familysplit[0]),
> Bytes.toBytes(familysplit[1]));
> } else {
> tableScan.addFamily(Bytes.toBytes(familysplit[0]));
> if (LOG.isTraceEnabled()) {
> LOG.trace("Scan family : " + familysplit[0] + " and empty
> qualifier.");
> }
> tableScan.addColumn(Bytes.toBytes(familysplit[0]), null);
> }
> } else if (StringUtils.isNotEmpty(familysplit[0])) {
> if (LOG.isTraceEnabled()) {
> LOG.trace("Scan family : " + familysplit[0]);
> }
> tableScan.addFamily(Bytes.toBytes(familysplit[0]));
> }
> }
> {code}
> Through the above code, when the column has an empty qualifier, the empty
> qualifier cannot be parsed correctly.In other words, 'f:'(empty qualifier)
> and 'f' (column family) are considered to have the same meaning, which is
> wrong.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-16458) Shorten backup / restore test execution time
[
https://issues.apache.org/jira/browse/HBASE-16458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16608468#comment-16608468
]
Mike Drob commented on HBASE-16458:
---
I'd like to review this patch but I'm confused which file I should be looking
at. Use of shutdown hooks caught my attention and is generally inadvisable.
> Shorten backup / restore test execution time
>
>
> Key: HBASE-16458
> URL: https://issues.apache.org/jira/browse/HBASE-16458
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
>Assignee: Vladimir Rodionov
>Priority: Major
> Labels: backup
> Attachments: 16458-v1.patch, 16458.HBASE-7912.v3.txt,
> 16458.HBASE-7912.v4.txt, 16458.HBASE-7912.v5.txt, 16458.v1.txt, 16458.v2.txt,
> 16458.v2.txt, 16458.v3.txt, 16458.v4.txt, 16458.v5.txt, HBASE-16458-v1.patch,
> HBASE-16458-v2.patch
>
>
> Below was timing information for all the backup / restore tests (today's
> result):
> {code}
> Running org.apache.hadoop.hbase.backup.TestIncrementalBackup
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 576.273 sec -
> in org.apache.hadoop.hbase.backup.TestIncrementalBackup
> Running org.apache.hadoop.hbase.backup.TestBackupBoundaryTests
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 124.67 sec -
> in org.apache.hadoop.hbase.backup.TestBackupBoundaryTests
> Running org.apache.hadoop.hbase.backup.TestBackupStatusProgress
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 102.34 sec -
> in org.apache.hadoop.hbase.backup.TestBackupStatusProgress
> Running org.apache.hadoop.hbase.backup.TestBackupAdmin
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 490.251 sec -
> in org.apache.hadoop.hbase.backup.TestBackupAdmin
> Running org.apache.hadoop.hbase.backup.TestHFileArchiving
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 84.323 sec -
> in org.apache.hadoop.hbase.backup.TestHFileArchiving
> Running org.apache.hadoop.hbase.backup.TestSystemTableSnapshot
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 65.492 sec -
> in org.apache.hadoop.hbase.backup.TestSystemTableSnapshot
> Running org.apache.hadoop.hbase.backup.TestBackupDescribe
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 93.758 sec -
> in org.apache.hadoop.hbase.backup.TestBackupDescribe
> Running org.apache.hadoop.hbase.backup.TestBackupLogCleaner
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 109.187 sec -
> in org.apache.hadoop.hbase.backup.TestBackupLogCleaner
> Running org.apache.hadoop.hbase.backup.TestIncrementalBackupNoDataLoss
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 330.539 sec -
> in org.apache.hadoop.hbase.backup.TestIncrementalBackupNoDataLoss
> Running org.apache.hadoop.hbase.backup.TestRemoteBackup
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 84.371 sec -
> in org.apache.hadoop.hbase.backup.TestRemoteBackup
> Running org.apache.hadoop.hbase.backup.TestBackupSystemTable
> Tests run: 15, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 67.893 sec -
> in org.apache.hadoop.hbase.backup.TestBackupSystemTable
> Running org.apache.hadoop.hbase.backup.TestRestoreBoundaryTests
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 120.779 sec -
> in org.apache.hadoop.hbase.backup.TestRestoreBoundaryTests
> Running org.apache.hadoop.hbase.backup.TestFullBackupSetRestoreSet
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 117.815 sec -
> in org.apache.hadoop.hbase.backup.TestFullBackupSetRestoreSet
> Running org.apache.hadoop.hbase.backup.TestBackupShowHistory
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 136.517 sec -
> in org.apache.hadoop.hbase.backup.TestBackupShowHistory
> Running org.apache.hadoop.hbase.backup.TestRemoteRestore
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 91.799 sec -
> in org.apache.hadoop.hbase.backup.TestRemoteRestore
> Running org.apache.hadoop.hbase.backup.TestFullRestore
> Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 317.711 sec
> - in org.apache.hadoop.hbase.backup.TestFullRestore
> Running org.apache.hadoop.hbase.backup.TestFullBackupSet
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 87.045 sec -
> in org.apache.hadoop.hbase.backup.TestFullBackupSet
> Running org.apache.hadoop.hbase.backup.TestBackupDelete
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 86.214 sec -
> in org.apache.hadoop.hbase.backup.TestBackupDelete
> Running org.apache.hadoop.hbase.backup.TestBackupDeleteRestore
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 77.631 sec -
> in org.apache.hadoop.hbase.backup.TestBackupDeleteRestore
> Running
[jira] [Commented] (HBASE-21052) After restoring a snapshot, table.jsp page for the table gets stuck
[
https://issues.apache.org/jira/browse/HBASE-21052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16608442#comment-16608442
]
Hudson commented on HBASE-21052:
Results for branch master
[build #482 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/482/]: (x)
*{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/master/482//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/482//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/482//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> After restoring a snapshot, table.jsp page for the table gets stuck
> ---
>
> Key: HBASE-21052
> URL: https://issues.apache.org/jira/browse/HBASE-21052
> Project: HBase
> Issue Type: Bug
> Components: snapshots
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Major
> Fix For: 3.0.0, 2.2.0
>
> Attachments: HBASE-21052.master.001.patch,
> HBASE-21052.master.002.patch, HBASE-21052.master.003.patch
>
>
> Steps to reproduce are as follows:
> 1. Create a table
> {code}
> create "test", "cf"
> {code}
> 2. Take a hbase snapshot for the table
> {code}
> snapshot "test", "snap"
> {code}
> 3. Disable the table
> {code}
> disable "test"
> {code}
> 4. Restore the hbase snapshot
> {code}
> restore_snapshot "snap"
> {code}
> 5. Open the table.jsp page for the table in a browser, but it gets stuck
> {code}
> http://:16010/table.jsp?name=test
> {code}
> According to the following thread dump, it looks like
> ConnectionImplementation.locateRegionInMeta() gets stuck when getting a
> compaction state.
> {code}
> "qtp2068100669-89" #89 daemon prio=5 os_prio=31 tid=0x7febac55b800
> nid=0xf403 waiting on condition [0x762b7000]
>java.lang.Thread.State: TIMED_WAITING (sleeping)
> at java.lang.Thread.sleep(Native Method)
> at
> org.apache.hadoop.hbase.client.ConnectionImplementation.locateRegionInMeta(ConnectionImplementation.java:933)
> at
> org.apache.hadoop.hbase.client.ConnectionImplementation.locateRegion(ConnectionImplementation.java:752)
> at
> org.apache.hadoop.hbase.client.ConnectionUtils$ShortCircuitingClusterConnection.locateRegion(ConnectionUtils.java:131)
> at
> org.apache.hadoop.hbase.client.ConnectionImplementation.locateRegion(ConnectionImplementation.java:738)
> at
> org.apache.hadoop.hbase.client.ConnectionUtils$ShortCircuitingClusterConnection.locateRegion(ConnectionUtils.java:131)
> at
> org.apache.hadoop.hbase.client.ConnectionImplementation.locateRegions(ConnectionImplementation.java:694)
> at
> org.apache.hadoop.hbase.client.ConnectionUtils$ShortCircuitingClusterConnection.locateRegions(ConnectionUtils.java:131)
> at
> org.apache.hadoop.hbase.client.HBaseAdmin.getCompactionState(HBaseAdmin.java:3336)
> at
> org.apache.hadoop.hbase.client.HBaseAdmin.getCompactionState(HBaseAdmin.java:2521)
> at
> org.apache.hadoop.hbase.generated.master.table_jsp._jspService(table_jsp.java:316)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:840)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1772)
> at
> org.apache.hadoop.hbase.http.lib.StaticUserWebFilter$StaticUserFilter.doFilter(StaticUserWebFilter.java:112)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1759)
> at
> org.apache.hadoop.hbase.http.ClickjackingPreventionFilter.doFilter(ClickjackingPreventionFilter.java:48)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1759)
> at
> org.apache.hadoop.hbase.http.HttpServer$QuotingInputFilter.doFilter(HttpServer.java:1374)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1759)
> at
> org.apache.hadoop.hbase.http.NoCacheFilter.doFilter(NoCacheFilter.java:49)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1759)
> at
>
[jira] [Commented] (HBASE-21173) Remove the duplicate HRegion#close in TestHRegion
[
https://issues.apache.org/jira/browse/HBASE-21173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16608428#comment-16608428
]
Hadoop QA commented on HBASE-21173:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
13s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
54s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
11s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
20s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
49s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
27s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
39s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
47s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
3s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m
3s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
20s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
45s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
12m 1s{color} | {color:green} Patch does not cause any errors with Hadoop
2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
34s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
36s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}126m
55s{color} | {color:green} hbase-server in the patch passed. {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}174m 30s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b |
| JIRA Issue | HBASE-21173 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12938986/HBASE-21173.master.002.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 739b275a2df0 3.13.0-143-generic #192-Ubuntu SMP Tue Feb 27
10:45:36 UTC 2018 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / a51c333856 |
| maven | version: Apache Maven 3.5.4
(1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) |
| Default Java | 1.8.0_181 |
| findbugs | v3.1.0-RC3 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/14370/testReport/ |
| Max. process+thread count | 4395 (vs. ulimit of 1) |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/14370/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> Remove the duplicate
[jira] [Commented] (HBASE-21174) [REST] Failed to parse empty qualifier in TableResource#getScanResource
[
https://issues.apache.org/jira/browse/HBASE-21174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16608419#comment-16608419
]
Guangxu Cheng commented on HBASE-21174:
---
Attach first patch for review.
Due to HBASE-21158, the new unit test for this issue will cause other unit
tests to fail. So, after HBASE-21158 is fixed and then trigger QA.
> [REST] Failed to parse empty qualifier in TableResource#getScanResource
> ---
>
> Key: HBASE-21174
> URL: https://issues.apache.org/jira/browse/HBASE-21174
> Project: HBase
> Issue Type: Bug
> Components: REST
>Affects Versions: 3.0.0, 2.2.0
>Reporter: Guangxu Cheng
>Assignee: Guangxu Cheng
>Priority: Major
> Attachments: HBASE-21174.master.001.patch
>
>
> {code:xml}
> GET /t1/*?column=f:c1=f:
> {code}
> If I want to get the values of 'f:'(empty qualifier) for all rows in the
> table by rest server, I will send the above request. However, this request
> will return all column values.
> {code:java|title=TableResource#getScanResource|borderStyle=solid}
> for (String csplit : column) {
> String[] familysplit = csplit.trim().split(":");
> if (familysplit.length == 2) {
> if (familysplit[1].length() > 0) {
> if (LOG.isTraceEnabled()) {
> LOG.trace("Scan family and column : " + familysplit[0] + " " +
> familysplit[1]);
> }
> tableScan.addColumn(Bytes.toBytes(familysplit[0]),
> Bytes.toBytes(familysplit[1]));
> } else {
> tableScan.addFamily(Bytes.toBytes(familysplit[0]));
> if (LOG.isTraceEnabled()) {
> LOG.trace("Scan family : " + familysplit[0] + " and empty
> qualifier.");
> }
> tableScan.addColumn(Bytes.toBytes(familysplit[0]), null);
> }
> } else if (StringUtils.isNotEmpty(familysplit[0])) {
> if (LOG.isTraceEnabled()) {
> LOG.trace("Scan family : " + familysplit[0]);
> }
> tableScan.addFamily(Bytes.toBytes(familysplit[0]));
> }
> }
> {code}
> Through the above code, when the column has an empty qualifier, the empty
> qualifier cannot be parsed correctly.In other words, 'f:'(empty qualifier)
> and 'f' (column family) are considered to have the same meaning, which is
> wrong.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21174) [REST] Failed to parse empty qualifier in TableResource#getScanResource
[
https://issues.apache.org/jira/browse/HBASE-21174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guangxu Cheng updated HBASE-21174:
--
Attachment: HBASE-21174.master.001.patch
> [REST] Failed to parse empty qualifier in TableResource#getScanResource
> ---
>
> Key: HBASE-21174
> URL: https://issues.apache.org/jira/browse/HBASE-21174
> Project: HBase
> Issue Type: Bug
> Components: REST
>Affects Versions: 3.0.0, 2.2.0
>Reporter: Guangxu Cheng
>Assignee: Guangxu Cheng
>Priority: Major
> Attachments: HBASE-21174.master.001.patch
>
>
> {code:xml}
> GET /t1/*?column=f:c1=f:
> {code}
> If I want to get the values of 'f:'(empty qualifier) for all rows in the
> table by rest server, I will send the above request. However, this request
> will return all column values.
> {code:java|title=TableResource#getScanResource|borderStyle=solid}
> for (String csplit : column) {
> String[] familysplit = csplit.trim().split(":");
> if (familysplit.length == 2) {
> if (familysplit[1].length() > 0) {
> if (LOG.isTraceEnabled()) {
> LOG.trace("Scan family and column : " + familysplit[0] + " " +
> familysplit[1]);
> }
> tableScan.addColumn(Bytes.toBytes(familysplit[0]),
> Bytes.toBytes(familysplit[1]));
> } else {
> tableScan.addFamily(Bytes.toBytes(familysplit[0]));
> if (LOG.isTraceEnabled()) {
> LOG.trace("Scan family : " + familysplit[0] + " and empty
> qualifier.");
> }
> tableScan.addColumn(Bytes.toBytes(familysplit[0]), null);
> }
> } else if (StringUtils.isNotEmpty(familysplit[0])) {
> if (LOG.isTraceEnabled()) {
> LOG.trace("Scan family : " + familysplit[0]);
> }
> tableScan.addFamily(Bytes.toBytes(familysplit[0]));
> }
> }
> {code}
> Through the above code, when the column has an empty qualifier, the empty
> qualifier cannot be parsed correctly.In other words, 'f:'(empty qualifier)
> and 'f' (column family) are considered to have the same meaning, which is
> wrong.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21174) [REST] Failed to parse empty qualifier in TableResource#getScanResource
[
https://issues.apache.org/jira/browse/HBASE-21174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guangxu Cheng updated HBASE-21174:
--
Environment: (was: {code:xml}
GET /t1/*?column=f:c1=f:
{code}
If I want to get the values of 'f:'(empty qualifier) for all rows in the table
by rest server, I will send the above request. However, this request will
return all column values.
{code:java|title=TableResource#getScanResource|borderStyle=solid}
for (String csplit : column) {
String[] familysplit = csplit.trim().split(":");
if (familysplit.length == 2) {
if (familysplit[1].length() > 0) {
if (LOG.isTraceEnabled()) {
LOG.trace("Scan family and column : " + familysplit[0] + " " +
familysplit[1]);
}
tableScan.addColumn(Bytes.toBytes(familysplit[0]),
Bytes.toBytes(familysplit[1]));
} else {
tableScan.addFamily(Bytes.toBytes(familysplit[0]));
if (LOG.isTraceEnabled()) {
LOG.trace("Scan family : " + familysplit[0] + " and empty
qualifier.");
}
tableScan.addColumn(Bytes.toBytes(familysplit[0]), null);
}
} else if (StringUtils.isNotEmpty(familysplit[0])) {
if (LOG.isTraceEnabled()) {
LOG.trace("Scan family : " + familysplit[0]);
}
tableScan.addFamily(Bytes.toBytes(familysplit[0]));
}
}
{code}
Through the above code, when the column has an empty qualifier, the empty
qualifier cannot be parsed correctly.In other words, 'f:'(empty qualifier) and
'f' (column family) are considered to have the same meaning, which is wrong.)
> [REST] Failed to parse empty qualifier in TableResource#getScanResource
> ---
>
> Key: HBASE-21174
> URL: https://issues.apache.org/jira/browse/HBASE-21174
> Project: HBase
> Issue Type: Bug
> Components: REST
>Affects Versions: 3.0.0, 2.2.0
>Reporter: Guangxu Cheng
>Assignee: Guangxu Cheng
>Priority: Major
>
> {code:title=TableResource#getScanResource|borderStyle=solid}
> for (String csplit : column) {
> String[] familysplit = csplit.trim().split(":");
> if (familysplit.length == 2) {
> if (familysplit[1].length() > 0) {
> if (LOG.isTraceEnabled()) {
> LOG.trace("Scan family and column : " + familysplit[0] + " " +
> familysplit[1]);
> }
> tableScan.addColumn(Bytes.toBytes(familysplit[0]),
> Bytes.toBytes(familysplit[1]));
> } else {
> tableScan.addFamily(Bytes.toBytes(familysplit[0]));
> if (LOG.isTraceEnabled()) {
> LOG.trace("Scan family : " + familysplit[0] + " and empty
> qualifier.");
> }
> tableScan.addColumn(Bytes.toBytes(familysplit[0]), null);
> }
> } else if (StringUtils.isNotEmpty(familysplit[0])) {
> if (LOG.isTraceEnabled()) {
> LOG.trace("Scan family : " + familysplit[0]);
> }
> tableScan.addFamily(Bytes.toBytes(familysplit[0]));
> }
> }
> {code}
> {code:xml}
> GET /t1/*?column=f:c1=f:
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21174) [REST] Failed to parse empty qualifier in TableResource#getScanResource
[
https://issues.apache.org/jira/browse/HBASE-21174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guangxu Cheng updated HBASE-21174:
--
Description:
{code:xml}
GET /t1/*?column=f:c1=f:
{code}
If I want to get the values of 'f:'(empty qualifier) for all rows in the table
by rest server, I will send the above request. However, this request will
return all column values.
{code:java|title=TableResource#getScanResource|borderStyle=solid}
for (String csplit : column) {
String[] familysplit = csplit.trim().split(":");
if (familysplit.length == 2) {
if (familysplit[1].length() > 0) {
if (LOG.isTraceEnabled()) {
LOG.trace("Scan family and column : " + familysplit[0] + " " +
familysplit[1]);
}
tableScan.addColumn(Bytes.toBytes(familysplit[0]),
Bytes.toBytes(familysplit[1]));
} else {
tableScan.addFamily(Bytes.toBytes(familysplit[0]));
if (LOG.isTraceEnabled()) {
LOG.trace("Scan family : " + familysplit[0] + " and empty
qualifier.");
}
tableScan.addColumn(Bytes.toBytes(familysplit[0]), null);
}
} else if (StringUtils.isNotEmpty(familysplit[0])) {
if (LOG.isTraceEnabled()) {
LOG.trace("Scan family : " + familysplit[0]);
}
tableScan.addFamily(Bytes.toBytes(familysplit[0]));
}
}
{code}
Through the above code, when the column has an empty qualifier, the empty
qualifier cannot be parsed correctly.In other words, 'f:'(empty qualifier) and
'f' (column family) are considered to have the same meaning, which is wrong.
was:
{code:title=TableResource#getScanResource|borderStyle=solid}
for (String csplit : column) {
String[] familysplit = csplit.trim().split(":");
if (familysplit.length == 2) {
if (familysplit[1].length() > 0) {
if (LOG.isTraceEnabled()) {
LOG.trace("Scan family and column : " + familysplit[0] + " " +
familysplit[1]);
}
tableScan.addColumn(Bytes.toBytes(familysplit[0]),
Bytes.toBytes(familysplit[1]));
} else {
tableScan.addFamily(Bytes.toBytes(familysplit[0]));
if (LOG.isTraceEnabled()) {
LOG.trace("Scan family : " + familysplit[0] + " and empty
qualifier.");
}
tableScan.addColumn(Bytes.toBytes(familysplit[0]), null);
}
} else if (StringUtils.isNotEmpty(familysplit[0])) {
if (LOG.isTraceEnabled()) {
LOG.trace("Scan family : " + familysplit[0]);
}
tableScan.addFamily(Bytes.toBytes(familysplit[0]));
}
}
{code}
{code:xml}
GET /t1/*?column=f:c1=f:
{code}
> [REST] Failed to parse empty qualifier in TableResource#getScanResource
> ---
>
> Key: HBASE-21174
> URL: https://issues.apache.org/jira/browse/HBASE-21174
> Project: HBase
> Issue Type: Bug
> Components: REST
>Affects Versions: 3.0.0, 2.2.0
>Reporter: Guangxu Cheng
>Assignee: Guangxu Cheng
>Priority: Major
>
> {code:xml}
> GET /t1/*?column=f:c1=f:
> {code}
> If I want to get the values of 'f:'(empty qualifier) for all rows in the
> table by rest server, I will send the above request. However, this request
> will return all column values.
> {code:java|title=TableResource#getScanResource|borderStyle=solid}
> for (String csplit : column) {
> String[] familysplit = csplit.trim().split(":");
> if (familysplit.length == 2) {
> if (familysplit[1].length() > 0) {
> if (LOG.isTraceEnabled()) {
> LOG.trace("Scan family and column : " + familysplit[0] + " " +
> familysplit[1]);
> }
> tableScan.addColumn(Bytes.toBytes(familysplit[0]),
> Bytes.toBytes(familysplit[1]));
> } else {
> tableScan.addFamily(Bytes.toBytes(familysplit[0]));
> if (LOG.isTraceEnabled()) {
> LOG.trace("Scan family : " + familysplit[0] + " and empty
> qualifier.");
> }
> tableScan.addColumn(Bytes.toBytes(familysplit[0]), null);
> }
> } else if (StringUtils.isNotEmpty(familysplit[0])) {
> if (LOG.isTraceEnabled()) {
> LOG.trace("Scan family : " + familysplit[0]);
> }
> tableScan.addFamily(Bytes.toBytes(familysplit[0]));
> }
> }
> {code}
> Through the above code, when the column has an empty qualifier, the empty
> qualifier cannot be parsed correctly.In other words, 'f:'(empty qualifier)
> and 'f' (column family) are considered to have the same meaning, which is
> wrong.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HBASE-21174) [REST] Failed to parse empty qualifier in TableResource#getScanResource
Guangxu Cheng created HBASE-21174:
-
Summary: [REST] Failed to parse empty qualifier in
TableResource#getScanResource
Key: HBASE-21174
URL: https://issues.apache.org/jira/browse/HBASE-21174
Project: HBase
Issue Type: Bug
Components: REST
Affects Versions: 3.0.0, 2.2.0
Environment: {code:xml}
GET /t1/*?column=f:c1=f:
{code}
If I want to get the values of 'f:'(empty qualifier) for all rows in the table
by rest server, I will send the above request. However, this request will
return all column values.
{code:java|title=TableResource#getScanResource|borderStyle=solid}
for (String csplit : column) {
String[] familysplit = csplit.trim().split(":");
if (familysplit.length == 2) {
if (familysplit[1].length() > 0) {
if (LOG.isTraceEnabled()) {
LOG.trace("Scan family and column : " + familysplit[0] + " " +
familysplit[1]);
}
tableScan.addColumn(Bytes.toBytes(familysplit[0]),
Bytes.toBytes(familysplit[1]));
} else {
tableScan.addFamily(Bytes.toBytes(familysplit[0]));
if (LOG.isTraceEnabled()) {
LOG.trace("Scan family : " + familysplit[0] + " and empty
qualifier.");
}
tableScan.addColumn(Bytes.toBytes(familysplit[0]), null);
}
} else if (StringUtils.isNotEmpty(familysplit[0])) {
if (LOG.isTraceEnabled()) {
LOG.trace("Scan family : " + familysplit[0]);
}
tableScan.addFamily(Bytes.toBytes(familysplit[0]));
}
}
{code}
Through the above code, when the column has an empty qualifier, the empty
qualifier cannot be parsed correctly.In other words, 'f:'(empty qualifier) and
'f' (column family) are considered to have the same meaning, which is wrong.
Reporter: Guangxu Cheng
Assignee: Guangxu Cheng
{code:title=TableResource#getScanResource|borderStyle=solid}
for (String csplit : column) {
String[] familysplit = csplit.trim().split(":");
if (familysplit.length == 2) {
if (familysplit[1].length() > 0) {
if (LOG.isTraceEnabled()) {
LOG.trace("Scan family and column : " + familysplit[0] + " " +
familysplit[1]);
}
tableScan.addColumn(Bytes.toBytes(familysplit[0]),
Bytes.toBytes(familysplit[1]));
} else {
tableScan.addFamily(Bytes.toBytes(familysplit[0]));
if (LOG.isTraceEnabled()) {
LOG.trace("Scan family : " + familysplit[0] + " and empty
qualifier.");
}
tableScan.addColumn(Bytes.toBytes(familysplit[0]), null);
}
} else if (StringUtils.isNotEmpty(familysplit[0])) {
if (LOG.isTraceEnabled()) {
LOG.trace("Scan family : " + familysplit[0]);
}
tableScan.addFamily(Bytes.toBytes(familysplit[0]));
}
}
{code}
{code:xml}
GET /t1/*?column=f:c1=f:
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21158) Empty qualifier cell is always returned when using QualifierFilter
[
https://issues.apache.org/jira/browse/HBASE-21158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16608390#comment-16608390
]
Guangxu Cheng commented on HBASE-21158:
---
I will commit it tomorrow if no other comments. Thanks
> Empty qualifier cell is always returned when using QualifierFilter
> --
>
> Key: HBASE-21158
> URL: https://issues.apache.org/jira/browse/HBASE-21158
> Project: HBase
> Issue Type: Bug
> Components: Filters
>Affects Versions: 3.0.0, 2.2.0
>Reporter: Guangxu Cheng
>Assignee: Guangxu Cheng
>Priority: Major
> Attachments: HBASE-21158.master.001.patch,
> HBASE-21158.master.002.patch
>
>
> {code:xml}
> hbase(main):002:0> put 'testTable','testrow','f:testcol1','testvalue1'
> 0 row(s) in 0.0040 seconds
> hbase(main):003:0> put 'testTable','testrow','f:','testvalue2'
> 0 row(s) in 0.0070 seconds
> # get row with empty column f:, result is correct.
> hbase(main):004:0> scan 'testTable',{FILTER => "QualifierFilter (=,
> 'binary:')"}
> ROW COLUMN+CELL
>
>
> testrowcolumn=f:,
> timestamp=1536218563581, value=testvalue2
>
> 1 row(s) in 0.0460 seconds
> # get row with column f:testcol1, result is incorrect.
> hbase(main):005:0> scan 'testTable',{FILTER => "QualifierFilter (=,
> 'binary:testcol1')"}
> ROW COLUMN+CELL
>
>
> testrowcolumn=f:,
> timestamp=1536218563581, value=testvalue2
>
> testrowcolumn=f:testcol1,
> timestamp=1536218550827, value=testvalue1
>
> 1 row(s) in 0.0070 seconds
> {code}
> As the above operation, when the row contains empty qualifier column, empty
> qualifier cell is always returned when using QualifierFilter.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21173) Remove the duplicate HRegion#close in TestHRegion
[
https://issues.apache.org/jira/browse/HBASE-21173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16608389#comment-16608389
]
Guangxu Cheng commented on HBASE-21173:
---
Attach 002 patch as [~yuzhih...@gmail.com] [~liuml07] suggestions.Thanks
{{testSequenceId}}
- In line 269, Replace region.close() with
HBaseTestingUtility.closeRegionAndWAL(region)
- In line 285, we need to verify that the value of region.getMaxFlushedSeqId()
is consistent before and after region.close(), so we keep region.close() and
replace it with HBaseTestingUtility.closeRegionAndWAL(region).
{{testCloseCarryingSnapshot}}
- In line 315, replace region.close() with
HBaseTestingUtility.closeRegionAndWAL(region)
- In line 317, remove duplicate HBaseTestingUtility.closeRegionAndWAL(region)
and set this.region to null
{{testCloseWithFailingFlush}}
- In line 578, replace region.close() with
HBaseTestingUtility.closeRegionAndWAL(region) and set this.region to null
{{testRecoveredEditsReplayCompaction}}
- In line 951, replace region.close() with
HBaseTestingUtility.closeRegionAndWAL(region)
{{testFlushMarkers}}
- In line 1083, replace region.close() with
HBaseTestingUtility.closeRegionAndWAL(region)
{{testGetWhileRegionClose}}
- In line 1281, set this.region to null
{{testBatchPut_whileMultipleRowLocksHeld}}
- In line 1281, set this.region to null
{{testRegionInfoFileCreation}}
- In line 4175, keep region.close() and set region to null as said by
Mingliang Liu
{{testBulkLoadReplicationEnabled}}
- In line 6234, remove region.close()
{quote}Other places to set this.region null value after HTU.closeRegionAndWAL()
is good to explicitly make the HTU.closeRegionAndWAL() in tearDown a no-op.
{quote}
Other places where set this.region null value after HTU.closeRegionAndWAL(),
will be fine as said by [~liuml07].
> Remove the duplicate HRegion#close in TestHRegion
> -
>
> Key: HBASE-21173
> URL: https://issues.apache.org/jira/browse/HBASE-21173
> Project: HBase
> Issue Type: Bug
> Components: test
>Affects Versions: 3.0.0, 2.2.0
>Reporter: Guangxu Cheng
>Assignee: Guangxu Cheng
>Priority: Major
> Attachments: HBASE-21173.master.001.patch,
> HBASE-21173.master.002.patch
>
>
> After HBASE-21138, some test methods still have the duplicate
> HRegion#close.So open this issue to remove the duplicate close
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21173) Remove the duplicate HRegion#close in TestHRegion
[ https://issues.apache.org/jira/browse/HBASE-21173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guangxu Cheng updated HBASE-21173: -- Attachment: HBASE-21173.master.002.patch > Remove the duplicate HRegion#close in TestHRegion > - > > Key: HBASE-21173 > URL: https://issues.apache.org/jira/browse/HBASE-21173 > Project: HBase > Issue Type: Bug > Components: test >Affects Versions: 3.0.0, 2.2.0 >Reporter: Guangxu Cheng >Assignee: Guangxu Cheng >Priority: Major > Attachments: HBASE-21173.master.001.patch, > HBASE-21173.master.002.patch > > > After HBASE-21138, some test methods still have the duplicate > HRegion#close.So open this issue to remove the duplicate close -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21172) Reimplement the retry backoff logic for ReopenTableRegionsProcedure
[
https://issues.apache.org/jira/browse/HBASE-21172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16608378#comment-16608378
]
Hadoop QA commented on HBASE-21172:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
12s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 2 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
24s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
0s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
4s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
24s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
9s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
26s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
43s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
14s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
54s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
4s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m
4s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
14s{color} | {color:green} hbase-procedure: The patch generated 0 new + 1
unchanged - 2 fixed = 1 total (was 3) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
10s{color} | {color:green} The patch hbase-server passed checkstyle {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
15s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
10m 24s{color} | {color:green} Patch does not cause any errors with Hadoop
2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
34s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
43s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
52s{color} | {color:green} hbase-procedure in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}119m
43s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
39s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}166m 47s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b |
| JIRA Issue | HBASE-21172 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12938980/HBASE-21172-v1.patch |
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux fc8ad10e0929 3.13.0-143-generic #192-Ubuntu SMP Tue Feb 27
10:45:36 UTC 2018 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
[jira] [Commented] (HBASE-21052) After restoring a snapshot, table.jsp page for the table gets stuck
[
https://issues.apache.org/jira/browse/HBASE-21052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16608357#comment-16608357
]
Hudson commented on HBASE-21052:
Results for branch branch-2
[build #1222 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1222/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1222//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1222//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1222//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> After restoring a snapshot, table.jsp page for the table gets stuck
> ---
>
> Key: HBASE-21052
> URL: https://issues.apache.org/jira/browse/HBASE-21052
> Project: HBase
> Issue Type: Bug
> Components: snapshots
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Major
> Fix For: 3.0.0, 2.2.0
>
> Attachments: HBASE-21052.master.001.patch,
> HBASE-21052.master.002.patch, HBASE-21052.master.003.patch
>
>
> Steps to reproduce are as follows:
> 1. Create a table
> {code}
> create "test", "cf"
> {code}
> 2. Take a hbase snapshot for the table
> {code}
> snapshot "test", "snap"
> {code}
> 3. Disable the table
> {code}
> disable "test"
> {code}
> 4. Restore the hbase snapshot
> {code}
> restore_snapshot "snap"
> {code}
> 5. Open the table.jsp page for the table in a browser, but it gets stuck
> {code}
> http://:16010/table.jsp?name=test
> {code}
> According to the following thread dump, it looks like
> ConnectionImplementation.locateRegionInMeta() gets stuck when getting a
> compaction state.
> {code}
> "qtp2068100669-89" #89 daemon prio=5 os_prio=31 tid=0x7febac55b800
> nid=0xf403 waiting on condition [0x762b7000]
>java.lang.Thread.State: TIMED_WAITING (sleeping)
> at java.lang.Thread.sleep(Native Method)
> at
> org.apache.hadoop.hbase.client.ConnectionImplementation.locateRegionInMeta(ConnectionImplementation.java:933)
> at
> org.apache.hadoop.hbase.client.ConnectionImplementation.locateRegion(ConnectionImplementation.java:752)
> at
> org.apache.hadoop.hbase.client.ConnectionUtils$ShortCircuitingClusterConnection.locateRegion(ConnectionUtils.java:131)
> at
> org.apache.hadoop.hbase.client.ConnectionImplementation.locateRegion(ConnectionImplementation.java:738)
> at
> org.apache.hadoop.hbase.client.ConnectionUtils$ShortCircuitingClusterConnection.locateRegion(ConnectionUtils.java:131)
> at
> org.apache.hadoop.hbase.client.ConnectionImplementation.locateRegions(ConnectionImplementation.java:694)
> at
> org.apache.hadoop.hbase.client.ConnectionUtils$ShortCircuitingClusterConnection.locateRegions(ConnectionUtils.java:131)
> at
> org.apache.hadoop.hbase.client.HBaseAdmin.getCompactionState(HBaseAdmin.java:3336)
> at
> org.apache.hadoop.hbase.client.HBaseAdmin.getCompactionState(HBaseAdmin.java:2521)
> at
> org.apache.hadoop.hbase.generated.master.table_jsp._jspService(table_jsp.java:316)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:840)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1772)
> at
> org.apache.hadoop.hbase.http.lib.StaticUserWebFilter$StaticUserFilter.doFilter(StaticUserWebFilter.java:112)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1759)
> at
> org.apache.hadoop.hbase.http.ClickjackingPreventionFilter.doFilter(ClickjackingPreventionFilter.java:48)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1759)
> at
> org.apache.hadoop.hbase.http.HttpServer$QuotingInputFilter.doFilter(HttpServer.java:1374)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1759)
> at
> org.apache.hadoop.hbase.http.NoCacheFilter.doFilter(NoCacheFilter.java:49)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1759)
>
