[jira] [Updated] (HBASE-15251) During a cluster restart, Hmaster thinks it is a failover by mistake
[ https://issues.apache.org/jira/browse/HBASE-15251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clara Xiong updated HBASE-15251: Affects Version/s: (was: 0.98.15) > During a cluster restart, Hmaster thinks it is a failover by mistake > > > Key: HBASE-15251 > URL: https://issues.apache.org/jira/browse/HBASE-15251 > Project: HBase > Issue Type: Bug > Components: master >Affects Versions: 2.0.0 >Reporter: Clara Xiong >Assignee: Clara Xiong > Attachments: HBASE-15251-master-v1.patch, HBASE-15251-master.patch > > > We often need to do cluster restart as part of release for a cluster of > > 1000 nodes. We have tried our best to get clean shutdown but 50% of the time, > hmaster still thinks it is a failover. This increases the restart time from 5 > min to 30 min and decreases locality from 99% to 5% since we didn't use a > locality-aware balancer. We had a bug HBASE-14129 but the fix didn't work. > After adding more logging and inspecting the logs, we identified two things > that trigger the failover handling: > 1. When Hmaster.AssignmentManager detects any dead servers on service > manager during joinCluster(), it determines this is a failover without > further check. I added a check whether there is even any region assigned to > these servers. During a clean restart, the regions are not even assigned. > 2. When there are some leftover empty folders for log and split directories > or empty wal files, it is also treated as a failover. I added a check for > that. Although this can be resolved by manual cleanup, it is still too > tedious for restarting a large cluster. > Patch will follow shortly. The fix is tested and used in production now. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14025) Update CHANGES.txt for 1.2
[ https://issues.apache.org/jira/browse/HBASE-14025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15153869#comment-15153869 ] Hudson commented on HBASE-14025: SUCCESS: Integrated in HBase-1.2-IT #443 (See [https://builds.apache.org/job/HBase-1.2-IT/443/]) HBASE-14025 update CHANGES.txt for 1.2 RC4 (busbey: rev 25b281972df2f5b15c426c8963cbf77dd853a5ad) * CHANGES.txt > Update CHANGES.txt for 1.2 > -- > > Key: HBASE-14025 > URL: https://issues.apache.org/jira/browse/HBASE-14025 > Project: HBase > Issue Type: Sub-task > Components: documentation >Affects Versions: 1.2.0 >Reporter: Sean Busbey >Assignee: Sean Busbey > Fix For: 1.2.0 > > > Since it's more effort than I expected, making a ticket to track actually > updating CHANGES.txt so that new RMs have an idea what to expect. > Maybe will make doc changes if there's enough here. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15251) During a cluster restart, Hmaster thinks it is a failover by mistake
[ https://issues.apache.org/jira/browse/HBASE-15251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15153864#comment-15153864 ] Stephen Yuan Jiang commented on HBASE-15251: +1 the updated patch (v1) looks good to me. > During a cluster restart, Hmaster thinks it is a failover by mistake > > > Key: HBASE-15251 > URL: https://issues.apache.org/jira/browse/HBASE-15251 > Project: HBase > Issue Type: Bug > Components: master >Affects Versions: 2.0.0, 0.98.15 >Reporter: Clara Xiong >Assignee: Clara Xiong > Attachments: HBASE-15251-master-v1.patch, HBASE-15251-master.patch > > > We often need to do cluster restart as part of release for a cluster of > > 1000 nodes. We have tried our best to get clean shutdown but 50% of the time, > hmaster still thinks it is a failover. This increases the restart time from 5 > min to 30 min and decreases locality from 99% to 5% since we didn't use a > locality-aware balancer. We had a bug HBASE-14129 but the fix didn't work. > After adding more logging and inspecting the logs, we identified two things > that trigger the failover handling: > 1. When Hmaster.AssignmentManager detects any dead servers on service > manager during joinCluster(), it determines this is a failover without > further check. I added a check whether there is even any region assigned to > these servers. During a clean restart, the regions are not even assigned. > 2. When there are some leftover empty folders for log and split directories > or empty wal files, it is also treated as a failover. I added a check for > that. Although this can be resolved by manual cleanup, it is still too > tedious for restarting a large cluster. > Patch will follow shortly. The fix is tested and used in production now. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15264) Implement a fan out HDFS OutputStream
[
https://issues.apache.org/jira/browse/HBASE-15264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15153845#comment-15153845
]
Hadoop QA commented on HBASE-15264:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
9s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 33s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 35s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 4m
9s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
17s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
56s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 25s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 34s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
47s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 32s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 32s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 35s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 35s
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 4m 12s
{color} | {color:red} Patch generated 11 new checkstyle issues in hbase-server
(total was 0, now 11). {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
17s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
22m 22s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m 2s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 25s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 34s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 83m 0s
{color} | {color:green} hbase-server in the patch passed with JDK v1.8.0_72.
{color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 86m 1s {color}
| {color:red} hbase-server in the patch failed with JDK v1.7.0_95. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
20s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 213m 9s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| JDK v1.7.0_95 Timed out junit tests |
org.apache.hadoop.hbase.snapshot.TestFlushSnapshotFromClient |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.9.1 Server=1.9.1 Image:yetus/hbase:date2016-02-19 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12788602/HBASE-15264-v4.patch |
| JIRA Issue | HBASE-15264 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux 6
[jira] [Commented] (HBASE-15291) FileSystem not closed in secure bulkLoad
[ https://issues.apache.org/jira/browse/HBASE-15291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15153831#comment-15153831 ] Ashish Singhi commented on HBASE-15291: --- What happens when there is a call to SecureBulkLoadEndpoint#cleanupBulkLoad after SecureBulkLoadEndpoint#secureBulkLoadHFiles, did you check ? > FileSystem not closed in secure bulkLoad > > > Key: HBASE-15291 > URL: https://issues.apache.org/jira/browse/HBASE-15291 > Project: HBase > Issue Type: Bug >Reporter: Yong Zhang >Assignee: Yong Zhang > Attachments: HBASE-15291.001.patch > > > FileSystem not closed in secure bulkLoad after bulkLoad finish, it will > cause memory used more and more if too many bulkLoad . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15247) InclusiveStopFilter does not respect reverse Filter property
[
https://issues.apache.org/jira/browse/HBASE-15247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15153818#comment-15153818
]
Ted Yu commented on HBASE-15247:
+1, pending QA run.
> InclusiveStopFilter does not respect reverse Filter property
>
>
> Key: HBASE-15247
> URL: https://issues.apache.org/jira/browse/HBASE-15247
> Project: HBase
> Issue Type: Bug
> Components: Filters
>Affects Versions: 2.0.0, 1.1.1
>Reporter: Rick Moritz
>Assignee: Amal Joshy
> Fix For: 2.0.0, 1.1.1, 1.3.0
>
> Attachments: HBASE-15247-branch-1.1.patch, HBASE-15247.patch
>
>
> InclusiveStopFilter only works with non-reversed Scans, it will not filter
> for reversed Scans, because it doesn't flip the cmp-operand in the reversed
> case. In fact, it doesn't even use the Filter.reverse flag.
> it should be something like this:
> if (reversed) {
> if (cmp > 0) {
> done = true;
> }
> }
> else {
> if (cmp < 0) {
> done = true;
> }
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15247) InclusiveStopFilter does not respect reverse Filter property
[
https://issues.apache.org/jira/browse/HBASE-15247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15153812#comment-15153812
]
Anoop Sam John commented on HBASE-15247:
+1. Will commit after QA report.
> InclusiveStopFilter does not respect reverse Filter property
>
>
> Key: HBASE-15247
> URL: https://issues.apache.org/jira/browse/HBASE-15247
> Project: HBase
> Issue Type: Bug
> Components: Filters
>Affects Versions: 2.0.0, 1.1.1
>Reporter: Rick Moritz
>Assignee: Amal Joshy
> Fix For: 2.0.0, 1.1.1, 1.3.0
>
> Attachments: HBASE-15247-branch-1.1.patch, HBASE-15247.patch
>
>
> InclusiveStopFilter only works with non-reversed Scans, it will not filter
> for reversed Scans, because it doesn't flip the cmp-operand in the reversed
> case. In fact, it doesn't even use the Filter.reverse flag.
> it should be something like this:
> if (reversed) {
> if (cmp > 0) {
> done = true;
> }
> }
> else {
> if (cmp < 0) {
> done = true;
> }
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15247) InclusiveStopFilter does not respect reverse Filter property
[
https://issues.apache.org/jira/browse/HBASE-15247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anoop Sam John updated HBASE-15247:
---
Fix Version/s: 1.3.0
> InclusiveStopFilter does not respect reverse Filter property
>
>
> Key: HBASE-15247
> URL: https://issues.apache.org/jira/browse/HBASE-15247
> Project: HBase
> Issue Type: Bug
> Components: Filters
>Affects Versions: 2.0.0, 1.1.1
>Reporter: Rick Moritz
>Assignee: Amal Joshy
> Fix For: 2.0.0, 1.1.1, 1.3.0
>
> Attachments: HBASE-15247-branch-1.1.patch, HBASE-15247.patch
>
>
> InclusiveStopFilter only works with non-reversed Scans, it will not filter
> for reversed Scans, because it doesn't flip the cmp-operand in the reversed
> case. In fact, it doesn't even use the Filter.reverse flag.
> it should be something like this:
> if (reversed) {
> if (cmp > 0) {
> done = true;
> }
> }
> else {
> if (cmp < 0) {
> done = true;
> }
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15247) InclusiveStopFilter does not respect reverse Filter property
[
https://issues.apache.org/jira/browse/HBASE-15247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amal Joshy updated HBASE-15247:
---
Attachment: HBASE-15247-branch-1.1.patch
Including patch for branch-1.1
> InclusiveStopFilter does not respect reverse Filter property
>
>
> Key: HBASE-15247
> URL: https://issues.apache.org/jira/browse/HBASE-15247
> Project: HBase
> Issue Type: Bug
> Components: Filters
>Affects Versions: 2.0.0, 1.1.1
>Reporter: Rick Moritz
>Assignee: Amal Joshy
> Fix For: 2.0.0, 1.1.1
>
> Attachments: HBASE-15247-branch-1.1.patch, HBASE-15247.patch
>
>
> InclusiveStopFilter only works with non-reversed Scans, it will not filter
> for reversed Scans, because it doesn't flip the cmp-operand in the reversed
> case. In fact, it doesn't even use the Filter.reverse flag.
> it should be something like this:
> if (reversed) {
> if (cmp > 0) {
> done = true;
> }
> }
> else {
> if (cmp < 0) {
> done = true;
> }
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15291) FileSystem not closed in secure bulkLoad
[ https://issues.apache.org/jira/browse/HBASE-15291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15153805#comment-15153805 ] Ted Yu commented on HBASE-15291: lgtm > FileSystem not closed in secure bulkLoad > > > Key: HBASE-15291 > URL: https://issues.apache.org/jira/browse/HBASE-15291 > Project: HBase > Issue Type: Bug >Reporter: Yong Zhang >Assignee: Yong Zhang > Attachments: HBASE-15291.001.patch > > > FileSystem not closed in secure bulkLoad after bulkLoad finish, it will > cause memory used more and more if too many bulkLoad . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15291) FileSystem not closed in secure bulkLoad
[ https://issues.apache.org/jira/browse/HBASE-15291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yong Zhang updated HBASE-15291: --- Status: Patch Available (was: Open) > FileSystem not closed in secure bulkLoad > > > Key: HBASE-15291 > URL: https://issues.apache.org/jira/browse/HBASE-15291 > Project: HBase > Issue Type: Bug >Reporter: Yong Zhang >Assignee: Yong Zhang > Attachments: HBASE-15291.001.patch > > > FileSystem not closed in secure bulkLoad after bulkLoad finish, it will > cause memory used more and more if too many bulkLoad . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15291) FileSystem not closed in secure bulkLoad
[ https://issues.apache.org/jira/browse/HBASE-15291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yong Zhang updated HBASE-15291: --- Attachment: HBASE-15291.001.patch Please help to review > FileSystem not closed in secure bulkLoad > > > Key: HBASE-15291 > URL: https://issues.apache.org/jira/browse/HBASE-15291 > Project: HBase > Issue Type: Bug >Reporter: Yong Zhang >Assignee: Yong Zhang > Attachments: HBASE-15291.001.patch > > > FileSystem not closed in secure bulkLoad after bulkLoad finish, it will > cause memory used more and more if too many bulkLoad . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-15291) FileSystem not closed in secure bulkLoad
Yong Zhang created HBASE-15291: -- Summary: FileSystem not closed in secure bulkLoad Key: HBASE-15291 URL: https://issues.apache.org/jira/browse/HBASE-15291 Project: HBase Issue Type: Bug Reporter: Yong Zhang Assignee: Yong Zhang FileSystem not closed in secure bulkLoad after bulkLoad finish, it will cause memory used more and more if too many bulkLoad . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15290) Hbase Rest CheckAndAPI should save other cells along with compared cell
[ https://issues.apache.org/jira/browse/HBASE-15290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15153802#comment-15153802 ] Ted Yu commented on HBASE-15290: Is it possible to add test so that there is no regression in the future ? > Hbase Rest CheckAndAPI should save other cells along with compared cell > --- > > Key: HBASE-15290 > URL: https://issues.apache.org/jira/browse/HBASE-15290 > Project: HBase > Issue Type: Bug > Components: hbase >Affects Versions: 1.1.1 > Environment: Linux and windows >Reporter: Ajith > Labels: easyfix > Attachments: checkputfix2.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > Java CheckAndPut API allows users to save Cells (C1..C5) while comparing a > Cell C1. > But in Rest API, even though caller sent multiple cells, hbase rest code is > ignoring all the cells except for compare cell. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14877) maven archetype: client application
[
https://issues.apache.org/jira/browse/HBASE-14877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Vimont updated HBASE-14877:
--
Status: Patch Available (was: Open)
Submitting v6 of the patch, which differs from previous versions of patch as
follows:
(1) In hbase-archetypes/hbase-client-project/pom.xml, the elements
{{maven.compiler.source}} and {{maven.compiler.target}} were incorrectly
hard-coded with the value "1.7"; this has been replaced by the variable
$compileSource.
(2) Footnote #5 in the hbase-archetypes/README.md file has been modified to
explain that, prior to archetype creation, Maven resource filtering will
replace the $compileSource variable with the literal value of the Java version
being used for compilation.
> maven archetype: client application
> ---
>
> Key: HBASE-14877
> URL: https://issues.apache.org/jira/browse/HBASE-14877
> Project: HBase
> Issue Type: Sub-task
> Components: build, Usability
>Affects Versions: 2.0.0
>Reporter: Nick Dimiduk
>Assignee: Daniel Vimont
> Labels: archetype, beginner, maven
> Attachments: HBASE-14877-v2.patch, HBASE-14877-v3.patch,
> HBASE-14877-v4.patch, HBASE-14877-v5.patch, HBASE-14877-v6.patch,
> HBASE-14877.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15247) InclusiveStopFilter does not respect reverse Filter property
[
https://issues.apache.org/jira/browse/HBASE-15247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amal Joshy updated HBASE-15247:
---
Attachment: HBASE-15247.patch
Patch for master branch.
> InclusiveStopFilter does not respect reverse Filter property
>
>
> Key: HBASE-15247
> URL: https://issues.apache.org/jira/browse/HBASE-15247
> Project: HBase
> Issue Type: Bug
> Components: Filters
>Affects Versions: 2.0.0, 1.1.1
>Reporter: Rick Moritz
>Assignee: Amal Joshy
> Fix For: 2.0.0, 1.1.1
>
> Attachments: HBASE-15247.patch
>
>
> InclusiveStopFilter only works with non-reversed Scans, it will not filter
> for reversed Scans, because it doesn't flip the cmp-operand in the reversed
> case. In fact, it doesn't even use the Filter.reverse flag.
> it should be something like this:
> if (reversed) {
> if (cmp > 0) {
> done = true;
> }
> }
> else {
> if (cmp < 0) {
> done = true;
> }
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (HBASE-15128) Disable region splits and merges switch in master
[
https://issues.apache.org/jira/browse/HBASE-15128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Heng Chen updated HBASE-15128:
--
Comment: was deleted
(was: | (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
49s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 18s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 25s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 9m
49s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
50s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green} 0m
58s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
23s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 1s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 11s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 0m 15s
{color} | {color:red} hbase-client in the patch failed. {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 0m 24s
{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m 22s
{color} | {color:red} hbase-server in the patch failed with JDK v1.8.0_72.
{color} |
| {color:red}-1{color} | {color:red} cc {color} | {color:red} 0m 22s {color} |
{color:red} hbase-server in the patch failed with JDK v1.8.0_72. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 22s {color}
| {color:red} hbase-server in the patch failed with JDK v1.8.0_72. {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m 23s
{color} | {color:red} hbase-server in the patch failed with JDK v1.7.0_95.
{color} |
| {color:red}-1{color} | {color:red} cc {color} | {color:red} 0m 23s {color} |
{color:red} hbase-server in the patch failed with JDK v1.7.0_95. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 23s {color}
| {color:red} hbase-server in the patch failed with JDK v1.7.0_95. {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m 48s
{color} | {color:red} Patch generated 5 new checkstyle issues in hbase-client
(total was 473, now 477). {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 4m 0s
{color} | {color:red} Patch generated 5 new checkstyle issues in hbase-server
(total was 338, now 342). {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
49s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} rubocop {color} | {color:red} 0m 10s
{color} | {color:red} The applied patch generated 20 new rubocop issues (total
was 785, now 802). {color} |
| {color:red}-1{color} | {color:red} ruby-lint {color} | {color:red} 0m 4s
{color} | {color:red} The applied patch generated 54 new ruby-lint issues
(total was 530, now 584). {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m 0s
{color} | {color:red} The patch has 5 line(s) that end in whitespace. Use git
apply --whitespace=fix. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
22m 9s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green} 0m
58s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
52s {color} | {color:green} the patch passed {color} |
| {co
[jira] [Issue Comment Deleted] (HBASE-15128) Disable region splits and merges switch in master
[
https://issues.apache.org/jira/browse/HBASE-15128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Heng Chen updated HBASE-15128:
--
Comment: was deleted
(was: | (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
13s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 41s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 41s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 10m
30s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
53s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green} 1m
2s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
44s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 59s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 16s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 0m 17s
{color} | {color:red} hbase-client in the patch failed. {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 0m 26s
{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m 22s
{color} | {color:red} hbase-server in the patch failed with JDK v1.8.0_72.
{color} |
| {color:red}-1{color} | {color:red} cc {color} | {color:red} 0m 22s {color} |
{color:red} hbase-server in the patch failed with JDK v1.8.0_72. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 22s {color}
| {color:red} hbase-server in the patch failed with JDK v1.8.0_72. {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m 26s
{color} | {color:red} hbase-server in the patch failed with JDK v1.7.0_95.
{color} |
| {color:red}-1{color} | {color:red} cc {color} | {color:red} 0m 26s {color} |
{color:red} hbase-server in the patch failed with JDK v1.7.0_95. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 26s {color}
| {color:red} hbase-server in the patch failed with JDK v1.7.0_95. {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 2m 5s
{color} | {color:red} Patch generated 5 new checkstyle issues in hbase-client
(total was 473, now 477). {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 4m 13s
{color} | {color:red} Patch generated 5 new checkstyle issues in hbase-server
(total was 338, now 342). {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
52s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} rubocop {color} | {color:red} 0m 10s
{color} | {color:red} The applied patch generated 38 new rubocop issues (total
was 785, now 820). {color} |
| {color:red}-1{color} | {color:red} ruby-lint {color} | {color:red} 0m 5s
{color} | {color:red} The applied patch generated 54 new ruby-lint issues
(total was 530, now 584). {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m 0s
{color} | {color:red} The patch has 5 line(s) that end in whitespace. Use git
apply --whitespace=fix. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
24m 19s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green} 1m
1s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 2m 18s
{color} | {color:red} hbase-server introduced 1 new FindBugs
[jira] [Updated] (HBASE-15247) InclusiveStopFilter does not respect reverse Filter property
[
https://issues.apache.org/jira/browse/HBASE-15247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amal Joshy updated HBASE-15247:
---
Status: Open (was: Patch Available)
> InclusiveStopFilter does not respect reverse Filter property
>
>
> Key: HBASE-15247
> URL: https://issues.apache.org/jira/browse/HBASE-15247
> Project: HBase
> Issue Type: Bug
> Components: Filters
>Affects Versions: 1.1.1, 2.0.0
>Reporter: Rick Moritz
>Assignee: Amal Joshy
> Fix For: 2.0.0, 1.1.1
>
>
> InclusiveStopFilter only works with non-reversed Scans, it will not filter
> for reversed Scans, because it doesn't flip the cmp-operand in the reversed
> case. In fact, it doesn't even use the Filter.reverse flag.
> it should be something like this:
> if (reversed) {
> if (cmp > 0) {
> done = true;
> }
> }
> else {
> if (cmp < 0) {
> done = true;
> }
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15247) InclusiveStopFilter does not respect reverse Filter property
[
https://issues.apache.org/jira/browse/HBASE-15247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amal Joshy updated HBASE-15247:
---
Fix Version/s: 1.1.1
2.0.0
Affects Version/s: 2.0.0
Status: Patch Available (was: Open)
> InclusiveStopFilter does not respect reverse Filter property
>
>
> Key: HBASE-15247
> URL: https://issues.apache.org/jira/browse/HBASE-15247
> Project: HBase
> Issue Type: Bug
> Components: Filters
>Affects Versions: 1.1.1, 2.0.0
>Reporter: Rick Moritz
>Assignee: Amal Joshy
> Fix For: 2.0.0, 1.1.1
>
>
> InclusiveStopFilter only works with non-reversed Scans, it will not filter
> for reversed Scans, because it doesn't flip the cmp-operand in the reversed
> case. In fact, it doesn't even use the Filter.reverse flag.
> it should be something like this:
> if (reversed) {
> if (cmp > 0) {
> done = true;
> }
> }
> else {
> if (cmp < 0) {
> done = true;
> }
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-14877) maven archetype: client application
[ https://issues.apache.org/jira/browse/HBASE-14877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Vimont updated HBASE-14877: -- Attachment: HBASE-14877-v6.patch > maven archetype: client application > --- > > Key: HBASE-14877 > URL: https://issues.apache.org/jira/browse/HBASE-14877 > Project: HBase > Issue Type: Sub-task > Components: build, Usability >Affects Versions: 2.0.0 >Reporter: Nick Dimiduk >Assignee: Daniel Vimont > Labels: archetype, beginner, maven > Attachments: HBASE-14877-v2.patch, HBASE-14877-v3.patch, > HBASE-14877-v4.patch, HBASE-14877-v5.patch, HBASE-14877-v6.patch, > HBASE-14877.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14877) maven archetype: client application
[ https://issues.apache.org/jira/browse/HBASE-14877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Vimont updated HBASE-14877: -- Status: Open (was: Patch Available) > maven archetype: client application > --- > > Key: HBASE-14877 > URL: https://issues.apache.org/jira/browse/HBASE-14877 > Project: HBase > Issue Type: Sub-task > Components: build, Usability >Affects Versions: 2.0.0 >Reporter: Nick Dimiduk >Assignee: Daniel Vimont > Labels: archetype, beginner, maven > Attachments: HBASE-14877-v2.patch, HBASE-14877-v3.patch, > HBASE-14877-v4.patch, HBASE-14877-v5.patch, HBASE-14877-v6.patch, > HBASE-14877.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15128) Disable region splits and merges switch in master
[
https://issues.apache.org/jira/browse/HBASE-15128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15153782#comment-15153782
]
Hadoop QA commented on HBASE-15128:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
49s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 18s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 25s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 9m
49s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
50s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green} 0m
58s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
23s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 1s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 11s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 0m 15s
{color} | {color:red} hbase-client in the patch failed. {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 0m 24s
{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m 22s
{color} | {color:red} hbase-server in the patch failed with JDK v1.8.0_72.
{color} |
| {color:red}-1{color} | {color:red} cc {color} | {color:red} 0m 22s {color} |
{color:red} hbase-server in the patch failed with JDK v1.8.0_72. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 22s {color}
| {color:red} hbase-server in the patch failed with JDK v1.8.0_72. {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m 23s
{color} | {color:red} hbase-server in the patch failed with JDK v1.7.0_95.
{color} |
| {color:red}-1{color} | {color:red} cc {color} | {color:red} 0m 23s {color} |
{color:red} hbase-server in the patch failed with JDK v1.7.0_95. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 23s {color}
| {color:red} hbase-server in the patch failed with JDK v1.7.0_95. {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m 48s
{color} | {color:red} Patch generated 5 new checkstyle issues in hbase-client
(total was 473, now 477). {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 4m 0s
{color} | {color:red} Patch generated 5 new checkstyle issues in hbase-server
(total was 338, now 342). {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
49s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} rubocop {color} | {color:red} 0m 10s
{color} | {color:red} The applied patch generated 20 new rubocop issues (total
was 785, now 802). {color} |
| {color:red}-1{color} | {color:red} ruby-lint {color} | {color:red} 0m 4s
{color} | {color:red} The applied patch generated 54 new ruby-lint issues
(total was 530, now 584). {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m 0s
{color} | {color:red} The patch has 5 line(s) that end in whitespace. Use git
apply --whitespace=fix. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
22m 9s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green} 0m
58s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
52s {color} | {color:green} the pa
[jira] [Updated] (HBASE-15290) Hbase Rest CheckAndAPI should save other cells along with compared cell
[ https://issues.apache.org/jira/browse/HBASE-15290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ajith updated HBASE-15290: -- Attachment: checkputfix2.patch Attached is the patch that has the fix for the bug. > Hbase Rest CheckAndAPI should save other cells along with compared cell > --- > > Key: HBASE-15290 > URL: https://issues.apache.org/jira/browse/HBASE-15290 > Project: HBase > Issue Type: Bug > Components: hbase >Affects Versions: 1.1.1 > Environment: Linux and windows >Reporter: Ajith > Labels: easyfix > Attachments: checkputfix2.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > Java CheckAndPut API allows users to save Cells (C1..C5) while comparing a > Cell C1. > But in Rest API, even though caller sent multiple cells, hbase rest code is > ignoring all the cells except for compare cell. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-15290) Hbase Rest CheckAndAPI should save other cells along with compared cell
Ajith created HBASE-15290: - Summary: Hbase Rest CheckAndAPI should save other cells along with compared cell Key: HBASE-15290 URL: https://issues.apache.org/jira/browse/HBASE-15290 Project: HBase Issue Type: Bug Components: hbase Affects Versions: 1.1.1 Environment: Linux and windows Reporter: Ajith Java CheckAndPut API allows users to save Cells (C1..C5) while comparing a Cell C1. But in Rest API, even though caller sent multiple cells, hbase rest code is ignoring all the cells except for compare cell. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-9393) Hbase does not closing a closed socket resulting in many CLOSE_WAIT
[ https://issues.apache.org/jira/browse/HBASE-9393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashish Singhi updated HBASE-9393: - Attachment: HBASE-9393.v12.patch Patch addressing Ted's comment. Please review. > Hbase does not closing a closed socket resulting in many CLOSE_WAIT > > > Key: HBASE-9393 > URL: https://issues.apache.org/jira/browse/HBASE-9393 > Project: HBase > Issue Type: Bug >Affects Versions: 0.94.2, 0.98.0 > Environment: Centos 6.4 - 7 regionservers/datanodes, 8 TB per node, > 7279 regions >Reporter: Avi Zrachya >Assignee: Ashish Singhi >Priority: Critical > Fix For: 2.0.0 > > Attachments: HBASE-9393.patch, HBASE-9393.v1.patch, > HBASE-9393.v10.patch, HBASE-9393.v11.patch, HBASE-9393.v12.patch, > HBASE-9393.v2.patch, HBASE-9393.v3.patch, HBASE-9393.v4.patch, > HBASE-9393.v5.patch, HBASE-9393.v5.patch, HBASE-9393.v5.patch, > HBASE-9393.v6.patch, HBASE-9393.v6.patch, HBASE-9393.v6.patch, > HBASE-9393.v7.patch, HBASE-9393.v8.patch, HBASE-9393.v9.patch > > > HBase dose not close a dead connection with the datanode. > This resulting in over 60K CLOSE_WAIT and at some point HBase can not connect > to the datanode because too many mapped sockets from one host to another on > the same port. > The example below is with low CLOSE_WAIT count because we had to restart > hbase to solve the porblem, later in time it will incease to 60-100K sockets > on CLOSE_WAIT > [root@hd2-region3 ~]# netstat -nap |grep CLOSE_WAIT |grep 21592 |wc -l > 13156 > [root@hd2-region3 ~]# ps -ef |grep 21592 > root 17255 17219 0 12:26 pts/000:00:00 grep 21592 > hbase21592 1 17 Aug29 ?03:29:06 > /usr/java/jdk1.6.0_26/bin/java -XX:OnOutOfMemoryError=kill -9 %p -Xmx8000m > -ea -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode > -Dhbase.log.dir=/var/log/hbase > -Dhbase.log.file=hbase-hbase-regionserver-hd2-region3.swnet.corp.log ... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15222) Use HDR histograms rather than hadoop or yammer's
[
https://issues.apache.org/jira/browse/HBASE-15222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15153751#comment-15153751
]
Hadoop QA commented on HBASE-15222:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 1s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s
{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
20s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m 43s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m 47s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 18m
41s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 2m
0s {color} | {color:green} master passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 9m 5s
{color} | {color:red} branch/. no findbugs output file
(./target/findbugsXml.xml) {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m 19s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m 56s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
32s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m 40s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 3m 40s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m 50s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 3m 50s
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 12m 38s
{color} | {color:red} Patch generated 8 new checkstyle issues in root (total
was 244, now 230). {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m 7s
{color} | {color:red} Patch generated 1 new checkstyle issues in hbase-common
(total was 1, now 2). {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m 15s
{color} | {color:red} Patch generated 3 new checkstyle issues in
hbase-hadoop2-compat (total was 48, now 32). {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 4m 1s
{color} | {color:red} Patch generated 4 new checkstyle issues in hbase-server
(total was 194, now 195). {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 2m
29s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m 0s
{color} | {color:red} The patch has 1 line(s) that end in whitespace. Use git
apply --whitespace=fix. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m 2s
{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
30m 27s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 10m 37s
{color} | {color:red} patch/. no findbugs output file
(./target/findbugsXml.xml) {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m 57s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 4m 42s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 90m 35s {color}
| {color:red} root in the patch failed with JD
[jira] [Commented] (HBASE-9393) Hbase does not closing a closed socket resulting in many CLOSE_WAIT
[ https://issues.apache.org/jira/browse/HBASE-9393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15153740#comment-15153740 ] Ashish Singhi commented on HBASE-9393: -- That I added for extra protection if its still null we can do it another time. Now I feel its not required. Will attach a patch in a short time. Thanks for the review. > Hbase does not closing a closed socket resulting in many CLOSE_WAIT > > > Key: HBASE-9393 > URL: https://issues.apache.org/jira/browse/HBASE-9393 > Project: HBase > Issue Type: Bug >Affects Versions: 0.94.2, 0.98.0 > Environment: Centos 6.4 - 7 regionservers/datanodes, 8 TB per node, > 7279 regions >Reporter: Avi Zrachya >Assignee: Ashish Singhi >Priority: Critical > Fix For: 2.0.0 > > Attachments: HBASE-9393.patch, HBASE-9393.v1.patch, > HBASE-9393.v10.patch, HBASE-9393.v11.patch, HBASE-9393.v2.patch, > HBASE-9393.v3.patch, HBASE-9393.v4.patch, HBASE-9393.v5.patch, > HBASE-9393.v5.patch, HBASE-9393.v5.patch, HBASE-9393.v6.patch, > HBASE-9393.v6.patch, HBASE-9393.v6.patch, HBASE-9393.v7.patch, > HBASE-9393.v8.patch, HBASE-9393.v9.patch > > > HBase dose not close a dead connection with the datanode. > This resulting in over 60K CLOSE_WAIT and at some point HBase can not connect > to the datanode because too many mapped sockets from one host to another on > the same port. > The example below is with low CLOSE_WAIT count because we had to restart > hbase to solve the porblem, later in time it will incease to 60-100K sockets > on CLOSE_WAIT > [root@hd2-region3 ~]# netstat -nap |grep CLOSE_WAIT |grep 21592 |wc -l > 13156 > [root@hd2-region3 ~]# ps -ef |grep 21592 > root 17255 17219 0 12:26 pts/000:00:00 grep 21592 > hbase21592 1 17 Aug29 ?03:29:06 > /usr/java/jdk1.6.0_26/bin/java -XX:OnOutOfMemoryError=kill -9 %p -Xmx8000m > -ea -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode > -Dhbase.log.dir=/var/log/hbase > -Dhbase.log.file=hbase-hbase-regionserver-hd2-region3.swnet.corp.log ... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15180) Reduce garbage created while reading Cells from Codec Decoder
[ https://issues.apache.org/jira/browse/HBASE-15180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15153715#comment-15153715 ] Anoop Sam John commented on HBASE-15180: Dropped branch-1 based fixed versions. Adding new method into Codec is fine there? Even if, we may change BB to new type in 2.0 later. So better we won't add any thing. > Reduce garbage created while reading Cells from Codec Decoder > - > > Key: HBASE-15180 > URL: https://issues.apache.org/jira/browse/HBASE-15180 > Project: HBase > Issue Type: Sub-task > Components: regionserver >Affects Versions: 0.98.0 >Reporter: Anoop Sam John >Assignee: Anoop Sam John > Fix For: 2.0.0 > > Attachments: HBASE-15180.patch, HBASE-15180_V2.patch, > HBASE-15180_V4.patch, HBASE-15180_V6.patch > > > In KeyValueDecoder#parseCell (Default Codec decoder) we use > KeyValueUtil#iscreate to read cells from the InputStream. Here we 1st create > a byte[] of length 4 and read the cell length and then an array of Cell's > length and read in cell bytes into it and create a KV. > Actually in server we read the reqs into a byte[] and CellScanner is created > on top of a ByteArrayInputStream on top of this. By default in write path, we > have MSLAB usage ON. So while adding Cells to memstore, we will copy the Cell > bytes to MSLAB memory chunks (default 2 MB size) and recreate Cells over that > bytes. So there is no issue if we create Cells over the RPC read byte[] > directly here in Decoder. No need for 2 byte[] creation and copy for every > Cell in request. > My plan is to make a Cell aware ByteArrayInputStream which can read Cells > directly from it. > Same Codec path is used in client side also. There better we can avoid this > direct Cell create and continue to do the copy to smaller byte[]s path. Plan > to introduce some thing like a CodecContext associated with every Codec > instance which can say the server/client context. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15180) Reduce garbage created while reading Cells from Codec Decoder
[ https://issues.apache.org/jira/browse/HBASE-15180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anoop Sam John updated HBASE-15180: --- Attachment: HBASE-15180_V6.patch > Reduce garbage created while reading Cells from Codec Decoder > - > > Key: HBASE-15180 > URL: https://issues.apache.org/jira/browse/HBASE-15180 > Project: HBase > Issue Type: Sub-task > Components: regionserver >Affects Versions: 0.98.0 >Reporter: Anoop Sam John >Assignee: Anoop Sam John > Fix For: 2.0.0 > > Attachments: HBASE-15180.patch, HBASE-15180_V2.patch, > HBASE-15180_V4.patch, HBASE-15180_V6.patch > > > In KeyValueDecoder#parseCell (Default Codec decoder) we use > KeyValueUtil#iscreate to read cells from the InputStream. Here we 1st create > a byte[] of length 4 and read the cell length and then an array of Cell's > length and read in cell bytes into it and create a KV. > Actually in server we read the reqs into a byte[] and CellScanner is created > on top of a ByteArrayInputStream on top of this. By default in write path, we > have MSLAB usage ON. So while adding Cells to memstore, we will copy the Cell > bytes to MSLAB memory chunks (default 2 MB size) and recreate Cells over that > bytes. So there is no issue if we create Cells over the RPC read byte[] > directly here in Decoder. No need for 2 byte[] creation and copy for every > Cell in request. > My plan is to make a Cell aware ByteArrayInputStream which can read Cells > directly from it. > Same Codec path is used in client side also. There better we can avoid this > direct Cell create and continue to do the copy to smaller byte[]s path. Plan > to introduce some thing like a CodecContext associated with every Codec > instance which can say the server/client context. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15180) Reduce garbage created while reading Cells from Codec Decoder
[ https://issues.apache.org/jira/browse/HBASE-15180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15153713#comment-15153713 ] Anoop Sam John commented on HBASE-15180: bq.maybe it is best to cut to BB? Or, your Interface that does BB – ByteBuff? Something to consider. Ok.. Add getDecoder() with BB as of now.. Later we need change to new interface type, we can change then. So this fix will go into 2.0 only. So before 2.0 is out, we will make the change of BB to new type as needed. > Reduce garbage created while reading Cells from Codec Decoder > - > > Key: HBASE-15180 > URL: https://issues.apache.org/jira/browse/HBASE-15180 > Project: HBase > Issue Type: Sub-task > Components: regionserver >Affects Versions: 0.98.0 >Reporter: Anoop Sam John >Assignee: Anoop Sam John > Fix For: 2.0.0 > > Attachments: HBASE-15180.patch, HBASE-15180_V2.patch, > HBASE-15180_V4.patch > > > In KeyValueDecoder#parseCell (Default Codec decoder) we use > KeyValueUtil#iscreate to read cells from the InputStream. Here we 1st create > a byte[] of length 4 and read the cell length and then an array of Cell's > length and read in cell bytes into it and create a KV. > Actually in server we read the reqs into a byte[] and CellScanner is created > on top of a ByteArrayInputStream on top of this. By default in write path, we > have MSLAB usage ON. So while adding Cells to memstore, we will copy the Cell > bytes to MSLAB memory chunks (default 2 MB size) and recreate Cells over that > bytes. So there is no issue if we create Cells over the RPC read byte[] > directly here in Decoder. No need for 2 byte[] creation and copy for every > Cell in request. > My plan is to make a Cell aware ByteArrayInputStream which can read Cells > directly from it. > Same Codec path is used in client side also. There better we can avoid this > direct Cell create and continue to do the copy to smaller byte[]s path. Plan > to introduce some thing like a CodecContext associated with every Codec > instance which can say the server/client context. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15180) Reduce garbage created while reading Cells from Codec Decoder
[ https://issues.apache.org/jira/browse/HBASE-15180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anoop Sam John updated HBASE-15180: --- Fix Version/s: (was: 1.2.1) (was: 1.3.0) > Reduce garbage created while reading Cells from Codec Decoder > - > > Key: HBASE-15180 > URL: https://issues.apache.org/jira/browse/HBASE-15180 > Project: HBase > Issue Type: Sub-task > Components: regionserver >Affects Versions: 0.98.0 >Reporter: Anoop Sam John >Assignee: Anoop Sam John > Fix For: 2.0.0 > > Attachments: HBASE-15180.patch, HBASE-15180_V2.patch, > HBASE-15180_V4.patch > > > In KeyValueDecoder#parseCell (Default Codec decoder) we use > KeyValueUtil#iscreate to read cells from the InputStream. Here we 1st create > a byte[] of length 4 and read the cell length and then an array of Cell's > length and read in cell bytes into it and create a KV. > Actually in server we read the reqs into a byte[] and CellScanner is created > on top of a ByteArrayInputStream on top of this. By default in write path, we > have MSLAB usage ON. So while adding Cells to memstore, we will copy the Cell > bytes to MSLAB memory chunks (default 2 MB size) and recreate Cells over that > bytes. So there is no issue if we create Cells over the RPC read byte[] > directly here in Decoder. No need for 2 byte[] creation and copy for every > Cell in request. > My plan is to make a Cell aware ByteArrayInputStream which can read Cells > directly from it. > Same Codec path is used in client side also. There better we can avoid this > direct Cell create and continue to do the copy to smaller byte[]s path. Plan > to introduce some thing like a CodecContext associated with every Codec > instance which can say the server/client context. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15128) Disable region splits and merges switch in master
[ https://issues.apache.org/jira/browse/HBASE-15128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Heng Chen updated HBASE-15128: -- Attachment: HBASE-15128_v6.patch Fix java doc and findbugs. And i fix some of ruby checkstyle errors, the others leaves because i follow the script style existed and not sure whether fix them or not. > Disable region splits and merges switch in master > - > > Key: HBASE-15128 > URL: https://issues.apache.org/jira/browse/HBASE-15128 > Project: HBase > Issue Type: Bug >Reporter: Enis Soztutar >Assignee: Heng Chen > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-15128.patch, HBASE-15128_v1.patch, > HBASE-15128_v3.patch, HBASE-15128_v5.patch, HBASE-15128_v6.patch > > > In large clusters where region splits are frequent, and HBCK runs take > longer, the concurrent splits cause further problems in HBCK since HBCK > assumes a static state for the region partition map. We have just seen a case > where HBCK undo's a concurrently splitting region causing number of > inconsistencies to go up. > We can have a mode in master where splits and merges are disabled like the > balancer and catalog janitor switches. Master will reject the split requests > if regionservers decide to split. This switch can be turned on / off by the > admins and also automatically by HBCK while it is running (similar to > balancer switch being disabled by HBCK). > HBCK should also disable the Catalog Janitor just in case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15264) Implement a fan out HDFS OutputStream
[ https://issues.apache.org/jira/browse/HBASE-15264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-15264: -- Fix Version/s: 2.0.0 Component/s: wal util Only in 2.0 first? [~stack] > Implement a fan out HDFS OutputStream > - > > Key: HBASE-15264 > URL: https://issues.apache.org/jira/browse/HBASE-15264 > Project: HBase > Issue Type: Sub-task > Components: util, wal >Reporter: Duo Zhang >Assignee: Duo Zhang > Fix For: 2.0.0 > > Attachments: HBASE-15264-v1.patch, HBASE-15264-v2.patch, > HBASE-15264-v3.patch, HBASE-15264-v4.patch, HBASE-15264.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15265) Implement an asynchronous FSHLog
[
https://issues.apache.org/jira/browse/HBASE-15265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15153676#comment-15153676
]
Duo Zhang commented on HBASE-15265:
---
There are two problems here, so the comments of this test file.
https://github.com/Apache9/hbase/blob/HBASE-15265/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/wal/TestAsyncLogRolling.java
First, {{FanOutOneBlockAsyncDFSOutput}} is fail-fast, which means the creation
is fail-fast too. But in the current log rolling architecture, we will abort RS
if log rolling failed. For the old {{FSHLog}} implementation, {{DFSClient}} and
{{DFSOutputStream}} have done a lot of retries when calling namenode failed or
connecting datanode failed so it is not a problem, but now we just throw
exception out so... We need to solve this, may change the abort logic of
{{LogRoller}} or add retry in {{AsyncFSWAL}}?
Second, AsyncFSWAL will not fail any sync request, instead, it will try rolling
the WALWriter and try again. But in testcase, this could lead to an infinite
waiting when shutdown. The shutdown timing is a little strange. We first mark
RS as stopped, and then close all regions on this RS. And if the abort flag is
false, we will flush the region and need to write something to WAL. If the WAL
writer is broken just at this time, {{AsyncFSWAL}} will try rolling the WAL
writer. But as said above, RS is marked as stopped, so LogRoller may have
already exited, the rolling will never success and the shutdown process hang...
Yes, I think {{AsyncFSWAL}} should have the ability to quit the infinite
waiting since we know that it will never success, but also I think we should
revisit the shutdown timing since lots of modules in RS is depending on the
stopped flag of RS.
Thanks.
> Implement an asynchronous FSHLog
>
>
> Key: HBASE-15265
> URL: https://issues.apache.org/jira/browse/HBASE-15265
> Project: HBase
> Issue Type: Sub-task
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15136) Explore different queuing behaviors while busy
[
https://issues.apache.org/jira/browse/HBASE-15136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15153670#comment-15153670
]
Hadoop QA commented on HBASE-15136:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
33s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m 3s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 55s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 9m
35s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
21s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m
52s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 5s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 11s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 0m 15s
{color} | {color:red} hbase-hadoop2-compat in the patch failed. {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 0m 32s
{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m 1s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m 1s
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m 32s
{color} | {color:red} hbase-server in the patch failed with JDK v1.7.0_95.
{color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 32s {color}
| {color:red} hbase-server in the patch failed with JDK v1.7.0_95. {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 2m 30s
{color} | {color:red} Patch generated 1 new checkstyle issues in hbase-client
(total was 0, now 1). {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 4m 59s
{color} | {color:red} Patch generated 2 new checkstyle issues in hbase-server
(total was 15, now 17). {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
16s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 1m 18s
{color} | {color:red} Patch causes 52 errors with Hadoop v2.4.0. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 2m 31s
{color} | {color:red} Patch causes 52 errors with Hadoop v2.4.1. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 3m 42s
{color} | {color:red} Patch causes 52 errors with Hadoop v2.5.0. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 4m 53s
{color} | {color:red} Patch causes 52 errors with Hadoop v2.5.1. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 6m 4s
{color} | {color:red} Patch causes 52 errors with Hadoop v2.5.2. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 7m 12s
{color} | {color:red} Patch causes 52 errors with Hadoop v2.6.1. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 8m 24s
{color} | {color:red} Patch causes 52 errors with Hadoop v2.6.2. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 9m 38s
{color} | {color:red} Patch causes 52 errors with Hadoop v2.6.3. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 10m 50s
{color} | {color:red} Patch causes 52 errors with Ha
[jira] [Updated] (HBASE-15264) Implement a fan out HDFS OutputStream
[ https://issues.apache.org/jira/browse/HBASE-15264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-15264: -- Attachment: HBASE-15264-v4.patch Simple change for implementing HBASE-15265. > Implement a fan out HDFS OutputStream > - > > Key: HBASE-15264 > URL: https://issues.apache.org/jira/browse/HBASE-15264 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Assignee: Duo Zhang > Attachments: HBASE-15264-v1.patch, HBASE-15264-v2.patch, > HBASE-15264-v3.patch, HBASE-15264-v4.patch, HBASE-15264.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14123) HBase Backup/Restore Phase 2
[ https://issues.apache.org/jira/browse/HBASE-14123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15153616#comment-15153616 ] Vladimir Rodionov commented on HBASE-14123: --- HBASE-14123 is based on the recent HBASE-14030 patch (patch on top of a patch). > HBase Backup/Restore Phase 2 > > > Key: HBASE-14123 > URL: https://issues.apache.org/jira/browse/HBASE-14123 > Project: HBase > Issue Type: Umbrella >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Attachments: HBASE-14123-v1.patch, HBASE-14123-v2.patch, > HBASE-14123-v3.patch, HBASE-14123-v4.patch, HBASE-14123-v5.patch, > HBASE-14123-v6.patch, HBASE-14123-v7.patch > > > Phase 2 umbrella JIRA. See HBASE-7912 for design document and description. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14123) HBase Backup/Restore Phase 2
[ https://issues.apache.org/jira/browse/HBASE-14123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15153614#comment-15153614 ] Vladimir Rodionov commented on HBASE-14123: --- Hmm. HBASE-14030 is still in review mode. Let us wait until it is complete and committed. > HBase Backup/Restore Phase 2 > > > Key: HBASE-14123 > URL: https://issues.apache.org/jira/browse/HBASE-14123 > Project: HBase > Issue Type: Umbrella >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Attachments: HBASE-14123-v1.patch, HBASE-14123-v2.patch, > HBASE-14123-v3.patch, HBASE-14123-v4.patch, HBASE-14123-v5.patch, > HBASE-14123-v6.patch, HBASE-14123-v7.patch > > > Phase 2 umbrella JIRA. See HBASE-7912 for design document and description. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14703) not collect stats when call HTable.mutateRow
[ https://issues.apache.org/jira/browse/HBASE-14703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15153602#comment-15153602 ] Heng Chen commented on HBASE-14703: --- Welcome back, i will rebase it today, :) > not collect stats when call HTable.mutateRow > - > > Key: HBASE-14703 > URL: https://issues.apache.org/jira/browse/HBASE-14703 > Project: HBase > Issue Type: Bug >Reporter: Heng Chen >Assignee: Heng Chen > Fix For: 2.0.0 > > Attachments: HBASE-14702_v5.2_addendum-addendum.patch, > HBASE-14703-5.2-addendum.patch, HBASE-14703-async.patch, > HBASE-14703-start.patch, HBASE-14703-v4.1.patch, HBASE-14703-v4.patch, > HBASE-14703-v6_with-check-and-mutate.patch, HBASE-14703.patch, > HBASE-14703_v1.patch, HBASE-14703_v10.patch, HBASE-14703_v10.patch, > HBASE-14703_v2.patch, HBASE-14703_v3.patch, HBASE-14703_v5.1.patch, > HBASE-14703_v5.2.patch, HBASE-14703_v5.patch, HBASE-14703_v6-addendum.patch, > HBASE-14703_v6.patch, HBASE-14703_v7.patch, HBASE-14703_v8.patch, > HBASE-14703_v9.patch > > > We are trying to fix the stats implementation, by moving it out of the Result > object and into an Rpc payload (but not the 'cell payload', just as part of > the values returned from the request). This change will also us use easily > switch to AsyncProcess as the executor, and support stats, for nearly all the > rpc calls. However, that means when you upgrade the client or server, you > will lose stats visibility until the other side is upgraded. We could keep > around the Result based stats storage to accommodate the old api and send > both stats back from the server (in each result and in the rpc payload). > Note that we will still be wire compatible - protobufs mean we can just ride > over the lack of information. > The other tricky part of this is that Result has a > non-InterfaceAudience.Private getStatistics() method (along with two > InterfaceAudience.Private addResults and setStatistics methods), so we might > need a release to deprecate the getStats() method before throwing it out? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14703) not collect stats when call HTable.mutateRow
[ https://issues.apache.org/jira/browse/HBASE-14703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15153591#comment-15153591 ] Jesse Yates commented on HBASE-14703: - Sorry [~chenheng] - fell off my queue. Thanks for the reminder. Promise I will look at it this weekend. > not collect stats when call HTable.mutateRow > - > > Key: HBASE-14703 > URL: https://issues.apache.org/jira/browse/HBASE-14703 > Project: HBase > Issue Type: Bug >Reporter: Heng Chen >Assignee: Heng Chen > Fix For: 2.0.0 > > Attachments: HBASE-14702_v5.2_addendum-addendum.patch, > HBASE-14703-5.2-addendum.patch, HBASE-14703-async.patch, > HBASE-14703-start.patch, HBASE-14703-v4.1.patch, HBASE-14703-v4.patch, > HBASE-14703-v6_with-check-and-mutate.patch, HBASE-14703.patch, > HBASE-14703_v1.patch, HBASE-14703_v10.patch, HBASE-14703_v10.patch, > HBASE-14703_v2.patch, HBASE-14703_v3.patch, HBASE-14703_v5.1.patch, > HBASE-14703_v5.2.patch, HBASE-14703_v5.patch, HBASE-14703_v6-addendum.patch, > HBASE-14703_v6.patch, HBASE-14703_v7.patch, HBASE-14703_v8.patch, > HBASE-14703_v9.patch > > > We are trying to fix the stats implementation, by moving it out of the Result > object and into an Rpc payload (but not the 'cell payload', just as part of > the values returned from the request). This change will also us use easily > switch to AsyncProcess as the executor, and support stats, for nearly all the > rpc calls. However, that means when you upgrade the client or server, you > will lose stats visibility until the other side is upgraded. We could keep > around the Result based stats storage to accommodate the old api and send > both stats back from the server (in each result and in the rpc payload). > Note that we will still be wire compatible - protobufs mean we can just ride > over the lack of information. > The other tricky part of this is that Result has a > non-InterfaceAudience.Private getStatistics() method (along with two > InterfaceAudience.Private addResults and setStatistics methods), so we might > need a release to deprecate the getStats() method before throwing it out? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14123) HBase Backup/Restore Phase 2
[ https://issues.apache.org/jira/browse/HBASE-14123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15153588#comment-15153588 ] Ted Yu commented on HBASE-14123: Can you put the patch on review board ? Thanks > HBase Backup/Restore Phase 2 > > > Key: HBASE-14123 > URL: https://issues.apache.org/jira/browse/HBASE-14123 > Project: HBase > Issue Type: Umbrella >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Attachments: HBASE-14123-v1.patch, HBASE-14123-v2.patch, > HBASE-14123-v3.patch, HBASE-14123-v4.patch, HBASE-14123-v5.patch, > HBASE-14123-v6.patch, HBASE-14123-v7.patch > > > Phase 2 umbrella JIRA. See HBASE-7912 for design document and description. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (HBASE-14450) HBase Backup/Restore Phase 2: Multiwal support
[ https://issues.apache.org/jira/browse/HBASE-14450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov resolved HBASE-14450. --- Resolution: Fixed Part of HBASE-14123 v7 patch. > HBase Backup/Restore Phase 2: Multiwal support > -- > > Key: HBASE-14450 > URL: https://issues.apache.org/jira/browse/HBASE-14450 > Project: HBase > Issue Type: Task >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Fix For: 2.0.0 > > > We need support multiwal configurations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14123) HBase Backup/Restore Phase 2
[ https://issues.apache.org/jira/browse/HBASE-14123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-14123: -- Attachment: HBASE-14123-v7.patch Patch v7 (includes MultiWAL support) > HBase Backup/Restore Phase 2 > > > Key: HBASE-14123 > URL: https://issues.apache.org/jira/browse/HBASE-14123 > Project: HBase > Issue Type: Umbrella >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Attachments: HBASE-14123-v1.patch, HBASE-14123-v2.patch, > HBASE-14123-v3.patch, HBASE-14123-v4.patch, HBASE-14123-v5.patch, > HBASE-14123-v6.patch, HBASE-14123-v7.patch > > > Phase 2 umbrella JIRA. See HBASE-7912 for design document and description. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15289) Add details about how to get usage instructions for Import and Export utilities
[
https://issues.apache.org/jira/browse/HBASE-15289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15153573#comment-15153573
]
Hadoop QA commented on HBASE-15289:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s
{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
2s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
6s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 6s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 27s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
37s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
6s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m 1s
{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
24m 36s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 2s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 31s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 122m 7s {color}
| {color:red} root in the patch failed with JDK v1.8.0_72. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 114m 26s
{color} | {color:green} root in the patch passed with JDK v1.7.0_95. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
22s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 290m 38s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| JDK v1.8.0_72 Failed junit tests | hadoop.hbase.client.TestCheckAndMutate |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.9.1 Server=1.9.1 Image:yetus/hbase:date2016-02-18 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12788532/HBASE-15289.patch |
| JIRA Issue | HBASE-15289 |
| Optional Tests | asflicense javac javadoc unit xml |
| uname | Linux dbc7397ac733 3.13.0-36-lowlatency #63-Ubuntu SMP PREEMPT Wed
Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / d2ba875 |
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/592/artifact/patchprocess/patch-unit-root-jdk1.8.0_72.txt
|
| unit test logs |
https://builds.apache.org/job/PreCommit-HBASE-Build/592/artifact/patchprocess/patch-unit-root-jdk1.8.0_72.txt
|
| JDK v1.7.0_95 Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/592/testReport/ |
| modules | C: . U: . |
| Max memory used | 175MB |
| Powered by | Apache Yetus 0.1.0 http://yetus.apache.org |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/592/console |
This message was automatically generated.
> Add details about how to get usage instructions for Import and Export
> utilities
> ---
>
> Key: HBASE-15289
> URL: https://issues.apache.org/jira/browse/HBASE-15289
> Project: HBase
> Issue Type: Bug
> Components: documentation
>Affects Versions: 2.0.0
>Reporter: Misty Stanley-Jones
>Assignee: Misty Stanley-Jones
> Labels: new
[jira] [Updated] (HBASE-15222) Use HDR histograms rather than hadoop or yammer's
[ https://issues.apache.org/jira/browse/HBASE-15222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark updated HBASE-15222: -- Attachment: HBASE-15222-v3.patch > Use HDR histograms rather than hadoop or yammer's > - > > Key: HBASE-15222 > URL: https://issues.apache.org/jira/browse/HBASE-15222 > Project: HBase > Issue Type: Bug > Components: metrics >Affects Versions: 2.0.0, 1.2.0, 1.3.0 >Reporter: Elliott Clark >Assignee: Elliott Clark >Priority: Critical > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-15222-v1.patch, HBASE-15222-v2.patch, > HBASE-15222-v3.patch, HBASE-15222.patch > > > Running the benchmarks now, but it looks like the results are pretty extreme. > The locking in our histograms is pretty extreme. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15271) Spark Bulk Load: Need to write HFiles to tmp location then rename to protect from Spark Executor Failures
[ https://issues.apache.org/jira/browse/HBASE-15271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Malaska updated HBASE-15271: Attachment: HBASE-15271.3.patch Made changes for Ted Yu's comment > Spark Bulk Load: Need to write HFiles to tmp location then rename to protect > from Spark Executor Failures > - > > Key: HBASE-15271 > URL: https://issues.apache.org/jira/browse/HBASE-15271 > Project: HBase > Issue Type: Bug >Reporter: Ted Malaska >Assignee: Ted Malaska > Attachments: HBASE-15271.1.patch, HBASE-15271.2.patch, > HBASE-15271.3.patch > > > With the current code if an executor failure before the HFile is close it > will cause problems. This jira will have the files first write out to a file > that starts with an underscore. Then when the HFile is complete it will be > renamed and the underscore will be removed. > The underscore is important because the load bulk functionality will skip > files with an underscore. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15271) Spark Bulk Load: Need to write HFiles to tmp location then rename to protect from Spark Executor Failures
[ https://issues.apache.org/jira/browse/HBASE-15271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Malaska updated HBASE-15271: Attachment: HBASE-15271.2.patch Added change based on Ted Yu's comment > Spark Bulk Load: Need to write HFiles to tmp location then rename to protect > from Spark Executor Failures > - > > Key: HBASE-15271 > URL: https://issues.apache.org/jira/browse/HBASE-15271 > Project: HBase > Issue Type: Bug >Reporter: Ted Malaska >Assignee: Ted Malaska > Attachments: HBASE-15271.1.patch, HBASE-15271.2.patch > > > With the current code if an executor failure before the HFile is close it > will cause problems. This jira will have the files first write out to a file > that starts with an underscore. Then when the HFile is complete it will be > renamed and the underscore will be removed. > The underscore is important because the load bulk functionality will skip > files with an underscore. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (HBASE-14949) Resolve name conflict when splitting if there are duplicated WAL entries
[ https://issues.apache.org/jira/browse/HBASE-14949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang resolved HBASE-14949. --- Resolution: Fixed Release Note: Now we can write duplicated WAL entries into different WAL files. This feature is required by the replication consistency fix and new implementation of WAL writer. > Resolve name conflict when splitting if there are duplicated WAL entries > > > Key: HBASE-14949 > URL: https://issues.apache.org/jira/browse/HBASE-14949 > Project: HBase > Issue Type: Sub-task > Components: wal >Reporter: Heng Chen >Assignee: Duo Zhang > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-14949-addendum-branch-1.patch, > HBASE-14949-v3.patch, HBASE-14949-v4.patch, HBASE-14949-v5.patch, > HBASE-14949.patch, HBASE-14949_v1.patch, HBASE-14949_v2.patch > > > The AsyncFSHLog introduced in HBASE-14790 may write same WAL entries to > different WAL files. WAL entry itself is idempotent so replay is not a > problem but the intermediate file name and final name when splitting is > constructed using the lowest or highest sequence id of the WAL entries > written, so it is possible that different WAL files will have same > intermediate or final file name when splitting. In the currentm > implementation, this will cause split fail or data loss. We need to solve > this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15243) Utilize the lowest seek value when all Filters in MUST_PASS_ONE FilterList return SEEK_NEXT_USING_HINT
[ https://issues.apache.org/jira/browse/HBASE-15243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15153503#comment-15153503 ] Ted Yu commented on HBASE-15243: Any more review comment ? > Utilize the lowest seek value when all Filters in MUST_PASS_ONE FilterList > return SEEK_NEXT_USING_HINT > -- > > Key: HBASE-15243 > URL: https://issues.apache.org/jira/browse/HBASE-15243 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Assignee: Ted Yu > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-15243-v1.txt, HBASE-15243-v2.txt, > HBASE-15243-v3.txt > > > As Preston Koprivica pointed out at the tail of HBASE-4394, when all filters > in a MUST_PASS_ONE FilterList return a SEEK_USING_NEXT_HINT code, we should > return SEEK_NEXT_USING_HINT from the FilterList to utilize the lowest seek > value. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15282) Bump hbase-spark to use Spark 1.6.0
[ https://issues.apache.org/jira/browse/HBASE-15282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Hsieh updated HBASE-15282: --- Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) thanks for the reviews [~malaskat], [~vanzin]. Committed to master. > Bump hbase-spark to use Spark 1.6.0 > --- > > Key: HBASE-15282 > URL: https://issues.apache.org/jira/browse/HBASE-15282 > Project: HBase > Issue Type: Improvement > Components: spark >Affects Versions: 2.0.0 >Reporter: Jonathan Hsieh >Assignee: Jonathan Hsieh > Fix For: 2.0.0 > > Attachments: hbase-15282.patch > > > The latest stable Spark is spark 1.6. [1] > Let's bump the version. > [1] http://spark.apache.org/news/spark-1-6-0-released.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15282) Bump hbase-spark to use Spark 1.6.0
[ https://issues.apache.org/jira/browse/HBASE-15282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Hsieh updated HBASE-15282: --- Summary: Bump hbase-spark to use Spark 1.6.0 (was: Bump Spark on Hbase to use Spark 1.6.) > Bump hbase-spark to use Spark 1.6.0 > --- > > Key: HBASE-15282 > URL: https://issues.apache.org/jira/browse/HBASE-15282 > Project: HBase > Issue Type: Improvement > Components: spark >Affects Versions: 2.0.0 >Reporter: Jonathan Hsieh >Assignee: Jonathan Hsieh > Fix For: 2.0.0 > > Attachments: hbase-15282.patch > > > The latest stable Spark is spark 1.6. [1] > Let's bump the version. > [1] http://spark.apache.org/news/spark-1-6-0-released.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15282) Bump Spark on Hbase to use Spark 1.6.
[ https://issues.apache.org/jira/browse/HBASE-15282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15153484#comment-15153484 ] Ted Malaska commented on HBASE-15282: - +1 > Bump Spark on Hbase to use Spark 1.6. > - > > Key: HBASE-15282 > URL: https://issues.apache.org/jira/browse/HBASE-15282 > Project: HBase > Issue Type: Improvement > Components: spark >Affects Versions: 2.0.0 >Reporter: Jonathan Hsieh >Assignee: Jonathan Hsieh > Fix For: 2.0.0 > > Attachments: hbase-15282.patch > > > The latest stable Spark is spark 1.6. [1] > Let's bump the version. > [1] http://spark.apache.org/news/spark-1-6-0-released.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15271) Spark Bulk Load: Need to write HFiles to tmp location then rename to protect from Spark Executor Failures
[ https://issues.apache.org/jira/browse/HBASE-15271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Malaska updated HBASE-15271: Attachment: HBASE-15271.1.patch First draft. Built and ran tests > Spark Bulk Load: Need to write HFiles to tmp location then rename to protect > from Spark Executor Failures > - > > Key: HBASE-15271 > URL: https://issues.apache.org/jira/browse/HBASE-15271 > Project: HBase > Issue Type: Bug >Reporter: Ted Malaska >Assignee: Ted Malaska > Attachments: HBASE-15271.1.patch > > > With the current code if an executor failure before the HFile is close it > will cause problems. This jira will have the files first write out to a file > that starts with an underscore. Then when the HFile is complete it will be > renamed and the underscore will be removed. > The underscore is important because the load bulk functionality will skip > files with an underscore. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14877) maven archetype: client application
[
https://issues.apache.org/jira/browse/HBASE-14877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15153455#comment-15153455
]
Daniel Vimont commented on HBASE-14877:
---
Both your points relate to converting the exemplar (which SHOULD have all
proper dependencies/inheritances within the hbase project hierarchy) into a
standalone project (which needs to have all hbase project dependencies
removed/replaced before it is used to produce an archetype). The conversion of
the exemplar is elaborated upon a bit in [footnote 5 of the
README|https://github.com/dvimont/test_hbasearchetypes_readme#f5].
To address your points:
{quote}
change the java 1.7 compile source/target in the pom? should this be inherited
from hbase $compileSource?
{quote}
{color:red}YES{color}, thanks for pointing this out! You are absolutely right
that the value "1.7" should NOT be hardcoded into hbase-client-project/pom.xml
in the {{maven.compiler.source}} and {{maven.compiler.target}} elements, but
should be inherited via {{$compileSource}}. Then, just as {{$project.version}}
is converted into a literal value by the maven-resources-plugin (see footnote 5
again), so too will {{$compileSource}} be converted into a literal value.
{quote}
ah after running 'mvn archetype:generate -Dfilter=hbase' i see
{{$project.version}} gets replaced with the hbase project version. So we'll
just inherit whatever version hbase has.
{quote}
{color:red}EXACTLY!{color} The variable {{$project.version}} gets replaced by
an appropriate literal value by the maven-resources-plugin.
{color:green}*I will make {{$compileSource}} related changes according to your
first bullet point above (also modifying the text of footnote 5 accordingly)
and submit a revised patch.*{color}
BTW, HBASE-15176 has already been added for "end-user-oriented documentation".
As soon as the first v1.3 archetype becomes publicly available via the Maven
central repository, I'll add an appropriate entry to the end-user Reference
Guide text.
*THANKS!*
> maven archetype: client application
> ---
>
> Key: HBASE-14877
> URL: https://issues.apache.org/jira/browse/HBASE-14877
> Project: HBase
> Issue Type: Sub-task
> Components: build, Usability
>Affects Versions: 2.0.0
>Reporter: Nick Dimiduk
>Assignee: Daniel Vimont
> Labels: archetype, beginner, maven
> Attachments: HBASE-14877-v2.patch, HBASE-14877-v3.patch,
> HBASE-14877-v4.patch, HBASE-14877-v5.patch, HBASE-14877.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15137) CallTimeoutException should be grounds for PFFE
[ https://issues.apache.org/jira/browse/HBASE-15137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15153441#comment-15153441 ] Elliott Clark commented on HBASE-15137: --- Probably needs a rebase with the re-working of exceptions. > CallTimeoutException should be grounds for PFFE > --- > > Key: HBASE-15137 > URL: https://issues.apache.org/jira/browse/HBASE-15137 > Project: HBase > Issue Type: Bug >Reporter: Elliott Clark >Assignee: Mikhail Antonov > Attachments: HBASE-15137.mantonov.patch, HBASE-15137.patch > > > If a region server is backed up enough that lots of calls are timing out then > we should think about treating a server as failing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15135) Add metrics for storefile age
[ https://issues.apache.org/jira/browse/HBASE-15135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15153440#comment-15153440 ] Elliott Clark commented on HBASE-15135: --- +1 commit to the world. > Add metrics for storefile age > - > > Key: HBASE-15135 > URL: https://issues.apache.org/jira/browse/HBASE-15135 > Project: HBase > Issue Type: New Feature >Reporter: Elliott Clark >Assignee: Mikhail Antonov > Attachments: HBASE-15135-v2.patch, HBASE-15135-v3.patch, > HBASE-15135-v4.patch, HBASE-15135.patch > > > In order to make sure that compactions are fully up to date it would be nice > to have metrics on: > * Max storefile age > * Min storefile age > * Average storefile age > * Number of reference files > If we could have those metrics per region and per regionserver it would be > awesome. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15136) Explore different queuing behaviors while busy
[ https://issues.apache.org/jira/browse/HBASE-15136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Antonov updated HBASE-15136: Status: Patch Available (was: Open) > Explore different queuing behaviors while busy > -- > > Key: HBASE-15136 > URL: https://issues.apache.org/jira/browse/HBASE-15136 > Project: HBase > Issue Type: New Feature > Components: IPC/RPC >Reporter: Elliott Clark >Assignee: Mikhail Antonov > Attachments: HBASE-15136-1.2.v1.patch, deadline_scheduler_v_0_2.patch > > > http://queue.acm.org/detail.cfm?id=2839461 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15136) Explore different queuing behaviors while busy
[ https://issues.apache.org/jira/browse/HBASE-15136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Antonov updated HBASE-15136: Attachment: HBASE-15136-1.2.v1.patch > Explore different queuing behaviors while busy > -- > > Key: HBASE-15136 > URL: https://issues.apache.org/jira/browse/HBASE-15136 > Project: HBase > Issue Type: New Feature > Components: IPC/RPC >Reporter: Elliott Clark >Assignee: Mikhail Antonov > Attachments: HBASE-15136-1.2.v1.patch, deadline_scheduler_v_0_2.patch > > > http://queue.acm.org/detail.cfm?id=2839461 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15136) Explore different queuing behaviors while busy
[ https://issues.apache.org/jira/browse/HBASE-15136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Antonov updated HBASE-15136: Attachment: (was: HBASE-15136-1.2.v1.branch) > Explore different queuing behaviors while busy > -- > > Key: HBASE-15136 > URL: https://issues.apache.org/jira/browse/HBASE-15136 > Project: HBase > Issue Type: New Feature > Components: IPC/RPC >Reporter: Elliott Clark >Assignee: Mikhail Antonov > Attachments: deadline_scheduler_v_0_2.patch > > > http://queue.acm.org/detail.cfm?id=2839461 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15136) Explore different queuing behaviors while busy
[ https://issues.apache.org/jira/browse/HBASE-15136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Antonov updated HBASE-15136: Attachment: HBASE-15136-1.2.v1.branch First version of patch, for 1.2 branch for now as that's where I test it, will rebase on master soon. > Explore different queuing behaviors while busy > -- > > Key: HBASE-15136 > URL: https://issues.apache.org/jira/browse/HBASE-15136 > Project: HBase > Issue Type: New Feature > Components: IPC/RPC >Reporter: Elliott Clark >Assignee: Mikhail Antonov > Attachments: deadline_scheduler_v_0_2.patch > > > http://queue.acm.org/detail.cfm?id=2839461 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15181) A simple implementation of date based tiered compaction
[ https://issues.apache.org/jira/browse/HBASE-15181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15153385#comment-15153385 ] Clara Xiong commented on HBASE-15181: - [~enis][~vrodionov] I appreciate all the callouts and suggestions greatly. I agree we have to guarantee correctness and I think the first proposal will carry the smaller trade-off. We want to construct the tiers to maximize performance for time-range scan on time-series data.The scan api are typically based on look back window based on data timestamps. So we want to use timestamp instead of creation time to align the tiers to the scans. And creation time may not be as reliable as sequence id as a monochronic indicator. [~vrodionov] I carefully thought about Enis' first proposal. It should work since we know which tier and compaction window a store file belongs to as long as we know the current time and the file's maxTimestamp. We don't need the sequenceId to build the tiers. But I want to add a tweak to this proposal on how to handle late-arriving data. I want to compact the out-of-order data with newer files other than older ones. Since we don’t write future data, the worst scenario is that file on the lower tier have long tails instead of the data goes to higher tier. The additional cost of long tail is the cost to scan newer and smaller files. Given the tiered design, we only need to scan additional data at most the tail size + current window size.This will also reduce the chance of recompacting small files to an out-of -portion file. For the bulk load scenarios, currently bulk-load file carries 0 as sequenceId which will land them at the highest tier. It is configurable to use the sequenceId at the time of creation which will land them at the lower tiers. We will need to call out that user wants to decide based on the data timestamps relatively to the tiers and the access pattern. Please let me know what you think. [~enis]We do have performance results from production on a very large cluster replicated across multiple DC serving many concurrent time-range scans of different look-back windows. We are collecting more. I will share them externally once they are ready, most likely next week. We have observed drastic IO reduction for the scans. > A simple implementation of date based tiered compaction > --- > > Key: HBASE-15181 > URL: https://issues.apache.org/jira/browse/HBASE-15181 > Project: HBase > Issue Type: New Feature > Components: Compaction >Reporter: Clara Xiong >Assignee: Clara Xiong > Fix For: 2.0.0, 1.3.0, 0.98.19 > > Attachments: HBASE-15181-v1.patch, HBASE-15181-v2.patch > > > This is a simple implementation of date-based tiered compaction similar to > Cassandra's for the following benefits: > 1. Improve date-range-based scan by structuring store files in date-based > tiered layout. > 2. Reduce compaction overhead. > 3. Improve TTL efficiency. > Perfect fit for the use cases that: > 1. has mostly date-based date write and scan and a focus on the most recent > data. > 2. never or rarely deletes data. > Out-of-order writes are handled gracefully so the data will still get to the > right store file for time-range-scan and re-compacton with existing store > file in the same time window is handled by ExploringCompactionPolicy. > Time range overlapping among store files is tolerated and the performance > impact is minimized. > Configuration can be set at hbase-site or overriden at per-table or > per-column-famly level by hbase shell. > Design spec is at > https://docs.google.com/document/d/1_AmlNb2N8Us1xICsTeGDLKIqL6T-oHoRLZ323MG_uy8/edit?usp=sharing -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-9393) Hbase does not closing a closed socket resulting in many CLOSE_WAIT
[
https://issues.apache.org/jira/browse/HBASE-9393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15153357#comment-15153357
]
Ted Yu commented on HBASE-9393:
---
{code}
+ if (FSDataInputStreamWrapper.instanceOfCanUnbuffer) {
+try {
+ if (FSDataInputStreamWrapper.unbuffer == null) {
+try {
+
FSDataInputStreamWrapper.setUnbufferMethod(streamClass.getDeclaredMethod("unbuffer"));
{code}
FSDataInputStreamWrapper.setUnbufferMethod() has been called in the for loop
ahead of the above if block. Why do we need to call it again ?
> Hbase does not closing a closed socket resulting in many CLOSE_WAIT
>
>
> Key: HBASE-9393
> URL: https://issues.apache.org/jira/browse/HBASE-9393
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.94.2, 0.98.0
> Environment: Centos 6.4 - 7 regionservers/datanodes, 8 TB per node,
> 7279 regions
>Reporter: Avi Zrachya
>Assignee: Ashish Singhi
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-9393.patch, HBASE-9393.v1.patch,
> HBASE-9393.v10.patch, HBASE-9393.v11.patch, HBASE-9393.v2.patch,
> HBASE-9393.v3.patch, HBASE-9393.v4.patch, HBASE-9393.v5.patch,
> HBASE-9393.v5.patch, HBASE-9393.v5.patch, HBASE-9393.v6.patch,
> HBASE-9393.v6.patch, HBASE-9393.v6.patch, HBASE-9393.v7.patch,
> HBASE-9393.v8.patch, HBASE-9393.v9.patch
>
>
> HBase dose not close a dead connection with the datanode.
> This resulting in over 60K CLOSE_WAIT and at some point HBase can not connect
> to the datanode because too many mapped sockets from one host to another on
> the same port.
> The example below is with low CLOSE_WAIT count because we had to restart
> hbase to solve the porblem, later in time it will incease to 60-100K sockets
> on CLOSE_WAIT
> [root@hd2-region3 ~]# netstat -nap |grep CLOSE_WAIT |grep 21592 |wc -l
> 13156
> [root@hd2-region3 ~]# ps -ef |grep 21592
> root 17255 17219 0 12:26 pts/000:00:00 grep 21592
> hbase21592 1 17 Aug29 ?03:29:06
> /usr/java/jdk1.6.0_26/bin/java -XX:OnOutOfMemoryError=kill -9 %p -Xmx8000m
> -ea -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode
> -Dhbase.log.dir=/var/log/hbase
> -Dhbase.log.file=hbase-hbase-regionserver-hd2-region3.swnet.corp.log ...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15288) Flakey TestMasterMetrics.testClusterRequests on branch-1.1
[ https://issues.apache.org/jira/browse/HBASE-15288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15153299#comment-15153299 ] Heng Chen commented on HBASE-15288: --- https://builds.apache.org/job/PreCommit-HBASE-Build/591/artifact/patchprocess/patch-unit-hbase-server-jdk1.8.0_72.txt > Flakey TestMasterMetrics.testClusterRequests on branch-1.1 > -- > > Key: HBASE-15288 > URL: https://issues.apache.org/jira/browse/HBASE-15288 > Project: HBase > Issue Type: Sub-task > Components: test >Reporter: Heng Chen > Fix For: 1.1.4 > > > I found it during HBASE-15169, Let me see what's happening. > https://builds.apache.org/job/PreCommit-HBASE-Build/586/testReport/org.apache.hadoop.hbase.master/TestMasterMetrics/testClusterRequests/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (HBASE-8744) Enable HBase to log the entire latency profile for HDFS packets resulting in slow writes.
[ https://issues.apache.org/jira/browse/HBASE-8744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-8744. -- Resolution: Unresolved HTrace is to do this. > Enable HBase to log the entire latency profile for HDFS packets resulting in > slow writes. > - > > Key: HBASE-8744 > URL: https://issues.apache.org/jira/browse/HBASE-8744 > Project: HBase > Issue Type: Improvement >Reporter: Pritam Damania >Priority: Minor > > When we see WAL outliers in HBase, at times it is not clear which component > in the whole stack is slow. At facebook we are implementing per request > profiling which passes profiling information throughout the entire stack. > This information can be used to determine the outliers in HBase. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (HBASE-4668) List HDFS enhancements to speed up backups for HBase
[ https://issues.apache.org/jira/browse/HBASE-4668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-4668. -- Resolution: Unresolved > List HDFS enhancements to speed up backups for HBase > > > Key: HBASE-4668 > URL: https://issues.apache.org/jira/browse/HBASE-4668 > Project: HBase > Issue Type: Sub-task > Components: documentation, regionserver >Reporter: Karthik Ranganathan >Assignee: Pritam Damania > > There are a host of improvements that help: > - HDFS fast copy > - Various enhancements to fast copy to speed up things > - File level hard links - which does ext3 hardlinks instead of copying blocks > thereby saving a lot of iops > Need to list out the HDFS jira's and have patches on them. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15222) Use HDR histograms rather than hadoop or yammer's
[ https://issues.apache.org/jira/browse/HBASE-15222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark updated HBASE-15222: -- Status: Patch Available (was: Open) > Use HDR histograms rather than hadoop or yammer's > - > > Key: HBASE-15222 > URL: https://issues.apache.org/jira/browse/HBASE-15222 > Project: HBase > Issue Type: Bug > Components: metrics >Affects Versions: 2.0.0, 1.2.0, 1.3.0 >Reporter: Elliott Clark >Assignee: Elliott Clark >Priority: Critical > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-15222-v1.patch, HBASE-15222-v2.patch, > HBASE-15222.patch > > > Running the benchmarks now, but it looks like the results are pretty extreme. > The locking in our histograms is pretty extreme. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15222) Use HDR histograms rather than hadoop or yammer's
[ https://issues.apache.org/jira/browse/HBASE-15222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark updated HBASE-15222: -- Attachment: HBASE-15222-v2.patch Deprecate the FastLongHistogram and remove the quantile stuff. > Use HDR histograms rather than hadoop or yammer's > - > > Key: HBASE-15222 > URL: https://issues.apache.org/jira/browse/HBASE-15222 > Project: HBase > Issue Type: Bug > Components: metrics >Affects Versions: 2.0.0, 1.2.0, 1.3.0 >Reporter: Elliott Clark >Assignee: Elliott Clark >Priority: Critical > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-15222-v1.patch, HBASE-15222-v2.patch, > HBASE-15222.patch > > > Running the benchmarks now, but it looks like the results are pretty extreme. > The locking in our histograms is pretty extreme. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (HBASE-24) Scaling: Too many open file handles to datanodes
[ https://issues.apache.org/jira/browse/HBASE-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-24. Resolution: Won't Fix Resolving as 'wont fix'... We open lots of files. Would be good if we opened less. > Scaling: Too many open file handles to datanodes > > > Key: HBASE-24 > URL: https://issues.apache.org/jira/browse/HBASE-24 > Project: HBase > Issue Type: Bug > Components: regionserver >Reporter: stack >Priority: Blocker > Attachments: HBASE-823.patch, MonitoredReader.java > > > We've been here before (HADOOP-2341). > Today the rapleaf gave me an lsof listing from a regionserver. Had thousands > of open sockets to datanodes all in ESTABLISHED and CLOSE_WAIT state. On > average they seem to have about ten file descriptors/sockets open per region > (They have 3 column families IIRC. Per family, can have between 1-5 or so > mapfiles open per family -- 3 is max... but compacting we open a new one, > etc.). > They have thousands of regions. 400 regions -- ~100G, which is not that > much -- takes about 4k open file handles. > If they want a regionserver to server a decent disk worths -- 300-400G -- > then thats maybe 1600 regions... 16k file handles. If more than just 3 > column families. then we are in danger of blowing out limits if they are > 32k. > We've been here before with HADOOP-2341. > A dfsclient that used non-blocking i/o would help applications like hbase > (The datanode doesn't have this problem as bad -- CLOSE_WAIT on regionserver > side, the bulk of the open fds in the rapleaf log, don't have a corresponding > open resource on datanode end). > Could also just open mapfiles as needed, but that'd kill our random read > performance and its bad enough already. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-15289) Add details about how to get usage instructions for Import and Export utilities
Misty Stanley-Jones created HBASE-15289: --- Summary: Add details about how to get usage instructions for Import and Export utilities Key: HBASE-15289 URL: https://issues.apache.org/jira/browse/HBASE-15289 Project: HBase Issue Type: Bug Affects Versions: 2.0.0 Reporter: Misty Stanley-Jones Assignee: Misty Stanley-Jones Fix For: 2.0.0 Some folks don't realize that you can specify options for the Import and Export commands, like limiting the column families or applying filters. Document how to see the usage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15289) Add details about how to get usage instructions for Import and Export utilities
[ https://issues.apache.org/jira/browse/HBASE-15289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misty Stanley-Jones updated HBASE-15289: Component/s: documentation > Add details about how to get usage instructions for Import and Export > utilities > --- > > Key: HBASE-15289 > URL: https://issues.apache.org/jira/browse/HBASE-15289 > Project: HBase > Issue Type: Bug > Components: documentation >Affects Versions: 2.0.0 >Reporter: Misty Stanley-Jones >Assignee: Misty Stanley-Jones > Labels: newbie > Fix For: 2.0.0 > > Attachments: HBASE-15289.patch > > > Some folks don't realize that you can specify options for the Import and > Export commands, like limiting the column families or applying filters. > Document how to see the usage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15289) Add details about how to get usage instructions for Import and Export utilities
[ https://issues.apache.org/jira/browse/HBASE-15289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misty Stanley-Jones updated HBASE-15289: Labels: newbie (was: ) Status: Patch Available (was: Open) > Add details about how to get usage instructions for Import and Export > utilities > --- > > Key: HBASE-15289 > URL: https://issues.apache.org/jira/browse/HBASE-15289 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0 >Reporter: Misty Stanley-Jones >Assignee: Misty Stanley-Jones > Labels: newbie > Fix For: 2.0.0 > > Attachments: HBASE-15289.patch > > > Some folks don't realize that you can specify options for the Import and > Export commands, like limiting the column families or applying filters. > Document how to see the usage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15289) Add details about how to get usage instructions for Import and Export utilities
[ https://issues.apache.org/jira/browse/HBASE-15289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misty Stanley-Jones updated HBASE-15289: Attachment: HBASE-15289.patch Ready for review. > Add details about how to get usage instructions for Import and Export > utilities > --- > > Key: HBASE-15289 > URL: https://issues.apache.org/jira/browse/HBASE-15289 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0 >Reporter: Misty Stanley-Jones >Assignee: Misty Stanley-Jones > Labels: newbie > Fix For: 2.0.0 > > Attachments: HBASE-15289.patch > > > Some folks don't realize that you can specify options for the Import and > Export commands, like limiting the column families or applying filters. > Document how to see the usage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15222) Use HDR histograms rather than hadoop or yammer's
[ https://issues.apache.org/jira/browse/HBASE-15222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark updated HBASE-15222: -- Attachment: HBASE-15222-v1.patch > Use HDR histograms rather than hadoop or yammer's > - > > Key: HBASE-15222 > URL: https://issues.apache.org/jira/browse/HBASE-15222 > Project: HBase > Issue Type: Bug > Components: metrics >Affects Versions: 2.0.0, 1.2.0, 1.3.0 >Reporter: Elliott Clark >Assignee: Elliott Clark >Priority: Critical > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-15222-v1.patch, HBASE-15222.patch > > > Running the benchmarks now, but it looks like the results are pretty extreme. > The locking in our histograms is pretty extreme. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15222) Use HDR histograms rather than hadoop or yammer's
[ https://issues.apache.org/jira/browse/HBASE-15222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15153036#comment-15153036 ] Elliott Clark commented on HBASE-15222: --- https://reviews.facebook.net/D54381 I added the transition to counter in a few places. I also transitioned block cache to HDR histograms. > Use HDR histograms rather than hadoop or yammer's > - > > Key: HBASE-15222 > URL: https://issues.apache.org/jira/browse/HBASE-15222 > Project: HBase > Issue Type: Bug > Components: metrics >Affects Versions: 2.0.0, 1.2.0, 1.3.0 >Reporter: Elliott Clark >Assignee: Elliott Clark >Priority: Critical > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-15222.patch > > > Running the benchmarks now, but it looks like the results are pretty extreme. > The locking in our histograms is pretty extreme. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15169) Backport HBASE-14362 'TestWALProcedureStoreOnHDFS is super duper flaky' to branch-1.1
[
https://issues.apache.org/jira/browse/HBASE-15169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15153028#comment-15153028
]
Hadoop QA commented on HBASE-15169:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
45s {color} | {color:green} branch-1.1 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 28s
{color} | {color:green} branch-1.1 passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 32s
{color} | {color:green} branch-1.1 passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
16s {color} | {color:green} branch-1.1 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
15s {color} | {color:green} branch-1.1 passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 1m 45s
{color} | {color:red} hbase-server in branch-1.1 has 79 extant Findbugs
warnings. {color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 0m 24s
{color} | {color:red} hbase-server in branch-1.1 failed with JDK v1.8.0_72.
{color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 30s
{color} | {color:green} branch-1.1 passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
39s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 28s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 28s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 33s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 33s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
14s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
16s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 4m
6s {color} | {color:green} Patch does not cause any errors with Hadoop 2.4.1
2.5.2 2.6.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
58s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 0m 26s
{color} | {color:red} hbase-server in the patch failed with JDK v1.8.0_72.
{color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 32s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 82m 45s {color}
| {color:red} hbase-server in the patch failed with JDK v1.8.0_72. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 87m 35s {color}
| {color:red} hbase-server in the patch failed with JDK v1.7.0_95. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
16s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 198m 30s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| JDK v1.8.0_72 Failed junit tests | hadoop.hbase.master.TestMasterMetrics |
| JDK v1.7.0_95 Failed junit tests |
hadoop.hbase.coprocessor.TestRegionObserverBypass |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.9.1 Server=1.9.1 Image:yetus/hbase:date2016-02-18 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12788472/HBASE-15169-branch-1.1.patch
|
| JIRA Issue | HBASE-15169 |
| Optional Tests | asflicense javac javadoc unit findbugs had
[jira] [Commented] (HBASE-9393) Hbase does not closing a closed socket resulting in many CLOSE_WAIT
[
https://issues.apache.org/jira/browse/HBASE-9393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15153026#comment-15153026
]
Hadoop QA commented on HBASE-9393:
--
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s
{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
38s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 32s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 34s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 4m
22s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
16s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
50s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 26s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 31s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
46s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 30s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 30s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 36s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 36s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 4m
2s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
16s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
24m 14s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m 8s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 32s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 39s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 106m 18s
{color} | {color:red} hbase-server in the patch failed with JDK v1.8.0_72.
{color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 99m 12s {color}
| {color:red} hbase-server in the patch failed with JDK v1.7.0_95. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
16s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 251m 9s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| JDK v1.8.0_72 Failed junit tests |
hadoop.hbase.replication.TestReplicationEndpoint |
| JDK v1.8.0_72 Timed out junit tests |
org.apache.hadoop.hbase.regionserver.TestHRegion |
| JDK v1.7.0_95 Failed junit tests |
hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort |
| | hadoop.hbase.snapshot.TestSecureExportSnapshot |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.9.1
[jira] [Commented] (HBASE-15272) Add error handling for split and compact actions in table.jsp
[
https://issues.apache.org/jira/browse/HBASE-15272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152978#comment-15152978
]
Hadoop QA commented on HBASE-15272:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s
{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
11s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
21s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 34s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 40s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
53s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
20s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
24m 37s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 29s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 36s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 119m 10s
{color} | {color:green} hbase-server in the patch passed with JDK v1.8.0_72.
{color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 111m 39s
{color} | {color:green} hbase-server in the patch passed with JDK v1.7.0_95.
{color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
24s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 281m 28s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.9.1 Server=1.9.1 Image:yetus/hbase:date2016-02-18 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12788461/HBASE-15272_v0.patch |
| JIRA Issue | HBASE-15272 |
| Optional Tests | asflicense javac javadoc unit |
| uname | Linux 28c7283617a8 3.13.0-36-lowlatency #63-Ubuntu SMP PREEMPT Wed
Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / d2ba875 |
| JDK v1.7.0_95 Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/589/testReport/ |
| modules | C: hbase-server U: hbase-server |
| Max memory used | 172MB |
| Powered by | Apache Yetus 0.1.0 http://yetus.apache.org |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/589/console |
This message was automatically generated.
> Add error handling for split and compact actions in table.jsp
> -
>
> Key: HBASE-15272
> URL: https://issues.apache.org/jira/browse/HBASE-15272
> Project: HBase
> Issue Type: Sub-task
> Components: UI
>Affects Versions: 2.0.0
>Reporter: Samir Ahmic
>Assignee: Samir Ahmic
> Fix For: 2.0.0
>
> Attachments: HBASE-15272_v0.patch
>
>
> Split and compact actions in table.jsp throwing 500 error in case when
> non-existing key is passed as parameter.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15222) Use HDR histograms rather than hadoop or yammer's
[ https://issues.apache.org/jira/browse/HBASE-15222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152918#comment-15152918 ] Mikhail Antonov commented on HBASE-15222: - Looks good to me. > Use HDR histograms rather than hadoop or yammer's > - > > Key: HBASE-15222 > URL: https://issues.apache.org/jira/browse/HBASE-15222 > Project: HBase > Issue Type: Bug > Components: metrics >Affects Versions: 2.0.0, 1.2.0, 1.3.0 >Reporter: Elliott Clark >Assignee: Elliott Clark >Priority: Critical > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-15222.patch > > > Running the benchmarks now, but it looks like the results are pretty extreme. > The locking in our histograms is pretty extreme. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15136) Explore different queuing behaviors while busy
[ https://issues.apache.org/jira/browse/HBASE-15136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152908#comment-15152908 ] Elliott Clark commented on HBASE-15136: --- https://reviews.facebook.net/D54351 Comments up on web review board. > Explore different queuing behaviors while busy > -- > > Key: HBASE-15136 > URL: https://issues.apache.org/jira/browse/HBASE-15136 > Project: HBase > Issue Type: New Feature > Components: IPC/RPC >Reporter: Elliott Clark >Assignee: Mikhail Antonov > Attachments: deadline_scheduler_v_0_2.patch > > > http://queue.acm.org/detail.cfm?id=2839461 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14949) Resolve name conflict when splitting if there are duplicated WAL entries
[ https://issues.apache.org/jira/browse/HBASE-14949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152868#comment-15152868 ] Hudson commented on HBASE-14949: FAILURE: Integrated in HBase-1.3 #560 (See [https://builds.apache.org/job/HBase-1.3/560/]) HBASE-14949 addendum fix compilation error on branch-1 (zhangduo: rev 7a1c407ea64337505da21727976c494ba741f8ef) * hbase-server/src/main/java/org/apache/hadoop/hbase/wal/WALSplitter.java > Resolve name conflict when splitting if there are duplicated WAL entries > > > Key: HBASE-14949 > URL: https://issues.apache.org/jira/browse/HBASE-14949 > Project: HBase > Issue Type: Sub-task > Components: wal >Reporter: Heng Chen >Assignee: Duo Zhang > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-14949-addendum-branch-1.patch, > HBASE-14949-v3.patch, HBASE-14949-v4.patch, HBASE-14949-v5.patch, > HBASE-14949.patch, HBASE-14949_v1.patch, HBASE-14949_v2.patch > > > The AsyncFSHLog introduced in HBASE-14790 may write same WAL entries to > different WAL files. WAL entry itself is idempotent so replay is not a > problem but the intermediate file name and final name when splitting is > constructed using the lowest or highest sequence id of the WAL entries > written, so it is possible that different WAL files will have same > intermediate or final file name when splitting. In the currentm > implementation, this will cause split fail or data loss. We need to solve > this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15285) Forward-port respect for isReturnResult from HBASE-15095
[ https://issues.apache.org/jira/browse/HBASE-15285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152870#comment-15152870 ] Hudson commented on HBASE-15285: FAILURE: Integrated in HBase-1.3 #560 (See [https://builds.apache.org/job/HBase-1.3/560/]) HBASE-15285 ADDENDUM make RETURN_RESULTS attribute name protected to (jmhsieh: rev 7b4646fe3dc44607d33c7a05112e5e1a7cf5649c) * hbase-client/src/main/java/org/apache/hadoop/hbase/client/Mutation.java > Forward-port respect for isReturnResult from HBASE-15095 > > > Key: HBASE-15285 > URL: https://issues.apache.org/jira/browse/HBASE-15285 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 2.0.0, 1.2.0 >Reporter: stack >Assignee: stack > Fix For: 2.0.0, 1.2.0, 1.3.0 > > Attachments: 15095.patch, 15095v2.patch, > HBASE-15285-branch-1.addendum.v1.patch > > > This issue is about forward-porting the bug fix done in HBASE-15095 so we > respect the isReturnResult properly in append and increment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15277) TestRegionMergeTransactionOnCluster.testWholesomeMerge fails with no connection to master
[
https://issues.apache.org/jira/browse/HBASE-15277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152821#comment-15152821
]
stack commented on HBASE-15277:
---
I see this test hung just now here
https://builds.apache.org/job/HBase-Trunk_matrix/jdk=latest1.8,label=yahoo-not-h2/719/consoleText
Need to add zombie catcher script back.
Maybe same issue. Maybe not.
> TestRegionMergeTransactionOnCluster.testWholesomeMerge fails with no
> connection to master
> -
>
> Key: HBASE-15277
> URL: https://issues.apache.org/jira/browse/HBASE-15277
> Project: HBase
> Issue Type: Sub-task
> Components: test
>Reporter: stack
> Fix For: 2.0.0
>
> Attachments: 15277.patch
>
>
> {code}
> java.io.IOException: connection is closed
> at
> org.apache.hadoop.hbase.MetaTableAccessor.getMetaHTable(MetaTableAccessor.java:254)
> at
> org.apache.hadoop.hbase.MetaTableAccessor.scanMeta(MetaTableAccessor.java:773)
> at
> org.apache.hadoop.hbase.MetaTableAccessor.scanMeta(MetaTableAccessor.java:702)
> at
> org.apache.hadoop.hbase.MetaTableAccessor.getTableRegionsAndLocations(MetaTableAccessor.java:624)
> at
> org.apache.hadoop.hbase.MetaTableAccessor.getTableRegionsAndLocations(MetaTableAccessor.java:575)
> at
> org.apache.hadoop.hbase.regionserver.TestRegionMergeTransactionOnCluster.waitAndVerifyRegionNum(TestRegionMergeTransactionOnCluster.java:426)
> at
> org.apache.hadoop.hbase.regionserver.TestRegionMergeTransactionOnCluster.mergeRegionsAndVerifyRegionNum(TestRegionMergeTransactionOnCluster.java:402)
> at
> org.apache.hadoop.hbase.regionserver.TestRegionMergeTransactionOnCluster.testWholesomeMerge(TestRegionMergeTransactionOnCluster.java:139)
> {code|
> Everywhere we rely on master connection being up. Instead try using the test
> Connection ... see how that does. Add timeouts on this flakey test too.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15205) Do not find the replication scope for every WAL#append()
[ https://issues.apache.org/jira/browse/HBASE-15205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152809#comment-15152809 ] stack commented on HBASE-15205: --- bq. Anyway I can remove it. Thanks for rename, but yeah, if a public method can be removed on audience private class, thats better. bq. Hence passing on the replicationScope to the WALKey thro FSWALEntry seems fine to me. bq. So you want me to change in such a way that during WALKey construction itself pass the replicationScope? My problem is with our having two sets of scopes, one in WALKey and another in WALEnry. There should be one set only. So, you think passing replications scopes through to WALKey the way to go? It already has scopes so makes sense? bq. Before updating the next patch you still want me to go with the way of setting the scope on HTD and use the same HTD to retrive the scope per family? Above was a suggestion. Do what you think makes most sense. If scopes are to be carried by the WalKey, in WAL#append, you don't have to take away the HTD to replace it with map of scopes? They'll be in the WALKey when it is constructed? bq. But I fear it wont serve the purpose of short living objects because the HTD.setValue() will convert things to Bytes. Good point. That makes my suggestion silly. Thanks Ram. > Do not find the replication scope for every WAL#append() > > > Key: HBASE-15205 > URL: https://issues.apache.org/jira/browse/HBASE-15205 > Project: HBase > Issue Type: Sub-task > Components: regionserver >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-15205.patch, HBASE-15205_1.patch, > HBASE-15205_2.patch, HBASE-15205_3.patch, HBASE-15205_4.patch, > ScopeWALEdits.jpg, ScopeWALEdits_afterpatch.jpg > > > After the byte[] and char[] the other top contributor for lot of GC (though > it is only 2.86%) is the UTF_8.newDecoder. > This happens because for every WAL append we try to calculate the replication > scope associate with the families associated with the TableDescriptor. I > think per WAL append doing this is very costly and creates lot of garbage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15285) Forward-port respect for isReturnResult from HBASE-15095
[ https://issues.apache.org/jira/browse/HBASE-15285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152781#comment-15152781 ] Hudson commented on HBASE-15285: FAILURE: Integrated in HBase-1.2 #555 (See [https://builds.apache.org/job/HBase-1.2/555/]) HBASE-15285 ADDENDUM make RETURN_RESULTS attribute name protected to (jmhsieh: rev d4388ba0101928d1d272b2e88dddfd5203400ee8) * hbase-client/src/main/java/org/apache/hadoop/hbase/client/Mutation.java > Forward-port respect for isReturnResult from HBASE-15095 > > > Key: HBASE-15285 > URL: https://issues.apache.org/jira/browse/HBASE-15285 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 2.0.0, 1.2.0 >Reporter: stack >Assignee: stack > Fix For: 2.0.0, 1.2.0, 1.3.0 > > Attachments: 15095.patch, 15095v2.patch, > HBASE-15285-branch-1.addendum.v1.patch > > > This issue is about forward-porting the bug fix done in HBASE-15095 so we > respect the isReturnResult properly in append and increment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14949) Resolve name conflict when splitting if there are duplicated WAL entries
[ https://issues.apache.org/jira/browse/HBASE-14949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152760#comment-15152760 ] stack commented on HBASE-14949: --- One-liner release note if you don't mind [~Apache9] This is nice internal fixup. Good to surface the basics. Thanks. > Resolve name conflict when splitting if there are duplicated WAL entries > > > Key: HBASE-14949 > URL: https://issues.apache.org/jira/browse/HBASE-14949 > Project: HBase > Issue Type: Sub-task > Components: wal >Reporter: Heng Chen >Assignee: Duo Zhang > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-14949-addendum-branch-1.patch, > HBASE-14949-v3.patch, HBASE-14949-v4.patch, HBASE-14949-v5.patch, > HBASE-14949.patch, HBASE-14949_v1.patch, HBASE-14949_v2.patch > > > The AsyncFSHLog introduced in HBASE-14790 may write same WAL entries to > different WAL files. WAL entry itself is idempotent so replay is not a > problem but the intermediate file name and final name when splitting is > constructed using the lowest or highest sequence id of the WAL entries > written, so it is possible that different WAL files will have same > intermediate or final file name when splitting. In the currentm > implementation, this will cause split fail or data loss. We need to solve > this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15222) Use HDR histograms rather than hadoop or yammer's
[ https://issues.apache.org/jira/browse/HBASE-15222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark updated HBASE-15222: -- Attachment: HBASE-15222.patch Still needs some clean up but it should make the idea known. > Use HDR histograms rather than hadoop or yammer's > - > > Key: HBASE-15222 > URL: https://issues.apache.org/jira/browse/HBASE-15222 > Project: HBase > Issue Type: Bug > Components: metrics >Affects Versions: 2.0.0, 1.2.0, 1.3.0 >Reporter: Elliott Clark >Assignee: Elliott Clark >Priority: Critical > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-15222.patch > > > Running the benchmarks now, but it looks like the results are pretty extreme. > The locking in our histograms is pretty extreme. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15274) ClientSideRegionScanner's reaction to Scan#setBatch is not consistent between HBase versions
[
https://issues.apache.org/jira/browse/HBASE-15274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152643#comment-15152643
]
Hudson commented on HBASE-15274:
FAILURE: Integrated in HBase-0.98-on-Hadoop-1.1 #1174 (See
[https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/1174/])
HBASE-15274 ClientSideRegionScanner's reaction to Scan#setBatch is not (enis:
rev 95b55fea8735c712f8ece4cb019dbbb1bedfc4bc)
*
hbase-server/src/main/java/org/apache/hadoop/hbase/client/ClientSideRegionScanner.java
> ClientSideRegionScanner's reaction to Scan#setBatch is not consistent between
> HBase versions
>
>
> Key: HBASE-15274
> URL: https://issues.apache.org/jira/browse/HBASE-15274
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.0.3, 1.1.3, 0.98.17
>Reporter: Youngjoon Kim
>Assignee: Youngjoon Kim
>Priority: Minor
> Fix For: 1.0.4, 0.98.18
>
> Attachments: HBASE-15274-0.98.patch, HBASE-15274-branch-1.0.patch
>
>
> In 1.1.3, ClientSideRegionScanner calls RegionScannerImpl#next() with single
> argument, so it honors Scan#setBatch(through defaultScannerContext in
> RegionScannerImpl).
> {code}
> // 1.1.3
> public class ClientSideRegionScanner extends AbstractClientScanner {
> ...
> @Override
> public Result next() throws IOException {
> values.clear();
> scanner.nextRaw(values);
> ...
> {code}
>
> \\
> But in 1.0.3 and 0.98.17, ClientSideRegionScanner calls
> RegionScannerImpl#next() with limit=-1, so it ignores Scan#setBatch.
> {code}
> // 1.0.3 and 0.98.17
> public class ClientSideRegionScanner extends AbstractClientScanner {
> ...
> @Override
> public Result next() throws IOException {
> values.clear();
> scanner.nextRaw(values, -1); // pass -1 as limit so that we see the whole
> row.
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15274) ClientSideRegionScanner's reaction to Scan#setBatch is not consistent between HBase versions
[
https://issues.apache.org/jira/browse/HBASE-15274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152642#comment-15152642
]
Hudson commented on HBASE-15274:
FAILURE: Integrated in HBase-0.98-matrix #300 (See
[https://builds.apache.org/job/HBase-0.98-matrix/300/])
HBASE-15274 ClientSideRegionScanner's reaction to Scan#setBatch is not (enis:
rev 95b55fea8735c712f8ece4cb019dbbb1bedfc4bc)
*
hbase-server/src/main/java/org/apache/hadoop/hbase/client/ClientSideRegionScanner.java
> ClientSideRegionScanner's reaction to Scan#setBatch is not consistent between
> HBase versions
>
>
> Key: HBASE-15274
> URL: https://issues.apache.org/jira/browse/HBASE-15274
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.0.3, 1.1.3, 0.98.17
>Reporter: Youngjoon Kim
>Assignee: Youngjoon Kim
>Priority: Minor
> Fix For: 1.0.4, 0.98.18
>
> Attachments: HBASE-15274-0.98.patch, HBASE-15274-branch-1.0.patch
>
>
> In 1.1.3, ClientSideRegionScanner calls RegionScannerImpl#next() with single
> argument, so it honors Scan#setBatch(through defaultScannerContext in
> RegionScannerImpl).
> {code}
> // 1.1.3
> public class ClientSideRegionScanner extends AbstractClientScanner {
> ...
> @Override
> public Result next() throws IOException {
> values.clear();
> scanner.nextRaw(values);
> ...
> {code}
>
> \\
> But in 1.0.3 and 0.98.17, ClientSideRegionScanner calls
> RegionScannerImpl#next() with limit=-1, so it ignores Scan#setBatch.
> {code}
> // 1.0.3 and 0.98.17
> public class ClientSideRegionScanner extends AbstractClientScanner {
> ...
> @Override
> public Result next() throws IOException {
> values.clear();
> scanner.nextRaw(values, -1); // pass -1 as limit so that we see the whole
> row.
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15279) OrderedBytes.isEncodedValue does not check for int8 and int16 types
[ https://issues.apache.org/jira/browse/HBASE-15279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-15279: -- Resolution: Fixed Hadoop Flags: Reviewed Fix Version/s: 1.1.4 1.3.0 2.0.0 Status: Resolved (was: Patch Available) Resolving. Pushed to branch-1.1+ > OrderedBytes.isEncodedValue does not check for int8 and int16 types > --- > > Key: HBASE-15279 > URL: https://issues.apache.org/jira/browse/HBASE-15279 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0, 1.3.0, 1.1.3 >Reporter: Robert Yokota >Assignee: Robert Yokota > Fix For: 2.0.0, 1.2.0, 1.3.0, 1.1.4 > > Attachments: HBASE-15279-2.patch, HBASE-15279.patch > > > OrderedBytes.isEncodedValue does not check for int8 and int16 types. This > also means that OrderedBytes.length may return an incorrect result, since it > calls OrderedBytes.isEncodedValue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15274) ClientSideRegionScanner's reaction to Scan#setBatch is not consistent between HBase versions
[
https://issues.apache.org/jira/browse/HBASE-15274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152631#comment-15152631
]
Hudson commented on HBASE-15274:
SUCCESS: Integrated in HBase-1.0 #1147 (See
[https://builds.apache.org/job/HBase-1.0/1147/])
HBASE-15274 ClientSideRegionScanner's reaction to Scan#setBatch is not (enis:
rev 2ce516b0fff93a4ee84bb53f9623c495d8dc3d13)
*
hbase-server/src/main/java/org/apache/hadoop/hbase/client/ClientSideRegionScanner.java
> ClientSideRegionScanner's reaction to Scan#setBatch is not consistent between
> HBase versions
>
>
> Key: HBASE-15274
> URL: https://issues.apache.org/jira/browse/HBASE-15274
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.0.3, 1.1.3, 0.98.17
>Reporter: Youngjoon Kim
>Assignee: Youngjoon Kim
>Priority: Minor
> Fix For: 1.0.4, 0.98.18
>
> Attachments: HBASE-15274-0.98.patch, HBASE-15274-branch-1.0.patch
>
>
> In 1.1.3, ClientSideRegionScanner calls RegionScannerImpl#next() with single
> argument, so it honors Scan#setBatch(through defaultScannerContext in
> RegionScannerImpl).
> {code}
> // 1.1.3
> public class ClientSideRegionScanner extends AbstractClientScanner {
> ...
> @Override
> public Result next() throws IOException {
> values.clear();
> scanner.nextRaw(values);
> ...
> {code}
>
> \\
> But in 1.0.3 and 0.98.17, ClientSideRegionScanner calls
> RegionScannerImpl#next() with limit=-1, so it ignores Scan#setBatch.
> {code}
> // 1.0.3 and 0.98.17
> public class ClientSideRegionScanner extends AbstractClientScanner {
> ...
> @Override
> public Result next() throws IOException {
> values.clear();
> scanner.nextRaw(values, -1); // pass -1 as limit so that we see the whole
> row.
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15169) Backport HBASE-14362 'TestWALProcedureStoreOnHDFS is super duper flaky' to branch-1.1
[ https://issues.apache.org/jira/browse/HBASE-15169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Dimiduk updated HBASE-15169: - Attachment: HBASE-15169-branch-1.1.patch > Backport HBASE-14362 'TestWALProcedureStoreOnHDFS is super duper flaky' to > branch-1.1 > - > > Key: HBASE-15169 > URL: https://issues.apache.org/jira/browse/HBASE-15169 > Project: HBase > Issue Type: Sub-task > Components: test >Reporter: Nick Dimiduk >Assignee: Heng Chen >Priority: Critical > Fix For: 1.1.4 > > Attachments: HBASE-15169-branch-1.1.patch, > HBASE-15169-branch-1.1.patch, HBASE-15169-branch-1.1.patch, > HBASE-15169-branch-1.1.patch, HBASE-15169-branch-1.1.patch, > HBASE-15169-branch-1.1.patch, HBASE-15169-branch-1.1.patch > > > This one fails consistently for me and there's a fix hanging out upstream. > Let's bring it back. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15120) Backport HBASE-14883 to branch-1.1
[ https://issues.apache.org/jira/browse/HBASE-15120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152592#comment-15152592 ] Nick Dimiduk commented on HBASE-15120: -- thanks fellas. > Backport HBASE-14883 to branch-1.1 > -- > > Key: HBASE-15120 > URL: https://issues.apache.org/jira/browse/HBASE-15120 > Project: HBase > Issue Type: Bug >Affects Versions: 1.1.2 >Reporter: Yu Li >Assignee: Yu Li >Priority: Minor > Fix For: 1.1.4 > > Attachments: HBASE-15120.branch-1.1.patch, > HBASE-15120.branch-1.1.patch, HBASE-15120.branch-1.1.patch > > > When checking branch-1.1 UT in HBASE-13590, found > TestSplitTransactionOnCluster#testFailedSplit will fail at a 12/50 chance. > The issue is fixed by HBASE-14883 but the change didn't go into branch-1.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15144) Procedure v2 - Web UI displaying Store state
[ https://issues.apache.org/jira/browse/HBASE-15144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152582#comment-15152582 ] Samir Ahmic commented on HBASE-15144: - Sure thing. All this changes make sense. Let me do the changes and i will add new patch. > Procedure v2 - Web UI displaying Store state > > > Key: HBASE-15144 > URL: https://issues.apache.org/jira/browse/HBASE-15144 > Project: HBase > Issue Type: Sub-task > Components: proc-v2, UI >Reporter: Matteo Bertozzi >Assignee: Samir Ahmic >Priority: Minor > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-15144_v0.patch, HBASE-15144_v1.patch, > WALStoreUI.png > > > The procedure webui page should show information about the WALProcedureStore. > * number/list/size of WALs active > * we may extract the "Sync wait %s, slotIndex=%s , totalSynced=%s (%s/sec)" > that today is only in LOG.trace() > * we have a getMillisToNextPeriodicRoll() and getMillisFromLastRoll() if > anyone want to see that -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15170) Backport HBASE-14807 'TestWALLockup is flakey' to branch-1.1
[ https://issues.apache.org/jira/browse/HBASE-15170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152581#comment-15152581 ] Nick Dimiduk commented on HBASE-15170: -- thanks [~stack] > Backport HBASE-14807 'TestWALLockup is flakey' to branch-1.1 > > > Key: HBASE-15170 > URL: https://issues.apache.org/jira/browse/HBASE-15170 > Project: HBase > Issue Type: Sub-task > Components: test >Reporter: Nick Dimiduk >Assignee: stack >Priority: Critical > Fix For: 1.1.4 > > Attachments: 15170.branch-1.1.patch > > > I'm hitting this one regularly and there's a fix for branch-1.2. Let's bring > it back. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15270) Use appropriate encoding for "filter" field in TaskMonitorTmpl.jamon
[
https://issues.apache.org/jira/browse/HBASE-15270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152547#comment-15152547
]
Hudson commented on HBASE-15270:
SUCCESS: Integrated in HBase-1.1-JDK7 #1666 (See
[https://builds.apache.org/job/HBase-1.1-JDK7/1666/])
HBASE-15270 Use appropriate encoding for "filter" field in (busbey: rev
e3ea7a427e2d62a721a18a991057f1a5b10984ac)
*
hbase-server/src/main/jamon/org/apache/hadoop/hbase/tmpl/common/TaskMonitorTmpl.jamon
> Use appropriate encoding for "filter" field in TaskMonitorTmpl.jamon
> -
>
> Key: HBASE-15270
> URL: https://issues.apache.org/jira/browse/HBASE-15270
> Project: HBase
> Issue Type: Sub-task
> Components: UI
>Affects Versions: 2.0.0, 1.2.1, 1.1.3
>Reporter: Samir Ahmic
>Assignee: Samir Ahmic
> Fix For: 2.0.0, 1.2.0, 1.3.0, 1.1.4
>
> Attachments: HBASE-15270_v0.patch, HBASE-15270_v1.patch
>
>
> In TaskMonitorTmpl.jamon we have this line
> {code}
> View as JSON
> {code}
> which is allowing "filter" parameter to take arbitrary value. I suggest that
> we encode this value for HTML.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15120) Backport HBASE-14883 to branch-1.1
[ https://issues.apache.org/jira/browse/HBASE-15120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152546#comment-15152546 ] Hudson commented on HBASE-15120: SUCCESS: Integrated in HBase-1.1-JDK7 #1666 (See [https://builds.apache.org/job/HBase-1.1-JDK7/1666/]) Revert "HBASE-15120 Use appropriate encoding for "filter" field in (busbey: rev 96c1683e2f7183e6855e9deb474d942e6b31fd35) * hbase-server/src/main/jamon/org/apache/hadoop/hbase/tmpl/common/TaskMonitorTmpl.jamon > Backport HBASE-14883 to branch-1.1 > -- > > Key: HBASE-15120 > URL: https://issues.apache.org/jira/browse/HBASE-15120 > Project: HBase > Issue Type: Bug >Affects Versions: 1.1.2 >Reporter: Yu Li >Assignee: Yu Li >Priority: Minor > Fix For: 1.1.4 > > Attachments: HBASE-15120.branch-1.1.patch, > HBASE-15120.branch-1.1.patch, HBASE-15120.branch-1.1.patch > > > When checking branch-1.1 UT in HBASE-13590, found > TestSplitTransactionOnCluster#testFailedSplit will fail at a 12/50 chance. > The issue is fixed by HBASE-14883 but the change didn't go into branch-1.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15279) OrderedBytes.isEncodedValue does not check for int8 and int16 types
[ https://issues.apache.org/jira/browse/HBASE-15279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152545#comment-15152545 ] Hudson commented on HBASE-15279: SUCCESS: Integrated in HBase-1.1-JDK7 #1666 (See [https://builds.apache.org/job/HBase-1.1-JDK7/1666/]) HBASE-15279 OrderedBytes.isEncodedValue does not check for int8 and (stack: rev 87d91e5537460cea2321c3ef3046cac1a450cbe0) * hbase-common/src/test/java/org/apache/hadoop/hbase/util/TestOrderedBytes.java * hbase-common/src/main/java/org/apache/hadoop/hbase/util/OrderedBytes.java > OrderedBytes.isEncodedValue does not check for int8 and int16 types > --- > > Key: HBASE-15279 > URL: https://issues.apache.org/jira/browse/HBASE-15279 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0, 1.3.0, 1.1.3 >Reporter: Robert Yokota >Assignee: Robert Yokota > Fix For: 1.2.0 > > Attachments: HBASE-15279-2.patch, HBASE-15279.patch > > > OrderedBytes.isEncodedValue does not check for int8 and int16 types. This > also means that OrderedBytes.length may return an incorrect result, since it > calls OrderedBytes.isEncodedValue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-9393) Hbase does not closing a closed socket resulting in many CLOSE_WAIT
[ https://issues.apache.org/jira/browse/HBASE-9393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashish Singhi updated HBASE-9393: - Attachment: HBASE-9393.v11.patch Fixed the last findbugs warning. Please review. > Hbase does not closing a closed socket resulting in many CLOSE_WAIT > > > Key: HBASE-9393 > URL: https://issues.apache.org/jira/browse/HBASE-9393 > Project: HBase > Issue Type: Bug >Affects Versions: 0.94.2, 0.98.0 > Environment: Centos 6.4 - 7 regionservers/datanodes, 8 TB per node, > 7279 regions >Reporter: Avi Zrachya >Assignee: Ashish Singhi >Priority: Critical > Fix For: 2.0.0 > > Attachments: HBASE-9393.patch, HBASE-9393.v1.patch, > HBASE-9393.v10.patch, HBASE-9393.v11.patch, HBASE-9393.v2.patch, > HBASE-9393.v3.patch, HBASE-9393.v4.patch, HBASE-9393.v5.patch, > HBASE-9393.v5.patch, HBASE-9393.v5.patch, HBASE-9393.v6.patch, > HBASE-9393.v6.patch, HBASE-9393.v6.patch, HBASE-9393.v7.patch, > HBASE-9393.v8.patch, HBASE-9393.v9.patch > > > HBase dose not close a dead connection with the datanode. > This resulting in over 60K CLOSE_WAIT and at some point HBase can not connect > to the datanode because too many mapped sockets from one host to another on > the same port. > The example below is with low CLOSE_WAIT count because we had to restart > hbase to solve the porblem, later in time it will incease to 60-100K sockets > on CLOSE_WAIT > [root@hd2-region3 ~]# netstat -nap |grep CLOSE_WAIT |grep 21592 |wc -l > 13156 > [root@hd2-region3 ~]# ps -ef |grep 21592 > root 17255 17219 0 12:26 pts/000:00:00 grep 21592 > hbase21592 1 17 Aug29 ?03:29:06 > /usr/java/jdk1.6.0_26/bin/java -XX:OnOutOfMemoryError=kill -9 %p -Xmx8000m > -ea -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode > -Dhbase.log.dir=/var/log/hbase > -Dhbase.log.file=hbase-hbase-regionserver-hd2-region3.swnet.corp.log ... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15144) Procedure v2 - Web UI displaying Store state
[ https://issues.apache.org/jira/browse/HBASE-15144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152520#comment-15152520 ] Matteo Bertozzi commented on HBASE-15144: - one last change. instead of totalSyncedUI = totalSynced.get(); you can assign totalSyncedUI when we do totalSynced.addAndGet(syncSlots()); we also have wal.getCorruptedLogs() you may display them as you do for wal.getActiveLogs() then you may move the 3 remaining syncWaitUI, slotIndexUI, syncedPerSecUI before the trace and use them in the LOG.trace() but this one is not really important since trace will be slow anyway. > Procedure v2 - Web UI displaying Store state > > > Key: HBASE-15144 > URL: https://issues.apache.org/jira/browse/HBASE-15144 > Project: HBase > Issue Type: Sub-task > Components: proc-v2, UI >Reporter: Matteo Bertozzi >Assignee: Samir Ahmic >Priority: Minor > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-15144_v0.patch, HBASE-15144_v1.patch, > WALStoreUI.png > > > The procedure webui page should show information about the WALProcedureStore. > * number/list/size of WALs active > * we may extract the "Sync wait %s, slotIndex=%s , totalSynced=%s (%s/sec)" > that today is only in LOG.trace() > * we have a getMillisToNextPeriodicRoll() and getMillisFromLastRoll() if > anyone want to see that -- This message was sent by Atlassian JIRA (v6.3.4#6332)
