[jira] [Commented] (HBASE-6056) Restore hbase-default version check
[ https://issues.apache.org/jira/browse/HBASE-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13279456#comment-13279456 ] Hudson commented on HBASE-6056: --- Integrated in HBase-TRUNK #2907 (See [https://builds.apache.org/job/HBase-TRUNK/2907/]) HBASE-6056 Restore hbase-default version check (Revision 1340344) Result = FAILURE stack : Files : * /hbase/trunk/src/main/java/org/apache/hadoop/hbase/HBaseConfiguration.java Restore hbase-default version check --- Key: HBASE-6056 URL: https://issues.apache.org/jira/browse/HBASE-6056 Project: HBase Issue Type: Bug Reporter: stack Assignee: stack Fix For: 0.94.1 Was removed by mistake. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (HBASE-6054) 0.92 failing because of missing commons-io after upgrade to hadoop 1.0.3.
[ https://issues.apache.org/jira/browse/HBASE-6054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-6054. -- Resolution: Fixed Fix Version/s: 0.92.2 Assignee: stack Failing for some other reason now, not because of this issue. Resolving. 0.92 failing because of missing commons-io after upgrade to hadoop 1.0.3. - Key: HBASE-6054 URL: https://issues.apache.org/jira/browse/HBASE-6054 Project: HBase Issue Type: Bug Reporter: stack Assignee: stack Fix For: 0.92.2 Attachments: commons-io.txt, hbasedefaultcheck.txt See this note: http://search-hadoop.com/m/0UrOr19BG8v1/test+failure+after+upgrading+to+hadoop+1.0.3+Was%253A+ClassNotFoundException%253A+org.apache.commons.io.FileUtilssubj=test+failure+after+upgrading+to+hadoop+1+0+3+Was+ClassNotFoundException+org+apache+commons+io+FileUtils -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-6056) Restore hbase-default version check
[ https://issues.apache.org/jira/browse/HBASE-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13279461#comment-13279461 ] Hudson commented on HBASE-6056: --- Integrated in HBase-0.94 #203 (See [https://builds.apache.org/job/HBase-0.94/203/]) HBASE-6056 Restore hbase-default version check (Revision 1340345) Result = SUCCESS stack : Files : * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/HBaseConfiguration.java Restore hbase-default version check --- Key: HBASE-6056 URL: https://issues.apache.org/jira/browse/HBASE-6056 Project: HBase Issue Type: Bug Reporter: stack Assignee: stack Fix For: 0.94.1 Was removed by mistake. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5998) Bulk assignment: regionserver optimization by using a temporary cache for table descriptors when receveing an open regions request
[ https://issues.apache.org/jira/browse/HBASE-5998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nkeywal updated HBASE-5998: --- Resolution: Fixed Status: Resolved (was: Patch Available) depiste the failure mentionned by jenkins, the patch is visible in the source code. Bulk assignment: regionserver optimization by using a temporary cache for table descriptors when receveing an open regions request -- Key: HBASE-5998 URL: https://issues.apache.org/jira/browse/HBASE-5998 Project: HBase Issue Type: Improvement Components: regionserver Affects Versions: 0.96.0 Reporter: nkeywal Assignee: nkeywal Priority: Minor Fix For: 0.96.0 Attachments: 5998.v2.patch, 5998.v3.patch During the assignment, on the regionserver, before creating the handlers we load the table description. Even if there is a cache, we check the timestamps for each region, while it's not necessary. The test below is just with one node, with more nodes the benefit will improve. By limiting the time spent in HRegion#openRegion we increase the parallelization during cluster startup, as the master is using a pool of threads to call the RS. -- Without the fix 2012-05-14 11:40:52,501 DEBUG org.apache.hadoop.hbase.master.AssignmentManager: Bulk assigning 1193 region(s) to localhost,11003,1336988444043 2012-05-14 11:41:09,947 DEBUG org.apache.hadoop.hbase.master.AssignmentManager: Bulk assigning done for localhost,11003,1336988444043 -- With the fix 2012-05-14 11:34:40,444 DEBUG org.apache.hadoop.hbase.master.AssignmentManager: Bulk assigning 1193 region(s) to localhost,11003,1336988444043 2012-05-14 11:34:40,929 DEBUG org.apache.hadoop.hbase.master.AssignmentManager: Bulk assigning done for localhost,11003,1336988065948 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-6057) Change some tests categories to optimize build time
nkeywal created HBASE-6057: -- Summary: Change some tests categories to optimize build time Key: HBASE-6057 URL: https://issues.apache.org/jira/browse/HBASE-6057 Project: HBase Issue Type: Improvement Components: test Affects Versions: 0.96.0 Reporter: nkeywal Assignee: nkeywal Priority: Minor Some tests categorized as small takes more than 15s: it's better if they are executed in // with the medium tests. Some medium tests last less than 2s: it's better to have then executed with the small tests: we save a fork. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-6057) Change some tests categories to optimize build time
[ https://issues.apache.org/jira/browse/HBASE-6057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nkeywal updated HBASE-6057: --- Status: Patch Available (was: Open) this should buy around 5%-10%... Change some tests categories to optimize build time --- Key: HBASE-6057 URL: https://issues.apache.org/jira/browse/HBASE-6057 Project: HBase Issue Type: Improvement Components: test Affects Versions: 0.96.0 Reporter: nkeywal Assignee: nkeywal Priority: Minor Attachments: 6057.v1.patch Some tests categorized as small takes more than 15s: it's better if they are executed in // with the medium tests. Some medium tests last less than 2s: it's better to have then executed with the small tests: we save a fork. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-6057) Change some tests categories to optimize build time
[ https://issues.apache.org/jira/browse/HBASE-6057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nkeywal updated HBASE-6057: --- Attachment: 6057.v1.patch Change some tests categories to optimize build time --- Key: HBASE-6057 URL: https://issues.apache.org/jira/browse/HBASE-6057 Project: HBase Issue Type: Improvement Components: test Affects Versions: 0.96.0 Reporter: nkeywal Assignee: nkeywal Priority: Minor Attachments: 6057.v1.patch Some tests categorized as small takes more than 15s: it's better if they are executed in // with the medium tests. Some medium tests last less than 2s: it's better to have then executed with the small tests: we save a fork. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-6058) Use ZK 3.4 API 'multi' in bulk assignment
nkeywal created HBASE-6058: -- Summary: Use ZK 3.4 API 'multi' in bulk assignment Key: HBASE-6058 URL: https://issues.apache.org/jira/browse/HBASE-6058 Project: HBase Issue Type: Improvement Components: master, zookeeper Affects Versions: 0.96.0 Reporter: nkeywal Assignee: nkeywal Priority: Minor We use async API today. This is already much much faster than the sync API. Still, it makes sense to use the 'multi' function: this will decrease the network zookeeper load at startup/rolling restart. On a 500 nodes cluster, we see 3 that 3 seconds are spent on updating ZK per bulk assignment. This should cut it in half (+ the benefits on the network/zk load). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-6057) Change some tests categories to optimize build time
[ https://issues.apache.org/jira/browse/HBASE-6057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13279502#comment-13279502 ] Hadoop QA commented on HBASE-6057: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12528217/6057.v1.patch against trunk revision . +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 57 new or modified tests. +1 hadoop23. The patch compiles against the hadoop 0.23.x profile. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. -1 findbugs. The patch appears to introduce 33 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.replication.TestReplication org.apache.hadoop.hbase.regionserver.TestSplitTransactionOnCluster org.apache.hadoop.hbase.replication.TestMultiSlaveReplication org.apache.hadoop.hbase.replication.TestMasterReplication Test results: https://builds.apache.org/job/PreCommit-HBASE-Build/1941//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/1941//artifact/trunk/patchprocess/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/1941//console This message is automatically generated. Change some tests categories to optimize build time --- Key: HBASE-6057 URL: https://issues.apache.org/jira/browse/HBASE-6057 Project: HBase Issue Type: Improvement Components: test Affects Versions: 0.96.0 Reporter: nkeywal Assignee: nkeywal Priority: Minor Attachments: 6057.v1.patch Some tests categorized as small takes more than 15s: it's better if they are executed in // with the medium tests. Some medium tests last less than 2s: it's better to have then executed with the small tests: we save a fork. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-6057) Change some tests categories to optimize build time
[ https://issues.apache.org/jira/browse/HBASE-6057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13279504#comment-13279504 ] nkeywal commented on HBASE-6057: All these tests are not impacted by the change. Patch is ok imho. Change some tests categories to optimize build time --- Key: HBASE-6057 URL: https://issues.apache.org/jira/browse/HBASE-6057 Project: HBase Issue Type: Improvement Components: test Affects Versions: 0.96.0 Reporter: nkeywal Assignee: nkeywal Priority: Minor Attachments: 6057.v1.patch Some tests categorized as small takes more than 15s: it's better if they are executed in // with the medium tests. Some medium tests last less than 2s: it's better to have then executed with the small tests: we save a fork. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5882) Prcoess RIT on master restart can try assigning the region if the region is found on a dead server instead of waiting for Timeout Monitor
[ https://issues.apache.org/jira/browse/HBASE-5882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13279505#comment-13279505 ] ramkrishna.s.vasudevan commented on HBASE-5882: --- Committed to trunk. Thanks for the patch Ashutosh. Thanks for the review Stack and Ted. Prcoess RIT on master restart can try assigning the region if the region is found on a dead server instead of waiting for Timeout Monitor - Key: HBASE-5882 URL: https://issues.apache.org/jira/browse/HBASE-5882 Project: HBase Issue Type: Improvement Affects Versions: 0.90.6, 0.92.1 Reporter: ramkrishna.s.vasudevan Assignee: Ashutosh Jindal Attachments: HBASE-5882_v5.patch, hbase_5882.patch, hbase_5882_V2.patch, hbase_5882_V3.patch, hbase_5882_V4.patch Currently on master restart if it tries to do processRIT, any region if found on dead server tries to avoid the nwe assignment so that timeout monitor can take care. This case is more prominent if the node is found in RS_ZK_REGION_OPENING state. I think we can handle this by triggering a new assignment with a new plan. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5974) Scanner retry behavior with RPC timeout on next() seems incorrect
[ https://issues.apache.org/jira/browse/HBASE-5974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13279506#comment-13279506 ] ramkrishna.s.vasudevan commented on HBASE-5974: --- @Todd/Stack Can you review this patch? Seems to be pretty important fix. Scanner retry behavior with RPC timeout on next() seems incorrect - Key: HBASE-5974 URL: https://issues.apache.org/jira/browse/HBASE-5974 Project: HBase Issue Type: Bug Components: client, regionserver Affects Versions: 0.90.7, 0.92.1, 0.94.0, 0.96.0 Reporter: Todd Lipcon Priority: Critical Attachments: HBASE-5974_0.94.patch I'm seeing the following behavior: - set RPC timeout to a short value - call next() for some batch of rows, big enough so the client times out before the result is returned - the HConnectionManager stuff will retry the next() call to the same server. At this point, one of two things can happen: 1) the previous next() call will still be processing, in which case you get a LeaseException, because it was removed from the map during the processing, or 2) the next() call will succeed but skip the prior batch of rows. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5840) Open Region FAILED_OPEN doesn't clear the TaskMonitor Status, keeps showing the old status
[ https://issues.apache.org/jira/browse/HBASE-5840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13279507#comment-13279507 ] ramkrishna.s.vasudevan commented on HBASE-5840: --- Committed to 0.94.1. Hence resolving this. Open Region FAILED_OPEN doesn't clear the TaskMonitor Status, keeps showing the old status -- Key: HBASE-5840 URL: https://issues.apache.org/jira/browse/HBASE-5840 Project: HBase Issue Type: Bug Components: regionserver Affects Versions: 0.94.0 Reporter: Gopinathan A Assignee: rajeshbabu Fix For: 0.96.0, 0.94.1 Attachments: HBASE-5840.patch, HBASE-5840_0.94.patch, HBASE-5840_trunk.patch, HBASE-5840_v2.patch TaskMonitor Status will not be cleared in case Regions FAILED_OPEN. This will keeps showing old status. This will miss leads the user. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5840) Open Region FAILED_OPEN doesn't clear the TaskMonitor Status, keeps showing the old status
[ https://issues.apache.org/jira/browse/HBASE-5840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-5840: -- Resolution: Fixed Status: Resolved (was: Patch Available) Open Region FAILED_OPEN doesn't clear the TaskMonitor Status, keeps showing the old status -- Key: HBASE-5840 URL: https://issues.apache.org/jira/browse/HBASE-5840 Project: HBase Issue Type: Bug Components: regionserver Affects Versions: 0.94.0 Reporter: Gopinathan A Assignee: rajeshbabu Fix For: 0.96.0, 0.94.1 Attachments: HBASE-5840.patch, HBASE-5840_0.94.patch, HBASE-5840_trunk.patch, HBASE-5840_v2.patch TaskMonitor Status will not be cleared in case Regions FAILED_OPEN. This will keeps showing old status. This will miss leads the user. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-6031) RegionServer does not go down while aborting
[ https://issues.apache.org/jira/browse/HBASE-6031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-6031: -- Affects Version/s: 0.94.0 Fix Version/s: 0.94.1 0.96.0 RegionServer does not go down while aborting Key: HBASE-6031 URL: https://issues.apache.org/jira/browse/HBASE-6031 Project: HBase Issue Type: Bug Affects Versions: 0.94.0 Reporter: ramkrishna.s.vasudevan Fix For: 0.96.0, 0.94.1 Following is the thread dump. {code} 1997531088@qtp-716941846-5 prio=10 tid=0x7f7c5820c800 nid=0xe1b in Object.wait() [0x7f7c56ae8000] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) at org.mortbay.io.nio.SelectChannelEndPoint.blockWritable(SelectChannelEndPoint.java:279) - locked 0x7f7cfe0616d0 (a org.mortbay.jetty.nio.SelectChannelConnector$ConnectorEndPoint) at org.mortbay.jetty.AbstractGenerator$Output.blockForOutput(AbstractGenerator.java:545) at org.mortbay.jetty.AbstractGenerator$Output.write(AbstractGenerator.java:639) at org.mortbay.jetty.AbstractGenerator$Output.write(AbstractGenerator.java:580) at java.io.ByteArrayOutputStream.writeTo(ByteArrayOutputStream.java:109) - locked 0x7f7cfe74d758 (a org.mortbay.util.ByteArrayOutputStream2) at org.mortbay.jetty.AbstractGenerator$OutputWriter.write(AbstractGenerator.java:904) at java.io.Writer.write(Writer.java:96) - locked 0x7f7cfca02fc0 (a org.mortbay.jetty.HttpConnection$OutputWriter) at java.io.PrintWriter.write(PrintWriter.java:361) - locked 0x7f7cfca02fc0 (a org.mortbay.jetty.HttpConnection$OutputWriter) at org.jamon.escaping.HtmlEscaping.write(HtmlEscaping.java:43) at org.jamon.escaping.AbstractCharacterEscaping.write(AbstractCharacterEscaping.java:35) at org.apache.hadoop.hbase.tmpl.regionserver.RSStatusTmplImpl.renderNoFlush(RSStatusTmplImpl.java:222) at org.apache.hadoop.hbase.tmpl.regionserver.RSStatusTmpl.renderNoFlush(RSStatusTmpl.java:180) at org.apache.hadoop.hbase.tmpl.regionserver.RSStatusTmpl.render(RSStatusTmpl.java:171) at org.apache.hadoop.hbase.regionserver.RSStatusServlet.doGet(RSStatusServlet.java:48) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1221) at org.apache.hadoop.http.lib.StaticUserWebFilter$StaticUserFilter.doFilter(StaticUserWebFilter.java:109) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212) at org.apache.hadoop.http.HttpServer$QuotingInputFilter.doFilter(HttpServer.java:932) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:399) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.Server.handle(Server.java:326) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:928) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582) 1374615312@qtp-716941846-3 prio=10 tid=0x7f7c58214800 nid=0xc42 in Object.wait() [0x7f7c55bd9000] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) at org.mortbay.io.nio.SelectChannelEndPoint.blockWritable(SelectChannelEndPoint.java:279) - locked 0x7f7cfdbb6cc8 (a org.mortbay.jetty.nio.SelectChannelConnector$ConnectorEndPoint) at
[jira] [Updated] (HBASE-5882) Prcoess RIT on master restart can try assigning the region if the region is found on a dead server instead of waiting for Timeout Monitor
[ https://issues.apache.org/jira/browse/HBASE-5882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-5882: -- Affects Version/s: 0.94.0 Fix Version/s: 0.94.1 0.96.0 Prcoess RIT on master restart can try assigning the region if the region is found on a dead server instead of waiting for Timeout Monitor - Key: HBASE-5882 URL: https://issues.apache.org/jira/browse/HBASE-5882 Project: HBase Issue Type: Improvement Affects Versions: 0.90.6, 0.92.1, 0.94.0 Reporter: ramkrishna.s.vasudevan Assignee: Ashutosh Jindal Fix For: 0.96.0, 0.94.1 Attachments: HBASE-5882_v5.patch, hbase_5882.patch, hbase_5882_V2.patch, hbase_5882_V3.patch, hbase_5882_V4.patch Currently on master restart if it tries to do processRIT, any region if found on dead server tries to avoid the nwe assignment so that timeout monitor can take care. This case is more prominent if the node is found in RS_ZK_REGION_OPENING state. I think we can handle this by triggering a new assignment with a new plan. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5840) Open Region FAILED_OPEN doesn't clear the TaskMonitor Status, keeps showing the old status
[ https://issues.apache.org/jira/browse/HBASE-5840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13279518#comment-13279518 ] Hudson commented on HBASE-5840: --- Integrated in HBase-0.94 #204 (See [https://builds.apache.org/job/HBase-0.94/204/]) HBASE-5840 Open Region FAILED_OPEN doesn't clear the TaskMonitor Status, keeps showing the old status (Rajesh) (Revision 1340396) Result = FAILURE ramkrishna : Files : * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/regionserver/TestHRegion.java Open Region FAILED_OPEN doesn't clear the TaskMonitor Status, keeps showing the old status -- Key: HBASE-5840 URL: https://issues.apache.org/jira/browse/HBASE-5840 Project: HBase Issue Type: Bug Components: regionserver Affects Versions: 0.94.0 Reporter: Gopinathan A Assignee: rajeshbabu Fix For: 0.96.0, 0.94.1 Attachments: HBASE-5840.patch, HBASE-5840_0.94.patch, HBASE-5840_trunk.patch, HBASE-5840_v2.patch TaskMonitor Status will not be cleared in case Regions FAILED_OPEN. This will keeps showing old status. This will miss leads the user. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-6056) Restore hbase-default version check
[ https://issues.apache.org/jira/browse/HBASE-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13279524#comment-13279524 ] Hudson commented on HBASE-6056: --- Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #11 (See [https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/11/]) HBASE-6056 Restore hbase-default version check (Revision 1340344) Result = FAILURE stack : Files : * /hbase/trunk/src/main/java/org/apache/hadoop/hbase/HBaseConfiguration.java Restore hbase-default version check --- Key: HBASE-6056 URL: https://issues.apache.org/jira/browse/HBASE-6056 Project: HBase Issue Type: Bug Reporter: stack Assignee: stack Fix For: 0.94.1 Was removed by mistake. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-6007) Make getTableRegions return an empty list if the table does not exist
[ https://issues.apache.org/jira/browse/HBASE-6007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13279523#comment-13279523 ] Hudson commented on HBASE-6007: --- Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #11 (See [https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/11/]) [jira] [HBASE-6007] Make getTableRegions return an empty list if the table does not exist Summary: Making the getTableRegions Thrift API method handle TableNotFoundException and return an empty list in that case. Without this the behavior is dependent on whether an HTable object is present in the thread-local cache in case a table was deleted. Test Plan: Unit tests Reviewers: kannan, liyintang Reviewed By: liyintang CC: stack Differential Revision: https://reviews.facebook.net/D3243 (Revision 1340310) Result = FAILURE mbautin : Files : * /hbase/trunk/src/main/java/org/apache/hadoop/hbase/thrift/ThriftServerRunner.java Make getTableRegions return an empty list if the table does not exist - Key: HBASE-6007 URL: https://issues.apache.org/jira/browse/HBASE-6007 Project: HBase Issue Type: Bug Reporter: Mikhail Bautin Assignee: Mikhail Bautin Priority: Minor Attachments: D3243.1.patch, jira-HBASE-6007-Make-getTableRegions-return-an-empty-2012-05-18_17_02_40.patch Making the getTableRegions Thrift API method handle TableNotFoundException and return an empty list in that case. Without this the behavior is dependent on whether an HTable object is present in the thread-local cache in case a table was deleted. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5882) Prcoess RIT on master restart can try assigning the region if the region is found on a dead server instead of waiting for Timeout Monitor
[ https://issues.apache.org/jira/browse/HBASE-5882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13279525#comment-13279525 ] Hudson commented on HBASE-5882: --- Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #11 (See [https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/11/]) HBASE-5882 Prcoess RIT on master restart can try assigning the region if the region is found on a dead server instead of waiting for Timeout Monitor (Ashutosh) (Revision 1340392) Result = FAILURE ramkrishna : Files : * /hbase/trunk/src/main/java/org/apache/hadoop/hbase/master/AssignmentManager.java * /hbase/trunk/src/test/java/org/apache/hadoop/hbase/master/TestAssignmentManager.java Prcoess RIT on master restart can try assigning the region if the region is found on a dead server instead of waiting for Timeout Monitor - Key: HBASE-5882 URL: https://issues.apache.org/jira/browse/HBASE-5882 Project: HBase Issue Type: Improvement Affects Versions: 0.90.6, 0.92.1, 0.94.0 Reporter: ramkrishna.s.vasudevan Assignee: Ashutosh Jindal Fix For: 0.96.0, 0.94.1 Attachments: HBASE-5882_v5.patch, hbase_5882.patch, hbase_5882_V2.patch, hbase_5882_V3.patch, hbase_5882_V4.patch Currently on master restart if it tries to do processRIT, any region if found on dead server tries to avoid the nwe assignment so that timeout monitor can take care. This case is more prominent if the node is found in RS_ZK_REGION_OPENING state. I think we can handle this by triggering a new assignment with a new plan. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5970) Improve the AssignmentManager#updateTimer and speed up handling opened event
[ https://issues.apache.org/jira/browse/HBASE-5970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13279526#comment-13279526 ] chunhui shen commented on HBASE-5970: - bq.Why is doing this work in the background faster? Is it just that it being inline, it takes a noticeable amount of time? AssignmentManager#updateTimers would check each region in RIT, and there are lots of regions in the RIT when startup, so it will took much time(about 30ms if 100k regions in RIT). However, in the current logic, we will do the AssignmentManager#updateTimers for each opened event, causing the whole process of handling all the opened events tooks much much time. If we do the updateTimers in the background, we needn't wait it when handling opened event. Also, we wouldn't updateTimers for the same Regionserver in a short time.(In fact, when cluster startup , lots of opened events from the same regionserver at the same time, we needn't do this work many times at the moment) Improve the AssignmentManager#updateTimer and speed up handling opened event Key: HBASE-5970 URL: https://issues.apache.org/jira/browse/HBASE-5970 Project: HBase Issue Type: Improvement Components: master Reporter: chunhui shen Assignee: chunhui shen Attachments: 5970v3.patch, HBASE-5970.patch, HBASE-5970v2.patch, HBASE-5970v3.patch We found handing opened event very slow in the environment with lots of regions. The problem is the slow AssignmentManager#updateTimer. We do the test for bulk assigning 10w (i.e. 100k) regions, the whole process of bulk assigning took 1 hours. 2012-05-06 20:31:49,201 INFO org.apache.hadoop.hbase.master.AssignmentManager: Bulk assigning 10 region(s) round-robin across 5 server(s) 2012-05-06 21:26:32,103 INFO org.apache.hadoop.hbase.master.AssignmentManager: Bulk assigning done I think we could do the improvement for the AssignmentManager#updateTimer: Make a thread do this work. After the improvement, it took only 4.5mins 2012-05-07 11:03:36,581 INFO org.apache.hadoop.hbase.master.AssignmentManager: Bulk assigning 10 region(s) across 5 server(s), retainAssignment=true 2012-05-07 11:07:57,073 INFO org.apache.hadoop.hbase.master.AssignmentManager: Bulk assigning done -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5970) Improve the AssignmentManager#updateTimer and speed up handling opened event
[ https://issues.apache.org/jira/browse/HBASE-5970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13279531#comment-13279531 ] chunhui shen commented on HBASE-5970: - @stack bq.You are addressing this comment in updateTimers?{code}// This loop could be expensive.{code} I keep this loop, but greatly reduce the call times bq.Is this javadoc right? I'm not sure, could you give a suggestion. Thanks for the review Improve the AssignmentManager#updateTimer and speed up handling opened event Key: HBASE-5970 URL: https://issues.apache.org/jira/browse/HBASE-5970 Project: HBase Issue Type: Improvement Components: master Reporter: chunhui shen Assignee: chunhui shen Attachments: 5970v3.patch, HBASE-5970.patch, HBASE-5970v2.patch, HBASE-5970v3.patch We found handing opened event very slow in the environment with lots of regions. The problem is the slow AssignmentManager#updateTimer. We do the test for bulk assigning 10w (i.e. 100k) regions, the whole process of bulk assigning took 1 hours. 2012-05-06 20:31:49,201 INFO org.apache.hadoop.hbase.master.AssignmentManager: Bulk assigning 10 region(s) round-robin across 5 server(s) 2012-05-06 21:26:32,103 INFO org.apache.hadoop.hbase.master.AssignmentManager: Bulk assigning done I think we could do the improvement for the AssignmentManager#updateTimer: Make a thread do this work. After the improvement, it took only 4.5mins 2012-05-07 11:03:36,581 INFO org.apache.hadoop.hbase.master.AssignmentManager: Bulk assigning 10 region(s) across 5 server(s), retainAssignment=true 2012-05-07 11:07:57,073 INFO org.apache.hadoop.hbase.master.AssignmentManager: Bulk assigning done -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5882) Prcoess RIT on master restart can try assigning the region if the region is found on a dead server instead of waiting for Timeout Monitor
[ https://issues.apache.org/jira/browse/HBASE-5882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13279535#comment-13279535 ] ramkrishna.s.vasudevan commented on HBASE-5882: --- Currently reverted as TestAssignmentManager needs some clean up. Prcoess RIT on master restart can try assigning the region if the region is found on a dead server instead of waiting for Timeout Monitor - Key: HBASE-5882 URL: https://issues.apache.org/jira/browse/HBASE-5882 Project: HBase Issue Type: Improvement Affects Versions: 0.90.6, 0.92.1, 0.94.0 Reporter: ramkrishna.s.vasudevan Assignee: Ashutosh Jindal Fix For: 0.96.0, 0.94.1 Attachments: HBASE-5882_v5.patch, hbase_5882.patch, hbase_5882_V2.patch, hbase_5882_V3.patch, hbase_5882_V4.patch Currently on master restart if it tries to do processRIT, any region if found on dead server tries to avoid the nwe assignment so that timeout monitor can take care. This case is more prominent if the node is found in RS_ZK_REGION_OPENING state. I think we can handle this by triggering a new assignment with a new plan. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-6058) Use ZK 3.4 API 'multi' in bulk assignment
[ https://issues.apache.org/jira/browse/HBASE-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13279559#comment-13279559 ] Zhihong Yu commented on HBASE-6058: --- There hasn't been consensus as to which HBase version would require zk 3.4 as the minimum supported version. Use ZK 3.4 API 'multi' in bulk assignment - Key: HBASE-6058 URL: https://issues.apache.org/jira/browse/HBASE-6058 Project: HBase Issue Type: Improvement Components: master, zookeeper Affects Versions: 0.96.0 Reporter: nkeywal Assignee: nkeywal Priority: Minor We use async API today. This is already much much faster than the sync API. Still, it makes sense to use the 'multi' function: this will decrease the network zookeeper load at startup/rolling restart. On a 500 nodes cluster, we see 3 that 3 seconds are spent on updating ZK per bulk assignment. This should cut it in half (+ the benefits on the network/zk load). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-6050) HLogSplitter renaming recovered.edits and CJ removing the parent directory races, making the HBCK to think cluster is inconsistent.
[ https://issues.apache.org/jira/browse/HBASE-6050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-6050: -- Attachment: HBASE-6050.patch Trunk patch. Pls provide your comments. HLogSplitter renaming recovered.edits and CJ removing the parent directory races, making the HBCK to think cluster is inconsistent. --- Key: HBASE-6050 URL: https://issues.apache.org/jira/browse/HBASE-6050 Project: HBase Issue Type: Bug Reporter: ramkrishna.s.vasudevan Attachments: HBASE-6050.patch The scenario is like this - A region is getting splitted. - The master is still not processed the split . - Region server goes down. - Split log manager starts splitting the logs and creates the recovered.edits in the splitlog path. - CJ starts and deletes the entry from META and also just completes the deletion of the region dir. - in hlogSplitter on final step we rename the recovered.edits to come under the regiondir. There if the regiondir doesnot exist we tend to create and then add the recovered.edits. Because of this HBCK thinks it to be an orphan region because we have the regiondir but with no regioninfo. Ideally cluster is fine but we it is misleading. {code} } else { Path dstdir = dst.getParent(); if (!fs.exists(dstdir)) { if (!fs.mkdirs(dstdir)) LOG.warn(mkdir failed on + dstdir); } } fs.rename(src, dst); LOG.debug( moved + src + = + dst); } else { LOG.debug(Could not move recovered edits from + src + as it doesn't exist); } } archiveLogs(null, corruptedLogs, processedLogs, oldLogDir, fs, conf); {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-6050) HLogSplitter renaming recovered.edits and CJ removing the parent directory races, making the HBCK to think cluster is inconsistent.
[ https://issues.apache.org/jira/browse/HBASE-6050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-6050: -- Status: Patch Available (was: Open) HLogSplitter renaming recovered.edits and CJ removing the parent directory races, making the HBCK to think cluster is inconsistent. --- Key: HBASE-6050 URL: https://issues.apache.org/jira/browse/HBASE-6050 Project: HBase Issue Type: Bug Reporter: ramkrishna.s.vasudevan Attachments: HBASE-6050.patch The scenario is like this - A region is getting splitted. - The master is still not processed the split . - Region server goes down. - Split log manager starts splitting the logs and creates the recovered.edits in the splitlog path. - CJ starts and deletes the entry from META and also just completes the deletion of the region dir. - in hlogSplitter on final step we rename the recovered.edits to come under the regiondir. There if the regiondir doesnot exist we tend to create and then add the recovered.edits. Because of this HBCK thinks it to be an orphan region because we have the regiondir but with no regioninfo. Ideally cluster is fine but we it is misleading. {code} } else { Path dstdir = dst.getParent(); if (!fs.exists(dstdir)) { if (!fs.mkdirs(dstdir)) LOG.warn(mkdir failed on + dstdir); } } fs.rename(src, dst); LOG.debug( moved + src + = + dst); } else { LOG.debug(Could not move recovered edits from + src + as it doesn't exist); } } archiveLogs(null, corruptedLogs, processedLogs, oldLogDir, fs, conf); {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-6033) Adding some fuction to check if a table/region is in compaction
[ https://issues.apache.org/jira/browse/HBASE-6033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jimmy Xiang updated HBASE-6033: --- Attachment: table_ui.png Adding some fuction to check if a table/region is in compaction --- Key: HBASE-6033 URL: https://issues.apache.org/jira/browse/HBASE-6033 Project: HBase Issue Type: New Feature Reporter: Jimmy Xiang Assignee: Jimmy Xiang Attachments: table_ui.png This feature will be helpful to find out if a major compaction is going on. We can show if it is in any minor compaction too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-6050) HLogSplitter renaming recovered.edits and CJ removing the parent directory races, making the HBCK to think cluster is inconsistent.
[ https://issues.apache.org/jira/browse/HBASE-6050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13279590#comment-13279590 ] Hadoop QA commented on HBASE-6050: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12528231/HBASE-6050.patch 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 hadoop23. The patch compiles against the hadoop 0.23.x profile. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. -1 findbugs. The patch appears to introduce 33 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.replication.TestReplication org.apache.hadoop.hbase.replication.TestMultiSlaveReplication org.apache.hadoop.hbase.replication.TestMasterReplication Test results: https://builds.apache.org/job/PreCommit-HBASE-Build/1942//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/1942//artifact/trunk/patchprocess/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/1942//console This message is automatically generated. HLogSplitter renaming recovered.edits and CJ removing the parent directory races, making the HBCK to think cluster is inconsistent. --- Key: HBASE-6050 URL: https://issues.apache.org/jira/browse/HBASE-6050 Project: HBase Issue Type: Bug Reporter: ramkrishna.s.vasudevan Attachments: HBASE-6050.patch The scenario is like this - A region is getting splitted. - The master is still not processed the split . - Region server goes down. - Split log manager starts splitting the logs and creates the recovered.edits in the splitlog path. - CJ starts and deletes the entry from META and also just completes the deletion of the region dir. - in hlogSplitter on final step we rename the recovered.edits to come under the regiondir. There if the regiondir doesnot exist we tend to create and then add the recovered.edits. Because of this HBCK thinks it to be an orphan region because we have the regiondir but with no regioninfo. Ideally cluster is fine but we it is misleading. {code} } else { Path dstdir = dst.getParent(); if (!fs.exists(dstdir)) { if (!fs.mkdirs(dstdir)) LOG.warn(mkdir failed on + dstdir); } } fs.rename(src, dst); LOG.debug( moved + src + = + dst); } else { LOG.debug(Could not move recovered edits from + src + as it doesn't exist); } } archiveLogs(null, corruptedLogs, processedLogs, oldLogDir, fs, conf); {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-6050) HLogSplitter renaming recovered.edits and CJ removing the parent directory races, making the HBCK to think cluster is inconsistent.
[ https://issues.apache.org/jira/browse/HBASE-6050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13279592#comment-13279592 ] ramkrishna.s.vasudevan commented on HBASE-6050: --- Replication related testcases are failing in the previous few QA builds. So this patch has not introduced it. HLogSplitter renaming recovered.edits and CJ removing the parent directory races, making the HBCK to think cluster is inconsistent. --- Key: HBASE-6050 URL: https://issues.apache.org/jira/browse/HBASE-6050 Project: HBase Issue Type: Bug Reporter: ramkrishna.s.vasudevan Attachments: HBASE-6050.patch The scenario is like this - A region is getting splitted. - The master is still not processed the split . - Region server goes down. - Split log manager starts splitting the logs and creates the recovered.edits in the splitlog path. - CJ starts and deletes the entry from META and also just completes the deletion of the region dir. - in hlogSplitter on final step we rename the recovered.edits to come under the regiondir. There if the regiondir doesnot exist we tend to create and then add the recovered.edits. Because of this HBCK thinks it to be an orphan region because we have the regiondir but with no regioninfo. Ideally cluster is fine but we it is misleading. {code} } else { Path dstdir = dst.getParent(); if (!fs.exists(dstdir)) { if (!fs.mkdirs(dstdir)) LOG.warn(mkdir failed on + dstdir); } } fs.rename(src, dst); LOG.debug( moved + src + = + dst); } else { LOG.debug(Could not move recovered edits from + src + as it doesn't exist); } } archiveLogs(null, corruptedLogs, processedLogs, oldLogDir, fs, conf); {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] [Assigned] (HBASE-1749) If RS looses lease, we used to restart by default; reinstitute
[ https://issues.apache.org/jira/browse/HBASE-1749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack reassigned HBASE-1749: Assignee: nkeywal Haven't you done this N? If RS looses lease, we used to restart by default; reinstitute -- Key: HBASE-1749 URL: https://issues.apache.org/jira/browse/HBASE-1749 Project: HBase Issue Type: Bug Reporter: stack Assignee: nkeywal -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5882) Prcoess RIT on master restart can try assigning the region if the region is found on a dead server instead of waiting for Timeout Monitor
[ https://issues.apache.org/jira/browse/HBASE-5882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13279636#comment-13279636 ] Hudson commented on HBASE-5882: --- Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #12 (See [https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/12/]) HBASE-5882 (Revert) TestAssginmentManager needs some cleanup (Revision 1340422) Result = FAILURE ramkrishna : Files : * /hbase/trunk/src/main/java/org/apache/hadoop/hbase/master/AssignmentManager.java * /hbase/trunk/src/test/java/org/apache/hadoop/hbase/master/TestAssignmentManager.java Prcoess RIT on master restart can try assigning the region if the region is found on a dead server instead of waiting for Timeout Monitor - Key: HBASE-5882 URL: https://issues.apache.org/jira/browse/HBASE-5882 Project: HBase Issue Type: Improvement Affects Versions: 0.90.6, 0.92.1, 0.94.0 Reporter: ramkrishna.s.vasudevan Assignee: Ashutosh Jindal Fix For: 0.96.0, 0.94.1 Attachments: HBASE-5882_v5.patch, hbase_5882.patch, hbase_5882_V2.patch, hbase_5882_V3.patch, hbase_5882_V4.patch Currently on master restart if it tries to do processRIT, any region if found on dead server tries to avoid the nwe assignment so that timeout monitor can take care. This case is more prominent if the node is found in RS_ZK_REGION_OPENING state. I think we can handle this by triggering a new assignment with a new plan. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (HBASE-5453) Switch on-disk formats (reference files, HFile meta fields, etc) to PB
[ https://issues.apache.org/jira/browse/HBASE-5453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13279646#comment-13279646 ] Zhihong Yu edited comment on HBASE-5453 at 5/20/12 1:25 AM: Since integration of this JIRA, TestGetClosestAtOrBefore#testUsingMetaAndBinary has been failing since build #2902. Replication-related tests have been failing for Hadoop QA since build #1938. was (Author: zhi...@ebaysf.com): Since integration of this JIRA, TestGetClosestAtOrBefore#testUsingMetaAndBinary has been failing since build #2902. Replication-related tests have been failing since build #1938. Switch on-disk formats (reference files, HFile meta fields, etc) to PB -- Key: HBASE-5453 URL: https://issues.apache.org/jira/browse/HBASE-5453 Project: HBase Issue Type: Sub-task Components: ipc, master, migration, regionserver Reporter: Todd Lipcon Assignee: stack Fix For: 0.96.0 Attachments: 5453.txt, 5453v10.txt, 5453v11.txt, 5453v11.txt, 5453v12.txt, 5453v13.txt, 5453v2.txt, 5453v3.txt, 5453v6.txt, 5453v9.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-5699) Run with 1 WAL in HRegionServer
[ https://issues.apache.org/jira/browse/HBASE-5699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13279661#comment-13279661 ] Lars Hofhansl commented on HBASE-5699: -- I suspect this will become more important when people eventually turn on HBASE-5954 (durable sync, if they don't in data centers with backup power supplies). bq. There would be many regions in a cluster. They may not receive even write load. Is that necessarily a problem? Just saying that while we are exploring this, might as well explore this option as well. I for one be happy if a region's edits are tied to that region and log splitting could just go away (well almost, would still need to split if the region is split). Run with 1 WAL in HRegionServer - Key: HBASE-5699 URL: https://issues.apache.org/jira/browse/HBASE-5699 Project: HBase Issue Type: Improvement Reporter: binlijin Assignee: Li Pi -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5699) Run with 1 WAL in HRegionServer
[ https://issues.apache.org/jira/browse/HBASE-5699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13279667#comment-13279667 ] Todd Lipcon commented on HBASE-5699: I think with durable sync, having a WAL-per-region would be even less feasible than it is today -- we currently depend on batching in order to get good throughput. If a server has 50 regions, then you'd get 50x less batching opportunity and write throughput would grind to a halt. Imagine a fan-out write to all of the regions -- it would generate 50 disk seeks instead of just 1. Run with 1 WAL in HRegionServer - Key: HBASE-5699 URL: https://issues.apache.org/jira/browse/HBASE-5699 Project: HBase Issue Type: Improvement Reporter: binlijin Assignee: Li Pi -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira