[jira] [Updated] (HBASE-4893) HConnectionImplementation closed-but-not-deleted, need a way to find the state of connection
[ 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
[ 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
[ 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.
[ 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()
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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()
[ 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
[ 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
[ 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
[ 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.
[ 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.
[ 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.
[ 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.
[ 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
[ 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
[ 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
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
[ 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
[ 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.
[ 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
[ 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
[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
[ 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
[ 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.
[ 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
[ 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
[ 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
[ 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
[ 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.
[ 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.
[ 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
[ 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.
[ 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.
[ 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.
[ 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.
[ 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.
[ 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
[ 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
[ 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
[ 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
[ 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
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
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
[ 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
[ 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
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
[ 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
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
[ 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
[ 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
[ 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
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
[ 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
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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[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
[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
[ 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
[ 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
[ 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()
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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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