[jira] [Commented] (HBASE-4304) requestsPerSecond counter stuck at 0
[ https://issues.apache.org/jira/browse/HBASE-4304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13136841#comment-13136841 ] stack commented on HBASE-4304: -- @Li Yeah. Svn for now. Do what Mr. Todd says. requestsPerSecond counter stuck at 0 Key: HBASE-4304 URL: https://issues.apache.org/jira/browse/HBASE-4304 Project: HBase Issue Type: Bug Components: master, regionserver Affects Versions: 0.92.0 Reporter: Todd Lipcon Assignee: Li Pi Priority: Critical Fix For: 0.92.0 Attachments: 4304v1.txt Running trunk @ r1163343, all of the requestsPerSecond counters are showing 0 both in the master UI and in the RS UI. The writeRequestsCount metric is properly updating in the RS UI. -- 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-4304) requestsPerSecond counter stuck at 0
[ https://issues.apache.org/jira/browse/HBASE-4304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Li Pi updated HBASE-4304: - Status: Patch Available (was: Open) requestsPerSecond counter stuck at 0 Key: HBASE-4304 URL: https://issues.apache.org/jira/browse/HBASE-4304 Project: HBase Issue Type: Bug Components: master, regionserver Affects Versions: 0.92.0 Reporter: Todd Lipcon Assignee: Li Pi Priority: Critical Fix For: 0.92.0 Attachments: 4304v1.txt, 4304v2.txt Running trunk @ r1163343, all of the requestsPerSecond counters are showing 0 both in the master UI and in the RS UI. The writeRequestsCount metric is properly updating in the RS UI. -- 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-4304) requestsPerSecond counter stuck at 0
[ https://issues.apache.org/jira/browse/HBASE-4304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Li Pi updated HBASE-4304: - Attachment: 4304v2.txt requestsPerSecond counter stuck at 0 Key: HBASE-4304 URL: https://issues.apache.org/jira/browse/HBASE-4304 Project: HBase Issue Type: Bug Components: master, regionserver Affects Versions: 0.92.0 Reporter: Todd Lipcon Assignee: Li Pi Priority: Critical Fix For: 0.92.0 Attachments: 4304v1.txt, 4304v2.txt Running trunk @ r1163343, all of the requestsPerSecond counters are showing 0 both in the master UI and in the RS UI. The writeRequestsCount metric is properly updating in the RS UI. -- 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-4304) requestsPerSecond counter stuck at 0
[ https://issues.apache.org/jira/browse/HBASE-4304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13136851#comment-13136851 ] Li Pi commented on HBASE-4304: -- done. going to sleep now. requestsPerSecond counter stuck at 0 Key: HBASE-4304 URL: https://issues.apache.org/jira/browse/HBASE-4304 Project: HBase Issue Type: Bug Components: master, regionserver Affects Versions: 0.92.0 Reporter: Todd Lipcon Assignee: Li Pi Priority: Critical Fix For: 0.92.0 Attachments: 4304v1.txt, 4304v2.txt Running trunk @ r1163343, all of the requestsPerSecond counters are showing 0 both in the master UI and in the RS UI. The writeRequestsCount metric is properly updating in the RS UI. -- 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-4224) Need a flush by regionserver rather than by table option
[ https://issues.apache.org/jira/browse/HBASE-4224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13136858#comment-13136858 ] Akash Ashok commented on HBASE-4224: Cool. Just taking a deeper look so that we make sure we're making the right decision 1. New API - Use of RegionServer side threading - Synchronize on HBaseAdmin side using zookeeper 2. Existing API - Threading on client side I am in favour of 2. Any suggestions or concerns ? Need a flush by regionserver rather than by table option Key: HBASE-4224 URL: https://issues.apache.org/jira/browse/HBASE-4224 Project: HBase Issue Type: Bug Components: shell Reporter: stack Assignee: Akash Ashok Attachments: HBase-4224.patch This evening needed to clean out logs on the cluster. logs are by regionserver. to let go of logs, we need to have all edits emptied from memory. only flush is by table or region. We need to be able to flush the regionserver. Need to add this. -- 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-4304) requestsPerSecond counter stuck at 0
[ https://issues.apache.org/jira/browse/HBASE-4304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13136920#comment-13136920 ] Hadoop QA commented on HBASE-4304: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12501046/4304v2.txt against trunk revision . +1 @author. The patch does not contain any @author tags. -1 tests included. The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. -1 javadoc. The javadoc tool appears to have generated -167 warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any 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.metrics.TestMetricsMBeanBase org.apache.hadoop.hbase.master.TestDistributedLogSplitting org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort org.apache.hadoop.hbase.coprocessor.TestMasterObserver Test results: https://builds.apache.org/job/PreCommit-HBASE-Build/77//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/77//artifact/trunk/patchprocess/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/77//console This message is automatically generated. requestsPerSecond counter stuck at 0 Key: HBASE-4304 URL: https://issues.apache.org/jira/browse/HBASE-4304 Project: HBase Issue Type: Bug Components: master, regionserver Affects Versions: 0.92.0 Reporter: Todd Lipcon Assignee: Li Pi Priority: Critical Fix For: 0.92.0 Attachments: 4304v1.txt, 4304v2.txt Running trunk @ r1163343, all of the requestsPerSecond counters are showing 0 both in the master UI and in the RS UI. The writeRequestsCount metric is properly updating in the RS UI. -- 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-4669) Add an option of using round-robin assignment for enabling table
[ https://issues.apache.org/jira/browse/HBASE-4669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jieshan Bean updated HBASE-4669: Attachment: HBASE-4669-Trunk-V2.patch HBASE-4669-90-V2.patch Add an option of using round-robin assignment for enabling table Key: HBASE-4669 URL: https://issues.apache.org/jira/browse/HBASE-4669 Project: HBase Issue Type: Improvement Components: master Affects Versions: 0.90.4, 0.94.0 Reporter: Jieshan Bean Priority: Minor Fix For: 0.94.0, 0.90.5 Attachments: HBASE-4669-90-V2.patch, HBASE-4669-90.patch, HBASE-4669-Trunk-V2.patch, HBASE-4669-Trunk.patch Under some scenarios, we use the function of disable/enable HTable. But currently, enable HTable uses the random-assignment. We hope all the regions show a better distribution, no matter how many regions and how many regionservers. So I suggest to add an option of using round-robin assignment on enable-table. -- 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-4669) Add an option of using round-robin assignment for enabling table
[ https://issues.apache.org/jira/browse/HBASE-4669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jieshan Bean updated HBASE-4669: Attachment: (was: HBASE-4669-Trunk-V2.patch) Add an option of using round-robin assignment for enabling table Key: HBASE-4669 URL: https://issues.apache.org/jira/browse/HBASE-4669 Project: HBase Issue Type: Improvement Components: master Affects Versions: 0.90.4, 0.94.0 Reporter: Jieshan Bean Priority: Minor Fix For: 0.94.0, 0.90.5 Attachments: HBASE-4669-90-V2.patch, HBASE-4669-90.patch, HBASE-4669-Trunk-V2.patch, HBASE-4669-Trunk.patch Under some scenarios, we use the function of disable/enable HTable. But currently, enable HTable uses the random-assignment. We hope all the regions show a better distribution, no matter how many regions and how many regionservers. So I suggest to add an option of using round-robin assignment on enable-table. -- 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-4457) Starting region server on non-default info port is resulting in broken URL's in master UI
[ https://issues.apache.org/jira/browse/HBASE-4457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137000#comment-13137000 ] Praveen Patibandla commented on HBASE-4457: --- Temporary fix won't work if we start multiple region servers on the same machine.I'm not able to allocate my time to work on this item.I hope someone else can pick it up. Starting region server on non-default info port is resulting in broken URL's in master UI - Key: HBASE-4457 URL: https://issues.apache.org/jira/browse/HBASE-4457 Project: HBase Issue Type: Bug Components: master Affects Versions: 0.92.0 Reporter: Praveen Patibandla Priority: Critical Labels: newbie Fix For: 0.92.0 Attachments: 4457-V1.patch, 4457.patch When hbase.regionserver.info.port is set to non-default port, Master UI has broken URL's in the region server table because it's hard coded to default port. -- 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-4120) isolation and allocation
[ https://issues.apache.org/jira/browse/HBASE-4120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137111#comment-13137111 ] jirapos...@reviews.apache.org commented on HBASE-4120: -- --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/1421/ --- (Updated 2011-10-27 13:05:36.419396) Review request for hbase. Changes --- fix v3 patch's review problems Summary --- Patch used for table priority alone,In this patch, not only tables can have different priorities but also the different actions like get,scan,put and delete can have priorities. This addresses bug HBase-4120. https://issues.apache.org/jira/browse/HBase-4120 Diffs (updated) - http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/ipc/HBaseRPC.java 1189169 http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/ipc/HBaseServer.java 1189169 http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/ipc/PriorityFunction.java PRE-CREATION http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/ipc/PriorityHBaseServer.java PRE-CREATION http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/ipc/PriorityJobQueue.java PRE-CREATION http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java 1189169 http://svn.apache.org/repos/asf/hbase/trunk/src/test/java/org/apache/hadoop/hbase/allocation/test/TestForActionPriority.java PRE-CREATION http://svn.apache.org/repos/asf/hbase/trunk/src/test/java/org/apache/hadoop/hbase/allocation/test/TestForPriorityJobQueue.java PRE-CREATION http://svn.apache.org/repos/asf/hbase/trunk/src/test/java/org/apache/hadoop/hbase/allocation/test/TestForTablePriority.java PRE-CREATION Diff: https://reviews.apache.org/r/1421/diff Testing --- Tested with test cases in TestCase_For_TablePriority_trunk_v1.patch please apply the patch of HBASE-4181 first,in some circumstances this bug will affect the performance of client. Thanks, Jia isolation and allocation Key: HBASE-4120 URL: https://issues.apache.org/jira/browse/HBASE-4120 Project: HBase Issue Type: New Feature Components: master, regionserver Affects Versions: 0.90.2, 0.90.3, 0.90.4, 0.92.0 Reporter: Liu Jia Fix For: 0.94.0 Attachments: Design_document_for_HBase_isolation_and_allocation.pdf, Design_document_for_HBase_isolation_and_allocation_Revised.pdf, HBase_isolation_and_allocation_user_guide.pdf, Performance_of_Table_priority.pdf, System Structure.jpg, TablePriority.patch The HBase isolation and allocation tool is designed to help users manage cluster resource among different application and tables. When we have a large scale of HBase cluster with many applications running on it, there will be lots of problems. In Taobao there is a cluster for many departments to test their applications performance, these applications are based on HBase. With one cluster which has 12 servers, there will be only one application running exclusively on this server, and many other applications must wait until the previous test finished. After we add allocation manage function to the cluster, applications can share the cluster and run concurrently. Also if the Test Engineer wants to make sure there is no interference, he/she can move out other tables from this group. In groups we use table priority to allocate resource, when system is busy; we can make sure high-priority tables are not affected lower-priority tables Different groups can have different region server configurations, some groups optimized for reading can have large block cache size, and others optimized for writing can have large memstore size. Tables and region servers can be moved easily between groups; after changing the configuration, a group can be restarted alone instead of restarting the whole cluster. git entry : https://github.com/ICT-Ope/HBase_allocation . We hope our work is helpful. -- 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-4669) Add an option of using round-robin assignment for enabling table
[ https://issues.apache.org/jira/browse/HBASE-4669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137119#comment-13137119 ] Ted Yu commented on HBASE-4669: --- Since this is an improvement, no patch for 0.90 is needed. Add an option of using round-robin assignment for enabling table Key: HBASE-4669 URL: https://issues.apache.org/jira/browse/HBASE-4669 Project: HBase Issue Type: Improvement Components: master Affects Versions: 0.90.4, 0.94.0 Reporter: Jieshan Bean Priority: Minor Fix For: 0.94.0, 0.90.5 Attachments: HBASE-4669-90-V2.patch, HBASE-4669-90.patch, HBASE-4669-Trunk-V2.patch, HBASE-4669-Trunk.patch Under some scenarios, we use the function of disable/enable HTable. But currently, enable HTable uses the random-assignment. We hope all the regions show a better distribution, no matter how many regions and how many regionservers. So I suggest to add an option of using round-robin assignment on enable-table. -- 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-4304) requestsPerSecond counter stuck at 0
[ https://issues.apache.org/jira/browse/HBASE-4304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137152#comment-13137152 ] Ted Yu commented on HBASE-4304: --- @Li: Please address TestMetricsMBeanBase first. requestsPerSecond counter stuck at 0 Key: HBASE-4304 URL: https://issues.apache.org/jira/browse/HBASE-4304 Project: HBase Issue Type: Bug Components: master, regionserver Affects Versions: 0.92.0 Reporter: Todd Lipcon Assignee: Li Pi Priority: Critical Fix For: 0.92.0 Attachments: 4304v1.txt, 4304v2.txt Running trunk @ r1163343, all of the requestsPerSecond counters are showing 0 both in the master UI and in the RS UI. The writeRequestsCount metric is properly updating in the RS UI. -- 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-4224) Need a flush by regionserver rather than by table option
[
https://issues.apache.org/jira/browse/HBASE-4224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137180#comment-13137180
]
Akash Ashok commented on HBASE-4224:
Also in HBaseAdmin.java
{code}
public synchronized byte[][] rollHLogWriter(String serverName)
{code}
I don't find a need for this to be synchronized. These are anyways synchronized
on the HLog side. Am I missing something here or can I remove synchronized ?
Need a flush by regionserver rather than by table option
Key: HBASE-4224
URL: https://issues.apache.org/jira/browse/HBASE-4224
Project: HBase
Issue Type: Bug
Components: shell
Reporter: stack
Assignee: Akash Ashok
Attachments: HBase-4224.patch
This evening needed to clean out logs on the cluster. logs are by
regionserver. to let go of logs, we need to have all edits emptied from
memory. only flush is by table or region. We need to be able to flush the
regionserver. Need to add this.
--
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-4457) Starting region server on non-default info port is resulting in broken URL's in master UI
[ https://issues.apache.org/jira/browse/HBASE-4457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137199#comment-13137199 ] stack commented on HBASE-4457: -- @Praveen No problem. Yeah the temporary workaround won't work if multiple regionservers on single machine. Thats rare though I'd say. Starting region server on non-default info port is resulting in broken URL's in master UI - Key: HBASE-4457 URL: https://issues.apache.org/jira/browse/HBASE-4457 Project: HBase Issue Type: Bug Components: master Affects Versions: 0.92.0 Reporter: Praveen Patibandla Priority: Critical Labels: newbie Fix For: 0.92.0 Attachments: 4457-V1.patch, 4457.patch When hbase.regionserver.info.port is set to non-default port, Master UI has broken URL's in the region server table because it's hard coded to default port. -- 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-4669) Add an option of using round-robin assignment for enabling table
[ https://issues.apache.org/jira/browse/HBASE-4669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-4669: -- Fix Version/s: (was: 0.90.5) Add an option of using round-robin assignment for enabling table Key: HBASE-4669 URL: https://issues.apache.org/jira/browse/HBASE-4669 Project: HBase Issue Type: Improvement Components: master Affects Versions: 0.90.4, 0.94.0 Reporter: Jieshan Bean Priority: Minor Fix For: 0.94.0 Attachments: HBASE-4669-90-V2.patch, HBASE-4669-90.patch, HBASE-4669-Trunk-V2.patch, HBASE-4669-Trunk.patch Under some scenarios, we use the function of disable/enable HTable. But currently, enable HTable uses the random-assignment. We hope all the regions show a better distribution, no matter how many regions and how many regionservers. So I suggest to add an option of using round-robin assignment on enable-table. -- 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-4669) Add an option of using round-robin assignment for enabling table
[ https://issues.apache.org/jira/browse/HBASE-4669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu reassigned HBASE-4669: - Assignee: Jieshan Bean Add an option of using round-robin assignment for enabling table Key: HBASE-4669 URL: https://issues.apache.org/jira/browse/HBASE-4669 Project: HBase Issue Type: Improvement Components: master Affects Versions: 0.90.4, 0.94.0 Reporter: Jieshan Bean Assignee: Jieshan Bean Priority: Minor Fix For: 0.94.0 Attachments: HBASE-4669-90-V2.patch, HBASE-4669-90.patch, HBASE-4669-Trunk-V2.patch, HBASE-4669-Trunk.patch Under some scenarios, we use the function of disable/enable HTable. But currently, enable HTable uses the random-assignment. We hope all the regions show a better distribution, no matter how many regions and how many regionservers. So I suggest to add an option of using round-robin assignment on enable-table. -- 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-4669) Add an option of using round-robin assignment for enabling table
[ https://issues.apache.org/jira/browse/HBASE-4669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-4669: -- Status: Patch Available (was: Open) Add an option of using round-robin assignment for enabling table Key: HBASE-4669 URL: https://issues.apache.org/jira/browse/HBASE-4669 Project: HBase Issue Type: Improvement Components: master Affects Versions: 0.90.4, 0.94.0 Reporter: Jieshan Bean Priority: Minor Fix For: 0.94.0, 0.90.5 Attachments: HBASE-4669-90-V2.patch, HBASE-4669-90.patch, HBASE-4669-Trunk-V2.patch, HBASE-4669-Trunk.patch Under some scenarios, we use the function of disable/enable HTable. But currently, enable HTable uses the random-assignment. We hope all the regions show a better distribution, no matter how many regions and how many regionservers. So I suggest to add an option of using round-robin assignment on enable-table. -- 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-4669) Add an option of using round-robin assignment for enabling table
[ https://issues.apache.org/jira/browse/HBASE-4669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137224#comment-13137224 ] Ted Yu commented on HBASE-4669: --- +1 on patch v2 for TRUNK. Add an option of using round-robin assignment for enabling table Key: HBASE-4669 URL: https://issues.apache.org/jira/browse/HBASE-4669 Project: HBase Issue Type: Improvement Components: master Affects Versions: 0.90.4, 0.94.0 Reporter: Jieshan Bean Assignee: Jieshan Bean Priority: Minor Fix For: 0.94.0 Attachments: HBASE-4669-90-V2.patch, HBASE-4669-90.patch, HBASE-4669-Trunk-V2.patch, HBASE-4669-Trunk.patch Under some scenarios, we use the function of disable/enable HTable. But currently, enable HTable uses the random-assignment. We hope all the regions show a better distribution, no matter how many regions and how many regionservers. So I suggest to add an option of using round-robin assignment on enable-table. -- 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-4685) TestDistributedLogSplitting.testOrphanLogCreation failing because of ArithmeticException: / by zero.
[ https://issues.apache.org/jira/browse/HBASE-4685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137251#comment-13137251 ] Ted Yu commented on HBASE-4685: --- +1 on patch. TestDistributedLogSplitting.testOrphanLogCreation failing because of ArithmeticException: / by zero. Key: HBASE-4685 URL: https://issues.apache.org/jira/browse/HBASE-4685 Project: HBase Issue Type: Bug Reporter: stack Attachments: 4685.txt -- 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-4639) DFS Cluster is used while not needed in some unit tests
[ https://issues.apache.org/jira/browse/HBASE-4639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137276#comment-13137276 ] nkeywal commented on HBASE-4639: Was actually implemented in HBASE-4634. On the tests mentioned above, on the central build, it brings the time from 4 minutes to 17 seconds. DFS Cluster is used while not needed in some unit tests --- Key: HBASE-4639 URL: https://issues.apache.org/jira/browse/HBASE-4639 Project: HBase Issue Type: Improvement Components: test Affects Versions: 0.94.0 Environment: all Reporter: nkeywal Assignee: nkeywal Priority: Minor Some tests could go directly to the localsystem instead of using a DFS cluster. This speeds-up the test. TestScanner From 60s to 5s TestCompaction from 140s to 15s TestGetClosestAtOrBefore from 9s to 1s TestStoreFile from 30s to 2s TestWideScanner: 18s - 3s TestFSTableDescriptorForceCreation 3s - 1s There is a partial dependency with HBASE-4634, as we now write on localdisk the data is not freed when the test is over. -- 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-4300) Start of new-version master fails if old master's znode is hanging around
[ https://issues.apache.org/jira/browse/HBASE-4300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-4300: - Status: Patch Available (was: Open) Start of new-version master fails if old master's znode is hanging around - Key: HBASE-4300 URL: https://issues.apache.org/jira/browse/HBASE-4300 Project: HBase Issue Type: Bug Affects Versions: 0.92.0 Reporter: Todd Lipcon Assignee: stack Priority: Critical Fix For: 0.92.0 Attachments: 4300-v2.txt, 4300-v3.txt, 4300.txt I shut down an 0.90 cluster, and had to do so uncleanly. I then started a trunk (0.92) cluster before the old master znode had expired. This cased: java.lang.StringIndexOutOfBoundsException: String index out of range: -1 at java.lang.String.substring(String.java:1937) at org.apache.hadoop.hbase.ServerName.parseHostname(ServerName.java:81) at org.apache.hadoop.hbase.ServerName.init(ServerName.java:63) at org.apache.hadoop.hbase.master.ActiveMasterManager.blockUntilBecomingActiveMaster(ActiveMasterManager.java:148) at org.apache.hadoop.hbase.master.HMaster.becomeActiveMaster(HMaster.java:342) at org.apache.hadoop.hbase.master.HMaster.run(HMaster.java:297) -- 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-4658) Put attributes are not exposed via the ThriftServer
[ https://issues.apache.org/jira/browse/HBASE-4658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137291#comment-13137291 ] Jonathan Gray commented on HBASE-4658: -- Dhruba, it is thrift 0.7.0 (or at least it was last time I generated). If you don't have time today I can regenerate Hbase.java and commit this. Re: HBASE-1744, will this change apply after that goes in? It seems like this change could be added on top of that change but that your current patch is based on the current thrift API? Put attributes are not exposed via the ThriftServer --- Key: HBASE-4658 URL: https://issues.apache.org/jira/browse/HBASE-4658 Project: HBase Issue Type: Bug Components: thrift Reporter: dhruba borthakur Assignee: dhruba borthakur Attachments: ThriftPutAttributes1.txt The Put api also takes in a bunch of arbitrary attributes that an application can use to associate metadata with each put operation. This is not exposed via Thrift. -- 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-4120) isolation and allocation
[ https://issues.apache.org/jira/browse/HBASE-4120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137293#comment-13137293 ] jirapos...@reviews.apache.org commented on HBASE-4120: -- --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/1421/#review2880 --- http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/ipc/PriorityFunction.java https://reviews.apache.org/r/1421/#comment6449 This class doesn't belong to ipc module. How about lifting this class and PriorityJobQueue to org/apache/hadoop/hbase ? http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/ipc/PriorityFunction.java https://reviews.apache.org/r/1421/#comment6450 This key should be named PRI_KEY_ACTION_PRIORITY. The string should be _action_priority http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/ipc/PriorityFunction.java https://reviews.apache.org/r/1421/#comment6438 Should read 'The priority map caches the region's priority in memory.' Originally there was one javadoc for all the maps. Now this sentence should be specific. http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/ipc/PriorityFunction.java https://reviews.apache.org/r/1421/#comment6439 Should read 'Key is the region name which usually is obtained from the IPC call' http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/ipc/PriorityFunction.java https://reviews.apache.org/r/1421/#comment6445 Under what circumstances would a region carry different priority than the table it belongs ? If there is such scenario, we should add a test for RegionPriority. Otherwise this map can be folded into tablePriMap. http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/ipc/PriorityFunction.java https://reviews.apache.org/r/1421/#comment6442 This map should be named scannerRegionMap http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/ipc/PriorityFunction.java https://reviews.apache.org/r/1421/#comment6437 The variable name can be improved. How about naming it scannerPriMap ? http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/ipc/PriorityFunction.java https://reviews.apache.org/r/1421/#comment6448 Class name is still incorrect, missing hbase component. http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/ipc/PriorityFunction.java https://reviews.apache.org/r/1421/#comment6447 Default value here is different from the value on line 70. http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/ipc/PriorityFunction.java https://reviews.apache.org/r/1421/#comment6436 Should read 'priority should be between'. http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/ipc/PriorityFunction.java https://reviews.apache.org/r/1421/#comment6435 Should read 'to set table action priority' http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/ipc/PriorityFunction.java https://reviews.apache.org/r/1421/#comment6440 This variable should be named actionPriority http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/ipc/PriorityFunction.java https://reviews.apache.org/r/1421/#comment6441 This variable should be called scannerId. http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/ipc/PriorityHBaseServer.java https://reviews.apache.org/r/1421/#comment6451 This parameter should be named priorityHandlerCount so that it is consistent with usage in HBaseServer. http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/ipc/PriorityJobQueue.java https://reviews.apache.org/r/1421/#comment6446 Should read 'which have same or higher priority' http://svn.apache.org/repos/asf/hbase/trunk/src/test/java/org/apache/hadoop/hbase/allocation/test/TestForTablePriority.java https://reviews.apache.org/r/1421/#comment6444 Typo: should be setTablePriority http://svn.apache.org/repos/asf/hbase/trunk/src/test/java/org/apache/hadoop/hbase/allocation/test/TestForTablePriority.java https://reviews.apache.org/r/1421/#comment6443 Typo: should be setTablePriority - Ted On 2011-10-27 13:05:36, Jia Liu wrote: bq. bq. --- bq. This is an automatically generated e-mail. To reply, visit: bq. https://reviews.apache.org/r/1421/ bq. --- bq. bq. (Updated 2011-10-27 13:05:36) bq. bq. bq. Review request for
[jira] [Commented] (HBASE-4658) Put attributes are not exposed via the ThriftServer
[ https://issues.apache.org/jira/browse/HBASE-4658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137297#comment-13137297 ] stack commented on HBASE-4658: -- The hbase-1744 work is done to the side of current thrift, IIRC. I'd say make note over there about integrating this change in. Can then do regen on commit of hbase-1744. Put attributes are not exposed via the ThriftServer --- Key: HBASE-4658 URL: https://issues.apache.org/jira/browse/HBASE-4658 Project: HBase Issue Type: Bug Components: thrift Reporter: dhruba borthakur Assignee: dhruba borthakur Attachments: ThriftPutAttributes1.txt The Put api also takes in a bunch of arbitrary attributes that an application can use to associate metadata with each put operation. This is not exposed via Thrift. -- 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-1744) Thrift server to match the new java api.
[
https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-1744:
-
Status: Patch Available (was: Open)
Thrift server to match the new java api.
Key: HBASE-1744
URL: https://issues.apache.org/jira/browse/HBASE-1744
Project: HBase
Issue Type: Improvement
Components: thrift
Reporter: Tim Sell
Assignee: Tim Sell
Priority: Critical
Fix For: 0.94.0
Attachments:
0001-thrift2-enable-usage-of-.deleteColumns-for-thrift.patch,
HBASE-1744.2.patch, HBASE-1744.3.patch, HBASE-1744.4.patch,
HBASE-1744.5.patch, HBASE-1744.6.patch, HBASE-1744.7.patch,
HBASE-1744.8.patch, HBASE-1744.9.patch, HBASE-1744.preview.1.patch,
thriftexperiment.patch
This mutateRows, etc.. is a little confusing compared to the new cleaner java
client.
Thinking of ways to make a thrift client that is just as elegant. something
like:
void put(1:Bytes table, 2:TPut put) throws (1:IOError io)
with:
struct TColumn {
1:Bytes family,
2:Bytes qualifier,
3:i64 timestamp
}
struct TPut {
1:Bytes row,
2:mapTColumn, Bytes values
}
This creates more verbose rpc than if the columns in TPut were just
mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and
still be intuitive from say python.
Presumably the goal of a thrift gateway is to be easy first.
--
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-4304) requestsPerSecond counter stuck at 0
[ https://issues.apache.org/jira/browse/HBASE-4304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Li Pi updated HBASE-4304: - Attachment: 4304v3.txt requestsPerSecond counter stuck at 0 Key: HBASE-4304 URL: https://issues.apache.org/jira/browse/HBASE-4304 Project: HBase Issue Type: Bug Components: master, regionserver Affects Versions: 0.92.0 Reporter: Todd Lipcon Assignee: Li Pi Priority: Critical Fix For: 0.92.0 Attachments: 4304v1.txt, 4304v2.txt, 4304v3.txt Running trunk @ r1163343, all of the requestsPerSecond counters are showing 0 both in the master UI and in the RS UI. The writeRequestsCount metric is properly updating in the RS UI. -- 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-4304) requestsPerSecond counter stuck at 0
[ https://issues.apache.org/jira/browse/HBASE-4304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Li Pi updated HBASE-4304: - Status: Open (was: Patch Available) requestsPerSecond counter stuck at 0 Key: HBASE-4304 URL: https://issues.apache.org/jira/browse/HBASE-4304 Project: HBase Issue Type: Bug Components: master, regionserver Affects Versions: 0.92.0 Reporter: Todd Lipcon Assignee: Li Pi Priority: Critical Fix For: 0.92.0 Attachments: 4304v1.txt, 4304v2.txt, 4304v3.txt Running trunk @ r1163343, all of the requestsPerSecond counters are showing 0 both in the master UI and in the RS UI. The writeRequestsCount metric is properly updating in the RS UI. -- 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-4304) requestsPerSecond counter stuck at 0
[ https://issues.apache.org/jira/browse/HBASE-4304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Li Pi updated HBASE-4304: - Status: Patch Available (was: Open) Fixed tests. requestsPerSecond counter stuck at 0 Key: HBASE-4304 URL: https://issues.apache.org/jira/browse/HBASE-4304 Project: HBase Issue Type: Bug Components: master, regionserver Affects Versions: 0.92.0 Reporter: Todd Lipcon Assignee: Li Pi Priority: Critical Fix For: 0.92.0 Attachments: 4304v1.txt, 4304v2.txt, 4304v3.txt Running trunk @ r1163343, all of the requestsPerSecond counters are showing 0 both in the master UI and in the RS UI. The writeRequestsCount metric is properly updating in the RS UI. -- 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=13137329#comment-13137329
]
Ted Yu commented on HBASE-4605:
---
See HBASE-4554 which can be used as example for setting coprocessor table
attributes.
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: constraint_as_cp.txt, java_Constraint_v2.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] [Commented] (HBASE-4669) Add an option of using round-robin assignment for enabling table
[ https://issues.apache.org/jira/browse/HBASE-4669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137337#comment-13137337 ] Hadoop QA commented on HBASE-4669: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12501068/HBASE-4669-Trunk-V2.patch 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 -167 warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any 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.master.TestMasterFailover org.apache.hadoop.hbase.client.TestAdmin org.apache.hadoop.hbase.master.TestDistributedLogSplitting org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithRemove Test results: https://builds.apache.org/job/PreCommit-HBASE-Build/78//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/78//artifact/trunk/patchprocess/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/78//console This message is automatically generated. Add an option of using round-robin assignment for enabling table Key: HBASE-4669 URL: https://issues.apache.org/jira/browse/HBASE-4669 Project: HBase Issue Type: Improvement Components: master Affects Versions: 0.90.4, 0.94.0 Reporter: Jieshan Bean Assignee: Jieshan Bean Priority: Minor Fix For: 0.94.0 Attachments: HBASE-4669-90-V2.patch, HBASE-4669-90.patch, HBASE-4669-Trunk-V2.patch, HBASE-4669-Trunk.patch Under some scenarios, we use the function of disable/enable HTable. But currently, enable HTable uses the random-assignment. We hope all the regions show a better distribution, no matter how many regions and how many regionservers. So I suggest to add an option of using round-robin assignment on enable-table. -- 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-4611) Add support for Phabricator/Differential as an alternative code review tool
[ https://issues.apache.org/jira/browse/HBASE-4611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137343#comment-13137343 ] John Sichi commented on HBASE-4611: --- We've published the JIRA integration module on github: https://github.com/facebook/arc-jira Here's how we made it installable from Hive: https://cwiki.apache.org/confluence/display/Hive/PhabricatorCodeReview https://issues.apache.org/jira/secure/attachment/12500986/D51.2.patch Add support for Phabricator/Differential as an alternative code review tool --- Key: HBASE-4611 URL: https://issues.apache.org/jira/browse/HBASE-4611 Project: HBase Issue Type: Task Reporter: Jonathan Gray Attachments: D21.1.patch, D21.1.patch From http://phabricator.org/ : Phabricator is a open source collection of web applications which make it easier to write, review, and share source code. It is currently available as an early release. Phabricator was developed at Facebook. It's open source so pretty much anyone could host an instance of this software. To begin with, there will be a public-facing instance located at http://reviews.facebook.net (sponsored by Facebook and hosted by the OSUOSL http://osuosl.org). We will use this JIRA to deal with adding (and ensuring) Apache-friendly support that will allow us to do code reviews with Phabricator for HBase. -- 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-4685) TestDistributedLogSplitting.testOrphanLogCreation failing because of ArithmeticException: / by zero.
[ https://issues.apache.org/jira/browse/HBASE-4685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137346#comment-13137346 ] Hadoop QA commented on HBASE-4685: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12501109/4685.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 -167 warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any 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.master.TestDistributedLogSplitting org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort org.apache.hadoop.hbase.coprocessor.TestMasterObserver Test results: https://builds.apache.org/job/PreCommit-HBASE-Build/79//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/79//artifact/trunk/patchprocess/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/79//console This message is automatically generated. TestDistributedLogSplitting.testOrphanLogCreation failing because of ArithmeticException: / by zero. Key: HBASE-4685 URL: https://issues.apache.org/jira/browse/HBASE-4685 Project: HBase Issue Type: Bug Reporter: stack Attachments: 4685.txt -- 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-4688) Make it so can run PE w/o having to put hbase jar on CLASSPATH
Make it so can run PE w/o having to put hbase jar on CLASSPATH
--
Key: HBASE-4688
URL: https://issues.apache.org/jira/browse/HBASE-4688
Project: HBase
Issue Type: Bug
Reporter: stack
I need this:
{code}
diff --git a/src/test/java/org/apache/hadoop/hbase/PerformanceEvaluation.java
b/src/test/java/org/apache/hadoop/hbase/PerformanceEvaluation.java
index 3982eff..ef47d0d 100644
--- a/src/test/java/org/apache/hadoop/hbase/PerformanceEvaluation.java
+++ b/src/test/java/org/apache/hadoop/hbase/PerformanceEvaluation.java
@@ -570,6 +570,9 @@ public class PerformanceEvaluation {
TextOutputFormat.setOutputPath(job, new Path(inputDir,outputs));
TableMapReduceUtil.addDependencyJars(job);
+// Add a Class from the hbase.jar so it gets registered too.
+TableMapReduceUtil.addDependencyJars(job.getConfiguration(),
+ org.apache.hadoop.hbase.util.Bytes.class);
job.waitForCompletion(true);
}
{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-4688) Make it so can run PE w/o having to put hbase jar on CLASSPATH
[
https://issues.apache.org/jira/browse/HBASE-4688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-4688:
-
Attachment: pe.txt
Make it so can run PE w/o having to put hbase jar on CLASSPATH
--
Key: HBASE-4688
URL: https://issues.apache.org/jira/browse/HBASE-4688
Project: HBase
Issue Type: Bug
Reporter: stack
Attachments: pe.txt
I need this:
{code}
diff --git a/src/test/java/org/apache/hadoop/hbase/PerformanceEvaluation.java
b/src/test/java/org/apache/hadoop/hbase/PerformanceEvaluation.java
index 3982eff..ef47d0d 100644
--- a/src/test/java/org/apache/hadoop/hbase/PerformanceEvaluation.java
+++ b/src/test/java/org/apache/hadoop/hbase/PerformanceEvaluation.java
@@ -570,6 +570,9 @@ public class PerformanceEvaluation {
TextOutputFormat.setOutputPath(job, new Path(inputDir,outputs));
TableMapReduceUtil.addDependencyJars(job);
+// Add a Class from the hbase.jar so it gets registered too.
+TableMapReduceUtil.addDependencyJars(job.getConfiguration(),
+ org.apache.hadoop.hbase.util.Bytes.class);
job.waitForCompletion(true);
}
{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-4669) Add an option of using round-robin assignment for enabling table
[ https://issues.apache.org/jira/browse/HBASE-4669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137411#comment-13137411 ] stack commented on HBASE-4669: -- Then I do not think your patch responsible for the above test failures. The CP ones have started to show up of late. I'm on the distributed log splitting one. The TestAdmin I do not know whats going on there. I'd commit. Add an option of using round-robin assignment for enabling table Key: HBASE-4669 URL: https://issues.apache.org/jira/browse/HBASE-4669 Project: HBase Issue Type: Improvement Components: master Affects Versions: 0.90.4, 0.94.0 Reporter: Jieshan Bean Assignee: Jieshan Bean Priority: Minor Fix For: 0.94.0 Attachments: HBASE-4669-90-V2.patch, HBASE-4669-90.patch, HBASE-4669-Trunk-V2.patch, HBASE-4669-Trunk.patch Under some scenarios, we use the function of disable/enable HTable. But currently, enable HTable uses the random-assignment. We hope all the regions show a better distribution, no matter how many regions and how many regionservers. So I suggest to add an option of using round-robin assignment on enable-table. -- 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-4611) Add support for Phabricator/Differential as an alternative code review tool
[ https://issues.apache.org/jira/browse/HBASE-4611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137417#comment-13137417 ] Phabricator commented on HBASE-4611: stack has commented on the revision [jira] [HBASE-4611] Add support for Phabricator/Differential as an alternative code review tool. I thing this change is really awesome REVISION DETAIL https://reviews.facebook.net/D21 Add support for Phabricator/Differential as an alternative code review tool --- Key: HBASE-4611 URL: https://issues.apache.org/jira/browse/HBASE-4611 Project: HBase Issue Type: Task Reporter: Jonathan Gray Attachments: D21.1.patch, D21.1.patch From http://phabricator.org/ : Phabricator is a open source collection of web applications which make it easier to write, review, and share source code. It is currently available as an early release. Phabricator was developed at Facebook. It's open source so pretty much anyone could host an instance of this software. To begin with, there will be a public-facing instance located at http://reviews.facebook.net (sponsored by Facebook and hosted by the OSUOSL http://osuosl.org). We will use this JIRA to deal with adding (and ensuring) Apache-friendly support that will allow us to do code reviews with Phabricator for HBase. -- 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-4611) Add support for Phabricator/Differential as an alternative code review tool
[ https://issues.apache.org/jira/browse/HBASE-4611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137418#comment-13137418 ] Phabricator commented on HBASE-4611: stack has commented on the revision [jira] [HBASE-4611] Add support for Phabricator/Differential as an alternative code review tool. I thing this change is really awesome REVISION DETAIL https://reviews.facebook.net/D21 Add support for Phabricator/Differential as an alternative code review tool --- Key: HBASE-4611 URL: https://issues.apache.org/jira/browse/HBASE-4611 Project: HBase Issue Type: Task Reporter: Jonathan Gray Attachments: D21.1.patch, D21.1.patch From http://phabricator.org/ : Phabricator is a open source collection of web applications which make it easier to write, review, and share source code. It is currently available as an early release. Phabricator was developed at Facebook. It's open source so pretty much anyone could host an instance of this software. To begin with, there will be a public-facing instance located at http://reviews.facebook.net (sponsored by Facebook and hosted by the OSUOSL http://osuosl.org). We will use this JIRA to deal with adding (and ensuring) Apache-friendly support that will allow us to do code reviews with Phabricator for HBase. -- 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-4687) regionserver may miss zk-heartbeats to master when replaying edits at region open
[ https://issues.apache.org/jira/browse/HBASE-4687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137425#comment-13137425 ] jirapos...@reviews.apache.org commented on HBASE-4687: -- --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/2585/ --- Review request for hbase, Dhruba Borthakur, Jonathan Gray, and Nicolas Spiegelberg. Summary --- must report.progress() at least once per edits file when replaying edits This addresses bug HBASE-4687. https://issues.apache.org/jira/browse/HBASE-4687 Diffs - src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java 5243b58 Diff: https://reviews.apache.org/r/2585/diff Testing --- small change and not tested. Thanks, Prakash regionserver may miss zk-heartbeats to master when replaying edits at region open - Key: HBASE-4687 URL: https://issues.apache.org/jira/browse/HBASE-4687 Project: HBase Issue Type: Bug Reporter: Prakash Khemani Assignee: Prakash Khemani replayRecoveredEdits() should do another reporter.progress() before returning. -- 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-4679) Thrift null mutation error
[ https://issues.apache.org/jira/browse/HBASE-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137439#comment-13137439 ] Nicolas Spiegelberg commented on HBASE-4679: internally reviewed by: karthik.ranga dhruba. Will commit at the end of today unless people have questions. Thrift null mutation error -- Key: HBASE-4679 URL: https://issues.apache.org/jira/browse/HBASE-4679 Project: HBase Issue Type: Bug Affects Versions: 0.92.0, 0.94.0 Reporter: Nicolas Spiegelberg Assignee: Nicolas Spiegelberg Attachments: HBASE-4679.patch When using null as a value for a mutation, HBasse thrift client failed and threw an error. We should instad check for a null byte buffer. -- 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-4687) regionserver may miss zk-heartbeats to master when replaying edits at region open
[ https://issues.apache.org/jira/browse/HBASE-4687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137443#comment-13137443 ] jirapos...@reviews.apache.org commented on HBASE-4687: -- --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/2585/#review2889 --- Looks good to me. Could you explain what the ramifications of not doing this are? I.e. what does the progress reporter have to do with ZK heartbeats? Thanks! - Lars On 2011-10-27 19:32:54, Prakash Khemani wrote: bq. bq. --- bq. This is an automatically generated e-mail. To reply, visit: bq. https://reviews.apache.org/r/2585/ bq. --- bq. bq. (Updated 2011-10-27 19:32:54) bq. bq. bq. Review request for hbase, Dhruba Borthakur, Jonathan Gray, and Nicolas Spiegelberg. bq. bq. bq. Summary bq. --- bq. bq. must report.progress() at least once per edits file when replaying edits bq. bq. bq. This addresses bug HBASE-4687. bq. https://issues.apache.org/jira/browse/HBASE-4687 bq. bq. bq. Diffs bq. - bq. bq.src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java 5243b58 bq. bq. Diff: https://reviews.apache.org/r/2585/diff bq. bq. bq. Testing bq. --- bq. bq. small change and not tested. bq. bq. bq. Thanks, bq. bq. Prakash bq. bq. regionserver may miss zk-heartbeats to master when replaying edits at region open - Key: HBASE-4687 URL: https://issues.apache.org/jira/browse/HBASE-4687 Project: HBase Issue Type: Bug Reporter: Prakash Khemani Assignee: Prakash Khemani replayRecoveredEdits() should do another reporter.progress() before returning. -- 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-4689) [89-fb] Fix table level rpc* metrics
[89-fb] Fix table level rpc* metrics Key: HBASE-4689 URL: https://issues.apache.org/jira/browse/HBASE-4689 Project: HBase Issue Type: Sub-task Affects Versions: 0.89.20100924 Reporter: Liyin Tang Assignee: Liyin Tang In r1182034, the per table/cf for rpc* metrics has a bug. It will only show cf level metrics even though we enabled the per table level metrics. Fix this bug here. -- 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-4304) requestsPerSecond counter stuck at 0
[ https://issues.apache.org/jira/browse/HBASE-4304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137447#comment-13137447 ] Li Pi commented on HBASE-4304: -- My testing shows org.apache.hadoop.hbase.master.TestDistributedLogSplitting org.apache.hadoop.hbase.master.TestMasterFailover fails anyways. requestsPerSecond counter stuck at 0 Key: HBASE-4304 URL: https://issues.apache.org/jira/browse/HBASE-4304 Project: HBase Issue Type: Bug Components: master, regionserver Affects Versions: 0.92.0 Reporter: Todd Lipcon Assignee: Li Pi Priority: Critical Fix For: 0.92.0 Attachments: 4304v1.txt, 4304v2.txt, 4304v3.txt Running trunk @ r1163343, all of the requestsPerSecond counters are showing 0 both in the master UI and in the RS UI. The writeRequestsCount metric is properly updating in the RS UI. -- 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-4304) requestsPerSecond counter stuck at 0
[
https://issues.apache.org/jira/browse/HBASE-4304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137461#comment-13137461
]
stack commented on HBASE-4304:
--
{code}
long now = System.currentTimeMillis();
long diff = (now-ts)/1000;
-if (diff == 0) diff = 1; // sigh this is crap.
+if (diff 0.5){
{code}
diff is a long. It can't be 0.5. You want to use a float or something?
Should the below instead be an accessor on RSM rather than expose the data
member?
{code}
- private final MetricsRate requests = new MetricsRate(requests, registry);
+ public final MetricsRate requests = new MetricsRate(requests, registry);
{code}
Good stuff Li. Agree on failing tests.
requestsPerSecond counter stuck at 0
Key: HBASE-4304
URL: https://issues.apache.org/jira/browse/HBASE-4304
Project: HBase
Issue Type: Bug
Components: master, regionserver
Affects Versions: 0.92.0
Reporter: Todd Lipcon
Assignee: Li Pi
Priority: Critical
Fix For: 0.92.0
Attachments: 4304v1.txt, 4304v2.txt, 4304v3.txt
Running trunk @ r1163343, all of the requestsPerSecond counters are showing 0
both in the master UI and in the RS UI. The writeRequestsCount metric is
properly updating in the RS UI.
--
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] [Work started] (HBASE-4689) [89-fb] Fix table level rpc* metrics
[ https://issues.apache.org/jira/browse/HBASE-4689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HBASE-4689 started by Liyin Tang. [89-fb] Fix table level rpc* metrics Key: HBASE-4689 URL: https://issues.apache.org/jira/browse/HBASE-4689 Project: HBase Issue Type: Sub-task Affects Versions: 0.89.20100924 Reporter: Liyin Tang Assignee: Liyin Tang Attachments: hbase-4689.patch In r1182034, the per table/cf for rpc* metrics has a bug. It will only show cf level metrics even though we enabled the per table level metrics. Fix this bug here. -- 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-4689) [89-fb] Make the table level metrics work with rpc* metrics
[ https://issues.apache.org/jira/browse/HBASE-4689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Liyin Tang updated HBASE-4689: -- Attachment: (was: hbase-4689.patch) [89-fb] Make the table level metrics work with rpc* metrics --- Key: HBASE-4689 URL: https://issues.apache.org/jira/browse/HBASE-4689 Project: HBase Issue Type: Sub-task Affects Versions: 0.89.20100924 Reporter: Liyin Tang Assignee: Liyin Tang In r1182034, the per table/cf for rpc* metrics has a bug. It will only show cf level metrics even though we enabled the per table level metrics. Fix this bug here. -- 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-4689) [89-fb] Make the table level metrics work with rpc* metrics
[ https://issues.apache.org/jira/browse/HBASE-4689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137478#comment-13137478 ] jirapos...@reviews.apache.org commented on HBASE-4689: -- --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/2587/ --- Review request for hbase, Mikhail Bautin, Pritam Damania, Prakash Khemani, Amitanand Aiyer, Kannan Muthukkaruppan, Jerry Chen, Karthik Ranganathan, and Nicolas Spiegelberg. Summary --- In r1182034, the per table/cf for rpc* metrics has a bug. It will only show cf level metrics even though we enabled the per table level metrics. Fix this bug here. This addresses bug HBASE-4689. https://issues.apache.org/jira/browse/HBASE-4689 Diffs - src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java 6c821c0 src/main/java/org/apache/hadoop/hbase/regionserver/metrics/SchemaMetrics.java 8776ffe src/test/java/org/apache/hadoop/hbase/regionserver/metrics/TestSchemaMetrics.java c03532a Diff: https://reviews.apache.org/r/2587/diff Testing --- passed all the unit tests and the metrics in the dev cluster Thanks, Liyin [89-fb] Make the table level metrics work with rpc* metrics --- Key: HBASE-4689 URL: https://issues.apache.org/jira/browse/HBASE-4689 Project: HBase Issue Type: Sub-task Affects Versions: 0.89.20100924 Reporter: Liyin Tang Assignee: Liyin Tang In r1182034, the per table/cf for rpc* metrics has a bug. It will only show cf level metrics even though we enabled the per table level metrics. Fix this bug here. -- 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-4660) Place to publish RegionServer information such as webuiport and coprocessors loaded
[ https://issues.apache.org/jira/browse/HBASE-4660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-4660: - Attachment: Screen shot 2011-10-27 at 1.40.40 PM.png This is what hbase-4070 does... its kinda wonky having list of regionserver coprocessors showing in the UI load. Place to publish RegionServer information such as webuiport and coprocessors loaded --- Key: HBASE-4660 URL: https://issues.apache.org/jira/browse/HBASE-4660 Project: HBase Issue Type: Bug Reporter: stack Attachments: Screen shot 2011-10-27 at 1.40.40 PM.png HBASE-4070 added loaded CoProcessors to HServerLoad which seems like wrong place to carry this info. We need a locus for static info of this type such as loaded CoProcessors and webuiport as well as stuff like how many cpus, RAM, etc: e.g. in regionserver znode or available on invocation of an HRegionServer method (master can ask HRegionServer when it needs 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-4686) [89-fb] Fix per-store metrics aggregation
[ https://issues.apache.org/jira/browse/HBASE-4686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Bautin updated HBASE-4686: -- Attachment: HBASE-4686-TestRegionServerMetics-and-Store-metric-a-20111027134023-cc718144.patch [89-fb] Fix per-store metrics aggregation -- Key: HBASE-4686 URL: https://issues.apache.org/jira/browse/HBASE-4686 Project: HBase Issue Type: Bug Reporter: Mikhail Bautin Assignee: Mikhail Bautin Attachments: HBASE-4686-TestRegionServerMetics-and-Store-metric-a-20111027134023-cc718144.patch In r1182034 per-Store metrics were broken, because the aggregation of StoreFile metrics over all stores in a region was replaced by overriding them every time. We saw these metrics drop by a factor of numRegions on a production cluster -- thanks to Kannan for noticing this! We need to fix the metrics and add a unit test to ensure regressions like this don't happen in the future. -- 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-4686) [89-fb] Fix per-store metrics aggregation
[ https://issues.apache.org/jira/browse/HBASE-4686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137517#comment-13137517 ] jirapos...@reviews.apache.org commented on HBASE-4686: -- --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/2590/ --- Review request for hbase and Liyin Tang. Summary --- In r1182034 per-Store metrics were broken, because the aggregation of StoreFile metrics over all stores in a region was replaced by overriding them every time. We saw these metrics drop by a factor of numRegions on a production cluster – thanks to Kannan for noticing this! We need to fix the metrics and add a unit test to ensure regressions like this don't happen in the future. This addresses bug HBASE-4686. https://issues.apache.org/jira/browse/HBASE-4686 Diffs - src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java 6c821c0 src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java 4a4436f src/main/java/org/apache/hadoop/hbase/regionserver/metrics/SchemaMetrics.java 8776ffe src/test/java/org/apache/hadoop/hbase/HBaseTestingUtility.java 7fd8977 src/test/java/org/apache/hadoop/hbase/regionserver/TestRegionServerMetrics.java PRE-CREATION src/test/java/org/apache/hadoop/hbase/regionserver/metrics/TestSchemaMetrics.java c03532a Diff: https://reviews.apache.org/r/2590/diff Testing --- Still running unit tests. Thanks, Mikhail [89-fb] Fix per-store metrics aggregation -- Key: HBASE-4686 URL: https://issues.apache.org/jira/browse/HBASE-4686 Project: HBase Issue Type: Bug Reporter: Mikhail Bautin Assignee: Mikhail Bautin Attachments: HBASE-4686-TestRegionServerMetics-and-Store-metric-a-20111027134023-cc718144.patch In r1182034 per-Store metrics were broken, because the aggregation of StoreFile metrics over all stores in a region was replaced by overriding them every time. We saw these metrics drop by a factor of numRegions on a production cluster -- thanks to Kannan for noticing this! We need to fix the metrics and add a unit test to ensure regressions like this don't happen in the future. -- 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-4689) [89-fb] Make the table level metrics work with rpc* metrics
[ https://issues.apache.org/jira/browse/HBASE-4689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137556#comment-13137556 ] jirapos...@reviews.apache.org commented on HBASE-4689: -- --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/2587/#review2893 --- there's a decent bit of refactoring here. what are the critical parts to look at? src/main/java/org/apache/hadoop/hbase/regionserver/metrics/SchemaMetrics.java https://reviews.apache.org/r/2587/#comment6472 Is printing multi-CF metrics scalable? With F families, isn't the space complexity O(2^F)? src/test/java/org/apache/hadoop/hbase/regionserver/metrics/TestSchemaMetrics.java https://reviews.apache.org/r/2587/#comment6471 as an aside: have we currently started using table-level metrics in our dashboards yet? the common abbreviation for table is tbl instead of tab (normally, cut out the vowels). would be nice to change if we're not dependent on this format yet. - Nicolas On 2011-10-27 20:23:31, Liyin Tang wrote: bq. bq. --- bq. This is an automatically generated e-mail. To reply, visit: bq. https://reviews.apache.org/r/2587/ bq. --- bq. bq. (Updated 2011-10-27 20:23:31) bq. bq. bq. Review request for hbase, Mikhail Bautin, Pritam Damania, Prakash Khemani, Amitanand Aiyer, Kannan Muthukkaruppan, Jerry Chen, Karthik Ranganathan, and Nicolas Spiegelberg. bq. bq. bq. Summary bq. --- bq. bq. In r1182034, the per table/cf for rpc* metrics has a bug. It will only show cf level metrics even though we enabled the per table level metrics. bq. Fix this bug here. bq. bq. bq. This addresses bug HBASE-4689. bq. https://issues.apache.org/jira/browse/HBASE-4689 bq. bq. bq. Diffs bq. - bq. bq.src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java 6c821c0 bq. src/main/java/org/apache/hadoop/hbase/regionserver/metrics/SchemaMetrics.java 8776ffe bq. src/test/java/org/apache/hadoop/hbase/regionserver/metrics/TestSchemaMetrics.java c03532a bq. bq. Diff: https://reviews.apache.org/r/2587/diff bq. bq. bq. Testing bq. --- bq. bq. Passed all the unit tests and tested the rpc metrics in the dev cluster bq. bq. bq. Thanks, bq. bq. Liyin bq. bq. [89-fb] Make the table level metrics work with rpc* metrics --- Key: HBASE-4689 URL: https://issues.apache.org/jira/browse/HBASE-4689 Project: HBase Issue Type: Sub-task Affects Versions: 0.89.20100924 Reporter: Liyin Tang Assignee: Liyin Tang Attachments: hbase-4689.patch In r1182034, the per table/cf for rpc* metrics has a bug. It will only show cf level metrics even though we enabled the per table level metrics. Fix this bug here. -- 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-4688) Make it so can run PE w/o having to put hbase jar on CLASSPATH
[
https://issues.apache.org/jira/browse/HBASE-4688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137559#comment-13137559
]
Hudson commented on HBASE-4688:
---
Integrated in HBase-TRUNK #2374 (See
[https://builds.apache.org/job/HBase-TRUNK/2374/])
HBASE-4688 Make it so can run PE w/o having to put hbase jar on CLASSPATH
stack :
Files :
* /hbase/trunk/src/test/java/org/apache/hadoop/hbase/PerformanceEvaluation.java
Make it so can run PE w/o having to put hbase jar on CLASSPATH
--
Key: HBASE-4688
URL: https://issues.apache.org/jira/browse/HBASE-4688
Project: HBase
Issue Type: Bug
Reporter: stack
Attachments: pe.txt
I need this:
{code}
diff --git a/src/test/java/org/apache/hadoop/hbase/PerformanceEvaluation.java
b/src/test/java/org/apache/hadoop/hbase/PerformanceEvaluation.java
index 3982eff..ef47d0d 100644
--- a/src/test/java/org/apache/hadoop/hbase/PerformanceEvaluation.java
+++ b/src/test/java/org/apache/hadoop/hbase/PerformanceEvaluation.java
@@ -570,6 +570,9 @@ public class PerformanceEvaluation {
TextOutputFormat.setOutputPath(job, new Path(inputDir,outputs));
TableMapReduceUtil.addDependencyJars(job);
+// Add a Class from the hbase.jar so it gets registered too.
+TableMapReduceUtil.addDependencyJars(job.getConfiguration(),
+ org.apache.hadoop.hbase.util.Bytes.class);
job.waitForCompletion(true);
}
{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-4528) The put operation can release the rowlock before sync-ing the Hlog
[
https://issues.apache.org/jira/browse/HBASE-4528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137565#comment-13137565
]
Ted Yu commented on HBASE-4528:
---
I found no log statements in any of the rollback methods.
I think at least we should add one LOG statement at the beginning of
rollbackMemstore(), such as:
{code}
LOG.debug(rollbackMemstore start: + start + end: + end);
{code}
The put operation can release the rowlock before sync-ing the Hlog
--
Key: HBASE-4528
URL: https://issues.apache.org/jira/browse/HBASE-4528
Project: HBase
Issue Type: Improvement
Components: regionserver
Reporter: dhruba borthakur
Assignee: dhruba borthakur
Fix For: 0.94.0
Attachments: HBASE-4528-Trunk-FINAL.patch, appendNoSync5.txt,
appendNoSyncPut1.txt, appendNoSyncPut2.txt, appendNoSyncPut3.txt,
appendNoSyncPut4.txt, appendNoSyncPut5.txt, appendNoSyncPut6.txt,
appendNoSyncPut7.txt, appendNoSyncPut8.txt
This allows for better throughput when there are hot rows. A single row
update improves from 100 puts/sec/server to 5000 puts/sec/server.
--
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-4528) The put operation can release the rowlock before sync-ing the Hlog
[ https://issues.apache.org/jira/browse/HBASE-4528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137570#comment-13137570 ] Jonathan Gray commented on HBASE-4528: -- +1 on adding the log line Ted. Will do. I will try to spend time looking at the unit test tonight. The put operation can release the rowlock before sync-ing the Hlog -- Key: HBASE-4528 URL: https://issues.apache.org/jira/browse/HBASE-4528 Project: HBase Issue Type: Improvement Components: regionserver Reporter: dhruba borthakur Assignee: dhruba borthakur Fix For: 0.94.0 Attachments: HBASE-4528-Trunk-FINAL.patch, appendNoSync5.txt, appendNoSyncPut1.txt, appendNoSyncPut2.txt, appendNoSyncPut3.txt, appendNoSyncPut4.txt, appendNoSyncPut5.txt, appendNoSyncPut6.txt, appendNoSyncPut7.txt, appendNoSyncPut8.txt This allows for better throughput when there are hot rows. A single row update improves from 100 puts/sec/server to 5000 puts/sec/server. -- 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-4685) TestDistributedLogSplitting.testOrphanLogCreation failing because of ArithmeticException: / by zero.
[ https://issues.apache.org/jira/browse/HBASE-4685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137583#comment-13137583 ] stack commented on HBASE-4685: -- The TDLS tests are failing because of 'too many open files'. These machines need the fds upped. Asking Giri who owns 'hadoop1', et al. Going to apply this patch. TestDistributedLogSplitting.testOrphanLogCreation failing because of ArithmeticException: / by zero. Key: HBASE-4685 URL: https://issues.apache.org/jira/browse/HBASE-4685 Project: HBase Issue Type: Bug Reporter: stack Attachments: 4685.txt -- 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-4685) TestDistributedLogSplitting.testOrphanLogCreation failing because of ArithmeticException: / by zero.
[ https://issues.apache.org/jira/browse/HBASE-4685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-4685: - Resolution: Fixed Fix Version/s: 0.92.0 Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Committed to TRUNK and 0.92 branch. TestDistributedLogSplitting.testOrphanLogCreation failing because of ArithmeticException: / by zero. Key: HBASE-4685 URL: https://issues.apache.org/jira/browse/HBASE-4685 Project: HBase Issue Type: Bug Reporter: stack Fix For: 0.92.0 Attachments: 4685.txt -- 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-4684) REST server is leaking ZK connections in 0.90
[ https://issues.apache.org/jira/browse/HBASE-4684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137597#comment-13137597 ] Andrew Purtell commented on HBASE-4684: --- Aha! I was looking in the wrong place. REST server is leaking ZK connections in 0.90 - Key: HBASE-4684 URL: https://issues.apache.org/jira/browse/HBASE-4684 Project: HBase Issue Type: Bug Affects Versions: 0.90.4 Reporter: Jean-Daniel Cryans Priority: Critical Fix For: 0.90.5 As reported a month ago, http://search-hadoop.com/m/FD6gmKzrxY1, the REST server is leak ZK connections. Upon investigation I see that TableResource.scanTransformAttrs creates a new HBA per minute per table (when the server is getting requests) but never deletes the connection created in there. There are a bunch of other places where HBAs are created but not cleaned after like SchemaResource, StorageClusterStatusResource, StorageClusterVersionResource, ExistsResource, etc. Those places shouldn't be as leaky under normal circumstances tho. Thanks to Jack Levin for bringing up this issue again when he tried to upgrade. -- 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-4684) REST server is leaking ZK connections in 0.90
[ https://issues.apache.org/jira/browse/HBASE-4684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137598#comment-13137598 ] Andrew Purtell commented on HBASE-4684: --- Yes, that's not good, going to rework this now. REST server is leaking ZK connections in 0.90 - Key: HBASE-4684 URL: https://issues.apache.org/jira/browse/HBASE-4684 Project: HBase Issue Type: Bug Affects Versions: 0.90.4 Reporter: Jean-Daniel Cryans Priority: Critical Fix For: 0.90.5 As reported a month ago, http://search-hadoop.com/m/FD6gmKzrxY1, the REST server is leak ZK connections. Upon investigation I see that TableResource.scanTransformAttrs creates a new HBA per minute per table (when the server is getting requests) but never deletes the connection created in there. There are a bunch of other places where HBAs are created but not cleaned after like SchemaResource, StorageClusterStatusResource, StorageClusterVersionResource, ExistsResource, etc. Those places shouldn't be as leaky under normal circumstances tho. Thanks to Jack Levin for bringing up this issue again when he tried to upgrade. -- 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-4660) Place to publish RegionServer information such as webuiport and coprocessors loaded
[ https://issues.apache.org/jira/browse/HBASE-4660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137606#comment-13137606 ] Eugene Koontz commented on HBASE-4660: -- I agree; but I also think it would be nice to separate all the comma-delimited values into separate tds. Place to publish RegionServer information such as webuiport and coprocessors loaded --- Key: HBASE-4660 URL: https://issues.apache.org/jira/browse/HBASE-4660 Project: HBase Issue Type: Bug Reporter: stack Attachments: Screen shot 2011-10-27 at 1.40.40 PM.png HBASE-4070 added loaded CoProcessors to HServerLoad which seems like wrong place to carry this info. We need a locus for static info of this type such as loaded CoProcessors and webuiport as well as stuff like how many cpus, RAM, etc: e.g. in regionserver znode or available on invocation of an HRegionServer method (master can ask HRegionServer when it needs 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-4660) Place to publish RegionServer information such as webuiport and coprocessors loaded
[ https://issues.apache.org/jira/browse/HBASE-4660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137614#comment-13137614 ] stack commented on HBASE-4660: -- Loaded CPs shouldn't be showing at all in load is my point. Place to publish RegionServer information such as webuiport and coprocessors loaded --- Key: HBASE-4660 URL: https://issues.apache.org/jira/browse/HBASE-4660 Project: HBase Issue Type: Bug Reporter: stack Attachments: Screen shot 2011-10-27 at 1.40.40 PM.png HBASE-4070 added loaded CoProcessors to HServerLoad which seems like wrong place to carry this info. We need a locus for static info of this type such as loaded CoProcessors and webuiport as well as stuff like how many cpus, RAM, etc: e.g. in regionserver znode or available on invocation of an HRegionServer method (master can ask HRegionServer when it needs 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-4528) The put operation can release the rowlock before sync-ing the Hlog
[
https://issues.apache.org/jira/browse/HBASE-4528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137613#comment-13137613
]
Ted Yu commented on HBASE-4528:
---
Found the following in output file for a failed test:
{code}
2011-10-27 14:25:15,878 DEBUG
[10.246.204.28,52533,1319750687794.splitLogManagerTimeoutMonitor]
master.SplitLogManager$TimeoutMonitor(829): total tasks = 1 unassigned = 1
2011-10-27 14:25:16,126 INFO
[SplitLogWorker-10.246.204.28,52535,1319750687853]
regionserver.SplitLogWorker(308): worker 10.246.204.28,52535,1319750687853 done
with task
/hbase/splitlog/hdfs%3A%2F%2Flocalhost%3A52522%2Fuser%2Fzhihyu%2F.logs%2F10.246.204.28%2C52535%2C1319750687853%2F10.246.204.28%252C52535%252C1319750687853.1319750690240
in 5049ms
2011-10-27 14:25:16,126 ERROR
[SplitLogWorker-10.246.204.28,52535,1319750687853]
regionserver.SplitLogWorker(169): unexpected error
java.lang.NullPointerException
at
org.apache.hadoop.hdfs.DFSClient$DFSOutputStream.closeThreads(DFSClient.java:3648)
at
org.apache.hadoop.hdfs.DFSClient$DFSOutputStream.closeInternal(DFSClient.java:3691)
at org.apache.hadoop.hdfs.DFSClient$DFSOutputStream.close(DFSClient.java:3626)
at
org.apache.hadoop.fs.FSDataOutputStream$PositionCache.close(FSDataOutputStream.java:61)
at org.apache.hadoop.fs.FSDataOutputStream.close(FSDataOutputStream.java:86)
at org.apache.hadoop.io.SequenceFile$Writer.close(SequenceFile.java:966)
at
org.apache.hadoop.hbase.regionserver.wal.SequenceFileLogWriter.close(SequenceFileLogWriter.java:177)
at
org.apache.hadoop.hbase.regionserver.wal.HLogSplitter.splitLogFileToTemp(HLogSplitter.java:458)
at
org.apache.hadoop.hbase.regionserver.wal.HLogSplitter.splitLogFileToTemp(HLogSplitter.java:352)
at
org.apache.hadoop.hbase.regionserver.SplitLogWorker$1.exec(SplitLogWorker.java:113)
at
org.apache.hadoop.hbase.regionserver.SplitLogWorker.grabTask(SplitLogWorker.java:266)
at
org.apache.hadoop.hbase.regionserver.SplitLogWorker.taskLoop(SplitLogWorker.java:197)
at
org.apache.hadoop.hbase.regionserver.SplitLogWorker.run(SplitLogWorker.java:165)
at java.lang.Thread.run(Thread.java:680)
2011-10-27 14:25:16,126 INFO
[SplitLogWorker-10.246.204.28,52535,1319750687853]
regionserver.SplitLogWorker(171): SplitLogWorker
10.246.204.28,52535,1319750687853 exiting
2011-10-27 14:25:16,878 DEBUG
[10.246.204.28,52533,1319750687794.splitLogManagerTimeoutMonitor]
master.SplitLogManager$TimeoutMonitor(829): total tasks = 1 unassigned = 1
{code}
I don't think NPE out of DFSClient.java for closing is critical.
The following patch allowed me to loop through TestDistributedLogSplitting on
MacBook 9 times without hitting test failure.
{code}
Index: src/main/java/org/apache/hadoop/hbase/regionserver/wal/HLogSplitter.java
===
--- src/main/java/org/apache/hadoop/hbase/regionserver/wal/HLogSplitter.java
(revision 1190003)
+++ src/main/java/org/apache/hadoop/hbase/regionserver/wal/HLogSplitter.java
(working copy)
@@ -455,7 +455,11 @@
}
n++;
WriterAndPath wap = (WriterAndPath)o;
-wap.w.close();
+try {
+ wap.w.close();
+} catch (Exception e) {
+ LOG.debug(splitLogFileToTemp closing SequenceFileLogWriter, e);
+}
LOG.debug(Closed + wap.p);
}
String msg = (processed + editsCount + edits across + n +
regions +
{code}
The put operation can release the rowlock before sync-ing the Hlog
--
Key: HBASE-4528
URL: https://issues.apache.org/jira/browse/HBASE-4528
Project: HBase
Issue Type: Improvement
Components: regionserver
Reporter: dhruba borthakur
Assignee: dhruba borthakur
Fix For: 0.94.0
Attachments: HBASE-4528-Trunk-FINAL.patch, appendNoSync5.txt,
appendNoSyncPut1.txt, appendNoSyncPut2.txt, appendNoSyncPut3.txt,
appendNoSyncPut4.txt, appendNoSyncPut5.txt, appendNoSyncPut6.txt,
appendNoSyncPut7.txt, appendNoSyncPut8.txt
This allows for better throughput when there are hot rows. A single row
update improves from 100 puts/sec/server to 5000 puts/sec/server.
--
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-4641) Block cache can be mistakenly instantiated on Master
[ https://issues.apache.org/jira/browse/HBASE-4641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137622#comment-13137622 ] Ted Yu commented on HBASE-4641: --- I haven't found other code path leading to block cache creation on master. Block cache can be mistakenly instantiated on Master Key: HBASE-4641 URL: https://issues.apache.org/jira/browse/HBASE-4641 Project: HBase Issue Type: Bug Components: master Affects Versions: 0.92.0, 0.94.0 Reporter: Jonathan Gray Assignee: Jonathan Gray Priority: Critical Fix For: 0.92.0 Attachments: HBASE-4641-v1.patch, HBASE-4641-v2.patch After changes in the block cache instantiation over in HBASE-4422, it looks like the HMaster can now end up with a block cache instantiated. Not a huge deal but prevents the process from shutting down properly. -- 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-4660) Place to publish RegionServer information such as webuiport and coprocessors loaded
[ https://issues.apache.org/jira/browse/HBASE-4660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137631#comment-13137631 ] Eugene Koontz commented on HBASE-4660: -- I agree; I went off on a tangent about the HTML presentation which is a separate display issue. Place to publish RegionServer information such as webuiport and coprocessors loaded --- Key: HBASE-4660 URL: https://issues.apache.org/jira/browse/HBASE-4660 Project: HBase Issue Type: Bug Reporter: stack Attachments: Screen shot 2011-10-27 at 1.40.40 PM.png HBASE-4070 added loaded CoProcessors to HServerLoad which seems like wrong place to carry this info. We need a locus for static info of this type such as loaded CoProcessors and webuiport as well as stuff like how many cpus, RAM, etc: e.g. in regionserver znode or available on invocation of an HRegionServer method (master can ask HRegionServer when it needs 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-4300) Start of new-version master fails if old master's znode is hanging around
[ https://issues.apache.org/jira/browse/HBASE-4300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-4300: - Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Committed to branch and trunk. Start of new-version master fails if old master's znode is hanging around - Key: HBASE-4300 URL: https://issues.apache.org/jira/browse/HBASE-4300 Project: HBase Issue Type: Bug Affects Versions: 0.92.0 Reporter: Todd Lipcon Assignee: stack Priority: Critical Fix For: 0.92.0 Attachments: 4300-v2.txt, 4300-v3.txt, 4300.txt I shut down an 0.90 cluster, and had to do so uncleanly. I then started a trunk (0.92) cluster before the old master znode had expired. This cased: java.lang.StringIndexOutOfBoundsException: String index out of range: -1 at java.lang.String.substring(String.java:1937) at org.apache.hadoop.hbase.ServerName.parseHostname(ServerName.java:81) at org.apache.hadoop.hbase.ServerName.init(ServerName.java:63) at org.apache.hadoop.hbase.master.ActiveMasterManager.blockUntilBecomingActiveMaster(ActiveMasterManager.java:148) at org.apache.hadoop.hbase.master.HMaster.becomeActiveMaster(HMaster.java:342) at org.apache.hadoop.hbase.master.HMaster.run(HMaster.java:297) -- 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-4686) [89-fb] Fix per-store metrics aggregation
[ https://issues.apache.org/jira/browse/HBASE-4686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137643#comment-13137643 ] Mikhail Bautin commented on HBASE-4686: --- I put another version of the patch on Differential: https://reviews.facebook.net/D87 [89-fb] Fix per-store metrics aggregation -- Key: HBASE-4686 URL: https://issues.apache.org/jira/browse/HBASE-4686 Project: HBase Issue Type: Bug Reporter: Mikhail Bautin Assignee: Mikhail Bautin Attachments: HBASE-4686-TestRegionServerMetics-and-Store-metric-a-20111027134023-cc718144.patch, HBASE-4686-jira-89-fb-Fix-per-store-metrics-aggregat-20111027152723-05bea421.patch In r1182034 per-Store metrics were broken, because the aggregation of StoreFile metrics over all stores in a region was replaced by overriding them every time. We saw these metrics drop by a factor of numRegions on a production cluster -- thanks to Kannan for noticing this! We need to fix the metrics and add a unit test to ensure regressions like this don't happen in the future. -- 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-4686) [89-fb] Fix per-store metrics aggregation
[ https://issues.apache.org/jira/browse/HBASE-4686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Bautin updated HBASE-4686: -- Attachment: HBASE-4686-jira-89-fb-Fix-per-store-metrics-aggregat-20111027152723-05bea421.patch Second version of the patch. [89-fb] Fix per-store metrics aggregation -- Key: HBASE-4686 URL: https://issues.apache.org/jira/browse/HBASE-4686 Project: HBase Issue Type: Bug Reporter: Mikhail Bautin Assignee: Mikhail Bautin Attachments: HBASE-4686-TestRegionServerMetics-and-Store-metric-a-20111027134023-cc718144.patch, HBASE-4686-jira-89-fb-Fix-per-store-metrics-aggregat-20111027152723-05bea421.patch In r1182034 per-Store metrics were broken, because the aggregation of StoreFile metrics over all stores in a region was replaced by overriding them every time. We saw these metrics drop by a factor of numRegions on a production cluster -- thanks to Kannan for noticing this! We need to fix the metrics and add a unit test to ensure regressions like this don't happen in the future. -- 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-4686) [89-fb] Fix per-store metrics aggregation
[ https://issues.apache.org/jira/browse/HBASE-4686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137649#comment-13137649 ] Mikhail Bautin commented on HBASE-4686: --- Sorry for confusing file names. The most recent patch is: https://issues.apache.org/jira/secure/attachment/12501169/HBASE-4686-jira-89-fb-Fix-per-store-metrics-aggregat-20111027152723-05bea421.patch [89-fb] Fix per-store metrics aggregation -- Key: HBASE-4686 URL: https://issues.apache.org/jira/browse/HBASE-4686 Project: HBase Issue Type: Bug Reporter: Mikhail Bautin Assignee: Mikhail Bautin Attachments: HBASE-4686-TestRegionServerMetics-and-Store-metric-a-20111027134023-cc718144.patch, HBASE-4686-jira-89-fb-Fix-per-store-metrics-aggregat-20111027152723-05bea421.patch In r1182034 per-Store metrics were broken, because the aggregation of StoreFile metrics over all stores in a region was replaced by overriding them every time. We saw these metrics drop by a factor of numRegions on a production cluster -- thanks to Kannan for noticing this! We need to fix the metrics and add a unit test to ensure regressions like this don't happen in the future. -- 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-4528) The put operation can release the rowlock before sync-ing the Hlog
[ https://issues.apache.org/jira/browse/HBASE-4528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-4528: -- Status: Patch Available (was: Open) Run test suite on PreCommit. The put operation can release the rowlock before sync-ing the Hlog -- Key: HBASE-4528 URL: https://issues.apache.org/jira/browse/HBASE-4528 Project: HBase Issue Type: Improvement Components: regionserver Reporter: dhruba borthakur Assignee: dhruba borthakur Fix For: 0.94.0 Attachments: 4528-trunk.txt, HBASE-4528-Trunk-FINAL.patch, appendNoSync5.txt, appendNoSyncPut1.txt, appendNoSyncPut2.txt, appendNoSyncPut3.txt, appendNoSyncPut4.txt, appendNoSyncPut5.txt, appendNoSyncPut6.txt, appendNoSyncPut7.txt, appendNoSyncPut8.txt This allows for better throughput when there are hot rows. A single row update improves from 100 puts/sec/server to 5000 puts/sec/server. -- 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-4528) The put operation can release the rowlock before sync-ing the Hlog
[ https://issues.apache.org/jira/browse/HBASE-4528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-4528: -- Attachment: 4528-trunk.txt Patch incorporating suggested fix for HLogSplitter.java The put operation can release the rowlock before sync-ing the Hlog -- Key: HBASE-4528 URL: https://issues.apache.org/jira/browse/HBASE-4528 Project: HBase Issue Type: Improvement Components: regionserver Reporter: dhruba borthakur Assignee: dhruba borthakur Fix For: 0.94.0 Attachments: 4528-trunk.txt, HBASE-4528-Trunk-FINAL.patch, appendNoSync5.txt, appendNoSyncPut1.txt, appendNoSyncPut2.txt, appendNoSyncPut3.txt, appendNoSyncPut4.txt, appendNoSyncPut5.txt, appendNoSyncPut6.txt, appendNoSyncPut7.txt, appendNoSyncPut8.txt This allows for better throughput when there are hot rows. A single row update improves from 100 puts/sec/server to 5000 puts/sec/server. -- 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-4683) Create config option to only cache index blocks
[ https://issues.apache.org/jira/browse/HBASE-4683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-4683: - Attachment: 4683.txt Here's the simple patch. This has only a global setting. Might make sense to have this per CF, or maybe per CF and a global default setting. Create config option to only cache index blocks --- Key: HBASE-4683 URL: https://issues.apache.org/jira/browse/HBASE-4683 Project: HBase Issue Type: New Feature Reporter: Lars Hofhansl Priority: Minor Fix For: 0.94.0 Attachments: 4683.txt 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. -- 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) Create config option to only cache index blocks
[ https://issues.apache.org/jira/browse/HBASE-4683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137705#comment-13137705 ] Lars Hofhansl commented on HBASE-4683: -- As for treating index blocks with MEMORY priority (not part of the patch), should we just always do that, or should that be configurable as well? Create config option to only cache index blocks --- Key: HBASE-4683 URL: https://issues.apache.org/jira/browse/HBASE-4683 Project: HBase Issue Type: New Feature Reporter: Lars Hofhansl Priority: Minor Fix For: 0.94.0 Attachments: 4683.txt 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. -- 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-4689) [89-fb] Make the table level metrics work with rpc* metrics
[ https://issues.apache.org/jira/browse/HBASE-4689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137707#comment-13137707 ] jirapos...@reviews.apache.org commented on HBASE-4689: -- bq. On 2011-10-27 21:09:56, Nicolas Spiegelberg wrote: bq. src/test/java/org/apache/hadoop/hbase/regionserver/metrics/TestSchemaMetrics.java, line 237 bq. https://reviews.apache.org/r/2587/diff/2/?file=53822#file53822line237 bq. bq. as an aside: have we currently started using table-level metrics in our dashboards yet? the common abbreviation for table is tbl instead of tab (normally, cut out the vowels). would be nice to change if we're not dependent on this format yet. Some applications has started to using this format:( But I agree to rename it as 'tbl'. - Liyin --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/2587/#review2893 --- On 2011-10-27 20:23:31, Liyin Tang wrote: bq. bq. --- bq. This is an automatically generated e-mail. To reply, visit: bq. https://reviews.apache.org/r/2587/ bq. --- bq. bq. (Updated 2011-10-27 20:23:31) bq. bq. bq. Review request for hbase, Mikhail Bautin, Pritam Damania, Prakash Khemani, Amitanand Aiyer, Kannan Muthukkaruppan, Jerry Chen, Karthik Ranganathan, and Nicolas Spiegelberg. bq. bq. bq. Summary bq. --- bq. bq. In r1182034, the per table/cf for rpc* metrics has a bug. It will only show cf level metrics even though we enabled the per table level metrics. bq. Fix this bug here. bq. bq. bq. This addresses bug HBASE-4689. bq. https://issues.apache.org/jira/browse/HBASE-4689 bq. bq. bq. Diffs bq. - bq. bq.src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java 6c821c0 bq. src/main/java/org/apache/hadoop/hbase/regionserver/metrics/SchemaMetrics.java 8776ffe bq. src/test/java/org/apache/hadoop/hbase/regionserver/metrics/TestSchemaMetrics.java c03532a bq. bq. Diff: https://reviews.apache.org/r/2587/diff bq. bq. bq. Testing bq. --- bq. bq. Passed all the unit tests and tested the rpc metrics in the dev cluster bq. bq. bq. Thanks, bq. bq. Liyin bq. bq. [89-fb] Make the table level metrics work with rpc* metrics --- Key: HBASE-4689 URL: https://issues.apache.org/jira/browse/HBASE-4689 Project: HBase Issue Type: Sub-task Affects Versions: 0.89.20100924 Reporter: Liyin Tang Assignee: Liyin Tang Attachments: hbase-4689.patch In r1182034, the per table/cf for rpc* metrics has a bug. It will only show cf level metrics even though we enabled the per table level metrics. Fix this bug here. -- 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-4680) FSUtils.isInSafeMode() requires superuser privileges when HDFS permissions checking enabled
[
https://issues.apache.org/jira/browse/HBASE-4680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137708#comment-13137708
]
Andrew Purtell commented on HBASE-4680:
---
+1
FSUtils.isInSafeMode() requires superuser privileges when HDFS permissions
checking enabled
---
Key: HBASE-4680
URL: https://issues.apache.org/jira/browse/HBASE-4680
Project: HBase
Issue Type: Bug
Components: util
Affects Versions: 0.92.0
Reporter: Gary Helmling
Priority: Critical
Fix For: 0.92.0
Attachments: HBASE-4680.patch
The HDFS safe mode check workaround introduced by HBASE-4510 performs a
{{FileSystem.setPermission()}} operation on the root directory (/) when
attempting to trigger a {{SafeModeException}}. As a result, it requires
superuser privileges when running with DFS permission checking enabled.
Changing the operations to act on the HBase root directory should be safe,
since the master process must have write access to 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-4528) The put operation can release the rowlock before sync-ing the Hlog
[ https://issues.apache.org/jira/browse/HBASE-4528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137719#comment-13137719 ] Jonathan Gray commented on HBASE-4528: -- Is it safe to ignore this close? Should it be a WARN not DEBUG? I'm a little confused why this is happening in the test. Is the FS being closed before this finishes or what? The put operation can release the rowlock before sync-ing the Hlog -- Key: HBASE-4528 URL: https://issues.apache.org/jira/browse/HBASE-4528 Project: HBase Issue Type: Improvement Components: regionserver Reporter: dhruba borthakur Assignee: dhruba borthakur Fix For: 0.94.0 Attachments: 4528-trunk.txt, HBASE-4528-Trunk-FINAL.patch, appendNoSync5.txt, appendNoSyncPut1.txt, appendNoSyncPut2.txt, appendNoSyncPut3.txt, appendNoSyncPut4.txt, appendNoSyncPut5.txt, appendNoSyncPut6.txt, appendNoSyncPut7.txt, appendNoSyncPut8.txt This allows for better throughput when there are hot rows. A single row update improves from 100 puts/sec/server to 5000 puts/sec/server. -- 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-4680) FSUtils.isInSafeMode() requires superuser privileges when HDFS permissions checking enabled
[
https://issues.apache.org/jira/browse/HBASE-4680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137721#comment-13137721
]
stack commented on HBASE-4680:
--
+1
FSUtils.isInSafeMode() requires superuser privileges when HDFS permissions
checking enabled
---
Key: HBASE-4680
URL: https://issues.apache.org/jira/browse/HBASE-4680
Project: HBase
Issue Type: Bug
Components: util
Affects Versions: 0.92.0
Reporter: Gary Helmling
Priority: Critical
Fix For: 0.92.0
Attachments: HBASE-4680.patch
The HDFS safe mode check workaround introduced by HBASE-4510 performs a
{{FileSystem.setPermission()}} operation on the root directory (/) when
attempting to trigger a {{SafeModeException}}. As a result, it requires
superuser privileges when running with DFS permission checking enabled.
Changing the operations to act on the HBase root directory should be safe,
since the master process must have write access to 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-4689) [89-fb] Make the table level metrics work with rpc* metrics
[ https://issues.apache.org/jira/browse/HBASE-4689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137728#comment-13137728 ] jirapos...@reviews.apache.org commented on HBASE-4689: -- --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/2587/ --- (Updated 2011-10-27 23:26:27.328348) Review request for hbase, Mikhail Bautin, Pritam Damania, Prakash Khemani, Amitanand Aiyer, Kannan Muthukkaruppan, Jerry Chen, Karthik Ranganathan, and Nicolas Spiegelberg. Changes --- Address Nicolas' comments. Summary --- In r1182034, the per table/cf for rpc* metrics has a bug. It will only show cf level metrics even though we enabled the per table level metrics. Fix this bug here. This addresses bug HBASE-4689. https://issues.apache.org/jira/browse/HBASE-4689 Diffs (updated) - src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java 6c821c0 src/main/java/org/apache/hadoop/hbase/regionserver/metrics/SchemaMetrics.java 8776ffe src/test/java/org/apache/hadoop/hbase/regionserver/metrics/TestSchemaMetrics.java c03532a Diff: https://reviews.apache.org/r/2587/diff Testing --- Passed all the unit tests and tested the rpc metrics in the dev cluster Thanks, Liyin [89-fb] Make the table level metrics work with rpc* metrics --- Key: HBASE-4689 URL: https://issues.apache.org/jira/browse/HBASE-4689 Project: HBase Issue Type: Sub-task Affects Versions: 0.89.20100924 Reporter: Liyin Tang Assignee: Liyin Tang Attachments: hbase-4689.patch In r1182034, the per table/cf for rpc* metrics has a bug. It will only show cf level metrics even though we enabled the per table level metrics. Fix this bug here. -- 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-4528) The put operation can release the rowlock before sync-ing the Hlog
[ https://issues.apache.org/jira/browse/HBASE-4528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137746#comment-13137746 ] Ted Yu commented on HBASE-4528: --- I didn't keep the whole output file for the failed test. I need to look at 0.20.205 source code for better understanding of the above NPE. The additional log should be changed to WARN. The put operation can release the rowlock before sync-ing the Hlog -- Key: HBASE-4528 URL: https://issues.apache.org/jira/browse/HBASE-4528 Project: HBase Issue Type: Improvement Components: regionserver Reporter: dhruba borthakur Assignee: dhruba borthakur Fix For: 0.94.0 Attachments: 4528-trunk.txt, HBASE-4528-Trunk-FINAL.patch, appendNoSync5.txt, appendNoSyncPut1.txt, appendNoSyncPut2.txt, appendNoSyncPut3.txt, appendNoSyncPut4.txt, appendNoSyncPut5.txt, appendNoSyncPut6.txt, appendNoSyncPut7.txt, appendNoSyncPut8.txt This allows for better throughput when there are hot rows. A single row update improves from 100 puts/sec/server to 5000 puts/sec/server. -- 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-4690) Intermittent TestRegionServerCoprocessorExceptionWithRemove#testExceptionFromCoprocessorDuringPut failure
[ https://issues.apache.org/jira/browse/HBASE-4690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell reassigned HBASE-4690: - Assignee: Eugene Koontz Intermittent TestRegionServerCoprocessorExceptionWithRemove#testExceptionFromCoprocessorDuringPut failure - Key: HBASE-4690 URL: https://issues.apache.org/jira/browse/HBASE-4690 Project: HBase Issue Type: Test Affects Versions: 0.92.0 Reporter: Ted Yu Assignee: Eugene Koontz Fix For: 0.92.0 See https://builds.apache.org/view/G-L/view/HBase/job/HBase-0.92/83/testReport/junit/org.apache.hadoop.hbase.coprocessor/TestRegionServerCoprocessorExceptionWithAbort/testExceptionFromCoprocessorDuringPut/ Somehow getRSForFirstRegionInTable() wasn't able to retrieve the region server. One fix for this issue is to spin up MiniCluster with 1 region server so that we don't need to search for the region server where first region is hosted. -- 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-4686) [89-fb] Fix per-store metrics aggregation
[ https://issues.apache.org/jira/browse/HBASE-4686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137761#comment-13137761 ] Phabricator commented on HBASE-4686: Liyin has accepted the revision [jira] [HBASE-4686] [89-fb] Fix per-store metrics aggregation . It looks good to me. Just one minor comments: INLINE COMMENTS src/main/java/org/apache/hadoop/hbase/regionserver/metrics/SchemaMetrics.java:384 This api looks like very hard to use. Maybe we can elaborate what's in the map a little bit:) REVISION DETAIL https://reviews.facebook.net/D87 [89-fb] Fix per-store metrics aggregation -- Key: HBASE-4686 URL: https://issues.apache.org/jira/browse/HBASE-4686 Project: HBase Issue Type: Bug Reporter: Mikhail Bautin Assignee: Mikhail Bautin Attachments: D87.1.patch, HBASE-4686-TestRegionServerMetics-and-Store-metric-a-20111027134023-cc718144.patch, HBASE-4686-jira-89-fb-Fix-per-store-metrics-aggregat-20111027152723-05bea421.patch In r1182034 per-Store metrics were broken, because the aggregation of StoreFile metrics over all stores in a region was replaced by overriding them every time. We saw these metrics drop by a factor of numRegions on a production cluster -- thanks to Kannan for noticing this! We need to fix the metrics and add a unit test to ensure regressions like this don't happen in the future. -- 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-4689) [89-fb] Make the table level metrics work with rpc* metrics
[ https://issues.apache.org/jira/browse/HBASE-4689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Liyin Tang updated HBASE-4689: -- Attachment: (was: hbase-4689.patch) [89-fb] Make the table level metrics work with rpc* metrics --- Key: HBASE-4689 URL: https://issues.apache.org/jira/browse/HBASE-4689 Project: HBase Issue Type: Sub-task Affects Versions: 0.89.20100924 Reporter: Liyin Tang Assignee: Liyin Tang Attachments: hbase-4689.patch In r1182034, the per table/cf for rpc* metrics has a bug. It will only show cf level metrics even though we enabled the per table level metrics. Fix this bug here. -- 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-4689) [89-fb] Make the table level metrics work with rpc* metrics
[ https://issues.apache.org/jira/browse/HBASE-4689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Liyin Tang updated HBASE-4689: -- Attachment: hbase-4689.patch [89-fb] Make the table level metrics work with rpc* metrics --- Key: HBASE-4689 URL: https://issues.apache.org/jira/browse/HBASE-4689 Project: HBase Issue Type: Sub-task Affects Versions: 0.89.20100924 Reporter: Liyin Tang Assignee: Liyin Tang Attachments: hbase-4689.patch In r1182034, the per table/cf for rpc* metrics has a bug. It will only show cf level metrics even though we enabled the per table level metrics. Fix this bug here. -- 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-4304) requestsPerSecond counter stuck at 0
[ https://issues.apache.org/jira/browse/HBASE-4304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137791#comment-13137791 ] Li Pi commented on HBASE-4304: -- Isn't diff in seconds? If so, I meant if diff 1. requestsPerSecond counter stuck at 0 Key: HBASE-4304 URL: https://issues.apache.org/jira/browse/HBASE-4304 Project: HBase Issue Type: Bug Components: master, regionserver Affects Versions: 0.92.0 Reporter: Todd Lipcon Assignee: Li Pi Priority: Critical Fix For: 0.92.0 Attachments: 4304v1.txt, 4304v2.txt, 4304v3.txt Running trunk @ r1163343, all of the requestsPerSecond counters are showing 0 both in the master UI and in the RS UI. The writeRequestsCount metric is properly updating in the RS UI. -- 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-4300) Start of new-version master fails if old master's znode is hanging around
[
https://issues.apache.org/jira/browse/HBASE-4300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137802#comment-13137802
]
Gary Helmling commented on HBASE-4300:
--
This change seems to be causing TestFromClientSide to hang in 0.92 branch.
Here's what I see in the output log on mini cluster startup:
{noformat}
2011-10-27 18:03:41,469 FATAL
[RegionServer:2;localhost.localdomain,45793,1319763820005]
regionserver.HRegionServer(1520): ABORTING region server localhost.loc
aldomain,45793,1319763820005: Unhandled exception: Not a host:port pair:
localhost.localdomain,59563,1319763819537
java.lang.IllegalArgumentException: Not a host:port pair:
localhost.localdomain,59563,1319763819537
at
org.apache.hadoop.hbase.util.Addressing.parseHostname(Addressing.java:74)
at org.apache.hadoop.hbase.ServerName.init(ServerName.java:95)
at
org.apache.hadoop.hbase.ServerName.parseVersionedServerName(ServerName.java:277)
at
org.apache.hadoop.hbase.MasterAddressTracker.bytesToServerName(MasterAddressTracker.java:77)
at
org.apache.hadoop.hbase.MasterAddressTracker.getMasterAddress(MasterAddressTracker.java:61)
at
org.apache.hadoop.hbase.regionserver.HRegionServer.getMaster(HRegionServer.java:1597)
at
org.apache.hadoop.hbase.regionserver.HRegionServer.reportForDuty(HRegionServer.java:1648)
at
org.apache.hadoop.hbase.regionserver.HRegionServer.run(HRegionServer.java:631)
at
org.apache.hadoop.hbase.MiniHBaseCluster$MiniHBaseClusterRegionServer.runRegionServer(MiniHBaseCluster.java:136)
at
org.apache.hadoop.hbase.MiniHBaseCluster$MiniHBaseClusterRegionServer.access$000(MiniHBaseCluster.java:89)
at
org.apache.hadoop.hbase.MiniHBaseCluster$MiniHBaseClusterRegionServer$1.run(MiniHBaseCluster.java:120)
{noformat}
Start of new-version master fails if old master's znode is hanging around
-
Key: HBASE-4300
URL: https://issues.apache.org/jira/browse/HBASE-4300
Project: HBase
Issue Type: Bug
Affects Versions: 0.92.0
Reporter: Todd Lipcon
Assignee: stack
Priority: Critical
Fix For: 0.92.0
Attachments: 4300-v2.txt, 4300-v3.txt, 4300.txt
I shut down an 0.90 cluster, and had to do so uncleanly. I then started a
trunk (0.92) cluster before the old master znode had expired. This cased:
java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at java.lang.String.substring(String.java:1937)
at
org.apache.hadoop.hbase.ServerName.parseHostname(ServerName.java:81)
at org.apache.hadoop.hbase.ServerName.init(ServerName.java:63)
at
org.apache.hadoop.hbase.master.ActiveMasterManager.blockUntilBecomingActiveMaster(ActiveMasterManager.java:148)
at
org.apache.hadoop.hbase.master.HMaster.becomeActiveMaster(HMaster.java:342)
at org.apache.hadoop.hbase.master.HMaster.run(HMaster.java:297)
--
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-4691) Remove more unnecessary byte[] copies from KeyValues
Remove more unnecessary byte[] copies from KeyValues Key: HBASE-4691 URL: https://issues.apache.org/jira/browse/HBASE-4691 Project: HBase Issue Type: Bug Reporter: Lars Hofhansl Assignee: Lars Hofhansl Priority: Minor Fix For: 0.94.0 Just looking through the code I found some more spots where we unnecessarily copy byte[] rather than just passing offset and length around. -- 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-4388) Second start after migration from 90 to trunk crashes
[ https://issues.apache.org/jira/browse/HBASE-4388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137892#comment-13137892 ] Hudson commented on HBASE-4388: --- Integrated in HBase-TRUNK #2375 (See [https://builds.apache.org/job/HBase-TRUNK/2375/]) HBASE-4388 Second start after migration from 90 to trunk crashes stack : Files : * /hbase/trunk/CHANGES.txt * /hbase/trunk/src/main/java/org/apache/hadoop/hbase/HConstants.java * /hbase/trunk/src/main/java/org/apache/hadoop/hbase/HRegionInfo.java * /hbase/trunk/src/main/java/org/apache/hadoop/hbase/catalog/MetaEditor.java * /hbase/trunk/src/main/java/org/apache/hadoop/hbase/catalog/MetaMigrationRemovingHTD.java * /hbase/trunk/src/main/java/org/apache/hadoop/hbase/catalog/MetaReader.java * /hbase/trunk/src/main/java/org/apache/hadoop/hbase/master/MasterFileSystem.java * /hbase/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java * /hbase/trunk/src/main/java/org/apache/hadoop/hbase/util/Writables.java * /hbase/trunk/src/test/data * /hbase/trunk/src/test/data/hbase-4388-root.dir.tgz * /hbase/trunk/src/test/java/org/apache/hadoop/hbase/HBaseTestingUtility.java * /hbase/trunk/src/test/java/org/apache/hadoop/hbase/client/TestMetaMigration.java * /hbase/trunk/src/test/java/org/apache/hadoop/hbase/client/TestMetaMigrationRemovingHTD.java * /hbase/trunk/src/test/java/org/apache/hadoop/hbase/migration * /hbase/trunk/src/test/java/org/apache/hadoop/hbase/migration/TestMigrationFrom090To092.java Second start after migration from 90 to trunk crashes - Key: HBASE-4388 URL: https://issues.apache.org/jira/browse/HBASE-4388 Project: HBase Issue Type: Bug Components: master, migration Affects Versions: 0.92.0 Reporter: Todd Lipcon Assignee: stack Priority: Blocker Fix For: 0.92.0 Attachments: 4388-v2.txt, 4388-v3.txt, 4388-v4.txt, 4388.txt, hbase-4388-root.dir.tgz, hbase-master-nase.log, meta.tgz I started a trunk cluster to upgrade from 90, inserted a ton of data, then did a clean shutdown. When I started again, I got the following exception: 11/09/13 12:29:09 INFO master.HMaster: Meta has HRI with HTDs. Updating meta now. 11/09/13 12:29:09 FATAL master.HMaster: Unhandled exception. Starting shutdown. java.lang.NegativeArraySizeException: -102 at org.apache.hadoop.hbase.util.Bytes.readByteArray(Bytes.java:147) at org.apache.hadoop.hbase.HTableDescriptor.readFields(HTableDescriptor.java:606) at org.apache.hadoop.hbase.migration.HRegionInfo090x.readFields(HRegionInfo090x.java:641) at org.apache.hadoop.hbase.util.Writables.getWritable(Writables.java:133) at org.apache.hadoop.hbase.util.Writables.getWritable(Writables.java:103) at org.apache.hadoop.hbase.util.Writables.getHRegionInfoForMigration(Writables.java:228) at org.apache.hadoop.hbase.catalog.MetaEditor.getHRegionInfoForMigration(MetaEditor.java:350) at org.apache.hadoop.hbase.catalog.MetaEditor$1.visit(MetaEditor.java:273) at org.apache.hadoop.hbase.catalog.MetaReader.fullScan(MetaReader.java:633) at org.apache.hadoop.hbase.catalog.MetaReader.fullScan(MetaReader.java:255) at org.apache.hadoop.hbase.catalog.MetaReader.fullScan(MetaReader.java:235) at org.apache.hadoop.hbase.catalog.MetaEditor.updateMetaWithNewRegionInfo(MetaEditor.java:284) at org.apache.hadoop.hbase.catalog.MetaEditor.migrateRootAndMeta(MetaEditor.java:298) at org.apache.hadoop.hbase.master.HMaster.updateMetaWithNewHRI(HMaster.java:529) at org.apache.hadoop.hbase.master.HMaster.finishInitialization(HMaster.java:472) at org.apache.hadoop.hbase.master.HMaster.run(HMaster.java:309) -- 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-4685) TestDistributedLogSplitting.testOrphanLogCreation failing because of ArithmeticException: / by zero.
[ https://issues.apache.org/jira/browse/HBASE-4685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137891#comment-13137891 ] Hudson commented on HBASE-4685: --- Integrated in HBase-TRUNK #2375 (See [https://builds.apache.org/job/HBase-TRUNK/2375/]) HBASE-4685 TestDistributedLogSplitting.testOrphanLogCreation failing because of ArithmeticException: / by zero. stack : Files : * /hbase/trunk/CHANGES.txt * /hbase/trunk/src/test/java/org/apache/hadoop/hbase/master/TestDistributedLogSplitting.java TestDistributedLogSplitting.testOrphanLogCreation failing because of ArithmeticException: / by zero. Key: HBASE-4685 URL: https://issues.apache.org/jira/browse/HBASE-4685 Project: HBase Issue Type: Bug Reporter: stack Fix For: 0.92.0 Attachments: 4685.txt -- 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-4300) Start of new-version master fails if old master's znode is hanging around
[ https://issues.apache.org/jira/browse/HBASE-4300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137893#comment-13137893 ] Hudson commented on HBASE-4300: --- Integrated in HBase-TRUNK #2375 (See [https://builds.apache.org/job/HBase-TRUNK/2375/]) HBASE-4300 Start of new-version master fails if old master's znode is hanging around stack : Files : * /hbase/trunk/CHANGES.txt * /hbase/trunk/src/main/java/org/apache/hadoop/hbase/ClusterStatus.java * /hbase/trunk/src/main/java/org/apache/hadoop/hbase/MasterAddressTracker.java * /hbase/trunk/src/main/java/org/apache/hadoop/hbase/ServerName.java * /hbase/trunk/src/main/java/org/apache/hadoop/hbase/executor/RegionTransitionData.java * /hbase/trunk/src/main/java/org/apache/hadoop/hbase/ipc/HMasterRegionInterface.java * /hbase/trunk/src/main/java/org/apache/hadoop/hbase/master/ActiveMasterManager.java * /hbase/trunk/src/main/java/org/apache/hadoop/hbase/master/HMaster.java * /hbase/trunk/src/main/java/org/apache/hadoop/hbase/master/MasterFileSystem.java * /hbase/trunk/src/main/java/org/apache/hadoop/hbase/master/ServerManager.java * /hbase/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java * /hbase/trunk/src/main/java/org/apache/hadoop/hbase/replication/ReplicationZookeeper.java * /hbase/trunk/src/main/java/org/apache/hadoop/hbase/thrift/ThriftServer.java * /hbase/trunk/src/main/java/org/apache/hadoop/hbase/util/Addressing.java * /hbase/trunk/src/main/java/org/apache/hadoop/hbase/zookeeper/RegionServerTracker.java * /hbase/trunk/src/main/java/org/apache/hadoop/hbase/zookeeper/RootRegionTracker.java * /hbase/trunk/src/test/java/org/apache/hadoop/hbase/TestServerName.java * /hbase/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestMasterAddressManager.java * /hbase/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestSplitTransactionOnCluster.java Start of new-version master fails if old master's znode is hanging around - Key: HBASE-4300 URL: https://issues.apache.org/jira/browse/HBASE-4300 Project: HBase Issue Type: Bug Affects Versions: 0.92.0 Reporter: Todd Lipcon Assignee: stack Priority: Critical Fix For: 0.92.0 Attachments: 4300-v2.txt, 4300-v3.txt, 4300.txt I shut down an 0.90 cluster, and had to do so uncleanly. I then started a trunk (0.92) cluster before the old master znode had expired. This cased: java.lang.StringIndexOutOfBoundsException: String index out of range: -1 at java.lang.String.substring(String.java:1937) at org.apache.hadoop.hbase.ServerName.parseHostname(ServerName.java:81) at org.apache.hadoop.hbase.ServerName.init(ServerName.java:63) at org.apache.hadoop.hbase.master.ActiveMasterManager.blockUntilBecomingActiveMaster(ActiveMasterManager.java:148) at org.apache.hadoop.hbase.master.HMaster.becomeActiveMaster(HMaster.java:342) at org.apache.hadoop.hbase.master.HMaster.run(HMaster.java:297) -- 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-4300) Start of new-version master fails if old master's znode is hanging around
[
https://issues.apache.org/jira/browse/HBASE-4300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137915#comment-13137915
]
Ted Yu commented on HBASE-4300:
---
From
https://builds.apache.org/view/G-L/view/HBase/job/HBase-TRUNK/2375/console, we
can see that only a few tests were run in 191 minutes:
{code}
Tests run: 13, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.121 sec
Running org.apache.hadoop.hbase.util.TestRegionSplitter
Running org.apache.hadoop.hbase.util.TestHBaseFsck
Build timed out (after 191 minutes). Marking the build as failed.
[locks-and-latches] Releasing all the locks
{code}
A lot of tests hung.
Start of new-version master fails if old master's znode is hanging around
-
Key: HBASE-4300
URL: https://issues.apache.org/jira/browse/HBASE-4300
Project: HBase
Issue Type: Bug
Affects Versions: 0.92.0
Reporter: Todd Lipcon
Assignee: stack
Priority: Critical
Fix For: 0.92.0
Attachments: 4300-v2.txt, 4300-v3.txt, 4300.txt
I shut down an 0.90 cluster, and had to do so uncleanly. I then started a
trunk (0.92) cluster before the old master znode had expired. This cased:
java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at java.lang.String.substring(String.java:1937)
at
org.apache.hadoop.hbase.ServerName.parseHostname(ServerName.java:81)
at org.apache.hadoop.hbase.ServerName.init(ServerName.java:63)
at
org.apache.hadoop.hbase.master.ActiveMasterManager.blockUntilBecomingActiveMaster(ActiveMasterManager.java:148)
at
org.apache.hadoop.hbase.master.HMaster.becomeActiveMaster(HMaster.java:342)
at org.apache.hadoop.hbase.master.HMaster.run(HMaster.java:297)
--
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-2312) Possible data loss when RS goes into GC pause while rolling HLog
[ https://issues.apache.org/jira/browse/HBASE-2312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phabricator updated HBASE-2312: --- Attachment: D99.1.patch nspiegelberg requested code review of HBASE-2312 [jira] Possible data loss when RS goes into GC pause while rolling HLog. Reviewers: JIRA HBASE-2312 Possible data loss when RS goes into GC pause while rolling HLog There is a very corner case when bad things could happen(ie data loss): 1)RS #1 is going to roll its HLog - not yet created the new one, old one will get no more writes 2)RS #1 enters GC Pause of Death 3)Master lists HLog files of RS#1 that is has to split as RS#1 is dead, starts splitting 4)RS #1 wakes up, created the new HLog (previous one was rolled) and appends an edit - which is lost The following seems like a possible solution: 1)Master detects RS#1 is dead 2)The master renames the /hbase/.logs/regionserver name directory to something else (say /hbase/.logs/regionserver name-dead) 3)Add mkdir support (as opposed to mkdirs) to HDFS - so that a file create fails if the directory doesn't exist. Dhruba tells me this is very doable. 4)RS#1 comes back up and is not able create the new hlog. It restarts itself. TEST PLAN EMPTY REVISION DETAIL https://reviews.facebook.net/D99 AFFECTED FILES src/main/java/org/apache/hadoop/hbase/HConstants.java src/main/java/org/apache/hadoop/hbase/master/MasterFileSystem.java src/main/java/org/apache/hadoop/hbase/regionserver/wal/HLog.java src/main/java/org/apache/hadoop/hbase/regionserver/wal/HLogSplitter.java src/main/java/org/apache/hadoop/hbase/regionserver/wal/SequenceFileLogWriter.java src/main/java/org/apache/hadoop/hbase/replication/regionserver/ReplicationSource.java src/test/java/org/apache/hadoop/hbase/regionserver/wal/TestHLogSplit.java MANAGE HERALD DIFFERENTIAL RULES https://reviews.facebook.net/herald/view/differential/ WHY DID I GET THIS EMAIL? https://reviews.facebook.net/herald/transcript/213/ Tip: use the X-Herald-Rules header to filter Herald messages in your client. Possible data loss when RS goes into GC pause while rolling HLog Key: HBASE-2312 URL: https://issues.apache.org/jira/browse/HBASE-2312 Project: HBase Issue Type: Bug Components: master, regionserver Affects Versions: 0.90.0 Reporter: Karthik Ranganathan Assignee: Nicolas Spiegelberg Priority: Critical Fix For: 0.92.0 Attachments: D99.1.patch There is a very corner case when bad things could happen(ie data loss): 1)RS #1 is going to roll its HLog - not yet created the new one, old one will get no more writes 2)RS #1 enters GC Pause of Death 3)Master lists HLog files of RS#1 that is has to split as RS#1 is dead, starts splitting 4)RS #1 wakes up, created the new HLog (previous one was rolled) and appends an edit - which is lost The following seems like a possible solution: 1)Master detects RS#1 is dead 2)The master renames the /hbase/.logs/regionserver name directory to something else (say /hbase/.logs/regionserver name-dead) 3)Add mkdir support (as opposed to mkdirs) to HDFS - so that a file create fails if the directory doesn't exist. Dhruba tells me this is very doable. 4)RS#1 comes back up and is not able create the new hlog. It restarts itself. -- 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-2312) Possible data loss when RS goes into GC pause while rolling HLog
[ https://issues.apache.org/jira/browse/HBASE-2312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137921#comment-13137921 ] Nicolas Spiegelberg commented on HBASE-2312: Have a review up that integrates distributed log splitting. Note that it also fixes that elusive bug in TestReplication, which was the original reason we delayed checking this patch in. The problem was that ReplicationSource would check in the alive RS folder instead of the dead RS folder to verify that it should stall and wait for Log Splitting to finish and move to the OldLogs directory. If JD could please verify. I think Prakash has a little more work to do here for the ProcessServerDeath case, but this is an existing bug. We should file another JIRA for that and get this one committed :) Possible data loss when RS goes into GC pause while rolling HLog Key: HBASE-2312 URL: https://issues.apache.org/jira/browse/HBASE-2312 Project: HBase Issue Type: Bug Components: master, regionserver Affects Versions: 0.90.0 Reporter: Karthik Ranganathan Assignee: Nicolas Spiegelberg Priority: Critical Fix For: 0.92.0 Attachments: D99.1.patch There is a very corner case when bad things could happen(ie data loss): 1)RS #1 is going to roll its HLog - not yet created the new one, old one will get no more writes 2)RS #1 enters GC Pause of Death 3)Master lists HLog files of RS#1 that is has to split as RS#1 is dead, starts splitting 4)RS #1 wakes up, created the new HLog (previous one was rolled) and appends an edit - which is lost The following seems like a possible solution: 1)Master detects RS#1 is dead 2)The master renames the /hbase/.logs/regionserver name directory to something else (say /hbase/.logs/regionserver name-dead) 3)Add mkdir support (as opposed to mkdirs) to HDFS - so that a file create fails if the directory doesn't exist. Dhruba tells me this is very doable. 4)RS#1 comes back up and is not able create the new hlog. It restarts itself. -- 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-4528) The put operation can release the rowlock before sync-ing the Hlog
[
https://issues.apache.org/jira/browse/HBASE-4528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137922#comment-13137922
]
Ted Yu commented on HBASE-4528:
---
From src/hdfs/org/apache/hadoop/hdfs/DFSClient.java:
{code}
private void closeThreads() throws IOException {
try {
streamer.close();
{code}
Besides closeInternal(), closeThreads() may be called from sync().
Looks like closeThreads() should be made re-entrant.
TRUNK build is broken at the moment.
I will try to reproduce the NPE after TRUNK becomes stable.
The put operation can release the rowlock before sync-ing the Hlog
--
Key: HBASE-4528
URL: https://issues.apache.org/jira/browse/HBASE-4528
Project: HBase
Issue Type: Improvement
Components: regionserver
Reporter: dhruba borthakur
Assignee: dhruba borthakur
Fix For: 0.94.0
Attachments: 4528-trunk.txt, HBASE-4528-Trunk-FINAL.patch,
appendNoSync5.txt, appendNoSyncPut1.txt, appendNoSyncPut2.txt,
appendNoSyncPut3.txt, appendNoSyncPut4.txt, appendNoSyncPut5.txt,
appendNoSyncPut6.txt, appendNoSyncPut7.txt, appendNoSyncPut8.txt
This allows for better throughput when there are hot rows. A single row
update improves from 100 puts/sec/server to 5000 puts/sec/server.
--
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-4300) Start of new-version master fails if old master's znode is hanging around
[ https://issues.apache.org/jira/browse/HBASE-4300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137925#comment-13137925 ] stack commented on HBASE-4300: -- Thanks lads. I'm on it. Start of new-version master fails if old master's znode is hanging around - Key: HBASE-4300 URL: https://issues.apache.org/jira/browse/HBASE-4300 Project: HBase Issue Type: Bug Affects Versions: 0.92.0 Reporter: Todd Lipcon Assignee: stack Priority: Critical Fix For: 0.92.0 Attachments: 4300-v2.txt, 4300-v3.txt, 4300.txt I shut down an 0.90 cluster, and had to do so uncleanly. I then started a trunk (0.92) cluster before the old master znode had expired. This cased: java.lang.StringIndexOutOfBoundsException: String index out of range: -1 at java.lang.String.substring(String.java:1937) at org.apache.hadoop.hbase.ServerName.parseHostname(ServerName.java:81) at org.apache.hadoop.hbase.ServerName.init(ServerName.java:63) at org.apache.hadoop.hbase.master.ActiveMasterManager.blockUntilBecomingActiveMaster(ActiveMasterManager.java:148) at org.apache.hadoop.hbase.master.HMaster.becomeActiveMaster(HMaster.java:342) at org.apache.hadoop.hbase.master.HMaster.run(HMaster.java:297) -- 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
[Differential] [Accepted] D87: [jira] [HBASE-4686] [89-fb] Fix per-store metrics aggregation
Liyin has accepted the revision [jira] [HBASE-4686] [89-fb] Fix per-store metrics aggregation . It looks good to me. Just one minor comments: INLINE COMMENTS src/main/java/org/apache/hadoop/hbase/regionserver/metrics/SchemaMetrics.java:384 This api looks like very hard to use. Maybe we can elaborate what's in the map a little bit:) REVISION DETAIL https://reviews.facebook.net/D87
[jira] [Updated] (HBASE-4679) Thrift null mutation error
[ https://issues.apache.org/jira/browse/HBASE-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Spiegelberg updated HBASE-4679: --- Resolution: Fixed Fix Version/s: 0.94.0 0.92.0 Status: Resolved (was: Patch Available) Thrift null mutation error -- Key: HBASE-4679 URL: https://issues.apache.org/jira/browse/HBASE-4679 Project: HBase Issue Type: Bug Affects Versions: 0.92.0, 0.94.0 Reporter: Nicolas Spiegelberg Assignee: Nicolas Spiegelberg Fix For: 0.92.0, 0.94.0 Attachments: HBASE-4679.patch When using null as a value for a mutation, HBasse thrift client failed and threw an error. We should instad check for a null byte buffer. -- 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-4645) Edits Log recovery losing data across column families
[ https://issues.apache.org/jira/browse/HBASE-4645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Spiegelberg updated HBASE-4645: --- Resolution: Fixed Fix Version/s: 0.94.0 0.92.0 Status: Resolved (was: Patch Available) Edits Log recovery losing data across column families - Key: HBASE-4645 URL: https://issues.apache.org/jira/browse/HBASE-4645 Project: HBase Issue Type: Bug Affects Versions: 0.89.20100924, 0.92.0 Reporter: Amitanand Aiyer Assignee: Amitanand Aiyer Fix For: 0.92.0, 0.94.0 Attachments: 4645-v9.diff There is a data loss happening (for some of the column families) when we do the replay logs. The bug seems to be from the fact that during replay-logs we only choose to replay the logs from the maximumSequenceID across *ALL* the stores. This is wrong. If a column family is ahead of others (because the crash happened before all the column families were flushed), then we lose data for the column families that have not yet caught up. The correct logic for replay should begin the replay from the minimum across the maximum in each store. -- 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-4681) StringIndexOutOfBoundsException parsing Hostname
[
https://issues.apache.org/jira/browse/HBASE-4681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137978#comment-13137978
]
gaojinchao commented on HBASE-4681:
---
Hi ,
operation:
1.kill -9 master
2.start master
I seen this logs:
2011-10-27 23:50:23,994 ERROR
org.apache.hadoop.hbase.zookeeper.RecoverableZooKeeper: Node /hbase/master
already exists and this is not a retry
2011-10-27 23:50:24,000 FATAL org.apache.hadoop.hbase.master.HMaster: Unhandled
exception. Starting shutdown.
java.lang.IllegalArgumentException: Not a host:port pair:
C3S31,2,1319773760617
at
org.apache.hadoop.hbase.util.Addressing.parseHostname(Addressing.java:74)
at org.apache.hadoop.hbase.ServerName.init(ServerName.java:95)
at
org.apache.hadoop.hbase.ServerName.parseVersionedServerName(ServerName.java:277)
at
org.apache.hadoop.hbase.master.ActiveMasterManager.blockUntilBecomingActiveMaster(ActiveMasterManager.java:148)
at
org.apache.hadoop.hbase.master.HMaster.becomeActiveMaster(HMaster.java:347)
at org.apache.hadoop.hbase.master.HMaster.run(HMaster.java:302)
at java.lang.Thread.run(Thread.java:662)
2011-10-27 23:50:24,002 INFO org.apache.hadoop.hbase.master.HMaster: Aborting
2011-10-27 23:50:24,002 DEBUG org.apache.hadoop.hbase.master.HMaster: Stopping
service threads
it seems data are garbled:
[zk: C3S32:2181(CONNECTED) 33] get /hbase/master
�
8974@C3S31C3S31,2,1319773760617
cZxid = 0x200015375
ctime = Thu Oct 27 23:49:20 EDT 2011
mZxid = 0x200015375
mtime = Thu Oct 27 23:49:20 EDT 2011
pZxid = 0x200015375
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0xa99db180010
dataLength = 40
numChildren = 0
[zk: C3S32:2181(CONNECTED) 34] quit
Quitting...
StringIndexOutOfBoundsException parsing Hostname
Key: HBASE-4681
URL: https://issues.apache.org/jira/browse/HBASE-4681
Project: HBase
Issue Type: Bug
Reporter: stack
Fix For: 0.92.0
Starting a 0.92 on 0.90 data with 0.90 zk ensemble I got this:
{code}
2011-10-26 06:13:53,920 ERROR
org.apache.hadoop.hbase.zookeeper.RecoverableZooKeeper: Node /hbase/master
already exists and this is not a retry
2011-10-26 06:13:53,927 FATAL org.apache.hadoop.hbase.master.HMaster:
Unhandled exception. Starting shutdown.
java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at java.lang.String.substring(String.java:1937)
at
org.apache.hadoop.hbase.ServerName.parseHostname(ServerName.java:81)
at org.apache.hadoop.hbase.ServerName.init(ServerName.java:63)
at
org.apache.hadoop.hbase.master.ActiveMasterManager.blockUntilBecomingActiveMaster(ActiveMasterManager.java:148)
at
org.apache.hadoop.hbase.master.HMaster.becomeActiveMaster(HMaster.java:346)
at org.apache.hadoop.hbase.master.HMaster.run(HMaster.java:301)
at java.lang.Thread.run(Thread.java:662)
2011-10-26 06:13:53,929 INFO org.apache.hadoop.hbase.master.HMaster: Aborting
2011-10-26 06:13:53,929 DEBUG org.apache.hadoop.hbase.master.HMaster:
Stopping service thre
{code}
I thought this had been fixed. Dig 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-2312) Possible data loss when RS goes into GC pause while rolling HLog
[ https://issues.apache.org/jira/browse/HBASE-2312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137987#comment-13137987 ] Phabricator commented on HBASE-2312: tedyu has commented on the revision HBASE-2312 [jira] Possible data loss when RS goes into GC pause while rolling HLog. INLINE COMMENTS src/main/java/org/apache/hadoop/hbase/master/MasterFileSystem.java:232 Should this assignment be exchanged with line 231 ? src/main/java/org/apache/hadoop/hbase/master/MasterFileSystem.java:256 If fs.rename() failed, should this assignment be skipped if fs.exists(splitDir) returns false ? src/main/java/org/apache/hadoop/hbase/master/MasterFileSystem.java:275 Should read because of: src/test/java/org/apache/hadoop/hbase/regionserver/wal/TestHLogSplit.java:831 Where would this sentence come from ? REVISION DETAIL https://reviews.facebook.net/D99 Possible data loss when RS goes into GC pause while rolling HLog Key: HBASE-2312 URL: https://issues.apache.org/jira/browse/HBASE-2312 Project: HBase Issue Type: Bug Components: master, regionserver Affects Versions: 0.90.0 Reporter: Karthik Ranganathan Assignee: Nicolas Spiegelberg Priority: Critical Fix For: 0.92.0 Attachments: D99.1.patch There is a very corner case when bad things could happen(ie data loss): 1)RS #1 is going to roll its HLog - not yet created the new one, old one will get no more writes 2)RS #1 enters GC Pause of Death 3)Master lists HLog files of RS#1 that is has to split as RS#1 is dead, starts splitting 4)RS #1 wakes up, created the new HLog (previous one was rolled) and appends an edit - which is lost The following seems like a possible solution: 1)Master detects RS#1 is dead 2)The master renames the /hbase/.logs/regionserver name directory to something else (say /hbase/.logs/regionserver name-dead) 3)Add mkdir support (as opposed to mkdirs) to HDFS - so that a file create fails if the directory doesn't exist. Dhruba tells me this is very doable. 4)RS#1 comes back up and is not able create the new hlog. It restarts itself. -- 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-2312) Possible data loss when RS goes into GC pause while rolling HLog
[ https://issues.apache.org/jira/browse/HBASE-2312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137992#comment-13137992 ] Phabricator commented on HBASE-2312: nspiegelberg has commented on the revision HBASE-2312 [jira] Possible data loss when RS goes into GC pause while rolling HLog. INLINE COMMENTS src/main/java/org/apache/hadoop/hbase/master/MasterFileSystem.java:232 231 basically resets the interrupt flag so the next blocking call will get an InterruptException. The other acceptable way to handle this scenario is to throw an InterruptedIOException, but we don't need the split to finish, so an IOE really isn't necessary. src/main/java/org/apache/hadoop/hbase/master/MasterFileSystem.java:254 this needs an IOE. patch porting problem src/test/java/org/apache/hadoop/hbase/regionserver/wal/TestHLogSplit.java:831 from JUnit documentation @Ignore takes an optional default parameter if you want to record why a test is being ignored REVISION DETAIL https://reviews.facebook.net/D99 Possible data loss when RS goes into GC pause while rolling HLog Key: HBASE-2312 URL: https://issues.apache.org/jira/browse/HBASE-2312 Project: HBase Issue Type: Bug Components: master, regionserver Affects Versions: 0.90.0 Reporter: Karthik Ranganathan Assignee: Nicolas Spiegelberg Priority: Critical Fix For: 0.92.0 Attachments: D99.1.patch There is a very corner case when bad things could happen(ie data loss): 1)RS #1 is going to roll its HLog - not yet created the new one, old one will get no more writes 2)RS #1 enters GC Pause of Death 3)Master lists HLog files of RS#1 that is has to split as RS#1 is dead, starts splitting 4)RS #1 wakes up, created the new HLog (previous one was rolled) and appends an edit - which is lost The following seems like a possible solution: 1)Master detects RS#1 is dead 2)The master renames the /hbase/.logs/regionserver name directory to something else (say /hbase/.logs/regionserver name-dead) 3)Add mkdir support (as opposed to mkdirs) to HDFS - so that a file create fails if the directory doesn't exist. Dhruba tells me this is very doable. 4)RS#1 comes back up and is not able create the new hlog. It restarts itself. -- 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-2312) Possible data loss when RS goes into GC pause while rolling HLog
[ https://issues.apache.org/jira/browse/HBASE-2312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137997#comment-13137997 ] Phabricator commented on HBASE-2312: tedyu has commented on the revision HBASE-2312 [jira] Possible data loss when RS goes into GC pause while rolling HLog. INLINE COMMENTS src/test/java/org/apache/hadoop/hbase/regionserver/wal/TestHLogSplit.java:831 HBase TRUNK uses 0.20.205 The @Ignore can be omitted, right ? REVISION DETAIL https://reviews.facebook.net/D99 Possible data loss when RS goes into GC pause while rolling HLog Key: HBASE-2312 URL: https://issues.apache.org/jira/browse/HBASE-2312 Project: HBase Issue Type: Bug Components: master, regionserver Affects Versions: 0.90.0 Reporter: Karthik Ranganathan Assignee: Nicolas Spiegelberg Priority: Critical Fix For: 0.92.0 Attachments: D99.1.patch There is a very corner case when bad things could happen(ie data loss): 1)RS #1 is going to roll its HLog - not yet created the new one, old one will get no more writes 2)RS #1 enters GC Pause of Death 3)Master lists HLog files of RS#1 that is has to split as RS#1 is dead, starts splitting 4)RS #1 wakes up, created the new HLog (previous one was rolled) and appends an edit - which is lost The following seems like a possible solution: 1)Master detects RS#1 is dead 2)The master renames the /hbase/.logs/regionserver name directory to something else (say /hbase/.logs/regionserver name-dead) 3)Add mkdir support (as opposed to mkdirs) to HDFS - so that a file create fails if the directory doesn't exist. Dhruba tells me this is very doable. 4)RS#1 comes back up and is not able create the new hlog. It restarts itself. -- 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-2312) Possible data loss when RS goes into GC pause while rolling HLog
[ https://issues.apache.org/jira/browse/HBASE-2312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13138002#comment-13138002 ] Phabricator commented on HBASE-2312: stack has requested changes to the revision HBASE-2312 [jira] Possible data loss when RS goes into GC pause while rolling HLog. Looks good. A few minor items. INLINE COMMENTS src/main/java/org/apache/hadoop/hbase/HConstants.java:188 Should this define be up here? Why not down in HLog? (I favor keeping defines in classes they pertain to -- could be ugly though if we need to go cross packages to get at a define. Master package would need to reach down into the wal package? If so, I suppose, leave it up here in HConstants). src/main/java/org/apache/hadoop/hbase/master/MasterFileSystem.java:192 The former code bracketed the return. Either put the return on same line as if or else add back the brackets I'd say. src/main/java/org/apache/hadoop/hbase/master/MasterFileSystem.java:223 Why not call server abort? Thats the usual idiom. src/main/java/org/apache/hadoop/hbase/master/MasterFileSystem.java:227 Why this? And 30 seconds is a long time (Should it be configurable)? src/main/java/org/apache/hadoop/hbase/master/MasterFileSystem.java:254 I suppose this not the end of the world. A regionserver could add a new log I suppose but chances of failed rename and RS adding new WAL are probably fairly low. src/main/java/org/apache/hadoop/hbase/regionserver/wal/SequenceFileLogWriter.java:126 Superfluous logging I'd say. Especially at info level. Log when we DON'T have this feature (maybe do it debug; if every file open has one of these info logs, then its going to generate lots of queries up in mailing lists, etc. At DEBUG it won't seem as critical) src/test/java/org/apache/hadoop/hbase/regionserver/wal/TestHLogSplit.java:831 Nice REVISION DETAIL https://reviews.facebook.net/D99 Possible data loss when RS goes into GC pause while rolling HLog Key: HBASE-2312 URL: https://issues.apache.org/jira/browse/HBASE-2312 Project: HBase Issue Type: Bug Components: master, regionserver Affects Versions: 0.90.0 Reporter: Karthik Ranganathan Assignee: Nicolas Spiegelberg Priority: Critical Fix For: 0.92.0 Attachments: D99.1.patch There is a very corner case when bad things could happen(ie data loss): 1)RS #1 is going to roll its HLog - not yet created the new one, old one will get no more writes 2)RS #1 enters GC Pause of Death 3)Master lists HLog files of RS#1 that is has to split as RS#1 is dead, starts splitting 4)RS #1 wakes up, created the new HLog (previous one was rolled) and appends an edit - which is lost The following seems like a possible solution: 1)Master detects RS#1 is dead 2)The master renames the /hbase/.logs/regionserver name directory to something else (say /hbase/.logs/regionserver name-dead) 3)Add mkdir support (as opposed to mkdirs) to HDFS - so that a file create fails if the directory doesn't exist. Dhruba tells me this is very doable. 4)RS#1 comes back up and is not able create the new hlog. It restarts itself. -- 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] [Issue Comment Edited] (HBASE-4528) The put operation can release the rowlock before sync-ing the Hlog
[
https://issues.apache.org/jira/browse/HBASE-4528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137922#comment-13137922
]
Ted Yu edited comment on HBASE-4528 at 10/28/11 4:37 AM:
-
From src/hdfs/org/apache/hadoop/hdfs/DFSClient.java:
{code}
private void closeThreads() throws IOException {
try {
streamer.close();
streamer.join();
{code}
Besides closeInternal(), closeThreads() may be called from sync().
Looks like closeThreads() should be made re-entrant (by adding streamer = null;
assignment after streamer.join() call).
So ignoring NPE shouldn't be a problem.
TRUNK build is broken at the moment.
I will try to reproduce the NPE after TRUNK becomes stable.
was (Author: yuzhih...@gmail.com):
From src/hdfs/org/apache/hadoop/hdfs/DFSClient.java:
{code}
private void closeThreads() throws IOException {
try {
streamer.close();
{code}
Besides closeInternal(), closeThreads() may be called from sync().
Looks like closeThreads() should be made re-entrant.
TRUNK build is broken at the moment.
I will try to reproduce the NPE after TRUNK becomes stable.
The put operation can release the rowlock before sync-ing the Hlog
--
Key: HBASE-4528
URL: https://issues.apache.org/jira/browse/HBASE-4528
Project: HBase
Issue Type: Improvement
Components: regionserver
Reporter: dhruba borthakur
Assignee: dhruba borthakur
Fix For: 0.94.0
Attachments: 4528-trunk.txt, HBASE-4528-Trunk-FINAL.patch,
appendNoSync5.txt, appendNoSyncPut1.txt, appendNoSyncPut2.txt,
appendNoSyncPut3.txt, appendNoSyncPut4.txt, appendNoSyncPut5.txt,
appendNoSyncPut6.txt, appendNoSyncPut7.txt, appendNoSyncPut8.txt
This allows for better throughput when there are hot rows. A single row
update improves from 100 puts/sec/server to 5000 puts/sec/server.
--
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
