date:20131226

[jira] [Commented] (HBASE-8731) Use the JDK 1.7 in the precommit env for trunk

2013-12-26 Thread Nicolas Liochon (JIRA)


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

Nicolas Liochon commented on HBASE-8731:


On precommit, we don't own the script the script that changes the variable.
A while ago, I spoke to Giri who said he could change this for us, and ask me 
to create this jira. I reopen it, so :-)

 Use the JDK 1.7 in the precommit env for trunk
 --

 Key: HBASE-8731
 URL: https://issues.apache.org/jira/browse/HBASE-8731
 Project: HBase
  Issue Type: Improvement
  Components: build
Affects Versions: 0.98.0
Reporter: Nicolas Liochon
Assignee: Giridharan Kesavan
 Fix For: 0.98.0


 HBase today uses the jdk 1.6. In the past it created issues when we tried to 
 use 1.7 for the core build while the precommit was on 1.6.
 Having the precommit on 1.7 would solve this.
 The best is to start with trunk. Likely 0.95 will come next, and may be, a 
 day, 0.94.



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

[jira] [Reopened] (HBASE-8731) Use the JDK 1.7 in the precommit env for trunk

2013-12-26 Thread Nicolas Liochon (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-8731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nicolas Liochon reopened HBASE-8731:


  Assignee: Giridharan Kesavan  (was: stack)

 Use the JDK 1.7 in the precommit env for trunk
 --

 Key: HBASE-8731
 URL: https://issues.apache.org/jira/browse/HBASE-8731
 Project: HBase
  Issue Type: Improvement
  Components: build
Affects Versions: 0.98.0
Reporter: Nicolas Liochon
Assignee: Giridharan Kesavan
 Fix For: 0.98.0


 HBase today uses the jdk 1.6. In the past it created issues when we tried to 
 use 1.7 for the core build while the precommit was on 1.6.
 Having the precommit on 1.7 would solve this.
 The best is to start with trunk. Likely 0.95 will come next, and may be, a 
 day, 0.94.



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

[jira] [Comment Edited] (HBASE-8731) Use the JDK 1.7 in the precommit env for trunk

2013-12-26 Thread Nicolas Liochon (JIRA)


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

Nicolas Liochon edited comment on HBASE-8731 at 12/26/13 9:53 AM:
--

On precommit, we don't own the script that changes the variable.
A while ago, I spoke to Giri who said he could change this for us, and ask me 
to create this jira. I reopen it, so :-)


was (Author: nkeywal):
On precommit, we don't own the script the script that changes the variable.
A while ago, I spoke to Giri who said he could change this for us, and ask me 
to create this jira. I reopen it, so :-)

 Use the JDK 1.7 in the precommit env for trunk
 --

 Key: HBASE-8731
 URL: https://issues.apache.org/jira/browse/HBASE-8731
 Project: HBase
  Issue Type: Improvement
  Components: build
Affects Versions: 0.99.0
Reporter: Nicolas Liochon
Assignee: Giridharan Kesavan

 HBase today uses the jdk 1.6. In the past it created issues when we tried to 
 use 1.7 for the core build while the precommit was on 1.6.
 Having the precommit on 1.7 would solve this.
 The best is to start with trunk. Likely 0.95 will come next, and may be, a 
 day, 0.94.



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

[jira] [Updated] (HBASE-8731) Use the JDK 1.7 in the precommit env for trunk

2013-12-26 Thread Nicolas Liochon (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-8731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nicolas Liochon updated HBASE-8731:
---

Affects Version/s: (was: 0.98.0)
   0.99.0

 Use the JDK 1.7 in the precommit env for trunk
 --

 Key: HBASE-8731
 URL: https://issues.apache.org/jira/browse/HBASE-8731
 Project: HBase
  Issue Type: Improvement
  Components: build
Affects Versions: 0.99.0
Reporter: Nicolas Liochon
Assignee: Giridharan Kesavan

 HBase today uses the jdk 1.6. In the past it created issues when we tried to 
 use 1.7 for the core build while the precommit was on 1.6.
 Having the precommit on 1.7 would solve this.
 The best is to start with trunk. Likely 0.95 will come next, and may be, a 
 day, 0.94.



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

[jira] [Updated] (HBASE-8731) Use the JDK 1.7 in the precommit env for trunk

2013-12-26 Thread Nicolas Liochon (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-8731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nicolas Liochon updated HBASE-8731:
---

Fix Version/s: (was: 0.98.0)

 Use the JDK 1.7 in the precommit env for trunk
 --

 Key: HBASE-8731
 URL: https://issues.apache.org/jira/browse/HBASE-8731
 Project: HBase
  Issue Type: Improvement
  Components: build
Affects Versions: 0.99.0
Reporter: Nicolas Liochon
Assignee: Giridharan Kesavan

 HBase today uses the jdk 1.6. In the past it created issues when we tried to 
 use 1.7 for the core build while the precommit was on 1.6.
 Having the precommit on 1.7 would solve this.
 The best is to start with trunk. Likely 0.95 will come next, and may be, a 
 day, 0.94.



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

[jira] [Commented] (HBASE-7226) HRegion.checkAndMutate uses incorrect comparison result for , =, and =

2013-12-26 Thread Hudson (JIRA)


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

Hudson commented on HBASE-7226:
---

SUCCESS: Integrated in HBase-0.98-on-Hadoop-1.1 #37 (See 
[https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/37/])
HBASE-7226 HRegion.checkAndMutate uses incorrect comparison result for , =,  
and = (tedyu: rev 1553454)
* 
/hbase/branches/0.98/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
* 
/hbase/branches/0.98/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestHRegion.java


 HRegion.checkAndMutate uses incorrect comparison result for , =,  and =
 ---

 Key: HBASE-7226
 URL: https://issues.apache.org/jira/browse/HBASE-7226
 Project: HBase
  Issue Type: Bug
  Components: regionserver
Reporter: Feng Honghua
Assignee: Feng Honghua
 Fix For: 0.98.0, 0.94.16, 0.99.0

 Attachments: HBASE-7226-trunk-v2.patch, HBASE-7226-trunk.patch, 
 HRegion_HBASE_7226_0.94.2.patch


 in HRegion.checkAndMutate, incorrect comparison results are used for , =,  
 and =, as below:
   switch (compareOp) {
   case LESS:
 matches = compareResult = 0;  // should be '' here
 break;
   case LESS_OR_EQUAL:
 matches = compareResult  0;  // should be '=' here
 break;
   case EQUAL:
 matches = compareResult == 0;
 break;
   case NOT_EQUAL:
 matches = compareResult != 0;
 break;
   case GREATER_OR_EQUAL:
 matches = compareResult  0;  // should be '=' here
 break;
   case GREATER:
 matches = compareResult = 0;  // should be '' here
 break;



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

[jira] [Commented] (HBASE-6104) Require EXEC permission to call coprocessor endpoints

2013-12-26 Thread Hudson (JIRA)


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

Hudson commented on HBASE-6104:
---

FAILURE: Integrated in HBase-TRUNK #4761 (See 
[https://builds.apache.org/job/HBase-TRUNK/4761/])
Revert HBASE-6104. Revert initial commit and addendum (apurtell: rev 1553450)
* 
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/EndpointObserver.java
* 
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
* 
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RegionCoprocessorHost.java
* 
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/AccessController.java
* 
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestAccessController.java
* 
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/security/visibility/TestVisibilityLabelsWithACL.java
Amend HBASE-6104. TestAccessController#testCoprocessorExec is improperly 
failing (apurtell: rev 1553446)
* 
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestAccessController.java


 Require EXEC permission to call coprocessor endpoints
 -

 Key: HBASE-6104
 URL: https://issues.apache.org/jira/browse/HBASE-6104
 Project: HBase
  Issue Type: New Feature
  Components: Coprocessors, security
Reporter: Gary Helmling
Assignee: Andrew Purtell
 Fix For: 0.99.0

 Attachments: 6104-addendum-1.patch, 6104-revert.patch, 6104.patch, 
 6104.patch, 6104.patch, 6104.patch, 6104.patch


 The EXEC action currently exists as only a placeholder in access control.  It 
 should really be used to enforce access to coprocessor endpoint RPC calls, 
 which are currently unrestricted.
 How the ACLs to support this would be modeled deserves some discussion:
 * Should access be scoped to a specific table and CoprocessorProtocol 
 extension?
 * Should it be possible to grant access to a CoprocessorProtocol 
 implementation globally (regardless of table)?
 * Are per-method restrictions necessary?
 * Should we expose hooks available to endpoint implementors so that they 
 could additionally apply their own permission checks? Some CP endpoints may 
 want to require READ permissions, others may want to enforce WRITE, or READ + 
 WRITE.
 To apply these kinds of checks we would also have to extend the 
 RegionObserver interface to provide hooks wrapping HRegion.exec().



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

[jira] [Commented] (HBASE-7226) HRegion.checkAndMutate uses incorrect comparison result for , =, and =

2013-12-26 Thread Hudson (JIRA)


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

Hudson commented on HBASE-7226:
---

FAILURE: Integrated in HBase-TRUNK #4761 (See 
[https://builds.apache.org/job/HBase-TRUNK/4761/])
HBASE-7226 HRegion.checkAndMutate uses incorrect comparison result for , =,  
and = (tedyu: rev 1553453)
* 
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
* 
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestHRegion.java


 HRegion.checkAndMutate uses incorrect comparison result for , =,  and =
 ---

 Key: HBASE-7226
 URL: https://issues.apache.org/jira/browse/HBASE-7226
 Project: HBase
  Issue Type: Bug
  Components: regionserver
Reporter: Feng Honghua
Assignee: Feng Honghua
 Fix For: 0.98.0, 0.94.16, 0.99.0

 Attachments: HBASE-7226-trunk-v2.patch, HBASE-7226-trunk.patch, 
 HRegion_HBASE_7226_0.94.2.patch


 in HRegion.checkAndMutate, incorrect comparison results are used for , =,  
 and =, as below:
   switch (compareOp) {
   case LESS:
 matches = compareResult = 0;  // should be '' here
 break;
   case LESS_OR_EQUAL:
 matches = compareResult  0;  // should be '=' here
 break;
   case EQUAL:
 matches = compareResult == 0;
 break;
   case NOT_EQUAL:
 matches = compareResult != 0;
 break;
   case GREATER_OR_EQUAL:
 matches = compareResult  0;  // should be '=' here
 break;
   case GREATER:
 matches = compareResult = 0;  // should be '' here
 break;



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

[jira] [Commented] (HBASE-10238) TestAccessController#verifyDenied can fail even if ADE is thrown

2013-12-26 Thread Hudson (JIRA)


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

Hudson commented on HBASE-10238:


FAILURE: Integrated in HBase-TRUNK #4761 (See 
[https://builds.apache.org/job/HBase-TRUNK/4761/])
Revert HBASE-10238. Revert initial commit and addendum (apurtell: rev 1553442)
* 
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestAccessController.java
Amend HBASE-10238. Special case for UndeclaredThrowableException (apurtell: rev 
1553438)
* 
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestAccessController.java


 TestAccessController#verifyDenied can fail even if ADE is thrown
 

 Key: HBASE-10238
 URL: https://issues.apache.org/jira/browse/HBASE-10238
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.98.0, 0.99.0
Reporter: Andrew Purtell
Assignee: Andrew Purtell
 Attachments: 10238-addendum-1.patch, 10238.patch


 In TestAccessController#verifyDenied there is code attempting to deal with 
 UTEs with AccessDeniedException as a nested cause. Although it would seem the 
 code intends to handle the exception reported by a recently failed test on 
 the 0.98 Hadoop 1.1 Jenkins build here:
 {noformat}
 java.lang.reflect.UndeclaredThrowableException: Unknown exception in doAs
 Caused by: java.security.PrivilegedActionException: 
 com.google.protobuf.ServiceException: Error calling method PingService.noop
 Caused by: com.google.protobuf.ServiceException: Error calling method 
 PingService.noop
 Caused by: 
 org.apache.hadoop.hbase.security.AccessDeniedExceptionorg.apache.hadoop.hbase.security.AccessDeniedException:
  Insufficient permissions (user=UserB, scope=testCoprocessorExec, family=, 
 action=EXEC)
 Caused by: org.apache.hadoop.hbase.ipc.RemoteWithExtrasException: 
 org.apache.hadoop.hbase.security.AccessDeniedException: Insufficient 
 permissions (user=UserB, scope=testCoprocessorExec, family=, action=EXEC)
 ...
 {noformat}
 it didn't work properly.



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

[jira] [Updated] (HBASE-7386) Investigate providing some supervisor support for znode deletion

2013-12-26 Thread Samir Ahmic (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-7386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Samir Ahmic updated HBASE-7386:
---

Attachment: HBASE-7386-src.patch
HBASE-7386-conf.patch
HBASE-7386-bin.patch

 Investigate providing some supervisor support for znode deletion
 

 Key: HBASE-7386
 URL: https://issues.apache.org/jira/browse/HBASE-7386
 Project: HBase
  Issue Type: Task
  Components: master, regionserver, scripts
Reporter: Gregory Chanan
Assignee: stack
Priority: Blocker
 Attachments: HBASE-7386-bin.patch, HBASE-7386-conf.patch, 
 HBASE-7386-src.patch, HBASE-7386-v0.patch, supervisordconfigs-v0.patch


 There a couple of JIRAs for deleting the znode on a process failure:
 HBASE-5844 (RS)
 HBASE-5926 (Master)
 which are pretty neat; on process failure, they delete the znode of the 
 underlying process so HBase can recover faster.
 These JIRAs were implemented via the startup scripts; i.e. the script hangs 
 around and waits for the process to exit, then deletes the znode.
 There are a few problems associated with this approach, as listed in the 
 below JIRAs:
 1) Hides startup output in script
 https://issues.apache.org/jira/browse/HBASE-5844?focusedCommentId=13463401page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13463401
 2) two hbase processes listed per launched daemon
 https://issues.apache.org/jira/browse/HBASE-5844?focusedCommentId=13463409page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13463409
 3) Not run by a real supervisor
 https://issues.apache.org/jira/browse/HBASE-5844?focusedCommentId=13463409page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13463409
 4) Weird output after kill -9 actual process in standalone mode
 https://issues.apache.org/jira/browse/HBASE-5926?focusedCommentId=13506801page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13506801
 5) Can kill existing RS if called again
 https://issues.apache.org/jira/browse/HBASE-5844?focusedCommentId=13463401page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13463401
 6) Hides stdout/stderr[6]
 https://issues.apache.org/jira/browse/HBASE-5844?focusedCommentId=13506832page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13506832
 I suspect running in via something like supervisor.d can solve these issues 
 if we provide the right support.



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

[jira] [Commented] (HBASE-7386) Investigate providing some supervisor support for znode deletion

2013-12-26 Thread Samir Ahmic (JIRA)


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

Samir Ahmic commented on HBASE-7386:


Based on what was discussed here i have created set of scripts and configs that 
support running hbase processes under python supervisor control. I did not 
touch any scrips from bin directory as i see this as optional solution for 
managing hbase processes. Only change in hbase source is adding 'autorestart' 
option in HMasterCommandLine.java.  Scripts does not require any config changes 
or additional env variables. 
All testing was done on 0.96 branch and partially on 0.94 using supervisor 3.0 
version, OS was Centos 5.8 and 5.10.
All suggestions and critics are welcome:)
Cheers

 Investigate providing some supervisor support for znode deletion
 

 Key: HBASE-7386
 URL: https://issues.apache.org/jira/browse/HBASE-7386
 Project: HBase
  Issue Type: Task
  Components: master, regionserver, scripts
Reporter: Gregory Chanan
Assignee: stack
Priority: Blocker
 Attachments: HBASE-7386-bin.patch, HBASE-7386-conf.patch, 
 HBASE-7386-src.patch, HBASE-7386-v0.patch, supervisordconfigs-v0.patch


 There a couple of JIRAs for deleting the znode on a process failure:
 HBASE-5844 (RS)
 HBASE-5926 (Master)
 which are pretty neat; on process failure, they delete the znode of the 
 underlying process so HBase can recover faster.
 These JIRAs were implemented via the startup scripts; i.e. the script hangs 
 around and waits for the process to exit, then deletes the znode.
 There are a few problems associated with this approach, as listed in the 
 below JIRAs:
 1) Hides startup output in script
 https://issues.apache.org/jira/browse/HBASE-5844?focusedCommentId=13463401page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13463401
 2) two hbase processes listed per launched daemon
 https://issues.apache.org/jira/browse/HBASE-5844?focusedCommentId=13463409page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13463409
 3) Not run by a real supervisor
 https://issues.apache.org/jira/browse/HBASE-5844?focusedCommentId=13463409page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13463409
 4) Weird output after kill -9 actual process in standalone mode
 https://issues.apache.org/jira/browse/HBASE-5926?focusedCommentId=13506801page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13506801
 5) Can kill existing RS if called again
 https://issues.apache.org/jira/browse/HBASE-5844?focusedCommentId=13463401page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13463401
 6) Hides stdout/stderr[6]
 https://issues.apache.org/jira/browse/HBASE-5844?focusedCommentId=13506832page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13506832
 I suspect running in via something like supervisor.d can solve these issues 
 if we provide the right support.



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

[jira] [Commented] (HBASE-10229) Support OperationAttributes in Increment and Append in Shell

2013-12-26 Thread ramkrishna.s.vasudevan (JIRA)


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

ramkrishna.s.vasudevan commented on HBASE-10229:


I plan to commit this if all are fine with this.  This would help me to give 
the final patch for HBASE-10228.  I have it but thought it would be better if I 
update it after this goes in.

 Support OperationAttributes in Increment and Append in Shell
 

 Key: HBASE-10229
 URL: https://issues.apache.org/jira/browse/HBASE-10229
 Project: HBase
  Issue Type: Improvement
  Components: shell
Affects Versions: 0.98.0
Reporter: ramkrishna.s.vasudevan
Assignee: ramkrishna.s.vasudevan
 Attachments: HBASE-10229_1.patch






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

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

2013-12-26 Thread Gustavo Anatoly (JIRA)


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

Gustavo Anatoly updated HBASE-10147:


Attachment: HBASE-10147.patch

Hi, Stack.

Could you please review the 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


 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-10169) Batch coprocessor

2013-12-26 Thread Jingcheng Du (JIRA)


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

Jingcheng Du commented on HBASE-10169:
--

[~ghelmling], [~apurtell]. Hi Gary, Andy.  It's a good idea to return the 
CoprocessorServiceResponse in a batch without combining in the server side. But 
it's very difficult to implement the coprocessor transparently.
   In the HTable, we have the method public T extends Service, R 
Mapbyte[],R coprocessorService(final ClassT service, byte[] startKey, 
byte[] endKey, final Batch.CallT,R callable). The Batch.call allows users to 
decide how to execute the coprocessor.
  final RegionCoprocessorRpcChannel channel = new 
RegionCoprocessorRpcChannel(connection, tableName, r);
  T instance = ProtobufUtil.newServiceStub(service, channel);
  R result = callable.call(instance);
  The RegionCoprocessorRpcChannel executes the HRegionServer.execService 
against a single region each time. If we use a 
RegionServerCoprocessorRpcChannel to directly invoke the 
HRegionServer.execMultiService() instead, the returned value of the 
callable.call(instance) should be ListR, which is not right. 
  So it's difficult to have the batch execution for coprocessor service.in a 
transparent way.
  Maybe we could add a new API for the HTable, like public T extends Service, 
R Mapbyte[],R coprocessorService(final ClassT service, 
Descriptors.MethodDescriptor method, byte[] startKey, byte[] endKey) to 
realize the batch coprocessor execution. But users are not allowed to decide 
how to execute the coprocessor since the Batch.Call is not in the arguments any 
more.
  How do you think about this? Please help advise. Thanks!

 Batch coprocessor
 -

 Key: HBASE-10169
 URL: https://issues.apache.org/jira/browse/HBASE-10169
 Project: HBase
  Issue Type: Sub-task
  Components: Coprocessors
Affects Versions: 0.99.0
Reporter: Jingcheng Du
Assignee: Jingcheng Du
 Attachments: Batch Coprocessor Design Document.docx, HBASE-10169.patch


 This is designed to improve the coprocessor invocation in the client side. 
 Currently the coprocessor invocation is to send a call to each region. If 
 there’s one region server, and 100 regions are located in this server, each 
 coprocessor invocation will send 100 calls, each call uses a single thread in 
 the client side. The threads will run out soon when the coprocessor 
 invocations are heavy. 
 In this design, all the calls to the same region server will be grouped into 
 one in a single coprocessor invocation. This call will be spread into each 
 region in the server side, and the results will be merged ahead in the server 
 side before being returned to the client.



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

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

2013-12-26 Thread Gustavo Anatoly (JIRA)


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

Gustavo Anatoly updated HBASE-10147:


Status: Patch Available  (was: Open)

 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


 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-26 Thread Hadoop QA (JIRA)

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

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/12620502/HBASE-10147.patch
against trunk revision .
ATTACHMENT ID: 12620502

{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: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/8284//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8284//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8284//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8284//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8284//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8284//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8284//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8284//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8284//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8284//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/8284//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.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)

96 matches

Mail list logo