[jira] [Updated] (HBASE-5584) Coprocessor hooks can be called in the respective handlers
[ https://issues.apache.org/jira/browse/HBASE-5584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-5584: -- Attachment: HBASE-5584_Security_addendum.patch Coprocessor hooks can be called in the respective handlers -- Key: HBASE-5584 URL: https://issues.apache.org/jira/browse/HBASE-5584 Project: HBase Issue Type: Improvement Components: coprocessors Reporter: ramkrishna.s.vasudevan Assignee: ramkrishna.s.vasudevan Fix For: 0.96.0 Attachments: HBASE-5584-1.patch, HBASE-5584-2.patch, HBASE-5584-3.patch, HBASE-5584.patch, HBASE-5584_Security_addendum.patch Following points can be changed w.r.t to coprocessors - Call preCreate, postCreate, preEnable, postEnable, etc. in their respective handlers - Currently it is called in the HMaster thus making the postApis async w.r.t the handlers - Similar is the case with the balancer. with current behaviour once we are in the postEnable(for eg) we any way need to wait for the main enable handler to be completed. We should ensure that we dont wait in the main thread so again we need to spawn a thread and wait on that. On the other hand if the pre and post api is called on the handlers then only that handler thread will be used in the pre/post apis If the above said plan is ok i can prepare a patch for all such related changes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5584) Coprocessor hooks can be called in the respective handlers
[ https://issues.apache.org/jira/browse/HBASE-5584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13269398#comment-13269398 ] ramkrishna.s.vasudevan commented on HBASE-5584: --- Update the addendum for SECURITY. Currently only dummy implementations have been given for the new apis as the existing preXXX and postXXX will do the actual validation of the operation like create, delete, etc. Let me know if it is ok so that i can commit it and make the SECURITY profile to compile? Coprocessor hooks can be called in the respective handlers -- Key: HBASE-5584 URL: https://issues.apache.org/jira/browse/HBASE-5584 Project: HBase Issue Type: Improvement Components: coprocessors Reporter: ramkrishna.s.vasudevan Assignee: ramkrishna.s.vasudevan Fix For: 0.96.0 Attachments: HBASE-5584-1.patch, HBASE-5584-2.patch, HBASE-5584-3.patch, HBASE-5584.patch, HBASE-5584_Security_addendum.patch Following points can be changed w.r.t to coprocessors - Call preCreate, postCreate, preEnable, postEnable, etc. in their respective handlers - Currently it is called in the HMaster thus making the postApis async w.r.t the handlers - Similar is the case with the balancer. with current behaviour once we are in the postEnable(for eg) we any way need to wait for the main enable handler to be completed. We should ensure that we dont wait in the main thread so again we need to spawn a thread and wait on that. On the other hand if the pre and post api is called on the handlers then only that handler thread will be used in the pre/post apis If the above said plan is ok i can prepare a patch for all such related changes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5949) We needn't add splitParent region to assignment map when rebuildUserRegions
chunhui shen created HBASE-5949: --- Summary: We needn't add splitParent region to assignment map when rebuildUserRegions Key: HBASE-5949 URL: https://issues.apache.org/jira/browse/HBASE-5949 Project: HBase Issue Type: Bug Components: master Reporter: chunhui shen Assignee: chunhui shen In current AssignmentManager#rebuildUserRegions, we will add splitParent region to assignment map. When doing balance, the splitParent region will be always in RIT because no server is carrying 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-5949) We needn't add splitParent region to assignment map when rebuildUserRegions
[ https://issues.apache.org/jira/browse/HBASE-5949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] chunhui shen updated HBASE-5949: Attachment: HBASE-5949.patch We needn't add splitParent region to assignment map when rebuildUserRegions --- Key: HBASE-5949 URL: https://issues.apache.org/jira/browse/HBASE-5949 Project: HBase Issue Type: Bug Components: master Reporter: chunhui shen Assignee: chunhui shen Attachments: HBASE-5949.patch In current AssignmentManager#rebuildUserRegions, we will add splitParent region to assignment map. When doing balance, the splitParent region will be always in RIT because no server is carrying 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-5949) We needn't add splitParent region to assignment map when rebuildUserRegions
[ https://issues.apache.org/jira/browse/HBASE-5949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13269453#comment-13269453 ] ramkrishna.s.vasudevan commented on HBASE-5949: --- @Chunhui Can you check HBASE-5806? I think both are addressing the same. We have added some testcase also for it. It will be uploaded today. You can take a look at it. We needn't add splitParent region to assignment map when rebuildUserRegions --- Key: HBASE-5949 URL: https://issues.apache.org/jira/browse/HBASE-5949 Project: HBase Issue Type: Bug Components: master Reporter: chunhui shen Assignee: chunhui shen Attachments: HBASE-5949.patch In current AssignmentManager#rebuildUserRegions, we will add splitParent region to assignment map. When doing balance, the splitParent region will be always in RIT because no server is carrying 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-5828) TestLogRolling fails in 0.90 branch killing the test suite up on jenkins
[ https://issues.apache.org/jira/browse/HBASE-5828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13269543#comment-13269543 ] xufeng commented on HBASE-5828: --- I just review the code and have a speculation about this issue: If the region of META table assigned on regionserver_A. The region of user table assigned on regionserver_B. At first,the pipeline of regionserver_A and regionserver_B have the same datanodes. The testcase testLogRollOnDatanodeDeath will kill the all datanodes in pipeline which belongs to the hlog writer of regionserver_B. When the testcase testLogRollOnPipelineRestart to deleteTale,it will update the META data. Because the datanodes in pipeline of regionserver_A have been stoped,So it will fail. Test will wait in HBaseAdmin#deletaTable() until retries exhausted. After long time this test will be killed. TestLogRolling fails in 0.90 branch killing the test suite up on jenkins Key: HBASE-5828 URL: https://issues.apache.org/jira/browse/HBASE-5828 Project: HBase Issue Type: Bug Reporter: stack See recent 0.90 builds up on jenkins: https://builds.apache.org/view/G-L/view/HBase/job/hbase-0.90/471/console -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5883) Backup master is going down due to connection refused exception
[ https://issues.apache.org/jira/browse/HBASE-5883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jieshan Bean updated HBASE-5883: Attachment: (was: HBASE-5883-90-addendum.patch) Backup master is going down due to connection refused exception --- Key: HBASE-5883 URL: https://issues.apache.org/jira/browse/HBASE-5883 Project: HBase Issue Type: Bug Components: master Affects Versions: 0.90.6, 0.92.1, 0.94.0 Reporter: Gopinathan A Assignee: Jieshan Bean Fix For: 0.96.0, 0.94.1 Attachments: HBASE-5883-90.patch, HBASE-5883-92.patch, HBASE-5883-94.patch, HBASE-5883-trunk.patch, trunk-addendum.patch The active master node network was down for some time (This node contains Master,DN,ZK,RS). Here backup node got notification, and started to became active. Immedietly backup node got aborted with the below exception. {noformat} 2012-04-09 10:42:24,270 INFO org.apache.hadoop.hbase.master.SplitLogManager: finished splitting (more than or equal to) 861248320 bytes in 4 log files in [hdfs://192.168.47.205:9000/hbase/.logs/HOST-192-168-47-202,60020,1333715537172-splitting] in 26374ms 2012-04-09 10:42:24,316 FATAL org.apache.hadoop.hbase.master.HMaster: Master server abort: loaded coprocessors are: [] 2012-04-09 10:42:24,333 FATAL org.apache.hadoop.hbase.master.HMaster: Unhandled exception. Starting shutdown. java.io.IOException: java.net.ConnectException: Connection refused at org.apache.hadoop.hbase.ipc.HBaseClient$Connection.setupIOstreams(HBaseClient.java:375) at org.apache.hadoop.hbase.ipc.HBaseClient.getConnection(HBaseClient.java:1045) at org.apache.hadoop.hbase.ipc.HBaseClient.call(HBaseClient.java:897) at org.apache.hadoop.hbase.ipc.WritableRpcEngine$Invoker.invoke(WritableRpcEngine.java:150) at $Proxy13.getProtocolVersion(Unknown Source) at org.apache.hadoop.hbase.ipc.WritableRpcEngine.getProxy(WritableRpcEngine.java:183) at org.apache.hadoop.hbase.ipc.HBaseRPC.getProxy(HBaseRPC.java:303) at org.apache.hadoop.hbase.ipc.HBaseRPC.getProxy(HBaseRPC.java:280) at org.apache.hadoop.hbase.ipc.HBaseRPC.getProxy(HBaseRPC.java:332) at org.apache.hadoop.hbase.ipc.HBaseRPC.waitForProxy(HBaseRPC.java:236) at org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getHRegionConnection(HConnectionManager.java:1276) at org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getHRegionConnection(HConnectionManager.java:1233) at org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getHRegionConnection(HConnectionManager.java:1220) at org.apache.hadoop.hbase.catalog.CatalogTracker.getCachedConnection(CatalogTracker.java:569) at org.apache.hadoop.hbase.catalog.CatalogTracker.getRootServerConnection(CatalogTracker.java:369) at org.apache.hadoop.hbase.catalog.CatalogTracker.waitForRootServerConnection(CatalogTracker.java:353) at org.apache.hadoop.hbase.catalog.CatalogTracker.verifyRootRegionLocation(CatalogTracker.java:660) at org.apache.hadoop.hbase.master.HMaster.assignRootAndMeta(HMaster.java:616) at org.apache.hadoop.hbase.master.HMaster.finishInitialization(HMaster.java:540) at org.apache.hadoop.hbase.master.HMaster.run(HMaster.java:363) at java.lang.Thread.run(Thread.java:662) Caused by: java.net.ConnectException: Connection refused at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:567) at org.apache.hadoop.net.SocketIOWithTimeout.connect(SocketIOWithTimeout.java:206) at org.apache.hadoop.net.NetUtils.connect(NetUtils.java:488) at org.apache.hadoop.hbase.ipc.HBaseClient$Connection.setupConnection(HBaseClient.java:328) at org.apache.hadoop.hbase.ipc.HBaseClient$Connection.setupIOstreams(HBaseClient.java:362) ... 20 more 2012-04-09 10:42:24,336 INFO org.apache.hadoop.hbase.master.HMaster: Aborting 2012-04-09 10:42:24,336 DEBUG org.apache.hadoop.hbase.master.HMaster: Stopping service threads {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5883) Backup master is going down due to connection refused exception
[ https://issues.apache.org/jira/browse/HBASE-5883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jieshan Bean updated HBASE-5883: Attachment: (was: HBASE-5883-94-addendum.patch) Backup master is going down due to connection refused exception --- Key: HBASE-5883 URL: https://issues.apache.org/jira/browse/HBASE-5883 Project: HBase Issue Type: Bug Components: master Affects Versions: 0.90.6, 0.92.1, 0.94.0 Reporter: Gopinathan A Assignee: Jieshan Bean Fix For: 0.96.0, 0.94.1 Attachments: HBASE-5883-90.patch, HBASE-5883-92.patch, HBASE-5883-94.patch, HBASE-5883-trunk.patch, trunk-addendum.patch The active master node network was down for some time (This node contains Master,DN,ZK,RS). Here backup node got notification, and started to became active. Immedietly backup node got aborted with the below exception. {noformat} 2012-04-09 10:42:24,270 INFO org.apache.hadoop.hbase.master.SplitLogManager: finished splitting (more than or equal to) 861248320 bytes in 4 log files in [hdfs://192.168.47.205:9000/hbase/.logs/HOST-192-168-47-202,60020,1333715537172-splitting] in 26374ms 2012-04-09 10:42:24,316 FATAL org.apache.hadoop.hbase.master.HMaster: Master server abort: loaded coprocessors are: [] 2012-04-09 10:42:24,333 FATAL org.apache.hadoop.hbase.master.HMaster: Unhandled exception. Starting shutdown. java.io.IOException: java.net.ConnectException: Connection refused at org.apache.hadoop.hbase.ipc.HBaseClient$Connection.setupIOstreams(HBaseClient.java:375) at org.apache.hadoop.hbase.ipc.HBaseClient.getConnection(HBaseClient.java:1045) at org.apache.hadoop.hbase.ipc.HBaseClient.call(HBaseClient.java:897) at org.apache.hadoop.hbase.ipc.WritableRpcEngine$Invoker.invoke(WritableRpcEngine.java:150) at $Proxy13.getProtocolVersion(Unknown Source) at org.apache.hadoop.hbase.ipc.WritableRpcEngine.getProxy(WritableRpcEngine.java:183) at org.apache.hadoop.hbase.ipc.HBaseRPC.getProxy(HBaseRPC.java:303) at org.apache.hadoop.hbase.ipc.HBaseRPC.getProxy(HBaseRPC.java:280) at org.apache.hadoop.hbase.ipc.HBaseRPC.getProxy(HBaseRPC.java:332) at org.apache.hadoop.hbase.ipc.HBaseRPC.waitForProxy(HBaseRPC.java:236) at org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getHRegionConnection(HConnectionManager.java:1276) at org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getHRegionConnection(HConnectionManager.java:1233) at org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getHRegionConnection(HConnectionManager.java:1220) at org.apache.hadoop.hbase.catalog.CatalogTracker.getCachedConnection(CatalogTracker.java:569) at org.apache.hadoop.hbase.catalog.CatalogTracker.getRootServerConnection(CatalogTracker.java:369) at org.apache.hadoop.hbase.catalog.CatalogTracker.waitForRootServerConnection(CatalogTracker.java:353) at org.apache.hadoop.hbase.catalog.CatalogTracker.verifyRootRegionLocation(CatalogTracker.java:660) at org.apache.hadoop.hbase.master.HMaster.assignRootAndMeta(HMaster.java:616) at org.apache.hadoop.hbase.master.HMaster.finishInitialization(HMaster.java:540) at org.apache.hadoop.hbase.master.HMaster.run(HMaster.java:363) at java.lang.Thread.run(Thread.java:662) Caused by: java.net.ConnectException: Connection refused at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:567) at org.apache.hadoop.net.SocketIOWithTimeout.connect(SocketIOWithTimeout.java:206) at org.apache.hadoop.net.NetUtils.connect(NetUtils.java:488) at org.apache.hadoop.hbase.ipc.HBaseClient$Connection.setupConnection(HBaseClient.java:328) at org.apache.hadoop.hbase.ipc.HBaseClient$Connection.setupIOstreams(HBaseClient.java:362) ... 20 more 2012-04-09 10:42:24,336 INFO org.apache.hadoop.hbase.master.HMaster: Aborting 2012-04-09 10:42:24,336 DEBUG org.apache.hadoop.hbase.master.HMaster: Stopping service threads {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5883) Backup master is going down due to connection refused exception
[ https://issues.apache.org/jira/browse/HBASE-5883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jieshan Bean updated HBASE-5883: Attachment: (was: HBASE-5883-trunk-addendum.patch) Backup master is going down due to connection refused exception --- Key: HBASE-5883 URL: https://issues.apache.org/jira/browse/HBASE-5883 Project: HBase Issue Type: Bug Components: master Affects Versions: 0.90.6, 0.92.1, 0.94.0 Reporter: Gopinathan A Assignee: Jieshan Bean Fix For: 0.96.0, 0.94.1 Attachments: HBASE-5883-90.patch, HBASE-5883-92.patch, HBASE-5883-94.patch, HBASE-5883-trunk.patch, trunk-addendum.patch The active master node network was down for some time (This node contains Master,DN,ZK,RS). Here backup node got notification, and started to became active. Immedietly backup node got aborted with the below exception. {noformat} 2012-04-09 10:42:24,270 INFO org.apache.hadoop.hbase.master.SplitLogManager: finished splitting (more than or equal to) 861248320 bytes in 4 log files in [hdfs://192.168.47.205:9000/hbase/.logs/HOST-192-168-47-202,60020,1333715537172-splitting] in 26374ms 2012-04-09 10:42:24,316 FATAL org.apache.hadoop.hbase.master.HMaster: Master server abort: loaded coprocessors are: [] 2012-04-09 10:42:24,333 FATAL org.apache.hadoop.hbase.master.HMaster: Unhandled exception. Starting shutdown. java.io.IOException: java.net.ConnectException: Connection refused at org.apache.hadoop.hbase.ipc.HBaseClient$Connection.setupIOstreams(HBaseClient.java:375) at org.apache.hadoop.hbase.ipc.HBaseClient.getConnection(HBaseClient.java:1045) at org.apache.hadoop.hbase.ipc.HBaseClient.call(HBaseClient.java:897) at org.apache.hadoop.hbase.ipc.WritableRpcEngine$Invoker.invoke(WritableRpcEngine.java:150) at $Proxy13.getProtocolVersion(Unknown Source) at org.apache.hadoop.hbase.ipc.WritableRpcEngine.getProxy(WritableRpcEngine.java:183) at org.apache.hadoop.hbase.ipc.HBaseRPC.getProxy(HBaseRPC.java:303) at org.apache.hadoop.hbase.ipc.HBaseRPC.getProxy(HBaseRPC.java:280) at org.apache.hadoop.hbase.ipc.HBaseRPC.getProxy(HBaseRPC.java:332) at org.apache.hadoop.hbase.ipc.HBaseRPC.waitForProxy(HBaseRPC.java:236) at org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getHRegionConnection(HConnectionManager.java:1276) at org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getHRegionConnection(HConnectionManager.java:1233) at org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getHRegionConnection(HConnectionManager.java:1220) at org.apache.hadoop.hbase.catalog.CatalogTracker.getCachedConnection(CatalogTracker.java:569) at org.apache.hadoop.hbase.catalog.CatalogTracker.getRootServerConnection(CatalogTracker.java:369) at org.apache.hadoop.hbase.catalog.CatalogTracker.waitForRootServerConnection(CatalogTracker.java:353) at org.apache.hadoop.hbase.catalog.CatalogTracker.verifyRootRegionLocation(CatalogTracker.java:660) at org.apache.hadoop.hbase.master.HMaster.assignRootAndMeta(HMaster.java:616) at org.apache.hadoop.hbase.master.HMaster.finishInitialization(HMaster.java:540) at org.apache.hadoop.hbase.master.HMaster.run(HMaster.java:363) at java.lang.Thread.run(Thread.java:662) Caused by: java.net.ConnectException: Connection refused at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:567) at org.apache.hadoop.net.SocketIOWithTimeout.connect(SocketIOWithTimeout.java:206) at org.apache.hadoop.net.NetUtils.connect(NetUtils.java:488) at org.apache.hadoop.hbase.ipc.HBaseClient$Connection.setupConnection(HBaseClient.java:328) at org.apache.hadoop.hbase.ipc.HBaseClient$Connection.setupIOstreams(HBaseClient.java:362) ... 20 more 2012-04-09 10:42:24,336 INFO org.apache.hadoop.hbase.master.HMaster: Aborting 2012-04-09 10:42:24,336 DEBUG org.apache.hadoop.hbase.master.HMaster: Stopping service threads {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5883) Backup master is going down due to connection refused exception
[ https://issues.apache.org/jira/browse/HBASE-5883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jieshan Bean updated HBASE-5883: Attachment: (was: HBASE-5883-92-addendum.patch) Backup master is going down due to connection refused exception --- Key: HBASE-5883 URL: https://issues.apache.org/jira/browse/HBASE-5883 Project: HBase Issue Type: Bug Components: master Affects Versions: 0.90.6, 0.92.1, 0.94.0 Reporter: Gopinathan A Assignee: Jieshan Bean Fix For: 0.96.0, 0.94.1 Attachments: HBASE-5883-90.patch, HBASE-5883-92.patch, HBASE-5883-94.patch, HBASE-5883-trunk.patch, trunk-addendum.patch The active master node network was down for some time (This node contains Master,DN,ZK,RS). Here backup node got notification, and started to became active. Immedietly backup node got aborted with the below exception. {noformat} 2012-04-09 10:42:24,270 INFO org.apache.hadoop.hbase.master.SplitLogManager: finished splitting (more than or equal to) 861248320 bytes in 4 log files in [hdfs://192.168.47.205:9000/hbase/.logs/HOST-192-168-47-202,60020,1333715537172-splitting] in 26374ms 2012-04-09 10:42:24,316 FATAL org.apache.hadoop.hbase.master.HMaster: Master server abort: loaded coprocessors are: [] 2012-04-09 10:42:24,333 FATAL org.apache.hadoop.hbase.master.HMaster: Unhandled exception. Starting shutdown. java.io.IOException: java.net.ConnectException: Connection refused at org.apache.hadoop.hbase.ipc.HBaseClient$Connection.setupIOstreams(HBaseClient.java:375) at org.apache.hadoop.hbase.ipc.HBaseClient.getConnection(HBaseClient.java:1045) at org.apache.hadoop.hbase.ipc.HBaseClient.call(HBaseClient.java:897) at org.apache.hadoop.hbase.ipc.WritableRpcEngine$Invoker.invoke(WritableRpcEngine.java:150) at $Proxy13.getProtocolVersion(Unknown Source) at org.apache.hadoop.hbase.ipc.WritableRpcEngine.getProxy(WritableRpcEngine.java:183) at org.apache.hadoop.hbase.ipc.HBaseRPC.getProxy(HBaseRPC.java:303) at org.apache.hadoop.hbase.ipc.HBaseRPC.getProxy(HBaseRPC.java:280) at org.apache.hadoop.hbase.ipc.HBaseRPC.getProxy(HBaseRPC.java:332) at org.apache.hadoop.hbase.ipc.HBaseRPC.waitForProxy(HBaseRPC.java:236) at org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getHRegionConnection(HConnectionManager.java:1276) at org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getHRegionConnection(HConnectionManager.java:1233) at org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getHRegionConnection(HConnectionManager.java:1220) at org.apache.hadoop.hbase.catalog.CatalogTracker.getCachedConnection(CatalogTracker.java:569) at org.apache.hadoop.hbase.catalog.CatalogTracker.getRootServerConnection(CatalogTracker.java:369) at org.apache.hadoop.hbase.catalog.CatalogTracker.waitForRootServerConnection(CatalogTracker.java:353) at org.apache.hadoop.hbase.catalog.CatalogTracker.verifyRootRegionLocation(CatalogTracker.java:660) at org.apache.hadoop.hbase.master.HMaster.assignRootAndMeta(HMaster.java:616) at org.apache.hadoop.hbase.master.HMaster.finishInitialization(HMaster.java:540) at org.apache.hadoop.hbase.master.HMaster.run(HMaster.java:363) at java.lang.Thread.run(Thread.java:662) Caused by: java.net.ConnectException: Connection refused at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:567) at org.apache.hadoop.net.SocketIOWithTimeout.connect(SocketIOWithTimeout.java:206) at org.apache.hadoop.net.NetUtils.connect(NetUtils.java:488) at org.apache.hadoop.hbase.ipc.HBaseClient$Connection.setupConnection(HBaseClient.java:328) at org.apache.hadoop.hbase.ipc.HBaseClient$Connection.setupIOstreams(HBaseClient.java:362) ... 20 more 2012-04-09 10:42:24,336 INFO org.apache.hadoop.hbase.master.HMaster: Aborting 2012-04-09 10:42:24,336 DEBUG org.apache.hadoop.hbase.master.HMaster: Stopping service threads {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5883) Backup master is going down due to connection refused exception
[ https://issues.apache.org/jira/browse/HBASE-5883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jieshan Bean updated HBASE-5883: Attachment: trunk-addendum.patch Backup master is going down due to connection refused exception --- Key: HBASE-5883 URL: https://issues.apache.org/jira/browse/HBASE-5883 Project: HBase Issue Type: Bug Components: master Affects Versions: 0.90.6, 0.92.1, 0.94.0 Reporter: Gopinathan A Assignee: Jieshan Bean Fix For: 0.96.0, 0.94.1 Attachments: HBASE-5883-90.patch, HBASE-5883-92.patch, HBASE-5883-94.patch, HBASE-5883-trunk.patch, trunk-addendum.patch The active master node network was down for some time (This node contains Master,DN,ZK,RS). Here backup node got notification, and started to became active. Immedietly backup node got aborted with the below exception. {noformat} 2012-04-09 10:42:24,270 INFO org.apache.hadoop.hbase.master.SplitLogManager: finished splitting (more than or equal to) 861248320 bytes in 4 log files in [hdfs://192.168.47.205:9000/hbase/.logs/HOST-192-168-47-202,60020,1333715537172-splitting] in 26374ms 2012-04-09 10:42:24,316 FATAL org.apache.hadoop.hbase.master.HMaster: Master server abort: loaded coprocessors are: [] 2012-04-09 10:42:24,333 FATAL org.apache.hadoop.hbase.master.HMaster: Unhandled exception. Starting shutdown. java.io.IOException: java.net.ConnectException: Connection refused at org.apache.hadoop.hbase.ipc.HBaseClient$Connection.setupIOstreams(HBaseClient.java:375) at org.apache.hadoop.hbase.ipc.HBaseClient.getConnection(HBaseClient.java:1045) at org.apache.hadoop.hbase.ipc.HBaseClient.call(HBaseClient.java:897) at org.apache.hadoop.hbase.ipc.WritableRpcEngine$Invoker.invoke(WritableRpcEngine.java:150) at $Proxy13.getProtocolVersion(Unknown Source) at org.apache.hadoop.hbase.ipc.WritableRpcEngine.getProxy(WritableRpcEngine.java:183) at org.apache.hadoop.hbase.ipc.HBaseRPC.getProxy(HBaseRPC.java:303) at org.apache.hadoop.hbase.ipc.HBaseRPC.getProxy(HBaseRPC.java:280) at org.apache.hadoop.hbase.ipc.HBaseRPC.getProxy(HBaseRPC.java:332) at org.apache.hadoop.hbase.ipc.HBaseRPC.waitForProxy(HBaseRPC.java:236) at org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getHRegionConnection(HConnectionManager.java:1276) at org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getHRegionConnection(HConnectionManager.java:1233) at org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getHRegionConnection(HConnectionManager.java:1220) at org.apache.hadoop.hbase.catalog.CatalogTracker.getCachedConnection(CatalogTracker.java:569) at org.apache.hadoop.hbase.catalog.CatalogTracker.getRootServerConnection(CatalogTracker.java:369) at org.apache.hadoop.hbase.catalog.CatalogTracker.waitForRootServerConnection(CatalogTracker.java:353) at org.apache.hadoop.hbase.catalog.CatalogTracker.verifyRootRegionLocation(CatalogTracker.java:660) at org.apache.hadoop.hbase.master.HMaster.assignRootAndMeta(HMaster.java:616) at org.apache.hadoop.hbase.master.HMaster.finishInitialization(HMaster.java:540) at org.apache.hadoop.hbase.master.HMaster.run(HMaster.java:363) at java.lang.Thread.run(Thread.java:662) Caused by: java.net.ConnectException: Connection refused at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:567) at org.apache.hadoop.net.SocketIOWithTimeout.connect(SocketIOWithTimeout.java:206) at org.apache.hadoop.net.NetUtils.connect(NetUtils.java:488) at org.apache.hadoop.hbase.ipc.HBaseClient$Connection.setupConnection(HBaseClient.java:328) at org.apache.hadoop.hbase.ipc.HBaseClient$Connection.setupIOstreams(HBaseClient.java:362) ... 20 more 2012-04-09 10:42:24,336 INFO org.apache.hadoop.hbase.master.HMaster: Aborting 2012-04-09 10:42:24,336 DEBUG org.apache.hadoop.hbase.master.HMaster: Stopping service threads {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5950) Add a decimal comparator for Filter
Jieshan Bean created HBASE-5950: --- Summary: Add a decimal comparator for Filter Key: HBASE-5950 URL: https://issues.apache.org/jira/browse/HBASE-5950 Project: HBase Issue Type: New Feature Components: filters Affects Versions: 0.94.0, 0.96.0 Reporter: Jieshan Bean Suppose we have a requirement like below: we want to get the rows with one specified column value larger than A and less than B. (They are all decimals or integers) namely: A Integer.valueof(column) B Use BinaryComparator will not help us to archive that goal: e.g. suppose A = 100, B = 200, one column value is 11. So it can satisfy that condition, but it's not the row we wanted. So I suggest to add one comparator to help implementing 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-5883) Backup master is going down due to connection refused exception
[ https://issues.apache.org/jira/browse/HBASE-5883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13269583#comment-13269583 ] Hadoop QA commented on HBASE-5883: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12525833/trunk-addendum.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 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.TestDrainingServer Test results: https://builds.apache.org/job/PreCommit-HBASE-Build/1785//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/1785//artifact/trunk/patchprocess/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/1785//console This message is automatically generated. Backup master is going down due to connection refused exception --- Key: HBASE-5883 URL: https://issues.apache.org/jira/browse/HBASE-5883 Project: HBase Issue Type: Bug Components: master Affects Versions: 0.90.6, 0.92.1, 0.94.0 Reporter: Gopinathan A Assignee: Jieshan Bean Fix For: 0.96.0, 0.94.1 Attachments: HBASE-5883-90.patch, HBASE-5883-92.patch, HBASE-5883-94.patch, HBASE-5883-trunk.patch, trunk-addendum.patch The active master node network was down for some time (This node contains Master,DN,ZK,RS). Here backup node got notification, and started to became active. Immedietly backup node got aborted with the below exception. {noformat} 2012-04-09 10:42:24,270 INFO org.apache.hadoop.hbase.master.SplitLogManager: finished splitting (more than or equal to) 861248320 bytes in 4 log files in [hdfs://192.168.47.205:9000/hbase/.logs/HOST-192-168-47-202,60020,1333715537172-splitting] in 26374ms 2012-04-09 10:42:24,316 FATAL org.apache.hadoop.hbase.master.HMaster: Master server abort: loaded coprocessors are: [] 2012-04-09 10:42:24,333 FATAL org.apache.hadoop.hbase.master.HMaster: Unhandled exception. Starting shutdown. java.io.IOException: java.net.ConnectException: Connection refused at org.apache.hadoop.hbase.ipc.HBaseClient$Connection.setupIOstreams(HBaseClient.java:375) at org.apache.hadoop.hbase.ipc.HBaseClient.getConnection(HBaseClient.java:1045) at org.apache.hadoop.hbase.ipc.HBaseClient.call(HBaseClient.java:897) at org.apache.hadoop.hbase.ipc.WritableRpcEngine$Invoker.invoke(WritableRpcEngine.java:150) at $Proxy13.getProtocolVersion(Unknown Source) at org.apache.hadoop.hbase.ipc.WritableRpcEngine.getProxy(WritableRpcEngine.java:183) at org.apache.hadoop.hbase.ipc.HBaseRPC.getProxy(HBaseRPC.java:303) at org.apache.hadoop.hbase.ipc.HBaseRPC.getProxy(HBaseRPC.java:280) at org.apache.hadoop.hbase.ipc.HBaseRPC.getProxy(HBaseRPC.java:332) at org.apache.hadoop.hbase.ipc.HBaseRPC.waitForProxy(HBaseRPC.java:236) at org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getHRegionConnection(HConnectionManager.java:1276) at org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getHRegionConnection(HConnectionManager.java:1233) at org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getHRegionConnection(HConnectionManager.java:1220) at org.apache.hadoop.hbase.catalog.CatalogTracker.getCachedConnection(CatalogTracker.java:569) at org.apache.hadoop.hbase.catalog.CatalogTracker.getRootServerConnection(CatalogTracker.java:369) at org.apache.hadoop.hbase.catalog.CatalogTracker.waitForRootServerConnection(CatalogTracker.java:353) at org.apache.hadoop.hbase.catalog.CatalogTracker.verifyRootRegionLocation(CatalogTracker.java:660) at org.apache.hadoop.hbase.master.HMaster.assignRootAndMeta(HMaster.java:616) at org.apache.hadoop.hbase.master.HMaster.finishInitialization(HMaster.java:540) at
[jira] [Updated] (HBASE-5883) Backup master is going down due to connection refused exception
[ https://issues.apache.org/jira/browse/HBASE-5883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jieshan Bean updated HBASE-5883: Attachment: 94-addendum.patch 92-addendum.patch 90-addendum.patch Backup master is going down due to connection refused exception --- Key: HBASE-5883 URL: https://issues.apache.org/jira/browse/HBASE-5883 Project: HBase Issue Type: Bug Components: master Affects Versions: 0.90.6, 0.92.1, 0.94.0 Reporter: Gopinathan A Assignee: Jieshan Bean Fix For: 0.96.0, 0.94.1 Attachments: 90-addendum.patch, 92-addendum.patch, 94-addendum.patch, HBASE-5883-90.patch, HBASE-5883-92.patch, HBASE-5883-94.patch, HBASE-5883-trunk.patch, trunk-addendum.patch The active master node network was down for some time (This node contains Master,DN,ZK,RS). Here backup node got notification, and started to became active. Immedietly backup node got aborted with the below exception. {noformat} 2012-04-09 10:42:24,270 INFO org.apache.hadoop.hbase.master.SplitLogManager: finished splitting (more than or equal to) 861248320 bytes in 4 log files in [hdfs://192.168.47.205:9000/hbase/.logs/HOST-192-168-47-202,60020,1333715537172-splitting] in 26374ms 2012-04-09 10:42:24,316 FATAL org.apache.hadoop.hbase.master.HMaster: Master server abort: loaded coprocessors are: [] 2012-04-09 10:42:24,333 FATAL org.apache.hadoop.hbase.master.HMaster: Unhandled exception. Starting shutdown. java.io.IOException: java.net.ConnectException: Connection refused at org.apache.hadoop.hbase.ipc.HBaseClient$Connection.setupIOstreams(HBaseClient.java:375) at org.apache.hadoop.hbase.ipc.HBaseClient.getConnection(HBaseClient.java:1045) at org.apache.hadoop.hbase.ipc.HBaseClient.call(HBaseClient.java:897) at org.apache.hadoop.hbase.ipc.WritableRpcEngine$Invoker.invoke(WritableRpcEngine.java:150) at $Proxy13.getProtocolVersion(Unknown Source) at org.apache.hadoop.hbase.ipc.WritableRpcEngine.getProxy(WritableRpcEngine.java:183) at org.apache.hadoop.hbase.ipc.HBaseRPC.getProxy(HBaseRPC.java:303) at org.apache.hadoop.hbase.ipc.HBaseRPC.getProxy(HBaseRPC.java:280) at org.apache.hadoop.hbase.ipc.HBaseRPC.getProxy(HBaseRPC.java:332) at org.apache.hadoop.hbase.ipc.HBaseRPC.waitForProxy(HBaseRPC.java:236) at org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getHRegionConnection(HConnectionManager.java:1276) at org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getHRegionConnection(HConnectionManager.java:1233) at org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getHRegionConnection(HConnectionManager.java:1220) at org.apache.hadoop.hbase.catalog.CatalogTracker.getCachedConnection(CatalogTracker.java:569) at org.apache.hadoop.hbase.catalog.CatalogTracker.getRootServerConnection(CatalogTracker.java:369) at org.apache.hadoop.hbase.catalog.CatalogTracker.waitForRootServerConnection(CatalogTracker.java:353) at org.apache.hadoop.hbase.catalog.CatalogTracker.verifyRootRegionLocation(CatalogTracker.java:660) at org.apache.hadoop.hbase.master.HMaster.assignRootAndMeta(HMaster.java:616) at org.apache.hadoop.hbase.master.HMaster.finishInitialization(HMaster.java:540) at org.apache.hadoop.hbase.master.HMaster.run(HMaster.java:363) at java.lang.Thread.run(Thread.java:662) Caused by: java.net.ConnectException: Connection refused at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:567) at org.apache.hadoop.net.SocketIOWithTimeout.connect(SocketIOWithTimeout.java:206) at org.apache.hadoop.net.NetUtils.connect(NetUtils.java:488) at org.apache.hadoop.hbase.ipc.HBaseClient$Connection.setupConnection(HBaseClient.java:328) at org.apache.hadoop.hbase.ipc.HBaseClient$Connection.setupIOstreams(HBaseClient.java:362) ... 20 more 2012-04-09 10:42:24,336 INFO org.apache.hadoop.hbase.master.HMaster: Aborting 2012-04-09 10:42:24,336 DEBUG org.apache.hadoop.hbase.master.HMaster: Stopping service threads {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5654) [findbugs] Address dodgy bugs
[ https://issues.apache.org/jira/browse/HBASE-5654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13269634#comment-13269634 ] ramkrishna.s.vasudevan commented on HBASE-5654: --- Default should not throw illegal argument exception in processRIT on master failover in trunk. Found it when a test case was written for HBASE-5806. [findbugs] Address dodgy bugs - Key: HBASE-5654 URL: https://issues.apache.org/jira/browse/HBASE-5654 Project: HBase Issue Type: Sub-task Components: scripts Affects Versions: 0.96.0 Reporter: Jonathan Hsieh Assignee: Ashutosh Jindal Labels: patch Fix For: 0.96.0 Attachments: Hbase 5654_v3.patch, Hbase-5654.patch, Hbase_5654_V2.patch, hbase-5654-tweak.patch, hbase-5654_v5.patch See https://builds.apache.org/job/PreCommit-HBASE-Build/1313//artifact/trunk/patchprocess/newPatchFindbugsWarnings.html#Warnings_STYLE This may be broken down further. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5654) [findbugs] Address dodgy bugs
[ https://issues.apache.org/jira/browse/HBASE-5654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13269640#comment-13269640 ] ramkrishna.s.vasudevan commented on HBASE-5654: --- Because RS_ZK_REGION_SPLIT and RS_ZK_REGION_SPLITTING will not be handled in processRIT. I think in that case we can just say break in default. [findbugs] Address dodgy bugs - Key: HBASE-5654 URL: https://issues.apache.org/jira/browse/HBASE-5654 Project: HBase Issue Type: Sub-task Components: scripts Affects Versions: 0.96.0 Reporter: Jonathan Hsieh Assignee: Ashutosh Jindal Labels: patch Fix For: 0.96.0 Attachments: Hbase 5654_v3.patch, Hbase-5654.patch, Hbase_5654_V2.patch, hbase-5654-tweak.patch, hbase-5654_v5.patch See https://builds.apache.org/job/PreCommit-HBASE-Build/1313//artifact/trunk/patchprocess/newPatchFindbugsWarnings.html#Warnings_STYLE This may be broken down further. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5951) Combining ColumnPrefixFilters using filterlist.
Davis Abraham created HBASE-5951: Summary: Combining ColumnPrefixFilters using filterlist. Key: HBASE-5951 URL: https://issues.apache.org/jira/browse/HBASE-5951 Project: HBase Issue Type: Bug Components: filters Affects Versions: 0.92.1 Environment: Combining multiple ColumnPrefixFilters using filterlist does not return exact result. Reporter: Davis Abraham FilterList listOfFilters = new FilterList (FilterList.Operator.MUST_PASS_ALL); FilterList listOfFilters1 = new FilterList (FilterList.Operator.MUST_PASS_ALL); FilterList listOfFilters2 = new FilterList (FilterList.Operator.MUST_PASS_ALL); SingleColumnValueFilter SingleFilter1 = new SingleColumnValueFilter(Bytes.toBytes(cf), Bytes.toBytes(country), CompareOp.EQUAL, Bytes.toBytes(USA)); listOfFilters.addFilter(SingleFilter1); ValueFilter VF1= new ValueFilter (CompareOp.EQUAL, new SubstringComparator(ABC)); ColumnPrefixFilter CF1= new ColumnPrefixFilter(Bytes.toBytes(name)); listOfFilters1.addFilter(CF1); listOfFilters1.addFilter(VF1); listOfFilters.addFilter(listOfFilters1); ValueFilter VF2= new ValueFilter (CompareOp.EQUAL, new SubstringComparator(ED)); ColumnPrefixFilter CF2= new ColumnPrefixFilter (Bytes.toBytes(CRS)); listOfFilters2.addFilter(CF2); listOfFilters2.addFilter(VF2); listOfFilters.addFilter(listOfFilters2); When i do a combibation of SingleFilter1 and listOfFilters1 the result is correct, same way the combination of SingleFilter1 and listOfFilters2 is returing correct result. But when all the three is combined im not getting any result.. Is it the problem with multiple ColumnPrefixFilter??? Value ABC exist in name.0 and value ED exist in CRS.0 and it is in the same row under same Column Family. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5883) Backup master is going down due to connection refused exception
[ https://issues.apache.org/jira/browse/HBASE-5883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13269664#comment-13269664 ] Hadoop QA commented on HBASE-5883: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12525851/94-addendum.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 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: Test results: https://builds.apache.org/job/PreCommit-HBASE-Build/1786//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/1786//artifact/trunk/patchprocess/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/1786//console This message is automatically generated. Backup master is going down due to connection refused exception --- Key: HBASE-5883 URL: https://issues.apache.org/jira/browse/HBASE-5883 Project: HBase Issue Type: Bug Components: master Affects Versions: 0.90.6, 0.92.1, 0.94.0 Reporter: Gopinathan A Assignee: Jieshan Bean Fix For: 0.96.0, 0.94.1 Attachments: 90-addendum.patch, 92-addendum.patch, 94-addendum.patch, HBASE-5883-90.patch, HBASE-5883-92.patch, HBASE-5883-94.patch, HBASE-5883-trunk.patch, trunk-addendum.patch The active master node network was down for some time (This node contains Master,DN,ZK,RS). Here backup node got notification, and started to became active. Immedietly backup node got aborted with the below exception. {noformat} 2012-04-09 10:42:24,270 INFO org.apache.hadoop.hbase.master.SplitLogManager: finished splitting (more than or equal to) 861248320 bytes in 4 log files in [hdfs://192.168.47.205:9000/hbase/.logs/HOST-192-168-47-202,60020,1333715537172-splitting] in 26374ms 2012-04-09 10:42:24,316 FATAL org.apache.hadoop.hbase.master.HMaster: Master server abort: loaded coprocessors are: [] 2012-04-09 10:42:24,333 FATAL org.apache.hadoop.hbase.master.HMaster: Unhandled exception. Starting shutdown. java.io.IOException: java.net.ConnectException: Connection refused at org.apache.hadoop.hbase.ipc.HBaseClient$Connection.setupIOstreams(HBaseClient.java:375) at org.apache.hadoop.hbase.ipc.HBaseClient.getConnection(HBaseClient.java:1045) at org.apache.hadoop.hbase.ipc.HBaseClient.call(HBaseClient.java:897) at org.apache.hadoop.hbase.ipc.WritableRpcEngine$Invoker.invoke(WritableRpcEngine.java:150) at $Proxy13.getProtocolVersion(Unknown Source) at org.apache.hadoop.hbase.ipc.WritableRpcEngine.getProxy(WritableRpcEngine.java:183) at org.apache.hadoop.hbase.ipc.HBaseRPC.getProxy(HBaseRPC.java:303) at org.apache.hadoop.hbase.ipc.HBaseRPC.getProxy(HBaseRPC.java:280) at org.apache.hadoop.hbase.ipc.HBaseRPC.getProxy(HBaseRPC.java:332) at org.apache.hadoop.hbase.ipc.HBaseRPC.waitForProxy(HBaseRPC.java:236) at org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getHRegionConnection(HConnectionManager.java:1276) at org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getHRegionConnection(HConnectionManager.java:1233) at org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getHRegionConnection(HConnectionManager.java:1220) at org.apache.hadoop.hbase.catalog.CatalogTracker.getCachedConnection(CatalogTracker.java:569) at org.apache.hadoop.hbase.catalog.CatalogTracker.getRootServerConnection(CatalogTracker.java:369) at org.apache.hadoop.hbase.catalog.CatalogTracker.waitForRootServerConnection(CatalogTracker.java:353) at org.apache.hadoop.hbase.catalog.CatalogTracker.verifyRootRegionLocation(CatalogTracker.java:660) at org.apache.hadoop.hbase.master.HMaster.assignRootAndMeta(HMaster.java:616) at org.apache.hadoop.hbase.master.HMaster.finishInitialization(HMaster.java:540) at
[jira] [Updated] (HBASE-5806) Handle split region related failures on master restart and RS restart
[ https://issues.apache.org/jira/browse/HBASE-5806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chinna Rao Lalam updated HBASE-5806: Attachment: HBASE-5806_trunk.patch HBASE-5806_0.94.patch Handle split region related failures on master restart and RS restart - Key: HBASE-5806 URL: https://issues.apache.org/jira/browse/HBASE-5806 Project: HBase Issue Type: Bug Affects Versions: 0.92.1 Reporter: ramkrishna.s.vasudevan Assignee: Chinna Rao Lalam Fix For: 0.92.2, 0.96.0, 0.94.1 Attachments: HBASE-5806.patch, HBASE-5806_0.94.patch, HBASE-5806_trunk.patch This issue is raised to solve issues that comes out of partial region split happened and the region node in the ZK which is in RS_ZK_REGION_SPLITTING and RS_ZK_REGION_SPLIT is not yet processed. This also tries to address HBASE-5615. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5806) Handle split region related failures on master restart and RS restart
[ https://issues.apache.org/jira/browse/HBASE-5806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13269707#comment-13269707 ] Chinna Rao Lalam commented on HBASE-5806: - Updated the patch with testcases. In trunk patch added this change in AssignmentManager.java to address the HBASE-5654 issue {code} default: -throw new IllegalStateException(Received event is not valid.); +break; } {code} Handle split region related failures on master restart and RS restart - Key: HBASE-5806 URL: https://issues.apache.org/jira/browse/HBASE-5806 Project: HBase Issue Type: Bug Affects Versions: 0.92.1 Reporter: ramkrishna.s.vasudevan Assignee: Chinna Rao Lalam Fix For: 0.92.2, 0.96.0, 0.94.1 Attachments: HBASE-5806.patch, HBASE-5806_0.94.patch, HBASE-5806_trunk.patch This issue is raised to solve issues that comes out of partial region split happened and the region node in the ZK which is in RS_ZK_REGION_SPLITTING and RS_ZK_REGION_SPLIT is not yet processed. This also tries to address HBASE-5615. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5806) Handle split region related failures on master restart and RS restart
[ https://issues.apache.org/jira/browse/HBASE-5806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chinna Rao Lalam updated HBASE-5806: Status: Patch Available (was: Open) Handle split region related failures on master restart and RS restart - Key: HBASE-5806 URL: https://issues.apache.org/jira/browse/HBASE-5806 Project: HBase Issue Type: Bug Affects Versions: 0.92.1 Reporter: ramkrishna.s.vasudevan Assignee: Chinna Rao Lalam Fix For: 0.92.2, 0.96.0, 0.94.1 Attachments: HBASE-5806.patch, HBASE-5806_0.94.patch, HBASE-5806_trunk.patch This issue is raised to solve issues that comes out of partial region split happened and the region node in the ZK which is in RS_ZK_REGION_SPLITTING and RS_ZK_REGION_SPLIT is not yet processed. This also tries to address HBASE-5615. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5806) Handle split region related failures on master restart and RS restart
[ https://issues.apache.org/jira/browse/HBASE-5806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13269709#comment-13269709 ] Chinna Rao Lalam commented on HBASE-5806: - Updated patch for 0.94 trunk. Handle split region related failures on master restart and RS restart - Key: HBASE-5806 URL: https://issues.apache.org/jira/browse/HBASE-5806 Project: HBase Issue Type: Bug Affects Versions: 0.92.1 Reporter: ramkrishna.s.vasudevan Assignee: Chinna Rao Lalam Fix For: 0.92.2, 0.96.0, 0.94.1 Attachments: HBASE-5806.patch, HBASE-5806_0.94.patch, HBASE-5806_trunk.patch This issue is raised to solve issues that comes out of partial region split happened and the region node in the ZK which is in RS_ZK_REGION_SPLITTING and RS_ZK_REGION_SPLIT is not yet processed. This also tries to address HBASE-5615. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5945) Reduce buffer copies in IPC server response path
[ https://issues.apache.org/jira/browse/HBASE-5945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13269722#comment-13269722 ] stack commented on HBASE-5945: -- /me hearts todd Reduce buffer copies in IPC server response path Key: HBASE-5945 URL: https://issues.apache.org/jira/browse/HBASE-5945 Project: HBase Issue Type: Improvement Components: ipc Affects Versions: 0.96.0 Reporter: Todd Lipcon Assignee: Todd Lipcon Priority: Critical Attachments: buffer-copies.txt, even-fewer-copies.txt, hbase-5495.txt The new PB code is sloppy with buffers and makes several needless copies. This increases GC time a lot. A few simple changes can cut this back down. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5806) Handle split region related failures on master restart and RS restart
[ https://issues.apache.org/jira/browse/HBASE-5806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13269742#comment-13269742 ] Zhihong Yu commented on HBASE-5806: --- Overall, patch looks good. {code} default: -throw new IllegalStateException(Received event is not valid.); +break; {code} Should the event be logged in the default case ? {code} + // If Znode not exists dont consider this region + if (data == null) { {code} 'not exists' - 'does not exist' {code} + public static class MockedMaster extends HMaster { {code} I think the class should be private. A better name would be MockMasterWithoutCatalogJanitor. Handle split region related failures on master restart and RS restart - Key: HBASE-5806 URL: https://issues.apache.org/jira/browse/HBASE-5806 Project: HBase Issue Type: Bug Affects Versions: 0.92.1 Reporter: ramkrishna.s.vasudevan Assignee: Chinna Rao Lalam Fix For: 0.92.2, 0.96.0, 0.94.1 Attachments: HBASE-5806.patch, HBASE-5806_0.94.patch, HBASE-5806_trunk.patch This issue is raised to solve issues that comes out of partial region split happened and the region node in the ZK which is in RS_ZK_REGION_SPLITTING and RS_ZK_REGION_SPLIT is not yet processed. This also tries to address HBASE-5615. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5806) Handle split region related failures on master restart and RS restart
[ https://issues.apache.org/jira/browse/HBASE-5806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13269746#comment-13269746 ] ramkrishna.s.vasudevan commented on HBASE-5806: --- {code} default: -throw new IllegalStateException(Received event is not valid.); +break; {code} Good that this testcase brought it out. {code} + public static class MockedMaster extends HMaster { {code} It has to be public otherwise the LocalHBaseCluster does not allow us to update the HMaster class. Handle split region related failures on master restart and RS restart - Key: HBASE-5806 URL: https://issues.apache.org/jira/browse/HBASE-5806 Project: HBase Issue Type: Bug Affects Versions: 0.92.1 Reporter: ramkrishna.s.vasudevan Assignee: Chinna Rao Lalam Fix For: 0.92.2, 0.96.0, 0.94.1 Attachments: HBASE-5806.patch, HBASE-5806_0.94.patch, HBASE-5806_trunk.patch This issue is raised to solve issues that comes out of partial region split happened and the region node in the ZK which is in RS_ZK_REGION_SPLITTING and RS_ZK_REGION_SPLIT is not yet processed. This also tries to address HBASE-5615. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5916) RS restart just before master intialization we make the cluster non operative
[ https://issues.apache.org/jira/browse/HBASE-5916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-5916: -- Attachment: HBASE-5916_trunk_2.patch Reattaching. Patch is getting applied cleanly. May be because of same name the QA did not pick it up. Please provide your comments on the latest patch. RS restart just before master intialization we make the cluster non operative - Key: HBASE-5916 URL: https://issues.apache.org/jira/browse/HBASE-5916 Project: HBase Issue Type: Bug Affects Versions: 0.92.1, 0.94.0 Reporter: ramkrishna.s.vasudevan Assignee: ramkrishna.s.vasudevan Priority: Critical Fix For: 0.94.1 Attachments: HBASE-5916_trunk.patch, HBASE-5916_trunk_1.patch, HBASE-5916_trunk_1.patch, HBASE-5916_trunk_2.patch Consider a case where my master is getting restarted. RS that was alive when the master restart started, gets restarted before the master initializes the ServerShutDownHandler. {code} serverShutdownHandlerEnabled = true; {code} In this case when the RS tries to register with the master, the master will try to expire the server but the server cannot be expired as still the serverShutdownHandler is not enabled. This case may happen when i have only one RS gets restarted or all the RS gets restarted at the same time.(before assignRootandMeta). {code} LOG.info(message); if (existingServer.getStartcode() serverName.getStartcode()) { LOG.info(Triggering server recovery; existingServer + existingServer + looks stale, new server: + serverName); expireServer(existingServer); } {code} If another RS is brought up then the cluster comes back to normalcy. May be a very corner case. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5916) RS restart just before master intialization we make the cluster non operative
[ https://issues.apache.org/jira/browse/HBASE-5916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-5916: -- Status: Open (was: Patch Available) RS restart just before master intialization we make the cluster non operative - Key: HBASE-5916 URL: https://issues.apache.org/jira/browse/HBASE-5916 Project: HBase Issue Type: Bug Affects Versions: 0.92.1, 0.94.0 Reporter: ramkrishna.s.vasudevan Assignee: ramkrishna.s.vasudevan Priority: Critical Fix For: 0.94.1 Attachments: HBASE-5916_trunk.patch, HBASE-5916_trunk_1.patch, HBASE-5916_trunk_1.patch, HBASE-5916_trunk_2.patch Consider a case where my master is getting restarted. RS that was alive when the master restart started, gets restarted before the master initializes the ServerShutDownHandler. {code} serverShutdownHandlerEnabled = true; {code} In this case when the RS tries to register with the master, the master will try to expire the server but the server cannot be expired as still the serverShutdownHandler is not enabled. This case may happen when i have only one RS gets restarted or all the RS gets restarted at the same time.(before assignRootandMeta). {code} LOG.info(message); if (existingServer.getStartcode() serverName.getStartcode()) { LOG.info(Triggering server recovery; existingServer + existingServer + looks stale, new server: + serverName); expireServer(existingServer); } {code} If another RS is brought up then the cluster comes back to normalcy. May be a very corner case. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5916) RS restart just before master intialization we make the cluster non operative
[ https://issues.apache.org/jira/browse/HBASE-5916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-5916: -- Status: Patch Available (was: Open) RS restart just before master intialization we make the cluster non operative - Key: HBASE-5916 URL: https://issues.apache.org/jira/browse/HBASE-5916 Project: HBase Issue Type: Bug Affects Versions: 0.92.1, 0.94.0 Reporter: ramkrishna.s.vasudevan Assignee: ramkrishna.s.vasudevan Priority: Critical Fix For: 0.94.1 Attachments: HBASE-5916_trunk.patch, HBASE-5916_trunk_1.patch, HBASE-5916_trunk_1.patch, HBASE-5916_trunk_2.patch Consider a case where my master is getting restarted. RS that was alive when the master restart started, gets restarted before the master initializes the ServerShutDownHandler. {code} serverShutdownHandlerEnabled = true; {code} In this case when the RS tries to register with the master, the master will try to expire the server but the server cannot be expired as still the serverShutdownHandler is not enabled. This case may happen when i have only one RS gets restarted or all the RS gets restarted at the same time.(before assignRootandMeta). {code} LOG.info(message); if (existingServer.getStartcode() serverName.getStartcode()) { LOG.info(Triggering server recovery; existingServer + existingServer + looks stale, new server: + serverName); expireServer(existingServer); } {code} If another RS is brought up then the cluster comes back to normalcy. May be a very corner case. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5916) RS restart just before master intialization we make the cluster non operative
[ https://issues.apache.org/jira/browse/HBASE-5916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13269752#comment-13269752 ] Hadoop QA commented on HBASE-5916: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12525870/HBASE-5916_trunk_2.patch against trunk revision . +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 6 new or modified tests. -1 patch. The patch command could not apply the patch. Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/1788//console This message is automatically generated. RS restart just before master intialization we make the cluster non operative - Key: HBASE-5916 URL: https://issues.apache.org/jira/browse/HBASE-5916 Project: HBase Issue Type: Bug Affects Versions: 0.92.1, 0.94.0 Reporter: ramkrishna.s.vasudevan Assignee: ramkrishna.s.vasudevan Priority: Critical Fix For: 0.94.1 Attachments: HBASE-5916_trunk.patch, HBASE-5916_trunk_1.patch, HBASE-5916_trunk_1.patch, HBASE-5916_trunk_2.patch Consider a case where my master is getting restarted. RS that was alive when the master restart started, gets restarted before the master initializes the ServerShutDownHandler. {code} serverShutdownHandlerEnabled = true; {code} In this case when the RS tries to register with the master, the master will try to expire the server but the server cannot be expired as still the serverShutdownHandler is not enabled. This case may happen when i have only one RS gets restarted or all the RS gets restarted at the same time.(before assignRootandMeta). {code} LOG.info(message); if (existingServer.getStartcode() serverName.getStartcode()) { LOG.info(Triggering server recovery; existingServer + existingServer + looks stale, new server: + serverName); expireServer(existingServer); } {code} If another RS is brought up then the cluster comes back to normalcy. May be a very corner case. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5806) Handle split region related failures on master restart and RS restart
[ https://issues.apache.org/jira/browse/HBASE-5806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13269759#comment-13269759 ] Hadoop QA commented on HBASE-5806: -- +1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12525862/HBASE-5806_trunk.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 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 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 passed unit tests in . Test results: https://builds.apache.org/job/PreCommit-HBASE-Build/1787//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/1787//artifact/trunk/patchprocess/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/1787//console This message is automatically generated. Handle split region related failures on master restart and RS restart - Key: HBASE-5806 URL: https://issues.apache.org/jira/browse/HBASE-5806 Project: HBase Issue Type: Bug Affects Versions: 0.92.1 Reporter: ramkrishna.s.vasudevan Assignee: Chinna Rao Lalam Fix For: 0.92.2, 0.96.0, 0.94.1 Attachments: HBASE-5806.patch, HBASE-5806_0.94.patch, HBASE-5806_trunk.patch This issue is raised to solve issues that comes out of partial region split happened and the region node in the ZK which is in RS_ZK_REGION_SPLITTING and RS_ZK_REGION_SPLIT is not yet processed. This also tries to address HBASE-5615. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5916) RS restart just before master intialization we make the cluster non operative
[ https://issues.apache.org/jira/browse/HBASE-5916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13269766#comment-13269766 ] Zhihong Yu commented on HBASE-5916: --- There is some conflict in TestMasterFailover.java which patch command couldn't resolve: {code} *** *** 38,43 import org.apache.hadoop.hbase.*; import org.apache.hadoop.hbase.executor.EventHandler.EventType; import org.apache.hadoop.hbase.master.AssignmentManager.RegionState; import org.apache.hadoop.hbase.regionserver.HRegion; import org.apache.hadoop.hbase.regionserver.HRegionServer; import org.apache.hadoop.hbase.util.Bytes; --- 39,45 import org.apache.hadoop.hbase.*; import org.apache.hadoop.hbase.executor.EventHandler.EventType; import org.apache.hadoop.hbase.master.AssignmentManager.RegionState; + import org.apache.hadoop.hbase.master.metrics.MasterMetrics; import org.apache.hadoop.hbase.regionserver.HRegion; import org.apache.hadoop.hbase.regionserver.HRegionServer; import org.apache.hadoop.hbase.util.Bytes; {code} RS restart just before master intialization we make the cluster non operative - Key: HBASE-5916 URL: https://issues.apache.org/jira/browse/HBASE-5916 Project: HBase Issue Type: Bug Affects Versions: 0.92.1, 0.94.0 Reporter: ramkrishna.s.vasudevan Assignee: ramkrishna.s.vasudevan Priority: Critical Fix For: 0.94.1 Attachments: HBASE-5916_trunk.patch, HBASE-5916_trunk_1.patch, HBASE-5916_trunk_1.patch, HBASE-5916_trunk_2.patch Consider a case where my master is getting restarted. RS that was alive when the master restart started, gets restarted before the master initializes the ServerShutDownHandler. {code} serverShutdownHandlerEnabled = true; {code} In this case when the RS tries to register with the master, the master will try to expire the server but the server cannot be expired as still the serverShutdownHandler is not enabled. This case may happen when i have only one RS gets restarted or all the RS gets restarted at the same time.(before assignRootandMeta). {code} LOG.info(message); if (existingServer.getStartcode() serverName.getStartcode()) { LOG.info(Triggering server recovery; existingServer + existingServer + looks stale, new server: + serverName); expireServer(existingServer); } {code} If another RS is brought up then the cluster comes back to normalcy. May be a very corner case. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5875) Process RIT and Master restart may remove an online server considering it as a dead server
[ https://issues.apache.org/jira/browse/HBASE-5875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-5875: -- Attachment: HBASE-5875_0.94_1.patch Process RIT and Master restart may remove an online server considering it as a dead server -- Key: HBASE-5875 URL: https://issues.apache.org/jira/browse/HBASE-5875 Project: HBase Issue Type: Bug Affects Versions: 0.92.1 Reporter: ramkrishna.s.vasudevan Assignee: ramkrishna.s.vasudevan Fix For: 0.94.1 Attachments: HBASE-5875.patch, HBASE-5875_0.94.patch, HBASE-5875_0.94_1.patch If on master restart it finds the ROOT/META to be in RIT state, master tries to assign the ROOT region through ProcessRIT. Master will trigger the assignment and next will try to verify the Root Region Location. Root region location verification is done seeing if the RS has the region in its online list. If the master triggered assignment has not yet been completed in RS then the verify root region location will fail. Because it failed {code} splitLogAndExpireIfOnline(currentRootServer); {code} we do split log and also remove the server from online server list. Ideally here there is nothing to do in splitlog as no region server was restarted. So master, though the server is online, master just invalidates the region server. In a special case, if i have only one RS then my cluster will become non operative. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5875) Process RIT and Master restart may remove an online server considering it as a dead server
[ https://issues.apache.org/jira/browse/HBASE-5875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-5875: -- Status: Open (was: Patch Available) Process RIT and Master restart may remove an online server considering it as a dead server -- Key: HBASE-5875 URL: https://issues.apache.org/jira/browse/HBASE-5875 Project: HBase Issue Type: Bug Affects Versions: 0.92.1 Reporter: ramkrishna.s.vasudevan Assignee: ramkrishna.s.vasudevan Fix For: 0.94.1 Attachments: HBASE-5875.patch, HBASE-5875_0.94.patch, HBASE-5875_0.94_1.patch If on master restart it finds the ROOT/META to be in RIT state, master tries to assign the ROOT region through ProcessRIT. Master will trigger the assignment and next will try to verify the Root Region Location. Root region location verification is done seeing if the RS has the region in its online list. If the master triggered assignment has not yet been completed in RS then the verify root region location will fail. Because it failed {code} splitLogAndExpireIfOnline(currentRootServer); {code} we do split log and also remove the server from online server list. Ideally here there is nothing to do in splitlog as no region server was restarted. So master, though the server is online, master just invalidates the region server. In a special case, if i have only one RS then my cluster will become non operative. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5875) Process RIT and Master restart may remove an online server considering it as a dead server
[ https://issues.apache.org/jira/browse/HBASE-5875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13269779#comment-13269779 ] ramkrishna.s.vasudevan commented on HBASE-5875: --- I have addressed the third comment in the recent patch. {code} LOG.info(Failed verification of + Bytes.toStringBinary(regionName) + + at address= + address + ; + t); {code} This log is same as the one below it. It is an existing one. {code} if(rit == true){ {code} Here rit means region in transition and it applies to META also if it is in RIT. So i think changing this name will not make it generic. Again, this is a patch for 0.94 Process RIT and Master restart may remove an online server considering it as a dead server -- Key: HBASE-5875 URL: https://issues.apache.org/jira/browse/HBASE-5875 Project: HBase Issue Type: Bug Affects Versions: 0.92.1 Reporter: ramkrishna.s.vasudevan Assignee: ramkrishna.s.vasudevan Fix For: 0.94.1 Attachments: HBASE-5875.patch, HBASE-5875_0.94.patch, HBASE-5875_0.94_1.patch If on master restart it finds the ROOT/META to be in RIT state, master tries to assign the ROOT region through ProcessRIT. Master will trigger the assignment and next will try to verify the Root Region Location. Root region location verification is done seeing if the RS has the region in its online list. If the master triggered assignment has not yet been completed in RS then the verify root region location will fail. Because it failed {code} splitLogAndExpireIfOnline(currentRootServer); {code} we do split log and also remove the server from online server list. Ideally here there is nothing to do in splitlog as no region server was restarted. So master, though the server is online, master just invalidates the region server. In a special case, if i have only one RS then my cluster will become non operative. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5916) RS restart just before master intialization we make the cluster non operative
[ https://issues.apache.org/jira/browse/HBASE-5916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-5916: -- Status: Open (was: Patch Available) RS restart just before master intialization we make the cluster non operative - Key: HBASE-5916 URL: https://issues.apache.org/jira/browse/HBASE-5916 Project: HBase Issue Type: Bug Affects Versions: 0.92.1, 0.94.0 Reporter: ramkrishna.s.vasudevan Assignee: ramkrishna.s.vasudevan Priority: Critical Fix For: 0.94.1 Attachments: HBASE-5916_trunk.patch, HBASE-5916_trunk_1.patch, HBASE-5916_trunk_1.patch, HBASE-5916_trunk_2.patch Consider a case where my master is getting restarted. RS that was alive when the master restart started, gets restarted before the master initializes the ServerShutDownHandler. {code} serverShutdownHandlerEnabled = true; {code} In this case when the RS tries to register with the master, the master will try to expire the server but the server cannot be expired as still the serverShutdownHandler is not enabled. This case may happen when i have only one RS gets restarted or all the RS gets restarted at the same time.(before assignRootandMeta). {code} LOG.info(message); if (existingServer.getStartcode() serverName.getStartcode()) { LOG.info(Triggering server recovery; existingServer + existingServer + looks stale, new server: + serverName); expireServer(existingServer); } {code} If another RS is brought up then the cluster comes back to normalcy. May be a very corner case. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5916) RS restart just before master intialization we make the cluster non operative
[ https://issues.apache.org/jira/browse/HBASE-5916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-5916: -- Status: Patch Available (was: Open) RS restart just before master intialization we make the cluster non operative - Key: HBASE-5916 URL: https://issues.apache.org/jira/browse/HBASE-5916 Project: HBase Issue Type: Bug Affects Versions: 0.92.1, 0.94.0 Reporter: ramkrishna.s.vasudevan Assignee: ramkrishna.s.vasudevan Priority: Critical Fix For: 0.94.1 Attachments: HBASE-5916_trunk.patch, HBASE-5916_trunk_1.patch, HBASE-5916_trunk_1.patch, HBASE-5916_trunk_2.patch, HBASE-5916_trunk_3.patch Consider a case where my master is getting restarted. RS that was alive when the master restart started, gets restarted before the master initializes the ServerShutDownHandler. {code} serverShutdownHandlerEnabled = true; {code} In this case when the RS tries to register with the master, the master will try to expire the server but the server cannot be expired as still the serverShutdownHandler is not enabled. This case may happen when i have only one RS gets restarted or all the RS gets restarted at the same time.(before assignRootandMeta). {code} LOG.info(message); if (existingServer.getStartcode() serverName.getStartcode()) { LOG.info(Triggering server recovery; existingServer + existingServer + looks stale, new server: + serverName); expireServer(existingServer); } {code} If another RS is brought up then the cluster comes back to normalcy. May be a very corner case. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5916) RS restart just before master intialization we make the cluster non operative
[ https://issues.apache.org/jira/browse/HBASE-5916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-5916: -- Attachment: HBASE-5916_trunk_3.patch The patch still applies correctly in Windows thro SVN client. But finally its because there is an empty line in the line number 33. Tried out in the apache linux machine. {code} Patching file src/test/java/org/apache/hadoop/hbase/master/TestMasterFailover.java using Plan A... Hunk #1 succeeded at 23. Hunk #2 succeeded at 37. Hunk #3 succeeded at 52. Hunk #4 succeeded at 137. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: {code} This time it should run. RS restart just before master intialization we make the cluster non operative - Key: HBASE-5916 URL: https://issues.apache.org/jira/browse/HBASE-5916 Project: HBase Issue Type: Bug Affects Versions: 0.92.1, 0.94.0 Reporter: ramkrishna.s.vasudevan Assignee: ramkrishna.s.vasudevan Priority: Critical Fix For: 0.94.1 Attachments: HBASE-5916_trunk.patch, HBASE-5916_trunk_1.patch, HBASE-5916_trunk_1.patch, HBASE-5916_trunk_2.patch, HBASE-5916_trunk_3.patch Consider a case where my master is getting restarted. RS that was alive when the master restart started, gets restarted before the master initializes the ServerShutDownHandler. {code} serverShutdownHandlerEnabled = true; {code} In this case when the RS tries to register with the master, the master will try to expire the server but the server cannot be expired as still the serverShutdownHandler is not enabled. This case may happen when i have only one RS gets restarted or all the RS gets restarted at the same time.(before assignRootandMeta). {code} LOG.info(message); if (existingServer.getStartcode() serverName.getStartcode()) { LOG.info(Triggering server recovery; existingServer + existingServer + looks stale, new server: + serverName); expireServer(existingServer); } {code} If another RS is brought up then the cluster comes back to normalcy. May be a very corner case. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5584) Coprocessor hooks can be called in the respective handlers
[ https://issues.apache.org/jira/browse/HBASE-5584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13269797#comment-13269797 ] ramkrishna.s.vasudevan commented on HBASE-5584: --- Could some one review this? Needs to be committed so that SECURITY compiles? Coprocessor hooks can be called in the respective handlers -- Key: HBASE-5584 URL: https://issues.apache.org/jira/browse/HBASE-5584 Project: HBase Issue Type: Improvement Components: coprocessors Reporter: ramkrishna.s.vasudevan Assignee: ramkrishna.s.vasudevan Fix For: 0.96.0 Attachments: HBASE-5584-1.patch, HBASE-5584-2.patch, HBASE-5584-3.patch, HBASE-5584.patch, HBASE-5584_Security_addendum.patch Following points can be changed w.r.t to coprocessors - Call preCreate, postCreate, preEnable, postEnable, etc. in their respective handlers - Currently it is called in the HMaster thus making the postApis async w.r.t the handlers - Similar is the case with the balancer. with current behaviour once we are in the postEnable(for eg) we any way need to wait for the main enable handler to be completed. We should ensure that we dont wait in the main thread so again we need to spawn a thread and wait on that. On the other hand if the pre and post api is called on the handlers then only that handler thread will be used in the pre/post apis If the above said plan is ok i can prepare a patch for all such related changes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5806) Handle split region related failures on master restart and RS restart
[ https://issues.apache.org/jira/browse/HBASE-5806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chinna Rao Lalam updated HBASE-5806: Attachment: HBASE-5806_trunk_1.patch HBASE-5806_0.94_1.patch Handle split region related failures on master restart and RS restart - Key: HBASE-5806 URL: https://issues.apache.org/jira/browse/HBASE-5806 Project: HBase Issue Type: Bug Affects Versions: 0.92.1 Reporter: ramkrishna.s.vasudevan Assignee: Chinna Rao Lalam Fix For: 0.92.2, 0.96.0, 0.94.1 Attachments: HBASE-5806.patch, HBASE-5806_0.94.patch, HBASE-5806_0.94_1.patch, HBASE-5806_trunk.patch, HBASE-5806_trunk_1.patch This issue is raised to solve issues that comes out of partial region split happened and the region node in the ZK which is in RS_ZK_REGION_SPLITTING and RS_ZK_REGION_SPLIT is not yet processed. This also tries to address HBASE-5615. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5904) is_enabled from shell returns differently from pre- and post- HBASE-5155
[ https://issues.apache.org/jira/browse/HBASE-5904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David S. Wang updated HBASE-5904: - Attachment: HBASE-5904.patch is_enabled from shell returns differently from pre- and post- HBASE-5155 Key: HBASE-5904 URL: https://issues.apache.org/jira/browse/HBASE-5904 Project: HBase Issue Type: Bug Components: zookeeper Affects Versions: 0.90.6 Reporter: David S. Wang If I launch an hbase shell that uses HBase and ZooKeeper without HBASE-5155, against HBase servers with HBASE-5155, then is_enabled for a table always returns false even if the table is considered enabled by the servers from the logs. If I then do the same thing but with an HBase shell and ZooKeeper with HBASE-5155, then is_enabled returns as expected. If I launch an HBase shell that uses HBase and ZooKeeper without HBASE-5155, against HBase servers also without HBASE-5155, then is_enabled works as you'd expect. But if I then do the same thing but with an HBase shell and ZooKeeper with HBASE-5155, then is_enabled returns false even though the table is considered enabled by the servers from the logs. Additionally, if I then try to enable the table from the HBASE-5155-containing shell, it hangs because the ZooKeeper code waits for the ZNode to be updated with ENABLED in the data field, but what actually happens is that the ZNode gets deleted since the servers are running without HBASE-5155. I think the culprit is that the indication of how a table is considered enabled inside ZooKeeper has changed with HBASE-5155. Before HBASE-5155, a table was considered enabled if the ZNode for it did not exist. After HBASE-5155, a table is considered enabled if the ZNode for it exists and has ENABLED in its data. I think the current code is incompatible when running clients and servers where one side has HBASE-5155 and the other side does not. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5904) is_enabled from shell returns differently from pre- and post- HBASE-5155
[ https://issues.apache.org/jira/browse/HBASE-5904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David S. Wang updated HBASE-5904: - Attachment: (was: HBASE-5904.patch) is_enabled from shell returns differently from pre- and post- HBASE-5155 Key: HBASE-5904 URL: https://issues.apache.org/jira/browse/HBASE-5904 Project: HBase Issue Type: Bug Components: zookeeper Affects Versions: 0.90.6 Reporter: David S. Wang If I launch an hbase shell that uses HBase and ZooKeeper without HBASE-5155, against HBase servers with HBASE-5155, then is_enabled for a table always returns false even if the table is considered enabled by the servers from the logs. If I then do the same thing but with an HBase shell and ZooKeeper with HBASE-5155, then is_enabled returns as expected. If I launch an HBase shell that uses HBase and ZooKeeper without HBASE-5155, against HBase servers also without HBASE-5155, then is_enabled works as you'd expect. But if I then do the same thing but with an HBase shell and ZooKeeper with HBASE-5155, then is_enabled returns false even though the table is considered enabled by the servers from the logs. Additionally, if I then try to enable the table from the HBASE-5155-containing shell, it hangs because the ZooKeeper code waits for the ZNode to be updated with ENABLED in the data field, but what actually happens is that the ZNode gets deleted since the servers are running without HBASE-5155. I think the culprit is that the indication of how a table is considered enabled inside ZooKeeper has changed with HBASE-5155. Before HBASE-5155, a table was considered enabled if the ZNode for it did not exist. After HBASE-5155, a table is considered enabled if the ZNode for it exists and has ENABLED in its data. I think the current code is incompatible when running clients and servers where one side has HBASE-5155 and the other side does not. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5904) is_enabled from shell returns differently from pre- and post- HBASE-5155
[ https://issues.apache.org/jira/browse/HBASE-5904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David S. Wang updated HBASE-5904: - Assignee: David S. Wang Status: Patch Available (was: Open) Revert HBASE-5155. Should apply only to 0.90 branch. is_enabled from shell returns differently from pre- and post- HBASE-5155 Key: HBASE-5904 URL: https://issues.apache.org/jira/browse/HBASE-5904 Project: HBase Issue Type: Bug Components: zookeeper Affects Versions: 0.90.6 Reporter: David S. Wang Assignee: David S. Wang Attachments: HBASE-5904.patch If I launch an hbase shell that uses HBase and ZooKeeper without HBASE-5155, against HBase servers with HBASE-5155, then is_enabled for a table always returns false even if the table is considered enabled by the servers from the logs. If I then do the same thing but with an HBase shell and ZooKeeper with HBASE-5155, then is_enabled returns as expected. If I launch an HBase shell that uses HBase and ZooKeeper without HBASE-5155, against HBase servers also without HBASE-5155, then is_enabled works as you'd expect. But if I then do the same thing but with an HBase shell and ZooKeeper with HBASE-5155, then is_enabled returns false even though the table is considered enabled by the servers from the logs. Additionally, if I then try to enable the table from the HBASE-5155-containing shell, it hangs because the ZooKeeper code waits for the ZNode to be updated with ENABLED in the data field, but what actually happens is that the ZNode gets deleted since the servers are running without HBASE-5155. I think the culprit is that the indication of how a table is considered enabled inside ZooKeeper has changed with HBASE-5155. Before HBASE-5155, a table was considered enabled if the ZNode for it did not exist. After HBASE-5155, a table is considered enabled if the ZNode for it exists and has ENABLED in its data. I think the current code is incompatible when running clients and servers where one side has HBASE-5155 and the other side does not. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5904) is_enabled from shell returns differently from pre- and post- HBASE-5155
[ https://issues.apache.org/jira/browse/HBASE-5904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David S. Wang updated HBASE-5904: - Attachment: HBASE-5904.patch is_enabled from shell returns differently from pre- and post- HBASE-5155 Key: HBASE-5904 URL: https://issues.apache.org/jira/browse/HBASE-5904 Project: HBase Issue Type: Bug Components: zookeeper Affects Versions: 0.90.6 Reporter: David S. Wang Attachments: HBASE-5904.patch If I launch an hbase shell that uses HBase and ZooKeeper without HBASE-5155, against HBase servers with HBASE-5155, then is_enabled for a table always returns false even if the table is considered enabled by the servers from the logs. If I then do the same thing but with an HBase shell and ZooKeeper with HBASE-5155, then is_enabled returns as expected. If I launch an HBase shell that uses HBase and ZooKeeper without HBASE-5155, against HBase servers also without HBASE-5155, then is_enabled works as you'd expect. But if I then do the same thing but with an HBase shell and ZooKeeper with HBASE-5155, then is_enabled returns false even though the table is considered enabled by the servers from the logs. Additionally, if I then try to enable the table from the HBASE-5155-containing shell, it hangs because the ZooKeeper code waits for the ZNode to be updated with ENABLED in the data field, but what actually happens is that the ZNode gets deleted since the servers are running without HBASE-5155. I think the culprit is that the indication of how a table is considered enabled inside ZooKeeper has changed with HBASE-5155. Before HBASE-5155, a table was considered enabled if the ZNode for it did not exist. After HBASE-5155, a table is considered enabled if the ZNode for it exists and has ENABLED in its data. I think the current code is incompatible when running clients and servers where one side has HBASE-5155 and the other side does not. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5904) is_enabled from shell returns differently from pre- and post- HBASE-5155
[ https://issues.apache.org/jira/browse/HBASE-5904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13269811#comment-13269811 ] David S. Wang commented on HBASE-5904: -- I added a patch off of 0.90 to revert HBASE-5155. I'll throw this on RB as well, but wanted to kick off Hadoop QA bot now. Note that all unit tests for me except for org.apache.hadoop.hbase.TestZooKeeper.testClientSessionExpired, which fails fairly consistently with or without this change. is_enabled from shell returns differently from pre- and post- HBASE-5155 Key: HBASE-5904 URL: https://issues.apache.org/jira/browse/HBASE-5904 Project: HBase Issue Type: Bug Components: zookeeper Affects Versions: 0.90.6 Reporter: David S. Wang Assignee: David S. Wang Attachments: HBASE-5904.patch If I launch an hbase shell that uses HBase and ZooKeeper without HBASE-5155, against HBase servers with HBASE-5155, then is_enabled for a table always returns false even if the table is considered enabled by the servers from the logs. If I then do the same thing but with an HBase shell and ZooKeeper with HBASE-5155, then is_enabled returns as expected. If I launch an HBase shell that uses HBase and ZooKeeper without HBASE-5155, against HBase servers also without HBASE-5155, then is_enabled works as you'd expect. But if I then do the same thing but with an HBase shell and ZooKeeper with HBASE-5155, then is_enabled returns false even though the table is considered enabled by the servers from the logs. Additionally, if I then try to enable the table from the HBASE-5155-containing shell, it hangs because the ZooKeeper code waits for the ZNode to be updated with ENABLED in the data field, but what actually happens is that the ZNode gets deleted since the servers are running without HBASE-5155. I think the culprit is that the indication of how a table is considered enabled inside ZooKeeper has changed with HBASE-5155. Before HBASE-5155, a table was considered enabled if the ZNode for it did not exist. After HBASE-5155, a table is considered enabled if the ZNode for it exists and has ENABLED in its data. I think the current code is incompatible when running clients and servers where one side has HBASE-5155 and the other side does not. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5806) Handle split region related failures on master restart and RS restart
[ https://issues.apache.org/jira/browse/HBASE-5806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13269812#comment-13269812 ] Chinna Rao Lalam commented on HBASE-5806: - Thanks for the review Ted. Updated the patch with the review comments. Handle split region related failures on master restart and RS restart - Key: HBASE-5806 URL: https://issues.apache.org/jira/browse/HBASE-5806 Project: HBase Issue Type: Bug Affects Versions: 0.92.1 Reporter: ramkrishna.s.vasudevan Assignee: Chinna Rao Lalam Fix For: 0.92.2, 0.96.0, 0.94.1 Attachments: HBASE-5806.patch, HBASE-5806_0.94.patch, HBASE-5806_0.94_1.patch, HBASE-5806_trunk.patch, HBASE-5806_trunk_1.patch This issue is raised to solve issues that comes out of partial region split happened and the region node in the ZK which is in RS_ZK_REGION_SPLITTING and RS_ZK_REGION_SPLIT is not yet processed. This also tries to address HBASE-5615. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5494) Introduce a zk hosted table-wide read/write lock so only one table operation at a time
[ https://issues.apache.org/jira/browse/HBASE-5494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13269825#comment-13269825 ] Phabricator commented on HBASE-5494: avf has commented on the revision [jira] [HBASE-5494] [89-fb] Table-level locks for schema changing operations.. Discussed Prakash's comments offline: since having thread id, host name, and operation in the lock name takes advantage of RecoverableZooKeeper accidentally re-entering a lock. Having a separate map in TableLockManager for all locks held, also serves as an additional guard. However, per further discussions with @stack, Kannan, and Prakash we've decided that we should create another JIRA to convert the locks to use sequential ZNodes (which allow reader/writer locks to be implemented as well as avoid many of the race conditions). I will create the said JIRA. REVISION DETAIL https://reviews.facebook.net/D2997 BRANCH table_level_ddl_locks Introduce a zk hosted table-wide read/write lock so only one table operation at a time -- Key: HBASE-5494 URL: https://issues.apache.org/jira/browse/HBASE-5494 Project: HBase Issue Type: Improvement Reporter: stack Attachments: D2997.3.patch, D2997.4.patch, D2997.5.patch, D2997.6.patch I saw this facility over in the accumulo code base. Currently we just try to sort out the mess when splits come in during an online schema edit; somehow we figure we can figure all possible region transition combinations and make the right call. We could try and narrow the number of combinations by taking out a zk table lock when doing table operations. For example, on split or merge, we could take a read-only lock meaning the table can't be disabled while these are running. We could then take a write only lock if we want to ensure the table doesn't change while disabling or enabling process is happening. Shouldn't be too hard to add. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5295) Improve the Thrift API to switch on/off writing to wal for Mutations
[ https://issues.apache.org/jira/browse/HBASE-5295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13269824#comment-13269824 ] Phabricator commented on HBASE-5295: mbautin has commented on the revision [jira] [HBASE-5295] [89-fb] Improve the Thrift API to switch on/off writing to wal for Mutations. @Kannan: thanks for reviewing! Could you please accept the diff if it looks good? REVISION DETAIL https://reviews.facebook.net/D3015 Improve the Thrift API to switch on/off writing to wal for Mutations - Key: HBASE-5295 URL: https://issues.apache.org/jira/browse/HBASE-5295 Project: HBase Issue Type: Improvement Components: thrift Reporter: dhruba borthakur Assignee: dhruba borthakur Attachments: D1515.1.patch, D1515.1.patch, D1515.1.patch, D1515.1.patch, D1515.2.patch, D1515.2.patch, D1515.2.patch, D1515.2.patch, D3015.1.patch, D3015.2.patch, D3015.3.patch, D3015.4.patch The thrift api currently does not support switching off updating wal for Puts/Deletes. Support 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-5584) Coprocessor hooks can be called in the respective handlers
[ https://issues.apache.org/jira/browse/HBASE-5584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13269827#comment-13269827 ] Zhihong Yu commented on HBASE-5584: --- TestAccessController passes with addendum. +1 on addendum. Coprocessor hooks can be called in the respective handlers -- Key: HBASE-5584 URL: https://issues.apache.org/jira/browse/HBASE-5584 Project: HBase Issue Type: Improvement Components: coprocessors Reporter: ramkrishna.s.vasudevan Assignee: ramkrishna.s.vasudevan Fix For: 0.96.0 Attachments: HBASE-5584-1.patch, HBASE-5584-2.patch, HBASE-5584-3.patch, HBASE-5584.patch, HBASE-5584_Security_addendum.patch Following points can be changed w.r.t to coprocessors - Call preCreate, postCreate, preEnable, postEnable, etc. in their respective handlers - Currently it is called in the HMaster thus making the postApis async w.r.t the handlers - Similar is the case with the balancer. with current behaviour once we are in the postEnable(for eg) we any way need to wait for the main enable handler to be completed. We should ensure that we dont wait in the main thread so again we need to spawn a thread and wait on that. On the other hand if the pre and post api is called on the handlers then only that handler thread will be used in the pre/post apis If the above said plan is ok i can prepare a patch for all such related changes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5916) RS restart just before master intialization we make the cluster non operative
[ https://issues.apache.org/jira/browse/HBASE-5916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13269836#comment-13269836 ] Hadoop QA commented on HBASE-5916: -- +1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12525878/HBASE-5916_trunk_3.patch against trunk revision . +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 6 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 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 passed unit tests in . Test results: https://builds.apache.org/job/PreCommit-HBASE-Build/1789//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/1789//artifact/trunk/patchprocess/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/1789//console This message is automatically generated. RS restart just before master intialization we make the cluster non operative - Key: HBASE-5916 URL: https://issues.apache.org/jira/browse/HBASE-5916 Project: HBase Issue Type: Bug Affects Versions: 0.92.1, 0.94.0 Reporter: ramkrishna.s.vasudevan Assignee: ramkrishna.s.vasudevan Priority: Critical Fix For: 0.94.1 Attachments: HBASE-5916_trunk.patch, HBASE-5916_trunk_1.patch, HBASE-5916_trunk_1.patch, HBASE-5916_trunk_2.patch, HBASE-5916_trunk_3.patch Consider a case where my master is getting restarted. RS that was alive when the master restart started, gets restarted before the master initializes the ServerShutDownHandler. {code} serverShutdownHandlerEnabled = true; {code} In this case when the RS tries to register with the master, the master will try to expire the server but the server cannot be expired as still the serverShutdownHandler is not enabled. This case may happen when i have only one RS gets restarted or all the RS gets restarted at the same time.(before assignRootandMeta). {code} LOG.info(message); if (existingServer.getStartcode() serverName.getStartcode()) { LOG.info(Triggering server recovery; existingServer + existingServer + looks stale, new server: + serverName); expireServer(existingServer); } {code} If another RS is brought up then the cluster comes back to normalcy. May be a very corner case. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5295) Improve the Thrift API to switch on/off writing to wal for Mutations
[ https://issues.apache.org/jira/browse/HBASE-5295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13269852#comment-13269852 ] Phabricator commented on HBASE-5295: Kannan has accepted the revision [jira] [HBASE-5295] [89-fb] Improve the Thrift API to switch on/off writing to wal for Mutations. sorry for forgetting to hit accept last time :) REVISION DETAIL https://reviews.facebook.net/D3015 BRANCH hbase_5295_improve_the_thrift_api_to_switch_v6 Improve the Thrift API to switch on/off writing to wal for Mutations - Key: HBASE-5295 URL: https://issues.apache.org/jira/browse/HBASE-5295 Project: HBase Issue Type: Improvement Components: thrift Reporter: dhruba borthakur Assignee: dhruba borthakur Attachments: D1515.1.patch, D1515.1.patch, D1515.1.patch, D1515.1.patch, D1515.2.patch, D1515.2.patch, D1515.2.patch, D1515.2.patch, D3015.1.patch, D3015.2.patch, D3015.3.patch, D3015.4.patch The thrift api currently does not support switching off updating wal for Puts/Deletes. Support 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-5806) Handle split region related failures on master restart and RS restart
[ https://issues.apache.org/jira/browse/HBASE-5806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13269850#comment-13269850 ] Hadoop QA commented on HBASE-5806: -- +1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12525884/HBASE-5806_trunk_1.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 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 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 passed unit tests in . Test results: https://builds.apache.org/job/PreCommit-HBASE-Build/1790//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/1790//artifact/trunk/patchprocess/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/1790//console This message is automatically generated. Handle split region related failures on master restart and RS restart - Key: HBASE-5806 URL: https://issues.apache.org/jira/browse/HBASE-5806 Project: HBase Issue Type: Bug Affects Versions: 0.92.1 Reporter: ramkrishna.s.vasudevan Assignee: Chinna Rao Lalam Fix For: 0.92.2, 0.96.0, 0.94.1 Attachments: HBASE-5806.patch, HBASE-5806_0.94.patch, HBASE-5806_0.94_1.patch, HBASE-5806_trunk.patch, HBASE-5806_trunk_1.patch This issue is raised to solve issues that comes out of partial region split happened and the region node in the ZK which is in RS_ZK_REGION_SPLITTING and RS_ZK_REGION_SPLIT is not yet processed. This also tries to address HBASE-5615. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5904) is_enabled from shell returns differently from pre- and post- HBASE-5155
[ https://issues.apache.org/jira/browse/HBASE-5904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13269854#comment-13269854 ] Hadoop QA commented on HBASE-5904: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12525885/HBASE-5904.patch against trunk revision . +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 15 new or modified tests. -1 patch. The patch command could not apply the patch. Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/1791//console This message is automatically generated. is_enabled from shell returns differently from pre- and post- HBASE-5155 Key: HBASE-5904 URL: https://issues.apache.org/jira/browse/HBASE-5904 Project: HBase Issue Type: Bug Components: zookeeper Affects Versions: 0.90.6 Reporter: David S. Wang Assignee: David S. Wang Attachments: HBASE-5904.patch If I launch an hbase shell that uses HBase and ZooKeeper without HBASE-5155, against HBase servers with HBASE-5155, then is_enabled for a table always returns false even if the table is considered enabled by the servers from the logs. If I then do the same thing but with an HBase shell and ZooKeeper with HBASE-5155, then is_enabled returns as expected. If I launch an HBase shell that uses HBase and ZooKeeper without HBASE-5155, against HBase servers also without HBASE-5155, then is_enabled works as you'd expect. But if I then do the same thing but with an HBase shell and ZooKeeper with HBASE-5155, then is_enabled returns false even though the table is considered enabled by the servers from the logs. Additionally, if I then try to enable the table from the HBASE-5155-containing shell, it hangs because the ZooKeeper code waits for the ZNode to be updated with ENABLED in the data field, but what actually happens is that the ZNode gets deleted since the servers are running without HBASE-5155. I think the culprit is that the indication of how a table is considered enabled inside ZooKeeper has changed with HBASE-5155. Before HBASE-5155, a table was considered enabled if the ZNode for it did not exist. After HBASE-5155, a table is considered enabled if the ZNode for it exists and has ENABLED in its data. I think the current code is incompatible when running clients and servers where one side has HBASE-5155 and the other side does not. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5922) HalfStoreFileReader seekBefore causes StackOverflowError
[ https://issues.apache.org/jira/browse/HBASE-5922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13269875#comment-13269875 ] Nate Putnam commented on HBASE-5922: @Anoop Agreed that the = is probably the right thing to do. I dug into that piece of code and think there is some issue with the underlying KeyValue.comparator that will keep that from working. It seems that it's nearly impossible for key to exactly equal splitkey. This particular issue is a production blocker for us so I would like to get the current fix into the code base and file another issue for the splitkey equality work. Sound good? HalfStoreFileReader seekBefore causes StackOverflowError Key: HBASE-5922 URL: https://issues.apache.org/jira/browse/HBASE-5922 Project: HBase Issue Type: Bug Components: client, io Affects Versions: 0.90.0 Environment: HBase 0.90.4 Reporter: Nate Putnam Assignee: Nate Putnam Priority: Critical Fix For: 0.90.7, 0.92.2, 0.96.0, 0.94.1 Attachments: HBASE-5922.patch, HBASE-5922.patch, HBASE-5922.v2.patch, HBASE-5922.v3.patch Calling HRegionServer.getClosestRowBefore() can cause a stack overflow if the underlying store file is a reference and the row key is in the bottom. java.io.IOException: java.io.IOException: java.lang.StackOverflowError at org.apache.hadoop.hbase.regionserver.HRegionServer.convertThrowableToIOE(HRegionServer.java:990) at org.apache.hadoop.hbase.regionserver.HRegionServer.convertThrowableToIOE(HRegionServer.java:978) at org.apache.hadoop.hbase.regionserver.HRegionServer.getClosestRowBefore(HRegionServer.java:1651) at sun.reflect.GeneratedMethodAccessor174.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.hadoop.hbase.ipc.HBaseRPC$Server.call(HBaseRPC.java:570) at org.apache.hadoop.hbase.ipc.HBaseServer$Handler.run(HBaseServer.java:1039) Caused by: java.lang.StackOverflowError at org.apache.hadoop.hbase.io.HalfStoreFileReader$1.seekBefore(HalfStoreFileReader.java:147) at org.apache.hadoop.hbase.io.HalfStoreFileReader$1.seekBefore(HalfStoreFileReader.java:149) at org.apache.hadoop.hbase.io.HalfStoreFileReader$1.seekBefore(HalfStoreFileReader.java:149) at org.apache.hadoop.hbase.io.HalfStoreFileReader$1.seekBefore(HalfStoreFileReader.java:149) at org.apache.hadoop.hbase.io.HalfStoreFileReader$1.seekBefore(HalfStoreFileReader.java:149) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-4336) Convert source tree into maven modules
[ https://issues.apache.org/jira/browse/HBASE-4336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13269887#comment-13269887 ] Jesse Yates commented on HBASE-4336: Commit candidate v0 is up at https://github.com/jyates/hbase/tree/refactor-modules. Its been rebased onto a fairly recent trunk (may be back a few days, but is pretty close). Worked with Matt Corgan and Ian Varley (thanks Matt and Ian!) on getting this working for more than one person; currently shown to work on OSX and Ubuntu. Give it a spin for the use cases you care about and lets get this rolled in! Notes for usage: * Requires Maven 3 (same as current HBase, but calling this out as its easy to mess up). * Security profile is now enabled with a property, not necessarily enabling a profile ** -Dsecurity, not -Psecurity (minor, but the 'right' way to use profiles) * mvn eclipse:eclipse requires running 'mvn install' first ** m2eclipse (built-in for Eclipse Indigo and installable in older versions) lets you do imports of the project, so you can ignore building the eclipse project files first. However, this way is a little wonky for the import, but you can basically ignore all the errors - seems to work fine. Testing done: * mvn ** clean, package, test, compile * usage ** deployed in pseudo-distributed and works from shell Convert source tree into maven modules -- Key: HBASE-4336 URL: https://issues.apache.org/jira/browse/HBASE-4336 Project: HBase Issue Type: Task Components: build Reporter: Gary Helmling Priority: Critical Fix For: 0.96.0 When we originally converted the build to maven we had a single core module defined, but later reverted this to a module-less build for the sake of simplicity. It now looks like it's time to re-address this, as we have an actual need for modules to: * provide a trimmed down client library that applications can make use of * more cleanly support building against different versions of Hadoop, in place of some of the reflection machinations currently required * incorporate the secure RPC engine that depends on some secure Hadoop classes I propose we start simply by refactoring into two initial modules: * core - common classes and utilities, and client-side code and interfaces * server - master and region server implementations and supporting code This would also lay the groundwork for incorporating the HBase security features that have been developed. Once the module structure is in place, security-related features could then be incorporated into a third module -- security -- after normal review and approval. The security module could then depend on secure Hadoop, without modifying the dependencies of the rest of the HBase 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-5584) Coprocessor hooks can be called in the respective handlers
[ https://issues.apache.org/jira/browse/HBASE-5584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13269960#comment-13269960 ] Zhihong Yu commented on HBASE-5584: --- It is very late in India. Addendum integrated to trunk so that people working on security-related code are unblocked. Thanks for the addendum, Ramkrishna. Coprocessor hooks can be called in the respective handlers -- Key: HBASE-5584 URL: https://issues.apache.org/jira/browse/HBASE-5584 Project: HBase Issue Type: Improvement Components: coprocessors Reporter: ramkrishna.s.vasudevan Assignee: ramkrishna.s.vasudevan Fix For: 0.96.0 Attachments: HBASE-5584-1.patch, HBASE-5584-2.patch, HBASE-5584-3.patch, HBASE-5584.patch, HBASE-5584_Security_addendum.patch Following points can be changed w.r.t to coprocessors - Call preCreate, postCreate, preEnable, postEnable, etc. in their respective handlers - Currently it is called in the HMaster thus making the postApis async w.r.t the handlers - Similar is the case with the balancer. with current behaviour once we are in the postEnable(for eg) we any way need to wait for the main enable handler to be completed. We should ensure that we dont wait in the main thread so again we need to spawn a thread and wait on that. On the other hand if the pre and post api is called on the handlers then only that handler thread will be used in the pre/post apis If the above said plan is ok i can prepare a patch for all such related changes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5952) Sync hardcoded default flush size and max file size with hbase-default.xml
Jimmy Xiang created HBASE-5952: -- Summary: Sync hardcoded default flush size and max file size with hbase-default.xml Key: HBASE-5952 URL: https://issues.apache.org/jira/browse/HBASE-5952 Project: HBase Issue Type: Bug Affects Versions: 0.92.2 Reporter: Jimmy Xiang Assignee: Jimmy Xiang Priority: Minor Fix For: 0.92.2 Since the hardcoded default flush size is 64MB, but the default in hbase-default.xml is 128MB, if the client does set it to 64MB, the actual flush size will be 128MB instead, due to the way HRegion get the flush size. We can change how HRegion get the flush size, but it is clean and simple to sync up the defaults. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5952) Sync hardcoded default flush size and max file size with hbase-default.xml
[ https://issues.apache.org/jira/browse/HBASE-5952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jimmy Xiang updated HBASE-5952: --- Attachment: hbase-5952.patch Sync hardcoded default flush size and max file size with hbase-default.xml -- Key: HBASE-5952 URL: https://issues.apache.org/jira/browse/HBASE-5952 Project: HBase Issue Type: Bug Affects Versions: 0.92.2 Reporter: Jimmy Xiang Assignee: Jimmy Xiang Priority: Minor Fix For: 0.92.2 Attachments: hbase-5952.patch Since the hardcoded default flush size is 64MB, but the default in hbase-default.xml is 128MB, if the client does set it to 64MB, the actual flush size will be 128MB instead, due to the way HRegion get the flush size. We can change how HRegion get the flush size, but it is clean and simple to sync up the defaults. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5952) Sync hardcoded default flush size and max file size with hbase-default.xml
[ https://issues.apache.org/jira/browse/HBASE-5952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jimmy Xiang updated HBASE-5952: --- Status: Patch Available (was: Open) Sync hardcoded default flush size and max file size with hbase-default.xml -- Key: HBASE-5952 URL: https://issues.apache.org/jira/browse/HBASE-5952 Project: HBase Issue Type: Bug Affects Versions: 0.92.2 Reporter: Jimmy Xiang Assignee: Jimmy Xiang Priority: Minor Fix For: 0.92.2 Attachments: hbase-5952.patch Since the hardcoded default flush size is 64MB, but the default in hbase-default.xml is 128MB, if the client does set it to 64MB, the actual flush size will be 128MB instead, due to the way HRegion get the flush size. We can change how HRegion get the flush size, but it is clean and simple to sync up the defaults. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5952) Sync hardcoded default flush size and max file size with hbase-default.xml
[ https://issues.apache.org/jira/browse/HBASE-5952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13269971#comment-13269971 ] Hadoop QA commented on HBASE-5952: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12525920/hbase-5952.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 patch. The patch command could not apply the patch. Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/1792//console This message is automatically generated. Sync hardcoded default flush size and max file size with hbase-default.xml -- Key: HBASE-5952 URL: https://issues.apache.org/jira/browse/HBASE-5952 Project: HBase Issue Type: Bug Affects Versions: 0.92.2 Reporter: Jimmy Xiang Assignee: Jimmy Xiang Priority: Minor Fix For: 0.92.2 Attachments: hbase-5952.patch Since the hardcoded default flush size is 64MB, but the default in hbase-default.xml is 128MB, if the client does set it to 64MB, the actual flush size will be 128MB instead, due to the way HRegion get the flush size. We can change how HRegion get the flush size, but it is clean and simple to sync up the defaults. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5295) Improve the Thrift API to switch on/off writing to wal for Mutations
[ https://issues.apache.org/jira/browse/HBASE-5295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13269976#comment-13269976 ] Phabricator commented on HBASE-5295: mbautin has committed the revision [jira] [HBASE-5295] [89-fb] Improve the Thrift API to switch on/off writing to wal for Mutations. REVISION DETAIL https://reviews.facebook.net/D3015 COMMIT https://reviews.facebook.net/rHBASEEIGHTNINEFBBRANCH1335234 Improve the Thrift API to switch on/off writing to wal for Mutations - Key: HBASE-5295 URL: https://issues.apache.org/jira/browse/HBASE-5295 Project: HBase Issue Type: Improvement Components: thrift Reporter: dhruba borthakur Assignee: dhruba borthakur Attachments: D1515.1.patch, D1515.1.patch, D1515.1.patch, D1515.1.patch, D1515.2.patch, D1515.2.patch, D1515.2.patch, D1515.2.patch, D3015.1.patch, D3015.2.patch, D3015.3.patch, D3015.4.patch The thrift api currently does not support switching off updating wal for Puts/Deletes. Support 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-5806) Handle split region related failures on master restart and RS restart
[ https://issues.apache.org/jira/browse/HBASE-5806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13269986#comment-13269986 ] Zhihong Yu commented on HBASE-5806: --- +1 on patch v2. {code} + private MockMasterWithoutCatalogJanitor abortAndWaitForMaster() throws IOException, InterruptedException { +cluster.abortMaster(0); +cluster.waitOnMaster(0); +cluster.getConfiguration().setClass(HConstants.MASTER_IMPL, MockMasterWithoutCatalogJanitor.class, HMaster.class); {code} Please wrap the two lines whose length exceeds 100 chars at time of integration. Handle split region related failures on master restart and RS restart - Key: HBASE-5806 URL: https://issues.apache.org/jira/browse/HBASE-5806 Project: HBase Issue Type: Bug Affects Versions: 0.92.1 Reporter: ramkrishna.s.vasudevan Assignee: Chinna Rao Lalam Fix For: 0.92.2, 0.96.0, 0.94.1 Attachments: HBASE-5806.patch, HBASE-5806_0.94.patch, HBASE-5806_0.94_1.patch, HBASE-5806_trunk.patch, HBASE-5806_trunk_1.patch This issue is raised to solve issues that comes out of partial region split happened and the region node in the ZK which is in RS_ZK_REGION_SPLITTING and RS_ZK_REGION_SPLIT is not yet processed. This also tries to address HBASE-5615. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5952) Sync hardcoded default flush size and max file size with hbase-default.xml
[ https://issues.apache.org/jira/browse/HBASE-5952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13269995#comment-13269995 ] Zhihong Yu commented on HBASE-5952: --- Patch makes sense. There was a conflict in HTableDescriptor.java: {code} *** *** 164,170 * Constant that denotes the maximum default size of the memstore after which * the contents are flushed to the store files */ - public static final long DEFAULT_MEMSTORE_FLUSH_SIZE = 1024*1024*64L; private volatile Boolean meta = null; private volatile Boolean root = null; --- 164,170 * Constant that denotes the maximum default size of the memstore after which * the contents are flushed to the store files */ + public static final long DEFAULT_MEMSTORE_FLUSH_SIZE = 1024*1024*128L; private volatile Boolean meta = null; private volatile Boolean root = null; {code} Sync hardcoded default flush size and max file size with hbase-default.xml -- Key: HBASE-5952 URL: https://issues.apache.org/jira/browse/HBASE-5952 Project: HBase Issue Type: Bug Affects Versions: 0.92.2 Reporter: Jimmy Xiang Assignee: Jimmy Xiang Priority: Minor Fix For: 0.92.2 Attachments: hbase-5952.patch Since the hardcoded default flush size is 64MB, but the default in hbase-default.xml is 128MB, if the client does set it to 64MB, the actual flush size will be 128MB instead, due to the way HRegion get the flush size. We can change how HRegion get the flush size, but it is clean and simple to sync up the defaults. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5952) Sync hardcoded default flush size and max file size with hbase-default.xml
[ https://issues.apache.org/jira/browse/HBASE-5952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-5952: - Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Committed to 0.92 branch. Thanks for the patch Jimmy. Sync hardcoded default flush size and max file size with hbase-default.xml -- Key: HBASE-5952 URL: https://issues.apache.org/jira/browse/HBASE-5952 Project: HBase Issue Type: Bug Affects Versions: 0.92.2 Reporter: Jimmy Xiang Assignee: Jimmy Xiang Priority: Minor Fix For: 0.92.2 Attachments: hbase-5952.patch Since the hardcoded default flush size is 64MB, but the default in hbase-default.xml is 128MB, if the client does set it to 64MB, the actual flush size will be 128MB instead, due to the way HRegion get the flush size. We can change how HRegion get the flush size, but it is clean and simple to sync up the defaults. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5922) HalfStoreFileReader seekBefore causes StackOverflowError
[ https://issues.apache.org/jira/browse/HBASE-5922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13270006#comment-13270006 ] stack commented on HBASE-5922: -- I'm good w/ committing v3 and opening a new issue to address other concerns. Anoop? HalfStoreFileReader seekBefore causes StackOverflowError Key: HBASE-5922 URL: https://issues.apache.org/jira/browse/HBASE-5922 Project: HBase Issue Type: Bug Components: client, io Affects Versions: 0.90.0 Environment: HBase 0.90.4 Reporter: Nate Putnam Assignee: Nate Putnam Priority: Critical Fix For: 0.90.7, 0.92.2, 0.96.0, 0.94.1 Attachments: HBASE-5922.patch, HBASE-5922.patch, HBASE-5922.v2.patch, HBASE-5922.v3.patch Calling HRegionServer.getClosestRowBefore() can cause a stack overflow if the underlying store file is a reference and the row key is in the bottom. java.io.IOException: java.io.IOException: java.lang.StackOverflowError at org.apache.hadoop.hbase.regionserver.HRegionServer.convertThrowableToIOE(HRegionServer.java:990) at org.apache.hadoop.hbase.regionserver.HRegionServer.convertThrowableToIOE(HRegionServer.java:978) at org.apache.hadoop.hbase.regionserver.HRegionServer.getClosestRowBefore(HRegionServer.java:1651) at sun.reflect.GeneratedMethodAccessor174.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.hadoop.hbase.ipc.HBaseRPC$Server.call(HBaseRPC.java:570) at org.apache.hadoop.hbase.ipc.HBaseServer$Handler.run(HBaseServer.java:1039) Caused by: java.lang.StackOverflowError at org.apache.hadoop.hbase.io.HalfStoreFileReader$1.seekBefore(HalfStoreFileReader.java:147) at org.apache.hadoop.hbase.io.HalfStoreFileReader$1.seekBefore(HalfStoreFileReader.java:149) at org.apache.hadoop.hbase.io.HalfStoreFileReader$1.seekBefore(HalfStoreFileReader.java:149) at org.apache.hadoop.hbase.io.HalfStoreFileReader$1.seekBefore(HalfStoreFileReader.java:149) at org.apache.hadoop.hbase.io.HalfStoreFileReader$1.seekBefore(HalfStoreFileReader.java:149) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5952) Sync hardcoded default flush size and max file size with hbase-default.xml
[ https://issues.apache.org/jira/browse/HBASE-5952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13270009#comment-13270009 ] Jimmy Xiang commented on HBASE-5952: @Ted, this patch is just for 0.92. Trunk and 0.94 don't have this problem. This patch applies well for me on my 0.92 branch. Probably git is out of sync with svn again. Sync hardcoded default flush size and max file size with hbase-default.xml -- Key: HBASE-5952 URL: https://issues.apache.org/jira/browse/HBASE-5952 Project: HBase Issue Type: Bug Affects Versions: 0.92.2 Reporter: Jimmy Xiang Assignee: Jimmy Xiang Priority: Minor Fix For: 0.92.2 Attachments: hbase-5952.patch Since the hardcoded default flush size is 64MB, but the default in hbase-default.xml is 128MB, if the client does set it to 64MB, the actual flush size will be 128MB instead, due to the way HRegion get the flush size. We can change how HRegion get the flush size, but it is clean and simple to sync up the defaults. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5952) Sync hardcoded default flush size and max file size with hbase-default.xml
[ https://issues.apache.org/jira/browse/HBASE-5952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13270014#comment-13270014 ] Jimmy Xiang commented on HBASE-5952: @Stack, thanks for review and commit it. Sync hardcoded default flush size and max file size with hbase-default.xml -- Key: HBASE-5952 URL: https://issues.apache.org/jira/browse/HBASE-5952 Project: HBase Issue Type: Bug Affects Versions: 0.92.2 Reporter: Jimmy Xiang Assignee: Jimmy Xiang Priority: Minor Fix For: 0.92.2 Attachments: hbase-5952.patch Since the hardcoded default flush size is 64MB, but the default in hbase-default.xml is 128MB, if the client does set it to 64MB, the actual flush size will be 128MB instead, due to the way HRegion get the flush size. We can change how HRegion get the flush size, but it is clean and simple to sync up the defaults. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5806) Handle split region related failures on master restart and RS restart
[ https://issues.apache.org/jira/browse/HBASE-5806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13270020#comment-13270020 ] stack commented on HBASE-5806: -- @Chinna Very nice work. Thanks. I can wrap the long lines on commit. Here's some questions on the patch just out of interest: {code} -JVMClusterUtil.MasterThread mt = - JVMClusterUtil.createMasterThread(c, -this.masterClass, index); +JVMClusterUtil.MasterThread mt = JVMClusterUtil.createMasterThread(c, +(Class? extends HMaster) c.getClass(HConstants.MASTER_IMPL, HMaster.class), index); this.masterThreads.add(mt); {code} What brought on the above change? Was this needed so you could add your mocking tests or is it that you fellas are doing a master subclass? I don't understand why we need this change (because of hbase-5654 ?): {code} default: -throw new IllegalStateException(Received event is not valid.); +break; } {code} Log that we are going to pass on a region here? {code} + // If znode does not exist dont consider this region + if (data == null) { +continue; + } {code} At debug level? Handle split region related failures on master restart and RS restart - Key: HBASE-5806 URL: https://issues.apache.org/jira/browse/HBASE-5806 Project: HBase Issue Type: Bug Affects Versions: 0.92.1 Reporter: ramkrishna.s.vasudevan Assignee: Chinna Rao Lalam Fix For: 0.92.2, 0.96.0, 0.94.1 Attachments: HBASE-5806.patch, HBASE-5806_0.94.patch, HBASE-5806_0.94_1.patch, HBASE-5806_trunk.patch, HBASE-5806_trunk_1.patch This issue is raised to solve issues that comes out of partial region split happened and the region node in the ZK which is in RS_ZK_REGION_SPLITTING and RS_ZK_REGION_SPLIT is not yet processed. This also tries to address HBASE-5615. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5104) Provide a reliable intra-row pagination mechanism
[ https://issues.apache.org/jira/browse/HBASE-5104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13270027#comment-13270027 ] Phabricator commented on HBASE-5104: mbautin has commented on the revision [jira] [HBASE-5104] Provide a reliable intra-row pagination mechanism. All unit tests pass, except TestCoprocessorEndpoint, which fails without this patch too. Could someone take another look and accept? Thanks! REVISION DETAIL https://reviews.facebook.net/D2799 Provide a reliable intra-row pagination mechanism - Key: HBASE-5104 URL: https://issues.apache.org/jira/browse/HBASE-5104 Project: HBase Issue Type: Bug Reporter: Kannan Muthukkaruppan Assignee: Madhuwanti Vaidya Attachments: D2799.1.patch, D2799.2.patch, D2799.3.patch, D2799.4.patch, D2799.5.patch, jira-HBASE-5104-Provide-a-reliable-intra-row-paginat-2012-04-16_12_39_42.patch, testFilterList.rb Addendum: Doing pagination (retrieving at most limit number of KVs at a particular offset) is currently supported via the ColumnPaginationFilter. However, it is not a very clean way of supporting pagination. Some of the problems with it are: * Normally, one would expect a query with (Filter(A) AND Filter(B)) to have same results as (query with Filter(A)) INTERSECT (query with Filter(B)). This is not the case for ColumnPaginationFilter as its internal state gets updated depending on whether or not Filter(A) returns TRUE/FALSE for a particular cell. * When this Filter is used in combination with other filters (e.g., doing AND with another filter using FilterList), the behavior of the query depends on the order of filters in the FilterList. This is not ideal. * ColumnPaginationFilter is a stateful filter which ends up counting multiple versions of the cell as separate values even if another filter upstream or the ScanQueryMatcher is going to reject the value for other reasons. Seems like we need a reliable way to do pagination. The particular use case that prompted this JIRA is pagination within the same rowKey. For example, for a given row key R, get columns with prefix P, starting at offset X (among columns which have prefix P) and limit Y. Some possible fixes might be: 1) enhance ColumnPrefixFilter to support another constructor which supports limit/offset. 2) Support pagination (limit/offset) at the Scan/Get API level (rather than as a filter) [Like SQL]. Original Post: Thanks Jiakai Liu for reporting this issue and doing the initial investigation. Email from Jiakai below: Assuming that we have an index column family with the following entries: tag0:001:thread1 ... tag1:001:thread1 tag1:002:thread2 ... tag1:010:thread10 ... tag2:001:thread1 tag2:005:thread5 ... To get threads with tag1 in range [5, 10), I tried the following code: ColumnPrefixFilter filter1 = new ColumnPrefixFilter(Bytes.toBytes(tag1)); ColumnPaginationFilter filter2 = new ColumnPaginationFilter(5 /* limit */, 5 /* offset */); FilterList filters = new FilterList(Operator.MUST_PASS_ALL); filters.addFilter(filter1); filters.addFilter(filter2); Get get = new Get(USER); get.addFamily(COLUMN_FAMILY); get.setMaxVersions(1); get.setFilter(filters); Somehow it didn't work as expected. It returned the entries as if the filter1 were not set. Turns out the ColumnPrefixFilter returns SEEK_NEXT_USING_HINT in some cases. The FilterList filter does not handle this return code properly (treat it as INCLUDE). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5584) Coprocessor hooks can be called in the respective handlers
[ https://issues.apache.org/jira/browse/HBASE-5584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13270032#comment-13270032 ] Hudson commented on HBASE-5584: --- Integrated in HBase-TRUNK-security #195 (See [https://builds.apache.org/job/HBase-TRUNK-security/195/]) HBASE-5584 Addendum fixes compilation error in AccessController (Ramkrishna) (Revision 1335226) Result = SUCCESS tedyu : Files : * /hbase/trunk/security/src/main/java/org/apache/hadoop/hbase/security/access/AccessController.java Coprocessor hooks can be called in the respective handlers -- Key: HBASE-5584 URL: https://issues.apache.org/jira/browse/HBASE-5584 Project: HBase Issue Type: Improvement Components: coprocessors Reporter: ramkrishna.s.vasudevan Assignee: ramkrishna.s.vasudevan Fix For: 0.96.0 Attachments: HBASE-5584-1.patch, HBASE-5584-2.patch, HBASE-5584-3.patch, HBASE-5584.patch, HBASE-5584_Security_addendum.patch Following points can be changed w.r.t to coprocessors - Call preCreate, postCreate, preEnable, postEnable, etc. in their respective handlers - Currently it is called in the HMaster thus making the postApis async w.r.t the handlers - Similar is the case with the balancer. with current behaviour once we are in the postEnable(for eg) we any way need to wait for the main enable handler to be completed. We should ensure that we dont wait in the main thread so again we need to spawn a thread and wait on that. On the other hand if the pre and post api is called on the handlers then only that handler thread will be used in the pre/post apis If the above said plan is ok i can prepare a patch for all such related changes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5948) Deprecate and remove the Avro gateway
[ https://issues.apache.org/jira/browse/HBASE-5948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13270035#comment-13270035 ] stack commented on HBASE-5948: -- +1 Deprecate and remove the Avro gateway - Key: HBASE-5948 URL: https://issues.apache.org/jira/browse/HBASE-5948 Project: HBase Issue Type: Task Affects Versions: 0.96.0 Reporter: Andrew Purtell Priority: Blocker Deprecate the Avro gateway in 0.94. Remove in 0.96. Made a blocker against that release. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5948) Deprecate and remove the Avro gateway
[ https://issues.apache.org/jira/browse/HBASE-5948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13270057#comment-13270057 ] Todd Lipcon commented on HBASE-5948: +1, let's move it to github so anyone who wants to pick it up can do so. Deprecate and remove the Avro gateway - Key: HBASE-5948 URL: https://issues.apache.org/jira/browse/HBASE-5948 Project: HBase Issue Type: Task Affects Versions: 0.96.0 Reporter: Andrew Purtell Priority: Blocker Deprecate the Avro gateway in 0.94. Remove in 0.96. Made a blocker against that release. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5935) Add Region-level PB-based calls to HMasterInterface
[ https://issues.apache.org/jira/browse/HBASE-5935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13270065#comment-13270065 ] jirapos...@reviews.apache.org commented on HBASE-5935: -- --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/5060/ --- Review request for hbase, Michael Stack and Jimmy Xiang. Summary --- Converted all the region-level calls in HMasterInterface to use Protobufs (move, assign, unassign). I've put the new generated calls in HMasterInterface rather than a new class, because it is easier to have one class for now, until I convert everything. This will only be temporary, but let me know how you want to handle. Bump the version number? This addresses bug HBASE-5935. https://issues.apache.org/jira/browse/HBASE-5935 Diffs - src/main/java/org/apache/hadoop/hbase/client/HBaseAdmin.java e3912c2 src/main/java/org/apache/hadoop/hbase/ipc/HMasterInterface.java ce81547 src/main/java/org/apache/hadoop/hbase/master/HMaster.java ccc7119 src/main/java/org/apache/hadoop/hbase/protobuf/RequestConverter.java d1e0993 src/main/java/org/apache/hadoop/hbase/protobuf/generated/MasterProtos.java PRE-CREATION src/main/protobuf/Master.proto PRE-CREATION src/main/protobuf/RegionServerStatus.proto 9d7728f src/test/java/org/apache/hadoop/hbase/TestDrainingServer.java a1992c3 src/test/java/org/apache/hadoop/hbase/coprocessor/TestMasterObserver.java bdec3ee Diff: https://reviews.apache.org/r/5060/diff Testing --- Thanks, Gregory Add Region-level PB-based calls to HMasterInterface --- Key: HBASE-5935 URL: https://issues.apache.org/jira/browse/HBASE-5935 Project: HBase Issue Type: Task Components: ipc, master, migration Reporter: Gregory Chanan Assignee: Gregory Chanan Fix For: 0.96.0 This should be a subtask of HBASE-5445, but since that is a subtask, I can't also make this a subtask (apparently). This is for converting the region-level calls, i.e.: moveRegion assignRegion unassignRegion -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5953) Expose the current state of the balancerSwitch
David S. Wang created HBASE-5953: Summary: Expose the current state of the balancerSwitch Key: HBASE-5953 URL: https://issues.apache.org/jira/browse/HBASE-5953 Project: HBase Issue Type: Improvement Components: master Affects Versions: 0.92.1, 0.94.0, 0.96.0 Reporter: David S. Wang Assignee: David S. Wang Priority: Minor The balancerSwitch as in both 0.90 and 0.92.1 is implemented in such a way that it is impossible to retrieve its value without changing it: /** Turn the load balancer on or off. @param b If true, enable balancer. If false, disable balancer. @return Previous balancer value */ public boolean balanceSwitch(final boolean b); It would be nice to have a way to just get the current state. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5954) Allow proper fsync support for HBase
Lars Hofhansl created HBASE-5954: Summary: Allow proper fsync support for HBase Key: HBASE-5954 URL: https://issues.apache.org/jira/browse/HBASE-5954 Project: HBase Issue Type: Improvement Reporter: Lars Hofhansl -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5954) Allow proper fsync support for HBase
[ https://issues.apache.org/jira/browse/HBASE-5954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13270116#comment-13270116 ] Lars Hofhansl commented on HBASE-5954: -- Over I HDFS-744 I propose changes to HDFS to allow fsync on files. Without that both WAL and HFiles (resulting from compactions/flushes) are not guaranteed to be on disk at the DFS replicas. The HDFS-744 is becoming big, so I'm not sure how the hadoop folks will receive it. I any case, this issues tracks the necessary changes on the HBase side. Allow proper fsync support for HBase Key: HBASE-5954 URL: https://issues.apache.org/jira/browse/HBASE-5954 Project: HBase Issue Type: Improvement Reporter: Lars Hofhansl -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5954) Allow proper fsync support for HBase
[ https://issues.apache.org/jira/browse/HBASE-5954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13270116#comment-13270116 ] Lars Hofhansl edited comment on HBASE-5954 at 5/8/12 1:06 AM: -- Over in HDFS-744 I propose changes to HDFS to allow fsync on files. Without that both WAL and HFiles (resulting from compactions/flushes) are not guaranteed to be on disk at the DFS replicas. The HDFS-744 is becoming big, so I'm not sure how the hadoop folks will receive it. I any case, this issues tracks the necessary changes on the HBase side. was (Author: lhofhansl): Over I HDFS-744 I propose changes to HDFS to allow fsync on files. Without that both WAL and HFiles (resulting from compactions/flushes) are not guaranteed to be on disk at the DFS replicas. The HDFS-744 is becoming big, so I'm not sure how the hadoop folks will receive it. I any case, this issues tracks the necessary changes on the HBase side. Allow proper fsync support for HBase Key: HBASE-5954 URL: https://issues.apache.org/jira/browse/HBASE-5954 Project: HBase Issue Type: Improvement Reporter: Lars Hofhansl -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5954) Allow proper fsync support for HBase
[ https://issues.apache.org/jira/browse/HBASE-5954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-5954: - Attachment: hbase-hdfs-744.txt Here's what I have. Not configurable. With this and HDFS-744, it should be possible to test this out. I will be doing that. Allow proper fsync support for HBase Key: HBASE-5954 URL: https://issues.apache.org/jira/browse/HBASE-5954 Project: HBase Issue Type: Improvement Reporter: Lars Hofhansl Attachments: hbase-hdfs-744.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-5935) Add Region-level PB-based calls to HMasterInterface
[ https://issues.apache.org/jira/browse/HBASE-5935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13270126#comment-13270126 ] jirapos...@reviews.apache.org commented on HBASE-5935: -- --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/5060/ --- (Updated 2012-05-08 01:34:20.873632) Review request for hbase, Michael Stack and Jimmy Xiang. Changes --- Update against newest trunk and added some additional error checking. Summary --- Converted all the region-level calls in HMasterInterface to use Protobufs (move, assign, unassign). I've put the new generated calls in HMasterInterface rather than a new class, because it is easier to have one class for now, until I convert everything. This will only be temporary, but let me know how you want to handle. Bump the version number? This addresses bug HBASE-5935. https://issues.apache.org/jira/browse/HBASE-5935 Diffs (updated) - src/main/java/org/apache/hadoop/hbase/ipc/HMasterInterface.java ce81547 src/main/java/org/apache/hadoop/hbase/master/HMaster.java ccc7119 src/main/java/org/apache/hadoop/hbase/client/HBaseAdmin.java 5d4be3f src/main/java/org/apache/hadoop/hbase/protobuf/RequestConverter.java a5e03e1 src/main/java/org/apache/hadoop/hbase/protobuf/generated/MasterProtos.java PRE-CREATION src/main/protobuf/Master.proto PRE-CREATION src/main/protobuf/RegionServerStatus.proto 9d7728f src/test/java/org/apache/hadoop/hbase/TestDrainingServer.java e5de603 src/test/java/org/apache/hadoop/hbase/coprocessor/TestMasterObserver.java 83297cc Diff: https://reviews.apache.org/r/5060/diff Testing --- Thanks, Gregory Add Region-level PB-based calls to HMasterInterface --- Key: HBASE-5935 URL: https://issues.apache.org/jira/browse/HBASE-5935 Project: HBase Issue Type: Task Components: ipc, master, migration Reporter: Gregory Chanan Assignee: Gregory Chanan Fix For: 0.96.0 This should be a subtask of HBASE-5445, but since that is a subtask, I can't also make this a subtask (apparently). This is for converting the region-level calls, i.e.: moveRegion assignRegion unassignRegion -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5875) Process RIT and Master restart may remove an online server considering it as a dead server
[ https://issues.apache.org/jira/browse/HBASE-5875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13270137#comment-13270137 ] chunhui shen commented on HBASE-5875: - I think we could change a litter to fix the issue. What about checking whether region in regionsInTransitionInRS when call getRegionInfo for verifyReionLocation? If so, it must not in other regionserver, we could wait. Another solution: We could skip verifyReionLocation if we found it in assignment map if processRegionInTransitionAndBlockUntilAssigned return true, could we ?(To be sure, we should change a little in AssignmentManager#regionOnline) Process RIT and Master restart may remove an online server considering it as a dead server -- Key: HBASE-5875 URL: https://issues.apache.org/jira/browse/HBASE-5875 Project: HBase Issue Type: Bug Affects Versions: 0.92.1 Reporter: ramkrishna.s.vasudevan Assignee: ramkrishna.s.vasudevan Fix For: 0.94.1 Attachments: HBASE-5875.patch, HBASE-5875_0.94.patch, HBASE-5875_0.94_1.patch If on master restart it finds the ROOT/META to be in RIT state, master tries to assign the ROOT region through ProcessRIT. Master will trigger the assignment and next will try to verify the Root Region Location. Root region location verification is done seeing if the RS has the region in its online list. If the master triggered assignment has not yet been completed in RS then the verify root region location will fail. Because it failed {code} splitLogAndExpireIfOnline(currentRootServer); {code} we do split log and also remove the server from online server list. Ideally here there is nothing to do in splitlog as no region server was restarted. So master, though the server is online, master just invalidates the region server. In a special case, if i have only one RS then my cluster will become non operative. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5922) HalfStoreFileReader seekBefore causes StackOverflowError
[ https://issues.apache.org/jira/browse/HBASE-5922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13270155#comment-13270155 ] Anoop Sam John commented on HBASE-5922: --- +1 on patch V3.. I am fine with another JIRA in handling the issue with the top half file seek... One suggestion about the test case is pls remove this assertion from the test case {code} + foundKeyValue = doTestOfSeekBefore(p, fs, top, midKV, cacheConf); + assertEquals(beforeMidKey, foundKeyValue); {code} This is actually a bug as per our above discussion... Ideally it should be returning NULL. At the time when we fix the issue we can have another test case with proper assert... What do u say? Otherwise I am fine with the code change and test cases HalfStoreFileReader seekBefore causes StackOverflowError Key: HBASE-5922 URL: https://issues.apache.org/jira/browse/HBASE-5922 Project: HBase Issue Type: Bug Components: client, io Affects Versions: 0.90.0 Environment: HBase 0.90.4 Reporter: Nate Putnam Assignee: Nate Putnam Priority: Critical Fix For: 0.90.7, 0.92.2, 0.96.0, 0.94.1 Attachments: HBASE-5922.patch, HBASE-5922.patch, HBASE-5922.v2.patch, HBASE-5922.v3.patch Calling HRegionServer.getClosestRowBefore() can cause a stack overflow if the underlying store file is a reference and the row key is in the bottom. java.io.IOException: java.io.IOException: java.lang.StackOverflowError at org.apache.hadoop.hbase.regionserver.HRegionServer.convertThrowableToIOE(HRegionServer.java:990) at org.apache.hadoop.hbase.regionserver.HRegionServer.convertThrowableToIOE(HRegionServer.java:978) at org.apache.hadoop.hbase.regionserver.HRegionServer.getClosestRowBefore(HRegionServer.java:1651) at sun.reflect.GeneratedMethodAccessor174.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.hadoop.hbase.ipc.HBaseRPC$Server.call(HBaseRPC.java:570) at org.apache.hadoop.hbase.ipc.HBaseServer$Handler.run(HBaseServer.java:1039) Caused by: java.lang.StackOverflowError at org.apache.hadoop.hbase.io.HalfStoreFileReader$1.seekBefore(HalfStoreFileReader.java:147) at org.apache.hadoop.hbase.io.HalfStoreFileReader$1.seekBefore(HalfStoreFileReader.java:149) at org.apache.hadoop.hbase.io.HalfStoreFileReader$1.seekBefore(HalfStoreFileReader.java:149) at org.apache.hadoop.hbase.io.HalfStoreFileReader$1.seekBefore(HalfStoreFileReader.java:149) at org.apache.hadoop.hbase.io.HalfStoreFileReader$1.seekBefore(HalfStoreFileReader.java:149) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5950) Add a decimal comparator for Filter
[ https://issues.apache.org/jira/browse/HBASE-5950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jieshan Bean reassigned HBASE-5950: --- Assignee: Jieshan Bean Add a decimal comparator for Filter --- Key: HBASE-5950 URL: https://issues.apache.org/jira/browse/HBASE-5950 Project: HBase Issue Type: New Feature Components: filters Affects Versions: 0.94.0, 0.96.0 Reporter: Jieshan Bean Assignee: Jieshan Bean Suppose we have a requirement like below: we want to get the rows with one specified column value larger than A and less than B. (They are all decimals or integers) namely: A Integer.valueof(column) B Use BinaryComparator will not help us to archive that goal: e.g. suppose A = 100, B = 200, one column value is 11. So it can satisfy that condition, but it's not the row we wanted. So I suggest to add one comparator to help implementing 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-5828) TestLogRolling fails in 0.90 branch killing the test suite up on jenkins
[ https://issues.apache.org/jira/browse/HBASE-5828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13270158#comment-13270158 ] xufeng commented on HBASE-5828: --- I added some debug log and reproduce it in my test env,I got the error that the TestLogRolling be killed. 1.The region assignment info: {noformat} Line 227: 2012-05-08 10:33:46,705 INFO [MASTER_OPEN_REGION-HADOOP-CI-AGENT-A:56223-0] handler.OpenedRegionHandler(137): The master has opened the region -ROOT-,,0.70236052 that was online on serverName=HADOOP-CI-AGENT-A,36476,133620154, load=(requests=0, regions=0, usedHeap=49, maxHeap=1348) Line 288: 2012-05-08 10:33:46,797 INFO [MASTER_OPEN_REGION-HADOOP-CI-AGENT-A:56223-1] handler.OpenedRegionHandler(137): The master has opened the region .META.,,1.1028785192 that was online on serverName=HADOOP-CI-AGENT-A,36476,133620154, load=(requests=0, regions=0, usedHeap=49, maxHeap=1348) Line 505: 2012-05-08 10:33:57,224 DEBUG [MASTER_OPEN_REGION-HADOOP-CI-AGENT-A:56223-2] handler.OpenedRegionHandler(139): The master has opened the region TestLogRolling,,133636745.7365edcbf8a8a078ce2c04f08a08e021. that was online on serverName=HADOOP-CI-AGENT-A,59995,133620124, load=(requests=0, regions=0, usedHeap=50, maxHeap=1348) Line 8497: 2012-05-08 10:34:47,678 DEBUG [MASTER_OPEN_REGION-HADOOP-CI-AGENT-A:56223-3] handler.OpenedRegionHandler(139): The master has opened the region TestLogRolling,,133687331.d0ba082226efdac56a16272b51d1147d. that was online on serverName=HADOOP-CI-AGENT-A,59995,133620124, load=(requests=0, regions=0, usedHeap=51, maxHeap=1348) {noformat} 2.The piple line info,ensure the datanodes in pipeline of the rs that holding the meta region did not change,it will cause the problem. {noformat} Line 8528: 2012-05-08 10:34:57,648 INFO [main] wal.TestLogRolling(339): xufeng1cluster.getRegionServer(0)serverName=HADOOP-CI-AGENT-A,59995,133620124, load=(requests=0, regions=1, usedHeap=50, maxHeap=1348) Line 8529: 2012-05-08 10:34:57,648 INFO [main] wal.TestLogRolling(344): xufeng1127.0.0.1:47107 Line 8530: 2012-05-08 10:34:57,648 INFO [main] wal.TestLogRolling(345): xufeng1127.0.0.1:33211 Line 8531: 2012-05-08 10:34:57,648 INFO [main] wal.TestLogRolling(351): xufeng2cluster.getRegionServer(1)serverName=HADOOP-CI-AGENT-A,36476,133620154, load=(requests=0, regions=2, usedHeap=50, maxHeap=1348) Line 8532: 2012-05-08 10:34:57,648 INFO [main] wal.TestLogRolling(356): xufeng2127.0.0.1:33211 Line 8533: 2012-05-08 10:34:57,649 INFO [main] wal.TestLogRolling(357): xufeng2127.0.0.1:47107 Line 9536: 2012-05-08 10:35:35,470 INFO [main] wal.TestLogRolling(420): xufeng3cluster.getRegionServer(0)serverName=HADOOP-CI-AGENT-A,59995,133620124, load=(requests=9, regions=1, usedHeap=49, maxHeap=1348) Line 9537: 2012-05-08 10:35:35,470 INFO [main] wal.TestLogRolling(425): xufeng3127.0.0.1:43393 Line 9538: 2012-05-08 10:35:35,471 INFO [main] wal.TestLogRolling(426): xufeng3127.0.0.1:41380 Line 9723: 2012-05-08 10:35:36,440 INFO [main] wal.TestLogRolling(432): xufeng4cluster.getRegionServer(1)serverName=HADOOP-CI-AGENT-A,36476,133620154, load=(requests=0, regions=2, usedHeap=52, maxHeap=1348) Line 9724: 2012-05-08 10:35:36,440 INFO [main] wal.TestLogRolling(437): xufeng4127.0.0.1:33211 Line 9725: 2012-05-08 10:35:36,440 INFO [main] wal.TestLogRolling(438): xufeng4127.0.0.1:47107 Line 9729: 2012-05-08 10:35:36,442 INFO [main] wal.TestLogRolling(468): xufeng5cluster.getRegionServer(0)serverName=HADOOP-CI-AGENT-A,59995,133620124, load=(requests=9, regions=1, usedHeap=49, maxHeap=1348) Line 9730: 2012-05-08 10:35:36,442 INFO [main] wal.TestLogRolling(473): xufeng5127.0.0.1:43393 Line 9731: 2012-05-08 10:35:36,442 INFO [main] wal.TestLogRolling(474): xufeng5127.0.0.1:41380 Line 9732: 2012-05-08 10:35:36,443 INFO [main] wal.TestLogRolling(480): xufeng6cluster.getRegionServer(1)serverName=HADOOP-CI-AGENT-A,36476,133620154, load=(requests=0, regions=2, usedHeap=52, maxHeap=1348) Line 9733: 2012-05-08 10:35:36,443 INFO [main] wal.TestLogRolling(485): xufeng6127.0.0.1:33211 Line 9734: 2012-05-08 10:35:36,443 INFO [main] wal.TestLogRolling(486): xufeng6127.0.0.1:47107 {noformat} TestLogRolling fails in 0.90 branch killing the test suite up on jenkins Key: HBASE-5828 URL: https://issues.apache.org/jira/browse/HBASE-5828 Project: HBase Issue Type: Bug Reporter: stack See
[jira] [Commented] (HBASE-5828) TestLogRolling fails in 0.90 branch killing the test suite up on jenkins
[ https://issues.apache.org/jira/browse/HBASE-5828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13270160#comment-13270160 ] xufeng commented on HBASE-5828: --- Q:Why the oter versions have not this problem? A:Because by @before and @after tag,every case will have the absolute test cluster. TestLogRolling fails in 0.90 branch killing the test suite up on jenkins Key: HBASE-5828 URL: https://issues.apache.org/jira/browse/HBASE-5828 Project: HBase Issue Type: Bug Reporter: stack See recent 0.90 builds up on jenkins: https://builds.apache.org/view/G-L/view/HBase/job/hbase-0.90/471/console -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5828) TestLogRolling fails in 0.90 branch killing the test suite up on jenkins
[ https://issues.apache.org/jira/browse/HBASE-5828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13270163#comment-13270163 ] xufeng commented on HBASE-5828: --- I can not access https://builds.apache.org/view/G-L/view/HBase/job/hbase-0.90/471/console Is the problem same to what I meeted? TestLogRolling fails in 0.90 branch killing the test suite up on jenkins Key: HBASE-5828 URL: https://issues.apache.org/jira/browse/HBASE-5828 Project: HBase Issue Type: Bug Reporter: stack See recent 0.90 builds up on jenkins: https://builds.apache.org/view/G-L/view/HBase/job/hbase-0.90/471/console -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5951) Combining ColumnPrefixFilters using filterlist.
[ https://issues.apache.org/jira/browse/HBASE-5951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13270169#comment-13270169 ] Anoop Sam John commented on HBASE-5951: --- @Davis It would be better if you describe your schema and the query what you are trying to generate. The case which you describe as not working involve 2 ColumnPrefixFilter with AND condition. ColumnPrefixFilter CF1= new ColumnPrefixFilter(Bytes.toBytes(name));- This will filter out all KVs with qualifier name other than name The othe one, ColumnPrefixFilter CF2= new ColumnPrefixFilter (Bytes.toBytes(CRS));- will filter out all KVs with qualifier name other than CRS So all KVs getting filtered out? If you tell your query need, we can discuss how the same can be created using Filter. Combining ColumnPrefixFilters using filterlist. --- Key: HBASE-5951 URL: https://issues.apache.org/jira/browse/HBASE-5951 Project: HBase Issue Type: Bug Components: filters Affects Versions: 0.92.1 Environment: Combining multiple ColumnPrefixFilters using filterlist does not return exact result. Reporter: Davis Abraham FilterList listOfFilters = new FilterList (FilterList.Operator.MUST_PASS_ALL); FilterList listOfFilters1 = new FilterList (FilterList.Operator.MUST_PASS_ALL); FilterList listOfFilters2 = new FilterList (FilterList.Operator.MUST_PASS_ALL); SingleColumnValueFilter SingleFilter1 = new SingleColumnValueFilter(Bytes.toBytes(cf), Bytes.toBytes(country), CompareOp.EQUAL, Bytes.toBytes(USA)); listOfFilters.addFilter(SingleFilter1); ValueFilter VF1= new ValueFilter (CompareOp.EQUAL, new SubstringComparator(ABC)); ColumnPrefixFilter CF1= new ColumnPrefixFilter(Bytes.toBytes(name)); listOfFilters1.addFilter(CF1); listOfFilters1.addFilter(VF1); listOfFilters.addFilter(listOfFilters1); ValueFilter VF2= new ValueFilter (CompareOp.EQUAL, new SubstringComparator(ED)); ColumnPrefixFilter CF2= new ColumnPrefixFilter (Bytes.toBytes(CRS)); listOfFilters2.addFilter(CF2); listOfFilters2.addFilter(VF2); listOfFilters.addFilter(listOfFilters2); When i do a combibation of SingleFilter1 and listOfFilters1 the result is correct, same way the combination of SingleFilter1 and listOfFilters2 is returing correct result. But when all the three is combined im not getting any result.. Is it the problem with multiple ColumnPrefixFilter??? Value ABC exist in name.0 and value ED exist in CRS.0 and it is in the same row under same Column Family. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5828) TestLogRolling fails in 0.90 branch killing the test suite up on jenkins
[ https://issues.apache.org/jira/browse/HBASE-5828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13270174#comment-13270174 ] Zhihong Yu commented on HBASE-5828: --- That build is no longer on Jenkins. You can look at: https://builds.apache.org/view/G-L/view/HBase/job/hbase-0.90/472/console TestLogRolling fails in 0.90 branch killing the test suite up on jenkins Key: HBASE-5828 URL: https://issues.apache.org/jira/browse/HBASE-5828 Project: HBase Issue Type: Bug Reporter: stack See recent 0.90 builds up on jenkins: https://builds.apache.org/view/G-L/view/HBase/job/hbase-0.90/471/console -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5757) TableInputFormat should handle as many errors as possible
[ https://issues.apache.org/jira/browse/HBASE-5757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13270176#comment-13270176 ] Jonathan Hsieh commented on HBASE-5757: --- Jan, I looked that the logic again I think your are right. When I did a quick glance last time I only saw the isolated patch and didn't see enough context to see the existing retry logic. (review board is helpful). Mind adding some comments explaining why this is ok to retry? (We are retrying once and if we fail twice we give up). It seems strange to me that we are retrying something that throws a DoNotRetyIOException. Anyone else have any comments? TableInputFormat should handle as many errors as possible - Key: HBASE-5757 URL: https://issues.apache.org/jira/browse/HBASE-5757 Project: HBase Issue Type: Bug Components: mapred, mapreduce Affects Versions: 0.90.6 Reporter: Jan Lukavsky Attachments: HBASE-5757.patch Prior to HBASE-4196 there was different handling of IOExceptions thrown from scanner in mapred and mapreduce API. The patch to HBASE-4196 unified this handling so that if exception is caught a reconnect is attempted (without bothering the mapred client). After that, HBASE-4269 changed this behavior back, but in both mapred and mapreduce APIs. The question is, is there any reason not to handle all errors that the input format can handle? In other words, why not try to reissue the request after *any* IOException? I see the following disadvantages of current approach * the client may see exceptions like LeaseException and ScannerTimeoutException if he fails to process all fetched data in timeout * to avoid ScannerTimeoutException the client must raise hbase.regionserver.lease.period * timeouts for tasks is aready configured in mapred.task.timeout, so this seems to me a bit redundant, because typically one needs to update both these parameters * I don't see any possibility to get rid of LeaseException (this is configured on server side) I think all of these issues would be gone, if the DoNotRetryIOException would not be rethrown. -On the other hand, handling errors in InputFormat has disadvantage, that it may hide from the user some inefficiency. Eg. if I have very big scanner.caching, and I manage to process only a few rows in timeout, I will end up with single row being fetched many times (and will not be explicitly notified about this). Could we solve this problem by adding some counter to the InputFormat?- -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5828) TestLogRolling fails in 0.90 branch killing the test suite up on jenkins
[ https://issues.apache.org/jira/browse/HBASE-5828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13270177#comment-13270177 ] xufeng commented on HBASE-5828: --- @Ted Where the log file I can get? TestLogRolling fails in 0.90 branch killing the test suite up on jenkins Key: HBASE-5828 URL: https://issues.apache.org/jira/browse/HBASE-5828 Project: HBase Issue Type: Bug Reporter: stack See recent 0.90 builds up on jenkins: https://builds.apache.org/view/G-L/view/HBase/job/hbase-0.90/471/console -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5916) RS restart just before master intialization we make the cluster non operative
[ https://issues.apache.org/jira/browse/HBASE-5916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13270178#comment-13270178 ] ramkrishna.s.vasudevan commented on HBASE-5916: --- The test cases are passing this time. @Stack Your comments on the patch? RS restart just before master intialization we make the cluster non operative - Key: HBASE-5916 URL: https://issues.apache.org/jira/browse/HBASE-5916 Project: HBase Issue Type: Bug Affects Versions: 0.92.1, 0.94.0 Reporter: ramkrishna.s.vasudevan Assignee: ramkrishna.s.vasudevan Priority: Critical Fix For: 0.94.1 Attachments: HBASE-5916_trunk.patch, HBASE-5916_trunk_1.patch, HBASE-5916_trunk_1.patch, HBASE-5916_trunk_2.patch, HBASE-5916_trunk_3.patch Consider a case where my master is getting restarted. RS that was alive when the master restart started, gets restarted before the master initializes the ServerShutDownHandler. {code} serverShutdownHandlerEnabled = true; {code} In this case when the RS tries to register with the master, the master will try to expire the server but the server cannot be expired as still the serverShutdownHandler is not enabled. This case may happen when i have only one RS gets restarted or all the RS gets restarted at the same time.(before assignRootandMeta). {code} LOG.info(message); if (existingServer.getStartcode() serverName.getStartcode()) { LOG.info(Triggering server recovery; existingServer + existingServer + looks stale, new server: + serverName); expireServer(existingServer); } {code} If another RS is brought up then the cluster comes back to normalcy. May be a very corner case. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5875) Process RIT and Master restart may remove an online server considering it as a dead server
[ https://issues.apache.org/jira/browse/HBASE-5875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13270181#comment-13270181 ] ramkrishna.s.vasudevan commented on HBASE-5875: --- bq.I think we could change a litter to fix the issue. Did you mean little? Can you come up with your patch based on second solution? bq.What about checking whether region in regionsInTransitionInRS when call getRegionInfo for verifyReionLocation? If so, it must not in other regionserver, we could wait. Here am not sure again how long to wait and how much to retry? Process RIT and Master restart may remove an online server considering it as a dead server -- Key: HBASE-5875 URL: https://issues.apache.org/jira/browse/HBASE-5875 Project: HBase Issue Type: Bug Affects Versions: 0.92.1 Reporter: ramkrishna.s.vasudevan Assignee: ramkrishna.s.vasudevan Fix For: 0.94.1 Attachments: HBASE-5875.patch, HBASE-5875_0.94.patch, HBASE-5875_0.94_1.patch If on master restart it finds the ROOT/META to be in RIT state, master tries to assign the ROOT region through ProcessRIT. Master will trigger the assignment and next will try to verify the Root Region Location. Root region location verification is done seeing if the RS has the region in its online list. If the master triggered assignment has not yet been completed in RS then the verify root region location will fail. Because it failed {code} splitLogAndExpireIfOnline(currentRootServer); {code} we do split log and also remove the server from online server list. Ideally here there is nothing to do in splitlog as no region server was restarted. So master, though the server is online, master just invalidates the region server. In a special case, if i have only one RS then my cluster will become non operative. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5828) TestLogRolling fails in 0.90 branch killing the test suite up on jenkins
[ https://issues.apache.org/jira/browse/HBASE-5828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13270183#comment-13270183 ] Zhihong Yu commented on HBASE-5828: --- https://builds.apache.org/view/G-L/view/HBase/job/hbase-0.90/472/artifact/trunk/target/surefire-reports/org.apache.hadoop.hbase.regionserver.wal.TestLogRolling-output.txt TestLogRolling fails in 0.90 branch killing the test suite up on jenkins Key: HBASE-5828 URL: https://issues.apache.org/jira/browse/HBASE-5828 Project: HBase Issue Type: Bug Reporter: stack See recent 0.90 builds up on jenkins: https://builds.apache.org/view/G-L/view/HBase/job/hbase-0.90/471/console -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5942) HConnnectionManager.getRegionServerWithRetries doesn't call afterCall properly
[ https://issues.apache.org/jira/browse/HBASE-5942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-5942: -- Attachment: hbase-5942.patch HConnnectionManager.getRegionServerWithRetries doesn't call afterCall properly -- Key: HBASE-5942 URL: https://issues.apache.org/jira/browse/HBASE-5942 Project: HBase Issue Type: Bug Affects Versions: 0.92.1 Reporter: Zhihong Yu Attachments: hbase-5942.patch HConnnectionManager.getRegionServerWithRetries: {code} return callable.call(); } catch (Throwable t) { callable.shouldRetry(t); {code} shouldRetry relies on the proper startTime and endTime to calculate the timeout value. However, callable.afterCall() is called in finally block. Thus callable.callTimeout will be set to negative value in callable.shouldRetry(). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5942) HConnnectionManager.getRegionServerWithRetries doesn't call afterCall properly
[ https://issues.apache.org/jira/browse/HBASE-5942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13270187#comment-13270187 ] ramkrishna.s.vasudevan commented on HBASE-5942: --- The above issue, Ted had pointed in one of my earlier patches which was a backporting issue. I dont remember the JIRA id now. HConnnectionManager.getRegionServerWithRetries doesn't call afterCall properly -- Key: HBASE-5942 URL: https://issues.apache.org/jira/browse/HBASE-5942 Project: HBase Issue Type: Bug Affects Versions: 0.92.1 Reporter: Zhihong Yu Attachments: hbase-5942.patch HConnnectionManager.getRegionServerWithRetries: {code} return callable.call(); } catch (Throwable t) { callable.shouldRetry(t); {code} shouldRetry relies on the proper startTime and endTime to calculate the timeout value. However, callable.afterCall() is called in finally block. Thus callable.callTimeout will be set to negative value in callable.shouldRetry(). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5942) HConnnectionManager.getRegionServerWithRetries doesn't call afterCall properly
[ https://issues.apache.org/jira/browse/HBASE-5942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13270187#comment-13270187 ] ramkrishna.s.vasudevan edited comment on HBASE-5942 at 5/8/12 4:31 AM: --- The above issue, Ted had pointed in one of my earlier patches which was a backporting issue. I dont remember the JIRA id now. {edit} Please review. Applies to 0.92. {edit} was (Author: ram_krish): The above issue, Ted had pointed in one of my earlier patches which was a backporting issue. I dont remember the JIRA id now. HConnnectionManager.getRegionServerWithRetries doesn't call afterCall properly -- Key: HBASE-5942 URL: https://issues.apache.org/jira/browse/HBASE-5942 Project: HBase Issue Type: Bug Affects Versions: 0.92.1 Reporter: Zhihong Yu Attachments: hbase-5942.patch HConnnectionManager.getRegionServerWithRetries: {code} return callable.call(); } catch (Throwable t) { callable.shouldRetry(t); {code} shouldRetry relies on the proper startTime and endTime to calculate the timeout value. However, callable.afterCall() is called in finally block. Thus callable.callTimeout will be set to negative value in callable.shouldRetry(). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5828) TestLogRolling fails in 0.90 branch killing the test suite up on jenkins
[ https://issues.apache.org/jira/browse/HBASE-5828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13270192#comment-13270192 ] stack commented on HBASE-5828: -- Xufeng: If you want to experiment, add logging or whatever, just make a patch and I'll apply it to 0.90 for you. Its hard figuring this stuff out. You need all the clues you can get. If you want me to run a bunch of 0.90 builds up on jenkins, just ask for it and I'll do it for you too. Thanks (Looks like there are moves to make a 0.90.7 coming so would be cool nailing this flapping test soon). Thanks Xufeng. TestLogRolling fails in 0.90 branch killing the test suite up on jenkins Key: HBASE-5828 URL: https://issues.apache.org/jira/browse/HBASE-5828 Project: HBase Issue Type: Bug Reporter: stack See recent 0.90 builds up on jenkins: https://builds.apache.org/view/G-L/view/HBase/job/hbase-0.90/471/console -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5955) Guava 11 drops MapEvictionListener and Hadoop 2.0.0-alpha requires it
Andrew Purtell created HBASE-5955: - Summary: Guava 11 drops MapEvictionListener and Hadoop 2.0.0-alpha requires it Key: HBASE-5955 URL: https://issues.apache.org/jira/browse/HBASE-5955 Project: HBase Issue Type: Bug Reporter: Andrew Purtell Hadoop 2.0.0-alpha depends on Guava 11.0.2. Updating HBase dependencies to match produces the following compilation errors: {code} [ERROR] SingleSizeCache.java:[41,32] cannot find symbol [ERROR] symbol : class MapEvictionListener [ERROR] location: package com.google.common.collect [ERROR] [ERROR] SingleSizeCache.java:[94,4] cannot find symbol [ERROR] symbol : class MapEvictionListener [ERROR] location: class org.apache.hadoop.hbase.io.hfile.slab.SingleSizeCache [ERROR] [ERROR] SingleSizeCache.java:[94,69] cannot find symbol [ERROR] symbol : class MapEvictionListener [ERROR] location: class org.apache.hadoop.hbase.io.hfile.slab.SingleSizeCache {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-5955) Guava 11 drops MapEvictionListener and Hadoop 2.0.0-alpha requires it
[ https://issues.apache.org/jira/browse/HBASE-5955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13270198#comment-13270198 ] Andrew Purtell commented on HBASE-5955: --- Also there's a change in MapMaker: {code} [ERROR] SingleSizeCache.java:[104,31] maximumSize(int) is not public in com.google.common.collect.MapMaker; cannot be accessed from outside package {code} Guava 11 drops MapEvictionListener and Hadoop 2.0.0-alpha requires it - Key: HBASE-5955 URL: https://issues.apache.org/jira/browse/HBASE-5955 Project: HBase Issue Type: Bug Reporter: Andrew Purtell Hadoop 2.0.0-alpha depends on Guava 11.0.2. Updating HBase dependencies to match produces the following compilation errors: {code} [ERROR] SingleSizeCache.java:[41,32] cannot find symbol [ERROR] symbol : class MapEvictionListener [ERROR] location: package com.google.common.collect [ERROR] [ERROR] SingleSizeCache.java:[94,4] cannot find symbol [ERROR] symbol : class MapEvictionListener [ERROR] location: class org.apache.hadoop.hbase.io.hfile.slab.SingleSizeCache [ERROR] [ERROR] SingleSizeCache.java:[94,69] cannot find symbol [ERROR] symbol : class MapEvictionListener [ERROR] location: class org.apache.hadoop.hbase.io.hfile.slab.SingleSizeCache {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-5935) Add Region-level PB-based calls to HMasterInterface
[ https://issues.apache.org/jira/browse/HBASE-5935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13270199#comment-13270199 ] jirapos...@reviews.apache.org commented on HBASE-5935: -- --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/5060/#review7667 --- Looks good. Some small potatoes below. On this, I've put the new generated calls in HMasterInterface rather than a new class, because it is easier to have one class for now, until I convert everything. This will only be temporary, but let me know how you want to handle. Bump the version number? ... when will HMasterInterface go away? What else all is to be done? Sure on bump the version number. Pretty soon they'll be ignored so no harm using up a few. Good stuff G. src/main/java/org/apache/hadoop/hbase/client/HBaseAdmin.java https://reviews.apache.org/r/5060/#comment16879 Is it right catching this here? You seem to handle it at a higher level up in the move invocation? Won't this clause catch all the possible SEs? Or I'm suffering myopia and there is more going on than just this call invocation? src/main/java/org/apache/hadoop/hbase/ipc/HMasterInterface.java https://reviews.apache.org/r/5060/#comment16885 OK. Not even deprecated. Just removed. Like Jimmy's remove of HRegionInterface and we can do this because these are internal APIs src/main/java/org/apache/hadoop/hbase/ipc/HMasterInterface.java https://reviews.apache.org/r/5060/#comment16880 It does seem a little messy having to hoist all these pb classes up in here AND into HMasterInterface. HMasterInterface is going to go away? src/main/java/org/apache/hadoop/hbase/master/HMaster.java https://reviews.apache.org/r/5060/#comment16883 This seems like a big improvement, having an actual return. src/main/java/org/apache/hadoop/hbase/master/HMaster.java https://reviews.apache.org/r/5060/#comment16881 FYI, spaces between if and open paren... and usually around operators. Just FYI. src/main/java/org/apache/hadoop/hbase/master/HMaster.java https://reviews.apache.org/r/5060/#comment16882 This needs paren (though its in the original) src/main/java/org/apache/hadoop/hbase/master/HMaster.java https://reviews.apache.org/r/5060/#comment16884 All IOEs now need to get converted to a SE? I added an HBaseException recently. Its a checked exception. Should we have an HBaseServiceExceptoin? SE is pb? src/main/protobuf/Master.proto https://reviews.apache.org/r/5060/#comment16886 Great. Is this all that is in the master interface? src/main/protobuf/RegionServerStatus.proto https://reviews.apache.org/r/5060/#comment16887 Good - Michael On 2012-05-08 01:34:20, Gregory Chanan wrote: bq. bq. --- bq. This is an automatically generated e-mail. To reply, visit: bq. https://reviews.apache.org/r/5060/ bq. --- bq. bq. (Updated 2012-05-08 01:34:20) bq. bq. bq. Review request for hbase, Michael Stack and Jimmy Xiang. bq. bq. bq. Summary bq. --- bq. bq. Converted all the region-level calls in HMasterInterface to use Protobufs (move, assign, unassign). bq. bq. I've put the new generated calls in HMasterInterface rather than a new class, because it is easier to have one class for now, until I convert everything. This will only be temporary, but let me know how you want to handle. Bump the version number? bq. bq. bq. This addresses bug HBASE-5935. bq. https://issues.apache.org/jira/browse/HBASE-5935 bq. bq. bq. Diffs bq. - bq. bq.src/main/java/org/apache/hadoop/hbase/ipc/HMasterInterface.java ce81547 bq.src/main/java/org/apache/hadoop/hbase/master/HMaster.java ccc7119 bq.src/main/java/org/apache/hadoop/hbase/client/HBaseAdmin.java 5d4be3f bq.src/main/java/org/apache/hadoop/hbase/protobuf/RequestConverter.java a5e03e1 bq. src/main/java/org/apache/hadoop/hbase/protobuf/generated/MasterProtos.java PRE-CREATION bq.src/main/protobuf/Master.proto PRE-CREATION bq.src/main/protobuf/RegionServerStatus.proto 9d7728f bq.src/test/java/org/apache/hadoop/hbase/TestDrainingServer.java e5de603 bq. src/test/java/org/apache/hadoop/hbase/coprocessor/TestMasterObserver.java 83297cc bq. bq. Diff: https://reviews.apache.org/r/5060/diff bq. bq. bq. Testing bq. --- bq. bq. bq. Thanks, bq. bq. Gregory bq. bq. Add Region-level PB-based calls to HMasterInterface --- Key: HBASE-5935 URL: https://issues.apache.org/jira/browse/HBASE-5935
[jira] [Commented] (HBASE-5953) Expose the current state of the balancerSwitch
[ https://issues.apache.org/jira/browse/HBASE-5953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13270200#comment-13270200 ] stack commented on HBASE-5953: -- Agreed. Its state should be out in zk anyways rather than an in-memory master state. Expose the current state of the balancerSwitch -- Key: HBASE-5953 URL: https://issues.apache.org/jira/browse/HBASE-5953 Project: HBase Issue Type: Improvement Components: master Affects Versions: 0.92.1, 0.94.0, 0.96.0 Reporter: David S. Wang Assignee: David S. Wang Priority: Minor The balancerSwitch as in both 0.90 and 0.92.1 is implemented in such a way that it is impossible to retrieve its value without changing it: /** Turn the load balancer on or off. @param b If true, enable balancer. If false, disable balancer. @return Previous balancer value */ public boolean balanceSwitch(final boolean b); It would be nice to have a way to just get the current state. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5877) When a query fails because the region has moved, let the regionserver return the new address to the client
[ https://issues.apache.org/jira/browse/HBASE-5877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13270212#comment-13270212 ] nkeywal commented on HBASE-5877: I didn't find the test in error. Could be committed imho. When a query fails because the region has moved, let the regionserver return the new address to the client -- Key: HBASE-5877 URL: https://issues.apache.org/jira/browse/HBASE-5877 Project: HBase Issue Type: Improvement Components: client, master, regionserver Affects Versions: 0.96.0 Reporter: nkeywal Assignee: nkeywal Priority: Minor Fix For: 0.96.0 Attachments: 5877-v16.txt, 5877-v17.txt, 5877.v1.patch, 5877.v12.patch, 5877.v15.patch, 5877.v6.patch This is mainly useful when we do a rolling restart. This will decrease the load on the master and the network load. Note that a region is not immediately opened after a close. So: - it seems preferable to wait before retrying on the other server. An optimisation would be to have an heuristic depending on when the region was closed. - during a rolling restart, the server moves the regions then stops. So we may have failures when the server is stopped, and this patch won't help. The implementation in the first patch does: - on the region move, there is an added parameter on the regionserver#close to say where we are sending the region - the regionserver keeps a list of what was moved. Each entry is kept 100 seconds. - the regionserver sends a specific exception when it receives a query on a moved region. This exception contains the new address. - the client analyses the exeptions and update its cache accordingly... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira