[jira] [Commented] (HBASE-16677) Add table size (total store file size) to table page
[ https://issues.apache.org/jira/browse/HBASE-16677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15520263#comment-15520263 ] Hudson commented on HBASE-16677: FAILURE: Integrated in Jenkins build HBase-1.4 #431 (See [https://builds.apache.org/job/HBase-1.4/431/]) HBASE-16677 Add table size (total store file size) to table page (Guang (chenheng: rev d6f9eab4be16dee0dd45ea9f1e0dd17ef8a74b7b) * (edit) hbase-server/src/main/resources/hbase-webapps/master/table.jsp > Add table size (total store file size) to table page > > > Key: HBASE-16677 > URL: https://issues.apache.org/jira/browse/HBASE-16677 > Project: HBase > Issue Type: New Feature > Components: website >Reporter: Guang Yang >Assignee: Guang Yang >Priority: Minor > Fix For: 2.0.0, 1.4.0 > > Attachments: HBASE-16677_v0.patch, HBASE-16677_v1.patch, > HBASE-16677_v2.patch, HBASE-16677_v3.patch, mini_cluster_master.png, > prod_cluster_partial.png, table_page_v3.png > > > Currently there is not an easy way to get the table size from the web UI, > though we have the region size on the page, it is still convenient to have a > table for the table size stat. > Another pain point is that when the table grow large with tens of thousands > of regions, it took extremely long time to load the page, however, sometimes > we don't want to check all the regions. An optimization could be to accept a > query parameter to specify the number of regions to render. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16667) Building with JDK 8: ignoring option MaxPermSize=256m
[
https://issues.apache.org/jira/browse/HBASE-16667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15520235#comment-15520235
]
Hudson commented on HBASE-16667:
FAILURE: Integrated in Jenkins build HBase-1.2-JDK8 #29 (See
[https://builds.apache.org/job/HBase-1.2-JDK8/29/])
HBASE-16667 Building with JDK 8: ignoring option MaxPermSize=256m (Niels
(jerryjch: rev f224e09ad9e5e18a31e14e2606bdefba5b901216)
* (edit) pom.xml
* (edit) hbase-it/pom.xml
> Building with JDK 8: ignoring option MaxPermSize=256m
> -
>
> Key: HBASE-16667
> URL: https://issues.apache.org/jira/browse/HBASE-16667
> Project: HBase
> Issue Type: Improvement
> Components: build
>Reporter: Niels Basjes
>Assignee: Niels Basjes
>Priority: Minor
> Labels: beginner
> Fix For: 2.0.0, 1.3.0, 1.4.0, 1.2.4
>
> Attachments: HBASE-16667-01.patch, HBASE-16667-branch-1-v1.patch,
> HBASE-16667-branch-1-v2.patch, HBASE-16667-v2.patch, HBASE-16667-v3.patch
>
>
> In JDK 8 the permgen was removed.
> As a consequence the build shows this line a lot of times, cluttering the
> output.
> {quote}
> OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support
> was removed in 8.0
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16682) Fix Shell tests failure. NoClassDefFoundError for MiniKdc
[
https://issues.apache.org/jira/browse/HBASE-16682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15520219#comment-15520219
]
Hadoop QA commented on HBASE-16682:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 19s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s
{color} | {color:red} 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. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 17s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
41s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 23s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
27s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 18s
{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 10s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
26s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 23s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 23s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
29s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m 3s
{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
30m 3s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green} 0m
22s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 15s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 11s
{color} | {color:green} hbase-testing-util in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 7m 28s
{color} | {color:green} hbase-shell in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
14s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 45m 42s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.11.2 Server=1.11.2 Image:yetus/hbase:7bda515 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12830214/HBASE-16682.master.003.patch
|
| JIRA Issue | HBASE-16682 |
| Optional Tests | asflicense javac javadoc unit xml compile |
| uname | Linux 433f5233cc65 3.13.0-92-generic #139-Ubuntu SMP Tue Jun 28
20:42:26 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / f7bb6fb |
| Default Java | 1.8.0_101 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/3707/testReport/ |
| modules | C: hbase-testing-util hbase-shell U: . |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/3707/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> Fix Shell tests failure. NoClassDefFoundError for MiniKdc
> -
>
> Key: HBASE-16682
> URL: https://issues.apache.org/jira/browse/HBASE-16682
[jira] [Commented] (HBASE-16667) Building with JDK 8: ignoring option MaxPermSize=256m
[
https://issues.apache.org/jira/browse/HBASE-16667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15520151#comment-15520151
]
Hudson commented on HBASE-16667:
FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #1668 (See
[https://builds.apache.org/job/HBase-Trunk_matrix/1668/])
HBASE-16667 Building with JDK 8: ignoring option MaxPermSize=256m (Niels
(jerryjch: rev 2765b9d9d965c61b3c40f81752cadb8ad536b501)
* (edit) conf/hbase-env.sh
* (edit) hbase-it/pom.xml
* (edit) hbase-spark/pom.xml
* (edit) pom.xml
* (edit) conf/hbase-env.cmd
* (edit) dev-support/jenkinsEnv.sh
> Building with JDK 8: ignoring option MaxPermSize=256m
> -
>
> Key: HBASE-16667
> URL: https://issues.apache.org/jira/browse/HBASE-16667
> Project: HBase
> Issue Type: Improvement
> Components: build
>Reporter: Niels Basjes
>Assignee: Niels Basjes
>Priority: Minor
> Labels: beginner
> Fix For: 2.0.0, 1.3.0, 1.4.0, 1.2.4
>
> Attachments: HBASE-16667-01.patch, HBASE-16667-branch-1-v1.patch,
> HBASE-16667-branch-1-v2.patch, HBASE-16667-v2.patch, HBASE-16667-v3.patch
>
>
> In JDK 8 the permgen was removed.
> As a consequence the build shows this line a lot of times, cluttering the
> output.
> {quote}
> OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support
> was removed in 8.0
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-16682) Fix Shell tests failure. NoClassDefFoundError for MiniKdc
[
https://issues.apache.org/jira/browse/HBASE-16682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Appy updated HBASE-16682:
-
Attachment: HBASE-16682.master.003.patch
> Fix Shell tests failure. NoClassDefFoundError for MiniKdc
> -
>
> Key: HBASE-16682
> URL: https://issues.apache.org/jira/browse/HBASE-16682
> Project: HBase
> Issue Type: Bug
>Reporter: Appy
>Assignee: Appy
> Attachments: HBASE-16682.master.001.patch,
> HBASE-16682.master.002.patch, HBASE-16682.master.003.patch
>
>
> Stacktrace
> {noformat}
> java.lang.NoClassDefFoundError: org/apache/hadoop/minikdc/MiniKdc
> at java.lang.Class.getDeclaredMethods0(Native Method)
> at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
> at java.lang.Class.getDeclaredMethods(Class.java:1975)
> at org.jruby.javasupport.JavaClass.getMethods(JavaClass.java:2110)
> at org.jruby.javasupport.JavaClass.setupClassMethods(JavaClass.java:955)
> at org.jruby.javasupport.JavaClass.access$700(JavaClass.java:99)
> at
> org.jruby.javasupport.JavaClass$ClassInitializer.initialize(JavaClass.java:650)
> at org.jruby.javasupport.JavaClass.setupProxy(JavaClass.java:689)
> at org.jruby.javasupport.Java.createProxyClass(Java.java:526)
> at org.jruby.javasupport.Java.getProxyClass(Java.java:455)
> at org.jruby.javasupport.Java.getInstance(Java.java:364)
> at
> org.jruby.javasupport.JavaUtil.convertJavaToUsableRubyObject(JavaUtil.java:166)
> at
> org.jruby.javasupport.JavaEmbedUtils.javaToRuby(JavaEmbedUtils.java:291)
> at
> org.jruby.embed.variable.AbstractVariable.updateByJavaObject(AbstractVariable.java:81)
> at
> org.jruby.embed.variable.GlobalVariable.(GlobalVariable.java:69)
> at
> org.jruby.embed.variable.GlobalVariable.getInstance(GlobalVariable.java:60)
> at
> org.jruby.embed.variable.VariableInterceptor.getVariableInstance(VariableInterceptor.java:97)
> at org.jruby.embed.internal.BiVariableMap.put(BiVariableMap.java:321)
> at org.jruby.embed.ScriptingContainer.put(ScriptingContainer.java:1123)
> at
> org.apache.hadoop.hbase.client.AbstractTestShell.setUpBeforeClass(AbstractTestShell.java:61)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:108)
> at
> org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:78)
> at
> org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:54)
> at
> org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:144)
> at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> Caused by: java.lang.ClassNotFoundException: org.apache.hadoop.minikdc.MiniKdc
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> at
[jira] [Commented] (HBASE-16682) Fix Shell tests failure. NoClassDefFoundError for MiniKdc
[
https://issues.apache.org/jira/browse/HBASE-16682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15520144#comment-15520144
]
Appy commented on HBASE-16682:
--
v3 patch adds the deps to hadoop profiles.
> Fix Shell tests failure. NoClassDefFoundError for MiniKdc
> -
>
> Key: HBASE-16682
> URL: https://issues.apache.org/jira/browse/HBASE-16682
> Project: HBase
> Issue Type: Bug
>Reporter: Appy
>Assignee: Appy
> Attachments: HBASE-16682.master.001.patch,
> HBASE-16682.master.002.patch, HBASE-16682.master.003.patch
>
>
> Stacktrace
> {noformat}
> java.lang.NoClassDefFoundError: org/apache/hadoop/minikdc/MiniKdc
> at java.lang.Class.getDeclaredMethods0(Native Method)
> at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
> at java.lang.Class.getDeclaredMethods(Class.java:1975)
> at org.jruby.javasupport.JavaClass.getMethods(JavaClass.java:2110)
> at org.jruby.javasupport.JavaClass.setupClassMethods(JavaClass.java:955)
> at org.jruby.javasupport.JavaClass.access$700(JavaClass.java:99)
> at
> org.jruby.javasupport.JavaClass$ClassInitializer.initialize(JavaClass.java:650)
> at org.jruby.javasupport.JavaClass.setupProxy(JavaClass.java:689)
> at org.jruby.javasupport.Java.createProxyClass(Java.java:526)
> at org.jruby.javasupport.Java.getProxyClass(Java.java:455)
> at org.jruby.javasupport.Java.getInstance(Java.java:364)
> at
> org.jruby.javasupport.JavaUtil.convertJavaToUsableRubyObject(JavaUtil.java:166)
> at
> org.jruby.javasupport.JavaEmbedUtils.javaToRuby(JavaEmbedUtils.java:291)
> at
> org.jruby.embed.variable.AbstractVariable.updateByJavaObject(AbstractVariable.java:81)
> at
> org.jruby.embed.variable.GlobalVariable.(GlobalVariable.java:69)
> at
> org.jruby.embed.variable.GlobalVariable.getInstance(GlobalVariable.java:60)
> at
> org.jruby.embed.variable.VariableInterceptor.getVariableInstance(VariableInterceptor.java:97)
> at org.jruby.embed.internal.BiVariableMap.put(BiVariableMap.java:321)
> at org.jruby.embed.ScriptingContainer.put(ScriptingContainer.java:1123)
> at
> org.apache.hadoop.hbase.client.AbstractTestShell.setUpBeforeClass(AbstractTestShell.java:61)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:108)
> at
> org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:78)
> at
> org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:54)
> at
> org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:144)
> at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> Caused by: java.lang.ClassNotFoundException: org.apache.hadoop.minikdc.MiniKdc
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at
[jira] [Commented] (HBASE-16682) Fix Shell tests failure. NoClassDefFoundError for MiniKdc
[
https://issues.apache.org/jira/browse/HBASE-16682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15520142#comment-15520142
]
Appy commented on HBASE-16682:
--
That's the thing, none of those 3 modules (shell, rsgroup, thrift) actually use
minikdc.
It's just shell complaining, probably because of some jruby stuff (see the
stack trace).
Scratch the common module part, i mentioned it by mistake.
[~busbey] I don't want to spend hours to dig into jruby to find the reason for
this, mainly because i have a feeling that it'll be of no use and we'll still
end up doing the fix of add deps in hbase-shell/pom.
What do you say?
> Fix Shell tests failure. NoClassDefFoundError for MiniKdc
> -
>
> Key: HBASE-16682
> URL: https://issues.apache.org/jira/browse/HBASE-16682
> Project: HBase
> Issue Type: Bug
>Reporter: Appy
>Assignee: Appy
> Attachments: HBASE-16682.master.001.patch,
> HBASE-16682.master.002.patch, HBASE-16682.master.003.patch
>
>
> Stacktrace
> {noformat}
> java.lang.NoClassDefFoundError: org/apache/hadoop/minikdc/MiniKdc
> at java.lang.Class.getDeclaredMethods0(Native Method)
> at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
> at java.lang.Class.getDeclaredMethods(Class.java:1975)
> at org.jruby.javasupport.JavaClass.getMethods(JavaClass.java:2110)
> at org.jruby.javasupport.JavaClass.setupClassMethods(JavaClass.java:955)
> at org.jruby.javasupport.JavaClass.access$700(JavaClass.java:99)
> at
> org.jruby.javasupport.JavaClass$ClassInitializer.initialize(JavaClass.java:650)
> at org.jruby.javasupport.JavaClass.setupProxy(JavaClass.java:689)
> at org.jruby.javasupport.Java.createProxyClass(Java.java:526)
> at org.jruby.javasupport.Java.getProxyClass(Java.java:455)
> at org.jruby.javasupport.Java.getInstance(Java.java:364)
> at
> org.jruby.javasupport.JavaUtil.convertJavaToUsableRubyObject(JavaUtil.java:166)
> at
> org.jruby.javasupport.JavaEmbedUtils.javaToRuby(JavaEmbedUtils.java:291)
> at
> org.jruby.embed.variable.AbstractVariable.updateByJavaObject(AbstractVariable.java:81)
> at
> org.jruby.embed.variable.GlobalVariable.(GlobalVariable.java:69)
> at
> org.jruby.embed.variable.GlobalVariable.getInstance(GlobalVariable.java:60)
> at
> org.jruby.embed.variable.VariableInterceptor.getVariableInstance(VariableInterceptor.java:97)
> at org.jruby.embed.internal.BiVariableMap.put(BiVariableMap.java:321)
> at org.jruby.embed.ScriptingContainer.put(ScriptingContainer.java:1123)
> at
> org.apache.hadoop.hbase.client.AbstractTestShell.setUpBeforeClass(AbstractTestShell.java:61)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:108)
> at
> org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:78)
> at
> org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:54)
> at
> org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:144)
> at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
> at
>
[jira] [Commented] (HBASE-16667) Building with JDK 8: ignoring option MaxPermSize=256m
[
https://issues.apache.org/jira/browse/HBASE-16667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15520138#comment-15520138
]
Hudson commented on HBASE-16667:
FAILURE: Integrated in Jenkins build HBase-1.3-JDK7 #22 (See
[https://builds.apache.org/job/HBase-1.3-JDK7/22/])
HBASE-16667 Building with JDK 8: ignoring option MaxPermSize=256m (Niels
(jerryjch: rev 2926a665ab75bc8da6c57a65f9c12528cd4ff992)
* (edit) pom.xml
* (edit) hbase-it/pom.xml
> Building with JDK 8: ignoring option MaxPermSize=256m
> -
>
> Key: HBASE-16667
> URL: https://issues.apache.org/jira/browse/HBASE-16667
> Project: HBase
> Issue Type: Improvement
> Components: build
>Reporter: Niels Basjes
>Assignee: Niels Basjes
>Priority: Minor
> Labels: beginner
> Fix For: 2.0.0, 1.3.0, 1.4.0, 1.2.4
>
> Attachments: HBASE-16667-01.patch, HBASE-16667-branch-1-v1.patch,
> HBASE-16667-branch-1-v2.patch, HBASE-16667-v2.patch, HBASE-16667-v3.patch
>
>
> In JDK 8 the permgen was removed.
> As a consequence the build shows this line a lot of times, cluttering the
> output.
> {quote}
> OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support
> was removed in 8.0
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16604) Scanner retries on IOException can cause the scans to miss data
[
https://issues.apache.org/jira/browse/HBASE-16604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15520137#comment-15520137
]
Hudson commented on HBASE-16604:
FAILURE: Integrated in Jenkins build HBase-1.3-JDK7 #22 (See
[https://builds.apache.org/job/HBase-1.3-JDK7/22/])
HBASE-16604 Scanner retries on IOException can cause the scans to miss
(jerryjch: rev 49a4980e6dac1e74275ae5b042b01cd27efc8ebd)
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/DelegatingKeyValueScanner.java
> Scanner retries on IOException can cause the scans to miss data
>
>
> Key: HBASE-16604
> URL: https://issues.apache.org/jira/browse/HBASE-16604
> Project: HBase
> Issue Type: Bug
> Components: regionserver, Scanners
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Fix For: 2.0.0, 1.3.0, 1.4.0, 1.1.7, 1.2.4
>
> Attachments: HBASE-16604-branch-1.3-addendum.patch,
> hbase-16604_v1.patch, hbase-16604_v2.patch, hbase-16604_v3.branch-1.patch,
> hbase-16604_v3.patch
>
>
> Debugging an ITBLL failure, where the Verify did not "see" all the data in
> the cluster, I've noticed that if we end up getting a generic IOException
> from the HFileReader level, we may end up missing the rest of the data in the
> region. I was able to manually test this, and this stack trace helps to
> understand what is going on:
> {code}
> 2016-09-09 16:27:15,633 INFO [hconnection-0x71ad3d8a-shared--pool21-t9]
> client.ScannerCallable(376): Open scanner=1 for
> scan={"loadColumnFamiliesOnDemand":null,"startRow":"","stopRow":"","batch":-1,"cacheBlocks":true,"totalColumns":1,"maxResultSize":2097152,"families":{"testFamily":["testFamily"]},"caching":100,"maxVersions":1,"timeRange":[0,9223372036854775807]}
> on region
> region=testScanThrowsException,,1473463632707.b2adfb618e5d0fe225c1dc40c0eabfee.,
> hostname=hw10676,51833,1473463626529, seqNum=2
> 2016-09-09 16:27:15,634 INFO
> [B.fifo.QRpcServer.handler=5,queue=0,port=51833]
> regionserver.RSRpcServices(2196): scan request:scanner_id: 1 number_of_rows:
> 100 close_scanner: false next_call_seq: 0 client_handles_partials: true
> client_handles_heartbeats: true renew: false
> 2016-09-09 16:27:15,635 INFO
> [B.fifo.QRpcServer.handler=5,queue=0,port=51833]
> regionserver.RSRpcServices(2510): Rolling back next call seqId
> 2016-09-09 16:27:15,635 INFO
> [B.fifo.QRpcServer.handler=5,queue=0,port=51833]
> regionserver.RSRpcServices(2565): Throwing new
> ServiceExceptionjava.io.IOException: Could not reseek
> StoreFileScanner[HFileScanner for reader
> reader=hdfs://localhost:51795/user/enis/test-data/d6fb1c70-93c1-4099-acb7-5723fc05a737/data/default/testScanThrowsException/b2adfb618e5d0fe225c1dc40c0eabfee/testFamily/5a213cc23b714e5e8e1a140ebbe72f2c,
> compression=none, cacheConf=blockCache=LruBlockCache{blockCount=0,
> currentSize=1567264, freeSize=1525578848, maxSize=1527146112,
> heapSize=1567264, minSize=1450788736, minFactor=0.95, multiSize=725394368,
> multiFactor=0.5, singleSize=362697184, singleFactor=0.25},
> cacheDataOnRead=true, cacheDataOnWrite=false, cacheIndexesOnWrite=false,
> cacheBloomsOnWrite=false, cacheEvictOnClose=false, cacheDataCompressed=false,
> prefetchOnOpen=false, firstKey=aaa/testFamily:testFamily/1473463633859/Put,
> lastKey=zzz/testFamily:testFamily/1473463634271/Put, avgKeyLen=35,
> avgValueLen=3, entries=17576, length=866998,
> cur=/testFamily:/OLDEST_TIMESTAMP/Minimum/vlen=0/seqid=0] to key
> /testFamily:testFamily/LATEST_TIMESTAMP/Maximum/vlen=0/seqid=0
> 2016-09-09 16:27:15,635 DEBUG
> [B.fifo.QRpcServer.handler=5,queue=0,port=51833] ipc.CallRunner(110):
> B.fifo.QRpcServer.handler=5,queue=0,port=51833: callId: 26 service:
> ClientService methodName: Scan size: 26 connection: 192.168.42.75:51903
> java.io.IOException: Could not reseek StoreFileScanner[HFileScanner for
> reader
> reader=hdfs://localhost:51795/user/enis/test-data/d6fb1c70-93c1-4099-acb7-5723fc05a737/data/default/testScanThrowsException/b2adfb618e5d0fe225c1dc40c0eabfee/testFamily/5a213cc23b714e5e8e1a140ebbe72f2c,
> compression=none, cacheConf=blockCache=LruBlockCache{blockCount=0,
> currentSize=1567264, freeSize=1525578848, maxSize=1527146112,
> heapSize=1567264, minSize=1450788736, minFactor=0.95, multiSize=725394368,
> multiFactor=0.5, singleSize=362697184, singleFactor=0.25},
> cacheDataOnRead=true, cacheDataOnWrite=false, cacheIndexesOnWrite=false,
> cacheBloomsOnWrite=false, cacheEvictOnClose=false, cacheDataCompressed=false,
> prefetchOnOpen=false, firstKey=aaa/testFamily:testFamily/1473463633859/Put,
> lastKey=zzz/testFamily:testFamily/1473463634271/Put, avgKeyLen=35,
> avgValueLen=3, entries=17576, length=866998,
> cur=/testFamily:/OLDEST_TIMESTAMP/Minimum/vlen=0/seqid=0] to key
>
[jira] [Commented] (HBASE-16704) Scan will broken while work with KeyValueCodecWithTags
[
https://issues.apache.org/jira/browse/HBASE-16704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15520125#comment-15520125
]
Anoop Sam John commented on HBASE-16704:
Found the issue. Patch will be coming today. Thanks for the find and helping to
test.
> Scan will broken while work with KeyValueCodecWithTags
> --
>
> Key: HBASE-16704
> URL: https://issues.apache.org/jira/browse/HBASE-16704
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: Yu Sun
>Assignee: Anoop Sam John
>
> scan will always broken if we set LIMIT more than 1 with rs
> hbase.client.rpc.codec set to
> org.apache.hadoop.hbase.codec.KeyValueCodecWithTags.
> How to reproduce:
> 1. 1 master + 1 rs, codec use KeyValueCodecWithTags.
> 2. create a table table_1024B_30g，1 cf and with only 1 qualifier, then load
> some data with ycsb，
> 3. scan 'table_1024B_30g', {LIMIT => 2, STARTROW => 'user5499'}, STARTROW is
> set any valid start row.
> 4. scan failed.
> this should be bug in KeyValueCodecWithTags, after some investigations, I
> found some the key not serialized correctly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16692) Make ByteBufferUtils#equals more safe and correct
[
https://issues.apache.org/jira/browse/HBASE-16692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15520114#comment-15520114
]
Hadoop QA commented on HBASE-16692:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 14s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 2 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 19s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
55s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 48s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
36s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
21s {color} | {color:green} master passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 0m 32s
{color} | {color:red} hbase-common in master has 1 extant Findbugs warnings.
{color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 39s
{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 8s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
58s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 47s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 47s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
37s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
21s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
24m 9s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green} 0m
20s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
25s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 39s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 38s
{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 79m 9s {color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
25s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 120m 7s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.regionserver.TestHRegionWithInMemoryFlush |
| Timed out junit tests | org.apache.hadoop.hbase.client.TestFromClientSide |
| | org.apache.hadoop.hbase.client.TestScannerTimeout |
| |
org.apache.hadoop.hbase.client.TestRestoreSnapshotFromClientWithRegionReplicas |
| | org.apache.hadoop.hbase.client.TestMobCloneSnapshotFromClient |
| | org.apache.hadoop.hbase.client.TestMobSnapshotCloneIndependence |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.11.2 Server=1.11.2 Image:yetus/hbase:7bda515 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12830211/HBASE-16692-master_v5.patch
|
| JIRA Issue | HBASE-16692 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux 66cb5b864984 3.13.0-92-generic #139-Ubuntu SMP Tue Jun 28
20:42:26 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
[jira] [Updated] (HBASE-16677) Add table size (total store file size) to table page
[ https://issues.apache.org/jira/browse/HBASE-16677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Heng Chen updated HBASE-16677: -- Resolution: Fixed Assignee: Guang Yang Hadoop Flags: Reviewed Fix Version/s: (was: 1.2.4) (was: 1.1.7) (was: 1.3.1) Status: Resolved (was: Patch Available) > Add table size (total store file size) to table page > > > Key: HBASE-16677 > URL: https://issues.apache.org/jira/browse/HBASE-16677 > Project: HBase > Issue Type: New Feature > Components: website >Reporter: Guang Yang >Assignee: Guang Yang >Priority: Minor > Fix For: 2.0.0, 1.4.0 > > Attachments: HBASE-16677_v0.patch, HBASE-16677_v1.patch, > HBASE-16677_v2.patch, HBASE-16677_v3.patch, mini_cluster_master.png, > prod_cluster_partial.png, table_page_v3.png > > > Currently there is not an easy way to get the table size from the web UI, > though we have the region size on the page, it is still convenient to have a > table for the table size stat. > Another pain point is that when the table grow large with tens of thousands > of regions, it took extremely long time to load the page, however, sometimes > we don't want to check all the regions. An optimization could be to accept a > query parameter to specify the number of regions to render. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (HBASE-12894) Upgrade Jetty to 9.2.6
[ https://issues.apache.org/jira/browse/HBASE-12894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guang Yang reassigned HBASE-12894: -- Assignee: Guang Yang > Upgrade Jetty to 9.2.6 > -- > > Key: HBASE-12894 > URL: https://issues.apache.org/jira/browse/HBASE-12894 > Project: HBase > Issue Type: Improvement > Components: REST >Affects Versions: 0.98.0 >Reporter: Rick Hallihan >Assignee: Guang Yang > Labels: MicrosoftSupport > Fix For: 2.0.0 > > > The Jetty component that is used for the HBase Stargate REST endpoint is > version 6.1.26 and is fairly outdated. We recently had a customer inquire > about enabling cross-origin resource sharing (CORS) for the REST endpoint and > found that this older version does not include the necessary filter or > configuration options, highlighted at: > http://wiki.eclipse.org/Jetty/Feature/Cross_Origin_Filter > The Jetty project has had significant updates through versions 7, 8 and 9, > including a transition to be an Eclipse subproject, so updating to the latest > version may be non-trivial. The last update to the Jetty component in > https://issues.apache.org/jira/browse/HBASE-3377 was a minor version update > and did not require significant work. This update will include a package > namespace update so there will likely be a larger number of required changes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16677) Add table size (total store file size) to table page
[ https://issues.apache.org/jira/browse/HBASE-16677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15520071#comment-15520071 ] Guang Yang commented on HBASE-16677: Thanks [~chenheng]. > Add table size (total store file size) to table page > > > Key: HBASE-16677 > URL: https://issues.apache.org/jira/browse/HBASE-16677 > Project: HBase > Issue Type: New Feature > Components: website >Reporter: Guang Yang >Priority: Minor > Fix For: 2.0.0, 1.4.0, 1.3.1, 1.1.7, 1.2.4 > > Attachments: HBASE-16677_v0.patch, HBASE-16677_v1.patch, > HBASE-16677_v2.patch, HBASE-16677_v3.patch, mini_cluster_master.png, > prod_cluster_partial.png, table_page_v3.png > > > Currently there is not an easy way to get the table size from the web UI, > though we have the region size on the page, it is still convenient to have a > table for the table size stat. > Another pain point is that when the table grow large with tens of thousands > of regions, it took extremely long time to load the page, however, sometimes > we don't want to check all the regions. An optimization could be to accept a > query parameter to specify the number of regions to render. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16677) Add table size (total store file size) to table page
[ https://issues.apache.org/jira/browse/HBASE-16677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15520064#comment-15520064 ] Heng Chen commented on HBASE-16677: --- works locally. Push to master and branch-1 > Add table size (total store file size) to table page > > > Key: HBASE-16677 > URL: https://issues.apache.org/jira/browse/HBASE-16677 > Project: HBase > Issue Type: New Feature > Components: website >Reporter: Guang Yang >Priority: Minor > Fix For: 2.0.0, 1.4.0, 1.3.1, 1.1.7, 1.2.4 > > Attachments: HBASE-16677_v0.patch, HBASE-16677_v1.patch, > HBASE-16677_v2.patch, HBASE-16677_v3.patch, mini_cluster_master.png, > prod_cluster_partial.png, table_page_v3.png > > > Currently there is not an easy way to get the table size from the web UI, > though we have the region size on the page, it is still convenient to have a > table for the table size stat. > Another pain point is that when the table grow large with tens of thousands > of regions, it took extremely long time to load the page, however, sometimes > we don't want to check all the regions. An optimization could be to accept a > query parameter to specify the number of regions to render. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16704) Scan will broken while work with KeyValueCodecWithTags
[
https://issues.apache.org/jira/browse/HBASE-16704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yu Sun updated HBASE-16704:
---
Assignee: Anoop Sam John
> Scan will broken while work with KeyValueCodecWithTags
> --
>
> Key: HBASE-16704
> URL: https://issues.apache.org/jira/browse/HBASE-16704
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: Yu Sun
>Assignee: Anoop Sam John
>
> scan will always broken if we set LIMIT more than 1 with rs
> hbase.client.rpc.codec set to
> org.apache.hadoop.hbase.codec.KeyValueCodecWithTags.
> How to reproduce:
> 1. 1 master + 1 rs, codec use KeyValueCodecWithTags.
> 2. create a table table_1024B_30g，1 cf and with only 1 qualifier, then load
> some data with ycsb，
> 3. scan 'table_1024B_30g', {LIMIT => 2, STARTROW => 'user5499'}, STARTROW is
> set any valid start row.
> 4. scan failed.
> this should be bug in KeyValueCodecWithTags, after some investigations, I
> found some the key not serialized correctly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16692) Make ByteBufferUtils#equals more safe and correct
[ https://issues.apache.org/jira/browse/HBASE-16692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15519981#comment-15519981 ] Ted Yu commented on HBASE-16692: +1 on v5 > Make ByteBufferUtils#equals more safe and correct > - > > Key: HBASE-16692 > URL: https://issues.apache.org/jira/browse/HBASE-16692 > Project: HBase > Issue Type: Improvement >Reporter: binlijin >Assignee: binlijin > Fix For: 2.0.0 > > Attachments: HBASE-16692-master.patch, HBASE-16692-master_v2.patch, > HBASE-16692-master_v3.patch, HBASE-16692-master_v4.patch, > HBASE-16692-master_v5.patch > > > ByteBufferUtils.equals(HConstants.EMPTY_BYTE_BUFFER, 0, 0, > HConstants.EMPTY_BYTE_ARRAY, 0, 0) will throw > java.lang.ArrayIndexOutOfBoundsException: -1, i think it should return true. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16667) Building with JDK 8: ignoring option MaxPermSize=256m
[
https://issues.apache.org/jira/browse/HBASE-16667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15519979#comment-15519979
]
Hudson commented on HBASE-16667:
FAILURE: Integrated in Jenkins build HBase-1.4 #430 (See
[https://builds.apache.org/job/HBase-1.4/430/])
HBASE-16667 Building with JDK 8: ignoring option MaxPermSize=256m (Niels
(jerryjch: rev 92b1b5ac80982f7617653ae98a3c3cce1705deb3)
* (edit) pom.xml
* (edit) hbase-it/pom.xml
> Building with JDK 8: ignoring option MaxPermSize=256m
> -
>
> Key: HBASE-16667
> URL: https://issues.apache.org/jira/browse/HBASE-16667
> Project: HBase
> Issue Type: Improvement
> Components: build
>Reporter: Niels Basjes
>Assignee: Niels Basjes
>Priority: Minor
> Labels: beginner
> Fix For: 2.0.0, 1.3.0, 1.4.0, 1.2.4
>
> Attachments: HBASE-16667-01.patch, HBASE-16667-branch-1-v1.patch,
> HBASE-16667-branch-1-v2.patch, HBASE-16667-v2.patch, HBASE-16667-v3.patch
>
>
> In JDK 8 the permgen was removed.
> As a consequence the build shows this line a lot of times, cluttering the
> output.
> {quote}
> OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support
> was removed in 8.0
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (HBASE-16704) Scan will broken while work with KeyValueCodecWithTags
Yu Sun created HBASE-16704:
--
Summary: Scan will broken while work with KeyValueCodecWithTags
Key: HBASE-16704
URL: https://issues.apache.org/jira/browse/HBASE-16704
Project: HBase
Issue Type: Bug
Affects Versions: 2.0.0
Reporter: Yu Sun
scan will always broken if we set LIMIT more than 1 with rs
hbase.client.rpc.codec set to
org.apache.hadoop.hbase.codec.KeyValueCodecWithTags.
How to reproduce:
1. 1 master + 1 rs, codec use KeyValueCodecWithTags.
2. create a table table_1024B_30g，1 cf and with only 1 qualifier, then load
some data with ycsb，
3. scan 'table_1024B_30g', {LIMIT => 2, STARTROW => 'user5499'}, STARTROW is
set any valid start row.
4. scan failed.
this should be bug in KeyValueCodecWithTags, after some investigations, I found
some the key not serialized correctly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-16692) Make ByteBufferUtils#equals more safe and correct
[ https://issues.apache.org/jira/browse/HBASE-16692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] binlijin updated HBASE-16692: - Attachment: HBASE-16692-master_v5.patch > Make ByteBufferUtils#equals more safe and correct > - > > Key: HBASE-16692 > URL: https://issues.apache.org/jira/browse/HBASE-16692 > Project: HBase > Issue Type: Improvement >Reporter: binlijin >Assignee: binlijin > Fix For: 2.0.0 > > Attachments: HBASE-16692-master.patch, HBASE-16692-master_v2.patch, > HBASE-16692-master_v3.patch, HBASE-16692-master_v4.patch, > HBASE-16692-master_v5.patch > > > ByteBufferUtils.equals(HConstants.EMPTY_BYTE_BUFFER, 0, 0, > HConstants.EMPTY_BYTE_ARRAY, 0, 0) will throw > java.lang.ArrayIndexOutOfBoundsException: -1, i think it should return true. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16134) Introduce Cell extension for server side.
[ https://issues.apache.org/jira/browse/HBASE-16134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15519918#comment-15519918 ] stack commented on HBASE-16134: --- Sounds good. In a separate issue let us address tags current circumstance where we have to pass booleans everywhere. How you think it will work when a Cell has system and user tags in it. Will there be filtering out of system tags when we return to client? +1 on current patch. Has a bunch of value aggregating the myriad Interfaces we have server-side all up into one. > Introduce Cell extension for server side. > - > > Key: HBASE-16134 > URL: https://issues.apache.org/jira/browse/HBASE-16134 > Project: HBase > Issue Type: Sub-task > Components: regionserver >Reporter: Anoop Sam John >Assignee: Anoop Sam John > Fix For: 2.0.0 > > Attachments: HBASE-16134.patch, HBASE-16134.patch, > HBASE-16134_V2.patch > > > Came after the discussion under HBASE-15721 and HBASE-15879. > InternalCell is a Cell extension. We do have Cell extensions across different > interfaces now. > SettableSeqId > SettableTimestamp > Streamable. > And demand for this keep growing. > So let us include everything into one Interface. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16657) Expose per-region last major compaction timestamp in RegionServer UI
[ https://issues.apache.org/jira/browse/HBASE-16657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dustin Pho updated HBASE-16657: --- Attachment: with-patch-changes.png > Expose per-region last major compaction timestamp in RegionServer UI > > > Key: HBASE-16657 > URL: https://issues.apache.org/jira/browse/HBASE-16657 > Project: HBase > Issue Type: Improvement > Components: regionserver, UI >Reporter: Gary Helmling >Assignee: Dustin Pho >Priority: Minor > Attachments: HBASE-16657.001.patch, HBASE-16657.002.patch, > with-patch-changes.png, without-patch-changes.png > > > HBASE-12859 added some tracking for the last major compaction completed for > each region. However, this is currently only exposed through the cluster > status reporting and the Admin API. Since the regionserver is already > reporting this information, it would be nice to fold it in somewhere to the > region listing in the regionserver UI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16657) Expose per-region last major compaction timestamp in RegionServer UI
[ https://issues.apache.org/jira/browse/HBASE-16657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dustin Pho updated HBASE-16657: --- Attachment: HBASE-16657.002.patch Changed format of lastMajorCompactionTs to "-MM-dd HH:mm ZZ" > Expose per-region last major compaction timestamp in RegionServer UI > > > Key: HBASE-16657 > URL: https://issues.apache.org/jira/browse/HBASE-16657 > Project: HBase > Issue Type: Improvement > Components: regionserver, UI >Reporter: Gary Helmling >Assignee: Dustin Pho >Priority: Minor > Attachments: HBASE-16657.001.patch, HBASE-16657.002.patch, > without-patch-changes.png > > > HBASE-12859 added some tracking for the last major compaction completed for > each region. However, this is currently only exposed through the cluster > status reporting and the Admin API. Since the regionserver is already > reporting this information, it would be nice to fold it in somewhere to the > region listing in the regionserver UI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16657) Expose per-region last major compaction timestamp in RegionServer UI
[ https://issues.apache.org/jira/browse/HBASE-16657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dustin Pho updated HBASE-16657: --- Attachment: (was: with-patch-changes.png) > Expose per-region last major compaction timestamp in RegionServer UI > > > Key: HBASE-16657 > URL: https://issues.apache.org/jira/browse/HBASE-16657 > Project: HBase > Issue Type: Improvement > Components: regionserver, UI >Reporter: Gary Helmling >Assignee: Dustin Pho >Priority: Minor > Attachments: HBASE-16657.001.patch, HBASE-16657.002.patch, > without-patch-changes.png > > > HBASE-12859 added some tracking for the last major compaction completed for > each region. However, this is currently only exposed through the cluster > status reporting and the Admin API. Since the regionserver is already > reporting this information, it would be nice to fold it in somewhere to the > region listing in the regionserver UI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16665) Check whether KeyValueUtil.createXXX could be replaced by CellUtil without copy
[ https://issues.apache.org/jira/browse/HBASE-16665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15519903#comment-15519903 ] Heng Chen commented on HBASE-16665: --- will commit it if no other concerns. > Check whether KeyValueUtil.createXXX could be replaced by CellUtil without > copy > --- > > Key: HBASE-16665 > URL: https://issues.apache.org/jira/browse/HBASE-16665 > Project: HBase > Issue Type: Bug >Reporter: Heng Chen > Attachments: HBASE-16665.patch, HBASE-16665.v1.patch, > HBASE-16665.v2.patch, HBASE-16665.v3.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16604) Scanner retries on IOException can cause the scans to miss data
[
https://issues.apache.org/jira/browse/HBASE-16604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15519889#comment-15519889
]
Jerry He commented on HBASE-16604:
--
The branch-1.3 commit broke the compilation on branch-1.3.
Committed and attached branch-1.3-addendum.patch.
> Scanner retries on IOException can cause the scans to miss data
>
>
> Key: HBASE-16604
> URL: https://issues.apache.org/jira/browse/HBASE-16604
> Project: HBase
> Issue Type: Bug
> Components: regionserver, Scanners
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Fix For: 2.0.0, 1.3.0, 1.4.0, 1.1.7, 1.2.4
>
> Attachments: HBASE-16604-branch-1.3-addendum.patch,
> hbase-16604_v1.patch, hbase-16604_v2.patch, hbase-16604_v3.branch-1.patch,
> hbase-16604_v3.patch
>
>
> Debugging an ITBLL failure, where the Verify did not "see" all the data in
> the cluster, I've noticed that if we end up getting a generic IOException
> from the HFileReader level, we may end up missing the rest of the data in the
> region. I was able to manually test this, and this stack trace helps to
> understand what is going on:
> {code}
> 2016-09-09 16:27:15,633 INFO [hconnection-0x71ad3d8a-shared--pool21-t9]
> client.ScannerCallable(376): Open scanner=1 for
> scan={"loadColumnFamiliesOnDemand":null,"startRow":"","stopRow":"","batch":-1,"cacheBlocks":true,"totalColumns":1,"maxResultSize":2097152,"families":{"testFamily":["testFamily"]},"caching":100,"maxVersions":1,"timeRange":[0,9223372036854775807]}
> on region
> region=testScanThrowsException,,1473463632707.b2adfb618e5d0fe225c1dc40c0eabfee.,
> hostname=hw10676,51833,1473463626529, seqNum=2
> 2016-09-09 16:27:15,634 INFO
> [B.fifo.QRpcServer.handler=5,queue=0,port=51833]
> regionserver.RSRpcServices(2196): scan request:scanner_id: 1 number_of_rows:
> 100 close_scanner: false next_call_seq: 0 client_handles_partials: true
> client_handles_heartbeats: true renew: false
> 2016-09-09 16:27:15,635 INFO
> [B.fifo.QRpcServer.handler=5,queue=0,port=51833]
> regionserver.RSRpcServices(2510): Rolling back next call seqId
> 2016-09-09 16:27:15,635 INFO
> [B.fifo.QRpcServer.handler=5,queue=0,port=51833]
> regionserver.RSRpcServices(2565): Throwing new
> ServiceExceptionjava.io.IOException: Could not reseek
> StoreFileScanner[HFileScanner for reader
> reader=hdfs://localhost:51795/user/enis/test-data/d6fb1c70-93c1-4099-acb7-5723fc05a737/data/default/testScanThrowsException/b2adfb618e5d0fe225c1dc40c0eabfee/testFamily/5a213cc23b714e5e8e1a140ebbe72f2c,
> compression=none, cacheConf=blockCache=LruBlockCache{blockCount=0,
> currentSize=1567264, freeSize=1525578848, maxSize=1527146112,
> heapSize=1567264, minSize=1450788736, minFactor=0.95, multiSize=725394368,
> multiFactor=0.5, singleSize=362697184, singleFactor=0.25},
> cacheDataOnRead=true, cacheDataOnWrite=false, cacheIndexesOnWrite=false,
> cacheBloomsOnWrite=false, cacheEvictOnClose=false, cacheDataCompressed=false,
> prefetchOnOpen=false, firstKey=aaa/testFamily:testFamily/1473463633859/Put,
> lastKey=zzz/testFamily:testFamily/1473463634271/Put, avgKeyLen=35,
> avgValueLen=3, entries=17576, length=866998,
> cur=/testFamily:/OLDEST_TIMESTAMP/Minimum/vlen=0/seqid=0] to key
> /testFamily:testFamily/LATEST_TIMESTAMP/Maximum/vlen=0/seqid=0
> 2016-09-09 16:27:15,635 DEBUG
> [B.fifo.QRpcServer.handler=5,queue=0,port=51833] ipc.CallRunner(110):
> B.fifo.QRpcServer.handler=5,queue=0,port=51833: callId: 26 service:
> ClientService methodName: Scan size: 26 connection: 192.168.42.75:51903
> java.io.IOException: Could not reseek StoreFileScanner[HFileScanner for
> reader
> reader=hdfs://localhost:51795/user/enis/test-data/d6fb1c70-93c1-4099-acb7-5723fc05a737/data/default/testScanThrowsException/b2adfb618e5d0fe225c1dc40c0eabfee/testFamily/5a213cc23b714e5e8e1a140ebbe72f2c,
> compression=none, cacheConf=blockCache=LruBlockCache{blockCount=0,
> currentSize=1567264, freeSize=1525578848, maxSize=1527146112,
> heapSize=1567264, minSize=1450788736, minFactor=0.95, multiSize=725394368,
> multiFactor=0.5, singleSize=362697184, singleFactor=0.25},
> cacheDataOnRead=true, cacheDataOnWrite=false, cacheIndexesOnWrite=false,
> cacheBloomsOnWrite=false, cacheEvictOnClose=false, cacheDataCompressed=false,
> prefetchOnOpen=false, firstKey=aaa/testFamily:testFamily/1473463633859/Put,
> lastKey=zzz/testFamily:testFamily/1473463634271/Put, avgKeyLen=35,
> avgValueLen=3, entries=17576, length=866998,
> cur=/testFamily:/OLDEST_TIMESTAMP/Minimum/vlen=0/seqid=0] to key
> /testFamily:testFamily/LATEST_TIMESTAMP/Maximum/vlen=0/seqid=0
> at
> org.apache.hadoop.hbase.regionserver.StoreFileScanner.reseek(StoreFileScanner.java:224)
> at
>
[jira] [Updated] (HBASE-16604) Scanner retries on IOException can cause the scans to miss data
[
https://issues.apache.org/jira/browse/HBASE-16604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jerry He updated HBASE-16604:
-
Attachment: HBASE-16604-branch-1.3-addendum.patch
> Scanner retries on IOException can cause the scans to miss data
>
>
> Key: HBASE-16604
> URL: https://issues.apache.org/jira/browse/HBASE-16604
> Project: HBase
> Issue Type: Bug
> Components: regionserver, Scanners
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Fix For: 2.0.0, 1.3.0, 1.4.0, 1.1.7, 1.2.4
>
> Attachments: HBASE-16604-branch-1.3-addendum.patch,
> hbase-16604_v1.patch, hbase-16604_v2.patch, hbase-16604_v3.branch-1.patch,
> hbase-16604_v3.patch
>
>
> Debugging an ITBLL failure, where the Verify did not "see" all the data in
> the cluster, I've noticed that if we end up getting a generic IOException
> from the HFileReader level, we may end up missing the rest of the data in the
> region. I was able to manually test this, and this stack trace helps to
> understand what is going on:
> {code}
> 2016-09-09 16:27:15,633 INFO [hconnection-0x71ad3d8a-shared--pool21-t9]
> client.ScannerCallable(376): Open scanner=1 for
> scan={"loadColumnFamiliesOnDemand":null,"startRow":"","stopRow":"","batch":-1,"cacheBlocks":true,"totalColumns":1,"maxResultSize":2097152,"families":{"testFamily":["testFamily"]},"caching":100,"maxVersions":1,"timeRange":[0,9223372036854775807]}
> on region
> region=testScanThrowsException,,1473463632707.b2adfb618e5d0fe225c1dc40c0eabfee.,
> hostname=hw10676,51833,1473463626529, seqNum=2
> 2016-09-09 16:27:15,634 INFO
> [B.fifo.QRpcServer.handler=5,queue=0,port=51833]
> regionserver.RSRpcServices(2196): scan request:scanner_id: 1 number_of_rows:
> 100 close_scanner: false next_call_seq: 0 client_handles_partials: true
> client_handles_heartbeats: true renew: false
> 2016-09-09 16:27:15,635 INFO
> [B.fifo.QRpcServer.handler=5,queue=0,port=51833]
> regionserver.RSRpcServices(2510): Rolling back next call seqId
> 2016-09-09 16:27:15,635 INFO
> [B.fifo.QRpcServer.handler=5,queue=0,port=51833]
> regionserver.RSRpcServices(2565): Throwing new
> ServiceExceptionjava.io.IOException: Could not reseek
> StoreFileScanner[HFileScanner for reader
> reader=hdfs://localhost:51795/user/enis/test-data/d6fb1c70-93c1-4099-acb7-5723fc05a737/data/default/testScanThrowsException/b2adfb618e5d0fe225c1dc40c0eabfee/testFamily/5a213cc23b714e5e8e1a140ebbe72f2c,
> compression=none, cacheConf=blockCache=LruBlockCache{blockCount=0,
> currentSize=1567264, freeSize=1525578848, maxSize=1527146112,
> heapSize=1567264, minSize=1450788736, minFactor=0.95, multiSize=725394368,
> multiFactor=0.5, singleSize=362697184, singleFactor=0.25},
> cacheDataOnRead=true, cacheDataOnWrite=false, cacheIndexesOnWrite=false,
> cacheBloomsOnWrite=false, cacheEvictOnClose=false, cacheDataCompressed=false,
> prefetchOnOpen=false, firstKey=aaa/testFamily:testFamily/1473463633859/Put,
> lastKey=zzz/testFamily:testFamily/1473463634271/Put, avgKeyLen=35,
> avgValueLen=3, entries=17576, length=866998,
> cur=/testFamily:/OLDEST_TIMESTAMP/Minimum/vlen=0/seqid=0] to key
> /testFamily:testFamily/LATEST_TIMESTAMP/Maximum/vlen=0/seqid=0
> 2016-09-09 16:27:15,635 DEBUG
> [B.fifo.QRpcServer.handler=5,queue=0,port=51833] ipc.CallRunner(110):
> B.fifo.QRpcServer.handler=5,queue=0,port=51833: callId: 26 service:
> ClientService methodName: Scan size: 26 connection: 192.168.42.75:51903
> java.io.IOException: Could not reseek StoreFileScanner[HFileScanner for
> reader
> reader=hdfs://localhost:51795/user/enis/test-data/d6fb1c70-93c1-4099-acb7-5723fc05a737/data/default/testScanThrowsException/b2adfb618e5d0fe225c1dc40c0eabfee/testFamily/5a213cc23b714e5e8e1a140ebbe72f2c,
> compression=none, cacheConf=blockCache=LruBlockCache{blockCount=0,
> currentSize=1567264, freeSize=1525578848, maxSize=1527146112,
> heapSize=1567264, minSize=1450788736, minFactor=0.95, multiSize=725394368,
> multiFactor=0.5, singleSize=362697184, singleFactor=0.25},
> cacheDataOnRead=true, cacheDataOnWrite=false, cacheIndexesOnWrite=false,
> cacheBloomsOnWrite=false, cacheEvictOnClose=false, cacheDataCompressed=false,
> prefetchOnOpen=false, firstKey=aaa/testFamily:testFamily/1473463633859/Put,
> lastKey=zzz/testFamily:testFamily/1473463634271/Put, avgKeyLen=35,
> avgValueLen=3, entries=17576, length=866998,
> cur=/testFamily:/OLDEST_TIMESTAMP/Minimum/vlen=0/seqid=0] to key
> /testFamily:testFamily/LATEST_TIMESTAMP/Maximum/vlen=0/seqid=0
> at
> org.apache.hadoop.hbase.regionserver.StoreFileScanner.reseek(StoreFileScanner.java:224)
> at
> org.apache.hadoop.hbase.regionserver.NonLazyKeyValueScanner.doRealSeek(NonLazyKeyValueScanner.java:55)
> at
>
[jira] [Commented] (HBASE-16661) Add last major compaction age to per-region metrics
[
https://issues.apache.org/jira/browse/HBASE-16661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15519886#comment-15519886
]
Hadoop QA commented on HBASE-16661:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 18s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 2 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 11s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
37s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 7s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
33s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
35s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
42s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 49s
{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 9s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
18s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 10s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 10s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
34s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
38s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
28m 34s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green} 0m
25s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
33s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 42s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 15s
{color} | {color:green} hbase-hadoop-compat in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 18s
{color} | {color:green} hbase-hadoop2-compat in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 92m 32s {color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
38s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 140m 31s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.regionserver.TestHRegionWithInMemoryFlush |
| Timed out junit tests | org.apache.hadoop.hbase.client.TestReplicasClient |
| | org.apache.hadoop.hbase.client.TestTableSnapshotScanner |
| | org.apache.hadoop.hbase.client.TestMobSnapshotCloneIndependence |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.11.2 Server=1.11.2 Image:yetus/hbase:7bda515 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12830206/HBASE-16661.002.patch
|
| JIRA Issue | HBASE-16661 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux 40b57c4db513 3.13.0-92-generic #139-Ubuntu SMP Tue Jun 28
20:42:26 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master /
[jira] [Updated] (HBASE-16667) Building with JDK 8: ignoring option MaxPermSize=256m
[
https://issues.apache.org/jira/browse/HBASE-16667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jerry He updated HBASE-16667:
-
Attachment: HBASE-16667-branch-1-v2.patch
branch-1-v1 is based on master.
Attached branch-1-v2 for branch-1.
> Building with JDK 8: ignoring option MaxPermSize=256m
> -
>
> Key: HBASE-16667
> URL: https://issues.apache.org/jira/browse/HBASE-16667
> Project: HBase
> Issue Type: Improvement
> Components: build
>Reporter: Niels Basjes
>Assignee: Niels Basjes
>Priority: Minor
> Labels: beginner
> Fix For: 2.0.0, 1.3.0, 1.4.0, 1.2.4
>
> Attachments: HBASE-16667-01.patch, HBASE-16667-branch-1-v1.patch,
> HBASE-16667-branch-1-v2.patch, HBASE-16667-v2.patch, HBASE-16667-v3.patch
>
>
> In JDK 8 the permgen was removed.
> As a consequence the build shows this line a lot of times, cluttering the
> output.
> {quote}
> OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support
> was removed in 8.0
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-16667) Building with JDK 8: ignoring option MaxPermSize=256m
[
https://issues.apache.org/jira/browse/HBASE-16667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jerry He updated HBASE-16667:
-
Resolution: Fixed
Hadoop Flags: Reviewed
Status: Resolved (was: Patch Available)
> Building with JDK 8: ignoring option MaxPermSize=256m
> -
>
> Key: HBASE-16667
> URL: https://issues.apache.org/jira/browse/HBASE-16667
> Project: HBase
> Issue Type: Improvement
> Components: build
>Reporter: Niels Basjes
>Assignee: Niels Basjes
>Priority: Minor
> Labels: beginner
> Fix For: 2.0.0, 1.3.0, 1.4.0, 1.2.4
>
> Attachments: HBASE-16667-01.patch, HBASE-16667-branch-1-v1.patch,
> HBASE-16667-branch-1-v2.patch, HBASE-16667-v2.patch, HBASE-16667-v3.patch
>
>
> In JDK 8 the permgen was removed.
> As a consequence the build shows this line a lot of times, cluttering the
> output.
> {quote}
> OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support
> was removed in 8.0
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16667) Building with JDK 8: ignoring option MaxPermSize=256m
[
https://issues.apache.org/jira/browse/HBASE-16667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15519842#comment-15519842
]
Jerry He commented on HBASE-16667:
--
Committed to 1.2+ branches.
> Building with JDK 8: ignoring option MaxPermSize=256m
> -
>
> Key: HBASE-16667
> URL: https://issues.apache.org/jira/browse/HBASE-16667
> Project: HBase
> Issue Type: Improvement
> Components: build
>Reporter: Niels Basjes
>Assignee: Niels Basjes
>Priority: Minor
> Labels: beginner
> Fix For: 2.0.0, 1.3.0, 1.4.0, 1.2.4
>
> Attachments: HBASE-16667-01.patch, HBASE-16667-branch-1-v1.patch,
> HBASE-16667-v2.patch, HBASE-16667-v3.patch
>
>
> In JDK 8 the permgen was removed.
> As a consequence the build shows this line a lot of times, cluttering the
> output.
> {quote}
> OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support
> was removed in 8.0
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16703) Explore object pooling of SeekerState
[ https://issues.apache.org/jira/browse/HBASE-16703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15519758#comment-15519758 ] Andrew Purtell commented on HBASE-16703: There's no reason we can't hold on to earlier allocated SeekerState objects, and their existing byte arrays, since they'll reallocate if needed. A wrinkle is SeekerState is shallow cloned with a wrapper class ClonedSeekerState for use by upper layers. Is that cloning sufficient to protect against reuse of the base SeekerState? I think that is the intent. If insufficient we can still do reference counting of SeekerState objects for deciding when to return them to a shared pool. Also, we can have the pools be thread locals to avoid cross thread synchronization overheads and still get a win on reducing allocations substantially. > Explore object pooling of SeekerState > - > > Key: HBASE-16703 > URL: https://issues.apache.org/jira/browse/HBASE-16703 > Project: HBase > Issue Type: Task >Reporter: Andrew Purtell > > In read workloads 35% of the allocation pressure produced by servicing RPC > requests comes from SeekerState. of the DataBlockEncoder implementation > currently in use, where we allocate two byte arrays of > INITIAL_KEY_BUFFER_SIZE in length. There's an opportunity for object pooling > of SeekerState here. Subsequent code checks if those byte arrays are sized > sufficiently to handle incoming data to copy. The arrays will be resized if > needed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-16703) Explore object pooling of SeekerState
Andrew Purtell created HBASE-16703: -- Summary: Explore object pooling of SeekerState Key: HBASE-16703 URL: https://issues.apache.org/jira/browse/HBASE-16703 Project: HBase Issue Type: Task Reporter: Andrew Purtell In read workloads 35% of the allocation pressure produced by servicing RPC requests comes from SeekerState. of the DataBlockEncoder implementation currently in use, where we allocate two byte arrays of INITIAL_KEY_BUFFER_SIZE in length. There's an opportunity for object pooling of SeekerState here. Subsequent code checks if those byte arrays are sized sufficiently to handle incoming data to copy. The arrays will be resized if needed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16661) Add last major compaction age to per-region metrics
[ https://issues.apache.org/jira/browse/HBASE-16661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dustin Pho updated HBASE-16661: --- Attachment: HBASE-16661.002.patch Logging the IOException in MetricsRegionWrapperImpl#getLastMajorCompactionAge. Also fixed the typo majorCompactioOnly => majorCompactionOnly in HRegion#getOldestHfileTs and Region#getOldestHfileTs. > Add last major compaction age to per-region metrics > --- > > Key: HBASE-16661 > URL: https://issues.apache.org/jira/browse/HBASE-16661 > Project: HBase > Issue Type: Improvement >Reporter: Gary Helmling >Assignee: Dustin Pho >Priority: Minor > Attachments: HBASE-16661.001.patch, HBASE-16661.002.patch > > > After HBASE-12859, we can now track the last major compaction timestamp for > each region. However, this is only exposed through cluster status reporting > and the admin API. > We have similar per-region metrics around storefile age, but none that > filters on major compaction specifically. > Let's add a metric for last major compaction age. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16574) Add backup / restore feature to refguide
[ https://issues.apache.org/jira/browse/HBASE-16574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15519431#comment-15519431 ] Ted Yu commented on HBASE-16574: [~misty]: Mind taking a look (on both format and content) ? Thanks > Add backup / restore feature to refguide > > > Key: HBASE-16574 > URL: https://issues.apache.org/jira/browse/HBASE-16574 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu > Labels: backup > Attachments: Backup-and-Restore-Apache_19Sep2016.pdf, > HBASE-16574.001.patch > > > This issue is to add backup / restore feature description to hbase refguide. > The description should cover: > scenarios where backup / restore is used > backup / restore commands and sample usage > considerations in setup -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16672) Add option for bulk load to always copy hfile(s) instead of renaming
[
https://issues.apache.org/jira/browse/HBASE-16672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15519394#comment-15519394
]
Hadoop QA commented on HBASE-16672:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 16s
{color} | {color:blue} Docker mode activated. {color} |
| {color:blue}0{color} | {color:blue} patch {color} | {color:blue} 0m 2s
{color} | {color:blue} The patch file was not named according to hbase's naming
conventions. Please see
https://yetus.apache.org/documentation/0.3.0/precommit-patchnames for
instructions. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 2 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 7s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
43s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 10s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 7m
7s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
27s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
56s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 46s
{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 8s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
23s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 10s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 1m 10s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 10s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 7m
7s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
27s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
24m 11s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
18s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 46s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 22s
{color} | {color:green} hbase-protocol in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 50s
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 79m 9s {color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
37s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 137m 41s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Timed out junit tests | org.apache.hadoop.hbase.client.TestReplicasClient |
| | org.apache.hadoop.hbase.client.TestFromClientSide |
| | org.apache.hadoop.hbase.regionserver.TestRegionReplicas |
| | org.apache.hadoop.hbase.client.TestIncrementFromClientSideWithCoprocessor
|
| | org.apache.hadoop.hbase.client.TestMobCloneSnapshotFromClient |
| | org.apache.hadoop.hbase.client.TestMobSnapshotCloneIndependence |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.11.2 Server=1.11.2 Image:yetus/hbase:7bda515 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12830191/16672.v10.txt |
| JIRA Issue | HBASE-16672 |
| Optional Tests | asflicense javac
[jira] [Updated] (HBASE-16672) Add option for bulk load to always copy hfile(s) instead of renaming
[ https://issues.apache.org/jira/browse/HBASE-16672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-16672: --- Hadoop Flags: Reviewed Release Note: This issue adds a config, always.copy.files, to LoadIncrementalHFiles. When set to true, source hfiles would be copied. Meaning source hfiles would be kept after bulk load is done. Default value is false. Summary: Add option for bulk load to always copy hfile(s) instead of renaming (was: Add option for bulk load to copy hfile(s) instead of renaming) > Add option for bulk load to always copy hfile(s) instead of renaming > > > Key: HBASE-16672 > URL: https://issues.apache.org/jira/browse/HBASE-16672 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Assignee: Ted Yu > Attachments: 16672.v1.txt, 16672.v10.txt, 16672.v2.txt, 16672.v3.txt, > 16672.v4.txt, 16672.v5.txt, 16672.v6.txt, 16672.v7.txt, 16672.v8.txt, > 16672.v9.txt > > > This is related to HBASE-14417, to support incrementally restoring to > multiple destinations, this issue adds option which would always copy > hfile(s) during bulk load. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16672) Add option for bulk load to copy hfile(s) instead of renaming
[
https://issues.apache.org/jira/browse/HBASE-16672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15519242#comment-15519242
]
Ashish Singhi commented on HBASE-16672:
---
+1 pending QA run.
{code}
/**
536* Create a protocol buffer bulk load request
537*
538* @param familyPaths
539* @param regionName
540* @param assignSeqNum
541* @return a bulk load request
542*/
543 public static BulkLoadHFileRequest buildBulkLoadHFileRequest(
544 final List> familyPaths,
545 final byte[] regionName, boolean assignSeqNum,
546 final Token userToken, final String bulkToken, boolean
copyFiles) {
{code}
Add other params also, can do it on commit if no other review comments also
please add release note to this.
> Add option for bulk load to copy hfile(s) instead of renaming
> -
>
> Key: HBASE-16672
> URL: https://issues.apache.org/jira/browse/HBASE-16672
> Project: HBase
> Issue Type: Improvement
>Reporter: Ted Yu
>Assignee: Ted Yu
> Attachments: 16672.v1.txt, 16672.v10.txt, 16672.v2.txt, 16672.v3.txt,
> 16672.v4.txt, 16672.v5.txt, 16672.v6.txt, 16672.v7.txt, 16672.v8.txt,
> 16672.v9.txt
>
>
> This is related to HBASE-14417, to support incrementally restoring to
> multiple destinations, this issue adds option which would always copy
> hfile(s) during bulk load.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15968) MVCC-sensitive semantics of versions
[
https://issues.apache.org/jira/browse/HBASE-15968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15519229#comment-15519229
]
Phil Yang commented on HBASE-15968:
---
Next I think we need test the performance. But current benchmark framework,
YCSB, may not consider versions. We only put one version in one row. So we can
use normal YCSB to test the performance of new semantics. If there is no Delete
and only one Put in each row. The expected performance is same as old
semantics. And we need extend YCSB to writing more versions with deletes. We
need test some scenes.
And this feature need serial replication, which conflicts with distributed log
replay. So this feature also conflicts with it unless we never need replication
in a cluster.
> MVCC-sensitive semantics of versions
>
>
> Key: HBASE-15968
> URL: https://issues.apache.org/jira/browse/HBASE-15968
> Project: HBase
> Issue Type: New Feature
>Reporter: Phil Yang
>Assignee: Phil Yang
> Attachments: HBASE-15968-v1.patch, HBASE-15968-v2.patch,
> HBASE-15968-v3.patch, HBASE-15968-v4.patch
>
>
> In HBase book, we have a section in Versions called "Current Limitations" see
> http://hbase.apache.org/book.html#_current_limitations
> {quote}
> 28.3. Current Limitations
> 28.3.1. Deletes mask Puts
> Deletes mask puts, even puts that happened after the delete was entered. See
> HBASE-2256. Remember that a delete writes a tombstone, which only disappears
> after then next major compaction has run. Suppose you do a delete of
> everything ⇐ T. After this you do a new put with a timestamp ⇐ T. This put,
> even if it happened after the delete, will be masked by the delete tombstone.
> Performing the put will not fail, but when you do a get you will notice the
> put did have no effect. It will start working again after the major
> compaction has run. These issues should not be a problem if you use
> always-increasing versions for new puts to a row. But they can occur even if
> you do not care about time: just do delete and put immediately after each
> other, and there is some chance they happen within the same millisecond.
> 28.3.2. Major compactions change query results
> …create three cell versions at t1, t2 and t3, with a maximum-versions
> setting of 2. So when getting all versions, only the values at t2 and t3 will
> be returned. But if you delete the version at t2 or t3, the one at t1 will
> appear again. Obviously, once a major compaction has run, such behavior will
> not be the case anymore… (See Garbage Collection in Bending time in HBase.)
> {quote}
> These limitations result from the current implementation on multi-versions:
> we only consider timestamp, no matter when it comes; we will not remove old
> version immediately if there are enough number of new versions.
> So we can get a stronger semantics of versions by two guarantees:
> 1, Delete will not mask Put that comes after it.
> 2, If a version is masked by enough number of higher versions (VERSIONS in
> cf's conf), it will never be seen any more.
> Some examples for understanding:
> (delete t<=3 means use Delete.addColumns to delete all versions whose ts is
> not greater than 3, and delete t3 means use Delete.addColumn to delete the
> version whose ts=3)
> case 1: put t2 -> put t3 -> delete t<=3 -> put t1, and we will get t1 because
> the put is after delete.
> case 2: maxversion=2, put t1 -> put t2 -> put t3 -> delete t3, and we will
> always get t2 no matter if there is a major compaction, because t1 is masked
> when we put t3 so t1 will never be seen.
> case 3: maxversion=2, put t1 -> put t2 -> put t3 -> delete t2 -> delete t3,
> and we will get nothing.
> case 4: maxversion=3, put t1 -> put t2 -> put t3 -> delete t2 -> delete t3,
> and we will get t1 because it is not masked.
> case 5: maxversion=2, put t1 -> put t2 -> put t3 -> delete t3 -> put t1, and
> we can get t3+t1 because when we put t1 at second time it is the 2nd latest
> version and it can be read.
> case 6:maxversion=2, put t3->put t2->put t1, and we will get t3+t2 just like
> what we can get now, ts is still the key of versions.
> Different VERSIONS may result in different results even the size of result is
> smaller than VERSIONS(see case 3 and 4). So Get/Scan.setMaxVersions will be
> handled at end after we read correct data according to CF's VERSIONS setting.
> The semantics is different from the current HBase, and we may need more logic
> to support the new semantic, so it is configurable and default is disabled.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-16672) Add option for bulk load to copy hfile(s) instead of renaming
[ https://issues.apache.org/jira/browse/HBASE-16672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-16672: --- Attachment: 16672.v10.txt Patch v10 adds a test which asserts that the original file exists if the flag is specified. > Add option for bulk load to copy hfile(s) instead of renaming > - > > Key: HBASE-16672 > URL: https://issues.apache.org/jira/browse/HBASE-16672 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Assignee: Ted Yu > Attachments: 16672.v1.txt, 16672.v10.txt, 16672.v2.txt, 16672.v3.txt, > 16672.v4.txt, 16672.v5.txt, 16672.v6.txt, 16672.v7.txt, 16672.v8.txt, > 16672.v9.txt > > > This is related to HBASE-14417, to support incrementally restoring to > multiple destinations, this issue adds option which would always copy > hfile(s) during bulk load. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16672) Add option for bulk load to copy hfile(s) instead of renaming
[ https://issues.apache.org/jira/browse/HBASE-16672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-16672: --- Attachment: 16672.v9.txt Fixed in patch v9. > Add option for bulk load to copy hfile(s) instead of renaming > - > > Key: HBASE-16672 > URL: https://issues.apache.org/jira/browse/HBASE-16672 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Assignee: Ted Yu > Attachments: 16672.v1.txt, 16672.v2.txt, 16672.v3.txt, 16672.v4.txt, > 16672.v5.txt, 16672.v6.txt, 16672.v7.txt, 16672.v8.txt, 16672.v9.txt > > > This is related to HBASE-14417, to support incrementally restoring to > multiple destinations, this issue adds option which would always copy > hfile(s) during bulk load. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16672) Add option for bulk load to copy hfile(s) instead of renaming
[
https://issues.apache.org/jira/browse/HBASE-16672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15519123#comment-15519123
]
Ashish Singhi commented on HBASE-16672:
---
{code}
+finalPath = bulkLoadListener.prepareBulkLoad(familyName, path,
copyFile);
+copyFile = false;
{code}
Why we are changing the value of copyFile here ? If it was true then we set
here to false so the next file in the for loop will not be copied, correct ?
> Add option for bulk load to copy hfile(s) instead of renaming
> -
>
> Key: HBASE-16672
> URL: https://issues.apache.org/jira/browse/HBASE-16672
> Project: HBase
> Issue Type: Improvement
>Reporter: Ted Yu
>Assignee: Ted Yu
> Attachments: 16672.v1.txt, 16672.v2.txt, 16672.v3.txt, 16672.v4.txt,
> 16672.v5.txt, 16672.v6.txt, 16672.v7.txt, 16672.v8.txt
>
>
> This is related to HBASE-14417, to support incrementally restoring to
> multiple destinations, this issue adds option which would always copy
> hfile(s) during bulk load.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16134) Introduce Cell extension for server side.
[ https://issues.apache.org/jira/browse/HBASE-16134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15518793#comment-15518793 ] Anoop Sam John commented on HBASE-16134: Coming back to this. The Codec based strip of tags was done as a temp solution not to pass the critical system tags from server back to client. This also imposes the limitation that Tags can not be used by users. Tags are a system side feature alone. In the past there were some Qs in user@ for using custom tags. Now before 2.0 release we should fix this. We should allow users to set tags on Cell and pass them while write. Also these custom tags must be returned back to users (Irrespective of codec and all). The system tags (like ACL, visibility) should not get transferred btw client and server. And when the client is run by a super user, we should pass all tags (including system tags). This way we can make sure that all tags are passed while replication and also tool like Export gets all tags. I have some idea on this and plan to do this sooner. Now for this issue as such, pls let me add write API with boolean param withTags. The KVCodec will pass false and KVCodecWithTags will pass true. Once the tag related IA is done, we can get rid of this boolean. How is that [~saint@gmail.com]? Will post a new patch soon. > Introduce Cell extension for server side. > - > > Key: HBASE-16134 > URL: https://issues.apache.org/jira/browse/HBASE-16134 > Project: HBase > Issue Type: Sub-task > Components: regionserver >Reporter: Anoop Sam John >Assignee: Anoop Sam John > Fix For: 2.0.0 > > Attachments: HBASE-16134.patch, HBASE-16134.patch, > HBASE-16134_V2.patch > > > Came after the discussion under HBASE-15721 and HBASE-15879. > InternalCell is a Cell extension. We do have Cell extensions across different > interfaces now. > SettableSeqId > SettableTimestamp > Streamable. > And demand for this keep growing. > So let us include everything into one Interface. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
