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

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

[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

[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

[nkeywal (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-5887) Make TestAcidGuarantees usable for system testing.

[Hudson (JIRA)]

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

Hudson commented on HBASE-5887:
---

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

 Result = SUCCESS
jmhsieh : 
Files : 
* 
/hbase/branches/0.94/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-5876) TestImportExport has been failing against hadoop 0.23 profile

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Jonathan Hsieh (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[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

[nkeywal (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Li Pi (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Anoop Sam John (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Anoop Sam John (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[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

[nkeywal (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Hadoop QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.HM

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

[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/ji

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

[Hadoop QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.ass

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

[Jieshan Bean (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Zhihong Yu (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Devaraj Das (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Phabricator (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[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

[stack (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Bob Copeland (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[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

[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

[stack (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)
>   ..

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

[Nicolas Spiegelberg (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[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

[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

[ramkrishna.s.vasudevan (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[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

[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

[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

[Hadoop QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Zhihong Yu (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[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

[Hadoop QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[ramkrishna.s.vasudevan (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Zhihong Yu (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[jirapos...@reviews.apache.org (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.  > 

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.src/test/java/org/apache/hadoop/

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

[Hadoop QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[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

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[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

[ramkrishna.s.vasudevan (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[ramkrishna.s.vasudevan (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Phabricator (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[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

[Phabricator (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Phabricator (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Hadoop QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[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

[Zhihong Yu (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[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

[Hadoop QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[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

[jirapos...@reviews.apache.org (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[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

[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

[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

[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

[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

[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

[Phabricator (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Hadoop QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[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

[Hadoop QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[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

[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

[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

[stack (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Jimmy Xiang (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Zhihong Yu (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Commented] (HBASE-5889) Remove HRegionInterface

[stack (JIRA)]

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

stack commented on HBASE-5889:
--

I took a look.  Its good.  I tried changing RegionServerUtil so it was package 
private but I got these failures which are odd given the class is named 
RegionServerUtil.  What you reckon?

{code}
[INFO] Compilation failure

/Users/Stack/checkouts/trunk/src/main/java/org/apache/hadoop/hbase/catalog/CatalogTracker.java:[43,43]
 org.apache.hadoop.hbase.regionserver.RegionServerUtil is not public in 
org.apache.hadoop.hbase.regionserver; cannot be accessed from outside package

/Users/Stack/checkouts/trunk/src/main/java/org/apache/hadoop/hbase/client/HConnectionManager.java:[79,43]
 org.apache.hadoop.hbase.regionserver.RegionServerUtil is not public in 
org.apache.hadoop.hbase.regionserver; cannot be accessed from outside package

/Users/Stack/checkouts/trunk/src/main/java/org/apache/hadoop/hbase/client/HBaseAdmin.java:[72,43]
 org.apache.hadoop.hbase.regionserver.RegionServerUtil is not public in 
org.apache.hadoop.hbase.regionserver; cannot be accessed from outside package

/Users/Stack/checkouts/trunk/src/main/java/org/apache/hadoop/hbase/client/HTable.java:[70,43]
 org.apache.hadoop.hbase.regionserver.RegionServerUtil is not public in 
org.apache.hadoop.hbase.regionserver; cannot be accessed from outside package

/Users/Stack/checkouts/trunk/src/main/java/org/apache/hadoop/hbase/master/ServerManager.java:[55,43]
 org.apache.hadoop.hbase.regionserver.RegionServerUtil is not public in 
org.apache.hadoop.hbase.regionserver; cannot be accessed from outside package
{code}

What are these classes making use of 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] [Created] (HBASE-5942) HConnnectionManager.getRegionServerWithRetries doesn't call afterCall properly

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

[Jimmy Xiang (JIRA)]

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

Jimmy Xiang commented on HBASE-5889:


The purpose is to re-use some shared code. I was thinking to separate it into 
two util classes: ClientUtil and AdminUtil, in the client package.
It is not for region server only.  How is that?

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

[Phabricator (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[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

[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

[Zhihong Yu (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Phabricator (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Phabricator (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[nkeywal (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[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

[Nate Putnam (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Hadoop QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Phabricator (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Phabricator (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Phabricator (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Phabricator (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Phabricator (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Phabricator (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[jira] [Commented] (HBASE-5295) Improve the Thrift API to switch on/off writing to wal for Mutations

[Phabricator (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-5295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13268724#comment-13268724
 ] 

Phabricator commented on HBASE-5295:


Kannan has commented on the revision "[jira] [HBASE-5295] [89-fb] Improve the 
Thrift API to switch on/off writing to wal for Mutations".

INLINE COMMENTS
  src/main/java/org/apache/hadoop/hbase/thrift/ThriftServerRunner.java:989 
@mikhail: the tighter check you added to make sure all mutations have the same 
writeToWAL setting should be added for this case too.

  Otherwise, rest of the diff looks really good. And nice test!

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


> Improve the Thrift API  to switch on/off writing to wal for Mutations
> -
>
> Key: HBASE-5295
> URL: https://issues.apache.org/jira/browse/HBASE-5295
> Project: HBase
>  Issue Type: Improvement
>  Components: thrift
>Reporter: dhruba borthakur
>Assignee: dhruba borthakur
> Attachments: D1515.1.patch, D1515.1.patch, D1515.1.patch, 
> D1515.1.patch, D1515.2.patch, D1515.2.patch, D1515.2.patch, D1515.2.patch, 
> D3015.1.patch
>
>
> The thrift api currently does not support switching off updating wal for 
> Puts/Deletes. Support it.

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

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

[stack (JIRA)]

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

stack commented on HBASE-5889:
--

The util is for serverside though?  If not, if for client side, then yes, 
belongs in client package.  Good on you Jimmy.

> 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