subject:"\[jira\] \[Commented\] \(HBASE\-10147\) Canary additions"

[jira] [Commented] (HBASE-10147) Canary additions

2017-07-03 Thread Gustavo Anatoly (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-10147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16072299#comment-16072299
 ] 

Gustavo Anatoly commented on HBASE-10147:
-

Hi, [~stack]

Thanks for comment :)
 I'm going to rebase and prepare a new patch.

> Canary additions
> 
>
> Key: HBASE-10147
> URL: https://issues.apache.org/jira/browse/HBASE-10147
> Project: HBase
>  Issue Type: Improvement
>Reporter: stack
>Assignee: Gustavo Anatoly
> Attachments: HBASE-10147.patch, HBASE-10147.patch, HBASE-10147.patch, 
> HBASE-10147.patch, HBASE-10147-v2.patch, HBASE-10147-v3.patch, 
> HBASE-10147-v4.patch, HBASE-10147-v5.patch
>
>
> I've been using the canary to quickly identify the dodgy machine in my 
> cluster.  It is useful for this.  What would  make it better would be:
> + Rather than saying how long it took to get a region after you have gotten 
> the region, it'd be sweet to log BEFORE you went to get the region the 
> regionname and the server it is on.  I ask for this because as is, I have to 
> wait for the canary to timeout which can be a while.
> + Second ask is that when I pass the -t, that when it fails, it says what it 
> failed against -- what region and hopefully what server location (might be 
> hard).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-10147) Canary additions

2017-07-01 Thread Hadoop QA (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-10147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16071504#comment-16071504
 ] 

Hadoop QA commented on HBASE-10147:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue}  0m  
0s{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red}  0m  4s{color} 
| {color:red} HBASE-10147 does not apply to master. Rebase required? Wrong 
Branch? See https://yetus.apache.org/documentation/0.4.0/precommit-patchnames 
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HBASE-10147 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12622175/HBASE-10147-v5.patch |
| Console output | 
https://builds.apache.org/job/PreCommit-HBASE-Build/7450/console |
| Powered by | Apache Yetus 0.4.0   http://yetus.apache.org |


This message was automatically generated.



> Canary additions
> 
>
> Key: HBASE-10147
> URL: https://issues.apache.org/jira/browse/HBASE-10147
> Project: HBase
>  Issue Type: Improvement
>Reporter: stack
>Assignee: Gustavo Anatoly
> Attachments: HBASE-10147.patch, HBASE-10147.patch, HBASE-10147.patch, 
> HBASE-10147.patch, HBASE-10147-v2.patch, HBASE-10147-v3.patch, 
> HBASE-10147-v4.patch, HBASE-10147-v5.patch
>
>
> I've been using the canary to quickly identify the dodgy machine in my 
> cluster.  It is useful for this.  What would  make it better would be:
> + Rather than saying how long it took to get a region after you have gotten 
> the region, it'd be sweet to log BEFORE you went to get the region the 
> regionname and the server it is on.  I ask for this because as is, I have to 
> wait for the canary to timeout which can be a while.
> + Second ask is that when I pass the -t, that when it fails, it says what it 
> failed against -- what region and hopefully what server location (might be 
> hard).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-10147) Canary additions

2017-07-01 Thread stack (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-10147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16071496#comment-16071496
 ] 

stack commented on HBASE-10147:
---

Patch has gone stale (my fault). Code is different now. Unscheduling unless 
gets picked up for a rebase (still a good idea) 

> Canary additions
> 
>
> Key: HBASE-10147
> URL: https://issues.apache.org/jira/browse/HBASE-10147
> Project: HBase
>  Issue Type: Improvement
>Reporter: stack
>Assignee: Gustavo Anatoly
> Fix For: 2.0.0
>
> Attachments: HBASE-10147.patch, HBASE-10147.patch, HBASE-10147.patch, 
> HBASE-10147.patch, HBASE-10147-v2.patch, HBASE-10147-v3.patch, 
> HBASE-10147-v4.patch, HBASE-10147-v5.patch
>
>
> I've been using the canary to quickly identify the dodgy machine in my 
> cluster.  It is useful for this.  What would  make it better would be:
> + Rather than saying how long it took to get a region after you have gotten 
> the region, it'd be sweet to log BEFORE you went to get the region the 
> regionname and the server it is on.  I ask for this because as is, I have to 
> wait for the canary to timeout which can be a while.
> + Second ask is that when I pass the -t, that when it fails, it says what it 
> failed against -- what region and hopefully what server location (might be 
> hard).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-10147) Canary additions

2014-01-09 Thread Hadoop QA (JIRA)

[
https://issues.apache.org/jira/browse/HBASE-10147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13866674#comment-13866674
]

Hadoop QA commented on HBASE-10147:
---

{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12622175/HBASE-10147-v5.patch
against trunk revision .
ATTACHMENT ID: 12622175

{color:green}+1 @author{color}. The patch does not contain any @author
tags.

{color:red}-1 tests included{color}. 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:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.

{color:green}+1 hadoop1.1{color}. The patch compiles against the hadoop
1.1 profile.

{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.

{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.

{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.

{color:red}-1 release audit{color}. The applied patch generated 4 release
audit warnings (more than the trunk's current 0 warnings).

{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100

{color:red}-1 site{color}. The patch appears to cause mvn site goal to
fail.

{color:red}-1 core tests{color}. The patch failed these unit tests:

Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/8377//testReport/
Release audit warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8377//artifact/trunk/patchprocess/patchReleaseAuditProblems.txt
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8377//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8377//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8377//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8377//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8377//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8377//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8377//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8377//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8377//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/8377//console

This message is automatically generated.

Canary additions

Key: HBASE-10147
URL: https://issues.apache.org/jira/browse/HBASE-10147
Project: HBase
Issue Type: Improvement
Reporter: stack
Assignee: Gustavo Anatoly
Attachments: HBASE-10147-v2.patch, HBASE-10147-v3.patch,
HBASE-10147-v4.patch, HBASE-10147-v5.patch, HBASE-10147.patch,
HBASE-10147.patch, HBASE-10147.patch, HBASE-10147.patch

I've been using the canary to quickly identify the dodgy machine in my
cluster. It is useful for this. What would make it better would be:
+ Rather than saying how long it took to get a region after you have gotten
the region, it'd be sweet to log BEFORE you went to get the region the
regionname and the server it is on. I ask for this because as is, I have to
wait for the canary to timeout which can be a while.
+ Second ask is that when I pass the -t, that when it fails, it says what it
failed against -- what region and hopefully what server location (might be
hard).

--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (HBASE-10147) Canary additions

2014-01-07 Thread Gustavo Anatoly (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-10147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13864243#comment-13864243
 ] 

Gustavo Anatoly commented on HBASE-10147:
-

Hi, [~takeshi.miao]

What do you think, about  this changes:

1 - Rename method;
2 - Change output messages;

{code}
@Override
public void publishMonitorInfo(HRegionInfo region, ServerName serverName) {
  LOG.info(String.format(Monitoring Region: %s - ServerName: %s,
   region.getRegionNameAsString(), serverName.getServerName()));
}

@Override
public void publishMonitorInfoTimeout(HRegionInfo region, ServerName 
serverName) {
  LOG.info(String.format(Monitor Timeout Region: %s - ServerName: %s,
region.getRegionNameAsString(), serverName.getServerName()));
}
{code}

 Canary additions
 

 Key: HBASE-10147
 URL: https://issues.apache.org/jira/browse/HBASE-10147
 Project: HBase
  Issue Type: Improvement
Reporter: stack
Assignee: Gustavo Anatoly
 Attachments: HBASE-10147-v2.patch, HBASE-10147-v3.patch, 
 HBASE-10147-v4.patch, HBASE-10147.patch, HBASE-10147.patch, 
 HBASE-10147.patch, HBASE-10147.patch


 I've been using the canary to quickly identify the dodgy machine in my 
 cluster.  It is useful for this.  What would  make it better would be:
 + Rather than saying how long it took to get a region after you have gotten 
 the region, it'd be sweet to log BEFORE you went to get the region the 
 regionname and the server it is on.  I ask for this because as is, I have to 
 wait for the canary to timeout which can be a while.
 + Second ask is that when I pass the -t, that when it fails, it says what it 
 failed against -- what region and hopefully what server location (might be 
 hard).



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (HBASE-10147) Canary additions

2014-01-07 Thread takeshi.miao (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-10147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13864375#comment-13864375
 ] 

takeshi.miao commented on HBASE-10147:
--

hi [~gustavoanatoly]
{quote}
1 - Rename method;
2 - Change output messages;
{quote}
The public API for interface _Sink_ is broken again if you do this way... but I 
not so insist this due to as I said previously
bq.I not sure whether it is acceptable code change, that is ok if stack says 
ok, due to I think currently that not many users really extend this interface 
... ?
[~stack] how do you think ?

otherwise, your change is fine for me ;)



 Canary additions
 

 Key: HBASE-10147
 URL: https://issues.apache.org/jira/browse/HBASE-10147
 Project: HBase
  Issue Type: Improvement
Reporter: stack
Assignee: Gustavo Anatoly
 Attachments: HBASE-10147-v2.patch, HBASE-10147-v3.patch, 
 HBASE-10147-v4.patch, HBASE-10147.patch, HBASE-10147.patch, 
 HBASE-10147.patch, HBASE-10147.patch


 I've been using the canary to quickly identify the dodgy machine in my 
 cluster.  It is useful for this.  What would  make it better would be:
 + Rather than saying how long it took to get a region after you have gotten 
 the region, it'd be sweet to log BEFORE you went to get the region the 
 regionname and the server it is on.  I ask for this because as is, I have to 
 wait for the canary to timeout which can be a while.
 + Second ask is that when I pass the -t, that when it fails, it says what it 
 failed against -- what region and hopefully what server location (might be 
 hard).



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (HBASE-10147) Canary additions

2014-01-05 Thread takeshi.miao (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-10147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13862747#comment-13862747
 ] 

takeshi.miao commented on HBASE-10147:
--

Hi [~gustavoanatoly]
Leaving the legacy one '_Sink.publishReadTiming_' is fine to me, due to I think 
that their purpose is somehow different, 1) '_Sink.publishInfo_' is used to 
prompt user that what portion of the HBase the _monitor_ is going to test, 2) 
'_Sink.publishReadTiming_' is used to tell the user how long the test took.

[~stacke] How do you think ?

A reminder, the abbreviation seems need to be revised.
{code}
...tool.Canary (Canary.java:publishInfo(103)) - Read from Region: ...
...tool.Canary (Canary.java:publishReadTiming(97)) - read from region ...
{code}

 Canary additions
 

 Key: HBASE-10147
 URL: https://issues.apache.org/jira/browse/HBASE-10147
 Project: HBase
  Issue Type: Improvement
Reporter: stack
Assignee: Gustavo Anatoly
 Attachments: HBASE-10147-v2.patch, HBASE-10147-v3.patch, 
 HBASE-10147-v4.patch, HBASE-10147.patch, HBASE-10147.patch, 
 HBASE-10147.patch, HBASE-10147.patch


 I've been using the canary to quickly identify the dodgy machine in my 
 cluster.  It is useful for this.  What would  make it better would be:
 + Rather than saying how long it took to get a region after you have gotten 
 the region, it'd be sweet to log BEFORE you went to get the region the 
 regionname and the server it is on.  I ask for this because as is, I have to 
 wait for the canary to timeout which can be a while.
 + Second ask is that when I pass the -t, that when it fails, it says what it 
 failed against -- what region and hopefully what server location (might be 
 hard).



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (HBASE-10147) Canary additions

2014-01-03 Thread Hadoop QA (JIRA)

[
https://issues.apache.org/jira/browse/HBASE-10147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13861604#comment-13861604
]

Hadoop QA commented on HBASE-10147:
---

{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12621328/HBASE-10147-v4.patch
against trunk revision .
ATTACHMENT ID: 12621328

{color:green}+1 @author{color}. The patch does not contain any @author
tags.

{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.

{color:green}+1 hadoop1.1{color}. The patch compiles against the hadoop
1.1 profile.

{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.

{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.

{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.

{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.

{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100

{color:red}-1 site{color}. The patch appears to cause mvn site goal to
fail.

{color:red}-1 core tests{color}. The patch failed these unit tests:

Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/8332//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8332//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8332//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8332//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8332//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8332//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8332//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8332//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8332//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8332//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/8332//console

This message is automatically generated.

Canary additions

Key: HBASE-10147
URL: https://issues.apache.org/jira/browse/HBASE-10147
Project: HBase
Issue Type: Improvement
Reporter: stack
Assignee: Gustavo Anatoly
Attachments: HBASE-10147-v2.patch, HBASE-10147-v3.patch,
HBASE-10147-v4.patch, HBASE-10147.patch, HBASE-10147.patch,
HBASE-10147.patch, HBASE-10147.patch

--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (HBASE-10147) Canary additions

2014-01-02 Thread Hadoop QA (JIRA)

[
https://issues.apache.org/jira/browse/HBASE-10147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13861078#comment-13861078
]

Hadoop QA commented on HBASE-10147:
---

{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12621065/HBASE-10147-v3.patch
against trunk revision .
ATTACHMENT ID: 12621065

{color:green}+1 @author{color}. The patch does not contain any @author
tags.

{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.

{color:green}+1 hadoop1.1{color}. The patch compiles against the hadoop
1.1 profile.

{color:red}-1 javadoc{color}. The javadoc tool appears to have generated
11 warning messages.

{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.

{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.

{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.

{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100

{color:red}-1 site{color}. The patch appears to cause mvn site goal to
fail.

{color:red}-1 core tests{color}. The patch failed these unit tests:

Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/8317//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8317//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8317//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8317//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8317//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8317//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8317//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8317//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8317//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8317//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/8317//console

This message is automatically generated.

Canary additions

Key: HBASE-10147
URL: https://issues.apache.org/jira/browse/HBASE-10147
Project: HBase
Issue Type: Improvement
Reporter: stack
Assignee: Gustavo Anatoly
Attachments: HBASE-10147-v2.patch, HBASE-10147-v3.patch,
HBASE-10147.patch, HBASE-10147.patch, HBASE-10147.patch, HBASE-10147.patch

--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (HBASE-10147) Canary additions

2014-01-02 Thread takeshi.miao (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-10147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13861158#comment-13861158
 ] 

takeshi.miao commented on HBASE-10147:
--

[~gustavoanatoly]
1. For backward compatible for method _Sink.publishReadTiming_, I think that we 
still need to keep the method calls in the code, which means that the following 
code snippet should not be removed...
{code}
@@ -521,12 +537,10 @@
   stopWatch.start();
   table.get(get);
   stopWatch.stop();
-  sink.publishReadTiming(region, column, stopWatch.getTime());
 } else {
   stopWatch.start();
   rs = table.getScanner(scan);
   stopWatch.stop();
-  sink.publishReadTiming(region, column, stopWatch.getTime());
 }
   } catch (Exception e) {
 sink.publishReadFailure(region, column, e);
@@ -624,7 +662,6 @@
 table.getScanner(scan);
 stopWatch.stop();
   }
-  this.getSink().publishReadTiming(tableName, serverName, 
stopWatch.getTime());
 } catch (TableNotFoundException tnfe) {
   // This is ignored because it doesn't imply that the regionserver is 
dead
 } catch (TableNotEnabledException tnee) {
{code}

2. We can leave the method impl for _Sink.publishReadTiming_ to do nothing
{code}
public static class StdOutSink implements Sink {
  //...
  public void publishReadTiming(HRegionInfo region, HColumnDescriptor 
column, long msTime) {
//DO NOTHING, for API backward compatibility
  }
  //...
}
{code}

3. The _Deprecated_ should put on the _interface_
{code}
  public interface Sink {
  //...
  /**
   * This method will be removed in the future release.
   * @deprecated {@link https://issues.apache.org/jira/browse/HBASE-10147}
   */
  @Deprecated
  public void publishReadTiming(HRegionInfo region, HColumnDescriptor 
column, long msTime);
  //...
}

public static class StdOutSink implements Sink {
  //...
  @Override
  @Deprecated
  public void publishReadTiming(HRegionInfo region, HColumnDescriptor 
column, long msTime) {
//...
  }
  //...
}
  }
{code}


 Canary additions
 

 Key: HBASE-10147
 URL: https://issues.apache.org/jira/browse/HBASE-10147
 Project: HBase
  Issue Type: Improvement
Reporter: stack
Assignee: Gustavo Anatoly
 Attachments: HBASE-10147-v2.patch, HBASE-10147-v3.patch, 
 HBASE-10147.patch, HBASE-10147.patch, HBASE-10147.patch, HBASE-10147.patch


 I've been using the canary to quickly identify the dodgy machine in my 
 cluster.  It is useful for this.  What would  make it better would be:
 + Rather than saying how long it took to get a region after you have gotten 
 the region, it'd be sweet to log BEFORE you went to get the region the 
 regionname and the server it is on.  I ask for this because as is, I have to 
 wait for the canary to timeout which can be a while.
 + Second ask is that when I pass the -t, that when it fails, it says what it 
 failed against -- what region and hopefully what server location (might be 
 hard).



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (HBASE-10147) Canary additions

2013-12-30 Thread Hadoop QA (JIRA)

[
https://issues.apache.org/jira/browse/HBASE-10147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13858896#comment-13858896
]

Hadoop QA commented on HBASE-10147:
---

{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12620839/HBASE-10147-v2.patch
against trunk revision .
ATTACHMENT ID: 12620839

{color:green}+1 @author{color}. The patch does not contain any @author
tags.

{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.

{color:green}+1 hadoop1.1{color}. The patch compiles against the hadoop
1.1 profile.

{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.

{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.

{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.

{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.

{color:red}-1 lineLengths{color}. The patch introduces the following lines
longer than 100:

{color:red}-1 site{color}. The patch appears to cause mvn site goal to
fail.

{color:red}-1 core tests{color}. The patch failed these unit tests:

Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/8305//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8305//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8305//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8305//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8305//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8305//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8305//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8305//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8305//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8305//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/8305//console

This message is automatically generated.

Canary additions

Key: HBASE-10147
URL: https://issues.apache.org/jira/browse/HBASE-10147
Project: HBase
Issue Type: Improvement
Reporter: stack
Assignee: Gustavo Anatoly
Attachments: HBASE-10147-v2.patch, HBASE-10147.patch,
HBASE-10147.patch, HBASE-10147.patch, HBASE-10147.patch

--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (HBASE-10147) Canary additions

2013-12-30 Thread takeshi.miao (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-10147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859293#comment-13859293
 ] 

takeshi.miao commented on HBASE-10147:
--

Hi [~gustavoanatoly], 
 about _Sink_ API usage, I found only inside _Canary_ Tool
This API is not depended by other codes in HBase project, but I mentioned
 The public API is broken, since the Sink interface is changed
which means that if I am a HBase user, I may want to extends this _'Sink'_ 
interface for other monitoring purpose if I see the [API doc 
|http://hbase.apache.org/devapidocs/org/apache/hadoop/hbase/tool/Canary.html#nested_class_summary];
 For example, I could extend the _Sink_ API to provide a JDBC impl. to let the 
_Sink_ push data to RDBMS for monitoring purpose, or something like that. The 
_Sink_ interface had been _*public*_ from first release till now (0.92, you can 
see HBASE-4393), so I am not sure how many users in the world would use this 
kind of feature to make their _Sink_ impl.; I need to point it out that this is 
a public API change and which might impact users' currently smooth running 
monitoring mechanism. Simply change the API and point it out in the release 
notes is a good way as well, I think.

BTW, why we remove the _table.close()_ in the patch-v02 ?
{code}
 @@ -472,17 +472,13 @@
return;
  }
  
 -try {
 -  for (HRegionInfo region : admin.getTableRegions(tableDesc.getName())) {
 -try {
 -  sniffRegion(admin, sink, region, table);
 -} catch (Exception e) {
 -  sink.publishReadFailure(region, e);
 -  LOG.debug(sniffRegion failed, e);
 -}
 +for (HRegionInfo region : admin.getTableRegions(tableDesc.getName())) {
 +  try {
 +sniffRegion(admin, sink, region, table);
 +  } catch (Exception e) {
 +sink.publishReadFailure(region, e);
 +LOG.debug(sniffRegion failed, e);
}
 -} finally {
 -  table.close(); // --- I mean here by takeshi.miao
  }
{code}


 Canary additions
 

 Key: HBASE-10147
 URL: https://issues.apache.org/jira/browse/HBASE-10147
 Project: HBase
  Issue Type: Improvement
Reporter: stack
Assignee: Gustavo Anatoly
 Attachments: HBASE-10147-v2.patch, HBASE-10147.patch, 
 HBASE-10147.patch, HBASE-10147.patch, HBASE-10147.patch


 I've been using the canary to quickly identify the dodgy machine in my 
 cluster.  It is useful for this.  What would  make it better would be:
 + Rather than saying how long it took to get a region after you have gotten 
 the region, it'd be sweet to log BEFORE you went to get the region the 
 regionname and the server it is on.  I ask for this because as is, I have to 
 wait for the canary to timeout which can be a while.
 + Second ask is that when I pass the -t, that when it fails, it says what it 
 failed against -- what region and hopefully what server location (might be 
 hard).



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (HBASE-10147) Canary additions

2013-12-30 Thread takeshi.miao (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-10147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859314#comment-13859314
 ] 

takeshi.miao commented on HBASE-10147:
--

hi [~gustavoanatoly],
I just refresh my memory to call out there is a simple way to deal with the 
public _Sink_ API change is...
to add _deprecate_ on this one obsolete methods in it. for example...
{code}
 public interface Sink {
   public void publishReadFailure(HRegionInfo region, Exception e);
   public void publishReadFailure(HRegionInfo region, HColumnDescriptor column, 
Exception e);
   @deprecate // this method will removed in the future release
   public void publishReadTiming(HRegionInfo region, HColumnDescriptor column, 
long msTime);
   public void publishInfo(HRegionInfo region, ServerName serverName);
   public void publishInfoTimeout(HRegionInfo region, ServerName serverName);
 }
{code}

 Canary additions
 

 Key: HBASE-10147
 URL: https://issues.apache.org/jira/browse/HBASE-10147
 Project: HBase
  Issue Type: Improvement
Reporter: stack
Assignee: Gustavo Anatoly
 Attachments: HBASE-10147-v2.patch, HBASE-10147.patch, 
 HBASE-10147.patch, HBASE-10147.patch, HBASE-10147.patch


 I've been using the canary to quickly identify the dodgy machine in my 
 cluster.  It is useful for this.  What would  make it better would be:
 + Rather than saying how long it took to get a region after you have gotten 
 the region, it'd be sweet to log BEFORE you went to get the region the 
 regionname and the server it is on.  I ask for this because as is, I have to 
 wait for the canary to timeout which can be a while.
 + Second ask is that when I pass the -t, that when it fails, it says what it 
 failed against -- what region and hopefully what server location (might be 
 hard).



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (HBASE-10147) Canary additions

2013-12-29 Thread takeshi.miao (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-10147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13858374#comment-13858374
 ] 

takeshi.miao commented on HBASE-10147:
--

[~stack]  [~gustavoanatoly]
This patch also looks good to me, but still has some questions need to verify, 
are...
1. The public API is broken, since the _Sink interface_ is changed
{code}
@@ -66,7 +66,8 @@
   public interface Sink {
 public void publishReadFailure(HRegionInfo region, Exception e);
 public void publishReadFailure(HRegionInfo region, HColumnDescriptor 
column, Exception e);
-public void publishReadTiming(HRegionInfo region, HColumnDescriptor 
column, long msTime);
+public void publishInfo(HRegionInfo region, ServerName serverName);
+public void publishInfoTimeout(HRegionInfo region, ServerName serverName);
   }
{code}
I not sure whether it is acceptable code change, that is ok if stack says ok, 
due to I think currently that not many users really extend this _interface_ ... 
?

2. I think that the _errorCode_ property would be better to be _volatile_. due 
to it would be manipulated by the _monitor_ thread, and read by _main_ thread 
in the same time.
{code}
#140  private static int errorCode;
// changed to
#140  private static volatile int errorCode;
{code}
And other changed static properties will be ok due to their value manipulation 
are not intervened between two threads in the same time.
{code}
#136  private static long timeout = DEFAULT_TIMEOUT;
#137  private static boolean failOnError = true;
//...
#139  private static long startTimeCanary;
{code}

3.  Just a little reminder that the _this_ reference shall be removed due to 
_failOnError_ is changed to _static_
{code}
#224  this.failOnError = Boolean.parseBoolean(args[i]);
//...
#249  if (this.failOnError  monitor.hasError()) {
//...
#255  if (this.failOnError  monitor.hasError()) {
{code}

FYR~

 Canary additions
 

 Key: HBASE-10147
 URL: https://issues.apache.org/jira/browse/HBASE-10147
 Project: HBase
  Issue Type: Improvement
Reporter: stack
Assignee: Gustavo Anatoly
 Attachments: HBASE-10147.patch, HBASE-10147.patch, HBASE-10147.patch, 
 HBASE-10147.patch


 I've been using the canary to quickly identify the dodgy machine in my 
 cluster.  It is useful for this.  What would  make it better would be:
 + Rather than saying how long it took to get a region after you have gotten 
 the region, it'd be sweet to log BEFORE you went to get the region the 
 regionname and the server it is on.  I ask for this because as is, I have to 
 wait for the canary to timeout which can be a while.
 + Second ask is that when I pass the -t, that when it fails, it says what it 
 failed against -- what region and hopefully what server location (might be 
 hard).



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (HBASE-10147) Canary additions

2013-12-29 Thread Gustavo Anatoly (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-10147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13858395#comment-13858395
 ] 

Gustavo Anatoly commented on HBASE-10147:
-

Thanks, [~takeshi.miao] for review the patch.

I will run another tests with your advices and verify some impacts. 

 Canary additions
 

 Key: HBASE-10147
 URL: https://issues.apache.org/jira/browse/HBASE-10147
 Project: HBase
  Issue Type: Improvement
Reporter: stack
Assignee: Gustavo Anatoly
 Attachments: HBASE-10147.patch, HBASE-10147.patch, HBASE-10147.patch, 
 HBASE-10147.patch


 I've been using the canary to quickly identify the dodgy machine in my 
 cluster.  It is useful for this.  What would  make it better would be:
 + Rather than saying how long it took to get a region after you have gotten 
 the region, it'd be sweet to log BEFORE you went to get the region the 
 regionname and the server it is on.  I ask for this because as is, I have to 
 wait for the canary to timeout which can be a while.
 + Second ask is that when I pass the -t, that when it fails, it says what it 
 failed against -- what region and hopefully what server location (might be 
 hard).



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (HBASE-10147) Canary additions

2013-12-27 Thread stack (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-10147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13857575#comment-13857575
 ] 

stack commented on HBASE-10147:
---

I took a quick skim of the patch; looks good.  Mind pasting how the output has 
changed w/ the addition of this patch [~gustavoanatoly]?  [~takeshi.miao] Any 
opinion on this patch?  Thanks.

 Canary additions
 

 Key: HBASE-10147
 URL: https://issues.apache.org/jira/browse/HBASE-10147
 Project: HBase
  Issue Type: Improvement
Reporter: stack
Assignee: Gustavo Anatoly
 Attachments: HBASE-10147.patch, HBASE-10147.patch


 I've been using the canary to quickly identify the dodgy machine in my 
 cluster.  It is useful for this.  What would  make it better would be:
 + Rather than saying how long it took to get a region after you have gotten 
 the region, it'd be sweet to log BEFORE you went to get the region the 
 regionname and the server it is on.  I ask for this because as is, I have to 
 wait for the canary to timeout which can be a while.
 + Second ask is that when I pass the -t, that when it fails, it says what it 
 failed against -- what region and hopefully what server location (might be 
 hard).



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (HBASE-10147) Canary additions

2013-12-27 Thread Hadoop QA (JIRA)

[
https://issues.apache.org/jira/browse/HBASE-10147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13857624#comment-13857624
]

Hadoop QA commented on HBASE-10147:
---

{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12620624/HBASE-10147.patch
against trunk revision .
ATTACHMENT ID: 12620624