[jira] [Updated] (HBASE-5584) Coprocessor hooks can be called in the respective handlers

2012-05-07 Thread ramkrishna.s.vasudevan (JIRA)

 [ 
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

2012-05-07 Thread ramkrishna.s.vasudevan (JIRA)

[ 
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

2012-05-07 Thread chunhui shen (JIRA)
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

2012-05-07 Thread chunhui shen (JIRA)

 [ 
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

2012-05-07 Thread ramkrishna.s.vasudevan (JIRA)

[ 
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

2012-05-07 Thread xufeng (JIRA)

[ 
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

2012-05-07 Thread Jieshan Bean (JIRA)

 [ 
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

2012-05-07 Thread Jieshan Bean (JIRA)

 [ 
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

2012-05-07 Thread Jieshan Bean (JIRA)

 [ 
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

2012-05-07 Thread Jieshan Bean (JIRA)

 [ 
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

2012-05-07 Thread Jieshan Bean (JIRA)

 [ 
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

2012-05-07 Thread Jieshan Bean (JIRA)
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

2012-05-07 Thread Hadoop QA (JIRA)

[ 
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

2012-05-07 Thread Jieshan Bean (JIRA)

 [ 
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

2012-05-07 Thread ramkrishna.s.vasudevan (JIRA)

[ 
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

2012-05-07 Thread ramkrishna.s.vasudevan (JIRA)

[ 
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.

2012-05-07 Thread Davis Abraham (JIRA)
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

2012-05-07 Thread Hadoop QA (JIRA)

[ 
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

2012-05-07 Thread Chinna Rao Lalam (JIRA)

 [ 
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

2012-05-07 Thread Chinna Rao Lalam (JIRA)

[ 
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

2012-05-07 Thread Chinna Rao Lalam (JIRA)

 [ 
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

2012-05-07 Thread Chinna Rao Lalam (JIRA)

[ 
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

2012-05-07 Thread stack (JIRA)

[ 
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

2012-05-07 Thread Zhihong Yu (JIRA)

[ 
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

2012-05-07 Thread ramkrishna.s.vasudevan (JIRA)

[ 
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

2012-05-07 Thread ramkrishna.s.vasudevan (JIRA)

 [ 
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

2012-05-07 Thread ramkrishna.s.vasudevan (JIRA)

 [ 
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

2012-05-07 Thread ramkrishna.s.vasudevan (JIRA)

 [ 
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

2012-05-07 Thread Hadoop QA (JIRA)

[ 
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

2012-05-07 Thread Hadoop QA (JIRA)

[ 
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

2012-05-07 Thread Zhihong Yu (JIRA)

[ 
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

2012-05-07 Thread ramkrishna.s.vasudevan (JIRA)

 [ 
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

2012-05-07 Thread ramkrishna.s.vasudevan (JIRA)

 [ 
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

2012-05-07 Thread ramkrishna.s.vasudevan (JIRA)

[ 
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

2012-05-07 Thread ramkrishna.s.vasudevan (JIRA)

 [ 
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

2012-05-07 Thread ramkrishna.s.vasudevan (JIRA)

 [ 
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

2012-05-07 Thread ramkrishna.s.vasudevan (JIRA)

 [ 
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

2012-05-07 Thread ramkrishna.s.vasudevan (JIRA)

[ 
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

2012-05-07 Thread Chinna Rao Lalam (JIRA)

 [ 
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

2012-05-07 Thread David S. Wang (JIRA)

 [ 
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

2012-05-07 Thread David S. Wang (JIRA)

 [ 
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

2012-05-07 Thread David S. Wang (JIRA)

 [ 
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

2012-05-07 Thread David S. Wang (JIRA)

 [ 
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

2012-05-07 Thread David S. Wang (JIRA)

[ 
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

2012-05-07 Thread Chinna Rao Lalam (JIRA)

[ 
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

2012-05-07 Thread Phabricator (JIRA)

[ 
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

2012-05-07 Thread Phabricator (JIRA)

[ 
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

2012-05-07 Thread Zhihong Yu (JIRA)

[ 
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

2012-05-07 Thread Hadoop QA (JIRA)

[ 
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

2012-05-07 Thread Phabricator (JIRA)

[ 
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

2012-05-07 Thread Hadoop QA (JIRA)

[ 
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

2012-05-07 Thread Hadoop QA (JIRA)

[ 
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

2012-05-07 Thread Nate Putnam (JIRA)

[ 
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

2012-05-07 Thread Jesse Yates (JIRA)

[ 
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

2012-05-07 Thread Zhihong Yu (JIRA)

[ 
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

2012-05-07 Thread Jimmy Xiang (JIRA)
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

2012-05-07 Thread Jimmy Xiang (JIRA)

 [ 
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

2012-05-07 Thread Jimmy Xiang (JIRA)

 [ 
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

2012-05-07 Thread Hadoop QA (JIRA)

[ 
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

2012-05-07 Thread Phabricator (JIRA)

[ 
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

2012-05-07 Thread Zhihong Yu (JIRA)

[ 
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

2012-05-07 Thread Zhihong Yu (JIRA)

[ 
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

2012-05-07 Thread stack (JIRA)

 [ 
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

2012-05-07 Thread stack (JIRA)

[ 
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

2012-05-07 Thread Jimmy Xiang (JIRA)

[ 
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

2012-05-07 Thread Jimmy Xiang (JIRA)

[ 
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

2012-05-07 Thread stack (JIRA)

[ 
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

2012-05-07 Thread Phabricator (JIRA)

[ 
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

2012-05-07 Thread Hudson (JIRA)

[ 
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

2012-05-07 Thread stack (JIRA)

[ 
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

2012-05-07 Thread Todd Lipcon (JIRA)

[ 
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

2012-05-07 Thread jirapos...@reviews.apache.org (JIRA)

[ 
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

2012-05-07 Thread David S. Wang (JIRA)
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

2012-05-07 Thread Lars Hofhansl (JIRA)
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

2012-05-07 Thread Lars Hofhansl (JIRA)

[ 
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

2012-05-07 Thread Lars Hofhansl (JIRA)

[ 
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

2012-05-07 Thread Lars Hofhansl (JIRA)

 [ 
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

2012-05-07 Thread jirapos...@reviews.apache.org (JIRA)

[ 
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

2012-05-07 Thread chunhui shen (JIRA)

[ 
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

2012-05-07 Thread Anoop Sam John (JIRA)

[ 
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

2012-05-07 Thread Jieshan Bean (JIRA)

 [ 
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

2012-05-07 Thread xufeng (JIRA)

[ 
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

2012-05-07 Thread xufeng (JIRA)

[ 
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

2012-05-07 Thread xufeng (JIRA)

[ 
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.

2012-05-07 Thread Anoop Sam John (JIRA)

[ 
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

2012-05-07 Thread Zhihong Yu (JIRA)

[ 
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

2012-05-07 Thread Jonathan Hsieh (JIRA)

[ 
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

2012-05-07 Thread xufeng (JIRA)

[ 
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

2012-05-07 Thread ramkrishna.s.vasudevan (JIRA)

[ 
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

2012-05-07 Thread ramkrishna.s.vasudevan (JIRA)

[ 
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

2012-05-07 Thread Zhihong Yu (JIRA)

[ 
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

2012-05-07 Thread ramkrishna.s.vasudevan (JIRA)

 [ 
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

2012-05-07 Thread ramkrishna.s.vasudevan (JIRA)

[ 
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

2012-05-07 Thread ramkrishna.s.vasudevan (JIRA)

[ 
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

2012-05-07 Thread stack (JIRA)

[ 
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

2012-05-07 Thread Andrew Purtell (JIRA)
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

2012-05-07 Thread Andrew Purtell (JIRA)

[ 
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

2012-05-07 Thread jirapos...@reviews.apache.org (JIRA)

[ 
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

2012-05-07 Thread stack (JIRA)

[ 
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

2012-05-07 Thread nkeywal (JIRA)

[ 
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




  1   2   >