[jira] [Commented] (HBASE-5444) Add PB-based calls to HMasterRegionInterface

2012-05-04 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268152#comment-13268152
 ] 

Hudson commented on HBASE-5444:
---

Integrated in HBase-TRUNK-security #191 (See 
[https://builds.apache.org/job/HBase-TRUNK-security/191/])
HBASE-5444 Add PB-based calls to HMasterRegionInterface (Revision 119)

 Result = SUCCESS
stack : 
Files : 
* 
/hbase/trunk/src/main/jamon/org/apache/hadoop/hbase/tmpl/master/MasterStatusTmpl.jamon
* 
/hbase/trunk/src/main/jamon/org/apache/hadoop/hbase/tmpl/regionserver/RSStatusTmpl.jamon
* /hbase/trunk/src/main/java/org/apache/hadoop/hbase/ClusterStatus.java
* /hbase/trunk/src/main/java/org/apache/hadoop/hbase/ServerLoad.java
* /hbase/trunk/src/main/java/org/apache/hadoop/hbase/ipc/HBaseRpcMetrics.java
* /hbase/trunk/src/main/java/org/apache/hadoop/hbase/ipc/HBaseServer.java
* 
/hbase/trunk/src/main/java/org/apache/hadoop/hbase/ipc/HMasterRegionInterface.java
* /hbase/trunk/src/main/java/org/apache/hadoop/hbase/ipc/Invocation.java
* 
/hbase/trunk/src/main/java/org/apache/hadoop/hbase/ipc/RegionServerStatusProtocol.java
* 
/hbase/trunk/src/main/java/org/apache/hadoop/hbase/master/AssignmentManager.java
* /hbase/trunk/src/main/java/org/apache/hadoop/hbase/master/HMaster.java
* /hbase/trunk/src/main/java/org/apache/hadoop/hbase/master/MXBean.java
* /hbase/trunk/src/main/java/org/apache/hadoop/hbase/master/MXBeanImpl.java
* 
/hbase/trunk/src/main/java/org/apache/hadoop/hbase/master/MasterDumpServlet.java
* /hbase/trunk/src/main/java/org/apache/hadoop/hbase/master/ServerManager.java
* /hbase/trunk/src/main/java/org/apache/hadoop/hbase/protobuf/ProtobufUtil.java
* 
/hbase/trunk/src/main/java/org/apache/hadoop/hbase/protobuf/generated/HBaseProtos.java
* 
/hbase/trunk/src/main/java/org/apache/hadoop/hbase/protobuf/generated/RegionServerStatusProtos.java
* 
/hbase/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java
* /hbase/trunk/src/main/protobuf/RegionServerStatus.proto
* /hbase/trunk/src/main/protobuf/hbase.proto
* /hbase/trunk/src/main/resources/hbase-webapps/master/table.jsp
* /hbase/trunk/src/test/java/org/apache/hadoop/hbase/MiniHBaseCluster.java
* 
/hbase/trunk/src/test/java/org/apache/hadoop/hbase/coprocessor/TestClassLoading.java
* 
/hbase/trunk/src/test/java/org/apache/hadoop/hbase/master/TestAssignmentManager.java
* /hbase/trunk/src/test/java/org/apache/hadoop/hbase/master/TestMXBean.java
* 
/hbase/trunk/src/test/java/org/apache/hadoop/hbase/master/TestMasterNoCluster.java
* 
/hbase/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestServerCustomProtocol.java


 Add PB-based calls to HMasterRegionInterface
 

 Key: HBASE-5444
 URL: https://issues.apache.org/jira/browse/HBASE-5444
 Project: HBase
  Issue Type: Sub-task
  Components: ipc, master, migration, regionserver
Reporter: Todd Lipcon
Assignee: Gregory Chanan
 Fix For: 0.96.0

 Attachments: HBASE-5444-v10-trunk.patch, HBASE-5444-v6-trunk.patch, 
 HBASE-5444-v9-trunk.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-5928) Hbck shouldn't npe when there are no tables.

2012-05-04 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268153#comment-13268153
 ] 

Hudson commented on HBASE-5928:
---

Integrated in HBase-TRUNK-security #191 (See 
[https://builds.apache.org/job/HBase-TRUNK-security/191/])
HBASE-5928 Hbck shouldn't npe when there are no tables (Elliott Clark) 
(Revision 1333691)

 Result = SUCCESS
jmhsieh : 
Files : 
* 
/hbase/trunk/src/main/java/org/apache/hadoop/hbase/client/HConnectionManager.java
* /hbase/trunk/src/main/java/org/apache/hadoop/hbase/util/HBaseFsck.java


 Hbck shouldn't npe when there are no tables.
 

 Key: HBASE-5928
 URL: https://issues.apache.org/jira/browse/HBASE-5928
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.92.1, 0.94.0, 0.96.0
Reporter: Elliott Clark
Assignee: Elliott Clark
Priority: Minor
 Fix For: 0.92.2, 0.96.0, 0.94.1

 Attachments: HBASE-5928-0.patch, HBASE-5928-1.patch, 
 hbase-5928-94.patch


 hbase fsck errors out when there are no tables.
 Exception in thread main java.lang.NullPointerException
   at 
 org.apache.hadoop.hbase.util.HBaseFsck.reportTablesInFlux(HBaseFsck.java:560)
   at 
 org.apache.hadoop.hbase.util.HBaseFsck.onlineConsistencyRepair(HBaseFsck.java:346)
   at org.apache.hadoop.hbase.util.HBaseFsck.onlineHbck(HBaseFsck.java:382)
   at org.apache.hadoop.hbase.util.HBaseFsck.main(HBaseFsck.java:3120)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-5886) Add new metric for possible data loss due to puts without WAL

2012-05-04 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268154#comment-13268154
 ] 

Hudson commented on HBASE-5886:
---

Integrated in HBase-TRUNK-security #191 (See 
[https://builds.apache.org/job/HBase-TRUNK-security/191/])
HBASE-5886 Add new metric for possible data loss due to puts without WAL 
(Revision 1333676)

 Result = SUCCESS
stack : 
Files : 
* /hbase/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
* 
/hbase/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java
* 
/hbase/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/metrics/RegionServerMetrics.java


 Add new metric for possible data loss due to puts without WAL 
 --

 Key: HBASE-5886
 URL: https://issues.apache.org/jira/browse/HBASE-5886
 Project: HBase
  Issue Type: New Feature
  Components: metrics, regionserver
Reporter: Matteo Bertozzi
Assignee: Matteo Bertozzi
Priority: Minor
  Labels: metrics
 Fix For: 0.96.0, 0.94.1

 Attachments: 5886-0.94.patch, HBASE-5886-v0.patch, 
 HBASE-5886-v1.patch, HBASE-5886-v2.patch, HBASE-5886-v3.patch, 
 HBASE-5886-v4.patch


 Add a metrics to keep track of puts without WAL and possible data loss size.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-5931) HBase security profile doesn't compile

2012-05-04 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268155#comment-13268155
 ] 

Hudson commented on HBASE-5931:
---

Integrated in HBase-TRUNK-security #191 (See 
[https://builds.apache.org/job/HBase-TRUNK-security/191/])
HBASE-5931 HBase security profile doesn't compile (Revision 1333600)

 Result = SUCCESS
stack : 
Files : 
* 
/hbase/trunk/security/src/main/java/org/apache/hadoop/hbase/security/HBasePolicyProvider.java
* /hbase/trunk/src/main/resources/hbase-webapps/master/table.jsp


 HBase security profile doesn't compile 
 ---

 Key: HBASE-5931
 URL: https://issues.apache.org/jira/browse/HBASE-5931
 Project: HBase
  Issue Type: Bug
Reporter: Jimmy Xiang
Assignee: Jimmy Xiang
 Fix For: 0.96.0

 Attachments: hbase-5931.patch


 The compilation is broken.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-04 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268156#comment-13268156
 ] 

Hudson commented on HBASE-5883:
---

Integrated in HBase-TRUNK-security #191 (See 
[https://builds.apache.org/job/HBase-TRUNK-security/191/])
HBASE-5883 Backup master is going down due to connection refused exception 
(Jieshan) (Revision 1333530)

 Result = SUCCESS
tedyu : 
Files : 
* /hbase/trunk/src/main/java/org/apache/hadoop/hbase/catalog/CatalogTracker.java
* /hbase/trunk/src/main/java/org/apache/hadoop/hbase/ipc/HBaseRPC.java


 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


 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

[jira] [Updated] (HBASE-5876) TestImportExport has been failing against hadoop 0.23 profile

2012-05-04 Thread Jonathan Hsieh (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-5876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jonathan Hsieh updated HBASE-5876:
--

   Resolution: Fixed
Fix Version/s: 0.94.1
   0.96.0
 Hadoop Flags: Reviewed
   Status: Resolved  (was: Patch Available)

Thanks for reviews ted and stack.   Committed to 0.94 and 0.96/trunk.

 TestImportExport has been failing against hadoop 0.23 profile
 -

 Key: HBASE-5876
 URL: https://issues.apache.org/jira/browse/HBASE-5876
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.94.0, 0.96.0
Reporter: Zhihong Yu
Assignee: Jonathan Hsieh
 Fix For: 0.96.0, 0.94.1

 Attachments: hbase-5876-94.patch, hbase-5876-v2.patch, 
 hbase-5876.patch


 TestImportExport has been failing against hadoop 0.23 profile

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-5887) Make TestAcidGuarantees usable for system testing.

2012-05-04 Thread Jonathan Hsieh (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-5887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jonathan Hsieh updated HBASE-5887:
--

   Resolution: Fixed
Fix Version/s: 0.94.1
   0.96.0
   0.92.2
 Hadoop Flags: Reviewed
   Status: Resolved  (was: Patch Available)

Thanks for reviews stack and ted.  Committed to 0.92, 0.94, 0.96/trunk. 

Will file follow on jira to improve documentation on system tests.

 Make TestAcidGuarantees usable for system testing.
 --

 Key: HBASE-5887
 URL: https://issues.apache.org/jira/browse/HBASE-5887
 Project: HBase
  Issue Type: Improvement
Affects Versions: 0.92.0, 0.92.1, 0.94.0
Reporter: Jonathan Hsieh
Assignee: Jonathan Hsieh
 Fix For: 0.92.2, 0.96.0, 0.94.1

 Attachments: hbase-5887-92.patch, hbase-5887.patch


 Currently, the TestAcidGuarantees run via main() will always abort with an 
 NPE because it digs into a non-existant HBaseTestingUtility for a flusher 
 thread.  We should tool this up so that it works properly from the command 
 line.  This would be a very useful long running test when used in conjunction 
 with fault injections to verify row acid properties.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-5938) Improve documentation of system tests such as TestAcidGuarantees

2012-05-04 Thread Jonathan Hsieh (JIRA)
Jonathan Hsieh created HBASE-5938:
-

 Summary: Improve documentation of system tests such as 
TestAcidGuarantees
 Key: HBASE-5938
 URL: https://issues.apache.org/jira/browse/HBASE-5938
 Project: HBase
  Issue Type: Improvement
  Components: test
Reporter: Jonathan Hsieh


There are several unit tests that have main methods and can be used as long 
running system tests.  Currently this includes TestAcidGuarantees (HBASE-5887), 
but may include more in the future.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-5902) Some scripts are not executable

2012-05-04 Thread nkeywal (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268186#comment-13268186
 ] 

nkeywal commented on HBASE-5902:


 @stack: yes, thank you!

 Some scripts are not executable
 ---

 Key: HBASE-5902
 URL: https://issues.apache.org/jira/browse/HBASE-5902
 Project: HBase
  Issue Type: Bug
  Components: scripts
Affects Versions: 0.96.0
Reporter: nkeywal
Assignee: nkeywal
Priority: Trivial
 Attachments: 5902.v1.patch, 5902v2.txt


 -rw-rw-r--  graceful_stop.sh
 -rw-rw-r--  hbase-config.sh
 -rw-rw-r--  local-master-backup.sh
 -rw-rw-r--  local-regionservers.sh

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-5876) TestImportExport has been failing against hadoop 0.23 profile

2012-05-04 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268194#comment-13268194
 ] 

Hudson commented on HBASE-5876:
---

Integrated in HBase-0.94 #178 (See 
[https://builds.apache.org/job/HBase-0.94/178/])
HBASE-5876 TestImportExport has been failing against hadoop 0.23 profile 
(Revision 1333777)

 Result = SUCCESS
jmhsieh : 
Files : 
* 
/hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/TestImportExport.java


 TestImportExport has been failing against hadoop 0.23 profile
 -

 Key: HBASE-5876
 URL: https://issues.apache.org/jira/browse/HBASE-5876
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.94.0, 0.96.0
Reporter: Zhihong Yu
Assignee: Jonathan Hsieh
 Fix For: 0.96.0, 0.94.1

 Attachments: hbase-5876-94.patch, hbase-5876-v2.patch, 
 hbase-5876.patch


 TestImportExport has been failing against hadoop 0.23 profile

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-5699) Run with 1 WAL in HRegionServer

2012-05-04 Thread Jonathan Hsieh (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268196#comment-13268196
 ] 

Jonathan Hsieh commented on HBASE-5699:
---

Li, if you want to undertake this I'll help.  Let's chat and then write a 
one-two page summary of what our goals are, what our assumptions are, and what 
our intended mechanisms are, how we are going to test this and then loopback 
here with a design/plan to get feedback..  

Another feature that may come into play also is the HLog compression.

 Run with  1 WAL in HRegionServer
 -

 Key: HBASE-5699
 URL: https://issues.apache.org/jira/browse/HBASE-5699
 Project: HBase
  Issue Type: Improvement
Reporter: binlijin
Assignee: Li Pi



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Updated] (HBASE-5494) Introduce a zk hosted table-wide read/write lock so only one table operation at a time

2012-05-04 Thread Phabricator (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-5494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phabricator updated HBASE-5494:
---

Attachment: D2997.5.patch

avf updated the revision [jira] [HBASE-5494] [89-fb] Table-level locks for 
schema changing operations..
Reviewers: Kannan, mbautin, Liyin, JIRA

  Stylistic changes, using putIfAbsent in 
DelayInducingInjectionHandler.awaitEvent(). Implemented Mikhail's suggestions 
regarding createTable: check that a table exists before acquiring the lock, 
acquire the lock, and then check if a table exists again -- in order to handle 
common scenarios more efficiently.

REVISION DETAIL
  https://reviews.facebook.net/D2997

AFFECTED FILES
  src/main/java/org/apache/hadoop/hbase/HConstants.java
  src/main/java/org/apache/hadoop/hbase/TableLockTimeoutException.java
  src/main/java/org/apache/hadoop/hbase/master/HMaster.java
  src/main/java/org/apache/hadoop/hbase/master/TableLockManager.java
  src/main/java/org/apache/hadoop/hbase/util/InjectionEvent.java
  src/main/java/org/apache/hadoop/hbase/util/InjectionHandler.java
  src/main/java/org/apache/hadoop/hbase/zookeeper/DistributedLock.java
  src/main/java/org/apache/hadoop/hbase/zookeeper/ZooKeeperWrapper.java
  src/test/java/org/apache/hadoop/hbase/master/TestSchemaModificationLocks.java
  src/test/java/org/apache/hadoop/hbase/util/DelayInducingInjectionHandler.java
  src/test/java/org/apache/hadoop/hbase/zookeeper/TestDistributedLock.java


 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


 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-5877) When a query fails because the region has moved, let the regionserver return the new address to the client

2012-05-04 Thread nkeywal (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268199#comment-13268199
 ] 

nkeywal commented on HBASE-5877:


@stack

bq. You don't want to have RegionMovedException carry a ServerName#toString 
instead of host and port?
I think it's safer this way, as I have to parse the string afterward. 
Otherwise, if someone modifies ServerName#toString he will break the parsing in 
RegionMovedException, a class he may never have heard of (yes, it will break 
the unit test :-))

bq. Is this a bug fix?
Unfortunately, it's a feature. The error management is duplicated, and I have 
to manage both cases, because we don't have the exception when we come back to 
the result later in the code.

bq. Put the history of moved regions out into its own class?
You're right, it would be better. Wil do.

bq. Don't presize this I'd say: private static final long TIMEOUT_REGION_MOVED 
= (2L * 60L * 1000L);
You would prefer a configurable value? 


bq. Stuff is lazily cleared from movedRegions? Should we have a cleaner come 
visit occasionally?
Aggreed, it would be better with a cleaner. Will do as well.

bq. Why you say the above? When we protobuf it, it'll just be an option so it 
shouldn't be too bad?
Yeah, if it was too bad I would not have proposed it :-). It's an imperfection 
to accept I think. We would not have it if we share the regions state within 
the cluster with ZK.

@ted
bq. Under what condition would newHrl be null above ?
Oops. Refactoring error. Removed.

bq. Please remove the space between newHrl and ')' below:
Done.

bq. Would the above code result in NPE since I see the following in javadoc:
It should not happen because we test hrl value before. But I added a check on 
the arguments to make it safer.

bq. Since updateCachedLocations() is used to handle exception, the presizing 
above may not be needed.

bq. Since updateCachedLocations() is used to handle exception, the presizing 
above may not be needed.
Yeah, I sized it thinking: if we're doing a rolling restart we may have 100 
regions with a wrong location if we're really unlucky. As it small, any 
solution would work here, but I prefer to have the size explicitly set, as it 
says I though about it, that's a reasonable size. I added a comment however. 

bq. The indentation of CloseRegionHandler() above is off.
Fixed.


bq. 'will contains' - 'will contain'. 'keep a too old' - 'keep too old'.
Fixed.



 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.v1.patch, 5877.v12.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




[jira] [Commented] (HBASE-5876) TestImportExport has been failing against hadoop 0.23 profile

2012-05-04 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268209#comment-13268209
 ] 

Hudson commented on HBASE-5876:
---

Integrated in HBase-TRUNK #2847 (See 
[https://builds.apache.org/job/HBase-TRUNK/2847/])
HBASE-5876 TestImportExport has been failing against hadoop 0.23 profile 
(Revision 1333778)

 Result = FAILURE
jmhsieh : 
Files : 
* /hbase/trunk/src/test/java/org/apache/hadoop/hbase/HBaseTestingUtility.java
* 
/hbase/trunk/src/test/java/org/apache/hadoop/hbase/mapreduce/MapreduceTestingShim.java
* 
/hbase/trunk/src/test/java/org/apache/hadoop/hbase/mapreduce/TestImportExport.java


 TestImportExport has been failing against hadoop 0.23 profile
 -

 Key: HBASE-5876
 URL: https://issues.apache.org/jira/browse/HBASE-5876
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.94.0, 0.96.0
Reporter: Zhihong Yu
Assignee: Jonathan Hsieh
 Fix For: 0.96.0, 0.94.1

 Attachments: hbase-5876-94.patch, hbase-5876-v2.patch, 
 hbase-5876.patch


 TestImportExport has been failing against hadoop 0.23 profile

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-5887) Make TestAcidGuarantees usable for system testing.

2012-05-04 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268210#comment-13268210
 ] 

Hudson commented on HBASE-5887:
---

Integrated in HBase-TRUNK #2847 (See 
[https://builds.apache.org/job/HBase-TRUNK/2847/])
HBASE-5887 Make TestAcidGuarantees usable for system testing (Revision 
1333785)

 Result = FAILURE
jmhsieh : 
Files : 
* /hbase/trunk/src/test/java/org/apache/hadoop/hbase/TestAcidGuarantees.java


 Make TestAcidGuarantees usable for system testing.
 --

 Key: HBASE-5887
 URL: https://issues.apache.org/jira/browse/HBASE-5887
 Project: HBase
  Issue Type: Improvement
Affects Versions: 0.92.0, 0.92.1, 0.94.0
Reporter: Jonathan Hsieh
Assignee: Jonathan Hsieh
 Fix For: 0.92.2, 0.96.0, 0.94.1

 Attachments: hbase-5887-92.patch, hbase-5887.patch


 Currently, the TestAcidGuarantees run via main() will always abort with an 
 NPE because it digs into a non-existant HBaseTestingUtility for a flusher 
 thread.  We should tool this up so that it works properly from the command 
 line.  This would be a very useful long running test when used in conjunction 
 with fault injections to verify row acid properties.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-5887) Make TestAcidGuarantees usable for system testing.

2012-05-04 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268214#comment-13268214
 ] 

Hudson commented on HBASE-5887:
---

Integrated in HBase-0.92 #398 (See 
[https://builds.apache.org/job/HBase-0.92/398/])
HBASE-5887 Make TestAcidGuarantees usable for system testing (Revision 
1333783)

 Result = FAILURE
jmhsieh : 
Files : 
* /hbase/branches/0.92/CHANGES.txt
* 
/hbase/branches/0.92/src/test/java/org/apache/hadoop/hbase/TestAcidGuarantees.java


 Make TestAcidGuarantees usable for system testing.
 --

 Key: HBASE-5887
 URL: https://issues.apache.org/jira/browse/HBASE-5887
 Project: HBase
  Issue Type: Improvement
Affects Versions: 0.92.0, 0.92.1, 0.94.0
Reporter: Jonathan Hsieh
Assignee: Jonathan Hsieh
 Fix For: 0.92.2, 0.96.0, 0.94.1

 Attachments: hbase-5887-92.patch, hbase-5887.patch


 Currently, the TestAcidGuarantees run via main() will always abort with an 
 NPE because it digs into a non-existant HBaseTestingUtility for a flusher 
 thread.  We should tool this up so that it works properly from the command 
 line.  This would be a very useful long running test when used in conjunction 
 with fault injections to verify row acid properties.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-5699) Run with 1 WAL in HRegionServer

2012-05-04 Thread Li Pi (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268216#comment-13268216
 ] 

Li Pi commented on HBASE-5699:
--

I thought about the compression bit already. I was going to compress each 
separate log individually.

Yeah, I should have probably wrote up what I was going to do before hacking 
stuff up. Will switch gears and work on that a bit instead.

 Run with  1 WAL in HRegionServer
 -

 Key: HBASE-5699
 URL: https://issues.apache.org/jira/browse/HBASE-5699
 Project: HBase
  Issue Type: Improvement
Reporter: binlijin
Assignee: Li Pi



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-5922) HalfStoreFileReader seekBefore causes StackOverflowError

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

[ 
https://issues.apache.org/jira/browse/HBASE-5922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268217#comment-13268217
 ] 

Anoop Sam John commented on HBASE-5922:
---

|most readable would change the recursive call on line 153 from seekBefore to 
delegate.seekBefore

+1 for this.. Yes recursion always confusing..
So when key  splitKey  - delegate.seekBefore(splitKey)

No harm in having key = splitKey also...

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

 Attachments: HBASE-5922.patch, HBASE-5922.patch, HBASE-5922.v2.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-5922) HalfStoreFileReader seekBefore causes StackOverflowError

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

[ 
https://issues.apache.org/jira/browse/HBASE-5922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268218#comment-13268218
 ] 

Anoop Sam John commented on HBASE-5922:
---

Also this fix is needed in all versions...
92.2, 94.1 and trunk

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

 Attachments: HBASE-5922.patch, HBASE-5922.patch, HBASE-5922.v2.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] [Updated] (HBASE-5883) Backup master is going down due to connection refused exception

2012-05-04 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: 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-addendum.patch, HBASE-5883-trunk.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-5844) Delete the region servers znode after a regions server crash

2012-05-04 Thread nkeywal (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268224#comment-13268224
 ] 

nkeywal commented on HBASE-5844:


Ready to be committed imho.

 Delete the region servers znode after a regions server crash
 

 Key: HBASE-5844
 URL: https://issues.apache.org/jira/browse/HBASE-5844
 Project: HBase
  Issue Type: Improvement
  Components: regionserver, scripts
Affects Versions: 0.96.0
Reporter: nkeywal
Assignee: nkeywal
 Fix For: 0.96.0

 Attachments: 5844.v1.patch, 5844.v2.patch, 5844.v3.patch, 
 5844.v3.patch, 5844.v4.patch


 today, if the regions server crashes, its znode is not deleted in ZooKeeper. 
 So the recovery process will stop only after a timeout, usually 30s.
 By deleting the znode in start script, we remove this delay and the recovery 
 starts immediately.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-04 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268243#comment-13268243
 ] 

Hadoop QA commented on HBASE-5883:
--

-1 overall.  Here are the results of testing the latest attachment 
  
http://issues.apache.org/jira/secure/attachment/12525583/HBASE-5883-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 passed unit tests in .

Test results: 
https://builds.apache.org/job/PreCommit-HBASE-Build/1762//testReport/
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/1762//artifact/trunk/patchprocess/newPatchFindbugsWarnings.html
Console output: 
https://builds.apache.org/job/PreCommit-HBASE-Build/1762//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-addendum.patch, HBASE-5883-trunk.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 

[jira] [Updated] (HBASE-5883) Backup master is going down due to connection refused exception

2012-05-04 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: HBASE-5883-94-addendum.patch
HBASE-5883-92-addendum.patch
HBASE-5883-90-addendum.patch

Addendum patches for all branches.

 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-addendum.patch, HBASE-5883-90.patch, 
 HBASE-5883-92-addendum.patch, HBASE-5883-92.patch, 
 HBASE-5883-94-addendum.patch, HBASE-5883-94.patch, 
 HBASE-5883-trunk-addendum.patch, HBASE-5883-trunk.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-5883) Backup master is going down due to connection refused exception

2012-05-04 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268259#comment-13268259
 ] 

Hadoop QA commented on HBASE-5883:
--

-1 overall.  Here are the results of testing the latest attachment 
  
http://issues.apache.org/jira/secure/attachment/12525595/HBASE-5883-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:
   org.apache.hadoop.hbase.client.TestFromClientSide

Test results: 
https://builds.apache.org/job/PreCommit-HBASE-Build/1763//testReport/
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/1763//artifact/trunk/patchprocess/newPatchFindbugsWarnings.html
Console output: 
https://builds.apache.org/job/PreCommit-HBASE-Build/1763//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-addendum.patch, HBASE-5883-90.patch, 
 HBASE-5883-92-addendum.patch, HBASE-5883-92.patch, 
 HBASE-5883-94-addendum.patch, HBASE-5883-94.patch, 
 HBASE-5883-trunk-addendum.patch, HBASE-5883-trunk.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 
 

[jira] [Commented] (HBASE-5927) AM#unassign should handle local exceptions after calling sendRegionClose

2012-05-04 Thread Jieshan Bean (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268285#comment-13268285
 ] 

Jieshan Bean commented on HBASE-5927:
-

Okay, I will add it:)

 AM#unassign should handle local exceptions after calling sendRegionClose
 

 Key: HBASE-5927
 URL: https://issues.apache.org/jira/browse/HBASE-5927
 Project: HBase
  Issue Type: Bug
  Components: master
Affects Versions: 0.92.1, 0.96.0, 0.94.1
Reporter: Jieshan Bean
Assignee: Jieshan Bean
 Fix For: 0.92.2, 0.96.0, 0.94.1


 A possible exception: If the related regionserver was just killed(But HMaster 
 has not perceived that), then we will get a local exception Connection reset 
 by peer. If this region belongs to a disabling table. what will happen?
 ServerShutdownHandler will remove this region from AM#regions. So this region 
 is still existing in RIT. TimeoutMonitor will take care of it after it got 
 timeout. Then invoke unassign again. Since this region has been removed from 
 AM#regions, it will return directly due to the below code:
 {code}
 synchronized (this.regions) {
   // Check if this region is currently assigned
   if (!regions.containsKey(region)) {
 LOG.debug(Attempted to unassign region  +
   region.getRegionNameAsString() +  but it is not  +
   currently assigned anywhere);
 return;
   }
 }
 {code}
 Then it leads to an end-less loop.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-04 Thread Zhihong Yu (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268369#comment-13268369
 ] 

Zhihong Yu commented on HBASE-5883:
---

+1 on addendum

 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-addendum.patch, HBASE-5883-90.patch, 
 HBASE-5883-92-addendum.patch, HBASE-5883-92.patch, 
 HBASE-5883-94-addendum.patch, HBASE-5883-94.patch, 
 HBASE-5883-trunk-addendum.patch, HBASE-5883-trunk.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-5732) Remove the SecureRPCEngine and merge the security-related logic in the core engine

2012-05-04 Thread Devaraj Das (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268394#comment-13268394
 ] 

Devaraj Das commented on HBASE-5732:


Yeah I should have commented back on RB.. Sorry about that. 
I'll upload a patch once I am done with the manual testing with kerberos (very 
soon).

 Remove the SecureRPCEngine and merge the security-related logic in the core 
 engine
 --

 Key: HBASE-5732
 URL: https://issues.apache.org/jira/browse/HBASE-5732
 Project: HBase
  Issue Type: Improvement
Reporter: Devaraj Das
Assignee: Devaraj Das
 Attachments: rpcengine-merge.3.patch, rpcengine-merge.4.patch, 
 rpcengine-merge.patch


 Remove the SecureRPCEngine and merge the security-related logic in the core 
 engine. Follow up to HBASE-5727.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-04 Thread Phabricator (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268412#comment-13268412
 ] 

Phabricator commented on HBASE-5494:


tedyu has commented on the revision [jira] [HBASE-5494] [89-fb] Table-level 
locks for schema changing operations..

  I think this feature should leave ample room for region level lock, to be 
developed in the future.
  Meaning, znode for table level lock would always exist because it has 
children znodes which represent region locks.

INLINE COMMENTS
  src/main/java/org/apache/hadoop/hbase/zookeeper/DistributedLock.java:147 Can 
this assumption be elaborated some more ?

REVISION DETAIL
  https://reviews.facebook.net/D2997


 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


 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] [Updated] (HBASE-5902) Some scripts are not executable

2012-05-04 Thread stack (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-5902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stack updated HBASE-5902:
-

   Resolution: Fixed
Fix Version/s: 0.94.1
   0.96.0
 Hadoop Flags: Reviewed
   Status: Resolved  (was: Patch Available)

Committed to 0.94 branch and to trunk.  Thanks for patch N.

 Some scripts are not executable
 ---

 Key: HBASE-5902
 URL: https://issues.apache.org/jira/browse/HBASE-5902
 Project: HBase
  Issue Type: Bug
  Components: scripts
Affects Versions: 0.96.0
Reporter: nkeywal
Assignee: nkeywal
Priority: Trivial
 Fix For: 0.96.0, 0.94.1

 Attachments: 5902.v1.patch, 5902v2.txt


 -rw-rw-r--  graceful_stop.sh
 -rw-rw-r--  hbase-config.sh
 -rw-rw-r--  local-master-backup.sh
 -rw-rw-r--  local-regionservers.sh

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-5894) Delete table failed but HBaseAdmin#deletetable report it as success

2012-05-04 Thread stack (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268431#comment-13268431
 ] 

stack commented on HBASE-5894:
--

+1 on patch

 Delete table failed but HBaseAdmin#deletetable report it as success
 ---

 Key: HBASE-5894
 URL: https://issues.apache.org/jira/browse/HBASE-5894
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.90.7, 0.92.2, 0.94.0
 Environment: all versions
Reporter: xufeng
Assignee: xufeng
Priority: Minor
 Attachments: HBASE-5894_90_patch_v1.patch, 
 HBASE-5894_90_patch_v1_surefire-report.html, HBASE-5894_92_patch_v1.patch, 
 HBASE-5894_92_patch_v1_surefire-report.html, HBASE-5894_94_patch_v1.patch, 
 HBASE-5894_94_patch_v1_surefire-report.html, HBASE-5894_trunk_patch_v1.patch, 
 HBASE-5894_trunk_patch_v1_surefire-report.html, 
 HBASE-5894_trunk_patch_v2.patch, 
 HBASE-5894_trunk_patch_v2_surefire-report.html


 Reproduce this issue by following steps:
 For reproduce it I add this code in DeleteTableHandler#handleTableOperation():
 {noformat}
   LOG.debug(Deleting region  + region.getRegionNameAsString() +
  from META and FS);
 +if (true) {
 +  throw new IOException(ERROR);
 +}
   // Remove region from META
   MetaEditor.deleteRegion(this.server.getCatalogTracker(), region);
 {noformat}
 step1:create a table and disable it.
 step2:delete it by HBaseAdmin#deleteTable() API.
 result:after lone time, The log say the Table has been deleted, but in fact 
 if we do list in shell,the table also exists.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-4956) Control direct memory buffer consumption by HBaseClient

2012-05-04 Thread Bob Copeland (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268435#comment-13268435
 ] 

Bob Copeland commented on HBASE-4956:
-

With regard to readFully() being everywhere -- perhaps it would be less 
intrusive to subclass DataInput, or to modify one of the read functions further 
down in the stack like org.apache.hadoop.net.SocketInputStream.read() to do the 
chunking.  You guys know the code better than I.

These numbers are for standalone mode.  I can't easily do a test on our 
distributed cluster but I don't think it would change the numbers much.  I'll 
upload my test script and then anyone who wants can repeat the experiment on 
their setup.

Each trial consists of a run of hbase org.jruby.Main thread_get.rb 1, which 
does 100 gets of a ~10 MB row, 3 times in a row, computing avg  stddev of 
wall-clock time.  Maxread variable is changed for every run.
{code}
sizeavg  stddev
 ~~  ~~
133.690 .10
1k3.072 .18
2k3.395 .19
4k3.493 .16
8k3.306 .19
16k   2.918 .21
32k   2.835 .06
64k   2.689 .08
128k  3.048 .03
len   3.328 .08
{code}

 Control direct memory buffer consumption by HBaseClient
 ---

 Key: HBASE-4956
 URL: https://issues.apache.org/jira/browse/HBASE-4956
 Project: HBase
  Issue Type: New Feature
Reporter: Ted Yu

 As Jonathan explained here 
 https://groups.google.com/group/asynchbase/browse_thread/thread/c45bc7ba788b2357?pli=1
  , standard hbase client inadvertently consumes large amount of direct memory.
 We should consider using netty for NIO-related tasks.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-4956) Control direct memory buffer consumption by HBaseClient

2012-05-04 Thread Bob Copeland (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bob Copeland updated HBASE-4956:


Attachment: thread_get.rb

Test script for reproducing the error (with max direct memory limits in place) 
or benchmarking different chunk sizes.  Although it can do threading, I have 
mostly passed 1 to do the tests in a single thread.

 Control direct memory buffer consumption by HBaseClient
 ---

 Key: HBASE-4956
 URL: https://issues.apache.org/jira/browse/HBASE-4956
 Project: HBase
  Issue Type: New Feature
Reporter: Ted Yu
 Attachments: thread_get.rb


 As Jonathan explained here 
 https://groups.google.com/group/asynchbase/browse_thread/thread/c45bc7ba788b2357?pli=1
  , standard hbase client inadvertently consumes large amount of direct memory.
 We should consider using netty for NIO-related tasks.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-5844) Delete the region servers znode after a regions server crash

2012-05-04 Thread stack (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-5844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stack updated HBASE-5844:
-

Resolution: Fixed
Status: Resolved  (was: Patch Available)

Committed to trunk.  Thanks for the patch N.

 Delete the region servers znode after a regions server crash
 

 Key: HBASE-5844
 URL: https://issues.apache.org/jira/browse/HBASE-5844
 Project: HBase
  Issue Type: Improvement
  Components: regionserver, scripts
Affects Versions: 0.96.0
Reporter: nkeywal
Assignee: nkeywal
 Fix For: 0.96.0

 Attachments: 5844.v1.patch, 5844.v2.patch, 5844.v3.patch, 
 5844.v3.patch, 5844.v4.patch


 today, if the regions server crashes, its znode is not deleted in ZooKeeper. 
 So the recovery process will stop only after a timeout, usually 30s.
 By deleting the znode in start script, we remove this delay and the recovery 
 starts immediately.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-04 Thread stack (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268452#comment-13268452
 ] 

stack commented on HBASE-5883:
--

Should we remove this too?

{code}
+} else if (ioex.getCause() != null
+ ioex.getCause() instanceof ConnectException) {
+  ce = (ConnectException) ioex.getCause();
+  ioe = ce;
{code}

If the above happens, we'll get a stack trace that will be missing the last few 
stacks; i.e. the difference between here where its handled and wherever 
ConnectionException was originally thrown.  It could be confuse debugging later?

Also, should we pass the ioe into handleConnectionException?  I'd think we'd do 
this for the case that ce is null (could that happen)?

Good stuff.

 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-addendum.patch, HBASE-5883-90.patch, 
 HBASE-5883-92-addendum.patch, HBASE-5883-92.patch, 
 HBASE-5883-94-addendum.patch, HBASE-5883-94.patch, 
 HBASE-5883-trunk-addendum.patch, HBASE-5883-trunk.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: 

[jira] [Commented] (HBASE-5867) Improve Compaction Throttle Default

2012-05-04 Thread Nicolas Spiegelberg (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268458#comment-13268458
 ] 

Nicolas Spiegelberg commented on HBASE-5867:


@stack: this should be a much better out-of-the-box than we currently have.  If 
anything, we could make the value higher (4 or 8 instead of 2).  However, this 
should be a substantially-better default than the current.

 Improve Compaction Throttle Default
 ---

 Key: HBASE-5867
 URL: https://issues.apache.org/jira/browse/HBASE-5867
 Project: HBase
  Issue Type: Improvement
Reporter: Nicolas Spiegelberg
Assignee: Nicolas Spiegelberg
Priority: Minor
 Attachments: D2943.1.patch


 We recently had a production issue where our compactions fell behind because 
 our compaction throttle was improperly tuned and accidentally upgraded all 
 compactions to the large pool.  The default from HBASE-3877 makes 1 bad 
 assumption: the default number of flushed files in a compaction.  Currently 
 the algorithm is:
 throttleSize ~= flushSize * 2
 This assumes that the basic compaction utilizes 3 files and that all 3 files 
 are compressed.  In this case, hbase.hstore.compaction.min == 6  the 
 values were not very compressible.  Both conditions should be taken into 
 consideration.  As a default, it is less damaging for the large thread to be 
 slightly higher than it needs to be versus having everything accidentally 
 promoted.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-04 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.patch

Tried to address this problem using the system time.  The test case attached in 
the patch reproduces the issue of how the HLog gets deleted.
If the way of using time to avoid this issue seems bad pls don't Hate me. I 
think atleast the test case will be useful.
I tried to use the zk but the problem is we will not be sure if that server is 
about to be expired server or current new server. 

 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


 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-04 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


 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-04 Thread ramkrishna.s.vasudevan (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268473#comment-13268473
 ] 

ramkrishna.s.vasudevan commented on HBASE-5916:
---

Just a try, need to do some more testing on it. Uploaded to get some feedback.

 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


 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-04 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.patch

Attached patch is for 0.94.
Trunk has some protobuf changes so the test case needs to be updated.
Again just another way of trying to address this problem.  Please provide your 
feedback.

 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


 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-5867) Improve Compaction Throttle Default

2012-05-04 Thread Nicolas Spiegelberg (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-5867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nicolas Spiegelberg updated HBASE-5867:
---

Status: Patch Available  (was: Open)

 Improve Compaction Throttle Default
 ---

 Key: HBASE-5867
 URL: https://issues.apache.org/jira/browse/HBASE-5867
 Project: HBase
  Issue Type: Improvement
Reporter: Nicolas Spiegelberg
Assignee: Nicolas Spiegelberg
Priority: Minor
 Attachments: D2943.1.patch, HBASE-5867-trunk.patch


 We recently had a production issue where our compactions fell behind because 
 our compaction throttle was improperly tuned and accidentally upgraded all 
 compactions to the large pool.  The default from HBASE-3877 makes 1 bad 
 assumption: the default number of flushed files in a compaction.  Currently 
 the algorithm is:
 throttleSize ~= flushSize * 2
 This assumes that the basic compaction utilizes 3 files and that all 3 files 
 are compressed.  In this case, hbase.hstore.compaction.min == 6  the 
 values were not very compressible.  Both conditions should be taken into 
 consideration.  As a default, it is less damaging for the large thread to be 
 slightly higher than it needs to be versus having everything accidentally 
 promoted.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-5867) Improve Compaction Throttle Default

2012-05-04 Thread Nicolas Spiegelberg (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-5867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nicolas Spiegelberg updated HBASE-5867:
---

Attachment: HBASE-5867-trunk.patch

straightforward port from 89fb

 Improve Compaction Throttle Default
 ---

 Key: HBASE-5867
 URL: https://issues.apache.org/jira/browse/HBASE-5867
 Project: HBase
  Issue Type: Improvement
Reporter: Nicolas Spiegelberg
Assignee: Nicolas Spiegelberg
Priority: Minor
 Attachments: D2943.1.patch, HBASE-5867-trunk.patch


 We recently had a production issue where our compactions fell behind because 
 our compaction throttle was improperly tuned and accidentally upgraded all 
 compactions to the large pool.  The default from HBASE-3877 makes 1 bad 
 assumption: the default number of flushed files in a compaction.  Currently 
 the algorithm is:
 throttleSize ~= flushSize * 2
 This assumes that the basic compaction utilizes 3 files and that all 3 files 
 are compressed.  In this case, hbase.hstore.compaction.min == 6  the 
 values were not very compressible.  Both conditions should be taken into 
 consideration.  As a default, it is less damaging for the large thread to be 
 slightly higher than it needs to be versus having everything accidentally 
 promoted.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-04 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268481#comment-13268481
 ] 

Hadoop QA commented on HBASE-5875:
--

-1 overall.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12525640/HBASE-5875_0.94.patch
  against trunk revision .

+1 @author.  The patch does not contain any @author tags.

+1 tests included.  The patch appears to include 9 new or modified tests.

-1 patch.  The patch command could not apply the patch.

Console output: 
https://builds.apache.org/job/PreCommit-HBASE-Build/1765//console

This message is automatically generated.

 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


 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-5902) Some scripts are not executable

2012-05-04 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268491#comment-13268491
 ] 

Hudson commented on HBASE-5902:
---

Integrated in HBase-0.94 #179 (See 
[https://builds.apache.org/job/HBase-0.94/179/])
HBASE-5902 Some scripts are not executable (Revision 1334020)

 Result = FAILURE
stack : 
Files : 
* /hbase/branches/0.94/bin/graceful_stop.sh
* /hbase/branches/0.94/bin/local-master-backup.sh
* /hbase/branches/0.94/bin/local-regionservers.sh


 Some scripts are not executable
 ---

 Key: HBASE-5902
 URL: https://issues.apache.org/jira/browse/HBASE-5902
 Project: HBase
  Issue Type: Bug
  Components: scripts
Affects Versions: 0.96.0
Reporter: nkeywal
Assignee: nkeywal
Priority: Trivial
 Fix For: 0.96.0, 0.94.1

 Attachments: 5902.v1.patch, 5902v2.txt


 -rw-rw-r--  graceful_stop.sh
 -rw-rw-r--  hbase-config.sh
 -rw-rw-r--  local-master-backup.sh
 -rw-rw-r--  local-regionservers.sh

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-04 Thread Zhihong Yu (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268502#comment-13268502
 ] 

Zhihong Yu commented on HBASE-5916:
---

{code}
+   * Verifies HBASE-5816. Here before the master splits the HLog if any new RS 
checks in it should
{code}
The JIRA should be HBASE-5916, right ?

 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


 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] [Created] (HBASE-5939) Add an autorestart option in the start scripts

2012-05-04 Thread nkeywal (JIRA)
nkeywal created HBASE-5939:
--

 Summary: Add an autorestart option in the start scripts
 Key: HBASE-5939
 URL: https://issues.apache.org/jira/browse/HBASE-5939
 Project: HBase
  Issue Type: Improvement
  Components: master, regionserver, scripts
Affects Versions: 0.96.0
Reporter: nkeywal
Assignee: nkeywal
Priority: Minor


When a binary dies on a server, we don't try to restart it while it would be 
possible in most cases.

We can have something as:
loop
 start
 wait
 if cleanStop then exit
 if already stopped less than 5 minutes ago sleep 1 minute
endloop

This is simple for master  backup master, a little bit more complex for the 
region server as it can be stopped by a script or by the shutdown procedure.

On a long long term it could allow a restart with exactly the same assignments.





--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-5867) Improve Compaction Throttle Default

2012-05-04 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268522#comment-13268522
 ] 

Hadoop QA commented on HBASE-5867:
--

-1 overall.  Here are the results of testing the latest attachment 
  
http://issues.apache.org/jira/secure/attachment/12525641/HBASE-5867-trunk.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.regionserver.wal.TestLogRollingNoCluster

Test results: 
https://builds.apache.org/job/PreCommit-HBASE-Build/1764//testReport/
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/1764//artifact/trunk/patchprocess/newPatchFindbugsWarnings.html
Console output: 
https://builds.apache.org/job/PreCommit-HBASE-Build/1764//console

This message is automatically generated.

 Improve Compaction Throttle Default
 ---

 Key: HBASE-5867
 URL: https://issues.apache.org/jira/browse/HBASE-5867
 Project: HBase
  Issue Type: Improvement
Reporter: Nicolas Spiegelberg
Assignee: Nicolas Spiegelberg
Priority: Minor
 Attachments: D2943.1.patch, HBASE-5867-trunk.patch


 We recently had a production issue where our compactions fell behind because 
 our compaction throttle was improperly tuned and accidentally upgraded all 
 compactions to the large pool.  The default from HBASE-3877 makes 1 bad 
 assumption: the default number of flushed files in a compaction.  Currently 
 the algorithm is:
 throttleSize ~= flushSize * 2
 This assumes that the basic compaction utilizes 3 files and that all 3 files 
 are compressed.  In this case, hbase.hstore.compaction.min == 6  the 
 values were not very compressible.  Both conditions should be taken into 
 consideration.  As a default, it is less damaging for the large thread to be 
 slightly higher than it needs to be versus having everything accidentally 
 promoted.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-04 Thread ramkrishna.s.vasudevan (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268524#comment-13268524
 ] 

ramkrishna.s.vasudevan commented on HBASE-5916:
---

Ooh.. Yes it is HBASE-5916.  

 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


 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-04 Thread Zhihong Yu (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268525#comment-13268525
 ] 

Zhihong Yu commented on HBASE-5875:
---

The following change is for debugging, right ? If so, please change log level 
accordingly:
{code}
+}catch(NotServingRegionException nsre){
+  LOG.info(Failed verification of  + Bytes.toStringBinary(regionName) +
+   at address= + address + ;  + t);
+  throw nsre;
{code}
{code}
+} catch (NotServingRegionException nsre) {
+  if(rit == true){
+// the root region location is available.
{code}
People unfamiliar with processRegionInTransitionAndBlockUntilAssigned() may get 
confused by the code above. rit actually means root region has come out of 
transition. So rit should be named accordingly.
{code}
+  public void setServerShutdownHandlerEnabled(boolean 
setServerShutDownEnabled) {
{code}
The above method should be made package-private. Append 'ForTest' to the end of 
method name would help clarify its purpose.

 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


 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-5889) Remove HRegionInterface

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

[ 
https://issues.apache.org/jira/browse/HBASE-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268526#comment-13268526
 ] 

jirapos...@reviews.apache.org commented on HBASE-5889:
--



bq.  On 2012-05-04 01:08:06, Michael Stack wrote:
bq.   src/main/java/org/apache/hadoop/hbase/protobuf/ProtobufUtil.java, line 
1295
bq.   
https://reviews.apache.org/r/4993/diff/1/?file=106388#file106388line1295
bq.  
bq.   HRegionServer util might be better place for this yes.  Or could 
they be put into a new class, RegionServerUtil in the regionserver package?  
Maybe they don't have to be public methods if done this way?
bq.   
bq.   Either sounds good to me boss.

It is good to have a new class RegionServerUtil.  Will do.


- Jimmy


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/4993/#review7539
---


On 2012-05-03 17:27:50, Jimmy Xiang wrote:
bq.  
bq.  ---
bq.  This is an automatically generated e-mail. To reply, visit:
bq.  https://reviews.apache.org/r/4993/
bq.  ---
bq.  
bq.  (Updated 2012-05-03 17:27:50)
bq.  
bq.  
bq.  Review request for hbase.
bq.  
bq.  
bq.  Summary
bq.  ---
bq.  
bq.  Removed HRegionInterface, and cleaned up the HRegionServer, moved pb code 
from RegionServer back to HRegionServer.
bq.  
bq.  The goal is to avoid two copies of region server code to maintain, and 
make it possible to avoid data type conversion in the sever side.
bq.  
bq.  Fixed some unit tests.  Now all region server unit tests test the new pb 
functions.
bq.  
bq.  Enhanced getServerInfo so that it returns the webui port too.
bq.  
bq.  
bq.  This addresses bug HBASE-5889.
bq.  https://issues.apache.org/jira/browse/HBASE-5889
bq.  
bq.  
bq.  Diffs
bq.  -
bq.  
bq.conf/hbase-policy.xml e45f23c 
bq.
security/src/main/java/org/apache/hadoop/hbase/security/HBasePolicyProvider.java
 0c4b4cb 
bq.
src/main/jamon/org/apache/hadoop/hbase/tmpl/regionserver/RSStatusTmpl.jamon 
87f04f4 
bq.src/main/java/org/apache/hadoop/hbase/HConstants.java a9d80a0 
bq.src/main/java/org/apache/hadoop/hbase/client/HBaseAdmin.java e3912c2 
bq.src/main/java/org/apache/hadoop/hbase/ipc/HBaseRpcMetrics.java fc9176d 
bq.src/main/java/org/apache/hadoop/hbase/ipc/HRegionInterface.java 757f98e 
bq.src/main/java/org/apache/hadoop/hbase/mapreduce/TableOutputFormat.java 
cd9b528 
bq.src/main/java/org/apache/hadoop/hbase/master/CatalogJanitor.java 79d5fdd 
bq.src/main/java/org/apache/hadoop/hbase/protobuf/ProtobufUtil.java 212ee3e 
bq.src/main/java/org/apache/hadoop/hbase/protobuf/RequestConverter.java 
d1e0993 
bq.src/main/java/org/apache/hadoop/hbase/protobuf/ResponseConverter.java 
81603af 
bq.
src/main/java/org/apache/hadoop/hbase/protobuf/generated/AdminProtos.java 
fbf0127 
bq.
src/main/java/org/apache/hadoop/hbase/protobuf/generated/ClientProtos.java 
db1333b 
bq.
src/main/java/org/apache/hadoop/hbase/protobuf/generated/HBaseProtos.java 
ae2094d 
bq.src/main/java/org/apache/hadoop/hbase/protobuf/generated/RPCProtos.java 
8b45f03 
bq.
src/main/java/org/apache/hadoop/hbase/protobuf/generated/ZooKeeperProtos.java 
827fb23 
bq.src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java 
96ac8bd 
bq.
src/main/java/org/apache/hadoop/hbase/regionserver/HRegionThriftServer.java 
4cb070e 
bq.src/main/java/org/apache/hadoop/hbase/regionserver/RegionServer.java 
c2c89ea 
bq.src/main/protobuf/Admin.proto 2ad6fb0 
bq.src/main/protobuf/RPC.proto 105fb3f 
bq.src/main/resources/hbase-default.xml f54b345 
bq.src/main/resources/hbase-webapps/master/table.jsp ca7310c 
bq.src/test/java/org/apache/hadoop/hbase/TestDrainingServer.java a1992c3 
bq.src/test/java/org/apache/hadoop/hbase/TestGlobalMemStoreSize.java 
ad77e0a 
bq.src/test/java/org/apache/hadoop/hbase/TestRegionRebalancing.java 5574b7f 
bq.src/test/java/org/apache/hadoop/hbase/catalog/TestCatalogTracker.java 
3dfc94e 
bq.
src/test/java/org/apache/hadoop/hbase/client/HConnectionTestingUtility.java 
42092b7 
bq.src/test/java/org/apache/hadoop/hbase/client/TestAdmin.java c270e28 
bq.src/test/java/org/apache/hadoop/hbase/client/TestMultiParallel.java 
c36272f 
bq.
src/test/java/org/apache/hadoop/hbase/coprocessor/TestMasterObserver.java 
bdec3ee 
bq.
src/test/java/org/apache/hadoop/hbase/coprocessor/TestRegionObserverInterface.java
 7dbba66 
bq.
src/test/java/org/apache/hadoop/hbase/mapreduce/TestLoadIncrementalHFilesSplitRecovery.java
 3acb988 
bq.
src/test/java/org/apache/hadoop/hbase/master/TestDistributedLogSplitting.java 
eb546a5 
bq.

[jira] [Commented] (HBASE-5916) RS restart just before master intialization we make the cluster non operative

2012-05-04 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268529#comment-13268529
 ] 

Hadoop QA commented on HBASE-5916:
--

-1 overall.  Here are the results of testing the latest attachment 
  
http://issues.apache.org/jira/secure/attachment/12525639/HBASE-5916_trunk.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 failed these unit tests:
   
org.apache.hadoop.hbase.regionserver.TestServerCustomProtocol
  org.apache.hadoop.hbase.master.TestAssignmentManager

Test results: 
https://builds.apache.org/job/PreCommit-HBASE-Build/1766//testReport/
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/1766//artifact/trunk/patchprocess/newPatchFindbugsWarnings.html
Console output: 
https://builds.apache.org/job/PreCommit-HBASE-Build/1766//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


 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-5844) Delete the region servers znode after a regions server crash

2012-05-04 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268530#comment-13268530
 ] 

Hudson commented on HBASE-5844:
---

Integrated in HBase-TRUNK #2848 (See 
[https://builds.apache.org/job/HBase-TRUNK/2848/])
HBASE-5844 Delete the region servers znode after a regions server crash 
(Revision 1334028)

 Result = FAILURE
stack : 
Files : 
* /hbase/trunk/bin/hbase-daemon.sh
* 
/hbase/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java


 Delete the region servers znode after a regions server crash
 

 Key: HBASE-5844
 URL: https://issues.apache.org/jira/browse/HBASE-5844
 Project: HBase
  Issue Type: Improvement
  Components: regionserver, scripts
Affects Versions: 0.96.0
Reporter: nkeywal
Assignee: nkeywal
 Fix For: 0.96.0

 Attachments: 5844.v1.patch, 5844.v2.patch, 5844.v3.patch, 
 5844.v3.patch, 5844.v4.patch


 today, if the regions server crashes, its znode is not deleted in ZooKeeper. 
 So the recovery process will stop only after a timeout, usually 30s.
 By deleting the znode in start script, we remove this delay and the recovery 
 starts immediately.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-5847) Support createTable(splitKeys) in Thrift

2012-05-04 Thread Phabricator (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-5847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phabricator updated HBASE-5847:
---

Attachment: D3039.1.patch

nspiegelberg requested code review of [jira] [HBASE-5847] Support 
createTable(splitKeys) in Thrift.
Reviewers: mbautin, Karthik, stack, JIRA

  The Thrift API does not allow a user to create a table with
  multiple split keys. This is needed for a handful of new internal
  projects that are written in PHP/C++.

TEST PLAN
   - mvn test -Dtest=TestThriftServer

REVISION DETAIL
  https://reviews.facebook.net/D3039

AFFECTED FILES
  src/main/java/org/apache/hadoop/hbase/thrift/ThriftServerRunner.java
  src/main/java/org/apache/hadoop/hbase/thrift/generated/Hbase.java
  src/main/java/org/apache/hadoop/hbase/thrift/generated/TRowResult.java
  src/main/resources/org/apache/hadoop/hbase/thrift/Hbase.thrift


 Support createTable(splitKeys) in Thrift
 

 Key: HBASE-5847
 URL: https://issues.apache.org/jira/browse/HBASE-5847
 Project: HBase
  Issue Type: Improvement
Reporter: Nicolas Spiegelberg
Assignee: Nicolas Spiegelberg
Priority: Trivial
 Attachments: D3039.1.patch


 The Thrift API does not allow a user to create a table with multiple split 
 keys.  This is needed for a handful of new internal projects that are written 
 in PHP/C++.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-5902) Some scripts are not executable

2012-05-04 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268531#comment-13268531
 ] 

Hudson commented on HBASE-5902:
---

Integrated in HBase-TRUNK #2848 (See 
[https://builds.apache.org/job/HBase-TRUNK/2848/])
HBASE-5902 Some scripts are not executable (Revision 1334019)

 Result = FAILURE
stack : 
Files : 
* /hbase/trunk/bin/graceful_stop.sh
* /hbase/trunk/bin/local-master-backup.sh
* /hbase/trunk/bin/local-regionservers.sh


 Some scripts are not executable
 ---

 Key: HBASE-5902
 URL: https://issues.apache.org/jira/browse/HBASE-5902
 Project: HBase
  Issue Type: Bug
  Components: scripts
Affects Versions: 0.96.0
Reporter: nkeywal
Assignee: nkeywal
Priority: Trivial
 Fix For: 0.96.0, 0.94.1

 Attachments: 5902.v1.patch, 5902v2.txt


 -rw-rw-r--  graceful_stop.sh
 -rw-rw-r--  hbase-config.sh
 -rw-rw-r--  local-master-backup.sh
 -rw-rw-r--  local-regionservers.sh

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-5584) Coprocessor hooks can be called in the respective handlers

2012-05-04 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-3.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


 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-04 Thread ramkrishna.s.vasudevan (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268536#comment-13268536
 ] 

ramkrishna.s.vasudevan commented on HBASE-5584:
---

Removed the commented lines.
@Andy
I think you are ok on commit right?

bq.Sorry, not clear, I am +0 on the patch itself as long as we're all ok with 
the above
Devs, can you take a look at it?

 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


 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-04 Thread ramkrishna.s.vasudevan (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268539#comment-13268539
 ] 

ramkrishna.s.vasudevan commented on HBASE-5916:
---

Failure in testcase 
{code}
java.lang.ClassCastException: 
org.apache.hadoop.hbase.Server$$EnhancerByMockitoWithCGLIB$$9bdf744 cannot be 
cast to org.apache.hadoop.hbase.master.HMaster
at 
org.apache.hadoop.hbase.master.AssignmentManager.rebuildUserRegions(AssignmentManager.java:2480)
at 
org.apache.hadoop.hbase.master.AssignmentManager.joinCluster(AssignmentManager.java:359)
at 
org.apache.hadoop.hbase.master.AssignmentManager.joinCluster(AssignmentManager.java:379)
at 
org.apache.hadoop.hbase.master.TestAssignmentManager$2.run(TestAssignmentManager.java:705)
{code}
The above exception is due to 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


 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-5494) Introduce a zk hosted table-wide read/write lock so only one table operation at a time

2012-05-04 Thread Phabricator (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268541#comment-13268541
 ] 

Phabricator commented on HBASE-5494:


Kannan has accepted the revision [jira] [HBASE-5494] [89-fb] Table-level locks 
for schema changing operations..

  Looks good! One minor comment.

INLINE COMMENTS
  src/main/java/org/apache/hadoop/hbase/master/HMaster.java:1391 for symmetry 
with other operations (like disable/enable/etc.), should we do this injection 
after acquiring the lock? With the latest update to the diff this order has 
changed.

  If we do want events before lock acquisition, we could introduce new ones in 
the future like HMASTER_BEFORE_CREATE_LOCK or something like that.

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


 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] [Updated] (HBASE-5847) Support createTable(splitKeys) in Thrift

2012-05-04 Thread Zhihong Yu (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-5847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Zhihong Yu updated HBASE-5847:
--

Hadoop Flags: Reviewed
  Status: Patch Available  (was: Open)

 Support createTable(splitKeys) in Thrift
 

 Key: HBASE-5847
 URL: https://issues.apache.org/jira/browse/HBASE-5847
 Project: HBase
  Issue Type: Improvement
Reporter: Nicolas Spiegelberg
Assignee: Nicolas Spiegelberg
Priority: Trivial
 Attachments: D3039.1.patch


 The Thrift API does not allow a user to create a table with multiple split 
 keys.  This is needed for a handful of new internal projects that are written 
 in PHP/C++.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-5847) Support createTable(splitKeys) in Thrift

2012-05-04 Thread Phabricator (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268544#comment-13268544
 ] 

Phabricator commented on HBASE-5847:


tedyu has accepted the revision [jira] [HBASE-5847] Support 
createTable(splitKeys) in Thrift.

REVISION DETAIL
  https://reviews.facebook.net/D3039

BRANCH
  5847


 Support createTable(splitKeys) in Thrift
 

 Key: HBASE-5847
 URL: https://issues.apache.org/jira/browse/HBASE-5847
 Project: HBase
  Issue Type: Improvement
Reporter: Nicolas Spiegelberg
Assignee: Nicolas Spiegelberg
Priority: Trivial
 Attachments: D3039.1.patch


 The Thrift API does not allow a user to create a table with multiple split 
 keys.  This is needed for a handful of new internal projects that are written 
 in PHP/C++.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-04 Thread Phabricator (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268546#comment-13268546
 ] 

Phabricator commented on HBASE-5494:


avf has commented on the revision [jira] [HBASE-5494] [89-fb] Table-level 
locks for schema changing operations..

INLINE COMMENTS
  src/main/java/org/apache/hadoop/hbase/master/HMaster.java:1391 Great catch. I 
mentally thought I did this, but I did not. For operations that do non-trivial 
work before locking, I think it makes sense to have BEFORE_LOCK events as well. 
Will do this.

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


 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-5847) Support createTable(splitKeys) in Thrift

2012-05-04 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268548#comment-13268548
 ] 

Hadoop QA commented on HBASE-5847:
--

-1 overall.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12525648/D3039.1.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/1768//console

This message is automatically generated.

 Support createTable(splitKeys) in Thrift
 

 Key: HBASE-5847
 URL: https://issues.apache.org/jira/browse/HBASE-5847
 Project: HBase
  Issue Type: Improvement
Reporter: Nicolas Spiegelberg
Assignee: Nicolas Spiegelberg
Priority: Trivial
 Attachments: D3039.1.patch


 The Thrift API does not allow a user to create a table with multiple split 
 keys.  This is needed for a handful of new internal projects that are written 
 in PHP/C++.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-4411) When copying tables/CFs, allow CF names to be changed

2012-05-04 Thread Jonathan Hsieh (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-4411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jonathan Hsieh updated HBASE-4411:
--

Assignee: Dave Revell

 When copying tables/CFs, allow CF names to be changed
 -

 Key: HBASE-4411
 URL: https://issues.apache.org/jira/browse/HBASE-4411
 Project: HBase
  Issue Type: Improvement
  Components: mapreduce
Reporter: Dave Revell
Assignee: Dave Revell
Priority: Minor
 Fix For: 0.92.0

 Attachments: HBASE-4411-trunk-v2.patch, HBASE-4411-trunk.patch


 The CopyTable mapreduce job uses the Import class to read CFs in one table 
 and output them to a different table. Here is a patch that allows different 
 CF names to be used in the source and destination.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-5847) Support createTable(splitKeys) in Thrift

2012-05-04 Thread Zhihong Yu (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268566#comment-13268566
 ] 

Zhihong Yu commented on HBASE-5847:
---

Looks like src/main/java/org/apache/hadoop/hbase/thrift/generated/Hbase.java 
needs to be generated again.

 Support createTable(splitKeys) in Thrift
 

 Key: HBASE-5847
 URL: https://issues.apache.org/jira/browse/HBASE-5847
 Project: HBase
  Issue Type: Improvement
Reporter: Nicolas Spiegelberg
Assignee: Nicolas Spiegelberg
Priority: Trivial
 Attachments: D3039.1.patch


 The Thrift API does not allow a user to create a table with multiple split 
 keys.  This is needed for a handful of new internal projects that are written 
 in PHP/C++.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-5940) HBase in-cluster backup based on the HDFS hardlink

2012-05-04 Thread Liyin Tang (JIRA)
Liyin Tang created HBASE-5940:
-

 Summary: HBase in-cluster backup based on the HDFS hardlink
 Key: HBASE-5940
 URL: https://issues.apache.org/jira/browse/HBASE-5940
 Project: HBase
  Issue Type: New Feature
Reporter: Liyin Tang
Assignee: Liyin Tang


The motivation of introducing the HardLink operation/api in HDFS is to get a 
full copy of the file without copying the bytes. 
So users/applications can create multiple hard links to the same source file 
instantly. 

And HBase can make full use of the hard-link to generate the in-cluster backup 
snapshot instantly. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-04 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268569#comment-13268569
 ] 

Hadoop QA commented on HBASE-5584:
--

+1 overall.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12525649/HBASE-5584-3.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/1767//testReport/
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/1767//artifact/trunk/patchprocess/newPatchFindbugsWarnings.html
Console output: 
https://builds.apache.org/job/PreCommit-HBASE-Build/1767//console

This message is automatically generated.

 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


 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-5877) When a query fails because the region has moved, let the regionserver return the new address to the client

2012-05-04 Thread nkeywal (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-5877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

nkeywal updated HBASE-5877:
---

Status: Open  (was: Patch Available)

 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.v1.patch, 5877.v12.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




[jira] [Commented] (HBASE-5889) Remove HRegionInterface

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

[ 
https://issues.apache.org/jira/browse/HBASE-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268600#comment-13268600
 ] 

jirapos...@reviews.apache.org commented on HBASE-5889:
--


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/4993/
---

(Updated 2012-05-04 18:16:37.788666)


Review request for hbase.


Changes
---

Addressed Stack's comments.


Summary
---

Removed HRegionInterface, and cleaned up the HRegionServer, moved pb code from 
RegionServer back to HRegionServer.

The goal is to avoid two copies of region server code to maintain, and make it 
possible to avoid data type conversion in the sever side.

Fixed some unit tests.  Now all region server unit tests test the new pb 
functions.

Enhanced getServerInfo so that it returns the webui port too.


This addresses bug HBASE-5889.
https://issues.apache.org/jira/browse/HBASE-5889


Diffs (updated)
-

  conf/hbase-policy.xml e45f23c 
  
security/src/main/java/org/apache/hadoop/hbase/security/HBasePolicyProvider.java
 fda40cc 
  src/main/jamon/org/apache/hadoop/hbase/tmpl/regionserver/RSStatusTmpl.jamon 
87f04f4 
  src/main/java/org/apache/hadoop/hbase/HConstants.java a9d80a0 
  src/main/java/org/apache/hadoop/hbase/catalog/CatalogTracker.java 8a383e4 
  src/main/java/org/apache/hadoop/hbase/client/HBaseAdmin.java e3912c2 
  src/main/java/org/apache/hadoop/hbase/client/HConnectionManager.java 11d8bf9 
  src/main/java/org/apache/hadoop/hbase/client/HTable.java b8290e4 
  src/main/java/org/apache/hadoop/hbase/ipc/ExecRPCInvoker.java 578b2b2 
  src/main/java/org/apache/hadoop/hbase/ipc/HBaseRpcMetrics.java fc9176d 
  src/main/java/org/apache/hadoop/hbase/ipc/HRegionInterface.java 757f98e 
  src/main/java/org/apache/hadoop/hbase/mapreduce/LoadIncrementalHFiles.java 
9e4ada9 
  src/main/java/org/apache/hadoop/hbase/mapreduce/TableOutputFormat.java 
cd9b528 
  src/main/java/org/apache/hadoop/hbase/master/CatalogJanitor.java 79d5fdd 
  src/main/java/org/apache/hadoop/hbase/master/ServerManager.java 6ba8ab0 
  src/main/java/org/apache/hadoop/hbase/protobuf/ProtobufUtil.java 212ee3e 
  src/main/java/org/apache/hadoop/hbase/protobuf/RequestConverter.java d1e0993 
  src/main/java/org/apache/hadoop/hbase/protobuf/ResponseConverter.java 81603af 
  src/main/java/org/apache/hadoop/hbase/protobuf/generated/AdminProtos.java 
fbf0127 
  src/main/java/org/apache/hadoop/hbase/protobuf/generated/ClientProtos.java 
db1333b 
  src/main/java/org/apache/hadoop/hbase/protobuf/generated/HBaseProtos.java 
ae2094d 
  src/main/java/org/apache/hadoop/hbase/protobuf/generated/RPCProtos.java 
8b45f03 
  src/main/java/org/apache/hadoop/hbase/protobuf/generated/ZooKeeperProtos.java 
827fb23 
  src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java 8c8381b 
  src/main/java/org/apache/hadoop/hbase/regionserver/HRegionThriftServer.java 
4cb070e 
  src/main/java/org/apache/hadoop/hbase/regionserver/RegionServer.java c2c89ea 
  src/main/java/org/apache/hadoop/hbase/regionserver/RegionServerUtil.java 
PRE-CREATION 
  
src/main/java/org/apache/hadoop/hbase/replication/regionserver/ReplicationSource.java
 5050df0 
  src/main/java/org/apache/hadoop/hbase/util/HBaseFsck.java 7b4f4a2 
  src/main/java/org/apache/hadoop/hbase/util/HBaseFsckRepair.java 9c3c9ef 
  src/main/protobuf/Admin.proto 2ad6fb0 
  src/main/protobuf/RPC.proto 105fb3f 
  src/main/resources/hbase-default.xml f54b345 
  src/test/java/org/apache/hadoop/hbase/TestDrainingServer.java a1992c3 
  src/test/java/org/apache/hadoop/hbase/TestGlobalMemStoreSize.java ad77e0a 
  src/test/java/org/apache/hadoop/hbase/TestRegionRebalancing.java 5574b7f 
  src/test/java/org/apache/hadoop/hbase/catalog/TestCatalogTracker.java 3dfc94e 
  src/test/java/org/apache/hadoop/hbase/client/HConnectionTestingUtility.java 
42092b7 
  src/test/java/org/apache/hadoop/hbase/client/TestAdmin.java c270e28 
  src/test/java/org/apache/hadoop/hbase/client/TestFromClientSide3.java 0079b13 
  src/test/java/org/apache/hadoop/hbase/client/TestMultiParallel.java c36272f 
  src/test/java/org/apache/hadoop/hbase/coprocessor/TestMasterObserver.java 
bdec3ee 
  
src/test/java/org/apache/hadoop/hbase/coprocessor/TestRegionObserverInterface.java
 7dbba66 
  
src/test/java/org/apache/hadoop/hbase/mapreduce/TestLoadIncrementalHFilesSplitRecovery.java
 3acb988 
  src/test/java/org/apache/hadoop/hbase/master/TestDistributedLogSplitting.java 
eb546a5 
  src/test/java/org/apache/hadoop/hbase/master/TestMasterFailover.java ceba5cd 
  
src/test/java/org/apache/hadoop/hbase/master/TestMasterRestartAfterDisablingTable.java
 ec08b17 
  src/test/java/org/apache/hadoop/hbase/master/TestRollingRestart.java 30c6cf1 
  src/test/java/org/apache/hadoop/hbase/master/TestZKBasedOpenCloseRegion.java 
8c3f67e 

[jira] [Updated] (HBASE-5889) Remove HRegionInterface

2012-05-04 Thread Jimmy Xiang (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jimmy Xiang updated HBASE-5889:
---

Status: Open  (was: Patch Available)

 Remove HRegionInterface
 ---

 Key: HBASE-5889
 URL: https://issues.apache.org/jira/browse/HBASE-5889
 Project: HBase
  Issue Type: Improvement
  Components: client, ipc, regionserver
Affects Versions: 0.96.0
Reporter: Jimmy Xiang
Assignee: Jimmy Xiang
 Fix For: 0.96.0

 Attachments: hbase-5889_v3.patch, hbase_5889.patch, 
 hbase_5889_v2.patch


 As a step to move internals to PB, so as to avoid the conversion for 
 performance reason, we should remove the HRegionInterface. 
 Therefore region server only supports ClientProtocol and AdminProtocol.  
 Later on, HRegion can work with PB messages directly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-5889) Remove HRegionInterface

2012-05-04 Thread Jimmy Xiang (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jimmy Xiang updated HBASE-5889:
---

Attachment: hbase-5889_v3.patch

 Remove HRegionInterface
 ---

 Key: HBASE-5889
 URL: https://issues.apache.org/jira/browse/HBASE-5889
 Project: HBase
  Issue Type: Improvement
  Components: client, ipc, regionserver
Affects Versions: 0.96.0
Reporter: Jimmy Xiang
Assignee: Jimmy Xiang
 Fix For: 0.96.0

 Attachments: hbase-5889_v3.patch, hbase_5889.patch, 
 hbase_5889_v2.patch


 As a step to move internals to PB, so as to avoid the conversion for 
 performance reason, we should remove the HRegionInterface. 
 Therefore region server only supports ClientProtocol and AdminProtocol.  
 Later on, HRegion can work with PB messages directly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-5889) Remove HRegionInterface

2012-05-04 Thread Jimmy Xiang (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jimmy Xiang updated HBASE-5889:
---

Status: Patch Available  (was: Open)

 Remove HRegionInterface
 ---

 Key: HBASE-5889
 URL: https://issues.apache.org/jira/browse/HBASE-5889
 Project: HBase
  Issue Type: Improvement
  Components: client, ipc, regionserver
Affects Versions: 0.96.0
Reporter: Jimmy Xiang
Assignee: Jimmy Xiang
 Fix For: 0.96.0

 Attachments: hbase-5889_v3.patch, hbase_5889.patch, 
 hbase_5889_v2.patch


 As a step to move internals to PB, so as to avoid the conversion for 
 performance reason, we should remove the HRegionInterface. 
 Therefore region server only supports ClientProtocol and AdminProtocol.  
 Later on, HRegion can work with PB messages directly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-5877) When a query fails because the region has moved, let the regionserver return the new address to the client

2012-05-04 Thread nkeywal (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-5877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

nkeywal updated HBASE-5877:
---

Attachment: 5877.v15.patch

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




[jira] [Updated] (HBASE-5877) When a query fails because the region has moved, let the regionserver return the new address to the client

2012-05-04 Thread nkeywal (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-5877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

nkeywal updated HBASE-5877:
---

Status: Patch Available  (was: Open)

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




[jira] [Updated] (HBASE-5494) Introduce a zk hosted table-wide read/write lock so only one table operation at a time

2012-05-04 Thread Phabricator (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-5494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phabricator updated HBASE-5494:
---

Attachment: D2997.6.patch

avf updated the revision [jira] [HBASE-5494] [89-fb] Table-level locks for 
schema changing operations..
Reviewers: Kannan, mbautin, Liyin, JIRA

  Move InjectionEventHandler.processEvent() call after lock acquisition in 
createTable(), explain the way node is deleted before watch is set race 
condition is handled in more detail.

REVISION DETAIL
  https://reviews.facebook.net/D2997

AFFECTED FILES
  src/main/java/org/apache/hadoop/hbase/HConstants.java
  src/main/java/org/apache/hadoop/hbase/TableLockTimeoutException.java
  src/main/java/org/apache/hadoop/hbase/master/HMaster.java
  src/main/java/org/apache/hadoop/hbase/master/TableLockManager.java
  src/main/java/org/apache/hadoop/hbase/util/InjectionEvent.java
  src/main/java/org/apache/hadoop/hbase/util/InjectionHandler.java
  src/main/java/org/apache/hadoop/hbase/zookeeper/DistributedLock.java
  src/main/java/org/apache/hadoop/hbase/zookeeper/ZooKeeperWrapper.java
  src/test/java/org/apache/hadoop/hbase/master/TestSchemaModificationLocks.java
  src/test/java/org/apache/hadoop/hbase/util/DelayInducingInjectionHandler.java
  src/test/java/org/apache/hadoop/hbase/zookeeper/TestDistributedLock.java


 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-5494) Introduce a zk hosted table-wide read/write lock so only one table operation at a time

2012-05-04 Thread Phabricator (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268625#comment-13268625
 ] 

Phabricator commented on HBASE-5494:


Kannan has commented on the revision [jira] [HBASE-5494] [89-fb] Table-level 
locks for schema changing operations..

  lgtm!

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-5889) Remove HRegionInterface

2012-05-04 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268628#comment-13268628
 ] 

Hadoop QA commented on HBASE-5889:
--

-1 overall.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12525658/hbase-5889_v3.patch
  against trunk revision .

+1 @author.  The patch does not contain any @author tags.

+1 tests included.  The patch appears to include 63 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 failed these unit tests:
   org.apache.hadoop.hbase.replication.TestReplication

Test results: 
https://builds.apache.org/job/PreCommit-HBASE-Build/1769//testReport/
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/1769//artifact/trunk/patchprocess/newPatchFindbugsWarnings.html
Console output: 
https://builds.apache.org/job/PreCommit-HBASE-Build/1769//console

This message is automatically generated.

 Remove HRegionInterface
 ---

 Key: HBASE-5889
 URL: https://issues.apache.org/jira/browse/HBASE-5889
 Project: HBase
  Issue Type: Improvement
  Components: client, ipc, regionserver
Affects Versions: 0.96.0
Reporter: Jimmy Xiang
Assignee: Jimmy Xiang
 Fix For: 0.96.0

 Attachments: hbase-5889_v3.patch, hbase_5889.patch, 
 hbase_5889_v2.patch


 As a step to move internals to PB, so as to avoid the conversion for 
 performance reason, we should remove the HRegionInterface. 
 Therefore region server only supports ClientProtocol and AdminProtocol.  
 Later on, HRegion can work with PB messages directly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-5941) improve multiDelete performance by grabbing locks ahead of time

2012-05-04 Thread Amitanand Aiyer (JIRA)
Amitanand Aiyer created HBASE-5941:
--

 Summary: improve multiDelete performance by grabbing locks ahead 
of time
 Key: HBASE-5941
 URL: https://issues.apache.org/jira/browse/HBASE-5941
 Project: HBase
  Issue Type: Improvement
  Components: regionserver
Affects Versions: 0.89.20100924, 0.89-fb, 0.94.1
Reporter: Amitanand Aiyer
Assignee: Amitanand Aiyer
Priority: Minor


Ning reported that the performance of deletes is slower than the performance of 
Puts. This should not be the case. 

On digging up, it turns out that there is a difference between multiPut and 
multiDelete in the way we grab locks.

multiPut grabs all the locks optimistically and processes the puts one by one. 
multiDelete grabs locks and releases
 them one at a time, for each delete operation, as if it were done separately. 
This may be causing a performance
 slow down for deletes. Trying to improve 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-5877) When a query fails because the region has moved, let the regionserver return the new address to the client

2012-05-04 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268649#comment-13268649
 ] 

Hadoop QA commented on HBASE-5877:
--

-1 overall.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12525660/5877.v15.patch
  against trunk revision .

+1 @author.  The patch does not contain any @author tags.

+1 tests included.  The patch appears to include 9 new or modified tests.

+1 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.client.TestMultiParallel

Test results: 
https://builds.apache.org/job/PreCommit-HBASE-Build/1770//testReport/
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/1770//artifact/trunk/patchprocess/newPatchFindbugsWarnings.html
Console output: 
https://builds.apache.org/job/PreCommit-HBASE-Build/1770//console

This message is automatically generated.

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




[jira] [Updated] (HBASE-5916) RS restart just before master intialization we make the cluster non operative

2012-05-04 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_1.patch

Updated 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


 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-04 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)

Will make use of hadoopqa to run the testcases, as am at home.

 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


 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-04 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


 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-5889) Remove HRegionInterface

2012-05-04 Thread stack (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268666#comment-13268666
 ] 

stack commented on HBASE-5889:
--

Is this good to go in Jimmy?  What comments did you address?

 Remove HRegionInterface
 ---

 Key: HBASE-5889
 URL: https://issues.apache.org/jira/browse/HBASE-5889
 Project: HBase
  Issue Type: Improvement
  Components: client, ipc, regionserver
Affects Versions: 0.96.0
Reporter: Jimmy Xiang
Assignee: Jimmy Xiang
 Fix For: 0.96.0

 Attachments: hbase-5889_v3.patch, hbase_5889.patch, 
 hbase_5889_v2.patch


 As a step to move internals to PB, so as to avoid the conversion for 
 performance reason, we should remove the HRegionInterface. 
 Therefore region server only supports ClientProtocol and AdminProtocol.  
 Later on, HRegion can work with PB messages directly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-5889) Remove HRegionInterface

2012-05-04 Thread Jimmy Xiang (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268670#comment-13268670
 ] 

Jimmy Xiang commented on HBASE-5889:


Yes, I think it is good to go.  I moved those utils like openRegion from 
ProtobufUtil to RegionServerUtil.

 Remove HRegionInterface
 ---

 Key: HBASE-5889
 URL: https://issues.apache.org/jira/browse/HBASE-5889
 Project: HBase
  Issue Type: Improvement
  Components: client, ipc, regionserver
Affects Versions: 0.96.0
Reporter: Jimmy Xiang
Assignee: Jimmy Xiang
 Fix For: 0.96.0

 Attachments: hbase-5889_v3.patch, hbase_5889.patch, 
 hbase_5889_v2.patch


 As a step to move internals to PB, so as to avoid the conversion for 
 performance reason, we should remove the HRegionInterface. 
 Therefore region server only supports ClientProtocol and AdminProtocol.  
 Later on, HRegion can work with PB messages directly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-04 Thread Zhihong Yu (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268678#comment-13268678
 ] 

Zhihong Yu commented on HBASE-5877:
---

I can reproduce the TestMultiParallel failure:
{code}
testFlushCommitsNoAbort(org.apache.hadoop.hbase.client.TestMultiParallel)  Time 
elapsed: 1.36 sec   ERROR!
java.lang.StackOverflowError
  at 
org.apache.hadoop.hbase.RegionMovedException.find(RegionMovedException.java:91)
  at 
org.apache.hadoop.hbase.RegionMovedException.find(RegionMovedException.java:108)
  at 
org.apache.hadoop.hbase.RegionMovedException.find(RegionMovedException.java:108)
  at 
org.apache.hadoop.hbase.RegionMovedException.find(RegionMovedException.java:108)
  at 
org.apache.hadoop.hbase.RegionMovedException.find(RegionMovedException.java:108)
  at 
org.apache.hadoop.hbase.RegionMovedException.find(RegionMovedException.java:108)
  at 
org.apache.hadoop.hbase.RegionMovedException.find(RegionMovedException.java:108)
{code}

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




[jira] [Created] (HBASE-5942) HConnnectionManager.getRegionServerWithRetries doesn't call afterCall properly

2012-05-04 Thread Zhihong Yu (JIRA)
Zhihong Yu created HBASE-5942:
-

 Summary: 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


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-5045) Add the table name and cf name for the next call int the task monitor

2012-05-04 Thread Phabricator (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268691#comment-13268691
 ] 

Phabricator commented on HBASE-5045:


amirshim has commented on the revision [jira] [HBASE-5045] Annotation for 
Custom Param formatting and next() RPC call info.

INLINE COMMENTS
  src/main/java/org/apache/hadoop/hbase/ipc/WritableRpcEngine.java:319 
status.setRPC a couple of lines away now takes method as a param.
  src/main/java/org/apache/hadoop/hbase/monitoring/MonitoredRPCHandler.java:45 
The real method returned by the Java reflection API... see 
MonitoredRPCHandlerImpl for more info.
  src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java:3489 This 
object is stored across RPC calls and we store the original scan, so that we 
can easily print the information about the scan in the task monitor. It needs 
to be accessible from ScanParamsFormatter
  src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java:2210 It 
doesn't have to be in here, but if not, then we have to expose some internals 
of HRS. This class needs to understand the internals, since it provides 
introspection about what it's method(s) do. i.e. If we change how we do scanner 
lookups, this class needs to change too.
  src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java:2221 
It's supposed to be strongly bound since it provides introspection about it's 
methods.
  src/main/java/org/apache/hadoop/hbase/util/ParamFormat.java:27 It's possible, 
but should be done in another diff.
  src/main/java/org/apache/hadoop/hbase/util/ParamFormatHelper.java:63 It's 
introspection on a method we control, since we force it to derive from 
ParamFormatter.  I called it getMap() to be consistent with the getMap() used 
in the TaskMonitor.
  src/main/java/org/apache/hadoop/hbase/util/ParamFormatHelper.java:102 See 
above.  I called it getMap to be consistent with the TaskMonitor functions.
  src/main/java/org/apache/hadoop/hbase/util/ParamFormatter.java:24 It formats 
information about a method call given the params it takes. PrettyPrint makes me 
think that it actually outputs the info somewhere, as opposed to a formatter 
that arranges the data for later pretty printing.  I shouldn't have put pretty 
print in so many comments.

REVISION DETAIL
  https://reviews.facebook.net/D2913

BRANCH
  add_the_table_name_and_cf_name_for_the_next_HBASE-5045_v3


 Add the table name and cf name for the next call int the task monitor
 -

 Key: HBASE-5045
 URL: https://issues.apache.org/jira/browse/HBASE-5045
 Project: HBase
  Issue Type: Improvement
Reporter: Liyin Tang
Assignee: Amir Shimoni
 Attachments: D2913.1.patch, D2913.2.patch


 In the task monitor, we don't have much information about the next call 
 compared to other operations.
 It would be nice to add the table name and cf name for each next call in the 
 task monitor.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Updated] (HBASE-5877) When a query fails because the region has moved, let the regionserver return the new address to the client

2012-05-04 Thread Zhihong Yu (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-5877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Zhihong Yu updated HBASE-5877:
--

Attachment: 5877-v16.txt

Patch v16 is able to pass TestMultiParallel.

See the following link for the reason of infinite recursion:

http://grepcode.com/file/repository.cloudera.com/content/repositories/releases/com.cloudera.hadoop/hadoop-core/0.20.2-737/org/apache/hadoop/ipc/RemoteException.java#RemoteException.unwrapRemoteException%28%29

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




[jira] [Updated] (HBASE-5045) Add the table name and cf name for the next call int the task monitor

2012-05-04 Thread Phabricator (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-5045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phabricator updated HBASE-5045:
---

Attachment: D3045.1.patch

amirshim requested code review of [jira] [HBASE-5045] Annotation for Custom 
Param formatting and next() RPC call info.
Reviewers: mbautin, Liyin, tedyu, stack, JIRA, nspiegelberg

  Porting Amir's fix from 89-fb. His original summary below.

  A method for associating pretty print classes with method calls.
  These allow you to get information about a method call given the params it was
  called with and what instance it was called on.

  The first use case is for getting info about a next() RPC call.

TEST PLAN
  Original test plan from Amir: run a script that stresses a
  regionserver with scan and next() scans, and check that the information is 
show
  in the JSON view of the TaskMonitor

REVISION DETAIL
  https://reviews.facebook.net/D3045

AFFECTED FILES
  src/main/java/org/apache/hadoop/hbase/ipc/HBaseServer.java
  src/main/java/org/apache/hadoop/hbase/ipc/WritableRpcEngine.java
  src/main/java/org/apache/hadoop/hbase/monitoring/MonitoredRPCHandler.java
  src/main/java/org/apache/hadoop/hbase/monitoring/MonitoredRPCHandlerImpl.java
  src/main/java/org/apache/hadoop/hbase/monitoring/MonitoredTask.java
  src/main/java/org/apache/hadoop/hbase/monitoring/MonitoredTaskImpl.java
  src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
  src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java
  src/main/java/org/apache/hadoop/hbase/util/ParamFormat.java
  src/main/java/org/apache/hadoop/hbase/util/ParamFormatHelper.java
  src/main/java/org/apache/hadoop/hbase/util/ParamFormatter.java
  src/test/java/org/apache/hadoop/hbase/util/TestParamFormatter.java

MANAGE HERALD DIFFERENTIAL RULES
  https://reviews.facebook.net/herald/view/differential/

WHY DID I GET THIS EMAIL?
  https://reviews.facebook.net/herald/transcript/6915/

Tip: use the X-Herald-Rules header to filter Herald messages in your client.


 Add the table name and cf name for the next call int the task monitor
 -

 Key: HBASE-5045
 URL: https://issues.apache.org/jira/browse/HBASE-5045
 Project: HBase
  Issue Type: Improvement
Reporter: Liyin Tang
Assignee: Amir Shimoni
 Attachments: D2913.1.patch, D2913.2.patch, D3045.1.patch


 In the task monitor, we don't have much information about the next call 
 compared to other operations.
 It would be nice to add the table name and cf name for each next call in the 
 task monitor.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-5699) Run with 1 WAL in HRegionServer

2012-05-04 Thread Zhihong Yu (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268697#comment-13268697
 ] 

Zhihong Yu commented on HBASE-5699:
---

bq. there is still a single HLog class, but underneath it would be multiple 
SequenceFileLogWriters
My approach is different from the above.
The new interface should be general enough that multi-HLog can be implemented 
without the requirement that HLog have multiple writers.

 Run with  1 WAL in HRegionServer
 -

 Key: HBASE-5699
 URL: https://issues.apache.org/jira/browse/HBASE-5699
 Project: HBase
  Issue Type: Improvement
Reporter: binlijin
Assignee: Li Pi



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-5045) Add the table name and cf name for the next call int the task monitor

2012-05-04 Thread Phabricator (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268700#comment-13268700
 ] 

Phabricator commented on HBASE-5045:


amirshim has commented on the revision [jira] [HBASE-5045] Annotation for 
Custom Param formatting and next() RPC call info.

  See https://reviews.facebook.net/D2913 for comments.

REVISION DETAIL
  https://reviews.facebook.net/D3045


 Add the table name and cf name for the next call int the task monitor
 -

 Key: HBASE-5045
 URL: https://issues.apache.org/jira/browse/HBASE-5045
 Project: HBase
  Issue Type: Improvement
Reporter: Liyin Tang
Assignee: Amir Shimoni
 Attachments: D2913.1.patch, D2913.2.patch, D3045.1.patch


 In the task monitor, we don't have much information about the next call 
 compared to other operations.
 It would be nice to add the table name and cf name for each next call in the 
 task monitor.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-5045) Add the table name and cf name for the next call int the task monitor

2012-05-04 Thread Phabricator (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268699#comment-13268699
 ] 

Phabricator commented on HBASE-5045:


amirshim has commented on the revision [jira] [HBASE-5045] Annotation for 
Custom Param formatting and next() RPC call info.

  Can't override Mikhail diff, so created a new diff: 
https://reviews.facebook.net/D3045

REVISION DETAIL
  https://reviews.facebook.net/D2913

BRANCH
  add_the_table_name_and_cf_name_for_the_next_HBASE-5045_v3


 Add the table name and cf name for the next call int the task monitor
 -

 Key: HBASE-5045
 URL: https://issues.apache.org/jira/browse/HBASE-5045
 Project: HBase
  Issue Type: Improvement
Reporter: Liyin Tang
Assignee: Amir Shimoni
 Attachments: D2913.1.patch, D2913.2.patch, D3045.1.patch


 In the task monitor, we don't have much information about the next call 
 compared to other operations.
 It would be nice to add the table name and cf name for each next call in the 
 task monitor.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-5877) When a query fails because the region has moved, let the regionserver return the new address to the client

2012-05-04 Thread nkeywal (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268701#comment-13268701
 ] 

nkeywal commented on HBASE-5877:


thank you Ted. It's strange, it though it worked locally. May be this test
was hung and was not reported as an error. Thank you anyway.




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




[jira] [Updated] (HBASE-5922) HalfStoreFileReader seekBefore causes StackOverflowError

2012-05-04 Thread Nate Putnam (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-5922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nate Putnam updated HBASE-5922:
---

Attachment: HBASE-5922.v3.patch

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

 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-5922) HalfStoreFileReader seekBefore causes StackOverflowError

2012-05-04 Thread Nate Putnam (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268702#comment-13268702
 ] 

Nate Putnam commented on HBASE-5922:


@Anoop happy to back port the fix to 92.x,94.x and 90.x once we agree on the 
solution. I've submitted another patch (v3) witch changes the return false to a 
delegate.seekBefore. 

I'm fairly confident that this is the final solution. If you have any 
concerns/comments let me know. 

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

 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-5045) Add the table name and cf name for the next call int the task monitor

2012-05-04 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268703#comment-13268703
 ] 

Hadoop QA commented on HBASE-5045:
--

-1 overall.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12525679/D3045.1.patch
  against trunk revision .

+1 @author.  The patch does not contain any @author tags.

+1 tests included.  The patch appears to include 2 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 failed these unit tests:
   org.apache.hadoop.hbase.TestCheckTestClasses

Test results: 
https://builds.apache.org/job/PreCommit-HBASE-Build/1772//testReport/
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/1772//artifact/trunk/patchprocess/newPatchFindbugsWarnings.html
Console output: 
https://builds.apache.org/job/PreCommit-HBASE-Build/1772//console

This message is automatically generated.

 Add the table name and cf name for the next call int the task monitor
 -

 Key: HBASE-5045
 URL: https://issues.apache.org/jira/browse/HBASE-5045
 Project: HBase
  Issue Type: Improvement
Reporter: Liyin Tang
Assignee: Amir Shimoni
 Attachments: D2913.1.patch, D2913.2.patch, D3045.1.patch


 In the task monitor, we don't have much information about the next call 
 compared to other operations.
 It would be nice to add the table name and cf name for each next call in the 
 task monitor.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-5045) Add the table name and cf name for the next call int the task monitor

2012-05-04 Thread Phabricator (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268706#comment-13268706
 ] 

Phabricator commented on HBASE-5045:


mbautin has commented on the revision [jira] [HBASE-5045] Annotation for 
Custom Param formatting and next() RPC call info.

  Amir: does this version address comments from the other diff?

REVISION DETAIL
  https://reviews.facebook.net/D3045


 Add the table name and cf name for the next call int the task monitor
 -

 Key: HBASE-5045
 URL: https://issues.apache.org/jira/browse/HBASE-5045
 Project: HBase
  Issue Type: Improvement
Reporter: Liyin Tang
Assignee: Amir Shimoni
 Attachments: D2913.1.patch, D2913.2.patch, D3045.1.patch


 In the task monitor, we don't have much information about the next call 
 compared to other operations.
 It would be nice to add the table name and cf name for each next call in the 
 task monitor.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-5045) Add the table name and cf name for the next call int the task monitor

2012-05-04 Thread Phabricator (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268707#comment-13268707
 ] 

Phabricator commented on HBASE-5045:


mbautin has abandoned the revision [jira] [HBASE-5045] Annotation for Custom 
Param formatting and next() RPC call info.

REVISION DETAIL
  https://reviews.facebook.net/D2913


 Add the table name and cf name for the next call int the task monitor
 -

 Key: HBASE-5045
 URL: https://issues.apache.org/jira/browse/HBASE-5045
 Project: HBase
  Issue Type: Improvement
Reporter: Liyin Tang
Assignee: Amir Shimoni
 Attachments: D2913.1.patch, D2913.2.patch, D3045.1.patch


 In the task monitor, we don't have much information about the next call 
 compared to other operations.
 It would be nice to add the table name and cf name for each next call in the 
 task monitor.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-5045) Add the table name and cf name for the next call int the task monitor

2012-05-04 Thread Phabricator (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268714#comment-13268714
 ] 

Phabricator commented on HBASE-5045:


amirshim has commented on the revision [jira] [HBASE-5045] Annotation for 
Custom Param formatting and next() RPC call info.

  Mikhail: Most of the comments in the other diff were addressed with comments 
in the other diff, but I added some more comments where needed in this diff.

REVISION DETAIL
  https://reviews.facebook.net/D3045


 Add the table name and cf name for the next call int the task monitor
 -

 Key: HBASE-5045
 URL: https://issues.apache.org/jira/browse/HBASE-5045
 Project: HBase
  Issue Type: Improvement
Reporter: Liyin Tang
Assignee: Amir Shimoni
 Attachments: D2913.1.patch, D2913.2.patch, D3045.1.patch


 In the task monitor, we don't have much information about the next call 
 compared to other operations.
 It would be nice to add the table name and cf name for each next call in the 
 task monitor.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-5045) Add the table name and cf name for the next call int the task monitor

2012-05-04 Thread Phabricator (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268718#comment-13268718
 ] 

Phabricator commented on HBASE-5045:


tedyu has commented on the revision [jira] [HBASE-5045] Annotation for Custom 
Param formatting and next() RPC call info.

INLINE COMMENTS
  src/test/java/org/apache/hadoop/hbase/util/TestParamFormatter.java:30 Please 
add @Category(SmallTests.class)

  src/test/java/org/apache/hadoop/hbase/util/TestParamFormatter.java:42 Two 
extra empty lines should be removed.
  src/test/java/org/apache/hadoop/hbase/util/TestParamFormatter.java:77 Please 
insert space between catch and (
  src/test/java/org/apache/hadoop/hbase/util/TestParamFormatter.java:131 This 
class and MyFailureCaseServer2 can be made private, right ?

REVISION DETAIL
  https://reviews.facebook.net/D3045


 Add the table name and cf name for the next call int the task monitor
 -

 Key: HBASE-5045
 URL: https://issues.apache.org/jira/browse/HBASE-5045
 Project: HBase
  Issue Type: Improvement
Reporter: Liyin Tang
Assignee: Amir Shimoni
 Attachments: D2913.1.patch, D2913.2.patch, D3045.1.patch


 In the task monitor, we don't have much information about the next call 
 compared to other operations.
 It would be nice to add the table name and cf name for each next call in the 
 task monitor.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-5045) Add the table name and cf name for the next call int the task monitor

2012-05-04 Thread Phabricator (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268719#comment-13268719
 ] 

Phabricator commented on HBASE-5045:


mbautin has commented on the revision [jira] [HBASE-5045] Annotation for 
Custom Param formatting and next() RPC call info.

INLINE COMMENTS
  src/test/java/org/apache/hadoop/hbase/util/TestParamFormatter.java:101 I 
think in general we don't put more than one class in a file. Either use a 
static inner class or put this class in its own file.
  src/test/java/org/apache/hadoop/hbase/util/TestParamFormatter.java:131 Make a 
static inner class or move to a separate file.
  src/test/java/org/apache/hadoop/hbase/util/TestParamFormatter.java:147 Make a 
static inner class or move to a separate file.

REVISION DETAIL
  https://reviews.facebook.net/D3045


 Add the table name and cf name for the next call int the task monitor
 -

 Key: HBASE-5045
 URL: https://issues.apache.org/jira/browse/HBASE-5045
 Project: HBase
  Issue Type: Improvement
Reporter: Liyin Tang
Assignee: Amir Shimoni
 Attachments: D2913.1.patch, D2913.2.patch, D3045.1.patch


 In the task monitor, we don't have much information about the next call 
 compared to other operations.
 It would be nice to add the table name and cf name for each next call in the 
 task monitor.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-5494) Introduce a zk hosted table-wide read/write lock so only one table operation at a time

2012-05-04 Thread Phabricator (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13268722#comment-13268722
 ] 

Phabricator commented on HBASE-5494:


mbautin has commented on the revision [jira] [HBASE-5494] [89-fb] Table-level 
locks for schema changing operations..

  Discussed offline with Alex. Changes to createTable (double-checked locking) 
look good to me.

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




  1   2   >