[jira] [Updated] (HBASE-4893) HConnectionImplementation closed-but-not-deleted, need a way to find the state of connection

2011-12-15 Thread Mubarak Seyed (Updated) (JIRA)

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

Mubarak Seyed updated HBASE-4893:
-

Fix Version/s: (was: 0.90.6)
   0.90.5

 HConnectionImplementation closed-but-not-deleted, need a way to find the 
 state of connection
 

 Key: HBASE-4893
 URL: https://issues.apache.org/jira/browse/HBASE-4893
 Project: HBase
  Issue Type: Bug
  Components: client
Affects Versions: 0.90.1
 Environment: Linux 2.6, HBase-0.90.1
Reporter: Mubarak Seyed
  Labels: noob
 Fix For: 0.90.5

 Attachments: HBASE-4893.v1.patch


 In abort() of HConnectionManager$HConnectionImplementation, instance of 
 HConnectionImplementation is marked as this.closed=true.
 There is no way for client application to check the hbase client connection 
 whether it is still opened/good (this.closed=false) or not. We need a method 
 to validate the state of a connection like isClosed().
 {code}
 public boolean isClosed(){
return this.closed;
 } 
 {code}
 Once the connection is closed and it should get deleted. Client application 
 still gets a connection from HConnectionManager.getConnection(Configuration) 
 and tries to make a RPC call to RS, since connection is already closed, 
 HConnectionImplementation.getRegionServerWithRetries throws 
 RetriesExhaustedException with error message
 {code}
 Caused by: org.apache.hadoop.hbase.client.RetriesExhaustedException: Trying 
 to contact region server null for region , row 
 '----xxx', but failed after 10 attempts.
 Exceptions:
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
   at 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getRegionServerWithRetries(HConnectionManager.java:1008)
   at org.apache.hadoop.hbase.client.HTable.get(HTable.java:546)
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-4893) HConnectionImplementation closed-but-not-deleted, need a way to find the state of connection

2011-12-15 Thread Mubarak Seyed (Commented) (JIRA)

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

Mubarak Seyed commented on HBASE-4893:
--

Yup, all tests were passed in 0.90.5. This is for 0.90.5. Thanks.

 HConnectionImplementation closed-but-not-deleted, need a way to find the 
 state of connection
 

 Key: HBASE-4893
 URL: https://issues.apache.org/jira/browse/HBASE-4893
 Project: HBase
  Issue Type: Bug
  Components: client
Affects Versions: 0.90.1
 Environment: Linux 2.6, HBase-0.90.1
Reporter: Mubarak Seyed
  Labels: noob
 Fix For: 0.90.5

 Attachments: HBASE-4893.v1.patch


 In abort() of HConnectionManager$HConnectionImplementation, instance of 
 HConnectionImplementation is marked as this.closed=true.
 There is no way for client application to check the hbase client connection 
 whether it is still opened/good (this.closed=false) or not. We need a method 
 to validate the state of a connection like isClosed().
 {code}
 public boolean isClosed(){
return this.closed;
 } 
 {code}
 Once the connection is closed and it should get deleted. Client application 
 still gets a connection from HConnectionManager.getConnection(Configuration) 
 and tries to make a RPC call to RS, since connection is already closed, 
 HConnectionImplementation.getRegionServerWithRetries throws 
 RetriesExhaustedException with error message
 {code}
 Caused by: org.apache.hadoop.hbase.client.RetriesExhaustedException: Trying 
 to contact region server null for region , row 
 '----xxx', but failed after 10 attempts.
 Exceptions:
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
   at 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getRegionServerWithRetries(HConnectionManager.java:1008)
   at org.apache.hadoop.hbase.client.HTable.get(HTable.java:546)
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-5036) [book] book.xml - minor additions to region-RegionServer assignment

2011-12-15 Thread Hudson (Commented) (JIRA)

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

Hudson commented on HBASE-5036:
---

Integrated in HBase-TRUNK #2546 (See 
[https://builds.apache.org/job/HBase-TRUNK/2546/])
hbase-5036 book.xml  architecture chapter minor mods regarding region-RS 
assignment


 [book] book.xml - minor additions to region-RegionServer assignment
 ---

 Key: HBASE-5036
 URL: https://issues.apache.org/jira/browse/HBASE-5036
 Project: HBase
  Issue Type: Improvement
Reporter: Doug Meil
Assignee: Doug Meil
Priority: Minor
 Attachments: book_hbase_5036.xml.patch


 book.xml
 * Arch/Catalog section:  added link to region-RegionServer assignment section.
 * Arch/Regions:  minor cleanup of bullet spacing in region-RS assignment 
 section.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-5034) Make distributed log splitting the default once we gain confidence in it.

2011-12-15 Thread Jonathan Hsieh (Commented) (JIRA)

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

Jonathan Hsieh commented on HBASE-5034:
---

My bad -- I didn't check that.  I think we should still deprecate and remove 
the older path so we only have one path/configuration to exercise in the future.

 Make distributed log splitting the default once we gain confidence in it.
 -

 Key: HBASE-5034
 URL: https://issues.apache.org/jira/browse/HBASE-5034
 Project: HBase
  Issue Type: Improvement
Affects Versions: 0.94.0
Reporter: Jonathan Hsieh

 As a suggestion:
 To reduce the number of paths necessary for testing, we should make 
 distributed log splitting the default setting for recovery once we gain 
 confidence with it.  After a release where it is the default (0.94 
 hopefully?), the release after could remove the original non-distributed 
 version.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-5026) Add coprocessor hook to HRegionServer.ScannerListener.leaseExpired()

2011-12-15 Thread Hudson (Commented) (JIRA)

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

Hudson commented on HBASE-5026:
---

Integrated in HBase-0.92-security #39 (See 
[https://builds.apache.org/job/HBase-0.92-security/39/])
HBASE-5026  Add coprocessor hook to 
HRegionServer.ScannerListener.leaseExpired()

tedyu : 
Files : 
* /hbase/branches/0.92/CHANGES.txt
* 
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java


 Add coprocessor hook to HRegionServer.ScannerListener.leaseExpired()
 

 Key: HBASE-5026
 URL: https://issues.apache.org/jira/browse/HBASE-5026
 Project: HBase
  Issue Type: Bug
  Components: coprocessors
Affects Versions: 0.92.0
Reporter: Liu Jia
Assignee: Liu Jia
 Fix For: 0.92.0, 0.94.0

 Attachments: RegionObserverLeaseExpired.patch


 The RegionObserver's preScannerClose() and postScannerClose()
 methods should cover the scanner leaseExpired() situation. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-4683) Always cache index and bloom blocks

2011-12-15 Thread Hudson (Commented) (JIRA)

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

Hudson commented on HBASE-4683:
---

Integrated in HBase-0.92-security #39 (See 
[https://builds.apache.org/job/HBase-0.92-security/39/])
HBASE-4683  Always cache index and bloom blocks

jdcryans : 
Files : 
* /hbase/branches/0.92/CHANGES.txt
* 
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/io/hfile/BlockType.java
* 
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/io/hfile/CacheConfig.java
* 
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/io/hfile/HFileReaderV1.java
* 
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/io/hfile/HFileReaderV2.java


 Always cache index and bloom blocks
 ---

 Key: HBASE-4683
 URL: https://issues.apache.org/jira/browse/HBASE-4683
 Project: HBase
  Issue Type: New Feature
Reporter: Lars Hofhansl
Assignee: Mikhail Bautin
Priority: Minor
 Fix For: 0.92.0, 0.94.0

 Attachments: 0001-Cache-important-block-types.patch, 4683-v2.txt, 
 4683.txt, D807.1.patch, D807.2.patch, D807.3.patch, HBASE-4683-0.92-v2.patch, 
 HBASE-4683-v3.patch


 This would add a new boolean config option: hfile.block.cache.datablocks
 Default would be true.
 Setting this to false allows HBase in a mode where only index blocks are 
 cached, which is useful for analytical scenarios where a useful working set 
 of the data cannot be expected to fit into the (aggregate) cache.
 This is the equivalent of setting cacheBlocks to false on all scans 
 (including scans on behalf of gets).
 I would like to get a general feeling about what folks think about this.
 The change itself would be simple.
 Update (Mikhail): we probably don't need a new conf option. Instead, we will 
 make index blocks cached by default.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-3065) Retry all 'retryable' zk operations; e.g. connection loss

2011-12-15 Thread Harsh J (Commented) (JIRA)

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

Harsh J commented on HBASE-3065:


As a result of this, can the blocks of code of the following manner be 
considered as resolved?

{code}
  if (rc != 0) {
// Thisis resultcode.  If non-zero, need to resubmit.
LOG.warn(rc != 0 for  + path +  -- retryable connectionloss --  +
  FIX see http://wiki.apache.org/hadoop/ZooKeeper/FAQ#A2;);
return;
  }
{code}

This is from AssignmentManager, lines 1306 and 1336 (two instances).

Or are those callbacks still not retrying in nature?

 Retry all 'retryable' zk operations; e.g. connection loss
 -

 Key: HBASE-3065
 URL: https://issues.apache.org/jira/browse/HBASE-3065
 Project: HBase
  Issue Type: Bug
Reporter: stack
Assignee: Liyin Tang
Priority: Blocker
 Fix For: 0.92.0

 Attachments: 3065-v3.txt, 3065-v4.txt, HBASE-3065-addendum.patch, 
 HBase-3065[r1088475]_1.patch, hbase3065_2.patch


 The 'new' master refactored our zk code tidying up all zk accesses and 
 coralling them behind nice zk utility classes.  One improvement was letting 
 out all KeeperExceptions letting the client deal.  Thats good generally 
 because in old days, we'd suppress important state zk changes in state.  But 
 there is at least one case the new zk utility could handle for the 
 application and thats the class of retryable KeeperExceptions.  The one that 
 comes to mind is conection loss.  On connection loss we should retry the 
 just-failed operation.  Usually the retry will just work.  At worse, on 
 reconnect, we'll pick up the expired session event. 
 Adding in this change shouldn't be too bad given the refactor of zk corralled 
 all zk access into one or two classes only.
 One thing to consider though is how much we should retry.  We could retry on 
 a timer or we could retry for ever as long as the Stoppable interface is 
 passed so if another thread has stopped or aborted the hosting service, we'll 
 notice and give up trying.  Doing the latter is probably better than some 
 kinda timeout.
 HBASE-3062 adds a timed retry on the first zk operation.  This issue is about 
 generalizing what is over there across all zk access.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-3065) Retry all 'retryable' zk operations; e.g. connection loss

2011-12-15 Thread Harsh J (Commented) (JIRA)

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

Harsh J commented on HBASE-3065:


Actually, the more critical one is from the CreateUnassigned one:

{code}
  if (rc != 0) {
// Thisis resultcode.  If non-zero, need to resubmit.
LOG.warn(rc != 0 for  + path +  -- retryable connectionloss --  +
  FIX see http://wiki.apache.org/hadoop/ZooKeeper/FAQ#A2;);
this.zkw.abort(Connectionloss writing unassigned at  + path +
  , rc= + rc, null);
return;
  }
{code}

(Line 1306, AssignmentManager). As you see there, it aborts the whole thing 
instead of retrying.

 Retry all 'retryable' zk operations; e.g. connection loss
 -

 Key: HBASE-3065
 URL: https://issues.apache.org/jira/browse/HBASE-3065
 Project: HBase
  Issue Type: Bug
Reporter: stack
Assignee: Liyin Tang
Priority: Blocker
 Fix For: 0.92.0

 Attachments: 3065-v3.txt, 3065-v4.txt, HBASE-3065-addendum.patch, 
 HBase-3065[r1088475]_1.patch, hbase3065_2.patch


 The 'new' master refactored our zk code tidying up all zk accesses and 
 coralling them behind nice zk utility classes.  One improvement was letting 
 out all KeeperExceptions letting the client deal.  Thats good generally 
 because in old days, we'd suppress important state zk changes in state.  But 
 there is at least one case the new zk utility could handle for the 
 application and thats the class of retryable KeeperExceptions.  The one that 
 comes to mind is conection loss.  On connection loss we should retry the 
 just-failed operation.  Usually the retry will just work.  At worse, on 
 reconnect, we'll pick up the expired session event. 
 Adding in this change shouldn't be too bad given the refactor of zk corralled 
 all zk access into one or two classes only.
 One thing to consider though is how much we should retry.  We could retry on 
 a timer or we could retry for ever as long as the Stoppable interface is 
 passed so if another thread has stopped or aborted the hosting service, we'll 
 notice and give up trying.  Doing the latter is probably better than some 
 kinda timeout.
 HBASE-3062 adds a timed retry on the first zk operation.  This issue is about 
 generalizing what is over there across all zk access.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-5036) [book] book.xml - minor additions to region-RegionServer assignment

2011-12-15 Thread Hudson (Commented) (JIRA)

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

Hudson commented on HBASE-5036:
---

Integrated in HBase-TRUNK-security #32 (See 
[https://builds.apache.org/job/HBase-TRUNK-security/32/])
hbase-5036 book.xml  architecture chapter minor mods regarding region-RS 
assignment


 [book] book.xml - minor additions to region-RegionServer assignment
 ---

 Key: HBASE-5036
 URL: https://issues.apache.org/jira/browse/HBASE-5036
 Project: HBase
  Issue Type: Improvement
Reporter: Doug Meil
Assignee: Doug Meil
Priority: Minor
 Attachments: book_hbase_5036.xml.patch


 book.xml
 * Arch/Catalog section:  added link to region-RegionServer assignment section.
 * Arch/Regions:  minor cleanup of bullet spacing in region-RS assignment 
 section.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-5030) Some tests do not close the HFile.Reader they use, leaving some file descriptors open

2011-12-15 Thread Hudson (Commented) (JIRA)

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

Hudson commented on HBASE-5030:
---

Integrated in HBase-TRUNK-security #32 (See 
[https://builds.apache.org/job/HBase-TRUNK-security/32/])
HBASE-5030 Some tests do not close the HFile.Reader they use, leaving some 
file descriptors open (N Keywal)

tedyu : 
Files : 
* 
/hbase/trunk/src/test/java/org/apache/hadoop/hbase/io/TestHalfStoreFileReader.java
* 
/hbase/trunk/src/test/java/org/apache/hadoop/hbase/io/hfile/TestHFileBlockIndex.java
* 
/hbase/trunk/src/test/java/org/apache/hadoop/hbase/io/hfile/TestHFilePerformance.java
* /hbase/trunk/src/test/java/org/apache/hadoop/hbase/io/hfile/TestReseekTo.java
* /hbase/trunk/src/test/java/org/apache/hadoop/hbase/io/hfile/TestSeekTo.java
* 
/hbase/trunk/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHFileOutputFormat.java
* 
/hbase/trunk/src/test/java/org/apache/hadoop/hbase/mapreduce/TestLoadIncrementalHFiles.java


 Some tests do not close the HFile.Reader they use, leaving some file 
 descriptors open
 -

 Key: HBASE-5030
 URL: https://issues.apache.org/jira/browse/HBASE-5030
 Project: HBase
  Issue Type: Bug
  Components: test
Affects Versions: 0.94.0
Reporter: nkeywal
Assignee: nkeywal
Priority: Trivial
 Attachments: 5030.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-5026) Add coprocessor hook to HRegionServer.ScannerListener.leaseExpired()

2011-12-15 Thread Hudson (Commented) (JIRA)

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

Hudson commented on HBASE-5026:
---

Integrated in HBase-TRUNK-security #32 (See 
[https://builds.apache.org/job/HBase-TRUNK-security/32/])
HBASE-5026  Add coprocessor hook to 
HRegionServer.ScannerListener.leaseExpired()

tedyu : 
Files : 
* /hbase/trunk/CHANGES.txt
* 
/hbase/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java


 Add coprocessor hook to HRegionServer.ScannerListener.leaseExpired()
 

 Key: HBASE-5026
 URL: https://issues.apache.org/jira/browse/HBASE-5026
 Project: HBase
  Issue Type: Bug
  Components: coprocessors
Affects Versions: 0.92.0
Reporter: Liu Jia
Assignee: Liu Jia
 Fix For: 0.92.0, 0.94.0

 Attachments: RegionObserverLeaseExpired.patch


 The RegionObserver's preScannerClose() and postScannerClose()
 methods should cover the scanner leaseExpired() situation. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-5028) [book] book.xml - adding information on region assignment and file locality

2011-12-15 Thread Hudson (Commented) (JIRA)

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

Hudson commented on HBASE-5028:
---

Integrated in HBase-TRUNK-security #32 (See 
[https://builds.apache.org/job/HBase-TRUNK-security/32/])
hbase-5028 book.xml - adding info on region assignment and file locality


 [book] book.xml - adding information on region assignment and file locality
 ---

 Key: HBASE-5028
 URL: https://issues.apache.org/jira/browse/HBASE-5028
 Project: HBase
  Issue Type: Improvement
Reporter: Doug Meil
Assignee: Doug Meil
Priority: Minor
 Attachments: book_hbase_5028.xml.patch


 book.xml
 * adding info in Architecture chapter on region assignment 
 * adding info in Architecture chapter on region-RS locality
 * adding 2 more links in other info appendix. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-4993) Performance regression in minicluster creation

2011-12-15 Thread Hudson (Commented) (JIRA)

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

Hudson commented on HBASE-4993:
---

Integrated in HBase-TRUNK-security #32 (See 
[https://builds.apache.org/job/HBase-TRUNK-security/32/])
HBASE-4993 Performance regression in minicluster creation

stack : 
Files : 
* /hbase/trunk/src/main/java/org/apache/hadoop/hbase/master/ServerManager.java
* /hbase/trunk/src/test/java/org/apache/hadoop/hbase/HBaseTestingUtility.java
* 
/hbase/trunk/src/test/java/org/apache/hadoop/hbase/master/TestMasterFailover.java
* /hbase/trunk/src/test/resources/hbase-site.xml


 Performance regression in minicluster creation
 --

 Key: HBASE-4993
 URL: https://issues.apache.org/jira/browse/HBASE-4993
 Project: HBase
  Issue Type: Bug
  Components: master
Affects Versions: 0.94.0
 Environment: all
Reporter: nkeywal
Assignee: nkeywal
 Fix For: 0.94.0

 Attachments: 4993.patch, 4993.v3.patch


 Side effect of 4610: the mini cluster needs 4,5 seconds to start

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-5022) Optimize HBaseConfiguration#create

2011-12-15 Thread Hudson (Commented) (JIRA)

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

Hudson commented on HBASE-5022:
---

Integrated in HBase-TRUNK-security #32 (See 
[https://builds.apache.org/job/HBase-TRUNK-security/32/])
HBASE-5022 Optimize HBaseConfiguration#create (N Keywal)

tedyu : 
Files : 
* /hbase/trunk/src/main/java/org/apache/hadoop/hbase/HBaseConfiguration.java


 Optimize HBaseConfiguration#create
 --

 Key: HBASE-5022
 URL: https://issues.apache.org/jira/browse/HBASE-5022
 Project: HBase
  Issue Type: Improvement
  Components: performance
Affects Versions: 0.94.0
Reporter: nkeywal
Assignee: nkeywal
Priority: Minor
 Attachments: 5022.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Updated] (HBASE-5027) HConnection.create(final Connection conf) does not clone, it creates a new Configuration reading *.xmls and then does a merge.

2011-12-15 Thread nkeywal (Updated) (JIRA)

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

nkeywal updated HBASE-5027:
---

Attachment: 5027.patch

 HConnection.create(final Connection conf) does not clone, it creates a new 
 Configuration reading *.xmls and then does a merge.
 --

 Key: HBASE-5027
 URL: https://issues.apache.org/jira/browse/HBASE-5027
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.94.0
Reporter: stack
 Fix For: 0.94.0

 Attachments: 5027.patch


 Its more expensive that it should be; its causing TestAdmin to fail after 
 HBASE-4417  went in.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Assigned] (HBASE-5027) HConnection.create(final Connection conf) does not clone, it creates a new Configuration reading *.xmls and then does a merge.

2011-12-15 Thread nkeywal (Assigned) (JIRA)

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

nkeywal reassigned HBASE-5027:
--

Assignee: nkeywal

 HConnection.create(final Connection conf) does not clone, it creates a new 
 Configuration reading *.xmls and then does a merge.
 --

 Key: HBASE-5027
 URL: https://issues.apache.org/jira/browse/HBASE-5027
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.94.0
Reporter: stack
Assignee: nkeywal
 Fix For: 0.94.0

 Attachments: 5027.patch


 Its more expensive that it should be; its causing TestAdmin to fail after 
 HBASE-4417  went in.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Updated] (HBASE-5027) HConnection.create(final Connection conf) does not clone, it creates a new Configuration reading *.xmls and then does a merge.

2011-12-15 Thread nkeywal (Updated) (JIRA)

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

nkeywal updated HBASE-5027:
---

Fix Version/s: 0.94.0
Affects Version/s: 0.94.0
   Status: Patch Available  (was: Open)

 HConnection.create(final Connection conf) does not clone, it creates a new 
 Configuration reading *.xmls and then does a merge.
 --

 Key: HBASE-5027
 URL: https://issues.apache.org/jira/browse/HBASE-5027
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.94.0
Reporter: stack
Assignee: nkeywal
 Fix For: 0.94.0

 Attachments: 5027.patch


 Its more expensive that it should be; its causing TestAdmin to fail after 
 HBASE-4417  went in.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-5027) HConnection.create(final Connection conf) does not clone, it creates a new Configuration reading *.xmls and then does a merge.

2011-12-15 Thread nkeywal (Commented) (JIRA)

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

nkeywal commented on HBASE-5027:


Patch submitted with the implementation proposed by Stack.
- I checked, if we leak a connection, the test fails
- I removed the clone anyway, it's more efficient
- I added a check on connection count in the ResourceChecker

 HConnection.create(final Connection conf) does not clone, it creates a new 
 Configuration reading *.xmls and then does a merge.
 --

 Key: HBASE-5027
 URL: https://issues.apache.org/jira/browse/HBASE-5027
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.94.0
Reporter: stack
Assignee: nkeywal
 Fix For: 0.94.0

 Attachments: 5027.patch


 Its more expensive that it should be; its causing TestAdmin to fail after 
 HBASE-4417  went in.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-5009) Failure of creating split dir if it already exists prevents splits from happening further

2011-12-15 Thread ramkrishna.s.vasudevan (Commented) (JIRA)

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

ramkrishna.s.vasudevan commented on HBASE-5009:
---

I am working on this and some more testing and analysis is going on.. will 
submit a patch after we are ok with it. :)

 Failure of creating split dir if it already exists prevents splits from 
 happening further
 -

 Key: HBASE-5009
 URL: https://issues.apache.org/jira/browse/HBASE-5009
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.90.6
Reporter: ramkrishna.s.vasudevan
Assignee: ramkrishna.s.vasudevan

 The scenario is
 - The split of a region takes a long time
 - The deletion of the splitDir fails due to HDFS problems.
 - Subsequent splits also fail after that.
 {code}
 private static void createSplitDir(final FileSystem fs, final Path splitdir)
   throws IOException {
 if (fs.exists(splitdir)) throw new IOException(Splitdir already exits?  
 + splitdir);
 if (!fs.mkdirs(splitdir)) throw new IOException(Failed create of  + 
 splitdir);
   }
 {code}
 Correct me if am wrong? If it is an issue can we change the behaviour of 
 throwing exception?
 Pls suggest.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Updated] (HBASE-5038) Some tests leak connections

2011-12-15 Thread nkeywal (Updated) (JIRA)

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

nkeywal updated HBASE-5038:
---

Summary: Some tests leak connections  (was: Some tests leaks connections)

 Some tests leak connections
 ---

 Key: HBASE-5038
 URL: https://issues.apache.org/jira/browse/HBASE-5038
 Project: HBase
  Issue Type: Bug
  Components: test
Affects Versions: 0.94.0
Reporter: nkeywal
Assignee: nkeywal
Priority: Minor



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Created] (HBASE-5038) Some tests leaks connections

2011-12-15 Thread nkeywal (Created) (JIRA)
Some tests leaks connections


 Key: HBASE-5038
 URL: https://issues.apache.org/jira/browse/HBASE-5038
 Project: HBase
  Issue Type: Bug
  Components: test
Affects Versions: 0.94.0
Reporter: nkeywal
Assignee: nkeywal
Priority: Minor




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Updated] (HBASE-5038) Some tests leak connections

2011-12-15 Thread nkeywal (Updated) (JIRA)

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

nkeywal updated HBASE-5038:
---

Attachment: 5038.patch

 Some tests leak connections
 ---

 Key: HBASE-5038
 URL: https://issues.apache.org/jira/browse/HBASE-5038
 Project: HBase
  Issue Type: Bug
  Components: test
Affects Versions: 0.94.0
Reporter: nkeywal
Assignee: nkeywal
Priority: Minor
 Attachments: 5038.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Updated] (HBASE-5038) Some tests leak connections

2011-12-15 Thread nkeywal (Updated) (JIRA)

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

nkeywal updated HBASE-5038:
---

Status: Patch Available  (was: Open)

 Some tests leak connections
 ---

 Key: HBASE-5038
 URL: https://issues.apache.org/jira/browse/HBASE-5038
 Project: HBase
  Issue Type: Bug
  Components: test
Affects Versions: 0.94.0
Reporter: nkeywal
Assignee: nkeywal
Priority: Minor
 Attachments: 5038.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-5027) HConnection.create(final Connection conf) does not clone, it creates a new Configuration reading *.xmls and then does a merge.

2011-12-15 Thread Hadoop QA (Commented) (JIRA)

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

Hadoop QA commented on HBASE-5027:
--

-1 overall.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12507513/5027.patch
  against trunk revision .

+1 @author.  The patch does not contain any @author tags.

+1 tests included.  The patch appears to include 9 new or modified tests.

-1 javadoc.  The javadoc tool appears to have generated -152 warning 
messages.

+1 javac.  The applied patch does not increase the total number of javac 
compiler warnings.

-1 findbugs.  The patch appears to introduce 75 new Findbugs (version 
1.3.9) warnings.

+1 release audit.  The applied patch does not increase the total number of 
release audit warnings.

 -1 core tests.  The patch failed these unit tests:
   org.apache.hadoop.hbase.client.TestInstantSchemaChange

Test results: 
https://builds.apache.org/job/PreCommit-HBASE-Build/513//testReport/
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/513//artifact/trunk/patchprocess/newPatchFindbugsWarnings.html
Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/513//console

This message is automatically generated.

 HConnection.create(final Connection conf) does not clone, it creates a new 
 Configuration reading *.xmls and then does a merge.
 --

 Key: HBASE-5027
 URL: https://issues.apache.org/jira/browse/HBASE-5027
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.94.0
Reporter: stack
Assignee: nkeywal
 Fix For: 0.94.0

 Attachments: 5027.patch


 Its more expensive that it should be; its causing TestAdmin to fail after 
 HBASE-4417  went in.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Updated] (HBASE-5039) [book] book.xml - more cleanup of Arch chapter on regions, adding a FAQ entry

2011-12-15 Thread Doug Meil (Updated) (JIRA)

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

Doug Meil updated HBASE-5039:
-

Attachment: book_hbase_5039.xml.patch

 [book] book.xml - more cleanup of Arch chapter on regions, adding a FAQ entry
 -

 Key: HBASE-5039
 URL: https://issues.apache.org/jira/browse/HBASE-5039
 Project: HBase
  Issue Type: Improvement
Reporter: Doug Meil
Assignee: Doug Meil
Priority: Minor
 Attachments: book_hbase_5039.xml.patch


 book.xml
 * Arch chapter/Regions.  clearing up a little more in region assignment
 * FAQ.  Adding an architecture section.
 * MapReduce chapter.  Fixed nit that Ian Varley brought to my attention on 
 RDBMS summary.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Created] (HBASE-5039) [book] book.xml - more cleanup of Arch chapter on regions, adding a FAQ entry

2011-12-15 Thread Doug Meil (Created) (JIRA)
[book] book.xml - more cleanup of Arch chapter on regions, adding a FAQ entry
-

 Key: HBASE-5039
 URL: https://issues.apache.org/jira/browse/HBASE-5039
 Project: HBase
  Issue Type: Improvement
Reporter: Doug Meil
Assignee: Doug Meil
Priority: Minor
 Attachments: book_hbase_5039.xml.patch

book.xml
* Arch chapter/Regions.  clearing up a little more in region assignment
* FAQ.  Adding an architecture section.
* MapReduce chapter.  Fixed nit that Ian Varley brought to my attention on 
RDBMS summary.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Updated] (HBASE-5039) [book] book.xml - more cleanup of Arch chapter on regions, adding a FAQ entry

2011-12-15 Thread Doug Meil (Updated) (JIRA)

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

Doug Meil updated HBASE-5039:
-

Status: Patch Available  (was: Open)

 [book] book.xml - more cleanup of Arch chapter on regions, adding a FAQ entry
 -

 Key: HBASE-5039
 URL: https://issues.apache.org/jira/browse/HBASE-5039
 Project: HBase
  Issue Type: Improvement
Reporter: Doug Meil
Assignee: Doug Meil
Priority: Minor
 Attachments: book_hbase_5039.xml.patch


 book.xml
 * Arch chapter/Regions.  clearing up a little more in region assignment
 * FAQ.  Adding an architecture section.
 * MapReduce chapter.  Fixed nit that Ian Varley brought to my attention on 
 RDBMS summary.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Updated] (HBASE-5039) [book] book.xml - more cleanup of Arch chapter on regions, adding a FAQ entry

2011-12-15 Thread Doug Meil (Updated) (JIRA)

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

Doug Meil updated HBASE-5039:
-

Resolution: Fixed
Status: Resolved  (was: Patch Available)

 [book] book.xml - more cleanup of Arch chapter on regions, adding a FAQ entry
 -

 Key: HBASE-5039
 URL: https://issues.apache.org/jira/browse/HBASE-5039
 Project: HBase
  Issue Type: Improvement
Reporter: Doug Meil
Assignee: Doug Meil
Priority: Minor
 Attachments: book_hbase_5039.xml.patch


 book.xml
 * Arch chapter/Regions.  clearing up a little more in region assignment
 * FAQ.  Adding an architecture section.
 * MapReduce chapter.  Fixed nit that Ian Varley brought to my attention on 
 RDBMS summary.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-5027) HConnection.create(final Connection conf) does not clone, it creates a new Configuration reading *.xmls and then does a merge.

2011-12-15 Thread nkeywal (Commented) (JIRA)

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

nkeywal commented on HBASE-5027:


Too many open files

We're using quite a lot of threads here:
hbase.ResourceChecker(145): after 
client.TestInstantSchemaChange#testInstantSchemaJanitor: 343 threads (was 117), 
863 file descriptors (was 600). 6 connections,  -thread leak?-  -file handle 
leak?- 

The patch can be committed imho, but I wonder why we have so many threads  
open files.

 HConnection.create(final Connection conf) does not clone, it creates a new 
 Configuration reading *.xmls and then does a merge.
 --

 Key: HBASE-5027
 URL: https://issues.apache.org/jira/browse/HBASE-5027
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.94.0
Reporter: stack
Assignee: nkeywal
 Fix For: 0.94.0

 Attachments: 5027.patch


 Its more expensive that it should be; its causing TestAdmin to fail after 
 HBASE-4417  went in.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-5014) PutSortReducer and KeyValueSortReduce should adhere to memory limits

2011-12-15 Thread Kannan Muthukkaruppan (Commented) (JIRA)

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

Kannan Muthukkaruppan commented on HBASE-5014:
--

The patch isn't automatically showing up on the JIRA (even though now you have 
added the [jira] in the phabricator diff). Could you upload the same here? 
Thanks Dhruba.

 PutSortReducer and KeyValueSortReduce should adhere to memory limits
 

 Key: HBASE-5014
 URL: https://issues.apache.org/jira/browse/HBASE-5014
 Project: HBase
  Issue Type: Improvement
  Components: mapreduce
Reporter: dhruba borthakur
Assignee: dhruba borthakur

 The PutSortReduce class has a configurable threshold to flush partial sorted 
 data for large rows. However, it was not using the size of the key in the 
 calculation of overall memory used. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-3065) Retry all 'retryable' zk operations; e.g. connection loss

2011-12-15 Thread stack (Commented) (JIRA)

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

stack commented on HBASE-3065:
--

We should make a test to prove these blocks not needed Harsh?

 Retry all 'retryable' zk operations; e.g. connection loss
 -

 Key: HBASE-3065
 URL: https://issues.apache.org/jira/browse/HBASE-3065
 Project: HBase
  Issue Type: Bug
Reporter: stack
Assignee: Liyin Tang
Priority: Blocker
 Fix For: 0.92.0

 Attachments: 3065-v3.txt, 3065-v4.txt, HBASE-3065-addendum.patch, 
 HBase-3065[r1088475]_1.patch, hbase3065_2.patch


 The 'new' master refactored our zk code tidying up all zk accesses and 
 coralling them behind nice zk utility classes.  One improvement was letting 
 out all KeeperExceptions letting the client deal.  Thats good generally 
 because in old days, we'd suppress important state zk changes in state.  But 
 there is at least one case the new zk utility could handle for the 
 application and thats the class of retryable KeeperExceptions.  The one that 
 comes to mind is conection loss.  On connection loss we should retry the 
 just-failed operation.  Usually the retry will just work.  At worse, on 
 reconnect, we'll pick up the expired session event. 
 Adding in this change shouldn't be too bad given the refactor of zk corralled 
 all zk access into one or two classes only.
 One thing to consider though is how much we should retry.  We could retry on 
 a timer or we could retry for ever as long as the Stoppable interface is 
 passed so if another thread has stopped or aborted the hosting service, we'll 
 notice and give up trying.  Doing the latter is probably better than some 
 kinda timeout.
 HBASE-3062 adds a timed retry on the first zk operation.  This issue is about 
 generalizing what is over there across all zk access.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Updated] (HBASE-5038) Some tests leak connections

2011-12-15 Thread stack (Updated) (JIRA)

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

stack updated HBASE-5038:
-

   Resolution: Fixed
Fix Version/s: 0.94.0
 Hadoop Flags: Reviewed
   Status: Resolved  (was: Patch Available)

Committed to trunk.  Thanks for the patch Nicolas.

 Some tests leak connections
 ---

 Key: HBASE-5038
 URL: https://issues.apache.org/jira/browse/HBASE-5038
 Project: HBase
  Issue Type: Bug
  Components: test
Affects Versions: 0.94.0
Reporter: nkeywal
Assignee: nkeywal
Priority: Minor
 Fix For: 0.94.0

 Attachments: 5038.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Updated] (HBASE-5034) Remove non distributed log splitting option

2011-12-15 Thread Jonathan Hsieh (Updated) (JIRA)

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

Jonathan Hsieh updated HBASE-5034:
--

Description: 
As a suggestion:

Distributed log splitting the default setting for recovery in 0.92.  To reduce 
the number of paths necessary for testing, we should remove the original 
non-distributed version.

  was:
As a suggestion:

To reduce the number of paths necessary for testing, we should make distributed 
log splitting the default setting for recovery once we gain confidence with it. 
 After a release where it is the default (0.94 hopefully?), the release after 
could remove the original non-distributed version.

Summary: Remove non distributed log splitting option  (was: Make 
distributed log splitting the default once we gain confidence in it.)

 Remove non distributed log splitting option
 ---

 Key: HBASE-5034
 URL: https://issues.apache.org/jira/browse/HBASE-5034
 Project: HBase
  Issue Type: Improvement
Affects Versions: 0.94.0
Reporter: Jonathan Hsieh

 As a suggestion:
 Distributed log splitting the default setting for recovery in 0.92.  To 
 reduce the number of paths necessary for testing, we should remove the 
 original non-distributed version.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-5027) HConnection.create(final Connection conf) does not clone, it creates a new Configuration reading *.xmls and then does a merge.

2011-12-15 Thread nkeywal (Commented) (JIRA)

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

nkeywal commented on HBASE-5027:


Yes, I removed the retry counter because the clone is expensive. It's true that 
when HBase is not available it will be slower. Put it back if yoy think it was 
an error to remove it.

for lsof: will we have the access rights for this? I can give it a try. But 
with the few hundreds of open file descriptors, it can be hard to read. As the 
connection counter comes from HBase, we may get more info from HBase directly I 
think.



 HConnection.create(final Connection conf) does not clone, it creates a new 
 Configuration reading *.xmls and then does a merge.
 --

 Key: HBASE-5027
 URL: https://issues.apache.org/jira/browse/HBASE-5027
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.94.0
Reporter: stack
Assignee: nkeywal
 Fix For: 0.94.0

 Attachments: 5027.patch


 Its more expensive that it should be; its causing TestAdmin to fail after 
 HBASE-4417  went in.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-5027) HConnection.create(final Connection conf) does not clone, it creates a new Configuration reading *.xmls and then does a merge.

2011-12-15 Thread stack (Commented) (JIRA)

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

stack commented on HBASE-5027:
--

You are right on the lsof; we're running as lowly user, not as root... though I 
suppose could run it on local machine as root and see?

Maybe I should make a cheaper clone first over in HBaseConfiguration, commit 
that, then commit above using the cheaper clone?

 HConnection.create(final Connection conf) does not clone, it creates a new 
 Configuration reading *.xmls and then does a merge.
 --

 Key: HBASE-5027
 URL: https://issues.apache.org/jira/browse/HBASE-5027
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.94.0
Reporter: stack
Assignee: nkeywal
 Fix For: 0.94.0

 Attachments: 5027.patch


 Its more expensive that it should be; its causing TestAdmin to fail after 
 HBASE-4417  went in.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-5034) Remove non distributed log splitting option

2011-12-15 Thread stack (Commented) (JIRA)

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

stack commented on HBASE-5034:
--

@Jon Agreed.  Issue is valid w/ your above edit.

 Remove non distributed log splitting option
 ---

 Key: HBASE-5034
 URL: https://issues.apache.org/jira/browse/HBASE-5034
 Project: HBase
  Issue Type: Improvement
Affects Versions: 0.94.0
Reporter: Jonathan Hsieh

 As a suggestion:
 Distributed log splitting the default setting for recovery in 0.92.  To 
 reduce the number of paths necessary for testing, we should remove the 
 original non-distributed version.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-5027) HConnection.create(final Connection conf) does not clone, it creates a new Configuration reading *.xmls and then does a merge.

2011-12-15 Thread stack (Commented) (JIRA)

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

stack commented on HBASE-5027:
--

Pardon me, you already made the cheaper clone fix over in hbase-5022.  So, I 
should just apply this patch minus the change to 
src/main/java/org/apache/hadoop/hbase/client/HBaseAdmin.java that should 
remove the regression?

 HConnection.create(final Connection conf) does not clone, it creates a new 
 Configuration reading *.xmls and then does a merge.
 --

 Key: HBASE-5027
 URL: https://issues.apache.org/jira/browse/HBASE-5027
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.94.0
Reporter: stack
Assignee: nkeywal
 Fix For: 0.94.0

 Attachments: 5027.patch


 Its more expensive that it should be; its causing TestAdmin to fail after 
 HBASE-4417  went in.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-5027) HConnection.create(final Connection conf) does not clone, it creates a new Configuration reading *.xmls and then does a merge.

2011-12-15 Thread nkeywal (Commented) (JIRA)

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

nkeywal commented on HBASE-5027:


The cheap clone was already committed by Ted in HBASE-5022. But even with
this, it's still expensive. As we now have only one check now instead of
1000 before, it won't really impact the test however.


On Thu, Dec 15, 2011 at 5:56 PM, stack (Commented) (JIRA)



 HConnection.create(final Connection conf) does not clone, it creates a new 
 Configuration reading *.xmls and then does a merge.
 --

 Key: HBASE-5027
 URL: https://issues.apache.org/jira/browse/HBASE-5027
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.94.0
Reporter: stack
Assignee: nkeywal
 Fix For: 0.94.0

 Attachments: 5027.patch


 Its more expensive that it should be; its causing TestAdmin to fail after 
 HBASE-4417  went in.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-5027) HConnection.create(final Connection conf) does not clone, it creates a new Configuration reading *.xmls and then does a merge.

2011-12-15 Thread nkeywal (Commented) (JIRA)

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

nkeywal commented on HBASE-5027:


Yes, i will work

On Thu, Dec 15, 2011 at 6:00 PM, stack (Commented) (JIRA)



 HConnection.create(final Connection conf) does not clone, it creates a new 
 Configuration reading *.xmls and then does a merge.
 --

 Key: HBASE-5027
 URL: https://issues.apache.org/jira/browse/HBASE-5027
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.94.0
Reporter: stack
Assignee: nkeywal
 Fix For: 0.94.0

 Attachments: 5027.patch


 Its more expensive that it should be; its causing TestAdmin to fail after 
 HBASE-4417  went in.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-5027) HConnection.create(final Connection conf) does not clone, it creates a new Configuration reading *.xmls and then does a merge.

2011-12-15 Thread nkeywal (Commented) (JIRA)

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

nkeywal commented on HBASE-5027:


't' is missing in my last comment = yes, just apply this patch minus the 
change to src/main/java/org/apache/hadoop/hbase/client/HBaseAdmin.java that 
should remove the regression will work :-)

 HConnection.create(final Connection conf) does not clone, it creates a new 
 Configuration reading *.xmls and then does a merge.
 --

 Key: HBASE-5027
 URL: https://issues.apache.org/jira/browse/HBASE-5027
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.94.0
Reporter: stack
Assignee: nkeywal
 Fix For: 0.94.0

 Attachments: 5027.patch


 Its more expensive that it should be; its causing TestAdmin to fail after 
 HBASE-4417  went in.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Updated] (HBASE-5027) HConnection.create(final Connection conf) does not clone, it creates a new Configuration reading *.xmls and then does a merge.

2011-12-15 Thread stack (Updated) (JIRA)

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

stack updated HBASE-5027:
-

Resolution: Fixed
Status: Resolved  (was: Patch Available)

Committed the patch minus TestAdmin change.  Thanks Nicolas.

 HConnection.create(final Connection conf) does not clone, it creates a new 
 Configuration reading *.xmls and then does a merge.
 --

 Key: HBASE-5027
 URL: https://issues.apache.org/jira/browse/HBASE-5027
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.94.0
Reporter: stack
Assignee: nkeywal
 Fix For: 0.94.0

 Attachments: 5027.patch


 Its more expensive that it should be; its causing TestAdmin to fail after 
 HBASE-4417  went in.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-5038) Some tests leak connections

2011-12-15 Thread Hadoop QA (Commented) (JIRA)

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

Hadoop QA commented on HBASE-5038:
--

-1 overall.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12507534/5038.patch
  against trunk revision .

+1 @author.  The patch does not contain any @author tags.

+1 tests included.  The patch appears to include 15 new or modified tests.

-1 javadoc.  The javadoc tool appears to have generated -152 warning 
messages.

+1 javac.  The applied patch does not increase the total number of javac 
compiler warnings.

-1 findbugs.  The patch appears to introduce 75 new Findbugs (version 
1.3.9) warnings.

+1 release audit.  The applied patch does not increase the total number of 
release audit warnings.

 -1 core tests.  The patch failed these unit tests:
   org.apache.hadoop.hbase.client.TestAdmin
  org.apache.hadoop.hbase.client.TestInstantSchemaChange

Test results: 
https://builds.apache.org/job/PreCommit-HBASE-Build/514//testReport/
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/514//artifact/trunk/patchprocess/newPatchFindbugsWarnings.html
Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/514//console

This message is automatically generated.

 Some tests leak connections
 ---

 Key: HBASE-5038
 URL: https://issues.apache.org/jira/browse/HBASE-5038
 Project: HBase
  Issue Type: Bug
  Components: test
Affects Versions: 0.94.0
Reporter: nkeywal
Assignee: nkeywal
Priority: Minor
 Fix For: 0.94.0

 Attachments: 5038.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-3065) Retry all 'retryable' zk operations; e.g. connection loss

2011-12-15 Thread Harsh J (Commented) (JIRA)

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

Harsh J commented on HBASE-3065:


Good point.

/me bangs his head on the wall for not trying first :)

I'll spend some time in the weekend to try out 0.92 and force this callback to 
fail.

 Retry all 'retryable' zk operations; e.g. connection loss
 -

 Key: HBASE-3065
 URL: https://issues.apache.org/jira/browse/HBASE-3065
 Project: HBase
  Issue Type: Bug
Reporter: stack
Assignee: Liyin Tang
Priority: Blocker
 Fix For: 0.92.0

 Attachments: 3065-v3.txt, 3065-v4.txt, HBASE-3065-addendum.patch, 
 HBase-3065[r1088475]_1.patch, hbase3065_2.patch


 The 'new' master refactored our zk code tidying up all zk accesses and 
 coralling them behind nice zk utility classes.  One improvement was letting 
 out all KeeperExceptions letting the client deal.  Thats good generally 
 because in old days, we'd suppress important state zk changes in state.  But 
 there is at least one case the new zk utility could handle for the 
 application and thats the class of retryable KeeperExceptions.  The one that 
 comes to mind is conection loss.  On connection loss we should retry the 
 just-failed operation.  Usually the retry will just work.  At worse, on 
 reconnect, we'll pick up the expired session event. 
 Adding in this change shouldn't be too bad given the refactor of zk corralled 
 all zk access into one or two classes only.
 One thing to consider though is how much we should retry.  We could retry on 
 a timer or we could retry for ever as long as the Stoppable interface is 
 passed so if another thread has stopped or aborted the hosting service, we'll 
 notice and give up trying.  Doing the latter is probably better than some 
 kinda timeout.
 HBASE-3062 adds a timed retry on the first zk operation.  This issue is about 
 generalizing what is over there across all zk access.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Resolved] (HBASE-5037) install hbase standalone ,hbase restart, thrift server can not reconnect

2011-12-15 Thread Jean-Daniel Cryans (Resolved) (JIRA)

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

Jean-Daniel Cryans resolved HBASE-5037.
---

Resolution: Invalid

For user questions and errors, please use the user mailing list. Regarding your 
issue, looks like either ran out of ZK connections or restarted zk while 
deleting it's data. Either way, look at the ZK log.

 install hbase standalone ,hbase restart, thrift server can not reconnect
 

 Key: HBASE-5037
 URL: https://issues.apache.org/jira/browse/HBASE-5037
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.90.4
 Environment: Linux TEST 2.6.18-92.el5PAE #1 SMP Tue Apr 29 13:31:02 
 EDT 2008 i686 i686 i386 GNU/Linux
Reporter: frank ling

 same as https://issues.apache.org/jira/browse/HBASE-2849
 thrift log:
 org.apache.zookeeper.ClientCnxn: Unable to read additional data from server 
 sessionid 0x1343b1b1fbf0005, likely server has closed socket, closing socket 
 connection and attempting reconnect
 hbase log:
 2011-12-15 14:58:03,793 INFO org.apache.zookeeper.server.NIOServerCnxn: 
 Accepted socket connection from /127.0.0.1:19035
 2011-12-15 14:58:03,793 INFO org.apache.zookeeper.server.NIOServerCnxn: 
 Refusing session request for client /127.0.0.1:19035 as it has seen zxid 
 0x169 our last zxid is 0x15c client must try another server
 2011-12-15 14:58:03,793 INFO org.apache.zookeeper.server.NIOServerCnxn: 
 Closed socket connection for client /127.0.0.1:19035 (no session established 
 for client)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-4605) Constraints

2011-12-15 Thread Zhihong Yu (Commented) (JIRA)

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

Zhihong Yu commented on HBASE-4605:
---

Integrated to TRUNK.

Thanks for the patch Jesse.

Thanks for the review Gary.

 Constraints
 ---

 Key: HBASE-4605
 URL: https://issues.apache.org/jira/browse/HBASE-4605
 Project: HBase
  Issue Type: Improvement
  Components: client, coprocessors
Affects Versions: 0.94.0
Reporter: Jesse Yates
Assignee: Jesse Yates
 Attachments: 4605-v6.txt, 4605.v7, constraint_as_cp.txt, 
 java_Constraint_v2.patch, java_HBASE-4605_v1.patch, java_HBASE-4605_v2.patch, 
 java_HBASE-4605_v3.patch, java_HBASE-4605_v5.patch, java_HBASE-4605_v7.patch


 From Jesse's comment on dev:
 {quote}
 What I would like to propose is a simple interface that people can use to 
 implement a 'constraint' (matching the classic database definition). This 
 would help ease of adoption by helping HBase more easily check that box, help 
 minimize code duplication across organizations, and lead to easier adoption.
 Essentially, people would implement a 'Constraint' interface for checking 
 keys before they are put into a table. Puts that are valid get written to the 
 table, but if not people can will throw an exception that gets propagated 
 back to the client explaining why the put was invalid.
 Constraints would be set on a per-table basis and the user would be expected 
 to ensure the jars containing the constraint are present on the machines 
 serving that table.
 Yes, people could roll their own mechanism for doing this via coprocessors 
 each time, but this would make it easier to do so, so you only have to 
 implement a very minimal interface and not worry about the specifics.
 {quote}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Created] (HBASE-5040) Secure HBase builds fail

2011-12-15 Thread Zhihong Yu (Created) (JIRA)
Secure HBase builds fail


 Key: HBASE-5040
 URL: https://issues.apache.org/jira/browse/HBASE-5040
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.92.0
Reporter: Zhihong Yu
 Fix For: 0.92.0


I saw the following in HBase-0.92-security build #39:
{code}
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:2.0.2:testCompile 
(default-testCompile) on project hbase: Compilation failure
[ERROR] 
https://builds.apache.org/job/HBase-0.92-security/ws/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestStore.java:[590,4]
 method does not override or implement a method from a supertype
[ERROR] - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:2.0.2:testCompile 
(default-testCompile) on project hbase: Compilation failure
https://builds.apache.org/job/HBase-0.92-security/ws/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestStore.java:[590,4]
 method does not override or implement a method from a supertype
{code}

The above was probably introduced by HBASE-5006

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Created] (HBASE-5041) Major compaction on non existing table does not throw error

2011-12-15 Thread Shrijeet Paliwal (Created) (JIRA)
Major compaction on non existing table does not throw error 


 Key: HBASE-5041
 URL: https://issues.apache.org/jira/browse/HBASE-5041
 Project: HBase
  Issue Type: Bug
  Components: regionserver, shell
Affects Versions: 0.90.3
Reporter: Shrijeet Paliwal


Following will not complain even if fubar does not exist

{code}
echo major_compact 'fubar' | $HBASE_HOME/bin/hbase shell
{code}

The downside for this defect is that major compaction may be skipped due to
a typo by Ops.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-4893) HConnectionImplementation closed-but-not-deleted, need a way to find the state of connection

2011-12-15 Thread Zhihong Yu (Commented) (JIRA)

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

Zhihong Yu commented on HBASE-4893:
---

One minor question about the patch:
{code}
   else LOG.fatal(msg);
-  this.closed = true;
+  HConnectionManager.deleteStaleConnection(this);
{code}
Why do we need to remove the assignment to this.closed ?

Please use appropriate command to generate patch, such as 'svn diff'
The current patch cannot be applied at the root of source tree.

Good work Mubarak.

 HConnectionImplementation closed-but-not-deleted, need a way to find the 
 state of connection
 

 Key: HBASE-4893
 URL: https://issues.apache.org/jira/browse/HBASE-4893
 Project: HBase
  Issue Type: Bug
  Components: client
Affects Versions: 0.90.1
 Environment: Linux 2.6, HBase-0.90.1
Reporter: Mubarak Seyed
  Labels: noob
 Fix For: 0.90.5

 Attachments: HBASE-4893.v1.patch


 In abort() of HConnectionManager$HConnectionImplementation, instance of 
 HConnectionImplementation is marked as this.closed=true.
 There is no way for client application to check the hbase client connection 
 whether it is still opened/good (this.closed=false) or not. We need a method 
 to validate the state of a connection like isClosed().
 {code}
 public boolean isClosed(){
return this.closed;
 } 
 {code}
 Once the connection is closed and it should get deleted. Client application 
 still gets a connection from HConnectionManager.getConnection(Configuration) 
 and tries to make a RPC call to RS, since connection is already closed, 
 HConnectionImplementation.getRegionServerWithRetries throws 
 RetriesExhaustedException with error message
 {code}
 Caused by: org.apache.hadoop.hbase.client.RetriesExhaustedException: Trying 
 to contact region server null for region , row 
 '----xxx', but failed after 10 attempts.
 Exceptions:
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
   at 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getRegionServerWithRetries(HConnectionManager.java:1008)
   at org.apache.hadoop.hbase.client.HTable.get(HTable.java:546)
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Resolved] (HBASE-4683) Always cache index and bloom blocks

2011-12-15 Thread Jean-Daniel Cryans (Resolved) (JIRA)

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

Jean-Daniel Cryans resolved HBASE-4683.
---

  Resolution: Fixed
Hadoop Flags: Reviewed

Committed to branch and trunk, thanks for the quick work Mikhail!

 Always cache index and bloom blocks
 ---

 Key: HBASE-4683
 URL: https://issues.apache.org/jira/browse/HBASE-4683
 Project: HBase
  Issue Type: New Feature
Reporter: Lars Hofhansl
Assignee: Mikhail Bautin
Priority: Minor
 Fix For: 0.92.0, 0.94.0

 Attachments: 0001-Cache-important-block-types.patch, 4683-v2.txt, 
 4683.txt, D807.1.patch, D807.2.patch, D807.3.patch, HBASE-4683-0.92-v2.patch, 
 HBASE-4683-v3.patch


 This would add a new boolean config option: hfile.block.cache.datablocks
 Default would be true.
 Setting this to false allows HBase in a mode where only index blocks are 
 cached, which is useful for analytical scenarios where a useful working set 
 of the data cannot be expected to fit into the (aggregate) cache.
 This is the equivalent of setting cacheBlocks to false on all scans 
 (including scans on behalf of gets).
 I would like to get a general feeling about what folks think about this.
 The change itself would be simple.
 Update (Mikhail): we probably don't need a new conf option. Instead, we will 
 make index blocks cached by default.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Created] (HBASE-5042) TestReadWriteConsistencyControl should be renamed

2011-12-15 Thread Zhihong Yu (Created) (JIRA)
TestReadWriteConsistencyControl should be renamed
-

 Key: HBASE-5042
 URL: https://issues.apache.org/jira/browse/HBASE-5042
 Project: HBase
  Issue Type: Task
Affects Versions: 0.92.0
Reporter: Zhihong Yu


TestReadWriteConsistencyControl tests MultiVersionConsistencyControl so it 
should be named TestMultiVersionConsistencyControl

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Updated] (HBASE-5014) PutSortReducer and KeyValueSortReduce should adhere to memory limits

2011-12-15 Thread dhruba borthakur (Updated) (JIRA)

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

dhruba borthakur updated HBASE-5014:


Attachment: putSortReducer1.txt

Attached patch from Review.

 PutSortReducer and KeyValueSortReduce should adhere to memory limits
 

 Key: HBASE-5014
 URL: https://issues.apache.org/jira/browse/HBASE-5014
 Project: HBase
  Issue Type: Improvement
  Components: mapreduce
Reporter: dhruba borthakur
Assignee: dhruba borthakur
 Attachments: putSortReducer1.txt


 The PutSortReduce class has a configurable threshold to flush partial sorted 
 data for large rows. However, it was not using the size of the key in the 
 calculation of overall memory used. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Created] (HBASE-5043) hbase shell readline breaks after suspend and resume

2011-12-15 Thread Aleksandr Levchuk (Created) (JIRA)
hbase shell readline breaks after suspend and resume


 Key: HBASE-5043
 URL: https://issues.apache.org/jira/browse/HBASE-5043
 Project: HBase
  Issue Type: Bug
  Components: shell
Affects Versions: 0.90.4
Reporter: Aleksandr Levchuk
Priority: Minor


Easily reproducible:
  (1) Start habse shell
  (2) Press Ctrl-z, to suspend process
  (3) Run fg, to resume

Now when you type nothing shows up.

An irb shell behaves much more gracefully on Suspend/Resume.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Updated] (HBASE-4938) Create a HRegion.getScanner public method that allows reading from a specified readPoint

2011-12-15 Thread dhruba borthakur (Updated) (JIRA)

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

dhruba borthakur updated HBASE-4938:


Attachment: scannerMVCC1.txt

Attached patch from review.

 Create a HRegion.getScanner public method that allows reading from a 
 specified readPoint
 

 Key: HBASE-4938
 URL: https://issues.apache.org/jira/browse/HBASE-4938
 Project: HBase
  Issue Type: Improvement
Reporter: dhruba borthakur
Assignee: dhruba borthakur
Priority: Minor
 Attachments: scannerMVCC1.txt


 There is an existing api HRegion.getScanner(Scan) that allows scanning a 
 table. My proposal is to extend it to HRegion.getScanner(Scan, long readPoint)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-4893) HConnectionImplementation closed-but-not-deleted, need a way to find the state of connection

2011-12-15 Thread Mubarak Seyed (Commented) (JIRA)

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

Mubarak Seyed commented on HBASE-4893:
--

If we keep this.closed=true, after removing the key from HBASE_INSTANCES map, 
connection.close(stopProxy) is getting called, since it is already marked as 
closed, close(stopProxy) will not stop the proxy for Master/RS and will not 
close the ZK connection.

{code}
void close(boolean stopProxy) {
  if (this.closed) {
return;
  }
  ..
  ..
}
{code}

Will submit a patch.

 HConnectionImplementation closed-but-not-deleted, need a way to find the 
 state of connection
 

 Key: HBASE-4893
 URL: https://issues.apache.org/jira/browse/HBASE-4893
 Project: HBase
  Issue Type: Bug
  Components: client
Affects Versions: 0.90.1
 Environment: Linux 2.6, HBase-0.90.1
Reporter: Mubarak Seyed
  Labels: noob
 Fix For: 0.90.5

 Attachments: HBASE-4893.v1.patch


 In abort() of HConnectionManager$HConnectionImplementation, instance of 
 HConnectionImplementation is marked as this.closed=true.
 There is no way for client application to check the hbase client connection 
 whether it is still opened/good (this.closed=false) or not. We need a method 
 to validate the state of a connection like isClosed().
 {code}
 public boolean isClosed(){
return this.closed;
 } 
 {code}
 Once the connection is closed and it should get deleted. Client application 
 still gets a connection from HConnectionManager.getConnection(Configuration) 
 and tries to make a RPC call to RS, since connection is already closed, 
 HConnectionImplementation.getRegionServerWithRetries throws 
 RetriesExhaustedException with error message
 {code}
 Caused by: org.apache.hadoop.hbase.client.RetriesExhaustedException: Trying 
 to contact region server null for region , row 
 '----xxx', but failed after 10 attempts.
 Exceptions:
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
   at 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getRegionServerWithRetries(HConnectionManager.java:1008)
   at org.apache.hadoop.hbase.client.HTable.get(HTable.java:546)
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-4893) HConnectionImplementation closed-but-not-deleted, need a way to find the state of connection

2011-12-15 Thread Zhihong Yu (Commented) (JIRA)

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

Zhihong Yu commented on HBASE-4893:
---

Thanks for the explanation.

In that case, I think the assignment should be moved to after 
HConnectionManager.deleteStaleConnection() call.

 HConnectionImplementation closed-but-not-deleted, need a way to find the 
 state of connection
 

 Key: HBASE-4893
 URL: https://issues.apache.org/jira/browse/HBASE-4893
 Project: HBase
  Issue Type: Bug
  Components: client
Affects Versions: 0.90.1
 Environment: Linux 2.6, HBase-0.90.1
Reporter: Mubarak Seyed
  Labels: noob
 Fix For: 0.90.5

 Attachments: HBASE-4893.v1.patch


 In abort() of HConnectionManager$HConnectionImplementation, instance of 
 HConnectionImplementation is marked as this.closed=true.
 There is no way for client application to check the hbase client connection 
 whether it is still opened/good (this.closed=false) or not. We need a method 
 to validate the state of a connection like isClosed().
 {code}
 public boolean isClosed(){
return this.closed;
 } 
 {code}
 Once the connection is closed and it should get deleted. Client application 
 still gets a connection from HConnectionManager.getConnection(Configuration) 
 and tries to make a RPC call to RS, since connection is already closed, 
 HConnectionImplementation.getRegionServerWithRetries throws 
 RetriesExhaustedException with error message
 {code}
 Caused by: org.apache.hadoop.hbase.client.RetriesExhaustedException: Trying 
 to contact region server null for region , row 
 '----xxx', but failed after 10 attempts.
 Exceptions:
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
   at 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getRegionServerWithRetries(HConnectionManager.java:1008)
   at org.apache.hadoop.hbase.client.HTable.get(HTable.java:546)
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Created] (HBASE-5044) Clarify solution for problem described on http://hbase.apache.org/book/trouble.mapreduce.html

2011-12-15 Thread Eugene Koontz (Created) (JIRA)
Clarify solution for problem described on 
http://hbase.apache.org/book/trouble.mapreduce.html
-

 Key: HBASE-5044
 URL: https://issues.apache.org/jira/browse/HBASE-5044
 Project: HBase
  Issue Type: Improvement
  Components: documentation
Reporter: Eugene Koontz
Assignee: Eugene Koontz
Priority: Trivial
 Fix For: 0.94.0, 0.90.4


Add some documentation regarding how to fix the problem described on :

http://hbase.apache.org/apidocs/org/apache/hadoop/hbase/mapreduce/package-summary.html#classpath

Should be some text like: 
{quote}
You should run your mapreduce job with your {{HADOOP_CLASSPATH}} set to include 
the HBase jar and HBase's configured classpath. For example (substitute your 
own hbase jar location for is {{hbase-0.90.0-SNAPSHOT.jar}}):
{quote}
{code}
HADOOP_CLASSPATH=${HBASE_HOME}/target/hbase-0.90.0-SNAPSHOT.jar:`${HBASE_HOME}/bin/hbase
 classpath` ${HADOOP_HOME}/bin/hadoop jar 
${HBASE_HOME}/target/hbase-0.90.0-SNAPSHOT.jar rowcounter usertable
{code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Updated] (HBASE-5029) TestDistributedLogSplitting fails on occasion

2011-12-15 Thread Phabricator (Updated) (JIRA)

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

Phabricator updated HBASE-5029:
---

Attachment: HBASE-5029.D891.1.patch

khemani requested code review of HBASE-5029 [jira] TestDistributedLogSplitting 
fails on occasion.
Reviewers: stack, nspiegelberg, JIRA

  had to make the test kind of toothless. Now on a rs abort it checks not only 
the error paths but also the success paths.

  difficult to ensure that the splitting doesn't finish before abort or that 
master doesn't preempt on seeing rs abort.

TEST PLAN
  the test passes

REVISION DETAIL
  https://reviews.facebook.net/D891

AFFECTED FILES
  src/test/java/org/apache/hadoop/hbase/master/TestDistributedLogSplitting.java

MANAGE HERALD DIFFERENTIAL RULES
  https://reviews.facebook.net/herald/view/differential/

WHY DID I GET THIS EMAIL?
  https://reviews.facebook.net/herald/transcript/1881/

Tip: use the X-Herald-Rules header to filter Herald messages in your client.


 TestDistributedLogSplitting fails on occasion
 -

 Key: HBASE-5029
 URL: https://issues.apache.org/jira/browse/HBASE-5029
 Project: HBase
  Issue Type: Bug
Reporter: stack
Assignee: Prakash Khemani
 Attachments: HBASE-5029.D891.1.patch


 This is how it usually fails: 
 https://builds.apache.org/view/G-L/view/HBase/job/HBase-0.92/lastCompletedBuild/testReport/org.apache.hadoop.hbase.master/TestDistributedLogSplitting/testWorkerAbort/
 Assigning mighty Prakash since he offered to take a looksee.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Created] (HBASE-5045) Add the table name and cf name for the next call int the task monitor

2011-12-15 Thread Liyin Tang (Created) (JIRA)
Add the table name and cf name for the next call int the task monitor
-

 Key: HBASE-5045
 URL: https://issues.apache.org/jira/browse/HBASE-5045
 Project: HBase
  Issue Type: Improvement
Reporter: Liyin Tang
Assignee: Liyin Tang


In the task monitor, we don't have much information about the next call 
compared to other operations.
It would be nice to add the table name and cf name for each next call in the 
task monitor.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Updated] (HBASE-5044) Clarify solution for problem described on http://hbase.apache.org/book/trouble.mapreduce.html

2011-12-15 Thread Eugene Koontz (Updated) (JIRA)

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

Eugene Koontz updated HBASE-5044:
-

Attachment: HBASE-5044.patch

 Clarify solution for problem described on 
 http://hbase.apache.org/book/trouble.mapreduce.html
 -

 Key: HBASE-5044
 URL: https://issues.apache.org/jira/browse/HBASE-5044
 Project: HBase
  Issue Type: Improvement
  Components: documentation
Reporter: Eugene Koontz
Assignee: Eugene Koontz
Priority: Trivial
 Fix For: 0.90.4, 0.94.0

 Attachments: HBASE-5044.patch


 Add some documentation regarding how to fix the problem described on :
 http://hbase.apache.org/apidocs/org/apache/hadoop/hbase/mapreduce/package-summary.html#classpath
 Should be some text like: 
 {quote}
 You should run your mapreduce job with your {{HADOOP_CLASSPATH}} set to 
 include the HBase jar and HBase's configured classpath. For example 
 (substitute your own hbase jar location for is {{hbase-0.90.0-SNAPSHOT.jar}}):
 {quote}
 {code}
 HADOOP_CLASSPATH=${HBASE_HOME}/target/hbase-0.90.0-SNAPSHOT.jar:`${HBASE_HOME}/bin/hbase
  classpath` ${HADOOP_HOME}/bin/hadoop jar 
 ${HBASE_HOME}/target/hbase-0.90.0-SNAPSHOT.jar rowcounter usertable
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Updated] (HBASE-5044) Clarify solution for problem described on http://hbase.apache.org/book/trouble.mapreduce.html

2011-12-15 Thread Eugene Koontz (Updated) (JIRA)

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

Eugene Koontz updated HBASE-5044:
-

Status: Patch Available  (was: Open)

patch to src/docbkx/troubleshooting.xml

 Clarify solution for problem described on 
 http://hbase.apache.org/book/trouble.mapreduce.html
 -

 Key: HBASE-5044
 URL: https://issues.apache.org/jira/browse/HBASE-5044
 Project: HBase
  Issue Type: Improvement
  Components: documentation
Reporter: Eugene Koontz
Assignee: Eugene Koontz
Priority: Trivial
 Fix For: 0.94.0, 0.90.4

 Attachments: HBASE-5044.patch


 Add some documentation regarding how to fix the problem described on :
 http://hbase.apache.org/apidocs/org/apache/hadoop/hbase/mapreduce/package-summary.html#classpath
 Should be some text like: 
 {quote}
 You should run your mapreduce job with your {{HADOOP_CLASSPATH}} set to 
 include the HBase jar and HBase's configured classpath. For example 
 (substitute your own hbase jar location for is {{hbase-0.90.0-SNAPSHOT.jar}}):
 {quote}
 {code}
 HADOOP_CLASSPATH=${HBASE_HOME}/target/hbase-0.90.0-SNAPSHOT.jar:`${HBASE_HOME}/bin/hbase
  classpath` ${HADOOP_HOME}/bin/hadoop jar 
 ${HBASE_HOME}/target/hbase-0.90.0-SNAPSHOT.jar rowcounter usertable
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-5029) TestDistributedLogSplitting fails on occasion

2011-12-15 Thread Phabricator (Commented) (JIRA)

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

Phabricator commented on HBASE-5029:


tedyu has commented on the revision HBASE-5029 [jira] 
TestDistributedLogSplitting fails on occasion.

  Good work.
  Some minor comments.

INLINE COMMENTS
  
src/test/java/org/apache/hadoop/hbase/master/TestDistributedLogSplitting.java:286
 We should put 3 into a variable so that the failure message below can 
reference it.
  
src/test/java/org/apache/hadoop/hbase/master/TestDistributedLogSplitting.java:250
 Nice explanation.
  Should this be lifted above line 248 ?
  
src/test/java/org/apache/hadoop/hbase/master/TestDistributedLogSplitting.java:255
 I think replacing it with 'region server' would make this clearer.

REVISION DETAIL
  https://reviews.facebook.net/D891


 TestDistributedLogSplitting fails on occasion
 -

 Key: HBASE-5029
 URL: https://issues.apache.org/jira/browse/HBASE-5029
 Project: HBase
  Issue Type: Bug
Reporter: stack
Assignee: Prakash Khemani
 Attachments: HBASE-5029.D891.1.patch


 This is how it usually fails: 
 https://builds.apache.org/view/G-L/view/HBase/job/HBase-0.92/lastCompletedBuild/testReport/org.apache.hadoop.hbase.master/TestDistributedLogSplitting/testWorkerAbort/
 Assigning mighty Prakash since he offered to take a looksee.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Updated] (HBASE-5040) Secure HBase builds fail

2011-12-15 Thread Zhihong Yu (Updated) (JIRA)

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

Zhihong Yu updated HBASE-5040:
--

Attachment: 5040.txt

Simple patch.

 Secure HBase builds fail
 

 Key: HBASE-5040
 URL: https://issues.apache.org/jira/browse/HBASE-5040
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.92.0
Reporter: Zhihong Yu
 Fix For: 0.92.0

 Attachments: 5040.txt


 I saw the following in HBase-0.92-security build #39:
 {code}
 [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-compiler-plugin:2.0.2:testCompile 
 (default-testCompile) on project hbase: Compilation failure
 [ERROR] 
 https://builds.apache.org/job/HBase-0.92-security/ws/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestStore.java:[590,4]
  method does not override or implement a method from a supertype
 [ERROR] - [Help 1]
 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
 goal org.apache.maven.plugins:maven-compiler-plugin:2.0.2:testCompile 
 (default-testCompile) on project hbase: Compilation failure
 https://builds.apache.org/job/HBase-0.92-security/ws/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestStore.java:[590,4]
  method does not override or implement a method from a supertype
 {code}
 The above was probably introduced by HBASE-5006

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Updated] (HBASE-5040) Secure HBase builds fail

2011-12-15 Thread Zhihong Yu (Updated) (JIRA)

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

Zhihong Yu updated HBASE-5040:
--

Status: Patch Available  (was: Open)

 Secure HBase builds fail
 

 Key: HBASE-5040
 URL: https://issues.apache.org/jira/browse/HBASE-5040
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.92.0
Reporter: Zhihong Yu
 Fix For: 0.92.0

 Attachments: 5040.txt


 I saw the following in HBase-0.92-security build #39:
 {code}
 [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-compiler-plugin:2.0.2:testCompile 
 (default-testCompile) on project hbase: Compilation failure
 [ERROR] 
 https://builds.apache.org/job/HBase-0.92-security/ws/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestStore.java:[590,4]
  method does not override or implement a method from a supertype
 [ERROR] - [Help 1]
 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
 goal org.apache.maven.plugins:maven-compiler-plugin:2.0.2:testCompile 
 (default-testCompile) on project hbase: Compilation failure
 https://builds.apache.org/job/HBase-0.92-security/ws/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestStore.java:[590,4]
  method does not override or implement a method from a supertype
 {code}
 The above was probably introduced by HBASE-5006

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Updated] (HBASE-5029) TestDistributedLogSplitting fails on occasion

2011-12-15 Thread Phabricator (Updated) (JIRA)

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

Phabricator updated HBASE-5029:
---

Attachment: HBASE-5029.D891.2.patch

khemani updated the revision HBASE-5029 [jira] TestDistributedLogSplitting 
fails on occasion.
Reviewers: stack, nspiegelberg, JIRA, tedyu

  ted's feedback implemented

REVISION DETAIL
  https://reviews.facebook.net/D891

AFFECTED FILES
  src/test/java/org/apache/hadoop/hbase/master/TestDistributedLogSplitting.java


 TestDistributedLogSplitting fails on occasion
 -

 Key: HBASE-5029
 URL: https://issues.apache.org/jira/browse/HBASE-5029
 Project: HBase
  Issue Type: Bug
Reporter: stack
Assignee: Prakash Khemani
 Attachments: HBASE-5029.D891.1.patch, HBASE-5029.D891.2.patch


 This is how it usually fails: 
 https://builds.apache.org/view/G-L/view/HBase/job/HBase-0.92/lastCompletedBuild/testReport/org.apache.hadoop.hbase.master/TestDistributedLogSplitting/testWorkerAbort/
 Assigning mighty Prakash since he offered to take a looksee.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-4893) HConnectionImplementation closed-but-not-deleted, need a way to find the state of connection

2011-12-15 Thread Mubarak Seyed (Commented) (JIRA)

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

Mubarak Seyed commented on HBASE-4893:
--

close(boolean stopProxy) already sets this.closed=true. close(stopProxy) will 
be called after removing the key from HBASE_INSTANCES map.

 HConnectionImplementation closed-but-not-deleted, need a way to find the 
 state of connection
 

 Key: HBASE-4893
 URL: https://issues.apache.org/jira/browse/HBASE-4893
 Project: HBase
  Issue Type: Bug
  Components: client
Affects Versions: 0.90.1
 Environment: Linux 2.6, HBase-0.90.1
Reporter: Mubarak Seyed
  Labels: noob
 Fix For: 0.90.5

 Attachments: HBASE-4893.v1.patch


 In abort() of HConnectionManager$HConnectionImplementation, instance of 
 HConnectionImplementation is marked as this.closed=true.
 There is no way for client application to check the hbase client connection 
 whether it is still opened/good (this.closed=false) or not. We need a method 
 to validate the state of a connection like isClosed().
 {code}
 public boolean isClosed(){
return this.closed;
 } 
 {code}
 Once the connection is closed and it should get deleted. Client application 
 still gets a connection from HConnectionManager.getConnection(Configuration) 
 and tries to make a RPC call to RS, since connection is already closed, 
 HConnectionImplementation.getRegionServerWithRetries throws 
 RetriesExhaustedException with error message
 {code}
 Caused by: org.apache.hadoop.hbase.client.RetriesExhaustedException: Trying 
 to contact region server null for region , row 
 '----xxx', but failed after 10 attempts.
 Exceptions:
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
   at 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getRegionServerWithRetries(HConnectionManager.java:1008)
   at org.apache.hadoop.hbase.client.HTable.get(HTable.java:546)
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-4893) HConnectionImplementation closed-but-not-deleted, need a way to find the state of connection

2011-12-15 Thread Zhihong Yu (Commented) (JIRA)

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

Zhihong Yu commented on HBASE-4893:
---

Should have read the code further :-)

Will integrate the new patch.

 HConnectionImplementation closed-but-not-deleted, need a way to find the 
 state of connection
 

 Key: HBASE-4893
 URL: https://issues.apache.org/jira/browse/HBASE-4893
 Project: HBase
  Issue Type: Bug
  Components: client
Affects Versions: 0.90.1
 Environment: Linux 2.6, HBase-0.90.1
Reporter: Mubarak Seyed
  Labels: noob
 Fix For: 0.90.5

 Attachments: HBASE-4893.v1.patch


 In abort() of HConnectionManager$HConnectionImplementation, instance of 
 HConnectionImplementation is marked as this.closed=true.
 There is no way for client application to check the hbase client connection 
 whether it is still opened/good (this.closed=false) or not. We need a method 
 to validate the state of a connection like isClosed().
 {code}
 public boolean isClosed(){
return this.closed;
 } 
 {code}
 Once the connection is closed and it should get deleted. Client application 
 still gets a connection from HConnectionManager.getConnection(Configuration) 
 and tries to make a RPC call to RS, since connection is already closed, 
 HConnectionImplementation.getRegionServerWithRetries throws 
 RetriesExhaustedException with error message
 {code}
 Caused by: org.apache.hadoop.hbase.client.RetriesExhaustedException: Trying 
 to contact region server null for region , row 
 '----xxx', but failed after 10 attempts.
 Exceptions:
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
   at 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getRegionServerWithRetries(HConnectionManager.java:1008)
   at org.apache.hadoop.hbase.client.HTable.get(HTable.java:546)
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Updated] (HBASE-4893) HConnectionImplementation closed-but-not-deleted, need a way to find the state of connection

2011-12-15 Thread Mubarak Seyed (Updated) (JIRA)

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

Mubarak Seyed updated HBASE-4893:
-

Attachment: HBASE-4893.v2.patch

The attached file HBASE-4893.v2.patch is an updated patch (generated from root 
of the source)

 HConnectionImplementation closed-but-not-deleted, need a way to find the 
 state of connection
 

 Key: HBASE-4893
 URL: https://issues.apache.org/jira/browse/HBASE-4893
 Project: HBase
  Issue Type: Bug
  Components: client
Affects Versions: 0.90.1
 Environment: Linux 2.6, HBase-0.90.1
Reporter: Mubarak Seyed
  Labels: noob
 Fix For: 0.90.5

 Attachments: HBASE-4893.v1.patch, HBASE-4893.v2.patch


 In abort() of HConnectionManager$HConnectionImplementation, instance of 
 HConnectionImplementation is marked as this.closed=true.
 There is no way for client application to check the hbase client connection 
 whether it is still opened/good (this.closed=false) or not. We need a method 
 to validate the state of a connection like isClosed().
 {code}
 public boolean isClosed(){
return this.closed;
 } 
 {code}
 Once the connection is closed and it should get deleted. Client application 
 still gets a connection from HConnectionManager.getConnection(Configuration) 
 and tries to make a RPC call to RS, since connection is already closed, 
 HConnectionImplementation.getRegionServerWithRetries throws 
 RetriesExhaustedException with error message
 {code}
 Caused by: org.apache.hadoop.hbase.client.RetriesExhaustedException: Trying 
 to contact region server null for region , row 
 '----xxx', but failed after 10 attempts.
 Exceptions:
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
   at 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getRegionServerWithRetries(HConnectionManager.java:1008)
   at org.apache.hadoop.hbase.client.HTable.get(HTable.java:546)
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Updated] (HBASE-4893) HConnectionImplementation is closed but not deleted

2011-12-15 Thread Zhihong Yu (Updated) (JIRA)

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

Zhihong Yu updated HBASE-4893:
--

Fix Version/s: (was: 0.90.5)
   0.90.6
  Summary: HConnectionImplementation is closed but not deleted  (was: 
HConnectionImplementation closed-but-not-deleted, need a way to find the state 
of connection)

 HConnectionImplementation is closed but not deleted
 ---

 Key: HBASE-4893
 URL: https://issues.apache.org/jira/browse/HBASE-4893
 Project: HBase
  Issue Type: Bug
  Components: client
Affects Versions: 0.90.1
 Environment: Linux 2.6, HBase-0.90.1
Reporter: Mubarak Seyed
  Labels: noob
 Fix For: 0.90.6

 Attachments: HBASE-4893.v1.patch, HBASE-4893.v2.patch


 In abort() of HConnectionManager$HConnectionImplementation, instance of 
 HConnectionImplementation is marked as this.closed=true.
 There is no way for client application to check the hbase client connection 
 whether it is still opened/good (this.closed=false) or not. We need a method 
 to validate the state of a connection like isClosed().
 {code}
 public boolean isClosed(){
return this.closed;
 } 
 {code}
 Once the connection is closed and it should get deleted. Client application 
 still gets a connection from HConnectionManager.getConnection(Configuration) 
 and tries to make a RPC call to RS, since connection is already closed, 
 HConnectionImplementation.getRegionServerWithRetries throws 
 RetriesExhaustedException with error message
 {code}
 Caused by: org.apache.hadoop.hbase.client.RetriesExhaustedException: Trying 
 to contact region server null for region , row 
 '----xxx', but failed after 10 attempts.
 Exceptions:
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
   at 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getRegionServerWithRetries(HConnectionManager.java:1008)
   at org.apache.hadoop.hbase.client.HTable.get(HTable.java:546)
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-4893) HConnectionImplementation is closed but not deleted

2011-12-15 Thread Zhihong Yu (Commented) (JIRA)

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

Zhihong Yu commented on HBASE-4893:
---

Integrated patch v2 to 0.90
It should be in 0.90.6 because 0.90.5 RC has been cut.

Thanks for the patch Mubarak.

Thanks for the review Stack.

 HConnectionImplementation is closed but not deleted
 ---

 Key: HBASE-4893
 URL: https://issues.apache.org/jira/browse/HBASE-4893
 Project: HBase
  Issue Type: Bug
  Components: client
Affects Versions: 0.90.1
 Environment: Linux 2.6, HBase-0.90.1
Reporter: Mubarak Seyed
  Labels: noob
 Fix For: 0.90.6

 Attachments: HBASE-4893.v1.patch, HBASE-4893.v2.patch


 In abort() of HConnectionManager$HConnectionImplementation, instance of 
 HConnectionImplementation is marked as this.closed=true.
 There is no way for client application to check the hbase client connection 
 whether it is still opened/good (this.closed=false) or not. We need a method 
 to validate the state of a connection like isClosed().
 {code}
 public boolean isClosed(){
return this.closed;
 } 
 {code}
 Once the connection is closed and it should get deleted. Client application 
 still gets a connection from HConnectionManager.getConnection(Configuration) 
 and tries to make a RPC call to RS, since connection is already closed, 
 HConnectionImplementation.getRegionServerWithRetries throws 
 RetriesExhaustedException with error message
 {code}
 Caused by: org.apache.hadoop.hbase.client.RetriesExhaustedException: Trying 
 to contact region server null for region , row 
 '----xxx', but failed after 10 attempts.
 Exceptions:
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
   at 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getRegionServerWithRetries(HConnectionManager.java:1008)
   at org.apache.hadoop.hbase.client.HTable.get(HTable.java:546)
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Resolved] (HBASE-1788) [stargate] multipart binary encoding option

2011-12-15 Thread Andrew Purtell (Resolved) (JIRA)

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

Andrew Purtell resolved HBASE-1788.
---

Resolution: Later
  Assignee: (was: Andrew Purtell)

There doesn't seem to be any need for this, and nothing I require.

 [stargate] multipart binary encoding option
 ---

 Key: HBASE-1788
 URL: https://issues.apache.org/jira/browse/HBASE-1788
 Project: HBase
  Issue Type: New Feature
Reporter: Andrew Purtell
Priority: Trivial

 Add support for multipart/related encoded entity bodies.
 There is support already for binary encoding also but not multipart  -- 
 operations with application/octet-stream encoding are limited to single KVs. 
 Multipart/related is not necessarily efficient. Timestamps and column names 
 would be sent as X-headers mixed between the binary blobs, and the part 
 headers and border adds more overhead. The only reason to support it is if 
 someone cannot use protobufs as an alternative to XML.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Assigned] (HBASE-1964) Enter temporary safe mode to ride over transient FS layer problems

2011-12-15 Thread Andrew Purtell (Assigned) (JIRA)

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

Andrew Purtell reassigned HBASE-1964:
-

Assignee: (was: Andrew Purtell)

 Enter temporary safe mode to ride over transient FS layer problems
 

 Key: HBASE-1964
 URL: https://issues.apache.org/jira/browse/HBASE-1964
 Project: HBase
  Issue Type: Sub-task
  Components: client
Reporter: elsif 

 When a hadoop/hbase cluster is under heavy load it will inevitably reach a 
 tipping point where data is lost or corrupted.  A
 graceful method is needed to put the cluster into safe mode until more 
 resources can be added or the load on the cluster has been
 reduced.  
 St.Ack has suggested the following short-term task: Meantime, it should be 
 possible to have a cron run a script that checks
 cluster resources from time-to-time -- e.g. how full hdfs is, how much each 
 regionserver is carrying -- and when it determines the needle is in the red,
 flip the cluster to be read-only.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-4893) HConnectionImplementation is closed but not deleted

2011-12-15 Thread Mubarak Seyed (Commented) (JIRA)

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

Mubarak Seyed commented on HBASE-4893:
--

Thanks Zhihong Yu. One basic question: Do i need to merge the fix into 0.92? 
Thanks.

 HConnectionImplementation is closed but not deleted
 ---

 Key: HBASE-4893
 URL: https://issues.apache.org/jira/browse/HBASE-4893
 Project: HBase
  Issue Type: Bug
  Components: client
Affects Versions: 0.90.1
 Environment: Linux 2.6, HBase-0.90.1
Reporter: Mubarak Seyed
  Labels: noob
 Fix For: 0.90.6

 Attachments: HBASE-4893.v1.patch, HBASE-4893.v2.patch


 In abort() of HConnectionManager$HConnectionImplementation, instance of 
 HConnectionImplementation is marked as this.closed=true.
 There is no way for client application to check the hbase client connection 
 whether it is still opened/good (this.closed=false) or not. We need a method 
 to validate the state of a connection like isClosed().
 {code}
 public boolean isClosed(){
return this.closed;
 } 
 {code}
 Once the connection is closed and it should get deleted. Client application 
 still gets a connection from HConnectionManager.getConnection(Configuration) 
 and tries to make a RPC call to RS, since connection is already closed, 
 HConnectionImplementation.getRegionServerWithRetries throws 
 RetriesExhaustedException with error message
 {code}
 Caused by: org.apache.hadoop.hbase.client.RetriesExhaustedException: Trying 
 to contact region server null for region , row 
 '----xxx', but failed after 10 attempts.
 Exceptions:
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
   at 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getRegionServerWithRetries(HConnectionManager.java:1008)
   at org.apache.hadoop.hbase.client.HTable.get(HTable.java:546)
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-904) Make client capable of riding over a cluster restart

2011-12-15 Thread Andrew Purtell (Commented) (JIRA)

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

Andrew Purtell commented on HBASE-904:
--

Testing the capability of the REST gateway to handle a cluster restart in 0.92.

 Make client capable of riding over a cluster restart
 

 Key: HBASE-904
 URL: https://issues.apache.org/jira/browse/HBASE-904
 Project: HBase
  Issue Type: Sub-task
Reporter: stack
Assignee: Andrew Purtell

 Currently, clients buried in REST server at least, are unable to recalibrate 
 if the cluster is restarted on them.  Fix it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-4893) HConnectionImplementation is closed but not deleted

2011-12-15 Thread Zhihong Yu (Commented) (JIRA)

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

Zhihong Yu commented on HBASE-4893:
---

Patch for 0.92 is welcome.

 HConnectionImplementation is closed but not deleted
 ---

 Key: HBASE-4893
 URL: https://issues.apache.org/jira/browse/HBASE-4893
 Project: HBase
  Issue Type: Bug
  Components: client
Affects Versions: 0.90.1
 Environment: Linux 2.6, HBase-0.90.1
Reporter: Mubarak Seyed
  Labels: noob
 Fix For: 0.90.6

 Attachments: HBASE-4893.v1.patch, HBASE-4893.v2.patch


 In abort() of HConnectionManager$HConnectionImplementation, instance of 
 HConnectionImplementation is marked as this.closed=true.
 There is no way for client application to check the hbase client connection 
 whether it is still opened/good (this.closed=false) or not. We need a method 
 to validate the state of a connection like isClosed().
 {code}
 public boolean isClosed(){
return this.closed;
 } 
 {code}
 Once the connection is closed and it should get deleted. Client application 
 still gets a connection from HConnectionManager.getConnection(Configuration) 
 and tries to make a RPC call to RS, since connection is already closed, 
 HConnectionImplementation.getRegionServerWithRetries throws 
 RetriesExhaustedException with error message
 {code}
 Caused by: org.apache.hadoop.hbase.client.RetriesExhaustedException: Trying 
 to contact region server null for region , row 
 '----xxx', but failed after 10 attempts.
 Exceptions:
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
 java.io.IOException: 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
  closed
   at 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getRegionServerWithRetries(HConnectionManager.java:1008)
   at org.apache.hadoop.hbase.client.HTable.get(HTable.java:546)
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-4047) [Coprocessors] Generic external process host

2011-12-15 Thread Andrew Purtell (Commented) (JIRA)

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

Andrew Purtell commented on HBASE-4047:
---

Start with testcases, the first a test that confirms a stuck child process via 
SIGSTOP doesn't take down the regionserver. Thinking there should be three 
selectable strategies:

1. Close and reopen the region, triggering force termination of the stuck child 
on close, and fork/initialization of a new child on open, along with reinit of 
all region related resources, other coprocessors, etc.

2. Unload/reload the malfunctioning coprocessor. Will require some work in the 
coprocessor framework to actually support unloading in a reasonable way. The 
JVM may make this complicated for integrated CPs, so perhaps just for those 
hosted in external processes.

3. Unload/terminate the malfunctioning coprocessor and continue operation. 
Consider changes in the CP framework for temporary blacklisting, will need that 
to avoid loading the suspect CP after a split.

 [Coprocessors] Generic external process host
 

 Key: HBASE-4047
 URL: https://issues.apache.org/jira/browse/HBASE-4047
 Project: HBase
  Issue Type: New Feature
  Components: coprocessors
Reporter: Andrew Purtell
Assignee: Andrew Purtell

 Where HBase coprocessors deviate substantially from the design (as I 
 understand it) of Google's BigTable coprocessors is we've reimagined it as a 
 framework for internal extension. In contrast BigTable coprocessors run as 
 separate processes colocated with tablet servers. The essential trade off is 
 between performance, flexibility and possibility, and the ability to control 
 and enforce resource usage.
 Since the initial design of HBase coprocessors some additional considerations 
 are in play:
 - Developing computational frameworks sitting directly on top of HBase hosted 
 in coprocessor(s);
 - Introduction of the map reduce next generation (mrng) resource management 
 model, and the probability that limits will be enforced via cgroups at the OS 
 level after this is generally available, e.g. when RHEL 6 deployments are 
 common;
 - The possibility of deployment of HBase onto mrng-enabled Hadoop clusters 
 via the mrng resource manager and a HBase-specific application controller.
 Therefore we should consider developing a coprocessor that is a generic host 
 for another coprocessor, but one that forks a child process, loads the target 
 coprocessor into the child, establishes a bidirectional pipe and uses an 
 eventing model and umbilical protocol to provide for the coprocessor loaded 
 into the child the same semantics as if it was loaded internally to the 
 parent, and (eventually) use available resource management capabilities on 
 the platform -- perhaps via the mrng resource controller or directly with 
 cgroups -- to limit the child as desired by system administrators or the 
 application designer.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Assigned] (HBASE-2396) Coprocessors: Server side dynamic scripting language execution

2011-12-15 Thread Andrew Purtell (Assigned) (JIRA)

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

Andrew Purtell reassigned HBASE-2396:
-

Assignee: Andrew Purtell

 Coprocessors: Server side dynamic scripting language execution
 --

 Key: HBASE-2396
 URL: https://issues.apache.org/jira/browse/HBASE-2396
 Project: HBase
  Issue Type: New Feature
  Components: coprocessors
Reporter: Todd Lipcon
Assignee: Andrew Purtell

 There are a lot of use cases where users want to perform some simple 
 operations on the region server. For example, a row may represent a Set and 
 users want append/search/remove style operations within the row without 
 having to perform the work on the client side. One possible solution is to 
 embed a small language something like PL/SQL (not necessarily in syntax) 
 which restricts users to a safe set of operations.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Resolved] (HBASE-2058) Coprocessors: CPU and memory limit policy enforcment via runtime weaving

2011-12-15 Thread Andrew Purtell (Resolved) (JIRA)

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

Andrew Purtell resolved HBASE-2058.
---

Resolution: Later

I suspect that given the available option of external coprocessor hosts 
(HBASE-4047), which enables things like resource reservation and limits via 
cgroups or similar OS-level facilities, there will never be sufficient impetus 
to undertake the difficult and research-y work described in this issue. But, 
marking as later as opposed to closing.

 Coprocessors: CPU and memory limit policy enforcment via runtime weaving
 

 Key: HBASE-2058
 URL: https://issues.apache.org/jira/browse/HBASE-2058
 Project: HBase
  Issue Type: Improvement
  Components: coprocessors
Reporter: Andrew Purtell

 Use the ASM bytecode analysis and rewriting engine to impose some constraints 
 on CPU and memory use. This is middle ground between arbitrary function and a 
 locked down language.
 We will be given arbitrary bytecode input. It is acceptable to reject a class 
 and abort coprocessor loading if it defies analysis at load time such that we 
 have insufficient confidence about the result.
 Wrap allocations to simply disallow large allocations. Hook or add finalizers 
 to keep a running tally of aggregate heap charge. Disallow allocation beyond 
 policy limit.
 Weave CPU usage tracking into loop headers. Throw an uncatchable exception if 
 time limits prescribed by policy are exceeded.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Created] (HBASE-5046) [Coprocessors] Generic external coprocessor host as coprocessor

2011-12-15 Thread Andrew Purtell (Created) (JIRA)
[Coprocessors] Generic external coprocessor host as coprocessor
---

 Key: HBASE-5046
 URL: https://issues.apache.org/jira/browse/HBASE-5046
 Project: HBase
  Issue Type: Sub-task
Reporter: Andrew Purtell
Assignee: Andrew Purtell


Just the skeleton.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Created] (HBASE-5047) [Coprocessors] Implement child failure strategies for external coprocessor host

2011-12-15 Thread Andrew Purtell (Created) (JIRA)
[Coprocessors] Implement child failure strategies for external coprocessor host
---

 Key: HBASE-5047
 URL: https://issues.apache.org/jira/browse/HBASE-5047
 Project: HBase
  Issue Type: Sub-task
Reporter: Andrew Purtell


There should be three selectable strategies:

1. Close and reopen the region, triggering force termination of the stuck child 
on close, and fork/initialization of a new child on open, along with reinit of 
all region related resources, other coprocessors, etc.

2. Unload/reload the malfunctioning coprocessor. Will require some work in the 
coprocessor framework to actually support unloading in a reasonable way. The 
JVM may make this complicated for integrated CPs, so perhaps just for those 
hosted in external processes.

3. Unload/terminate the malfunctioning coprocessor and continue operation. 
Consider changes in the CP framework for temporary blacklisting, will need that 
to avoid loading the suspect CP after a split.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-5047) [Coprocessors] Implement child failure strategies for external coprocessor host

2011-12-15 Thread Andrew Purtell (Commented) (JIRA)

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

Andrew Purtell commented on HBASE-5047:
---

Is it sufficient to consider children that crashed as permanently stuck?

 [Coprocessors] Implement child failure strategies for external coprocessor 
 host
 ---

 Key: HBASE-5047
 URL: https://issues.apache.org/jira/browse/HBASE-5047
 Project: HBase
  Issue Type: Sub-task
  Components: coprocessors
Reporter: Andrew Purtell

 There should be three selectable strategies:
 1. Close and reopen the region, triggering force termination of the stuck 
 child on close, and fork/initialization of a new child on open, along with 
 reinit of all region related resources, other coprocessors, etc.
 2. Unload/reload the malfunctioning coprocessor. Will require some work in 
 the coprocessor framework to actually support unloading in a reasonable way. 
 The JVM may make this complicated for integrated CPs, so perhaps just for 
 those hosted in external processes.
 3. Unload/terminate the malfunctioning coprocessor and continue operation. 
 Consider changes in the CP framework for temporary blacklisting, will need 
 that to avoid loading the suspect CP after a split.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-5047) [Coprocessors] Implement child failure strategies for external coprocessor host

2011-12-15 Thread Andrew Purtell (Commented) (JIRA)

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

Andrew Purtell commented on HBASE-5047:
---

Also need a configurable option to declare laggy children as stuck, a hard 
response latency threshold and perhaps also a soft latency threshold with a 
tolerance factor, e.g. no more than 3 overages in a minute.

 [Coprocessors] Implement child failure strategies for external coprocessor 
 host
 ---

 Key: HBASE-5047
 URL: https://issues.apache.org/jira/browse/HBASE-5047
 Project: HBase
  Issue Type: Sub-task
  Components: coprocessors
Reporter: Andrew Purtell

 There should be three selectable strategies:
 1. Close and reopen the region, triggering force termination of the stuck 
 child on close, and fork/initialization of a new child on open, along with 
 reinit of all region related resources, other coprocessors, etc.
 2. Unload/reload the malfunctioning coprocessor. Will require some work in 
 the coprocessor framework to actually support unloading in a reasonable way. 
 The JVM may make this complicated for integrated CPs, so perhaps just for 
 those hosted in external processes.
 3. Unload/terminate the malfunctioning coprocessor and continue operation. 
 Consider changes in the CP framework for temporary blacklisting, will need 
 that to avoid loading the suspect CP after a split.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Assigned] (HBASE-5047) [Coprocessors] Implement child failure strategies for external coprocessor host

2011-12-15 Thread Andrew Purtell (Assigned) (JIRA)

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

Andrew Purtell reassigned HBASE-5047:
-

Assignee: Andrew Purtell

 [Coprocessors] Implement child failure strategies for external coprocessor 
 host
 ---

 Key: HBASE-5047
 URL: https://issues.apache.org/jira/browse/HBASE-5047
 Project: HBase
  Issue Type: Sub-task
  Components: coprocessors
Reporter: Andrew Purtell
Assignee: Andrew Purtell

 There should be three selectable strategies:
 1. Close and reopen the region, triggering force termination of the stuck 
 child on close, and fork/initialization of a new child on open, along with 
 reinit of all region related resources, other coprocessors, etc.
 2. Unload/reload the malfunctioning coprocessor. Will require some work in 
 the coprocessor framework to actually support unloading in a reasonable way. 
 The JVM may make this complicated for integrated CPs, so perhaps just for 
 those hosted in external processes.
 3. Unload/terminate the malfunctioning coprocessor and continue operation. 
 Consider changes in the CP framework for temporary blacklisting, will need 
 that to avoid loading the suspect CP after a split.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Created] (HBASE-5048) Use EnvironmentEdgeManager.currentTimeMillis() instead of System.currentTimeMillis()

2011-12-15 Thread Mikhail Bautin (Created) (JIRA)
Use EnvironmentEdgeManager.currentTimeMillis() instead of 
System.currentTimeMillis()


 Key: HBASE-5048
 URL: https://issues.apache.org/jira/browse/HBASE-5048
 Project: HBase
  Issue Type: Improvement
Reporter: Mikhail Bautin
Priority: Minor


We need to switch to using EnvironmentEdgeManager.currentTimeMillis() instead 
of System.currentTimeMillis() across the codebase to reduce confusion when 
writing tests that require custom timing of operations.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Updated] (HBASE-5014) PutSortReducer should adhere to memory limits

2011-12-15 Thread Kannan Muthukkaruppan (Updated) (JIRA)

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

Kannan Muthukkaruppan updated HBASE-5014:
-

Summary: PutSortReducer should adhere to memory limits  (was: 
PutSortReducer and KeyValueSortReduce should adhere to memory limits)

updating title of bug. will commit patch next.

 PutSortReducer should adhere to memory limits
 -

 Key: HBASE-5014
 URL: https://issues.apache.org/jira/browse/HBASE-5014
 Project: HBase
  Issue Type: Improvement
  Components: mapreduce
Reporter: dhruba borthakur
Assignee: dhruba borthakur
 Attachments: putSortReducer1.txt


 The PutSortReduce class has a configurable threshold to flush partial sorted 
 data for large rows. However, it was not using the size of the key in the 
 calculation of overall memory used. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-5047) [Coprocessors] Implement child failure strategies for external coprocessor host

2011-12-15 Thread Andrew Purtell (Commented) (JIRA)

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

Andrew Purtell commented on HBASE-5047:
---

Regarding case #3 above, if a malfunctioning external coprocessor is terminated 
on one RS I think it makes most sense to propagate that failure to the whole 
cluster via a zookeeper based mechanism. Otherwise there are the obvious 
problems as a burden to the coprocessor developer. If choosing #3 as a 
strategy, the coprocessor developer has elected to take down the malfunctioning 
app but continue all other service. Allow resumption of service with a 
redeployment and an administrative action to reenable.

 [Coprocessors] Implement child failure strategies for external coprocessor 
 host
 ---

 Key: HBASE-5047
 URL: https://issues.apache.org/jira/browse/HBASE-5047
 Project: HBase
  Issue Type: Sub-task
  Components: coprocessors
Reporter: Andrew Purtell
Assignee: Andrew Purtell

 There should be three selectable strategies:
 1. Close and reopen the region, triggering force termination of the stuck 
 child on close, and fork/initialization of a new child on open, along with 
 reinit of all region related resources, other coprocessors, etc.
 2. Unload/reload the malfunctioning coprocessor. Will require some work in 
 the coprocessor framework to actually support unloading in a reasonable way. 
 The JVM may make this complicated for integrated CPs, so perhaps just for 
 those hosted in external processes.
 3. Unload/terminate the malfunctioning coprocessor and continue operation. 
 Consider changes in the CP framework for temporary blacklisting, will need 
 that to avoid loading the suspect CP after a split.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Updated] (HBASE-5014) PutSortReducer should adhere to memory limits

2011-12-15 Thread Kannan Muthukkaruppan (Updated) (JIRA)

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

Kannan Muthukkaruppan updated HBASE-5014:
-

   Resolution: Fixed
Fix Version/s: 0.94.0
   Status: Resolved  (was: Patch Available)

 PutSortReducer should adhere to memory limits
 -

 Key: HBASE-5014
 URL: https://issues.apache.org/jira/browse/HBASE-5014
 Project: HBase
  Issue Type: Improvement
  Components: mapreduce
Reporter: dhruba borthakur
Assignee: dhruba borthakur
 Fix For: 0.94.0

 Attachments: putSortReducer1.txt


 The PutSortReduce class has a configurable threshold to flush partial sorted 
 data for large rows. However, it was not using the size of the key in the 
 calculation of overall memory used. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-5040) Secure HBase builds fail

2011-12-15 Thread Andrew Purtell (Commented) (JIRA)

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

Andrew Purtell commented on HBASE-5040:
---

I'm +1 if then actually the build succeeds. Otherwise this issue can be an 
umbrella for more work.

 Secure HBase builds fail
 

 Key: HBASE-5040
 URL: https://issues.apache.org/jira/browse/HBASE-5040
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.92.0
Reporter: Zhihong Yu
 Fix For: 0.92.0

 Attachments: 5040.txt


 I saw the following in HBase-0.92-security build #39:
 {code}
 [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-compiler-plugin:2.0.2:testCompile 
 (default-testCompile) on project hbase: Compilation failure
 [ERROR] 
 https://builds.apache.org/job/HBase-0.92-security/ws/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestStore.java:[590,4]
  method does not override or implement a method from a supertype
 [ERROR] - [Help 1]
 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
 goal org.apache.maven.plugins:maven-compiler-plugin:2.0.2:testCompile 
 (default-testCompile) on project hbase: Compilation failure
 https://builds.apache.org/job/HBase-0.92-security/ws/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestStore.java:[590,4]
  method does not override or implement a method from a supertype
 {code}
 The above was probably introduced by HBASE-5006

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Updated] (HBASE-4938) Create a HRegion.getScanner public method that allows reading from a specified readPoint

2011-12-15 Thread Zhihong Yu (Updated) (JIRA)

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

Zhihong Yu updated HBASE-4938:
--

Status: Patch Available  (was: Open)

Patch testing

 Create a HRegion.getScanner public method that allows reading from a 
 specified readPoint
 

 Key: HBASE-4938
 URL: https://issues.apache.org/jira/browse/HBASE-4938
 Project: HBase
  Issue Type: Improvement
Reporter: dhruba borthakur
Assignee: dhruba borthakur
Priority: Minor
 Attachments: scannerMVCC1.txt


 There is an existing api HRegion.getScanner(Scan) that allows scanning a 
 table. My proposal is to extend it to HRegion.getScanner(Scan, long readPoint)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Updated] (HBASE-4938) Create a HRegion.getScanner public method that allows reading from a specified readPoint

2011-12-15 Thread Zhihong Yu (Updated) (JIRA)

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

Zhihong Yu updated HBASE-4938:
--

Status: Open  (was: Patch Available)

 Create a HRegion.getScanner public method that allows reading from a 
 specified readPoint
 

 Key: HBASE-4938
 URL: https://issues.apache.org/jira/browse/HBASE-4938
 Project: HBase
  Issue Type: Improvement
Reporter: dhruba borthakur
Assignee: dhruba borthakur
Priority: Minor
 Attachments: scannerMVCC1.txt


 There is an existing api HRegion.getScanner(Scan) that allows scanning a 
 table. My proposal is to extend it to HRegion.getScanner(Scan, long readPoint)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira





[jira] [Commented] (HBASE-5040) Secure HBase builds fail

2011-12-15 Thread Zhihong Yu (Commented) (JIRA)

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

Zhihong Yu commented on HBASE-5040:
---

Hadoop QA only builds insecure HBase.
How would we know that the fix actually works for secure HBase ?

 Secure HBase builds fail
 

 Key: HBASE-5040
 URL: https://issues.apache.org/jira/browse/HBASE-5040
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.92.0
Reporter: Zhihong Yu
 Fix For: 0.92.0

 Attachments: 5040.txt


 I saw the following in HBase-0.92-security build #39:
 {code}
 [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-compiler-plugin:2.0.2:testCompile 
 (default-testCompile) on project hbase: Compilation failure
 [ERROR] 
 https://builds.apache.org/job/HBase-0.92-security/ws/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestStore.java:[590,4]
  method does not override or implement a method from a supertype
 [ERROR] - [Help 1]
 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
 goal org.apache.maven.plugins:maven-compiler-plugin:2.0.2:testCompile 
 (default-testCompile) on project hbase: Compilation failure
 https://builds.apache.org/job/HBase-0.92-security/ws/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestStore.java:[590,4]
  method does not override or implement a method from a supertype
 {code}
 The above was probably introduced by HBASE-5006

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Created] (HBASE-5049) TestHLogSplit.testLogRollAfterSplitStart not working due to HBASE-5006

2011-12-15 Thread Jimmy Xiang (Created) (JIRA)
TestHLogSplit.testLogRollAfterSplitStart not working due to HBASE-5006
--

 Key: HBASE-5049
 URL: https://issues.apache.org/jira/browse/HBASE-5049
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.92.0, 0.94.0
Reporter: Jimmy Xiang
Priority: Trivial


java.lang.IllegalStateException: Can't overwrite cause
at java.lang.Throwable.initCause(Throwable.java:320)
at 
org.apache.hadoop.hbase.regionserver.wal.HLog.createWriter(HLog.java:624)
at 
org.apache.hadoop.hbase.regionserver.wal.HLog.createWriterInstance(HLog.java:570)
at 
org.apache.hadoop.hbase.regionserver.wal.HLog.rollWriter(HLog.java:504)
at 
org.apache.hadoop.hbase.regionserver.wal.TestHLogSplit.testLogRollAfterSplitStart(TestHLogSplit.java:880)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Resolved] (HBASE-904) Make client capable of riding over a cluster restart

2011-12-15 Thread Andrew Purtell (Resolved) (JIRA)

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

Andrew Purtell resolved HBASE-904.
--

Resolution: Not A Problem
  Assignee: (was: Andrew Purtell)

No longer a problem.

 Make client capable of riding over a cluster restart
 

 Key: HBASE-904
 URL: https://issues.apache.org/jira/browse/HBASE-904
 Project: HBase
  Issue Type: Sub-task
Reporter: stack

 Currently, clients buried in REST server at least, are unable to recalibrate 
 if the cluster is restarted on them.  Fix it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Updated] (HBASE-5049) TestHLogSplit.testLogRollAfterSplitStart not working due to HBASE-5006

2011-12-15 Thread Jimmy Xiang (Updated) (JIRA)

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

Jimmy Xiang updated HBASE-5049:
---

Attachment: 0001-HBASE-5049-TestHLogSplit.testLogRollAfterSplitStart-.patch

 TestHLogSplit.testLogRollAfterSplitStart not working due to HBASE-5006
 --

 Key: HBASE-5049
 URL: https://issues.apache.org/jira/browse/HBASE-5049
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.92.0, 0.94.0
Reporter: Jimmy Xiang
Priority: Trivial
 Attachments: 
 0001-HBASE-5049-TestHLogSplit.testLogRollAfterSplitStart-.patch


 java.lang.IllegalStateException: Can't overwrite cause
   at java.lang.Throwable.initCause(Throwable.java:320)
   at 
 org.apache.hadoop.hbase.regionserver.wal.HLog.createWriter(HLog.java:624)
   at 
 org.apache.hadoop.hbase.regionserver.wal.HLog.createWriterInstance(HLog.java:570)
   at 
 org.apache.hadoop.hbase.regionserver.wal.HLog.rollWriter(HLog.java:504)
   at 
 org.apache.hadoop.hbase.regionserver.wal.TestHLogSplit.testLogRollAfterSplitStart(TestHLogSplit.java:880)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Updated] (HBASE-5049) TestHLogSplit.testLogRollAfterSplitStart not working due to HBASE-5006

2011-12-15 Thread Jimmy Xiang (Updated) (JIRA)

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

Jimmy Xiang updated HBASE-5049:
---

Assignee: Jimmy Xiang
  Status: Patch Available  (was: Open)

 TestHLogSplit.testLogRollAfterSplitStart not working due to HBASE-5006
 --

 Key: HBASE-5049
 URL: https://issues.apache.org/jira/browse/HBASE-5049
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.92.0, 0.94.0
Reporter: Jimmy Xiang
Assignee: Jimmy Xiang
Priority: Trivial
 Attachments: 
 0001-HBASE-5049-TestHLogSplit.testLogRollAfterSplitStart-.patch


 java.lang.IllegalStateException: Can't overwrite cause
   at java.lang.Throwable.initCause(Throwable.java:320)
   at 
 org.apache.hadoop.hbase.regionserver.wal.HLog.createWriter(HLog.java:624)
   at 
 org.apache.hadoop.hbase.regionserver.wal.HLog.createWriterInstance(HLog.java:570)
   at 
 org.apache.hadoop.hbase.regionserver.wal.HLog.rollWriter(HLog.java:504)
   at 
 org.apache.hadoop.hbase.regionserver.wal.TestHLogSplit.testLogRollAfterSplitStart(TestHLogSplit.java:880)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-5049) TestHLogSplit.testLogRollAfterSplitStart not working due to HBASE-5006

2011-12-15 Thread jirapos...@reviews.apache.org (Commented) (JIRA)

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

jirapos...@reviews.apache.org commented on HBASE-5049:
--


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3218/
---

Review request for hbase, Todd Lipcon, Ted Yu, and Michael Stack.


Summary
---

Minor unit test fix.


This addresses bug HBASE-5049.
https://issues.apache.org/jira/browse/HBASE-5049


Diffs
-

  src/main/java/org/apache/hadoop/hbase/regionserver/wal/HLog.java 90f9243 

Diff: https://reviews.apache.org/r/3218/diff


Testing
---

TestHLogSplit works fine in eclipse now.


Thanks,

Jimmy



 TestHLogSplit.testLogRollAfterSplitStart not working due to HBASE-5006
 --

 Key: HBASE-5049
 URL: https://issues.apache.org/jira/browse/HBASE-5049
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.92.0, 0.94.0
Reporter: Jimmy Xiang
Assignee: Jimmy Xiang
Priority: Trivial
 Attachments: 
 0001-HBASE-5049-TestHLogSplit.testLogRollAfterSplitStart-.patch


 java.lang.IllegalStateException: Can't overwrite cause
   at java.lang.Throwable.initCause(Throwable.java:320)
   at 
 org.apache.hadoop.hbase.regionserver.wal.HLog.createWriter(HLog.java:624)
   at 
 org.apache.hadoop.hbase.regionserver.wal.HLog.createWriterInstance(HLog.java:570)
   at 
 org.apache.hadoop.hbase.regionserver.wal.HLog.rollWriter(HLog.java:504)
   at 
 org.apache.hadoop.hbase.regionserver.wal.TestHLogSplit.testLogRollAfterSplitStart(TestHLogSplit.java:880)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-5049) TestHLogSplit.testLogRollAfterSplitStart not working due to HBASE-5006

2011-12-15 Thread Zhihong Yu (Commented) (JIRA)

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

Zhihong Yu commented on HBASE-5049:
---

I looked at 
https://builds.apache.org/view/G-L/view/HBase/job/HBase-TRUNK/2547/console and 
saw TestHLogSplit pass.

I ran TestHLogSplit#testLogRollAfterSplitStart on MacBook for both TRUNK and 
0.92 - I didn't see the exception.

Can you let me know how the test failure can be reproduced ?

 TestHLogSplit.testLogRollAfterSplitStart not working due to HBASE-5006
 --

 Key: HBASE-5049
 URL: https://issues.apache.org/jira/browse/HBASE-5049
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.92.0, 0.94.0
Reporter: Jimmy Xiang
Assignee: Jimmy Xiang
Priority: Trivial
 Attachments: 
 0001-HBASE-5049-TestHLogSplit.testLogRollAfterSplitStart-.patch


 java.lang.IllegalStateException: Can't overwrite cause
   at java.lang.Throwable.initCause(Throwable.java:320)
   at 
 org.apache.hadoop.hbase.regionserver.wal.HLog.createWriter(HLog.java:624)
   at 
 org.apache.hadoop.hbase.regionserver.wal.HLog.createWriterInstance(HLog.java:570)
   at 
 org.apache.hadoop.hbase.regionserver.wal.HLog.rollWriter(HLog.java:504)
   at 
 org.apache.hadoop.hbase.regionserver.wal.TestHLogSplit.testLogRollAfterSplitStart(TestHLogSplit.java:880)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-5044) Clarify solution for problem described on http://hbase.apache.org/book/trouble.mapreduce.html

2011-12-15 Thread Hadoop QA (Commented) (JIRA)

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

Hadoop QA commented on HBASE-5044:
--

-1 overall.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12507571/HBASE-5044.patch
  against trunk revision .

+1 @author.  The patch does not contain any @author tags.

+0 tests included.  The patch appears to be a documentation patch that 
doesn't require tests.

-1 javadoc.  The javadoc tool appears to have generated -152 warning 
messages.

+1 javac.  The applied patch does not increase the total number of javac 
compiler warnings.

-1 findbugs.  The patch appears to introduce 76 new Findbugs (version 
1.3.9) warnings.

+1 release audit.  The applied patch does not increase the total number of 
release audit warnings.

+1 core tests.  The patch passed unit tests in .

Test results: 
https://builds.apache.org/job/PreCommit-HBASE-Build/515//testReport/
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/515//artifact/trunk/patchprocess/newPatchFindbugsWarnings.html
Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/515//console

This message is automatically generated.

 Clarify solution for problem described on 
 http://hbase.apache.org/book/trouble.mapreduce.html
 -

 Key: HBASE-5044
 URL: https://issues.apache.org/jira/browse/HBASE-5044
 Project: HBase
  Issue Type: Improvement
  Components: documentation
Reporter: Eugene Koontz
Assignee: Eugene Koontz
Priority: Trivial
 Fix For: 0.90.4, 0.94.0

 Attachments: HBASE-5044.patch


 Add some documentation regarding how to fix the problem described on :
 http://hbase.apache.org/apidocs/org/apache/hadoop/hbase/mapreduce/package-summary.html#classpath
 Should be some text like: 
 {quote}
 You should run your mapreduce job with your {{HADOOP_CLASSPATH}} set to 
 include the HBase jar and HBase's configured classpath. For example 
 (substitute your own hbase jar location for is {{hbase-0.90.0-SNAPSHOT.jar}}):
 {quote}
 {code}
 HADOOP_CLASSPATH=${HBASE_HOME}/target/hbase-0.90.0-SNAPSHOT.jar:`${HBASE_HOME}/bin/hbase
  classpath` ${HADOOP_HOME}/bin/hadoop jar 
 ${HBASE_HOME}/target/hbase-0.90.0-SNAPSHOT.jar rowcounter usertable
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-4938) Create a HRegion.getScanner public method that allows reading from a specified readPoint

2011-12-15 Thread Zhihong Yu (Commented) (JIRA)

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

Zhihong Yu commented on HBASE-4938:
---

PreCommit build isn't running.
New patch needs to be attached.

 Create a HRegion.getScanner public method that allows reading from a 
 specified readPoint
 

 Key: HBASE-4938
 URL: https://issues.apache.org/jira/browse/HBASE-4938
 Project: HBase
  Issue Type: Improvement
Reporter: dhruba borthakur
Assignee: dhruba borthakur
Priority: Minor
 Attachments: scannerMVCC1.txt


 There is an existing api HRegion.getScanner(Scan) that allows scanning a 
 table. My proposal is to extend it to HRegion.getScanner(Scan, long readPoint)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-5040) Secure HBase builds fail

2011-12-15 Thread Hadoop QA (Commented) (JIRA)

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

Hadoop QA commented on HBASE-5040:
--

-1 overall.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12507573/5040.txt
  against trunk revision .

+1 @author.  The patch does not contain any @author tags.

+1 tests included.  The patch appears to include 3 new or modified tests.

-1 javadoc.  The javadoc tool appears to have generated -152 warning 
messages.

+1 javac.  The applied patch does not increase the total number of javac 
compiler warnings.

-1 findbugs.  The patch appears to introduce 76 new Findbugs (version 
1.3.9) warnings.

+1 release audit.  The applied patch does not increase the total number of 
release audit warnings.

 -1 core tests.  The patch failed these unit tests:
   org.apache.hadoop.hbase.client.TestInstantSchemaChange

Test results: 
https://builds.apache.org/job/PreCommit-HBASE-Build/516//testReport/
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/516//artifact/trunk/patchprocess/newPatchFindbugsWarnings.html
Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/516//console

This message is automatically generated.

 Secure HBase builds fail
 

 Key: HBASE-5040
 URL: https://issues.apache.org/jira/browse/HBASE-5040
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.92.0
Reporter: Zhihong Yu
 Fix For: 0.92.0

 Attachments: 5040.txt


 I saw the following in HBase-0.92-security build #39:
 {code}
 [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-compiler-plugin:2.0.2:testCompile 
 (default-testCompile) on project hbase: Compilation failure
 [ERROR] 
 https://builds.apache.org/job/HBase-0.92-security/ws/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestStore.java:[590,4]
  method does not override or implement a method from a supertype
 [ERROR] - [Help 1]
 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
 goal org.apache.maven.plugins:maven-compiler-plugin:2.0.2:testCompile 
 (default-testCompile) on project hbase: Compilation failure
 https://builds.apache.org/job/HBase-0.92-security/ws/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestStore.java:[590,4]
  method does not override or implement a method from a supertype
 {code}
 The above was probably introduced by HBASE-5006

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-5040) Secure HBase builds fail

2011-12-15 Thread Andrew Purtell (Commented) (JIRA)

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

Andrew Purtell commented on HBASE-5040:
---

We really should be building security with the same upstream Hadoop artifact as 
otherwise. So while your change will get the security build past this breakage, 
it's not the right fix IMO. We should get HADOOP-7070 into the next RC of 1.0, 
if there is going to be one, or put up an updated patched version of Hadoop.

 Secure HBase builds fail
 

 Key: HBASE-5040
 URL: https://issues.apache.org/jira/browse/HBASE-5040
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.92.0
Reporter: Zhihong Yu
 Fix For: 0.92.0

 Attachments: 5040.txt


 I saw the following in HBase-0.92-security build #39:
 {code}
 [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-compiler-plugin:2.0.2:testCompile 
 (default-testCompile) on project hbase: Compilation failure
 [ERROR] 
 https://builds.apache.org/job/HBase-0.92-security/ws/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestStore.java:[590,4]
  method does not override or implement a method from a supertype
 [ERROR] - [Help 1]
 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
 goal org.apache.maven.plugins:maven-compiler-plugin:2.0.2:testCompile 
 (default-testCompile) on project hbase: Compilation failure
 https://builds.apache.org/job/HBase-0.92-security/ws/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestStore.java:[590,4]
  method does not override or implement a method from a supertype
 {code}
 The above was probably introduced by HBASE-5006

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




  1   2   >