[jira] [Updated] (HBASE-5733) AssignmentManager#processDeadServersAndRegionsInTransition can fail with NPE.

[Uma Maheswara Rao G (Updated) (JIRA)]

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

Uma Maheswara Rao G updated HBASE-5733:
---

Affects Version/s: 0.96.0

> AssignmentManager#processDeadServersAndRegionsInTransition can fail with NPE.
> -
>
> Key: HBASE-5733
> URL: https://issues.apache.org/jira/browse/HBASE-5733
> Project: HBase
>  Issue Type: Bug
>  Components: master
>Affects Versions: 0.96.0
>Reporter: Uma Maheswara Rao G
>Assignee: Uma Maheswara Rao G
>
> Found while going through the code...
> AssignmentManager#processDeadServersAndRegionsInTransition can fail with NPE 
> as this is directly iterating the nodes from 
> listChildrenAndWatchForNewChildren with-out checking for null.
> Here also we need to handle with  null  check like other places.

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

[jira] [Commented] (HBASE-5729) Jenkins build failing; failsafe NPE'ing

[nkeywal (Commented) (JIRA)]

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

nkeywal commented on HBASE-5729:


For future reference if it happens again:

root exception was
{noformat}
Caused by: java.lang.NullPointerException
at 
org.apache.maven.surefire.util.DefaultDirectoryScanner.processIncludesExcludes(DefaultDirectoryScanner.java:136)
at 
org.apache.maven.surefire.util.DefaultDirectoryScanner.collectTests(DefaultDirectoryScanner.java:113)
at 
org.apache.maven.surefire.util.DefaultDirectoryScanner.locateTestClasses(DefaultDirectoryScanner.java:62)
at 
org.apache.maven.surefire.junitcore.JUnitCoreProvider.scanClassPath(JUnitCoreProvider.java:188)
at 
org.apache.maven.surefire.junitcore.JUnitCoreProvider.getSuitesAsList(JUnitCoreProvider.java:145)
at 
org.apache.maven.surefire.junitcore.JUnitCoreProvider.getSuites(JUnitCoreProvider.java:103)
{noformat}

Initial error was:

{noformat}
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-failsafe-plugin:2.12-TRUNK-HBASE-2:integration-test
 (integration-test) on project hbase: Execution integration-test of goal 
org.apache.maven.plugins:maven-failsafe-plugin:2.12-TRUNK-HBASE-2:integration-test
 failed: java.lang.reflect.InvocationTargetException; nested exception is 
java.lang.reflect.InvocationTargetException: null: NullPointerException -> 
[Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal 
org.apache.maven.plugins:maven-failsafe-plugin:2.12-TRUNK-HBASE-2:integration-test
 (integration-test) on project hbase: Execution integration-test of goal 
org.apache.maven.plugins:maven-failsafe-plugin:2.12-TRUNK-HBASE-2:integration-test
 failed: java.lang.reflect.InvocationTargetException; nested exception is 
java.lang.reflect.InvocationTargetException: null
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
{noformat}

> Jenkins build failing; failsafe NPE'ing
> ---
>
> Key: HBASE-5729
> URL: https://issues.apache.org/jira/browse/HBASE-5729
> Project: HBase
>  Issue Type: Bug
>Reporter: stack
>Assignee: stack
>Priority: Blocker
>
> Builds up on jenkins have been failing over the last few days.  Looking at it 
> w/ nkeyway, its kinda odd.  I ran exact command locally as did N and it works 
> fine.  I removed all of my repo and still works.  N looked at surefire 
> source.  Its the includes that is coming back empty causing the NPE we see up 
> on jenkins.  Extra odd is that it does not seem like it a checkin of ours 
> that brought this on.  See here where its 'working' on 0.94 branch: 
> https://builds.apache.org/view/G-L/view/HBase/job/HBase-0.94/76/  Then a 
> little later Ted triggers a build w/ no changes made: 
> https://builds.apache.org/view/G-L/view/HBase/job/HBase-0.94/77/console
> Its failing running the integration test phase.  Let me mess around and try 
> and get it going again.

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

[jira] [Commented] (HBASE-5729) Jenkins build failing; failsafe NPE'ing

[nkeywal (Commented) (JIRA)]

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

nkeywal commented on HBASE-5729:


{noformat}
mvn -e  site install assembly:single  -Dtest.exclude.pattern="whatever"
{noformat}

works as well. It seems that surefire wants the variables to be defined in
{noformat}

  ${unittest.include}
  **/*$*
  ${test.exclude.pattern}

{noformat}

So suppressing the line in the .pom sould be ok, even if it does not explain 
why it was working before.


> Jenkins build failing; failsafe NPE'ing
> ---
>
> Key: HBASE-5729
> URL: https://issues.apache.org/jira/browse/HBASE-5729
> Project: HBase
>  Issue Type: Bug
>Reporter: stack
>Assignee: stack
>Priority: Blocker
>
> Builds up on jenkins have been failing over the last few days.  Looking at it 
> w/ nkeyway, its kinda odd.  I ran exact command locally as did N and it works 
> fine.  I removed all of my repo and still works.  N looked at surefire 
> source.  Its the includes that is coming back empty causing the NPE we see up 
> on jenkins.  Extra odd is that it does not seem like it a checkin of ours 
> that brought this on.  See here where its 'working' on 0.94 branch: 
> https://builds.apache.org/view/G-L/view/HBase/job/HBase-0.94/76/  Then a 
> little later Ted triggers a build w/ no changes made: 
> https://builds.apache.org/view/G-L/view/HBase/job/HBase-0.94/77/console
> Its failing running the integration test phase.  Let me mess around and try 
> and get it going again.

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

[jira] [Commented] (HBASE-1936) ClassLoader that loads from hdfs; useful adding filters to classpath without having to restart services

[Jieshan Bean (Commented) (JIRA)]

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

Jieshan Bean commented on HBASE-1936:
-

Yes.
Regarding on how to add the new class into HDFS seems not mentioned in this 
patch. Should we also take care of this?


> ClassLoader that loads from hdfs; useful adding filters to classpath without 
> having to restart services
> ---
>
> Key: HBASE-1936
> URL: https://issues.apache.org/jira/browse/HBASE-1936
> Project: HBase
>  Issue Type: New Feature
>Reporter: stack
>Assignee: Daniel Ploeg
>  Labels: noob
> Attachments: cp_from_hdfs.patch
>
>


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

[jira] [Commented] (HBASE-5599) The hbck tool can not fix the six scenarios, it is NO_VERSION_FILE, NOT_IN_META_OR_DEPLOYED, NOT_IN_META, SHOULD_NOT_BE_DEPLOYED, FIRST_REGION_STARTKEY_NOT_EMPTY, HOLE_

[fulin wang (Commented) (JIRA)]

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

fulin wang commented on HBASE-5599:
---

I have writed the test case. I am running all the test case,
But the test case testShouldCheckMasterFailOverWhenMETAIsInOpenedState always 
failed.

> The hbck tool can not fix the six scenarios, it is NO_VERSION_FILE, 
> NOT_IN_META_OR_DEPLOYED, NOT_IN_META, SHOULD_NOT_BE_DEPLOYED, 
> FIRST_REGION_STARTKEY_NOT_EMPTY, HOLE_IN_REGION_CHAIN.
> 
>
> Key: HBASE-5599
> URL: https://issues.apache.org/jira/browse/HBASE-5599
> Project: HBase
>  Issue Type: New Feature
>  Components: hbck
>Affects Versions: 0.90.6
>Reporter: fulin wang
>Assignee: fulin wang
> Fix For: 0.90.6
>
> Attachments: hbase-5599-0.90.patch, hbase-5599-0.90_v2.patch, 
> hbase-5599-0.90_v3.patch, hbase-5599-0.90_v5.patch, hbase-5599-0.90_v6.patch, 
> hbase-5599-0.92_v5.patch, hbase-5599-0.94_v5.patch, hbase-5599-trunk_v5.patch
>
>
> The hbck tool can not fix the six scenarios.
> 1. Version file does not exist in root dir.
>Fix: I try to create a version file by 'FSUtils.setVersion' method.
>
> 2. [REGIONNAME][KEY] on HDFS, but not listed in META or deployed on any 
> region server.
>Fix: I get region info form the hdfs file, this region info write to 
> '.META.' table.
>
> 3. [REGIONNAME][KEY] not in META, but deployed on [SERVERNAME]
>Fix: I get region info form the hdfs file, this region info write to 
> '.META.' table.
>
> 4. [REGIONNAME] should not be deployed according to META, but is deployed on 
> [SERVERNAME]
>Fix: Close this region.
>
> 5. First region should start with an empty key.  You need to  create a new 
> region and regioninfo in HDFS to plug the hole.
>Fix: The region info is not in hdfs and .META., so it create a empty 
> region for this error.
> 6. There is a hole in the region chain between [KEY] and [KEY]. You need to 
> create a new regioninfo and region dir in hdfs to plug the hole.
>   Fix: The region info is not in hdfs and .META., so it create a empty region 
> for this hole.
>   

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

[jira] [Commented] (HBASE-5615) the master never does balance because of balancing the parent region

[Zhihong Yu (Commented) (JIRA)]

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

Zhihong Yu commented on HBASE-5615:
---

Thanks for the finding, Ram.

Reverted from 0.92, 0.94 and trunk.

> the master never does balance because of balancing the parent region
> 
>
> Key: HBASE-5615
> URL: https://issues.apache.org/jira/browse/HBASE-5615
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 0.90.7
>Reporter: xufeng
>Assignee: xufeng
>Priority: Critical
> Fix For: 0.90.7, 0.92.2, 0.94.0, 0.96.0
>
> Attachments: 5615-trunk.txt, HBASE-5615-90.patch, HBASE-5615.patch, 
> NoPatched-surefire-report-5615-90.html, Patched_surefire-report-5615-90.html
>
>
> the master never do balance becauseof when master do rebuildUserRegions()，it 
> will add the parent region into  AssignmentManager#servers,
> if balancer let the parent region to move,the parent will in RIT forever.thus 
> balance will never be executed.

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

[jira] [Commented] (HBASE-5680) Hbase94 and Hbase 92.2 is not compatible with the Hadoop 23.1

[Zhihong Yu (Commented) (JIRA)]

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

Zhihong Yu commented on HBASE-5680:
---

Thanks for the reply, Jon.


> Hbase94 and Hbase 92.2 is not compatible with the Hadoop 23.1 
> --
>
> Key: HBASE-5680
> URL: https://issues.apache.org/jira/browse/HBASE-5680
> Project: HBase
>  Issue Type: Bug
>  Components: master
>Affects Versions: 0.90.6, 0.92.1, 0.94.0, 0.96.0
>Reporter: Kristam Subba Swathi
>Assignee: Jonathan Hsieh
> Attachments: hbase-5680-94.patch
>
>
> Hmaster is not able to start because of the following error
> Please find the following error 
> 
> 2012-03-30 11:12:19,487 FATAL org.apache.hadoop.hbase.master.HMaster: 
> Unhandled exception. Starting shutdown.
> java.lang.NoClassDefFoundError: 
> org/apache/hadoop/hdfs/protocol/FSConstants$SafeModeAction
>   at org.apache.hadoop.hbase.util.FSUtils.waitOnSafeMode(FSUtils.java:524)
>   at 
> org.apache.hadoop.hbase.master.MasterFileSystem.checkRootDir(MasterFileSystem.java:324)
>   at 
> org.apache.hadoop.hbase.master.MasterFileSystem.createInitialFileSystemLayout(MasterFileSystem.java:127)
>   at 
> org.apache.hadoop.hbase.master.MasterFileSystem.(MasterFileSystem.java:112)
>   at 
> org.apache.hadoop.hbase.master.HMaster.finishInitialization(HMaster.java:496)
>   at org.apache.hadoop.hbase.master.HMaster.run(HMaster.java:363)
>   at java.lang.Thread.run(Thread.java:662)
> Caused by: java.lang.ClassNotFoundException: 
> org.apache.hadoop.hdfs.protocol.FSConstants$SafeModeAction
>   at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
>   at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
>   ... 7 more
> There is a change in the FSConstants

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

[jira] [Commented] (HBASE-1936) ClassLoader that loads from hdfs; useful adding filters to classpath without having to restart services

[stack (Commented) (JIRA)]

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

stack commented on HBASE-1936:
--

Jieshan This patch is really old.  Do whatever you want with it to make it work.

> ClassLoader that loads from hdfs; useful adding filters to classpath without 
> having to restart services
> ---
>
> Key: HBASE-1936
> URL: https://issues.apache.org/jira/browse/HBASE-1936
> Project: HBase
>  Issue Type: New Feature
>Reporter: stack
>Assignee: Daniel Ploeg
>  Labels: noob
> Attachments: cp_from_hdfs.patch
>
>


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

[jira] [Commented] (HBASE-5615) the master never does balance because of balancing the parent region

[Hudson (Commented) (JIRA)]

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

Hudson commented on HBASE-5615:
---

Integrated in HBase-TRUNK #2719 (See 
[https://builds.apache.org/job/HBase-TRUNK/2719/])
HBASE-5615 revert due to race condition in case master dies (Revision 
1310324)

 Result = SUCCESS
tedyu : 
Files : 
* 
/hbase/trunk/src/main/java/org/apache/hadoop/hbase/master/AssignmentManager.java


> the master never does balance because of balancing the parent region
> 
>
> Key: HBASE-5615
> URL: https://issues.apache.org/jira/browse/HBASE-5615
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 0.90.7
>Reporter: xufeng
>Assignee: xufeng
>Priority: Critical
> Fix For: 0.90.7, 0.92.2, 0.94.0, 0.96.0
>
> Attachments: 5615-trunk.txt, HBASE-5615-90.patch, HBASE-5615.patch, 
> NoPatched-surefire-report-5615-90.html, Patched_surefire-report-5615-90.html
>
>
> the master never do balance becauseof when master do rebuildUserRegions()，it 
> will add the parent region into  AssignmentManager#servers,
> if balancer let the parent region to move,the parent will in RIT forever.thus 
> balance will never be executed.

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

[jira] [Commented] (HBASE-5615) the master never does balance because of balancing the parent region

[Hudson (Commented) (JIRA)]

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

Hudson commented on HBASE-5615:
---

Integrated in HBase-0.94 #92 (See 
[https://builds.apache.org/job/HBase-0.94/92/])
HBASE-5615 revert due to race condition in case master dies (Revision 
1310322)

 Result = SUCCESS
tedyu : 
Files : 
* 
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/master/AssignmentManager.java


> the master never does balance because of balancing the parent region
> 
>
> Key: HBASE-5615
> URL: https://issues.apache.org/jira/browse/HBASE-5615
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 0.90.7
>Reporter: xufeng
>Assignee: xufeng
>Priority: Critical
> Fix For: 0.90.7, 0.92.2, 0.94.0, 0.96.0
>
> Attachments: 5615-trunk.txt, HBASE-5615-90.patch, HBASE-5615.patch, 
> NoPatched-surefire-report-5615-90.html, Patched_surefire-report-5615-90.html
>
>
> the master never do balance becauseof when master do rebuildUserRegions()，it 
> will add the parent region into  AssignmentManager#servers,
> if balancer let the parent region to move,the parent will in RIT forever.thus 
> balance will never be executed.

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

[jira] [Commented] (HBASE-5213) "hbase master stop" does not bring down backup masters

[stack (Commented) (JIRA)]

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

stack commented on HBASE-5213:
--

This seems to have broken 0.90 builds.  Can we revert from 0.90 trunk till 
fixed.  See here: https://builds.apache.org/view/G-L/view/HBase/job/hbase-0.90/ 
 Build #458 is where it got committed and thereafter the build fails rolling 
the wal test.

> "hbase master stop" does not bring down backup masters
> --
>
> Key: HBASE-5213
> URL: https://issues.apache.org/jira/browse/HBASE-5213
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 0.90.5, 0.92.0, 0.94.0, 0.96.0
>Reporter: Gregory Chanan
>Assignee: Gregory Chanan
>Priority: Minor
> Fix For: 0.90.7, 0.92.2, 0.94.0, 0.96.0
>
> Attachments: HBASE-5213-v0-trunk.patch, HBASE-5213-v1-trunk.patch, 
> HBASE-5213-v2-90.patch, HBASE-5213-v2-92.patch, HBASE-5213-v2-trunk.patch
>
>
> Typing "hbase master stop" produces the following message:
> "stop   Start cluster shutdown; Master signals RegionServer shutdown"
> It seems like backup masters should be considered part of the cluster, but 
> they are not brought down by "hbase master stop".
> "stop-hbase.sh" does correctly bring down the backup masters.
> The same behavior is observed when a client app makes use of the client API 
> HBaseAdmin.shutdown() 
> http://hbase.apache.org/apidocs/org/apache/hadoop/hbase/client/HBaseAdmin.html#shutdown()
>  -- this isn't too surprising since I think "hbase master stop" just calls 
> this API.
> It seems like HBASE-1448 address this; perhaps there was a regression?

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

[jira] [Commented] (HBASE-5680) Hbase94 and Hbase 92.2 is not compatible with the Hadoop 23.1

[stack (Commented) (JIRA)]

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

stack commented on HBASE-5680:
--

+1 on patch

> Hbase94 and Hbase 92.2 is not compatible with the Hadoop 23.1 
> --
>
> Key: HBASE-5680
> URL: https://issues.apache.org/jira/browse/HBASE-5680
> Project: HBase
>  Issue Type: Bug
>  Components: master
>Affects Versions: 0.90.6, 0.92.1, 0.94.0, 0.96.0
>Reporter: Kristam Subba Swathi
>Assignee: Jonathan Hsieh
> Attachments: hbase-5680-94.patch
>
>
> Hmaster is not able to start because of the following error
> Please find the following error 
> 
> 2012-03-30 11:12:19,487 FATAL org.apache.hadoop.hbase.master.HMaster: 
> Unhandled exception. Starting shutdown.
> java.lang.NoClassDefFoundError: 
> org/apache/hadoop/hdfs/protocol/FSConstants$SafeModeAction
>   at org.apache.hadoop.hbase.util.FSUtils.waitOnSafeMode(FSUtils.java:524)
>   at 
> org.apache.hadoop.hbase.master.MasterFileSystem.checkRootDir(MasterFileSystem.java:324)
>   at 
> org.apache.hadoop.hbase.master.MasterFileSystem.createInitialFileSystemLayout(MasterFileSystem.java:127)
>   at 
> org.apache.hadoop.hbase.master.MasterFileSystem.(MasterFileSystem.java:112)
>   at 
> org.apache.hadoop.hbase.master.HMaster.finishInitialization(HMaster.java:496)
>   at org.apache.hadoop.hbase.master.HMaster.run(HMaster.java:363)
>   at java.lang.Thread.run(Thread.java:662)
> Caused by: java.lang.ClassNotFoundException: 
> org.apache.hadoop.hdfs.protocol.FSConstants$SafeModeAction
>   at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
>   at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
>   ... 7 more
> There is a change in the FSConstants

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-5640) bulk load runs slowly than before

[stack (Updated) (JIRA)]

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

stack updated HBASE-5640:
-

Status: Patch Available  (was: Open)

> bulk load runs slowly than before
> -
>
> Key: HBASE-5640
> URL: https://issues.apache.org/jira/browse/HBASE-5640
> Project: HBase
>  Issue Type: Bug
>Reporter: dhruba borthakur
>Assignee: dhruba borthakur
>Priority: Minor
>  Labels: bulkloader
> Attachments: bulkLoadFs1.txt, bulkLoadFs2.txt
>
>
> I am loading data from an external system into hbase. There are many prints 
> of the form. This is possibly a regression caused by a recent patch.
> on different filesystem than destination store - moving to this filesystem

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

[jira] [Commented] (HBASE-5739) Upgrade guava to 11.0.2

[stack (Commented) (JIRA)]

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

stack commented on HBASE-5739:
--

+1 on patch.

> Upgrade guava to 11.0.2
> ---
>
> Key: HBASE-5739
> URL: https://issues.apache.org/jira/browse/HBASE-5739
> Project: HBase
>  Issue Type: Improvement
>  Components: build
>Affects Versions: 0.96.0
>Reporter: Todd Lipcon
>Assignee: Todd Lipcon
> Fix For: 0.96.0
>
> Attachments: hbase-5739.txt
>
>
> Hadoop has upgraded to this new version of Guava. We should, too, so we don't 
> have compatibility issues running on Hadoop 2.0+

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

[jira] [Commented] (HBASE-5213) "hbase master stop" does not bring down backup masters

[David S. Wang (Commented) (JIRA)]

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

David S. Wang commented on HBASE-5213:
--

Greg is out of town for the next week or so ... IMHO if it's breaking 0.90, we 
should revert for now and Greg can look at it when he gets back.

> "hbase master stop" does not bring down backup masters
> --
>
> Key: HBASE-5213
> URL: https://issues.apache.org/jira/browse/HBASE-5213
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 0.90.5, 0.92.0, 0.94.0, 0.96.0
>Reporter: Gregory Chanan
>Assignee: Gregory Chanan
>Priority: Minor
> Fix For: 0.90.7, 0.92.2, 0.94.0, 0.96.0
>
> Attachments: HBASE-5213-v0-trunk.patch, HBASE-5213-v1-trunk.patch, 
> HBASE-5213-v2-90.patch, HBASE-5213-v2-92.patch, HBASE-5213-v2-trunk.patch
>
>
> Typing "hbase master stop" produces the following message:
> "stop   Start cluster shutdown; Master signals RegionServer shutdown"
> It seems like backup masters should be considered part of the cluster, but 
> they are not brought down by "hbase master stop".
> "stop-hbase.sh" does correctly bring down the backup masters.
> The same behavior is observed when a client app makes use of the client API 
> HBaseAdmin.shutdown() 
> http://hbase.apache.org/apidocs/org/apache/hadoop/hbase/client/HBaseAdmin.html#shutdown()
>  -- this isn't too surprising since I think "hbase master stop" just calls 
> this API.
> It seems like HBASE-1448 address this; perhaps there was a regression?

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

[jira] [Commented] (HBASE-5689) Skipping RecoveredEdits may cause data loss

[stack (Commented) (JIRA)]

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

stack commented on HBASE-5689:
--

@Ming (Hey, long time no hear from you).

On 1., yes, sounds good.  I do not think 2. holds.  It is more robust replaying 
any file that is > 'current max seqid of the region' at least until we do more 
thinking on this topic.  The WAL split can be messy or just as bad, we can be 
inventive around how we might split WALs and how we might write files to 
replay. 

> Skipping RecoveredEdits may cause data loss
> ---
>
> Key: HBASE-5689
> URL: https://issues.apache.org/jira/browse/HBASE-5689
> Project: HBase
>  Issue Type: Bug
>  Components: regionserver
>Affects Versions: 0.94.0
>Reporter: chunhui shen
>Assignee: chunhui shen
>Priority: Critical
> Fix For: 0.94.0
>
> Attachments: 5689-testcase.patch, 5689-v4.txt, HBASE-5689.patch, 
> HBASE-5689.patch, HBASE-5689v2.patch, HBASE-5689v3.patch
>
>
> Let's see the following scenario:
> 1.Region is on the server A
> 2.put KV(r1->v1) to the region
> 3.move region from server A to server B
> 4.put KV(r2->v2) to the region
> 5.move region from server B to server A
> 6.put KV(r3->v3) to the region
> 7.kill -9 server B and start it
> 8.kill -9 server A and start it 
> 9.scan the region, we could only get two KV(r1->v1,r2->v2), the third 
> KV(r3->v3) is lost.
> Let's analyse the upper scenario from the code:
> 1.the edit logs of KV(r1->v1) and KV(r3->v3) are both recorded in the same 
> hlog file on server A.
> 2.when we split server B's hlog file in the process of ServerShutdownHandler, 
> we create one RecoveredEdits file f1 for the region.
> 2.when we split server A's hlog file in the process of ServerShutdownHandler, 
> we create another RecoveredEdits file f2 for the region.
> 3.however, RecoveredEdits file f2 will be skiped when initializing region
> HRegion#replayRecoveredEditsIfAny
> {code}
>  for (Path edits: files) {
>   if (edits == null || !this.fs.exists(edits)) {
> LOG.warn("Null or non-existent edits file: " + edits);
> continue;
>   }
>   if (isZeroLengthThenDelete(this.fs, edits)) continue;
>   if (checkSafeToSkip) {
> Path higher = files.higher(edits);
> long maxSeqId = Long.MAX_VALUE;
> if (higher != null) {
>   // Edit file name pattern, HLog.EDITFILES_NAME_PATTERN: "-?[0-9]+"
>   String fileName = higher.getName();
>   maxSeqId = Math.abs(Long.parseLong(fileName));
> }
> if (maxSeqId <= minSeqId) {
>   String msg = "Maximum possible sequenceid for this log is " + 
> maxSeqId
>   + ", skipped the whole file, path=" + edits;
>   LOG.debug(msg);
>   continue;
> } else {
>   checkSafeToSkip = false;
> }
>   }
> {code}
>  

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

[jira] [Updated] (HBASE-5739) Upgrade guava to 11.0.2

[Zhihong Yu (Updated) (JIRA)]

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

Zhihong Yu updated HBASE-5739:
--

Status: Patch Available  (was: Open)

> Upgrade guava to 11.0.2
> ---
>
> Key: HBASE-5739
> URL: https://issues.apache.org/jira/browse/HBASE-5739
> Project: HBase
>  Issue Type: Improvement
>  Components: build
>Affects Versions: 0.96.0
>Reporter: Todd Lipcon
>Assignee: Todd Lipcon
> Fix For: 0.96.0
>
> Attachments: hbase-5739.txt
>
>
> Hadoop has upgraded to this new version of Guava. We should, too, so we don't 
> have compatibility issues running on Hadoop 2.0+

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-5680) Improve compatibility warning about HBase with Hadoop 0.23.x

[Jonathan Hsieh (Updated) (JIRA)]

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

Jonathan Hsieh updated HBASE-5680:
--

Summary: Improve compatibility warning about HBase with Hadoop 0.23.x  
(was: Hbase94 and Hbase 92.2 is not compatible with the Hadoop 23.1 )

> Improve compatibility warning about HBase with Hadoop 0.23.x
> 
>
> Key: HBASE-5680
> URL: https://issues.apache.org/jira/browse/HBASE-5680
> Project: HBase
>  Issue Type: Bug
>  Components: master
>Affects Versions: 0.90.6, 0.92.1, 0.94.0, 0.96.0
>Reporter: Kristam Subba Swathi
>Assignee: Jonathan Hsieh
> Attachments: hbase-5680-94.patch
>
>
> Hmaster is not able to start because of the following error
> Please find the following error 
> 
> 2012-03-30 11:12:19,487 FATAL org.apache.hadoop.hbase.master.HMaster: 
> Unhandled exception. Starting shutdown.
> java.lang.NoClassDefFoundError: 
> org/apache/hadoop/hdfs/protocol/FSConstants$SafeModeAction
>   at org.apache.hadoop.hbase.util.FSUtils.waitOnSafeMode(FSUtils.java:524)
>   at 
> org.apache.hadoop.hbase.master.MasterFileSystem.checkRootDir(MasterFileSystem.java:324)
>   at 
> org.apache.hadoop.hbase.master.MasterFileSystem.createInitialFileSystemLayout(MasterFileSystem.java:127)
>   at 
> org.apache.hadoop.hbase.master.MasterFileSystem.(MasterFileSystem.java:112)
>   at 
> org.apache.hadoop.hbase.master.HMaster.finishInitialization(HMaster.java:496)
>   at org.apache.hadoop.hbase.master.HMaster.run(HMaster.java:363)
>   at java.lang.Thread.run(Thread.java:662)
> Caused by: java.lang.ClassNotFoundException: 
> org.apache.hadoop.hdfs.protocol.FSConstants$SafeModeAction
>   at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
>   at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
>   ... 7 more
> There is a change in the FSConstants

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

[jira] [Commented] (HBASE-5723) Simple Design of Secondary Index

[Jesse Yates (Commented) (JIRA)]

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

Jesse Yates commented on HBASE-5723:


There is a lot of work that the Lily guys have done along the lines of ensuring 
consistency, but basically revolves around using a WAL for making sure the 
edits get back in. Personally, I find their approach a bit heavy handed (esp 
with the coprocessor framework _now_ available, though it makes sense before 
CPs). They also have done a lot of work (open source!) for indexing different 
data types, integration with Solr, etc. Either way, worth taking a dive into 
their stuff, if only for inspiration and seeing what people who have thought a 
lot about this problem have some up with.

> Simple Design of Secondary Index
> 
>
> Key: HBASE-5723
> URL: https://issues.apache.org/jira/browse/HBASE-5723
> Project: HBase
>  Issue Type: New Feature
>  Components: coprocessors
>Reporter: ShiXing
>Priority: Minor
> Attachments: Simple Design of HBase SecondaryIndex.pdf
>
>
> Use coprocessor to create index. And primary tables' compaction to purge the 
> stale data. 
> Attach file is the Design of the Seconday Index.

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

[jira] [Commented] (HBASE-5680) Improve compatibility warning about HBase with Hadoop 0.23.x

[Jonathan Hsieh (Commented) (JIRA)]

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

Jonathan Hsieh commented on HBASE-5680:
---

Failed test worked locally for me, and is unrelated.

Commiting to 0.90/0.92/0.94/trunk.  Thanks for taking a look ram, ted, stack!

> Improve compatibility warning about HBase with Hadoop 0.23.x
> 
>
> Key: HBASE-5680
> URL: https://issues.apache.org/jira/browse/HBASE-5680
> Project: HBase
>  Issue Type: Bug
>  Components: master
>Affects Versions: 0.90.6, 0.92.1, 0.94.0, 0.96.0
>Reporter: Kristam Subba Swathi
>Assignee: Jonathan Hsieh
> Attachments: hbase-5680-94.patch
>
>
> Hmaster is not able to start because of the following error
> Please find the following error 
> 
> 2012-03-30 11:12:19,487 FATAL org.apache.hadoop.hbase.master.HMaster: 
> Unhandled exception. Starting shutdown.
> java.lang.NoClassDefFoundError: 
> org/apache/hadoop/hdfs/protocol/FSConstants$SafeModeAction
>   at org.apache.hadoop.hbase.util.FSUtils.waitOnSafeMode(FSUtils.java:524)
>   at 
> org.apache.hadoop.hbase.master.MasterFileSystem.checkRootDir(MasterFileSystem.java:324)
>   at 
> org.apache.hadoop.hbase.master.MasterFileSystem.createInitialFileSystemLayout(MasterFileSystem.java:127)
>   at 
> org.apache.hadoop.hbase.master.MasterFileSystem.(MasterFileSystem.java:112)
>   at 
> org.apache.hadoop.hbase.master.HMaster.finishInitialization(HMaster.java:496)
>   at org.apache.hadoop.hbase.master.HMaster.run(HMaster.java:363)
>   at java.lang.Thread.run(Thread.java:662)
> Caused by: java.lang.ClassNotFoundException: 
> org.apache.hadoop.hdfs.protocol.FSConstants$SafeModeAction
>   at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
>   at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
>   ... 7 more
> There is a change in the FSConstants

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-5680) Improve compatibility warning about HBase with Hadoop 0.23.x

[Jonathan Hsieh (Updated) (JIRA)]

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

Jonathan Hsieh updated HBASE-5680:
--

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

> Improve compatibility warning about HBase with Hadoop 0.23.x
> 
>
> Key: HBASE-5680
> URL: https://issues.apache.org/jira/browse/HBASE-5680
> Project: HBase
>  Issue Type: Bug
>  Components: master
>Affects Versions: 0.90.6, 0.92.1, 0.94.0, 0.96.0
>Reporter: Kristam Subba Swathi
>Assignee: Jonathan Hsieh
> Fix For: 0.90.7, 0.92.2, 0.94.0, 0.96.0
>
> Attachments: hbase-5680-94.patch
>
>
> Hmaster is not able to start because of the following error
> Please find the following error 
> 
> 2012-03-30 11:12:19,487 FATAL org.apache.hadoop.hbase.master.HMaster: 
> Unhandled exception. Starting shutdown.
> java.lang.NoClassDefFoundError: 
> org/apache/hadoop/hdfs/protocol/FSConstants$SafeModeAction
>   at org.apache.hadoop.hbase.util.FSUtils.waitOnSafeMode(FSUtils.java:524)
>   at 
> org.apache.hadoop.hbase.master.MasterFileSystem.checkRootDir(MasterFileSystem.java:324)
>   at 
> org.apache.hadoop.hbase.master.MasterFileSystem.createInitialFileSystemLayout(MasterFileSystem.java:127)
>   at 
> org.apache.hadoop.hbase.master.MasterFileSystem.(MasterFileSystem.java:112)
>   at 
> org.apache.hadoop.hbase.master.HMaster.finishInitialization(HMaster.java:496)
>   at org.apache.hadoop.hbase.master.HMaster.run(HMaster.java:363)
>   at java.lang.Thread.run(Thread.java:662)
> Caused by: java.lang.ClassNotFoundException: 
> org.apache.hadoop.hdfs.protocol.FSConstants$SafeModeAction
>   at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
>   at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
>   ... 7 more
> There is a change in the FSConstants

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

[jira] [Reopened] (HBASE-5213) "hbase master stop" does not bring down backup masters

[Zhihong Yu (Reopened) (JIRA)]

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

Zhihong Yu reopened HBASE-5213:
---


TestLogRolling hangs in 0.90

> "hbase master stop" does not bring down backup masters
> --
>
> Key: HBASE-5213
> URL: https://issues.apache.org/jira/browse/HBASE-5213
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 0.90.5, 0.92.0, 0.94.0, 0.96.0
>Reporter: Gregory Chanan
>Assignee: Gregory Chanan
>Priority: Minor
> Fix For: 0.90.7, 0.92.2, 0.94.0, 0.96.0
>
> Attachments: 5213.jstack, HBASE-5213-v0-trunk.patch, 
> HBASE-5213-v1-trunk.patch, HBASE-5213-v2-90.patch, HBASE-5213-v2-92.patch, 
> HBASE-5213-v2-trunk.patch
>
>
> Typing "hbase master stop" produces the following message:
> "stop   Start cluster shutdown; Master signals RegionServer shutdown"
> It seems like backup masters should be considered part of the cluster, but 
> they are not brought down by "hbase master stop".
> "stop-hbase.sh" does correctly bring down the backup masters.
> The same behavior is observed when a client app makes use of the client API 
> HBaseAdmin.shutdown() 
> http://hbase.apache.org/apidocs/org/apache/hadoop/hbase/client/HBaseAdmin.html#shutdown()
>  -- this isn't too surprising since I think "hbase master stop" just calls 
> this API.
> It seems like HBASE-1448 address this; perhaps there was a regression?

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

[jira] [Commented] (HBASE-5689) Skipping RecoveredEdits may cause data loss

[stack (Commented) (JIRA)]

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

stack commented on HBASE-5689:
--

Looking at the patch, it looks good to me.

On the Math.abs, its probably not needed any more given current file formats 
but its not doing any harm.  I tried to go back through src history to see how 
we used name the recovered edits files -- they used be called stuff like 
oldlogfile.log, etc -- and they have been named for first seqid in the file 
since 0.90 so its unlikely this will ever go negative or that this code will 
encouter a file named negatively.

I also thought that perhaps this patch only for trunk because what about the 
case where we have existing wal files that are still named by the first seqid 
in the file?  But this should be fine.  We'll over-replay rather than 
under-replay edits in this case so it should be fine.

+1 on commit adding back the Math.abs on commit (though reasoning would have it 
we don't need, I think we should add it back just-in-case).

> Skipping RecoveredEdits may cause data loss
> ---
>
> Key: HBASE-5689
> URL: https://issues.apache.org/jira/browse/HBASE-5689
> Project: HBase
>  Issue Type: Bug
>  Components: regionserver
>Affects Versions: 0.94.0
>Reporter: chunhui shen
>Assignee: chunhui shen
>Priority: Critical
> Fix For: 0.94.0
>
> Attachments: 5689-testcase.patch, 5689-v4.txt, HBASE-5689.patch, 
> HBASE-5689.patch, HBASE-5689v2.patch, HBASE-5689v3.patch
>
>
> Let's see the following scenario:
> 1.Region is on the server A
> 2.put KV(r1->v1) to the region
> 3.move region from server A to server B
> 4.put KV(r2->v2) to the region
> 5.move region from server B to server A
> 6.put KV(r3->v3) to the region
> 7.kill -9 server B and start it
> 8.kill -9 server A and start it 
> 9.scan the region, we could only get two KV(r1->v1,r2->v2), the third 
> KV(r3->v3) is lost.
> Let's analyse the upper scenario from the code:
> 1.the edit logs of KV(r1->v1) and KV(r3->v3) are both recorded in the same 
> hlog file on server A.
> 2.when we split server B's hlog file in the process of ServerShutdownHandler, 
> we create one RecoveredEdits file f1 for the region.
> 2.when we split server A's hlog file in the process of ServerShutdownHandler, 
> we create another RecoveredEdits file f2 for the region.
> 3.however, RecoveredEdits file f2 will be skiped when initializing region
> HRegion#replayRecoveredEditsIfAny
> {code}
>  for (Path edits: files) {
>   if (edits == null || !this.fs.exists(edits)) {
> LOG.warn("Null or non-existent edits file: " + edits);
> continue;
>   }
>   if (isZeroLengthThenDelete(this.fs, edits)) continue;
>   if (checkSafeToSkip) {
> Path higher = files.higher(edits);
> long maxSeqId = Long.MAX_VALUE;
> if (higher != null) {
>   // Edit file name pattern, HLog.EDITFILES_NAME_PATTERN: "-?[0-9]+"
>   String fileName = higher.getName();
>   maxSeqId = Math.abs(Long.parseLong(fileName));
> }
> if (maxSeqId <= minSeqId) {
>   String msg = "Maximum possible sequenceid for this log is " + 
> maxSeqId
>   + ", skipped the whole file, path=" + edits;
>   LOG.debug(msg);
>   continue;
> } else {
>   checkSafeToSkip = false;
> }
>   }
> {code}
>  

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

[jira] [Updated] (HBASE-4393) Implement a canary monitoring program

[Matteo Bertozzi (Updated) (JIRA)]

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

Matteo Bertozzi updated HBASE-4393:
---

Attachment: HBASE-4393-v0.patch

use LOG as default Sink, renamed methods as suggested and removed the 
BasicParser.

@Stack
What is your idea, about integrating hbck? some sort of automatic recovery in 
some codition?

> Implement a canary monitoring program
> -
>
> Key: HBASE-4393
> URL: https://issues.apache.org/jira/browse/HBASE-4393
> Project: HBase
>  Issue Type: New Feature
>  Components: monitoring
>Affects Versions: 0.92.0
>Reporter: Todd Lipcon
>Assignee: Matteo Bertozzi
> Attachments: Canary-v0.java, HBASE-4393-v0.patch, HBaseCanary.java
>
>
> This JIRA is to implement a standalone program that can be used to do "canary 
> monitoring" of a running HBase cluster. This program would gather a list of 
> the regions in the cluster, then iterate over them doing lightweight 
> operations (eg short scans) to provide metrics about latency as well as alert 
> on availability issues.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-5213) "hbase master stop" does not bring down backup masters

[Zhihong Yu (Updated) (JIRA)]

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

Zhihong Yu updated HBASE-5213:
--

Attachment: 5213.jstack

jstack for the hanging test.

> "hbase master stop" does not bring down backup masters
> --
>
> Key: HBASE-5213
> URL: https://issues.apache.org/jira/browse/HBASE-5213
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 0.90.5, 0.92.0, 0.94.0, 0.96.0
>Reporter: Gregory Chanan
>Assignee: Gregory Chanan
>Priority: Minor
> Fix For: 0.90.7, 0.92.2, 0.94.0, 0.96.0
>
> Attachments: 5213.jstack, HBASE-5213-v0-trunk.patch, 
> HBASE-5213-v1-trunk.patch, HBASE-5213-v2-90.patch, HBASE-5213-v2-92.patch, 
> HBASE-5213-v2-trunk.patch
>
>
> Typing "hbase master stop" produces the following message:
> "stop   Start cluster shutdown; Master signals RegionServer shutdown"
> It seems like backup masters should be considered part of the cluster, but 
> they are not brought down by "hbase master stop".
> "stop-hbase.sh" does correctly bring down the backup masters.
> The same behavior is observed when a client app makes use of the client API 
> HBaseAdmin.shutdown() 
> http://hbase.apache.org/apidocs/org/apache/hadoop/hbase/client/HBaseAdmin.html#shutdown()
>  -- this isn't too surprising since I think "hbase master stop" just calls 
> this API.
> It seems like HBASE-1448 address this; perhaps there was a regression?

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

[jira] [Commented] (HBASE-3909) Add dynamic config

[Subbu M Iyer (Commented) (JIRA)]

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

Subbu M Iyer commented on HBASE-3909:
-

@Uma:

5. getMaster().updateConfig is not deprecated. It is used by the Shell. 

7. If ZK is down or connectivity is lost we have much bigger problem then 
loosing a config update. 

8. Yes. I thought of creating two buckets of configuration elements. 1) 
Bootstrap config items which may not be changed after the cluster is up or have 
no effect changing them once cluster is up 2) Non bootstrap, truly runtime 
configurations which have immediate effect. My thought was to add these 
features if there is a consensus from the group.

9. Yes. But if a user is changing the configuration either in XML or dynamic he 
is better aware of the implications. no?

10. NodeDeleted is not required. We are not going to delete a configuration 
entry at runtime and even doing so may not have any effect now. In the future 
if we want to trigger some actions based on presence/absence of some 
configuration entries this might be added.

11. Yes, we can offer a Master/RS specific fine grained configuration controls 
if that is a real requirement. My thought is begin with some thing
very simple and add complexities as we see fit. So, one option is as we all 
know is to create separate subset of config nodes per Master/RS in the cluster 
and they subscribe to events specific to their own subset. But, if you look at 
our current configuration xml we make no clear distinction as to which 
properties belong to which runtime entity. Although we name them like 
config.key.master or config.key.region, I am not sure whether we can count on 
them to make a decision on whether a property applies to MAster only or RS only 
and so on.

12. My thought is InMemory Configuration holds the config items after creating 
a ZK node for the same as other wise it may not be altered. Basically we need 
to make sure that ZK config node exists for a config key before we keep it in 
memory. 

13. My thought is ideally we want Master to be the single point of source for 
all cluster wide config management/updates. We definitely don't want to 
directly manipulate a RS specific property. I mean we should not expose API's 
in RS to enable config key manipulations. Master should be the single point of 
source for all configuration entries irrespective of whether the config is 
cluster wide, master specific or RS specific and ZK should be the medium of 
communication across the cluster. So, master will be involved in all config 
updates is my take. 

Others please comment.

> Add dynamic config
> --
>
> Key: HBASE-3909
> URL: https://issues.apache.org/jira/browse/HBASE-3909
> Project: HBase
>  Issue Type: Bug
>Reporter: stack
> Fix For: 0.96.0
>
> Attachments: 3909-v1.patch, 3909.v1
>
>
> I'm sure this issue exists already, at least as part of the discussion around 
> making online schema edits possible, but no hard this having its own issue.  
> Ted started a conversation on this topic up on dev and Todd suggested we 
> lookd at how Hadoop did it over in HADOOP-7001

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

[jira] [Commented] (HBASE-5615) the master never does balance because of balancing the parent region

[Hudson (Commented) (JIRA)]

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

Hudson commented on HBASE-5615:
---

Integrated in HBase-0.92 #359 (See 
[https://builds.apache.org/job/HBase-0.92/359/])
HBASE-5615 revert due to race condition in case master dies (Revision 
1310321)

 Result = SUCCESS
tedyu : 
Files : 
* /hbase/branches/0.92/CHANGES.txt
* 
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/master/AssignmentManager.java


> the master never does balance because of balancing the parent region
> 
>
> Key: HBASE-5615
> URL: https://issues.apache.org/jira/browse/HBASE-5615
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 0.90.7
>Reporter: xufeng
>Assignee: xufeng
>Priority: Critical
> Fix For: 0.90.7, 0.92.2, 0.94.0, 0.96.0
>
> Attachments: 5615-trunk.txt, HBASE-5615-90.patch, HBASE-5615.patch, 
> NoPatched-surefire-report-5615-90.html, Patched_surefire-report-5615-90.html
>
>
> the master never do balance becauseof when master do rebuildUserRegions()，it 
> will add the parent region into  AssignmentManager#servers,
> if balancer let the parent region to move,the parent will in RIT forever.thus 
> balance will never be executed.

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

[jira] [Commented] (HBASE-5213) "hbase master stop" does not bring down backup masters

[Jonathan Hsieh (Commented) (JIRA)]

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

Jonathan Hsieh commented on HBASE-5213:
---

I'll revert the 0.90 version.  Sorry about this fellas.

> "hbase master stop" does not bring down backup masters
> --
>
> Key: HBASE-5213
> URL: https://issues.apache.org/jira/browse/HBASE-5213
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 0.90.5, 0.92.0, 0.94.0, 0.96.0
>Reporter: Gregory Chanan
>Assignee: Gregory Chanan
>Priority: Minor
> Fix For: 0.90.7, 0.92.2, 0.94.0, 0.96.0
>
> Attachments: 5213.jstack, HBASE-5213-v0-trunk.patch, 
> HBASE-5213-v1-trunk.patch, HBASE-5213-v2-90.patch, HBASE-5213-v2-92.patch, 
> HBASE-5213-v2-trunk.patch
>
>
> Typing "hbase master stop" produces the following message:
> "stop   Start cluster shutdown; Master signals RegionServer shutdown"
> It seems like backup masters should be considered part of the cluster, but 
> they are not brought down by "hbase master stop".
> "stop-hbase.sh" does correctly bring down the backup masters.
> The same behavior is observed when a client app makes use of the client API 
> HBaseAdmin.shutdown() 
> http://hbase.apache.org/apidocs/org/apache/hadoop/hbase/client/HBaseAdmin.html#shutdown()
>  -- this isn't too surprising since I think "hbase master stop" just calls 
> this API.
> It seems like HBASE-1448 address this; perhaps there was a regression?

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

[jira] [Commented] (HBASE-3909) Add dynamic config

[Zhihong Yu (Commented) (JIRA)]

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

Zhihong Yu commented on HBASE-3909:
---

For #11, we can create another JIRA for annotating the scope of each config 
parameter: whether it affects master or region server, or both.
This way master and region server wouldn't need to receive zk event whose 
underlying config update is irrelevant to itself.

> Add dynamic config
> --
>
> Key: HBASE-3909
> URL: https://issues.apache.org/jira/browse/HBASE-3909
> Project: HBase
>  Issue Type: Bug
>Reporter: stack
> Fix For: 0.96.0
>
> Attachments: 3909-v1.patch, 3909.v1
>
>
> I'm sure this issue exists already, at least as part of the discussion around 
> making online schema edits possible, but no hard this having its own issue.  
> Ted started a conversation on this topic up on dev and Todd suggested we 
> lookd at how Hadoop did it over in HADOOP-7001

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

[jira] [Commented] (HBASE-5739) Upgrade guava to 11.0.2

[Hadoop QA (Commented) (JIRA)]

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

Hadoop QA commented on HBASE-5739:
--

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

This message is automatically generated.

> Upgrade guava to 11.0.2
> ---
>
> Key: HBASE-5739
> URL: https://issues.apache.org/jira/browse/HBASE-5739
> Project: HBase
>  Issue Type: Improvement
>  Components: build
>Affects Versions: 0.96.0
>Reporter: Todd Lipcon
>Assignee: Todd Lipcon
> Fix For: 0.96.0
>
> Attachments: hbase-5739.txt
>
>
> Hadoop has upgraded to this new version of Guava. We should, too, so we don't 
> have compatibility issues running on Hadoop 2.0+

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

[jira] [Commented] (HBASE-5680) Improve compatibility warning about HBase with Hadoop 0.23.x

[Hudson (Commented) (JIRA)]

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

Hudson commented on HBASE-5680:
---

Integrated in HBase-TRUNK #2720 (See 
[https://builds.apache.org/job/HBase-TRUNK/2720/])
HBASE-5680 Improve compatibility warning about HBase with Hadoop 0.23.x 
(Revision 1310429)

 Result = SUCCESS
jmhsieh : 
Files : 
* /hbase/trunk/src/main/java/org/apache/hadoop/hbase/master/HMaster.java


> Improve compatibility warning about HBase with Hadoop 0.23.x
> 
>
> Key: HBASE-5680
> URL: https://issues.apache.org/jira/browse/HBASE-5680
> Project: HBase
>  Issue Type: Bug
>  Components: master
>Affects Versions: 0.90.6, 0.92.1, 0.94.0, 0.96.0
>Reporter: Kristam Subba Swathi
>Assignee: Jonathan Hsieh
> Fix For: 0.90.7, 0.92.2, 0.94.0, 0.96.0
>
> Attachments: hbase-5680-94.patch
>
>
> Hmaster is not able to start because of the following error
> Please find the following error 
> 
> 2012-03-30 11:12:19,487 FATAL org.apache.hadoop.hbase.master.HMaster: 
> Unhandled exception. Starting shutdown.
> java.lang.NoClassDefFoundError: 
> org/apache/hadoop/hdfs/protocol/FSConstants$SafeModeAction
>   at org.apache.hadoop.hbase.util.FSUtils.waitOnSafeMode(FSUtils.java:524)
>   at 
> org.apache.hadoop.hbase.master.MasterFileSystem.checkRootDir(MasterFileSystem.java:324)
>   at 
> org.apache.hadoop.hbase.master.MasterFileSystem.createInitialFileSystemLayout(MasterFileSystem.java:127)
>   at 
> org.apache.hadoop.hbase.master.MasterFileSystem.(MasterFileSystem.java:112)
>   at 
> org.apache.hadoop.hbase.master.HMaster.finishInitialization(HMaster.java:496)
>   at org.apache.hadoop.hbase.master.HMaster.run(HMaster.java:363)
>   at java.lang.Thread.run(Thread.java:662)
> Caused by: java.lang.ClassNotFoundException: 
> org.apache.hadoop.hdfs.protocol.FSConstants$SafeModeAction
>   at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
>   at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
>   ... 7 more
> There is a change in the FSConstants

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

[jira] [Commented] (HBASE-5599) The hbck tool can not fix the six scenarios, it is NO_VERSION_FILE, NOT_IN_META_OR_DEPLOYED, NOT_IN_META, SHOULD_NOT_BE_DEPLOYED, FIRST_REGION_STARTKEY_NOT_EMPTY, HOLE_

[Jonathan Hsieh (Commented) (JIRA)]

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

Jonathan Hsieh commented on HBASE-5599:
---

Can you share the test code?  Extra sets of eyes might help find the problem!

> The hbck tool can not fix the six scenarios, it is NO_VERSION_FILE, 
> NOT_IN_META_OR_DEPLOYED, NOT_IN_META, SHOULD_NOT_BE_DEPLOYED, 
> FIRST_REGION_STARTKEY_NOT_EMPTY, HOLE_IN_REGION_CHAIN.
> 
>
> Key: HBASE-5599
> URL: https://issues.apache.org/jira/browse/HBASE-5599
> Project: HBase
>  Issue Type: New Feature
>  Components: hbck
>Affects Versions: 0.90.6
>Reporter: fulin wang
>Assignee: fulin wang
> Fix For: 0.90.6
>
> Attachments: hbase-5599-0.90.patch, hbase-5599-0.90_v2.patch, 
> hbase-5599-0.90_v3.patch, hbase-5599-0.90_v5.patch, hbase-5599-0.90_v6.patch, 
> hbase-5599-0.92_v5.patch, hbase-5599-0.94_v5.patch, hbase-5599-trunk_v5.patch
>
>
> The hbck tool can not fix the six scenarios.
> 1. Version file does not exist in root dir.
>Fix: I try to create a version file by 'FSUtils.setVersion' method.
>
> 2. [REGIONNAME][KEY] on HDFS, but not listed in META or deployed on any 
> region server.
>Fix: I get region info form the hdfs file, this region info write to 
> '.META.' table.
>
> 3. [REGIONNAME][KEY] not in META, but deployed on [SERVERNAME]
>Fix: I get region info form the hdfs file, this region info write to 
> '.META.' table.
>
> 4. [REGIONNAME] should not be deployed according to META, but is deployed on 
> [SERVERNAME]
>Fix: Close this region.
>
> 5. First region should start with an empty key.  You need to  create a new 
> region and regioninfo in HDFS to plug the hole.
>Fix: The region info is not in hdfs and .META., so it create a empty 
> region for this error.
> 6. There is a hole in the region chain between [KEY] and [KEY]. You need to 
> create a new regioninfo and region dir in hdfs to plug the hole.
>   Fix: The region info is not in hdfs and .META., so it create a empty region 
> for this hole.
>   

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

[jira] [Commented] (HBASE-5680) Improve compatibility warning about HBase with Hadoop 0.23.x

[Hudson (Commented) (JIRA)]

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

Hudson commented on HBASE-5680:
---

Integrated in HBase-0.94 #93 (See 
[https://builds.apache.org/job/HBase-0.94/93/])
HBASE-5680 Improve compatibility warning about HBase with Hadoop 0.23.x 
(Revision 1310433)

 Result = SUCCESS
jmhsieh : 
Files : 
* /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/master/HMaster.java


> Improve compatibility warning about HBase with Hadoop 0.23.x
> 
>
> Key: HBASE-5680
> URL: https://issues.apache.org/jira/browse/HBASE-5680
> Project: HBase
>  Issue Type: Bug
>  Components: master
>Affects Versions: 0.90.6, 0.92.1, 0.94.0, 0.96.0
>Reporter: Kristam Subba Swathi
>Assignee: Jonathan Hsieh
> Fix For: 0.90.7, 0.92.2, 0.94.0, 0.96.0
>
> Attachments: hbase-5680-94.patch
>
>
> Hmaster is not able to start because of the following error
> Please find the following error 
> 
> 2012-03-30 11:12:19,487 FATAL org.apache.hadoop.hbase.master.HMaster: 
> Unhandled exception. Starting shutdown.
> java.lang.NoClassDefFoundError: 
> org/apache/hadoop/hdfs/protocol/FSConstants$SafeModeAction
>   at org.apache.hadoop.hbase.util.FSUtils.waitOnSafeMode(FSUtils.java:524)
>   at 
> org.apache.hadoop.hbase.master.MasterFileSystem.checkRootDir(MasterFileSystem.java:324)
>   at 
> org.apache.hadoop.hbase.master.MasterFileSystem.createInitialFileSystemLayout(MasterFileSystem.java:127)
>   at 
> org.apache.hadoop.hbase.master.MasterFileSystem.(MasterFileSystem.java:112)
>   at 
> org.apache.hadoop.hbase.master.HMaster.finishInitialization(HMaster.java:496)
>   at org.apache.hadoop.hbase.master.HMaster.run(HMaster.java:363)
>   at java.lang.Thread.run(Thread.java:662)
> Caused by: java.lang.ClassNotFoundException: 
> org.apache.hadoop.hdfs.protocol.FSConstants$SafeModeAction
>   at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
>   at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
>   ... 7 more
> There is a change in the FSConstants

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

[jira] [Commented] (HBASE-3909) Add dynamic config

[Uma Maheswara Rao G (Commented) (JIRA)]

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

Uma Maheswara Rao G commented on HBASE-3909:


{quote}
5. getMaster().updateConfig is not deprecated. It is used by the Shell.
{quote}
{code}
 @Deprecated
  public HMasterInterface getMaster()
But, I am not sure for wnat reason, this API has been deprecated.
{code}

{quote}
7. If ZK is down or connectivity is lost we have much bigger problem then 
loosing a config update
{quote}
for example, i am referring HBASE-5635 kind of issues. 


I think your 11th point mostly answering my 13th question. My 11th point was 
something defferent. Since you want to make the initial patch simple, let's 
discuss that later or separate task.


{quote}
13. My thought is ideally we want Master to be the single point of source for 
all cluster wide config management/updates. We definitely don't want to 
directly manipulate a RS specific property. I mean we should not expose API's 
in RS to enable config key manipulations. Master should be the single point of 
source for all configuration entries irrespective of whether the config is 
cluster wide, master specific or RS specific and ZK should be the medium of 
communication across the cluster. So, master will be involved in all config 
updates is my take. 
{quote}

I am not talking about the configuration updation from defferent nodes. I am 
talking about some config item updations which may not be really required for 
all the nodes. ( like some configurations items will be used only by master and 
some items will be used only by RS). Anyway as you said, we can take this point 
as next task I feel.

> Add dynamic config
> --
>
> Key: HBASE-3909
> URL: https://issues.apache.org/jira/browse/HBASE-3909
> Project: HBase
>  Issue Type: Bug
>Reporter: stack
> Fix For: 0.96.0
>
> Attachments: 3909-v1.patch, 3909.v1
>
>
> I'm sure this issue exists already, at least as part of the discussion around 
> making online schema edits possible, but no hard this having its own issue.  
> Ted started a conversation on this topic up on dev and Todd suggested we 
> lookd at how Hadoop did it over in HADOOP-7001

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-5635) If getTaskList() returns null splitlogWorker is down. It wont serve any requests.

[Zhihong Yu (Updated) (JIRA)]

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

Zhihong Yu updated HBASE-5635:
--

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

> If getTaskList() returns null splitlogWorker is down. It wont serve any 
> requests. 
> --
>
> Key: HBASE-5635
> URL: https://issues.apache.org/jira/browse/HBASE-5635
> Project: HBase
>  Issue Type: Bug
>  Components: wal
>Affects Versions: 0.92.1
>Reporter: Kristam Subba Swathi
> Attachments: HBASE-5635.1.patch, HBASE-5635.2.patch, HBASE-5635.patch
>
>
> During the hlog split operation if all the zookeepers are down ,then the 
> paths will be returned as null and the splitworker thread wil be exited
> Now this regionserver wil not be able to acquire any other tasks since the 
> splitworker thread is exited
> Please find the attached code for more details
> {code}
> private List getTaskList() {
> for (int i = 0; i < zkretries; i++) {
>   try {
> return (ZKUtil.listChildrenAndWatchForNewChildren(this.watcher,
> this.watcher.splitLogZNode));
>   } catch (KeeperException e) {
> LOG.warn("Could not get children of znode " +
> this.watcher.splitLogZNode, e);
> try {
>   Thread.sleep(1000);
> } catch (InterruptedException e1) {
>   LOG.warn("Interrupted while trying to get task list ...", e1);
>   Thread.currentThread().interrupt();
>   return null;
> }
>   }
> }
> {code}
> in the org.apache.hadoop.hbase.regionserver.SplitLogWorker 
>  

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

[jira] [Commented] (HBASE-4393) Implement a canary monitoring program

[Hadoop QA (Commented) (JIRA)]

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

Hadoop QA commented on HBASE-4393:
--

-1 overall.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12521688/HBASE-4393-v0.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 javadoc.  The javadoc tool did not generate any warning messages.

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

-1 findbugs.  The patch appears to introduce 4 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/1430//testReport/
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/1430//artifact/trunk/patchprocess/newPatchFindbugsWarnings.html
Console output: 
https://builds.apache.org/job/PreCommit-HBASE-Build/1430//console

This message is automatically generated.

> Implement a canary monitoring program
> -
>
> Key: HBASE-4393
> URL: https://issues.apache.org/jira/browse/HBASE-4393
> Project: HBase
>  Issue Type: New Feature
>  Components: monitoring
>Affects Versions: 0.92.0
>Reporter: Todd Lipcon
>Assignee: Matteo Bertozzi
> Attachments: Canary-v0.java, HBASE-4393-v0.patch, HBaseCanary.java
>
>
> This JIRA is to implement a standalone program that can be used to do "canary 
> monitoring" of a running HBase cluster. This program would gather a list of 
> the regions in the cluster, then iterate over them doing lightweight 
> operations (eg short scans) to provide metrics about latency as well as alert 
> on availability issues.

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

[jira] [Commented] (HBASE-5734) Change hbck sideline root

[Jimmy Xiang (Commented) (JIRA)]

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

Jimmy Xiang commented on HBASE-5734:


It is nice to expose it as an argument. However, it offers not too much value 
since we don't expect hbck to be ran all the time. They can rename it 
afterwards if they really want.

We already have lots of arguments.


> Change hbck sideline root
> -
>
> Key: HBASE-5734
> URL: https://issues.apache.org/jira/browse/HBASE-5734
> Project: HBase
>  Issue Type: Improvement
>  Components: hbck
>Affects Versions: 0.94.0, 0.96.0
>Reporter: Jimmy Xiang
>Assignee: Jimmy Xiang
>Priority: Trivial
> Fix For: 0.96.0
>
> Attachments: hbase-5734.patch
>
>
> Currently hbck sideline root is the root which can run into permission issue. 
> We can change it to /hbck

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

[jira] [Commented] (HBASE-5615) the master never does balance because of balancing the parent region

[Lars Hofhansl (Commented) (JIRA)]

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

Lars Hofhansl commented on HBASE-5615:
--

Thanks for the explanation Ram!
Now, do you think this is even a problem in 0.92+, or can we close this issue?

> the master never does balance because of balancing the parent region
> 
>
> Key: HBASE-5615
> URL: https://issues.apache.org/jira/browse/HBASE-5615
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 0.90.7
>Reporter: xufeng
>Assignee: xufeng
>Priority: Critical
> Fix For: 0.90.7, 0.92.2, 0.94.0, 0.96.0
>
> Attachments: 5615-trunk.txt, HBASE-5615-90.patch, HBASE-5615.patch, 
> NoPatched-surefire-report-5615-90.html, Patched_surefire-report-5615-90.html
>
>
> the master never do balance becauseof when master do rebuildUserRegions()，it 
> will add the parent region into  AssignmentManager#servers,
> if balancer let the parent region to move,the parent will in RIT forever.thus 
> balance will never be executed.

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

[jira] [Commented] (HBASE-5735) Clearer warning message when connecting a non-secure HBase client to a secure HBase server

[Jonathan Hsieh (Commented) (JIRA)]

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

Jonathan Hsieh commented on HBASE-5735:
---

nit: Should we still include the server version as well?

> Clearer warning message when connecting a non-secure HBase client to a secure 
> HBase server
> --
>
> Key: HBASE-5735
> URL: https://issues.apache.org/jira/browse/HBASE-5735
> Project: HBase
>  Issue Type: Improvement
>  Components: security
>Affects Versions: 0.92.1, 0.94.0
>Reporter: Shaneal Manek
>Priority: Trivial
> Attachments: HBASE-5375-v2.patch, HBASE-5375.patch
>
>
> When a connection from a non secure-rpc-engine
> client is attempted the warning message you get is related to version
> mismatch:
> Mar 28, 3:27:13 PM WARN org.apache.hadoop.ipc.SecureServer Incorrect
> header or version mismatch from 172.29.82.121:43849 got version 3
> expected version 4
> While this is true, it isn't as useful as it could be. A more specific error 
> message warning end users that they're connecting with a non-secure client 
> may be more useful.

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

[jira] [Commented] (HBASE-5720) HFileDataBlockEncoderImpl uses wrong header size when reading HFiles with no checksums

[Lars Hofhansl (Commented) (JIRA)]

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

Lars Hofhansl commented on HBASE-5720:
--

v4 does not compile:
{quote}
[ERROR] 
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/trunk/src/main/java/org/apache/hadoop/hbase/io/hfile/HFileDataBlockEncoderImpl.java:[74,39]
 cannot find symbol
[ERROR] symbol  : variable block
[ERROR] location: class 
org.apache.hadoop.hbase.io.hfile.HFileDataBlockEncoderImpl
{quote}

The "block" indeed is not known to HFileDataBlockEncoderImpl. I'm lacking a bit 
context to suggest a different fix.


> HFileDataBlockEncoderImpl uses wrong header size when reading HFiles with no 
> checksums
> --
>
> Key: HBASE-5720
> URL: https://issues.apache.org/jira/browse/HBASE-5720
> Project: HBase
>  Issue Type: Bug
>  Components: io, regionserver
>Affects Versions: 0.94.0
>Reporter: Matt Corgan
>Priority: Blocker
> Fix For: 0.94.0
>
> Attachments: 5720v4.txt, 5720v4.txt, 5720v4.txt, HBASE-5720-v1.patch, 
> HBASE-5720-v2.patch, HBASE-5720-v3.patch
>
>
> When reading a .92 HFile without checksums, encoding it, and storing in the 
> block cache, the HFileDataBlockEncoderImpl always allocates a dummy header 
> appropriate for checksums even though there are none.  This corrupts the 
> byte[].
> Attaching a patch that allocates a DUMMY_HEADER_NO_CHECKSUM in that case 
> which I think is the desired behavior.

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

[jira] [Commented] (HBASE-5635) If getTaskList() returns null splitlogWorker is down. It wont serve any requests.

[Hadoop QA (Commented) (JIRA)]

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

Hadoop QA commented on HBASE-5635:
--

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

This message is automatically generated.

> If getTaskList() returns null splitlogWorker is down. It wont serve any 
> requests. 
> --
>
> Key: HBASE-5635
> URL: https://issues.apache.org/jira/browse/HBASE-5635
> Project: HBase
>  Issue Type: Bug
>  Components: wal
>Affects Versions: 0.92.1
>Reporter: Kristam Subba Swathi
> Attachments: HBASE-5635.1.patch, HBASE-5635.2.patch, HBASE-5635.patch
>
>
> During the hlog split operation if all the zookeepers are down ,then the 
> paths will be returned as null and the splitworker thread wil be exited
> Now this regionserver wil not be able to acquire any other tasks since the 
> splitworker thread is exited
> Please find the attached code for more details
> {code}
> private List getTaskList() {
> for (int i = 0; i < zkretries; i++) {
>   try {
> return (ZKUtil.listChildrenAndWatchForNewChildren(this.watcher,
> this.watcher.splitLogZNode));
>   } catch (KeeperException e) {
> LOG.warn("Could not get children of znode " +
> this.watcher.splitLogZNode, e);
> try {
>   Thread.sleep(1000);
> } catch (InterruptedException e1) {
>   LOG.warn("Interrupted while trying to get task list ...", e1);
>   Thread.currentThread().interrupt();
>   return null;
> }
>   }
> }
> {code}
> in the org.apache.hadoop.hbase.regionserver.SplitLogWorker 
>  

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

[jira] [Commented] (HBASE-5736) ThriftServerRunner.HbaseHandler.mutateRow() does not use ByteBuffer correctly

[Scott Chen (Commented) (JIRA)]

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

Scott Chen commented on HBASE-5736:
---

Failed test seems related. I will take a look.

> ThriftServerRunner.HbaseHandler.mutateRow() does not use ByteBuffer correctly
> -
>
> Key: HBASE-5736
> URL: https://issues.apache.org/jira/browse/HBASE-5736
> Project: HBase
>  Issue Type: Bug
>Reporter: Scott Chen
>Assignee: Scott Chen
> Attachments: HBASE-5736.D2649.1.patch, HBASE-5736.D2649.2.patch
>
>
> We have fixed similar bug in
> https://issues.apache.org/jira/browse/HBASE-5507
> It uses ByteBuffer.array() to read the ByteBuffer.
> This will ignore the offset return the whole underlying byte array.
> The bug can be triggered by using framed Transport thrift servers.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-4393) Implement a canary monitoring program

[Matteo Bertozzi (Updated) (JIRA)]

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

Matteo Bertozzi updated HBASE-4393:
---

Attachment: (was: HBASE-4393-v0.patch)

> Implement a canary monitoring program
> -
>
> Key: HBASE-4393
> URL: https://issues.apache.org/jira/browse/HBASE-4393
> Project: HBase
>  Issue Type: New Feature
>  Components: monitoring
>Affects Versions: 0.92.0
>Reporter: Todd Lipcon
>Assignee: Matteo Bertozzi
> Attachments: Canary-v0.java, HBASE-4393-v0.patch, HBaseCanary.java
>
>
> This JIRA is to implement a standalone program that can be used to do "canary 
> monitoring" of a running HBase cluster. This program would gather a list of 
> the regions in the cluster, then iterate over them doing lightweight 
> operations (eg short scans) to provide metrics about latency as well as alert 
> on availability issues.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-4393) Implement a canary monitoring program

[Matteo Bertozzi (Updated) (JIRA)]

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

Matteo Bertozzi updated HBASE-4393:
---

Attachment: HBASE-4393-v0.patch

> Implement a canary monitoring program
> -
>
> Key: HBASE-4393
> URL: https://issues.apache.org/jira/browse/HBASE-4393
> Project: HBase
>  Issue Type: New Feature
>  Components: monitoring
>Affects Versions: 0.92.0
>Reporter: Todd Lipcon
>Assignee: Matteo Bertozzi
> Attachments: Canary-v0.java, HBASE-4393-v0.patch, HBaseCanary.java
>
>
> This JIRA is to implement a standalone program that can be used to do "canary 
> monitoring" of a running HBase cluster. This program would gather a list of 
> the regions in the cluster, then iterate over them doing lightweight 
> operations (eg short scans) to provide metrics about latency as well as alert 
> on availability issues.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-5736) ThriftServerRunner.HbaseHandler.mutateRow() does not use ByteBuffer correctly

[Phabricator (Updated) (JIRA)]

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

Phabricator updated HBASE-5736:
---

Attachment: HBASE-5736.D2649.3.patch

sc updated the revision "HBASE-5736 [jira] 
ThriftServerRunner.HbaseHandler.mutateRow() does not use ByteBuffer correctly".
Reviewers: tedyu, dhruba, JIRA

  Increase test timeout because more tests are added.

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

AFFECTED FILES
  src/main/java/org/apache/hadoop/hbase/thrift/ThriftServerRunner.java
  src/test/java/org/apache/hadoop/hbase/thrift/TestThriftServer.java
  src/test/java/org/apache/hadoop/hbase/thrift/TestThriftServerCmdLine.java


> ThriftServerRunner.HbaseHandler.mutateRow() does not use ByteBuffer correctly
> -
>
> Key: HBASE-5736
> URL: https://issues.apache.org/jira/browse/HBASE-5736
> Project: HBase
>  Issue Type: Bug
>Reporter: Scott Chen
>Assignee: Scott Chen
> Attachments: HBASE-5736.D2649.1.patch, HBASE-5736.D2649.2.patch, 
> HBASE-5736.D2649.3.patch
>
>
> We have fixed similar bug in
> https://issues.apache.org/jira/browse/HBASE-5507
> It uses ByteBuffer.array() to read the ByteBuffer.
> This will ignore the offset return the whole underlying byte array.
> The bug can be triggered by using framed Transport thrift servers.

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

[jira] [Commented] (HBASE-5736) ThriftServerRunner.HbaseHandler.mutateRow() does not use ByteBuffer correctly

[Scott Chen (Commented) (JIRA)]

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

Scott Chen commented on HBASE-5736:
---

The test got timeout. It makes sense because I am adding more steps to the test.
Increasing the timeout should fix this.

> ThriftServerRunner.HbaseHandler.mutateRow() does not use ByteBuffer correctly
> -
>
> Key: HBASE-5736
> URL: https://issues.apache.org/jira/browse/HBASE-5736
> Project: HBase
>  Issue Type: Bug
>Reporter: Scott Chen
>Assignee: Scott Chen
> Attachments: HBASE-5736.D2649.1.patch, HBASE-5736.D2649.2.patch, 
> HBASE-5736.D2649.3.patch
>
>
> We have fixed similar bug in
> https://issues.apache.org/jira/browse/HBASE-5507
> It uses ByteBuffer.array() to read the ByteBuffer.
> This will ignore the offset return the whole underlying byte array.
> The bug can be triggered by using framed Transport thrift servers.

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

[jira] [Commented] (HBASE-5719) Enhance hbck to sideline overlapped mega regions

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

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

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


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

(Updated 2012-04-06 18:27:34.615205)


Review request for hbase and jmhsieh.


Changes
---

Addressed Jon's comments.


Summary
---

Make it configurable to sideline some regions in big overlapped groups which 
hbck doesn't handle currently.

The regions chose to sideline are those which overlap with most other regions.


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


Diffs (updated)
-

  src/main/java/org/apache/hadoop/hbase/util/HBaseFsck.java 54f9b21 
  src/main/java/org/apache/hadoop/hbase/util/RegionSplitCalculator.java 17678dd 
  src/test/java/org/apache/hadoop/hbase/util/TestRegionSplitCalculator.java 
ac3b225 

Diff: https://reviews.apache.org/r/4649/diff


Testing
---

mvn -PlocalTests -Dtest=TestHBaseFsck* clean test

Also tested in real system to fix inconsistencies.


Thanks,

Jimmy



> Enhance hbck to sideline overlapped mega regions
> 
>
> Key: HBASE-5719
> URL: https://issues.apache.org/jira/browse/HBASE-5719
> Project: HBase
>  Issue Type: New Feature
>  Components: hbck
>Affects Versions: 0.94.0, 0.96.0
>Reporter: Jimmy Xiang
>Assignee: Jimmy Xiang
> Fix For: 0.96.0
>
> Attachments: hbase-5719.patch
>
>
> If there are too many regions in one overlapped group (by default, more than 
> 10), hbck currently doesn't merge them since it takes time.
> In this case, we can sideline some regions in the group and break the 
> overlapping to fix the inconsistency.  Later on, sidelined regions can be 
> bulk loaded manually.

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

[jira] [Commented] (HBASE-5680) Improve compatibility warning about HBase with Hadoop 0.23.x

[Hudson (Commented) (JIRA)]

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

Hudson commented on HBASE-5680:
---

Integrated in HBase-0.92 #360 (See 
[https://builds.apache.org/job/HBase-0.92/360/])
HBASE-5680 Improve compatibility warning about HBase with Hadoop 0.23.x 
(Revision 1310434)

 Result = SUCCESS
jmhsieh : 
Files : 
* /hbase/branches/0.92/CHANGES.txt
* /hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/master/HMaster.java


> Improve compatibility warning about HBase with Hadoop 0.23.x
> 
>
> Key: HBASE-5680
> URL: https://issues.apache.org/jira/browse/HBASE-5680
> Project: HBase
>  Issue Type: Bug
>  Components: master
>Affects Versions: 0.90.6, 0.92.1, 0.94.0, 0.96.0
>Reporter: Kristam Subba Swathi
>Assignee: Jonathan Hsieh
> Fix For: 0.90.7, 0.92.2, 0.94.0, 0.96.0
>
> Attachments: hbase-5680-94.patch
>
>
> Hmaster is not able to start because of the following error
> Please find the following error 
> 
> 2012-03-30 11:12:19,487 FATAL org.apache.hadoop.hbase.master.HMaster: 
> Unhandled exception. Starting shutdown.
> java.lang.NoClassDefFoundError: 
> org/apache/hadoop/hdfs/protocol/FSConstants$SafeModeAction
>   at org.apache.hadoop.hbase.util.FSUtils.waitOnSafeMode(FSUtils.java:524)
>   at 
> org.apache.hadoop.hbase.master.MasterFileSystem.checkRootDir(MasterFileSystem.java:324)
>   at 
> org.apache.hadoop.hbase.master.MasterFileSystem.createInitialFileSystemLayout(MasterFileSystem.java:127)
>   at 
> org.apache.hadoop.hbase.master.MasterFileSystem.(MasterFileSystem.java:112)
>   at 
> org.apache.hadoop.hbase.master.HMaster.finishInitialization(HMaster.java:496)
>   at org.apache.hadoop.hbase.master.HMaster.run(HMaster.java:363)
>   at java.lang.Thread.run(Thread.java:662)
> Caused by: java.lang.ClassNotFoundException: 
> org.apache.hadoop.hdfs.protocol.FSConstants$SafeModeAction
>   at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
>   at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
>   ... 7 more
> There is a change in the FSConstants

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-5666) RegionServer doesn't retry to check if base node is available

[Matteo Bertozzi (Updated) (JIRA)]

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

Matteo Bertozzi updated HBASE-5666:
---

Attachment: HBASE-5666-v6.patch

> RegionServer doesn't retry to check if base node is available
> -
>
> Key: HBASE-5666
> URL: https://issues.apache.org/jira/browse/HBASE-5666
> Project: HBase
>  Issue Type: Bug
>  Components: regionserver, zookeeper
>Reporter: Matteo Bertozzi
>Assignee: Matteo Bertozzi
> Attachments: HBASE-5666-v1.patch, HBASE-5666-v2.patch, 
> HBASE-5666-v3.patch, HBASE-5666-v4.patch, HBASE-5666-v5.patch, 
> HBASE-5666-v6.patch, hbase-1-regionserver.log, hbase-2-regionserver.log, 
> hbase-3-regionserver.log, hbase-master.log, hbase-regionserver.log, 
> hbase-zookeeper.log
>
>
> I've a script that starts hbase and a couple of region servers in distributed 
> mode (hbase.cluster.distributed = true)
> {code}
> $HBASE_HOME/bin/start-hbase.sh
> $HBASE_HOME/bin/local-regionservers.sh start 1 2 3
> {code}
> but the region servers are not able to start...
> It seems that during the RS start the the znode is still not available, and 
> HRegionServer.initializeZooKeeper() check just once if the base not is 
> available.
> {code}
> 2012-03-28 21:54:05,013 INFO 
> org.apache.hadoop.hbase.regionserver.HRegionServer: STOPPED: Check the value 
> configured in 'zookeeper.znode.parent'. There could be a mismatch with the 
> one configured in the master.
> 2012-03-28 21:54:08,598 FATAL 
> org.apache.hadoop.hbase.regionserver.HRegionServer: ABORTING region server 
> localhost,60202,133296824: Initialization of RS failed.  Hence aborting 
> RS.
> java.io.IOException: Received the shutdown message while waiting.
>   at 
> org.apache.hadoop.hbase.regionserver.HRegionServer.blockAndCheckIfStopped(HRegionServer.java:626)
>   at 
> org.apache.hadoop.hbase.regionserver.HRegionServer.initializeZooKeeper(HRegionServer.java:596)
>   at 
> org.apache.hadoop.hbase.regionserver.HRegionServer.preRegistrationInitialization(HRegionServer.java:558)
>   at 
> org.apache.hadoop.hbase.regionserver.HRegionServer.run(HRegionServer.java:672)
>   at java.lang.Thread.run(Thread.java:662)
> {code}

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

[jira] [Commented] (HBASE-5736) ThriftServerRunner.HbaseHandler.mutateRow() does not use ByteBuffer correctly

[Hadoop QA (Commented) (JIRA)]

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

Hadoop QA commented on HBASE-5736:
--

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

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

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

+1 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.io.hfile.TestForceCacheImportantBlocks

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

This message is automatically generated.

> ThriftServerRunner.HbaseHandler.mutateRow() does not use ByteBuffer correctly
> -
>
> Key: HBASE-5736
> URL: https://issues.apache.org/jira/browse/HBASE-5736
> Project: HBase
>  Issue Type: Bug
>Reporter: Scott Chen
>Assignee: Scott Chen
> Attachments: HBASE-5736.D2649.1.patch, HBASE-5736.D2649.2.patch, 
> HBASE-5736.D2649.3.patch
>
>
> We have fixed similar bug in
> https://issues.apache.org/jira/browse/HBASE-5507
> It uses ByteBuffer.array() to read the ByteBuffer.
> This will ignore the offset return the whole underlying byte array.
> The bug can be triggered by using framed Transport thrift servers.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-5709) Move active master and backup master znodes to use pbs

[stack (Updated) (JIRA)]

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

stack updated HBASE-5709:
-

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

Committed to trunk.  Thanks for review Jimmy.

> Move active master and backup master znodes to use pbs
> --
>
> Key: HBASE-5709
> URL: https://issues.apache.org/jira/browse/HBASE-5709
> Project: HBase
>  Issue Type: Task
>Reporter: stack
>Assignee: stack
> Fix For: 0.96.0
>
> Attachments: 5709.txt, 5709v2.txt, 5709v3.txt
>
>


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

[jira] [Commented] (HBASE-5730) [89-fb] Make HRegionThriftServer's thread pool bounded

[Phabricator (Commented) (JIRA)]

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

Phabricator commented on HBASE-5730:


alevchuk has commented on the revision "[jira] [HBASE-5730] [89-fb] Make 
HRegionThriftServer's thread pool bounded".

  When the thread count exceeds the limit, is the a counter that gets bumped 
every time a new thread is prevented from spawning?

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

BRANCH
  make_hregionthriftserver_s_thread_pool_HBASE-5730


> [89-fb] Make HRegionThriftServer's thread pool bounded
> --
>
> Key: HBASE-5730
> URL: https://issues.apache.org/jira/browse/HBASE-5730
> Project: HBase
>  Issue Type: Bug
>Reporter: Mikhail Bautin
>Assignee: Mikhail Bautin
>
> This JIRA is for a quick fix in 89-fb to reuse TBoundedThreadPoolServer in 
> HRegionThriftServer. We will address whatever problems HRegionThriftServer 
> still has in trunk in HBASE-5703.

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

[jira] [Commented] (HBASE-5730) [89-fb] Make HRegionThriftServer's thread pool bounded

[Phabricator (Commented) (JIRA)]

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

Phabricator commented on HBASE-5730:


mbautin has commented on the revision "[jira] [HBASE-5730] [89-fb] Make 
HRegionThriftServer's thread pool bounded".

  No, we do not have such a counter at the moment. I will try to address that 
when porting Thrift server metrics to 89-fb.

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

BRANCH
  make_hregionthriftserver_s_thread_pool_HBASE-5730


> [89-fb] Make HRegionThriftServer's thread pool bounded
> --
>
> Key: HBASE-5730
> URL: https://issues.apache.org/jira/browse/HBASE-5730
> Project: HBase
>  Issue Type: Bug
>Reporter: Mikhail Bautin
>Assignee: Mikhail Bautin
>
> This JIRA is for a quick fix in 89-fb to reuse TBoundedThreadPoolServer in 
> HRegionThriftServer. We will address whatever problems HRegionThriftServer 
> still has in trunk in HBASE-5703.

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

[jira] [Commented] (HBASE-5707) Move clusterid and clusterup (shutdown) znodes over to pb

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

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

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


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


Looks good to me. I prefer to call it startDate instead of startdate.  It is up 
to you.

- Jimmy


On 2012-04-03 21:04:54, Michael Stack wrote:
bq.  
bq.  ---
bq.  This is an automatically generated e-mail. To reply, visit:
bq.  https://reviews.apache.org/r/4627/
bq.  ---
bq.  
bq.  (Updated 2012-04-03 21:04:54)
bq.  
bq.  
bq.  Review request for hbase.
bq.  
bq.  
bq.  Summary
bq.  ---
bq.  
bq.  Move two more znodes to serialize their content as pb.
bq.  
bq.  Here are the changes:
bq.  
bq.  {code}
bq.  M src/main/java/org/apache/hadoop/hbase/client/HConnectionManager.java
bq.Get the clusterid via utility in the ClusterId class rather than
bq.get it directly.
bq.  M src/main/java/org/apache/hadoop/hbase/zookeeper/ClusterId.java
bq.  M src/main/java/org/apache/hadoop/hbase/zookeeper/ClusterStatusTracker.java
bq.Serialize and deserialize using new ClusterId pb message.
bq.Include the PBUF preamble on znode content.
bq.  M src/main/java/org/apache/hadoop/hbase/zookeeper/RootRegionTracker.java
bq.Rename getRootRegionZNodeContent to getZNodeData so it aligns in name
bq.with the other cases where we compose the znode content up in ClusterId
bq.and in ClusterStatusTracker.
bq.  M src/main/protobuf/ZooKeeper.proto
bq.Add new messages for ClusterId and ClusterUp
bq.  {code}
bq.  
bq.  
bq.  This addresses bug hbase-5707.
bq.  https://issues.apache.org/jira/browse/hbase-5707
bq.  
bq.  
bq.  Diffs
bq.  -
bq.  
bq.src/main/java/org/apache/hadoop/hbase/client/HConnectionManager.java 
aa30969 
bq.
src/main/java/org/apache/hadoop/hbase/protobuf/generated/ZooKeeperProtos.java 
8ff87fe 
bq.src/main/java/org/apache/hadoop/hbase/zookeeper/ClusterId.java 3fa83e6 
bq.
src/main/java/org/apache/hadoop/hbase/zookeeper/ClusterStatusTracker.java 
61e7367 
bq.src/main/java/org/apache/hadoop/hbase/zookeeper/RootRegionTracker.java 
6b2ea57 
bq.src/main/protobuf/ZooKeeper.proto 20f8eb0 
bq.  
bq.  Diff: https://reviews.apache.org/r/4627/diff
bq.  
bq.  
bq.  Testing
bq.  ---
bq.  
bq.  
bq.  Thanks,
bq.  
bq.  Michael
bq.  
bq.



> Move clusterid and clusterup (shutdown) znodes over to pb
> -
>
> Key: HBASE-5707
> URL: https://issues.apache.org/jira/browse/HBASE-5707
> Project: HBase
>  Issue Type: Task
>Reporter: stack
> Attachments: 5707.txt
>
>


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

[jira] [Commented] (HBASE-5720) HFileDataBlockEncoderImpl uses wrong header size when reading HFiles with no checksums

[Matt Corgan (Commented) (JIRA)]

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

Matt Corgan commented on HBASE-5720:


Looks like HBASE-5313 shuffles things around by adding the 
HFileBlockDefaultEncodingContext

> HFileDataBlockEncoderImpl uses wrong header size when reading HFiles with no 
> checksums
> --
>
> Key: HBASE-5720
> URL: https://issues.apache.org/jira/browse/HBASE-5720
> Project: HBase
>  Issue Type: Bug
>  Components: io, regionserver
>Affects Versions: 0.94.0
>Reporter: Matt Corgan
>Priority: Blocker
> Fix For: 0.94.0
>
> Attachments: 5720v4.txt, 5720v4.txt, 5720v4.txt, HBASE-5720-v1.patch, 
> HBASE-5720-v2.patch, HBASE-5720-v3.patch
>
>
> When reading a .92 HFile without checksums, encoding it, and storing in the 
> block cache, the HFileDataBlockEncoderImpl always allocates a dummy header 
> appropriate for checksums even though there are none.  This corrupts the 
> byte[].
> Attaching a patch that allocates a DUMMY_HEADER_NO_CHECKSUM in that case 
> which I think is the desired behavior.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-5740) Compaction interruption may be due to balacing

[Jimmy Xiang (Created) (JIRA)]

Compaction interruption may be due to balacing
--

 Key: HBASE-5740
 URL: https://issues.apache.org/jira/browse/HBASE-5740
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.96.0
Reporter: Jimmy Xiang
Assignee: Jimmy Xiang
Priority: Trivial
 Fix For: 0.96.0
 Attachments: hbase-5740.patch

Currently, the log shows 

Aborting compaction of store LOG in region CCS_ACCOUNT_LOG_HBASE02_01,scm01 
IDNWNoA0002765 00061395804,1328855408473.8b68adefea8dbc8c77a97ce88cf657a6. 
because user requested stop.

But it is actually because of balancing.

Currently, there is no way to figure out who closed the region.  So it is 
better to change the message to say it is because of user, or balancing.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-5740) Compaction interruption may be due to balacing

[Jimmy Xiang (Updated) (JIRA)]

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

Jimmy Xiang updated HBASE-5740:
---

Attachment: hbase-5740.patch

> Compaction interruption may be due to balacing
> --
>
> Key: HBASE-5740
> URL: https://issues.apache.org/jira/browse/HBASE-5740
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 0.96.0
>Reporter: Jimmy Xiang
>Assignee: Jimmy Xiang
>Priority: Trivial
> Fix For: 0.96.0
>
> Attachments: hbase-5740.patch
>
>
> Currently, the log shows 
> Aborting compaction of store LOG in region CCS_ACCOUNT_LOG_HBASE02_01,scm01 
> IDNWNoA0002765 00061395804,1328855408473.8b68adefea8dbc8c77a97ce88cf657a6. 
> because user requested stop.
> But it is actually because of balancing.
> Currently, there is no way to figure out who closed the region.  So it is 
> better to change the message to say it is because of user, or balancing.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-5740) Compaction interruption may be due to balacing

[Jimmy Xiang (Updated) (JIRA)]

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

Jimmy Xiang updated HBASE-5740:
---

Status: Patch Available  (was: Open)

> Compaction interruption may be due to balacing
> --
>
> Key: HBASE-5740
> URL: https://issues.apache.org/jira/browse/HBASE-5740
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 0.96.0
>Reporter: Jimmy Xiang
>Assignee: Jimmy Xiang
>Priority: Trivial
> Fix For: 0.96.0
>
> Attachments: hbase-5740.patch
>
>
> Currently, the log shows 
> Aborting compaction of store LOG in region CCS_ACCOUNT_LOG_HBASE02_01,scm01 
> IDNWNoA0002765 00061395804,1328855408473.8b68adefea8dbc8c77a97ce88cf657a6. 
> because user requested stop.
> But it is actually because of balancing.
> Currently, there is no way to figure out who closed the region.  So it is 
> better to change the message to say it is because of user, or balancing.

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

[jira] [Commented] (HBASE-5335) Dynamic Schema Configurations

[Nicolas Spiegelberg (Commented) (JIRA)]

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

Nicolas Spiegelberg commented on HBASE-5335:


Status update
1. Fixing the 3 unit test failures, caused by new split code between 89fb -> 
trunk.  
2. Fixed some ruby display/parsing problems found during manual testing.  We 
need a way to unit test the Ruby shell code easily.  
3. Taking the time to fix an issue that constantly annoys me: you should be 
able to run 'describe TABLE', copy the output, and paste it directly into 
'create' or 'alter'


> Dynamic Schema Configurations
> -
>
> Key: HBASE-5335
> URL: https://issues.apache.org/jira/browse/HBASE-5335
> Project: HBase
>  Issue Type: New Feature
>Reporter: Nicolas Spiegelberg
>Assignee: Nicolas Spiegelberg
>  Labels: configuration, schema
> Fix For: 0.96.0
>
> Attachments: D2247.1.patch, D2247.2.patch, D2247.3.patch, 
> D2247.4.patch, D2247.5.patch, D2247.6.patch, D2247.7.patch, D2247.8.patch, 
> HBASE-5335-trunk-2.patch, HBASE-5335-trunk.patch
>
>
> Currently, the ability for a core developer to add per-table & per-CF 
> configuration settings is very heavyweight.  You need to add a reserved 
> keyword all the way up the stack & you have to support this variable 
> long-term if you're going to expose it explicitly to the user.  This has 
> ended up with using Configuration.get() a lot because it is lightweight and 
> you can tweak settings while you're trying to understand system behavior 
> [since there are many config params that may never need to be tuned].  We 
> need to add the ability to put & read arbitrary KV settings in the HBase 
> schema.  Combined with online schema change, this will allow us to safely 
> iterate on configuration settings.

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

[Nicolas Spiegelberg (Updated) (JIRA)]

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

Nicolas Spiegelberg updated HBASE-5335:
---

Comment: was deleted

(was: Status update
1. Fixing the 3 unit test failures, caused by new split code between 89fb -> 
trunk.  
2. Fixed some ruby display/parsing problems found during manual testing.  We 
need a way to unit test the Ruby shell code easily.  
3. Taking the time to fix an issue that constantly annoys me: you should be 
able to run 'describe TABLE', copy the output, and paste it directly into 
'create' or 'alter'
)

> Dynamic Schema Configurations
> -
>
> Key: HBASE-5335
> URL: https://issues.apache.org/jira/browse/HBASE-5335
> Project: HBase
>  Issue Type: New Feature
>Reporter: Nicolas Spiegelberg
>Assignee: Nicolas Spiegelberg
>  Labels: configuration, schema
> Fix For: 0.96.0
>
> Attachments: D2247.1.patch, D2247.2.patch, D2247.3.patch, 
> D2247.4.patch, D2247.5.patch, D2247.6.patch, D2247.7.patch, D2247.8.patch, 
> HBASE-5335-trunk-2.patch, HBASE-5335-trunk.patch
>
>
> Currently, the ability for a core developer to add per-table & per-CF 
> configuration settings is very heavyweight.  You need to add a reserved 
> keyword all the way up the stack & you have to support this variable 
> long-term if you're going to expose it explicitly to the user.  This has 
> ended up with using Configuration.get() a lot because it is lightweight and 
> you can tweak settings while you're trying to understand system behavior 
> [since there are many config params that may never need to be tuned].  We 
> need to add the ability to put & read arbitrary KV settings in the HBase 
> schema.  Combined with online schema change, this will allow us to safely 
> iterate on configuration settings.

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

[jira] [Commented] (HBASE-5335) Dynamic Schema Configurations

[Nicolas Spiegelberg (Commented) (JIRA)]

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

Nicolas Spiegelberg commented on HBASE-5335:


Status update
1. Fixing the 3 unit test failures, caused by new split code between 89fb -> 
trunk.  
2. Fixed some ruby display/parsing problems found during manual testing.  We 
need a way to unit test the Ruby shell code easily.  
3. Taking the time to fix an issue that constantly annoys me: you should be 
able to run 'describe TABLE', copy the output, and paste it directly into 
'create' or 'alter'


> Dynamic Schema Configurations
> -
>
> Key: HBASE-5335
> URL: https://issues.apache.org/jira/browse/HBASE-5335
> Project: HBase
>  Issue Type: New Feature
>Reporter: Nicolas Spiegelberg
>Assignee: Nicolas Spiegelberg
>  Labels: configuration, schema
> Fix For: 0.96.0
>
> Attachments: D2247.1.patch, D2247.2.patch, D2247.3.patch, 
> D2247.4.patch, D2247.5.patch, D2247.6.patch, D2247.7.patch, D2247.8.patch, 
> HBASE-5335-trunk-2.patch, HBASE-5335-trunk.patch
>
>
> Currently, the ability for a core developer to add per-table & per-CF 
> configuration settings is very heavyweight.  You need to add a reserved 
> keyword all the way up the stack & you have to support this variable 
> long-term if you're going to expose it explicitly to the user.  This has 
> ended up with using Configuration.get() a lot because it is lightweight and 
> you can tweak settings while you're trying to understand system behavior 
> [since there are many config params that may never need to be tuned].  We 
> need to add the ability to put & read arbitrary KV settings in the HBase 
> schema.  Combined with online schema change, this will allow us to safely 
> iterate on configuration settings.

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

[jira] [Commented] (HBASE-5720) HFileDataBlockEncoderImpl uses wrong header size when reading HFiles with no checksums

[stack (Commented) (JIRA)]

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

stack commented on HBASE-5720:
--

Sorry for attaching non-compiling patch.  Looking at this, its hard to get the 
a default header into the HFileBlockDefaultEncodingContext where it seems it 
now belongs.

> HFileDataBlockEncoderImpl uses wrong header size when reading HFiles with no 
> checksums
> --
>
> Key: HBASE-5720
> URL: https://issues.apache.org/jira/browse/HBASE-5720
> Project: HBase
>  Issue Type: Bug
>  Components: io, regionserver
>Affects Versions: 0.94.0
>Reporter: Matt Corgan
>Priority: Blocker
> Fix For: 0.94.0
>
> Attachments: 5720v4.txt, 5720v4.txt, 5720v4.txt, HBASE-5720-v1.patch, 
> HBASE-5720-v2.patch, HBASE-5720-v3.patch
>
>
> When reading a .92 HFile without checksums, encoding it, and storing in the 
> block cache, the HFileDataBlockEncoderImpl always allocates a dummy header 
> appropriate for checksums even though there are none.  This corrupts the 
> byte[].
> Attaching a patch that allocates a DUMMY_HEADER_NO_CHECKSUM in that case 
> which I think is the desired behavior.

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

[jira] [Commented] (HBASE-5709) Move active master and backup master znodes to use pbs

[Hudson (Commented) (JIRA)]

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

Hudson commented on HBASE-5709:
---

Integrated in HBase-TRUNK #2721 (See 
[https://builds.apache.org/job/HBase-TRUNK/2721/])
HBASE-5709 Move active master and backup master znodes to use pbs (Revision 
1310553)

 Result = SUCCESS
stack : 
Files : 
* /hbase/trunk/src/main/java/org/apache/hadoop/hbase/MasterAddressTracker.java
* 
/hbase/trunk/src/main/java/org/apache/hadoop/hbase/client/HConnectionManager.java
* 
/hbase/trunk/src/main/java/org/apache/hadoop/hbase/master/ActiveMasterManager.java
* /hbase/trunk/src/main/java/org/apache/hadoop/hbase/master/HMaster.java
* 
/hbase/trunk/src/main/java/org/apache/hadoop/hbase/protobuf/generated/ZooKeeperProtos.java
* 
/hbase/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java
* 
/hbase/trunk/src/main/java/org/apache/hadoop/hbase/zookeeper/MasterAddressTracker.java
* 
/hbase/trunk/src/main/java/org/apache/hadoop/hbase/zookeeper/RootRegionTracker.java
* /hbase/trunk/src/main/java/org/apache/hadoop/hbase/zookeeper/ZKUtil.java
* 
/hbase/trunk/src/main/java/org/apache/hadoop/hbase/zookeeper/ZooKeeperWatcher.java
* /hbase/trunk/src/main/protobuf/ZooKeeper.proto
* 
/hbase/trunk/src/test/java/org/apache/hadoop/hbase/master/TestActiveMasterManager.java
* 
/hbase/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestMasterAddressManager.java
* 
/hbase/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestRSStatusServlet.java


> Move active master and backup master znodes to use pbs
> --
>
> Key: HBASE-5709
> URL: https://issues.apache.org/jira/browse/HBASE-5709
> Project: HBase
>  Issue Type: Task
>Reporter: stack
>Assignee: stack
> Fix For: 0.96.0
>
> Attachments: 5709.txt, 5709v2.txt, 5709v3.txt
>
>


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

[jira] [Commented] (HBASE-5666) RegionServer doesn't retry to check if base node is available

[Hadoop QA (Commented) (JIRA)]

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

Hadoop QA commented on HBASE-5666:
--

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

This message is automatically generated.

> RegionServer doesn't retry to check if base node is available
> -
>
> Key: HBASE-5666
> URL: https://issues.apache.org/jira/browse/HBASE-5666
> Project: HBase
>  Issue Type: Bug
>  Components: regionserver, zookeeper
>Reporter: Matteo Bertozzi
>Assignee: Matteo Bertozzi
> Attachments: HBASE-5666-v1.patch, HBASE-5666-v2.patch, 
> HBASE-5666-v3.patch, HBASE-5666-v4.patch, HBASE-5666-v5.patch, 
> HBASE-5666-v6.patch, hbase-1-regionserver.log, hbase-2-regionserver.log, 
> hbase-3-regionserver.log, hbase-master.log, hbase-regionserver.log, 
> hbase-zookeeper.log
>
>
> I've a script that starts hbase and a couple of region servers in distributed 
> mode (hbase.cluster.distributed = true)
> {code}
> $HBASE_HOME/bin/start-hbase.sh
> $HBASE_HOME/bin/local-regionservers.sh start 1 2 3
> {code}
> but the region servers are not able to start...
> It seems that during the RS start the the znode is still not available, and 
> HRegionServer.initializeZooKeeper() check just once if the base not is 
> available.
> {code}
> 2012-03-28 21:54:05,013 INFO 
> org.apache.hadoop.hbase.regionserver.HRegionServer: STOPPED: Check the value 
> configured in 'zookeeper.znode.parent'. There could be a mismatch with the 
> one configured in the master.
> 2012-03-28 21:54:08,598 FATAL 
> org.apache.hadoop.hbase.regionserver.HRegionServer: ABORTING region server 
> localhost,60202,133296824: Initialization of RS failed.  Hence aborting 
> RS.
> java.io.IOException: Received the shutdown message while waiting.
>   at 
> org.apache.hadoop.hbase.regionserver.HRegionServer.blockAndCheckIfStopped(HRegionServer.java:626)
>   at 
> org.apache.hadoop.hbase.regionserver.HRegionServer.initializeZooKeeper(HRegionServer.java:596)
>   at 
> org.apache.hadoop.hbase.regionserver.HRegionServer.preRegistrationInitialization(HRegionServer.java:558)
>   at 
> org.apache.hadoop.hbase.regionserver.HRegionServer.run(HRegionServer.java:672)
>   at java.lang.Thread.run(Thread.java:662)
> {code}

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

[jira] [Updated] (HBASE-5335) Dynamic Schema Configurations

[Nicolas Spiegelberg (Updated) (JIRA)]

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

Nicolas Spiegelberg updated HBASE-5335:
---

Status: Open  (was: Patch Available)

> Dynamic Schema Configurations
> -
>
> Key: HBASE-5335
> URL: https://issues.apache.org/jira/browse/HBASE-5335
> Project: HBase
>  Issue Type: New Feature
>Reporter: Nicolas Spiegelberg
>Assignee: Nicolas Spiegelberg
>  Labels: configuration, schema
> Fix For: 0.96.0
>
> Attachments: D2247.1.patch, D2247.2.patch, D2247.3.patch, 
> D2247.4.patch, D2247.5.patch, D2247.6.patch, D2247.7.patch, D2247.8.patch, 
> HBASE-5335-trunk-2.patch, HBASE-5335-trunk-3.patch, HBASE-5335-trunk.patch
>
>
> Currently, the ability for a core developer to add per-table & per-CF 
> configuration settings is very heavyweight.  You need to add a reserved 
> keyword all the way up the stack & you have to support this variable 
> long-term if you're going to expose it explicitly to the user.  This has 
> ended up with using Configuration.get() a lot because it is lightweight and 
> you can tweak settings while you're trying to understand system behavior 
> [since there are many config params that may never need to be tuned].  We 
> need to add the ability to put & read arbitrary KV settings in the HBase 
> schema.  Combined with online schema change, this will allow us to safely 
> iterate on configuration settings.

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

[Nicolas Spiegelberg (Updated) (JIRA)]

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

Nicolas Spiegelberg updated HBASE-5335:
---

Attachment: HBASE-5335-trunk-3.patch

final patch *crosses fingers*

> Dynamic Schema Configurations
> -
>
> Key: HBASE-5335
> URL: https://issues.apache.org/jira/browse/HBASE-5335
> Project: HBase
>  Issue Type: New Feature
>Reporter: Nicolas Spiegelberg
>Assignee: Nicolas Spiegelberg
>  Labels: configuration, schema
> Fix For: 0.96.0
>
> Attachments: D2247.1.patch, D2247.2.patch, D2247.3.patch, 
> D2247.4.patch, D2247.5.patch, D2247.6.patch, D2247.7.patch, D2247.8.patch, 
> HBASE-5335-trunk-2.patch, HBASE-5335-trunk-3.patch, HBASE-5335-trunk.patch
>
>
> Currently, the ability for a core developer to add per-table & per-CF 
> configuration settings is very heavyweight.  You need to add a reserved 
> keyword all the way up the stack & you have to support this variable 
> long-term if you're going to expose it explicitly to the user.  This has 
> ended up with using Configuration.get() a lot because it is lightweight and 
> you can tweak settings while you're trying to understand system behavior 
> [since there are many config params that may never need to be tuned].  We 
> need to add the ability to put & read arbitrary KV settings in the HBase 
> schema.  Combined with online schema change, this will allow us to safely 
> iterate on configuration settings.

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

[jira] [Work stopped] (HBASE-5335) Dynamic Schema Configurations

[Nicolas Spiegelberg (Work stopped) (JIRA)]

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

Work on HBASE-5335 stopped by Nicolas Spiegelberg.

> Dynamic Schema Configurations
> -
>
> Key: HBASE-5335
> URL: https://issues.apache.org/jira/browse/HBASE-5335
> Project: HBase
>  Issue Type: New Feature
>Reporter: Nicolas Spiegelberg
>Assignee: Nicolas Spiegelberg
>  Labels: configuration, schema
> Fix For: 0.96.0
>
> Attachments: D2247.1.patch, D2247.2.patch, D2247.3.patch, 
> D2247.4.patch, D2247.5.patch, D2247.6.patch, D2247.7.patch, D2247.8.patch, 
> HBASE-5335-trunk-2.patch, HBASE-5335-trunk-3.patch, HBASE-5335-trunk.patch
>
>
> Currently, the ability for a core developer to add per-table & per-CF 
> configuration settings is very heavyweight.  You need to add a reserved 
> keyword all the way up the stack & you have to support this variable 
> long-term if you're going to expose it explicitly to the user.  This has 
> ended up with using Configuration.get() a lot because it is lightweight and 
> you can tweak settings while you're trying to understand system behavior 
> [since there are many config params that may never need to be tuned].  We 
> need to add the ability to put & read arbitrary KV settings in the HBase 
> schema.  Combined with online schema change, this will allow us to safely 
> iterate on configuration settings.

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

[Nicolas Spiegelberg (Updated) (JIRA)]

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

Nicolas Spiegelberg updated HBASE-5335:
---

Status: Patch Available  (was: Open)

> Dynamic Schema Configurations
> -
>
> Key: HBASE-5335
> URL: https://issues.apache.org/jira/browse/HBASE-5335
> Project: HBase
>  Issue Type: New Feature
>Reporter: Nicolas Spiegelberg
>Assignee: Nicolas Spiegelberg
>  Labels: configuration, schema
> Fix For: 0.96.0
>
> Attachments: D2247.1.patch, D2247.2.patch, D2247.3.patch, 
> D2247.4.patch, D2247.5.patch, D2247.6.patch, D2247.7.patch, D2247.8.patch, 
> HBASE-5335-trunk-2.patch, HBASE-5335-trunk-3.patch, HBASE-5335-trunk.patch
>
>
> Currently, the ability for a core developer to add per-table & per-CF 
> configuration settings is very heavyweight.  You need to add a reserved 
> keyword all the way up the stack & you have to support this variable 
> long-term if you're going to expose it explicitly to the user.  This has 
> ended up with using Configuration.get() a lot because it is lightweight and 
> you can tweak settings while you're trying to understand system behavior 
> [since there are many config params that may never need to be tuned].  We 
> need to add the ability to put & read arbitrary KV settings in the HBase 
> schema.  Combined with online schema change, this will allow us to safely 
> iterate on configuration settings.

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

[jira] [Work started] (HBASE-5335) Dynamic Schema Configurations

[Nicolas Spiegelberg (Work started) (JIRA)]

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

Work on HBASE-5335 started by Nicolas Spiegelberg.

> Dynamic Schema Configurations
> -
>
> Key: HBASE-5335
> URL: https://issues.apache.org/jira/browse/HBASE-5335
> Project: HBase
>  Issue Type: New Feature
>Reporter: Nicolas Spiegelberg
>Assignee: Nicolas Spiegelberg
>  Labels: configuration, schema
> Fix For: 0.96.0
>
> Attachments: D2247.1.patch, D2247.2.patch, D2247.3.patch, 
> D2247.4.patch, D2247.5.patch, D2247.6.patch, D2247.7.patch, D2247.8.patch, 
> HBASE-5335-trunk-2.patch, HBASE-5335-trunk-3.patch, HBASE-5335-trunk.patch
>
>
> Currently, the ability for a core developer to add per-table & per-CF 
> configuration settings is very heavyweight.  You need to add a reserved 
> keyword all the way up the stack & you have to support this variable 
> long-term if you're going to expose it explicitly to the user.  This has 
> ended up with using Configuration.get() a lot because it is lightweight and 
> you can tweak settings while you're trying to understand system behavior 
> [since there are many config params that may never need to be tuned].  We 
> need to add the ability to put & read arbitrary KV settings in the HBase 
> schema.  Combined with online schema change, this will allow us to safely 
> iterate on configuration settings.

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

[jira] [Commented] (HBASE-5335) Dynamic Schema Configurations

[Hadoop QA (Commented) (JIRA)]

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

Hadoop QA commented on HBASE-5335:
--

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

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

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

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

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

This message is automatically generated.

> Dynamic Schema Configurations
> -
>
> Key: HBASE-5335
> URL: https://issues.apache.org/jira/browse/HBASE-5335
> Project: HBase
>  Issue Type: New Feature
>Reporter: Nicolas Spiegelberg
>Assignee: Nicolas Spiegelberg
>  Labels: configuration, schema
> Fix For: 0.96.0
>
> Attachments: D2247.1.patch, D2247.2.patch, D2247.3.patch, 
> D2247.4.patch, D2247.5.patch, D2247.6.patch, D2247.7.patch, D2247.8.patch, 
> HBASE-5335-trunk-2.patch, HBASE-5335-trunk-3.patch, HBASE-5335-trunk.patch
>
>
> Currently, the ability for a core developer to add per-table & per-CF 
> configuration settings is very heavyweight.  You need to add a reserved 
> keyword all the way up the stack & you have to support this variable 
> long-term if you're going to expose it explicitly to the user.  This has 
> ended up with using Configuration.get() a lot because it is lightweight and 
> you can tweak settings while you're trying to understand system behavior 
> [since there are many config params that may never need to be tuned].  We 
> need to add the ability to put & read arbitrary KV settings in the HBase 
> schema.  Combined with online schema change, this will allow us to safely 
> iterate on configuration settings.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-5735) Clearer warning message when connecting a non-secure HBase client to a secure HBase server

[Shaneal Manek (Updated) (JIRA)]

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

Shaneal Manek updated HBASE-5735:
-

Attachment: HBASE-5735-v3.patch

Adds the server's version to the warning message when an insecure client is 
attempting to connect (per Jon's suggestion).

> Clearer warning message when connecting a non-secure HBase client to a secure 
> HBase server
> --
>
> Key: HBASE-5735
> URL: https://issues.apache.org/jira/browse/HBASE-5735
> Project: HBase
>  Issue Type: Improvement
>  Components: security
>Affects Versions: 0.92.1, 0.94.0
>Reporter: Shaneal Manek
>Priority: Trivial
> Attachments: HBASE-5375-v2.patch, HBASE-5375.patch, 
> HBASE-5735-v3.patch
>
>
> When a connection from a non secure-rpc-engine
> client is attempted the warning message you get is related to version
> mismatch:
> Mar 28, 3:27:13 PM WARN org.apache.hadoop.ipc.SecureServer Incorrect
> header or version mismatch from 172.29.82.121:43849 got version 3
> expected version 4
> While this is true, it isn't as useful as it could be. A more specific error 
> message warning end users that they're connecting with a non-secure client 
> may be more useful.

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

[jira] [Commented] (HBASE-5735) Clearer warning message when connecting a non-secure HBase client to a secure HBase server

[Shaneal Manek (Commented) (JIRA)]

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

Shaneal Manek commented on HBASE-5735:
--

Jon: Sounds reasonable. Uploaded a new patch that does so.

> Clearer warning message when connecting a non-secure HBase client to a secure 
> HBase server
> --
>
> Key: HBASE-5735
> URL: https://issues.apache.org/jira/browse/HBASE-5735
> Project: HBase
>  Issue Type: Improvement
>  Components: security
>Affects Versions: 0.92.1, 0.94.0
>Reporter: Shaneal Manek
>Priority: Trivial
> Attachments: HBASE-5375-v2.patch, HBASE-5375.patch, 
> HBASE-5735-v3.patch
>
>
> When a connection from a non secure-rpc-engine
> client is attempted the warning message you get is related to version
> mismatch:
> Mar 28, 3:27:13 PM WARN org.apache.hadoop.ipc.SecureServer Incorrect
> header or version mismatch from 172.29.82.121:43849 got version 3
> expected version 4
> While this is true, it isn't as useful as it could be. A more specific error 
> message warning end users that they're connecting with a non-secure client 
> may be more useful.

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

[jira] [Commented] (HBASE-5666) RegionServer doesn't retry to check if base node is available

[Matteo Bertozzi (Commented) (JIRA)]

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

Matteo Bertozzi commented on HBASE-5666:


Since the logical flow is:
 * HMaster start and create the base node
 * Region Servers wait for base node to be available

I prefer to use HBASE-5666-v6.patch adding the retry logic to 
ZKUtil.checkExists() in this way we've the "wait for base node step".

In the other case (@stack: fixing the ZookeeperWatcher) the first (master|RS) 
that arrive create the base node... but doesn't sounds right. 

> RegionServer doesn't retry to check if base node is available
> -
>
> Key: HBASE-5666
> URL: https://issues.apache.org/jira/browse/HBASE-5666
> Project: HBase
>  Issue Type: Bug
>  Components: regionserver, zookeeper
>Reporter: Matteo Bertozzi
>Assignee: Matteo Bertozzi
> Attachments: HBASE-5666-v1.patch, HBASE-5666-v2.patch, 
> HBASE-5666-v3.patch, HBASE-5666-v4.patch, HBASE-5666-v5.patch, 
> HBASE-5666-v6.patch, hbase-1-regionserver.log, hbase-2-regionserver.log, 
> hbase-3-regionserver.log, hbase-master.log, hbase-regionserver.log, 
> hbase-zookeeper.log
>
>
> I've a script that starts hbase and a couple of region servers in distributed 
> mode (hbase.cluster.distributed = true)
> {code}
> $HBASE_HOME/bin/start-hbase.sh
> $HBASE_HOME/bin/local-regionservers.sh start 1 2 3
> {code}
> but the region servers are not able to start...
> It seems that during the RS start the the znode is still not available, and 
> HRegionServer.initializeZooKeeper() check just once if the base not is 
> available.
> {code}
> 2012-03-28 21:54:05,013 INFO 
> org.apache.hadoop.hbase.regionserver.HRegionServer: STOPPED: Check the value 
> configured in 'zookeeper.znode.parent'. There could be a mismatch with the 
> one configured in the master.
> 2012-03-28 21:54:08,598 FATAL 
> org.apache.hadoop.hbase.regionserver.HRegionServer: ABORTING region server 
> localhost,60202,133296824: Initialization of RS failed.  Hence aborting 
> RS.
> java.io.IOException: Received the shutdown message while waiting.
>   at 
> org.apache.hadoop.hbase.regionserver.HRegionServer.blockAndCheckIfStopped(HRegionServer.java:626)
>   at 
> org.apache.hadoop.hbase.regionserver.HRegionServer.initializeZooKeeper(HRegionServer.java:596)
>   at 
> org.apache.hadoop.hbase.regionserver.HRegionServer.preRegistrationInitialization(HRegionServer.java:558)
>   at 
> org.apache.hadoop.hbase.regionserver.HRegionServer.run(HRegionServer.java:672)
>   at java.lang.Thread.run(Thread.java:662)
> {code}

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

[jira] [Updated] (HBASE-5707) Move clusterid and clusterup (shutdown) znodes over to pb

[stack (Updated) (JIRA)]

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

stack updated HBASE-5707:
-

Attachment: 5707v2.txt

Change startdate to startDate as per Jimmy suggestion.

> Move clusterid and clusterup (shutdown) znodes over to pb
> -
>
> Key: HBASE-5707
> URL: https://issues.apache.org/jira/browse/HBASE-5707
> Project: HBase
>  Issue Type: Task
>Reporter: stack
> Attachments: 5707.txt, 5707v2.txt
>
>


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

[jira] [Updated] (HBASE-5335) Dynamic Schema Configurations

[Nicolas Spiegelberg (Updated) (JIRA)]

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

Nicolas Spiegelberg updated HBASE-5335:
---

Status: Open  (was: Patch Available)

f*** Hadoop QA needs to learn patch -p1

> Dynamic Schema Configurations
> -
>
> Key: HBASE-5335
> URL: https://issues.apache.org/jira/browse/HBASE-5335
> Project: HBase
>  Issue Type: New Feature
>Reporter: Nicolas Spiegelberg
>Assignee: Nicolas Spiegelberg
>  Labels: configuration, schema
> Fix For: 0.96.0
>
> Attachments: D2247.1.patch, D2247.2.patch, D2247.3.patch, 
> D2247.4.patch, D2247.5.patch, D2247.6.patch, D2247.7.patch, D2247.8.patch, 
> HBASE-5335-trunk-2.patch, HBASE-5335-trunk-3.patch, HBASE-5335-trunk-3.patch, 
> HBASE-5335-trunk.patch
>
>
> Currently, the ability for a core developer to add per-table & per-CF 
> configuration settings is very heavyweight.  You need to add a reserved 
> keyword all the way up the stack & you have to support this variable 
> long-term if you're going to expose it explicitly to the user.  This has 
> ended up with using Configuration.get() a lot because it is lightweight and 
> you can tweak settings while you're trying to understand system behavior 
> [since there are many config params that may never need to be tuned].  We 
> need to add the ability to put & read arbitrary KV settings in the HBase 
> schema.  Combined with online schema change, this will allow us to safely 
> iterate on configuration settings.

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

[Nicolas Spiegelberg (Updated) (JIRA)]

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

Nicolas Spiegelberg updated HBASE-5335:
---

Attachment: HBASE-5335-trunk-3.patch

> Dynamic Schema Configurations
> -
>
> Key: HBASE-5335
> URL: https://issues.apache.org/jira/browse/HBASE-5335
> Project: HBase
>  Issue Type: New Feature
>Reporter: Nicolas Spiegelberg
>Assignee: Nicolas Spiegelberg
>  Labels: configuration, schema
> Fix For: 0.96.0
>
> Attachments: D2247.1.patch, D2247.2.patch, D2247.3.patch, 
> D2247.4.patch, D2247.5.patch, D2247.6.patch, D2247.7.patch, D2247.8.patch, 
> HBASE-5335-trunk-2.patch, HBASE-5335-trunk-3.patch, HBASE-5335-trunk-3.patch, 
> HBASE-5335-trunk.patch
>
>
> Currently, the ability for a core developer to add per-table & per-CF 
> configuration settings is very heavyweight.  You need to add a reserved 
> keyword all the way up the stack & you have to support this variable 
> long-term if you're going to expose it explicitly to the user.  This has 
> ended up with using Configuration.get() a lot because it is lightweight and 
> you can tweak settings while you're trying to understand system behavior 
> [since there are many config params that may never need to be tuned].  We 
> need to add the ability to put & read arbitrary KV settings in the HBase 
> schema.  Combined with online schema change, this will allow us to safely 
> iterate on configuration settings.

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

[Nicolas Spiegelberg (Updated) (JIRA)]

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

Nicolas Spiegelberg updated HBASE-5335:
---

Status: Patch Available  (was: Open)

> Dynamic Schema Configurations
> -
>
> Key: HBASE-5335
> URL: https://issues.apache.org/jira/browse/HBASE-5335
> Project: HBase
>  Issue Type: New Feature
>Reporter: Nicolas Spiegelberg
>Assignee: Nicolas Spiegelberg
>  Labels: configuration, schema
> Fix For: 0.96.0
>
> Attachments: D2247.1.patch, D2247.2.patch, D2247.3.patch, 
> D2247.4.patch, D2247.5.patch, D2247.6.patch, D2247.7.patch, D2247.8.patch, 
> HBASE-5335-trunk-2.patch, HBASE-5335-trunk-3.patch, HBASE-5335-trunk-3.patch, 
> HBASE-5335-trunk.patch
>
>
> Currently, the ability for a core developer to add per-table & per-CF 
> configuration settings is very heavyweight.  You need to add a reserved 
> keyword all the way up the stack & you have to support this variable 
> long-term if you're going to expose it explicitly to the user.  This has 
> ended up with using Configuration.get() a lot because it is lightweight and 
> you can tweak settings while you're trying to understand system behavior 
> [since there are many config params that may never need to be tuned].  We 
> need to add the ability to put & read arbitrary KV settings in the HBase 
> schema.  Combined with online schema change, this will allow us to safely 
> iterate on configuration settings.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-5740) Compaction interruption may be due to balacing

[Jimmy Xiang (Updated) (JIRA)]

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

Jimmy Xiang updated HBASE-5740:
---

Description: 
Currently, the log shows 

Aborting compaction of store LOG in region  because user requested stop.

But it is actually because of balancing.

Currently, there is no way to figure out who closed the region.  So it is 
better to change the message to say it is because of user, or balancing.

  was:
Currently, the log shows 

Aborting compaction of store LOG in region CCS_ACCOUNT_LOG_HBASE02_01,scm01 
IDNWNoA0002765 00061395804,1328855408473.8b68adefea8dbc8c77a97ce88cf657a6. 
because user requested stop.

But it is actually because of balancing.

Currently, there is no way to figure out who closed the region.  So it is 
better to change the message to say it is because of user, or balancing.


> Compaction interruption may be due to balacing
> --
>
> Key: HBASE-5740
> URL: https://issues.apache.org/jira/browse/HBASE-5740
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 0.96.0
>Reporter: Jimmy Xiang
>Assignee: Jimmy Xiang
>Priority: Trivial
> Fix For: 0.96.0
>
> Attachments: hbase-5740.patch
>
>
> Currently, the log shows 
> Aborting compaction of store LOG in region  because user requested stop.
> But it is actually because of balancing.
> Currently, there is no way to figure out who closed the region.  So it is 
> better to change the message to say it is because of user, or balancing.

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

[jira] [Commented] (HBASE-5335) Dynamic Schema Configurations

[Hadoop QA (Commented) (JIRA)]

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

Hadoop QA commented on HBASE-5335:
--

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

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

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

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

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

+1 findbugs.  The patch does not introduce any new Findbugs (version 1.3.9) 
warnings.

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

 -1 core tests.  The patch failed these unit tests:
 

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

This message is automatically generated.

> Dynamic Schema Configurations
> -
>
> Key: HBASE-5335
> URL: https://issues.apache.org/jira/browse/HBASE-5335
> Project: HBase
>  Issue Type: New Feature
>Reporter: Nicolas Spiegelberg
>Assignee: Nicolas Spiegelberg
>  Labels: configuration, schema
> Fix For: 0.96.0
>
> Attachments: D2247.1.patch, D2247.2.patch, D2247.3.patch, 
> D2247.4.patch, D2247.5.patch, D2247.6.patch, D2247.7.patch, D2247.8.patch, 
> HBASE-5335-trunk-2.patch, HBASE-5335-trunk-3.patch, HBASE-5335-trunk-3.patch, 
> HBASE-5335-trunk.patch
>
>
> Currently, the ability for a core developer to add per-table & per-CF 
> configuration settings is very heavyweight.  You need to add a reserved 
> keyword all the way up the stack & you have to support this variable 
> long-term if you're going to expose it explicitly to the user.  This has 
> ended up with using Configuration.get() a lot because it is lightweight and 
> you can tweak settings while you're trying to understand system behavior 
> [since there are many config params that may never need to be tuned].  We 
> need to add the ability to put & read arbitrary KV settings in the HBase 
> schema.  Combined with online schema change, this will allow us to safely 
> iterate on configuration settings.

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

[jira] [Commented] (HBASE-5707) Move clusterid and clusterup (shutdown) znodes over to pb

[Hadoop QA (Commented) (JIRA)]

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

Hadoop QA commented on HBASE-5707:
--

-1 overall.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12521723/5707v2.txt
  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 javadoc.  The javadoc tool did not generate any warning messages.

-1 javac.  The patch appears to cause mvn compile goal to fail.

-1 findbugs.  The patch appears to cause Findbugs (version 1.3.9) to fail.

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

 -1 core tests.  The patch failed these unit tests:
 

Test results: 
https://builds.apache.org/job/PreCommit-HBASE-Build/1437//testReport/
Console output: 
https://builds.apache.org/job/PreCommit-HBASE-Build/1437//console

This message is automatically generated.

> Move clusterid and clusterup (shutdown) znodes over to pb
> -
>
> Key: HBASE-5707
> URL: https://issues.apache.org/jira/browse/HBASE-5707
> Project: HBase
>  Issue Type: Task
>Reporter: stack
> Attachments: 5707.txt, 5707v2.txt
>
>


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

[jira] [Created] (HBASE-5741) ImportTsv does not check for table existence

[Clint Heath (Created) (JIRA)]

ImportTsv does not check for table existence 
-

 Key: HBASE-5741
 URL: https://issues.apache.org/jira/browse/HBASE-5741
 Project: HBase
  Issue Type: Bug
  Components: mapreduce
Affects Versions: 0.90.4
Reporter: Clint Heath


The usage statement for the "importtsv" command to hbase claims this:

"Note: if you do not use this option, then the target table must already exist 
in HBase" (in reference to the "importtsv.bulk.output" command-line option)

The truth is, the table must exist no matter what, importtsv cannot and will 
not create it for you.

This is the case because the createSubmittableJob method of ImportTsv does not 
even attempt to check if the table exists already, much less create it:

(From org.apache.hadoop.hbase.mapreduce.ImportTsv.java)

305 HTable table = new HTable(conf, tableName);

The HTable method signature in use there assumes the table exists and runs a 
meta scan on it:

(From org.apache.hadoop.hbase.client.HTable.java)

142 * Creates an object to access a HBase table.
...
151 public HTable(Configuration conf, final String tableName)

What we should do inside of createSubmittableJob is something similar to what 
the "completebulkloads" command would do:

(Taken from org.apache.hadoop.hbase.mapreduce.LoadIncrementalHFiles.java)

690 boolean tableExists = this.doesTableExist(tableName);
691 if (!tableExists) this.createTable(tableName,dirPath);

Currently the docs are misleading, the table in fact must exist prior to 
running importtsv. We should check if it exists rather than assume it's already 
there and throw the below exception:

12/03/14 17:15:42 WARN client.HConnectionManager$HConnectionImplementation: 
Encountered problems when prefetch META table: 
org.apache.hadoop.hbase.TableNotFoundException: Cannot find row in .META. for 
table: myTable2, row=myTable2,,99
at 
org.apache.hadoop.hbase.client.MetaScanner.metaScan(MetaScanner.java:150)
...


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-5707) Move clusterid and clusterup (shutdown) znodes over to pb

[stack (Updated) (JIRA)]

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

stack updated HBASE-5707:
-

Attachment: 5707v2.txt

Version that compiles.

> Move clusterid and clusterup (shutdown) znodes over to pb
> -
>
> Key: HBASE-5707
> URL: https://issues.apache.org/jira/browse/HBASE-5707
> Project: HBase
>  Issue Type: Task
>Reporter: stack
> Attachments: 5707.txt, 5707v2.txt, 5707v2.txt
>
>


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

[jira] [Commented] (HBASE-5740) Compaction interruption may be due to balacing

[Hadoop QA (Commented) (JIRA)]

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

Hadoop QA commented on HBASE-5740:
--

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

This message is automatically generated.

> Compaction interruption may be due to balacing
> --
>
> Key: HBASE-5740
> URL: https://issues.apache.org/jira/browse/HBASE-5740
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 0.96.0
>Reporter: Jimmy Xiang
>Assignee: Jimmy Xiang
>Priority: Trivial
> Fix For: 0.96.0
>
> Attachments: hbase-5740.patch
>
>
> Currently, the log shows 
> Aborting compaction of store LOG in region  because user requested stop.
> But it is actually because of balancing.
> Currently, there is no way to figure out who closed the region.  So it is 
> better to change the message to say it is because of user, or balancing.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-5707) Move clusterid and clusterup (shutdown) znodes over to pb

[stack (Updated) (JIRA)]

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

stack updated HBASE-5707:
-

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

Thanks for review Jimmy.

> Move clusterid and clusterup (shutdown) znodes over to pb
> -
>
> Key: HBASE-5707
> URL: https://issues.apache.org/jira/browse/HBASE-5707
> Project: HBase
>  Issue Type: Task
>Reporter: stack
>Assignee: stack
> Fix For: 0.96.0
>
> Attachments: 5707.txt, 5707v2.txt, 5707v2.txt
>
>


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

[jira] [Commented] (HBASE-5736) ThriftServerRunner.HbaseHandler.mutateRow() does not use ByteBuffer correctly

[Zhihong Yu (Commented) (JIRA)]

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

Zhihong Yu commented on HBASE-5736:
---

The test failure was caused by OutOfMemoryError.

Will integrate later if there is no objection.

> ThriftServerRunner.HbaseHandler.mutateRow() does not use ByteBuffer correctly
> -
>
> Key: HBASE-5736
> URL: https://issues.apache.org/jira/browse/HBASE-5736
> Project: HBase
>  Issue Type: Bug
>Reporter: Scott Chen
>Assignee: Scott Chen
> Attachments: HBASE-5736.D2649.1.patch, HBASE-5736.D2649.2.patch, 
> HBASE-5736.D2649.3.patch
>
>
> We have fixed similar bug in
> https://issues.apache.org/jira/browse/HBASE-5507
> It uses ByteBuffer.array() to read the ByteBuffer.
> This will ignore the offset return the whole underlying byte array.
> The bug can be triggered by using framed Transport thrift servers.

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

[jira] [Assigned] (HBASE-5741) ImportTsv does not check for table existence

[Himanshu Vashishtha (Assigned) (JIRA)]

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

Himanshu Vashishtha reassigned HBASE-5741:
--

Assignee: Himanshu Vashishtha

> ImportTsv does not check for table existence 
> -
>
> Key: HBASE-5741
> URL: https://issues.apache.org/jira/browse/HBASE-5741
> Project: HBase
>  Issue Type: Bug
>  Components: mapreduce
>Affects Versions: 0.90.4
>Reporter: Clint Heath
>Assignee: Himanshu Vashishtha
>
> The usage statement for the "importtsv" command to hbase claims this:
> "Note: if you do not use this option, then the target table must already 
> exist in HBase" (in reference to the "importtsv.bulk.output" command-line 
> option)
> The truth is, the table must exist no matter what, importtsv cannot and will 
> not create it for you.
> This is the case because the createSubmittableJob method of ImportTsv does 
> not even attempt to check if the table exists already, much less create it:
> (From org.apache.hadoop.hbase.mapreduce.ImportTsv.java)
> 305 HTable table = new HTable(conf, tableName);
> The HTable method signature in use there assumes the table exists and runs a 
> meta scan on it:
> (From org.apache.hadoop.hbase.client.HTable.java)
> 142 * Creates an object to access a HBase table.
> ...
> 151 public HTable(Configuration conf, final String tableName)
> What we should do inside of createSubmittableJob is something similar to what 
> the "completebulkloads" command would do:
> (Taken from org.apache.hadoop.hbase.mapreduce.LoadIncrementalHFiles.java)
> 690 boolean tableExists = this.doesTableExist(tableName);
> 691 if (!tableExists) this.createTable(tableName,dirPath);
> Currently the docs are misleading, the table in fact must exist prior to 
> running importtsv. We should check if it exists rather than assume it's 
> already there and throw the below exception:
> 12/03/14 17:15:42 WARN client.HConnectionManager$HConnectionImplementation: 
> Encountered problems when prefetch META table: 
> org.apache.hadoop.hbase.TableNotFoundException: Cannot find row in .META. for 
> table: myTable2, row=myTable2,,99
>   at 
> org.apache.hadoop.hbase.client.MetaScanner.metaScan(MetaScanner.java:150)
> ...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-5742) LoadIncrementalHFiles throws too generic of an exception

[David Capwell (Created) (JIRA)]

LoadIncrementalHFiles throws too generic of an exception


 Key: HBASE-5742
 URL: https://issues.apache.org/jira/browse/HBASE-5742
 Project: HBase
  Issue Type: Improvement
  Components: mapreduce
Reporter: David Capwell


In 0.90 the LoadIncrementalHFiles constructor did not throw an exception, now 
it throws Exception.  The constructor should ether not throw an exception or 
throw ZooKeeperConnectionException, and MasterNotRunningException since those 
come from the HBaseAdmin call.

https://github.com/apache/hbase/blob/trunk/src/main/java/org/apache/hadoop/hbase/mapreduce/LoadIncrementalHFiles.java#L105

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

[jira] [Commented] (HBASE-5740) Compaction interruption may be due to balacing

[Jean-Daniel Cryans (Commented) (JIRA)]

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

Jean-Daniel Cryans commented on HBASE-5740:
---

Or disabling, or online altering (open/close).

> Compaction interruption may be due to balacing
> --
>
> Key: HBASE-5740
> URL: https://issues.apache.org/jira/browse/HBASE-5740
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 0.96.0
>Reporter: Jimmy Xiang
>Assignee: Jimmy Xiang
>Priority: Trivial
> Fix For: 0.96.0
>
> Attachments: hbase-5740.patch
>
>
> Currently, the log shows 
> Aborting compaction of store LOG in region  because user requested stop.
> But it is actually because of balancing.
> Currently, there is no way to figure out who closed the region.  So it is 
> better to change the message to say it is because of user, or balancing.

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

[Nicolas Spiegelberg (Created) (JIRA)]

Support GIT patches
---

 Key: HBASE-5743
 URL: https://issues.apache.org/jira/browse/HBASE-5743
 Project: HBase
  Issue Type: Bug
Reporter: Nicolas Spiegelberg


Need to import HADOOP-7384 into our version of Hadoop QA to allow test-patch to 
be more flexible about patch format

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

[jira] [Assigned] (HBASE-5743) Support GIT patches

[Nicolas Spiegelberg (Assigned) (JIRA)]

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

Nicolas Spiegelberg reassigned HBASE-5743:
--

Assignee: Nicolas Spiegelberg

> Support GIT patches
> ---
>
> Key: HBASE-5743
> URL: https://issues.apache.org/jira/browse/HBASE-5743
> Project: HBase
>  Issue Type: Bug
>Reporter: Nicolas Spiegelberg
>Assignee: Nicolas Spiegelberg
>
> Need to import HADOOP-7384 into our version of Hadoop QA to allow test-patch 
> to be more flexible about patch format

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

[jira] [Commented] (HBASE-5740) Compaction interruption may be due to balacing

[Jimmy Xiang (Commented) (JIRA)]

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

Jimmy Xiang commented on HBASE-5740:


This is also requested by user, right?  Region split could be another one 
triggered by system.  Any other related operations triggered by system?

> Compaction interruption may be due to balacing
> --
>
> Key: HBASE-5740
> URL: https://issues.apache.org/jira/browse/HBASE-5740
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 0.96.0
>Reporter: Jimmy Xiang
>Assignee: Jimmy Xiang
>Priority: Trivial
> Fix For: 0.96.0
>
> Attachments: hbase-5740.patch
>
>
> Currently, the log shows 
> Aborting compaction of store LOG in region  because user requested stop.
> But it is actually because of balancing.
> Currently, there is no way to figure out who closed the region.  So it is 
> better to change the message to say it is because of user, or balancing.

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

[jira] [Commented] (HBASE-5735) Clearer warning message when connecting a non-secure HBase client to a secure HBase server

[Hadoop QA (Commented) (JIRA)]

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

Hadoop QA commented on HBASE-5735:
--

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

This message is automatically generated.

> Clearer warning message when connecting a non-secure HBase client to a secure 
> HBase server
> --
>
> Key: HBASE-5735
> URL: https://issues.apache.org/jira/browse/HBASE-5735
> Project: HBase
>  Issue Type: Improvement
>  Components: security
>Affects Versions: 0.92.1, 0.94.0
>Reporter: Shaneal Manek
>Priority: Trivial
> Attachments: HBASE-5375-v2.patch, HBASE-5375.patch, 
> HBASE-5735-v3.patch
>
>
> When a connection from a non secure-rpc-engine
> client is attempted the warning message you get is related to version
> mismatch:
> Mar 28, 3:27:13 PM WARN org.apache.hadoop.ipc.SecureServer Incorrect
> header or version mismatch from 172.29.82.121:43849 got version 3
> expected version 4
> While this is true, it isn't as useful as it could be. A more specific error 
> message warning end users that they're connecting with a non-secure client 
> may be more useful.

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

[jira] [Commented] (HBASE-5620) Convert the client protocol of HRegionInterface to PB

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

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

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


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


Good stuff Jimmy.  A few comments below.  Sorry I ramble at times.  Read to the 
end before reacting because I change my mind as I work through the patch.  You 
forgot to add RequestConverter?


src/main/java/org/apache/hadoop/hbase/HConstants.java


Should these be in here?  Can they be elsewhere, as defines in 
RegionClassProtocol?



src/main/java/org/apache/hadoop/hbase/catalog/MetaReader.java


I don't know how you get away with these removes but I'm glad to see them 
go -- anything that shrinks this catalog package is good by me



src/main/java/org/apache/hadoop/hbase/client/HBaseAdmin.java


RegionClientProtocol is a bad name, no?  Should it be just ClientProtocol 
and AdminProtocol?



src/main/java/org/apache/hadoop/hbase/client/HBaseAdmin.java


this should be getClient?  We're going to get a client for a table?  Maybe 
should be getTableClient?



src/main/java/org/apache/hadoop/hbase/client/HBaseAdmin.java


Why we need a converter?



src/main/java/org/apache/hadoop/hbase/client/HBaseAdmin.java


Whats the NULL_CONTROLLER about?



src/main/java/org/apache/hadoop/hbase/client/HBaseAdmin.java


So we don't close scanners anymore?



src/main/java/org/apache/hadoop/hbase/client/HConnection.java


Why do we need to pollute HConnection w/ higher level notions such as 
RegionClientProtocol (or ClientProtocol?) hmmm ClientProtocol would be ok 
but not RegionClientProtocol...



src/main/java/org/apache/hadoop/hbase/client/HConnection.java


I wonder if this needs to be public and in the Interface?  Could it be an 
internal thing?  How uses this thing that comes out?  Maybe it needs to be here 
but sure seems like an internal thing: i.e. we pass hostname and port of a 
particular regionserver but then internally as we go about the cluster the 
client will go to new regionservers and set up connections 

Looking around though, it seems that while most uses of this method should 
be shut down: e.g. over in catalog package and replaced by calls that go via 
HTable, there are a few places we need this still probably .. as in the master 
sendRegionClose, etc. calls.   So you can't get rid  of it.

But this looks like it should be called RegionServerProtocol
or ClientProtocol and not RegionClientProtocol.  It connects to a 
RegionServer not a Region.

Or what you think Jimmy?When I look at the RegionClient proto file, is 
it true to say that in each message, we MUST pass a region since we are going 
against a particular region... which would mean this is indeed a 
RegionClientProtocol (you just have to specify coordinates in two steps; 1. 
pass servername setting up connection, then 2. for any call on the connection, 
need to specify the region.)






src/main/java/org/apache/hadoop/hbase/client/HConnectionManager.java


Move these defines into this class rather than up in HConstants?



src/main/java/org/apache/hadoop/hbase/client/HConnectionManager.java


Whats happening here?  We want to drop the methods that took hostname and 
port only and move to those that take servername?



src/main/java/org/apache/hadoop/hbase/client/HConnectionManager.java


Is this good?  Should we have servername?  What if server restarts in 
between?  Would we want to notice that we don't have a connection to new 
instantiation and go create one?



src/main/java/org/apache/hadoop/hbase/client/HConnectionManager.java


Does this need to be synchronized at all?



src/main/java/org/apache/hadoop/hbase/client/ScannerCallable.java


I suppose HBaseClient down in rpc knows it because it has to deserialize 
the pb?



src/main/java/org/apache/hadoop/hbase/client/ScannerCallable.java

[jira] [Commented] (HBASE-5720) HFileDataBlockEncoderImpl uses wrong header size when reading HFiles with no checksums

[Lars Hofhansl (Commented) (JIRA)]

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

Lars Hofhansl commented on HBASE-5720:
--

Yeah, I poked around a few minutes. Seems we need to pass the header at the 
time when we do the encoding, rather than storing it in the EncodingContext. 
The changes for that are not entirely trivial.
An ugly way out might be a setter for the header in the EncodingContext and 
then set it when known, but that is too nasty and error prone. Maybe Dhruba has 
an idea...?

At this point I think I want to commit to and close this for 0.94 and file 
another jira for trunk. Any objections to that?

> HFileDataBlockEncoderImpl uses wrong header size when reading HFiles with no 
> checksums
> --
>
> Key: HBASE-5720
> URL: https://issues.apache.org/jira/browse/HBASE-5720
> Project: HBase
>  Issue Type: Bug
>  Components: io, regionserver
>Affects Versions: 0.94.0
>Reporter: Matt Corgan
>Priority: Blocker
> Fix For: 0.94.0
>
> Attachments: 5720v4.txt, 5720v4.txt, 5720v4.txt, HBASE-5720-v1.patch, 
> HBASE-5720-v2.patch, HBASE-5720-v3.patch
>
>
> When reading a .92 HFile without checksums, encoding it, and storing in the 
> block cache, the HFileDataBlockEncoderImpl always allocates a dummy header 
> appropriate for checksums even though there are none.  This corrupts the 
> byte[].
> Attaching a patch that allocates a DUMMY_HEADER_NO_CHECKSUM in that case 
> which I think is the desired behavior.

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

[Nicolas Spiegelberg (Updated) (JIRA)]

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

Nicolas Spiegelberg updated HBASE-5743:
---

Attachment: HBASE-5743.patch

Test plan:

1. ./dev-support/smart-apply-patch.sh HBASE-5335-trunk-3.patch
2. git show 5335-trunk | PATCH=echo dev-support/smart-apply-patch.sh -

> Support GIT patches
> ---
>
> Key: HBASE-5743
> URL: https://issues.apache.org/jira/browse/HBASE-5743
> Project: HBase
>  Issue Type: Bug
>Reporter: Nicolas Spiegelberg
>Assignee: Nicolas Spiegelberg
> Attachments: HBASE-5743.patch
>
>
> Need to import HADOOP-7384 into our version of Hadoop QA to allow test-patch 
> to be more flexible about patch format

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

[jira] [Issue Comment Edited] (HBASE-5674) add support in HBase to overwrite hbase timestamp to a version number during major compaction

[Mikhail Bautin (Issue Comment Edited) (JIRA)]

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

Mikhail Bautin edited comment on HBASE-5674 at 4/6/12 9:15 PM:
---

Thanks Matt and stack for the point out of 4676. Yeah, we are very very 
interested in the work that is going on HBase-4676.

  was (Author: he yongqiang):
Thanks Matt and stack for the point out of 4676. Yeah, we are very very 
interested in the work that is going on HBase-4767.
  
> add support in HBase to overwrite hbase timestamp to a version number during 
> major compaction
> -
>
> Key: HBASE-5674
> URL: https://issues.apache.org/jira/browse/HBASE-5674
> Project: HBase
>  Issue Type: Improvement
>Reporter: He Yongqiang
>Assignee: He Yongqiang
>
> Right now, a millisecond-level timestamp is attached to every record. 
> In our case, we only need a version number (mostly it will be just zero etc). 
> A millisecond timestamp is too heavy to carry. We should add support to 
> overwrite it to zero during major compaction. 
> KVs before major compaction will remain using system timestamp. And this 
> should be configurable, so that we should not mess up if the hbase timestamp 
> is specified by application.

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

[jira] [Commented] (HBASE-5717) Scanner metrics are only reported if you get to the end of a scanner

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

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

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



bq.  On 2012-04-04 22:03:32, Ian Varley wrote:
bq.  >

Good catch. There is another scenario that could be useful when you have long 
running scan operation. While a scan is running, e.g. before it finishes or 
closed, if somehow the ScanMetrics can be updated for time to time without perf 
impact, that can provide more real-time number for mapreduce HBase Ccounters 
which uses ScanMetrics. But that could be a separate nice-to-have improvement.


- Ming


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


On 2012-04-05 18:52:50, Ian Varley wrote:
bq.  
bq.  ---
bq.  This is an automatically generated e-mail. To reply, visit:
bq.  https://reviews.apache.org/r/4640/
bq.  ---
bq.  
bq.  (Updated 2012-04-05 18:52:50)
bq.  
bq.  
bq.  Review request for hbase.
bq.  
bq.  
bq.  Summary
bq.  ---
bq.  
bq.  Fix for persistence of scan metrics when the scanner doesn't run to 
exhaustion.
bq.  
bq.  
bq.  This addresses bug HBASE-5717.
bq.  https://issues.apache.org/jira/browse/HBASE-5717
bq.  
bq.  
bq.  Diffs
bq.  -
bq.  
bq./src/test/java/org/apache/hadoop/hbase/client/TestFromClientSide.java 
1309585 
bq./src/main/java/org/apache/hadoop/hbase/client/ClientScanner.java 1309585 
bq.  
bq.  Diff: https://reviews.apache.org/r/4640/diff
bq.  
bq.  
bq.  Testing
bq.  ---
bq.  
bq.  Altered the scan metrics unit test to show this problem (now fails without 
changes to ClientScanner.java).
bq.  
bq.  
bq.  Thanks,
bq.  
bq.  Ian
bq.  
bq.



> Scanner metrics are only reported if you get to the end of a scanner
> 
>
> Key: HBASE-5717
> URL: https://issues.apache.org/jira/browse/HBASE-5717
> Project: HBase
>  Issue Type: Bug
>  Components: client, metrics
>Reporter: Ian Varley
>Priority: Minor
> Attachments: ClientScanner_HBASE_5717-v2.patch, 
> ClientScanner_HBASE_5717-v3.patch, ClientScanner_HBASE_5717.patch
>
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> When you turn on Scanner Metrics, the metrics are currently only made 
> available if you run over all records available in the scanner. If you stop 
> iterating before the end, the values are never flushed into the metrics 
> object (in the Scan attribute).
> Will supply a patch with fix and test.

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

[jira] [Commented] (HBASE-5707) Move clusterid and clusterup (shutdown) znodes over to pb

[Hudson (Commented) (JIRA)]

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

Hudson commented on HBASE-5707:
---

Integrated in HBase-TRUNK #2722 (See 
[https://builds.apache.org/job/HBase-TRUNK/2722/])
HBASE-5707 Move clusterid and clusterup (shutdown) znodes over to pb 
(Revision 1310568)

 Result = SUCCESS
stack : 
Files : 
* 
/hbase/trunk/src/main/java/org/apache/hadoop/hbase/client/HConnectionManager.java
* 
/hbase/trunk/src/main/java/org/apache/hadoop/hbase/protobuf/generated/ZooKeeperProtos.java
* /hbase/trunk/src/main/java/org/apache/hadoop/hbase/zookeeper/ClusterId.java
* 
/hbase/trunk/src/main/java/org/apache/hadoop/hbase/zookeeper/ClusterStatusTracker.java
* 
/hbase/trunk/src/main/java/org/apache/hadoop/hbase/zookeeper/RootRegionTracker.java
* /hbase/trunk/src/main/protobuf/ZooKeeper.proto


> Move clusterid and clusterup (shutdown) znodes over to pb
> -
>
> Key: HBASE-5707
> URL: https://issues.apache.org/jira/browse/HBASE-5707
> Project: HBase
>  Issue Type: Task
>Reporter: stack
>Assignee: stack
> Fix For: 0.96.0
>
> Attachments: 5707.txt, 5707v2.txt, 5707v2.txt
>
>


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

[jira] [Commented] (HBASE-5355) Compressed RPC's for HBase

[Mikhail Bautin (Commented) (JIRA)]

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

Mikhail Bautin commented on HBASE-5355:
---

We have committed this feature (internally) to 89-fb. The implementation is 
available at https://reviews.facebook.net/D1671. I tried to apply a patch to 
trunk, but it turned out to be very complex due to protocol refactoring done in 
trunk. Since trunk is moving to protocol buffers, this feature might be 
implemented very differently there compared to our RPC compression 
implementation 89-fb. Given these complications, we currently do not have 
enough resources to do the proper port to trunk, so I will commit the 89-fb 
patch into the 0.89-fb branch and leave the JIRA open for the trunk fix.

> Compressed RPC's for HBase
> --
>
> Key: HBASE-5355
> URL: https://issues.apache.org/jira/browse/HBASE-5355
> Project: HBase
>  Issue Type: Improvement
>  Components: ipc
>Affects Versions: 0.89.20100924
>Reporter: Karthik Ranganathan
>Assignee: Karthik Ranganathan
>
> Some application need ability to do large batched writes and reads from a 
> remote MR cluster. These eventually get bottlenecked on the network. These 
> results are also pretty compressible sometimes.
> The aim here is to add the ability to do compressed calls to the server on 
> both the send and receive paths.

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

[Nicolas Spiegelberg (Updated) (JIRA)]

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

Nicolas Spiegelberg updated HBASE-5743:
---

Attachment: HBASE-5743-2.patch

using smart-apply-patch file from hadoop trunk instead of the older version 
from HADOOP-7384.  This runs 'patch' in dry-run mode to determine prefix level, 
which is a far more fault-tolerant way of solving the problem.

> Support GIT patches
> ---
>
> Key: HBASE-5743
> URL: https://issues.apache.org/jira/browse/HBASE-5743
> Project: HBase
>  Issue Type: Bug
>Reporter: Nicolas Spiegelberg
>Assignee: Nicolas Spiegelberg
> Attachments: HBASE-5743-2.patch, HBASE-5743.patch
>
>
> Need to import HADOOP-7384 into our version of Hadoop QA to allow test-patch 
> to be more flexible about patch format

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