date:20120519


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

Hudson commented on HBASE-6056:
---

Integrated in HBase-TRUNK #2907 (See 
[https://builds.apache.org/job/HBase-TRUNK/2907/])
HBASE-6056 Restore hbase-default version check (Revision 1340344)

 Result = FAILURE
stack : 
Files : 
* /hbase/trunk/src/main/java/org/apache/hadoop/hbase/HBaseConfiguration.java


 Restore hbase-default version check
 ---

 Key: HBASE-6056
 URL: https://issues.apache.org/jira/browse/HBASE-6056
 Project: HBase
  Issue Type: Bug
Reporter: stack
Assignee: stack
 Fix For: 0.94.1


 Was removed by mistake.

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

[jira] [Resolved] (HBASE-6054) 0.92 failing because of missing commons-io after upgrade to hadoop 1.0.3.

2012-05-19 Thread stack (JIRA)


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

stack resolved HBASE-6054.
--

   Resolution: Fixed
Fix Version/s: 0.92.2
 Assignee: stack

Failing for some other reason now, not because of this issue.  Resolving.

 0.92 failing because of missing commons-io after upgrade to hadoop 1.0.3.
 -

 Key: HBASE-6054
 URL: https://issues.apache.org/jira/browse/HBASE-6054
 Project: HBase
  Issue Type: Bug
Reporter: stack
Assignee: stack
 Fix For: 0.92.2

 Attachments: commons-io.txt, hbasedefaultcheck.txt


 See this note: 
 http://search-hadoop.com/m/0UrOr19BG8v1/test+failure+after+upgrading+to+hadoop+1.0.3+Was%253A+ClassNotFoundException%253A+org.apache.commons.io.FileUtilssubj=test+failure+after+upgrading+to+hadoop+1+0+3+Was+ClassNotFoundException+org+apache+commons+io+FileUtils

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

[jira] [Commented] (HBASE-6056) Restore hbase-default version check


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

Hudson commented on HBASE-6056:
---

Integrated in HBase-0.94 #203 (See 
[https://builds.apache.org/job/HBase-0.94/203/])
HBASE-6056 Restore hbase-default version check (Revision 1340345)

 Result = SUCCESS
stack : 
Files : 
* 
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/HBaseConfiguration.java


 Restore hbase-default version check
 ---

 Key: HBASE-6056
 URL: https://issues.apache.org/jira/browse/HBASE-6056
 Project: HBase
  Issue Type: Bug
Reporter: stack
Assignee: stack
 Fix For: 0.94.1


 Was removed by mistake.

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

[jira] [Updated] (HBASE-5998) Bulk assignment: regionserver optimization by using a temporary cache for table descriptors when receveing an open regions request


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

nkeywal updated HBASE-5998:
---

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

depiste the failure mentionned by jenkins, the patch is visible in the source 
code.

 Bulk assignment: regionserver optimization by using a temporary cache for 
 table descriptors when receveing an open regions request
 --

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

 Attachments: 5998.v2.patch, 5998.v3.patch


 During the assignment, on the regionserver, before creating the handlers we 
 load the table description. Even if there is a cache, we check the timestamps 
 for each region, while it's not necessary. The test below is just with one 
 node, with more nodes the benefit will improve. By limiting the time spent in 
 HRegion#openRegion we increase the parallelization during cluster startup, as 
 the master is using a pool of threads to call the RS.
 -- Without the fix
 2012-05-14 11:40:52,501 DEBUG 
 org.apache.hadoop.hbase.master.AssignmentManager: Bulk assigning 1193 
 region(s) to localhost,11003,1336988444043
 2012-05-14 11:41:09,947 DEBUG 
 org.apache.hadoop.hbase.master.AssignmentManager: Bulk assigning done for 
 localhost,11003,1336988444043
 -- With the fix
 2012-05-14 11:34:40,444 DEBUG 
 org.apache.hadoop.hbase.master.AssignmentManager: Bulk assigning 1193 
 region(s) to localhost,11003,1336988444043
 2012-05-14 11:34:40,929 DEBUG 
 org.apache.hadoop.hbase.master.AssignmentManager: Bulk assigning done for 
 localhost,11003,1336988065948

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

[jira] [Created] (HBASE-6057) Change some tests categories to optimize build time

nkeywal created HBASE-6057:
--

 Summary: Change some tests categories to optimize build time
 Key: HBASE-6057
 URL: https://issues.apache.org/jira/browse/HBASE-6057
 Project: HBase
  Issue Type: Improvement
  Components: test
Affects Versions: 0.96.0
Reporter: nkeywal
Assignee: nkeywal
Priority: Minor


Some tests categorized as small takes more than 15s: it's better if they are 
executed in // with the medium tests.
Some medium tests last less than 2s: it's better to have then executed with the 
small tests: we save a fork.

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

[jira] [Updated] (HBASE-6057) Change some tests categories to optimize build time


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

nkeywal updated HBASE-6057:
---

Status: Patch Available  (was: Open)

this should buy around 5%-10%...

 Change some tests categories to optimize build time
 ---

 Key: HBASE-6057
 URL: https://issues.apache.org/jira/browse/HBASE-6057
 Project: HBase
  Issue Type: Improvement
  Components: test
Affects Versions: 0.96.0
Reporter: nkeywal
Assignee: nkeywal
Priority: Minor
 Attachments: 6057.v1.patch


 Some tests categorized as small takes more than 15s: it's better if they are 
 executed in // with the medium tests.
 Some medium tests last less than 2s: it's better to have then executed with 
 the small tests: we save a fork.

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

[jira] [Updated] (HBASE-6057) Change some tests categories to optimize build time


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

nkeywal updated HBASE-6057:
---

Attachment: 6057.v1.patch

 Change some tests categories to optimize build time
 ---

 Key: HBASE-6057
 URL: https://issues.apache.org/jira/browse/HBASE-6057
 Project: HBase
  Issue Type: Improvement
  Components: test
Affects Versions: 0.96.0
Reporter: nkeywal
Assignee: nkeywal
Priority: Minor
 Attachments: 6057.v1.patch


 Some tests categorized as small takes more than 15s: it's better if they are 
 executed in // with the medium tests.
 Some medium tests last less than 2s: it's better to have then executed with 
 the small tests: we save a fork.

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

[jira] [Created] (HBASE-6058) Use ZK 3.4 API 'multi' in bulk assignment

nkeywal created HBASE-6058:
--

 Summary: Use ZK 3.4 API 'multi' in bulk assignment
 Key: HBASE-6058
 URL: https://issues.apache.org/jira/browse/HBASE-6058
 Project: HBase
  Issue Type: Improvement
  Components: master, zookeeper
Affects Versions: 0.96.0
Reporter: nkeywal
Assignee: nkeywal
Priority: Minor


We use async API today. This is already much much faster than the sync API. 
Still, it makes sense to use the 'multi' function: this will decrease the 
network  zookeeper load at startup/rolling restart.

On a 500 nodes cluster, we see 3 that 3 seconds are spent on updating ZK per 
bulk assignment. This should cut it in half (+ the benefits on the network/zk 
load).

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

[jira] [Commented] (HBASE-6057) Change some tests categories to optimize build time

2012-05-19 Thread Hadoop QA (JIRA)

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

Hadoop QA commented on HBASE-6057:
--

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

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

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

+1 hadoop23. The patch compiles against the hadoop 0.23.x profile.

+1 javadoc. The javadoc tool did not generate any warning messages.

+1 javac. The applied patch does not increase the total number of javac
compiler warnings.

-1 findbugs. The patch appears to introduce 33 new Findbugs (version
1.3.9) warnings.

+1 release audit. The applied patch does not increase the total number of
release audit warnings.

-1 core tests. The patch failed these unit tests:
org.apache.hadoop.hbase.replication.TestReplication

org.apache.hadoop.hbase.regionserver.TestSplitTransactionOnCluster
org.apache.hadoop.hbase.replication.TestMultiSlaveReplication
org.apache.hadoop.hbase.replication.TestMasterReplication

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

This message is automatically generated.

Change some tests categories to optimize build time
---

Key: HBASE-6057
URL: https://issues.apache.org/jira/browse/HBASE-6057
Project: HBase
Issue Type: Improvement
Components: test
Affects Versions: 0.96.0
Reporter: nkeywal
Assignee: nkeywal
Priority: Minor
Attachments: 6057.v1.patch

Some tests categorized as small takes more than 15s: it's better if they are
executed in // with the medium tests.
Some medium tests last less than 2s: it's better to have then executed with
the small tests: we save a fork.

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

[jira] [Commented] (HBASE-6057) Change some tests categories to optimize build time


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

nkeywal commented on HBASE-6057:


All these tests are not impacted by the change. Patch is ok imho.

 Change some tests categories to optimize build time
 ---

 Key: HBASE-6057
 URL: https://issues.apache.org/jira/browse/HBASE-6057
 Project: HBase
  Issue Type: Improvement
  Components: test
Affects Versions: 0.96.0
Reporter: nkeywal
Assignee: nkeywal
Priority: Minor
 Attachments: 6057.v1.patch


 Some tests categorized as small takes more than 15s: it's better if they are 
 executed in // with the medium tests.
 Some medium tests last less than 2s: it's better to have then executed with 
 the small tests: we save a fork.

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

[jira] [Commented] (HBASE-5882) Prcoess RIT on master restart can try assigning the region if the region is found on a dead server instead of waiting for Timeout Monitor


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

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

Committed to trunk. Thanks for the patch Ashutosh.
Thanks for the review Stack and Ted.

 Prcoess RIT on master restart can try assigning the region if the region is 
 found on a dead server instead of waiting for Timeout Monitor
 -

 Key: HBASE-5882
 URL: https://issues.apache.org/jira/browse/HBASE-5882
 Project: HBase
  Issue Type: Improvement
Affects Versions: 0.90.6, 0.92.1
Reporter: ramkrishna.s.vasudevan
Assignee: Ashutosh Jindal
 Attachments: HBASE-5882_v5.patch, hbase_5882.patch, 
 hbase_5882_V2.patch, hbase_5882_V3.patch, hbase_5882_V4.patch


 Currently on  master restart if it tries to do processRIT, any region if 
 found on dead server tries to avoid the nwe assignment so that timeout 
 monitor can take care.
 This case is more prominent if the node is found in RS_ZK_REGION_OPENING 
 state. I think we can handle this by triggering a new assignment with a new 
 plan.

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

[jira] [Commented] (HBASE-5974) Scanner retry behavior with RPC timeout on next() seems incorrect


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

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

@Todd/Stack
Can you review this patch?  Seems to be pretty important fix.

 Scanner retry behavior with RPC timeout on next() seems incorrect
 -

 Key: HBASE-5974
 URL: https://issues.apache.org/jira/browse/HBASE-5974
 Project: HBase
  Issue Type: Bug
  Components: client, regionserver
Affects Versions: 0.90.7, 0.92.1, 0.94.0, 0.96.0
Reporter: Todd Lipcon
Priority: Critical
 Attachments: HBASE-5974_0.94.patch


 I'm seeing the following behavior:
 - set RPC timeout to a short value
 - call next() for some batch of rows, big enough so the client times out 
 before the result is returned
 - the HConnectionManager stuff will retry the next() call to the same server. 
 At this point, one of two things can happen: 1) the previous next() call will 
 still be processing, in which case you get a LeaseException, because it was 
 removed from the map during the processing, or 2) the next() call will 
 succeed but skip the prior batch of rows.

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

[jira] [Commented] (HBASE-5840) Open Region FAILED_OPEN doesn't clear the TaskMonitor Status, keeps showing the old status


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

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

Committed to 0.94.1.  Hence resolving this.

 Open Region FAILED_OPEN doesn't clear the TaskMonitor Status, keeps showing 
 the old status
 --

 Key: HBASE-5840
 URL: https://issues.apache.org/jira/browse/HBASE-5840
 Project: HBase
  Issue Type: Bug
  Components: regionserver
Affects Versions: 0.94.0
Reporter: Gopinathan A
Assignee: rajeshbabu
 Fix For: 0.96.0, 0.94.1

 Attachments: HBASE-5840.patch, HBASE-5840_0.94.patch, 
 HBASE-5840_trunk.patch, HBASE-5840_v2.patch


 TaskMonitor Status will not be cleared in case Regions FAILED_OPEN. This will 
 keeps showing old status.
 This will miss leads the user.

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

[jira] [Updated] (HBASE-5840) Open Region FAILED_OPEN doesn't clear the TaskMonitor Status, keeps showing the old status


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

ramkrishna.s.vasudevan updated HBASE-5840:
--

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

 Open Region FAILED_OPEN doesn't clear the TaskMonitor Status, keeps showing 
 the old status
 --

 Key: HBASE-5840
 URL: https://issues.apache.org/jira/browse/HBASE-5840
 Project: HBase
  Issue Type: Bug
  Components: regionserver
Affects Versions: 0.94.0
Reporter: Gopinathan A
Assignee: rajeshbabu
 Fix For: 0.96.0, 0.94.1

 Attachments: HBASE-5840.patch, HBASE-5840_0.94.patch, 
 HBASE-5840_trunk.patch, HBASE-5840_v2.patch


 TaskMonitor Status will not be cleared in case Regions FAILED_OPEN. This will 
 keeps showing old status.
 This will miss leads the user.

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

[jira] [Updated] (HBASE-6031) RegionServer does not go down while aborting


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

ramkrishna.s.vasudevan updated HBASE-6031:
--

Affects Version/s: 0.94.0
Fix Version/s: 0.94.1
   0.96.0

 RegionServer does not go down while aborting
 

 Key: HBASE-6031
 URL: https://issues.apache.org/jira/browse/HBASE-6031
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.94.0
Reporter: ramkrishna.s.vasudevan
 Fix For: 0.96.0, 0.94.1


 Following is the thread dump.
 {code}
 1997531088@qtp-716941846-5 prio=10 tid=0x7f7c5820c800 nid=0xe1b in 
 Object.wait() [0x7f7c56ae8000]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
   at java.lang.Object.wait(Native Method)
   at 
 org.mortbay.io.nio.SelectChannelEndPoint.blockWritable(SelectChannelEndPoint.java:279)
   - locked 0x7f7cfe0616d0 (a 
 org.mortbay.jetty.nio.SelectChannelConnector$ConnectorEndPoint)
   at 
 org.mortbay.jetty.AbstractGenerator$Output.blockForOutput(AbstractGenerator.java:545)
   at 
 org.mortbay.jetty.AbstractGenerator$Output.write(AbstractGenerator.java:639)
   at 
 org.mortbay.jetty.AbstractGenerator$Output.write(AbstractGenerator.java:580)
   at java.io.ByteArrayOutputStream.writeTo(ByteArrayOutputStream.java:109)
   - locked 0x7f7cfe74d758 (a 
 org.mortbay.util.ByteArrayOutputStream2)
   at 
 org.mortbay.jetty.AbstractGenerator$OutputWriter.write(AbstractGenerator.java:904)
   at java.io.Writer.write(Writer.java:96)
   - locked 0x7f7cfca02fc0 (a 
 org.mortbay.jetty.HttpConnection$OutputWriter)
   at java.io.PrintWriter.write(PrintWriter.java:361)
   - locked 0x7f7cfca02fc0 (a 
 org.mortbay.jetty.HttpConnection$OutputWriter)
   at org.jamon.escaping.HtmlEscaping.write(HtmlEscaping.java:43)
   at 
 org.jamon.escaping.AbstractCharacterEscaping.write(AbstractCharacterEscaping.java:35)
   at 
 org.apache.hadoop.hbase.tmpl.regionserver.RSStatusTmplImpl.renderNoFlush(RSStatusTmplImpl.java:222)
   at 
 org.apache.hadoop.hbase.tmpl.regionserver.RSStatusTmpl.renderNoFlush(RSStatusTmpl.java:180)
   at 
 org.apache.hadoop.hbase.tmpl.regionserver.RSStatusTmpl.render(RSStatusTmpl.java:171)
   at 
 org.apache.hadoop.hbase.regionserver.RSStatusServlet.doGet(RSStatusServlet.java:48)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
   at 
 org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
   at 
 org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1221)
   at 
 org.apache.hadoop.http.lib.StaticUserWebFilter$StaticUserFilter.doFilter(StaticUserWebFilter.java:109)
   at 
 org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
   at 
 org.apache.hadoop.http.HttpServer$QuotingInputFilter.doFilter(HttpServer.java:932)
   at 
 org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
   at 
 org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:399)
   at 
 org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
   at 
 org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
   at 
 org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
   at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450)
   at 
 org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
   at 
 org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
   at org.mortbay.jetty.Server.handle(Server.java:326)
   at 
 org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
   at 
 org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:928)
   at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
   at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
   at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
   at 
 org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410)
   at 
 org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
 1374615312@qtp-716941846-3 prio=10 tid=0x7f7c58214800 nid=0xc42 in 
 Object.wait() [0x7f7c55bd9000]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
   at java.lang.Object.wait(Native Method)
   at 
 org.mortbay.io.nio.SelectChannelEndPoint.blockWritable(SelectChannelEndPoint.java:279)
   - locked 0x7f7cfdbb6cc8 (a 
 org.mortbay.jetty.nio.SelectChannelConnector$ConnectorEndPoint)
   at

[jira] [Updated] (HBASE-5882) Prcoess RIT on master restart can try assigning the region if the region is found on a dead server instead of waiting for Timeout Monitor


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

ramkrishna.s.vasudevan updated HBASE-5882:
--

Affects Version/s: 0.94.0
Fix Version/s: 0.94.1
   0.96.0

 Prcoess RIT on master restart can try assigning the region if the region is 
 found on a dead server instead of waiting for Timeout Monitor
 -

 Key: HBASE-5882
 URL: https://issues.apache.org/jira/browse/HBASE-5882
 Project: HBase
  Issue Type: Improvement
Affects Versions: 0.90.6, 0.92.1, 0.94.0
Reporter: ramkrishna.s.vasudevan
Assignee: Ashutosh Jindal
 Fix For: 0.96.0, 0.94.1

 Attachments: HBASE-5882_v5.patch, hbase_5882.patch, 
 hbase_5882_V2.patch, hbase_5882_V3.patch, hbase_5882_V4.patch


 Currently on  master restart if it tries to do processRIT, any region if 
 found on dead server tries to avoid the nwe assignment so that timeout 
 monitor can take care.
 This case is more prominent if the node is found in RS_ZK_REGION_OPENING 
 state. I think we can handle this by triggering a new assignment with a new 
 plan.

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

[jira] [Commented] (HBASE-5840) Open Region FAILED_OPEN doesn't clear the TaskMonitor Status, keeps showing the old status


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

Hudson commented on HBASE-5840:
---

Integrated in HBase-0.94 #204 (See 
[https://builds.apache.org/job/HBase-0.94/204/])
HBASE-5840 Open Region FAILED_OPEN doesn't clear the TaskMonitor Status, 
keeps showing the old status (Rajesh) (Revision 1340396)

 Result = FAILURE
ramkrishna : 
Files : 
* 
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
* 
/hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/regionserver/TestHRegion.java


 Open Region FAILED_OPEN doesn't clear the TaskMonitor Status, keeps showing 
 the old status
 --

 Key: HBASE-5840
 URL: https://issues.apache.org/jira/browse/HBASE-5840
 Project: HBase
  Issue Type: Bug
  Components: regionserver
Affects Versions: 0.94.0
Reporter: Gopinathan A
Assignee: rajeshbabu
 Fix For: 0.96.0, 0.94.1

 Attachments: HBASE-5840.patch, HBASE-5840_0.94.patch, 
 HBASE-5840_trunk.patch, HBASE-5840_v2.patch


 TaskMonitor Status will not be cleared in case Regions FAILED_OPEN. This will 
 keeps showing old status.
 This will miss leads the user.

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

[jira] [Commented] (HBASE-6056) Restore hbase-default version check


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

Hudson commented on HBASE-6056:
---

Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #11 (See 
[https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/11/])
HBASE-6056 Restore hbase-default version check (Revision 1340344)

 Result = FAILURE
stack : 
Files : 
* /hbase/trunk/src/main/java/org/apache/hadoop/hbase/HBaseConfiguration.java


 Restore hbase-default version check
 ---

 Key: HBASE-6056
 URL: https://issues.apache.org/jira/browse/HBASE-6056
 Project: HBase
  Issue Type: Bug
Reporter: stack
Assignee: stack
 Fix For: 0.94.1


 Was removed by mistake.

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

[jira] [Commented] (HBASE-6007) Make getTableRegions return an empty list if the table does not exist


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

Hudson commented on HBASE-6007:
---

Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #11 (See 
[https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/11/])
[jira] [HBASE-6007] Make getTableRegions return an empty list if the table 
does not exist

Summary:
Making the getTableRegions Thrift API method handle TableNotFoundException and 
return an empty list in that case. Without this the behavior is dependent on 
whether an HTable object is present in the thread-local cache in case a table 
was deleted.

Test Plan: Unit tests

Reviewers: kannan, liyintang

Reviewed By: liyintang

CC: stack

Differential Revision: https://reviews.facebook.net/D3243 (Revision 1340310)

 Result = FAILURE
mbautin : 
Files : 
* 
/hbase/trunk/src/main/java/org/apache/hadoop/hbase/thrift/ThriftServerRunner.java


 Make getTableRegions return an empty list if the table does not exist
 -

 Key: HBASE-6007
 URL: https://issues.apache.org/jira/browse/HBASE-6007
 Project: HBase
  Issue Type: Bug
Reporter: Mikhail Bautin
Assignee: Mikhail Bautin
Priority: Minor
 Attachments: D3243.1.patch, 
 jira-HBASE-6007-Make-getTableRegions-return-an-empty-2012-05-18_17_02_40.patch


 Making the getTableRegions Thrift API method handle TableNotFoundException 
 and return an empty list in that case. Without this the behavior is dependent 
 on whether an HTable object is present in the thread-local cache in case a 
 table was deleted.

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

[jira] [Commented] (HBASE-5882) Prcoess RIT on master restart can try assigning the region if the region is found on a dead server instead of waiting for Timeout Monitor


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

Hudson commented on HBASE-5882:
---

Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #11 (See 
[https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/11/])
HBASE-5882 Prcoess RIT on master restart can try assigning the region if 
the region is found on a dead server instead of waiting for Timeout Monitor 
(Ashutosh) (Revision 1340392)

 Result = FAILURE
ramkrishna : 
Files : 
* 
/hbase/trunk/src/main/java/org/apache/hadoop/hbase/master/AssignmentManager.java
* 
/hbase/trunk/src/test/java/org/apache/hadoop/hbase/master/TestAssignmentManager.java


 Prcoess RIT on master restart can try assigning the region if the region is 
 found on a dead server instead of waiting for Timeout Monitor
 -

 Key: HBASE-5882
 URL: https://issues.apache.org/jira/browse/HBASE-5882
 Project: HBase
  Issue Type: Improvement
Affects Versions: 0.90.6, 0.92.1, 0.94.0
Reporter: ramkrishna.s.vasudevan
Assignee: Ashutosh Jindal
 Fix For: 0.96.0, 0.94.1

 Attachments: HBASE-5882_v5.patch, hbase_5882.patch, 
 hbase_5882_V2.patch, hbase_5882_V3.patch, hbase_5882_V4.patch


 Currently on  master restart if it tries to do processRIT, any region if 
 found on dead server tries to avoid the nwe assignment so that timeout 
 monitor can take care.
 This case is more prominent if the node is found in RS_ZK_REGION_OPENING 
 state. I think we can handle this by triggering a new assignment with a new 
 plan.

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

[jira] [Commented] (HBASE-5970) Improve the AssignmentManager#updateTimer and speed up handling opened event

2012-05-19 Thread chunhui shen (JIRA)


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

chunhui shen commented on HBASE-5970:
-

bq.Why is doing this work in the background faster? Is it just that it being 
inline, it takes a noticeable amount of time?

AssignmentManager#updateTimers would check each region in RIT, and there are 
lots of regions in the RIT when startup, so it will took much time(about 30ms 
if 100k regions in RIT). However, in the current logic, we will do the 
AssignmentManager#updateTimers for each opened event, causing the whole process 
of handling all the opened events tooks much much time.

If we do the updateTimers in the background, we needn't wait it when handling 
opened event. Also, we wouldn't updateTimers for the same Regionserver in a 
short time.(In fact, when cluster startup , lots of opened events from the same 
regionserver at the same time, we needn't do this work many times at the moment)

 Improve the AssignmentManager#updateTimer and speed up handling opened event
 

 Key: HBASE-5970
 URL: https://issues.apache.org/jira/browse/HBASE-5970
 Project: HBase
  Issue Type: Improvement
  Components: master
Reporter: chunhui shen
Assignee: chunhui shen
 Attachments: 5970v3.patch, HBASE-5970.patch, HBASE-5970v2.patch, 
 HBASE-5970v3.patch


 We found handing opened event very slow in the environment with lots of 
 regions.
 The problem is the slow AssignmentManager#updateTimer.
 We do the test for bulk assigning 10w (i.e. 100k) regions, the whole process 
 of bulk assigning took 1 hours.
 2012-05-06 20:31:49,201 INFO 
 org.apache.hadoop.hbase.master.AssignmentManager: Bulk assigning 10 
 region(s) round-robin across 5 server(s)
 2012-05-06 21:26:32,103 INFO 
 org.apache.hadoop.hbase.master.AssignmentManager: Bulk assigning done
 I think we could do the improvement for the AssignmentManager#updateTimer: 
 Make a thread do this work.
 After the improvement, it took only 4.5mins
 2012-05-07 11:03:36,581 INFO 
 org.apache.hadoop.hbase.master.AssignmentManager: Bulk assigning 10 
 region(s) across 5 server(s), retainAssignment=true 
 2012-05-07 11:07:57,073 INFO 
 org.apache.hadoop.hbase.master.AssignmentManager: Bulk assigning done 

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

[jira] [Commented] (HBASE-5970) Improve the AssignmentManager#updateTimer and speed up handling opened event

2012-05-19 Thread chunhui shen (JIRA)


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

chunhui shen commented on HBASE-5970:
-

@stack
bq.You are addressing this comment in updateTimers?{code}// This loop could be 
expensive.{code}
I keep this loop, but greatly reduce the call times

bq.Is this javadoc right?
I'm not sure, could you give a suggestion.

Thanks for the review

 Improve the AssignmentManager#updateTimer and speed up handling opened event
 

 Key: HBASE-5970
 URL: https://issues.apache.org/jira/browse/HBASE-5970
 Project: HBase
  Issue Type: Improvement
  Components: master
Reporter: chunhui shen
Assignee: chunhui shen
 Attachments: 5970v3.patch, HBASE-5970.patch, HBASE-5970v2.patch, 
 HBASE-5970v3.patch


 We found handing opened event very slow in the environment with lots of 
 regions.
 The problem is the slow AssignmentManager#updateTimer.
 We do the test for bulk assigning 10w (i.e. 100k) regions, the whole process 
 of bulk assigning took 1 hours.
 2012-05-06 20:31:49,201 INFO 
 org.apache.hadoop.hbase.master.AssignmentManager: Bulk assigning 10 
 region(s) round-robin across 5 server(s)
 2012-05-06 21:26:32,103 INFO 
 org.apache.hadoop.hbase.master.AssignmentManager: Bulk assigning done
 I think we could do the improvement for the AssignmentManager#updateTimer: 
 Make a thread do this work.
 After the improvement, it took only 4.5mins
 2012-05-07 11:03:36,581 INFO 
 org.apache.hadoop.hbase.master.AssignmentManager: Bulk assigning 10 
 region(s) across 5 server(s), retainAssignment=true 
 2012-05-07 11:07:57,073 INFO 
 org.apache.hadoop.hbase.master.AssignmentManager: Bulk assigning done 

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

[jira] [Commented] (HBASE-5882) Prcoess RIT on master restart can try assigning the region if the region is found on a dead server instead of waiting for Timeout Monitor


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

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

Currently reverted as TestAssignmentManager needs some clean up.

 Prcoess RIT on master restart can try assigning the region if the region is 
 found on a dead server instead of waiting for Timeout Monitor
 -

 Key: HBASE-5882
 URL: https://issues.apache.org/jira/browse/HBASE-5882
 Project: HBase
  Issue Type: Improvement
Affects Versions: 0.90.6, 0.92.1, 0.94.0
Reporter: ramkrishna.s.vasudevan
Assignee: Ashutosh Jindal
 Fix For: 0.96.0, 0.94.1

 Attachments: HBASE-5882_v5.patch, hbase_5882.patch, 
 hbase_5882_V2.patch, hbase_5882_V3.patch, hbase_5882_V4.patch


 Currently on  master restart if it tries to do processRIT, any region if 
 found on dead server tries to avoid the nwe assignment so that timeout 
 monitor can take care.
 This case is more prominent if the node is found in RS_ZK_REGION_OPENING 
 state. I think we can handle this by triggering a new assignment with a new 
 plan.

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

[jira] [Commented] (HBASE-6058) Use ZK 3.4 API 'multi' in bulk assignment

2012-05-19 Thread Zhihong Yu (JIRA)


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

Zhihong Yu commented on HBASE-6058:
---

There hasn't been consensus as to which HBase version would require zk 3.4 as 
the minimum supported version.

 Use ZK 3.4 API 'multi' in bulk assignment
 -

 Key: HBASE-6058
 URL: https://issues.apache.org/jira/browse/HBASE-6058
 Project: HBase
  Issue Type: Improvement
  Components: master, zookeeper
Affects Versions: 0.96.0
Reporter: nkeywal
Assignee: nkeywal
Priority: Minor

 We use async API today. This is already much much faster than the sync API. 
 Still, it makes sense to use the 'multi' function: this will decrease the 
 network  zookeeper load at startup/rolling restart.
 On a 500 nodes cluster, we see 3 that 3 seconds are spent on updating ZK per 
 bulk assignment. This should cut it in half (+ the benefits on the network/zk 
 load).

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

[jira] [Updated] (HBASE-6050) HLogSplitter renaming recovered.edits and CJ removing the parent directory races, making the HBCK to think cluster is inconsistent.


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

ramkrishna.s.vasudevan updated HBASE-6050:
--

Attachment: HBASE-6050.patch

Trunk patch.  Pls provide your comments.

 HLogSplitter renaming recovered.edits and CJ removing the parent directory 
 races, making the HBCK to think cluster is inconsistent.
 ---

 Key: HBASE-6050
 URL: https://issues.apache.org/jira/browse/HBASE-6050
 Project: HBase
  Issue Type: Bug
Reporter: ramkrishna.s.vasudevan
 Attachments: HBASE-6050.patch


 The scenario is like this
 - A region is getting splitted.
 - The master is still not processed the split .
 - Region server goes down.
 - Split log manager starts splitting the logs and creates the 
 recovered.edits in the splitlog path.
 - CJ starts and deletes the entry from META and also just completes the 
 deletion of the region dir.
 - in hlogSplitter on final step we rename the recovered.edits to come under 
 the regiondir.
 There if the regiondir doesnot exist we tend to create and then add the 
 recovered.edits.
 Because of this HBCK thinks it to be an orphan region because we have the 
 regiondir but with no regioninfo.
 Ideally cluster is fine but we it is misleading.
 {code}
 } else {
   Path dstdir = dst.getParent();
   if (!fs.exists(dstdir)) {
 if (!fs.mkdirs(dstdir)) LOG.warn(mkdir failed on  + dstdir);
   }
 }
 fs.rename(src, dst);
 LOG.debug( moved  + src +  =  + dst);
   } else {
 LOG.debug(Could not move recovered edits from  + src +
  as it doesn't exist);
   }
 }
 archiveLogs(null, corruptedLogs, processedLogs,
 oldLogDir, fs, conf);
 {code}

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

[jira] [Updated] (HBASE-6050) HLogSplitter renaming recovered.edits and CJ removing the parent directory races, making the HBCK to think cluster is inconsistent.


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

ramkrishna.s.vasudevan updated HBASE-6050:
--

Status: Patch Available  (was: Open)

 HLogSplitter renaming recovered.edits and CJ removing the parent directory 
 races, making the HBCK to think cluster is inconsistent.
 ---

 Key: HBASE-6050
 URL: https://issues.apache.org/jira/browse/HBASE-6050
 Project: HBase
  Issue Type: Bug
Reporter: ramkrishna.s.vasudevan
 Attachments: HBASE-6050.patch


 The scenario is like this
 - A region is getting splitted.
 - The master is still not processed the split .
 - Region server goes down.
 - Split log manager starts splitting the logs and creates the 
 recovered.edits in the splitlog path.
 - CJ starts and deletes the entry from META and also just completes the 
 deletion of the region dir.
 - in hlogSplitter on final step we rename the recovered.edits to come under 
 the regiondir.
 There if the regiondir doesnot exist we tend to create and then add the 
 recovered.edits.
 Because of this HBCK thinks it to be an orphan region because we have the 
 regiondir but with no regioninfo.
 Ideally cluster is fine but we it is misleading.
 {code}
 } else {
   Path dstdir = dst.getParent();
   if (!fs.exists(dstdir)) {
 if (!fs.mkdirs(dstdir)) LOG.warn(mkdir failed on  + dstdir);
   }
 }
 fs.rename(src, dst);
 LOG.debug( moved  + src +  =  + dst);
   } else {
 LOG.debug(Could not move recovered edits from  + src +
  as it doesn't exist);
   }
 }
 archiveLogs(null, corruptedLogs, processedLogs,
 oldLogDir, fs, conf);
 {code}

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

[jira] [Updated] (HBASE-6033) Adding some fuction to check if a table/region is in compaction

2012-05-19 Thread Jimmy Xiang (JIRA)


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

Jimmy Xiang updated HBASE-6033:
---

Attachment: table_ui.png

 Adding some fuction to check if a table/region is in compaction
 ---

 Key: HBASE-6033
 URL: https://issues.apache.org/jira/browse/HBASE-6033
 Project: HBase
  Issue Type: New Feature
Reporter: Jimmy Xiang
Assignee: Jimmy Xiang
 Attachments: table_ui.png


 This feature will be helpful to find out if a major compaction is going on.
 We can show if it is in any minor compaction too.

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

[jira] [Commented] (HBASE-6050) HLogSplitter renaming recovered.edits and CJ removing the parent directory races, making the HBCK to think cluster is inconsistent.

2012-05-19 Thread Hadoop QA (JIRA)

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

Hadoop QA commented on HBASE-6050:
--

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

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

-1 tests included. The patch doesn't appear to include any new or modified
tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.

+1 hadoop23. The patch compiles against the hadoop 0.23.x profile.

+1 javadoc. The javadoc tool did not generate any warning messages.

+1 javac. The applied patch does not increase the total number of javac
compiler warnings.

-1 findbugs. The patch appears to introduce 33 new Findbugs (version
1.3.9) warnings.

+1 release audit. The applied patch does not increase the total number of
release audit warnings.

-1 core tests. The patch failed these unit tests:
org.apache.hadoop.hbase.replication.TestReplication
org.apache.hadoop.hbase.replication.TestMultiSlaveReplication
org.apache.hadoop.hbase.replication.TestMasterReplication

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

This message is automatically generated.

HLogSplitter renaming recovered.edits and CJ removing the parent directory
races, making the HBCK to think cluster is inconsistent.
---

Key: HBASE-6050
URL: https://issues.apache.org/jira/browse/HBASE-6050
Project: HBase
Issue Type: Bug
Reporter: ramkrishna.s.vasudevan
Attachments: HBASE-6050.patch

The scenario is like this
- A region is getting splitted.
- The master is still not processed the split .
- Region server goes down.
- Split log manager starts splitting the logs and creates the
recovered.edits in the splitlog path.
- CJ starts and deletes the entry from META and also just completes the
deletion of the region dir.
- in hlogSplitter on final step we rename the recovered.edits to come under
the regiondir.
There if the regiondir doesnot exist we tend to create and then add the
recovered.edits.
Because of this HBCK thinks it to be an orphan region because we have the
regiondir but with no regioninfo.
Ideally cluster is fine but we it is misleading.
{code}
} else {
Path dstdir = dst.getParent();
if (!fs.exists(dstdir)) {
if (!fs.mkdirs(dstdir)) LOG.warn(mkdir failed on + dstdir);
}
}
fs.rename(src, dst);
LOG.debug( moved + src + = + dst);
} else {
LOG.debug(Could not move recovered edits from + src +
as it doesn't exist);
}
}
archiveLogs(null, corruptedLogs, processedLogs,
oldLogDir, fs, conf);
{code}

[jira] [Commented] (HBASE-6050) HLogSplitter renaming recovered.edits and CJ removing the parent directory races, making the HBCK to think cluster is inconsistent.


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

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

Replication related testcases are failing in the previous few QA builds.
So this patch has not introduced it.

 HLogSplitter renaming recovered.edits and CJ removing the parent directory 
 races, making the HBCK to think cluster is inconsistent.
 ---

 Key: HBASE-6050
 URL: https://issues.apache.org/jira/browse/HBASE-6050
 Project: HBase
  Issue Type: Bug
Reporter: ramkrishna.s.vasudevan
 Attachments: HBASE-6050.patch


 The scenario is like this
 - A region is getting splitted.
 - The master is still not processed the split .
 - Region server goes down.
 - Split log manager starts splitting the logs and creates the 
 recovered.edits in the splitlog path.
 - CJ starts and deletes the entry from META and also just completes the 
 deletion of the region dir.
 - in hlogSplitter on final step we rename the recovered.edits to come under 
 the regiondir.
 There if the regiondir doesnot exist we tend to create and then add the 
 recovered.edits.
 Because of this HBCK thinks it to be an orphan region because we have the 
 regiondir but with no regioninfo.
 Ideally cluster is fine but we it is misleading.
 {code}
 } else {
   Path dstdir = dst.getParent();
   if (!fs.exists(dstdir)) {
 if (!fs.mkdirs(dstdir)) LOG.warn(mkdir failed on  + dstdir);
   }
 }
 fs.rename(src, dst);
 LOG.debug( moved  + src +  =  + dst);
   } else {
 LOG.debug(Could not move recovered edits from  + src +
  as it doesn't exist);
   }
 }
 archiveLogs(null, corruptedLogs, processedLogs,
 oldLogDir, fs, conf);
 {code}

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

[jira] [Assigned] (HBASE-1749) If RS looses lease, we used to restart by default; reinstitute

2012-05-19 Thread stack (JIRA)


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

stack reassigned HBASE-1749:


Assignee: nkeywal

Haven't you done this N?

 If RS looses lease, we used to restart by default; reinstitute
 --

 Key: HBASE-1749
 URL: https://issues.apache.org/jira/browse/HBASE-1749
 Project: HBase
  Issue Type: Bug
Reporter: stack
Assignee: nkeywal



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

[jira] [Commented] (HBASE-5882) Prcoess RIT on master restart can try assigning the region if the region is found on a dead server instead of waiting for Timeout Monitor