[jira] [Commented] (HBASE-18517) limit max log message width in log4j
[
https://issues.apache.org/jira/browse/HBASE-18517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115671#comment-16115671
]
Hadoop QA commented on HBASE-18517:
---
| (/) *{color:green}+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} 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}
33m 20s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
13s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 34m 0s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:bdc94b1 |
| JIRA Issue | HBASE-18517 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12880548/HBASE-18517.master.001.patch
|
| Optional Tests | asflicense |
| uname | Linux 056d807a4a39 3.13.0-119-generic #166-Ubuntu SMP Wed May 3
12:18:55 UTC 2017 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 / 637f7ab |
| modules | C: . U: . |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/7948/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
This message was automatically generated.
> limit max log message width in log4j
>
>
> Key: HBASE-18517
> URL: https://issues.apache.org/jira/browse/HBASE-18517
> Project: HBase
> Issue Type: Bug
>Affects Versions: 3.0.0, 1.5.0
>Reporter: Vikas Vishwakarma
>Assignee: Vikas Vishwakarma
> Fix For: 3.0.0, 1.5.0
>
> Attachments: HBASE-18517.branch-1.001.patch,
> HBASE-18517.master.001.patch
>
>
> We had two cases now in our prod / pilot setups which is leading to humongous
> log lines in RegionServer logs.
> In first case, one of the phoenix user had constructed a query with a really
> large list of Id filters (61 MB) that translated into HBase scan that was
> running slow which lead to responseTooSlow messages in the logs with the
> entire filter list being printed in the logs, example
> ipc.RpcServer - (responseTooSlow):
> {"call":"Scan(org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ScanRequest)","starttimems":1501457864417,"responsesize":11,"method":"Scan","param":"region
> { type: REGION_NAME value: .
> org.apache.hadoop.hbase.filter.FirstKeyOnlyFilter\\022\351\\200\\036\\n(org.apache.phoenix.filter.SkipScanFilter
> ... ...
> There was another case where a use case had created a table with really large
> key/region names. This was causing humongous log lines for flush and
> compaction on these regions filling up the RS logs
> These large logs usually cause issues with disk I/O load, loading the splunk
> servers, even machine perf degradations. With 61 MB log lines basic log
> processing commands like vim, scrolling the logs, wc -l , etc were getting
> stuck. High GC activity was also noted on this cluster although not 100% sure
> if it was related to above issue.
> We should consider limiting the message size in logs which can be easily done
> by adding a maximum width format modifier on the message conversion character
> in log4j.properties
> log4j.appender.console.layout.ConversionPattern=...: %m%n
> to
> log4j.appender.console.layout.ConversionPattern=...: %.1m%n
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18525) TestAssignmentManager#testSocketTimeout fails in master branch
[
https://issues.apache.org/jira/browse/HBASE-18525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115670#comment-16115670
]
Umesh Agashe commented on HBASE-18525:
--
Hi [~tedyu],
I think with current code UnassignProcedure is expected to fail and in short
term the test can be changed accordingly.
The test instantiates SocketTimeoutRsExecutor with maxServerRetries of 3. In
case of AssignProcedure retries are determined by
AssignmentManager.getAssignMaxAttempts() but in case of UnassignProcedure on
first failure procedure is determined to be failed. Long term fix is to have
max attempts for unassign operation like assign.
Pre HBASE-18491, we just assumed that when communication fails with RS,
ServerCrashProcedure will take care of reassigning region and unaasign region
operation can be considered successful. The assumption is a cause of the
failure of other test re-enabled in HBASE-18491.
Let me know your thoughts.
Thanks, Umesh
> TestAssignmentManager#testSocketTimeout fails in master branch
> --
>
> Key: HBASE-18525
> URL: https://issues.apache.org/jira/browse/HBASE-18525
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Attachments: 18525.v1.txt
>
>
> Toward the end of the test output, I saw:
> {code}
> 2017-08-05 03:30:16,591 INFO [Time-limited test]
> assignment.TestAssignmentManager(446): ExecutionException
> java.util.concurrent.ExecutionException:
> org.apache.hadoop.hbase.master.procedure.ServerCrashException:
> ServerCrashProcedure pid=3, server=localhost,103,1
> at
> org.apache.hadoop.hbase.master.procedure.ProcedureSyncWait$ProcedureFuture.get(ProcedureSyncWait.java:104)
> at
> org.apache.hadoop.hbase.master.procedure.ProcedureSyncWait$ProcedureFuture.get(ProcedureSyncWait.java:62)
> at
> org.apache.hadoop.hbase.master.assignment.TestAssignmentManager.waitOnFuture(TestAssignmentManager.java:444)
> at
> org.apache.hadoop.hbase.master.assignment.TestAssignmentManager.testSocketTimeout(TestAssignmentManager.java:255)
> 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.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at
> org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:298)
> at
> org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:292)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.hadoop.hbase.master.procedure.ServerCrashException:
> ServerCrashProcedure pid=3, server=localhost,103,1
> at
> org.apache.hadoop.hbase.master.assignment.UnassignProcedure.updateTransition(UnassignProcedure.java:169)
> at
> org.apache.hadoop.hbase.master.assignment.RegionTransitionProcedure.execute(RegionTransitionProcedure.java:274)
> at
> org.apache.hadoop.hbase.master.assignment.RegionTransitionProcedure.execute(RegionTransitionProcedure.java:57)
> at
> org.apache.hadoop.hbase.procedure2.Procedure.doExecute(Procedure.java:847)
> at
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor.execProcedure(ProcedureExecutor.java:1440)
> at
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor.executeProcedure(ProcedureExecutor.java:1209)
> at
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor.access$800(ProcedureExecutor.java:79)
> at
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor$WorkerThread.run(ProcedureExecutor.java:1719)
> {code}
> This test failure seems to happen after HBASE-18491 was checked in.
> Looking at the change in UnassignProcedure, it seems we should handle the two
> conditions differently:
> {code}
> if (serverCrashed.get() || !isServerOnline(env, regionNode)) {
> {code}
> With attached patch, TestAssignmentManager#testSocketTimeout and
> TestServerCrashProcedure#testRecoveryAndDoubleExecutionOnRsWithMeta pass.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (HBASE-18502) Change MasterObserver to use TableDescriptor and ColumnFamilyDescriptor
[ https://issues.apache.org/jira/browse/HBASE-18502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115663#comment-16115663 ] Ted Yu edited comment on HBASE-18502 at 8/6/17 6:37 AM: lgtm Looked at hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/package-info.java which doesn't need to be modified was (Author: yuzhih...@gmail.com): lgtm Please cover hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/package-info.java as well > Change MasterObserver to use TableDescriptor and ColumnFamilyDescriptor > --- > > Key: HBASE-18502 > URL: https://issues.apache.org/jira/browse/HBASE-18502 > Project: HBase > Issue Type: Sub-task >Reporter: Chia-Ping Tsai >Assignee: Chia-Ping Tsai >Priority: Critical > Fix For: 3.0.0, 2.0.0-alpha-2 > > Attachments: HBASE-18502.v0.patch, HBASE-18502.v1.patch, > HBASE-18502.v1.patch > > > MasterObserver is IA.COPROC so we can make some Incompatible change for 3.0 > and 2.0 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18502) Change MasterObserver to use TableDescriptor and ColumnFamilyDescriptor
[ https://issues.apache.org/jira/browse/HBASE-18502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115663#comment-16115663 ] Ted Yu commented on HBASE-18502: lgtm Please cover hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/package-info.java as well > Change MasterObserver to use TableDescriptor and ColumnFamilyDescriptor > --- > > Key: HBASE-18502 > URL: https://issues.apache.org/jira/browse/HBASE-18502 > Project: HBase > Issue Type: Sub-task >Reporter: Chia-Ping Tsai >Assignee: Chia-Ping Tsai >Priority: Critical > Fix For: 3.0.0, 2.0.0-alpha-2 > > Attachments: HBASE-18502.v0.patch, HBASE-18502.v1.patch, > HBASE-18502.v1.patch > > > MasterObserver is IA.COPROC so we can make some Incompatible change for 3.0 > and 2.0 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18296) NPE in ProcedureExecutor.removeChore
[
https://issues.apache.org/jira/browse/HBASE-18296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115661#comment-16115661
]
Ping Liu commented on HBASE-18296:
--
[~mdrob]
Do you remember which test it is where you found this error? There are many
places where HRegionServer starts up. It'll be great if the specific test can
be identified.
> NPE in ProcedureExecutor.removeChore
>
>
> Key: HBASE-18296
> URL: https://issues.apache.org/jira/browse/HBASE-18296
> Project: HBase
> Issue Type: Bug
> Components: proc-v2
>Affects Versions: 2.0.0-alpha-1
>Reporter: Mike Drob
>
> Saw this in logs while debugging other failing tests:
> {noformat}
> 2017-06-29 13:54:15,995 ERROR [M:0;172.18.16.40:55484]
> server.NIOServerCnxnFactory$1(44): Thread
> Thread[M:0;172.18.16.40:55484,5,FailOnTimeoutGroup] died
> java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor.removeChore(ProcedureExecutor.java:656)
> at
> org.apache.hadoop.hbase.master.assignment.AssignmentManager.stop(AssignmentManager.java:233)
> at
> org.apache.hadoop.hbase.master.HMaster.stopServiceThreads(HMaster.java:1154)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.run(HRegionServer.java:1189)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> I think it was related to an initialization failure, but we should code more
> defensively anyway
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18520) Add jmx value to determine true Master Start time
[ https://issues.apache.org/jira/browse/HBASE-18520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-18520: --- Resolution: Fixed Hadoop Flags: Reviewed Fix Version/s: 2.0.0-alpha-2 1.4.0 3.0.0 Status: Resolved (was: Patch Available) Adjusted the subject of the patch by adding JIRA number and aligning description with JIRA title. > Add jmx value to determine true Master Start time > - > > Key: HBASE-18520 > URL: https://issues.apache.org/jira/browse/HBASE-18520 > Project: HBase > Issue Type: Bug > Components: metrics >Reporter: Zach York >Assignee: Zach York >Priority: Minor > Fix For: 3.0.0, 1.4.0, 2.0.0-alpha-2 > > Attachments: HBASE-18520.branch-1.001.patch, > HBASE-18520.branch-1.002.patch, HBASE-18520.master.001.patch, > HBASE-18520.master.002.patch, HBASE-18520.master.003.patch > > > The masterActiveTime is being set before regions are assigned. This patch > adds a new jmx metric to expose the final time when the master has become the > active master (All regions are assigned, etc.). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18517) limit max log message width in log4j
[
https://issues.apache.org/jira/browse/HBASE-18517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Vishwakarma updated HBASE-18517:
--
Attachment: (was: HBASE-18374.master.001.patch)
> limit max log message width in log4j
>
>
> Key: HBASE-18517
> URL: https://issues.apache.org/jira/browse/HBASE-18517
> Project: HBase
> Issue Type: Bug
>Affects Versions: 3.0.0, 1.5.0
>Reporter: Vikas Vishwakarma
>Assignee: Vikas Vishwakarma
> Fix For: 3.0.0, 1.5.0
>
> Attachments: HBASE-18517.branch-1.001.patch,
> HBASE-18517.master.001.patch
>
>
> We had two cases now in our prod / pilot setups which is leading to humongous
> log lines in RegionServer logs.
> In first case, one of the phoenix user had constructed a query with a really
> large list of Id filters (61 MB) that translated into HBase scan that was
> running slow which lead to responseTooSlow messages in the logs with the
> entire filter list being printed in the logs, example
> ipc.RpcServer - (responseTooSlow):
> {"call":"Scan(org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ScanRequest)","starttimems":1501457864417,"responsesize":11,"method":"Scan","param":"region
> { type: REGION_NAME value: .
> org.apache.hadoop.hbase.filter.FirstKeyOnlyFilter\\022\351\\200\\036\\n(org.apache.phoenix.filter.SkipScanFilter
> ... ...
> There was another case where a use case had created a table with really large
> key/region names. This was causing humongous log lines for flush and
> compaction on these regions filling up the RS logs
> These large logs usually cause issues with disk I/O load, loading the splunk
> servers, even machine perf degradations. With 61 MB log lines basic log
> processing commands like vim, scrolling the logs, wc -l , etc were getting
> stuck. High GC activity was also noted on this cluster although not 100% sure
> if it was related to above issue.
> We should consider limiting the message size in logs which can be easily done
> by adding a maximum width format modifier on the message conversion character
> in log4j.properties
> log4j.appender.console.layout.ConversionPattern=...: %m%n
> to
> log4j.appender.console.layout.ConversionPattern=...: %.1m%n
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18517) limit max log message width in log4j
[
https://issues.apache.org/jira/browse/HBASE-18517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Vishwakarma updated HBASE-18517:
--
Attachment: HBASE-18517.master.001.patch
> limit max log message width in log4j
>
>
> Key: HBASE-18517
> URL: https://issues.apache.org/jira/browse/HBASE-18517
> Project: HBase
> Issue Type: Bug
>Affects Versions: 3.0.0, 1.5.0
>Reporter: Vikas Vishwakarma
>Assignee: Vikas Vishwakarma
> Fix For: 3.0.0, 1.5.0
>
> Attachments: HBASE-18517.branch-1.001.patch,
> HBASE-18517.master.001.patch
>
>
> We had two cases now in our prod / pilot setups which is leading to humongous
> log lines in RegionServer logs.
> In first case, one of the phoenix user had constructed a query with a really
> large list of Id filters (61 MB) that translated into HBase scan that was
> running slow which lead to responseTooSlow messages in the logs with the
> entire filter list being printed in the logs, example
> ipc.RpcServer - (responseTooSlow):
> {"call":"Scan(org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ScanRequest)","starttimems":1501457864417,"responsesize":11,"method":"Scan","param":"region
> { type: REGION_NAME value: .
> org.apache.hadoop.hbase.filter.FirstKeyOnlyFilter\\022\351\\200\\036\\n(org.apache.phoenix.filter.SkipScanFilter
> ... ...
> There was another case where a use case had created a table with really large
> key/region names. This was causing humongous log lines for flush and
> compaction on these regions filling up the RS logs
> These large logs usually cause issues with disk I/O load, loading the splunk
> servers, even machine perf degradations. With 61 MB log lines basic log
> processing commands like vim, scrolling the logs, wc -l , etc were getting
> stuck. High GC activity was also noted on this cluster although not 100% sure
> if it was related to above issue.
> We should consider limiting the message size in logs which can be easily done
> by adding a maximum width format modifier on the message conversion character
> in log4j.properties
> log4j.appender.console.layout.ConversionPattern=...: %m%n
> to
> log4j.appender.console.layout.ConversionPattern=...: %.1m%n
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18368) FilterList with multiple FamilyFilters concatenated by OR does not work.
[
https://issues.apache.org/jira/browse/HBASE-18368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115650#comment-16115650
]
Ted Yu commented on HBASE-18368:
[~allan163]:
Do you have time to resume the work here ?
> FilterList with multiple FamilyFilters concatenated by OR does not work.
>
>
> Key: HBASE-18368
> URL: https://issues.apache.org/jira/browse/HBASE-18368
> Project: HBase
> Issue Type: Sub-task
> Components: Filters
>Affects Versions: 3.0.0, 2.0.0-alpha-1
>Reporter: Peter Somogyi
>Assignee: Allan Yang
>Priority: Critical
> Attachments: HBASE-18368.branch-1.patch,
> HBASE-18368.branch-1.v2.patch, HBASE-18368.branch-1.v3.patch,
> HBASE-18368.patch
>
>
> Scan gives back incomplete list if multiple filters are combined with OR /
> MUST_PASS_ONE.
> Using 2 FamilyFilters in a FilterList using MUST_PASS_ONE operator will give
> back results for only the first Filter.
> {code:java|title=Test code}
> @Test
> public void testFiltersWithOr() throws Exception {
> TableName tn = TableName.valueOf("MyTest");
> Table table = utility.createTable(tn, new String[] {"cf1", "cf2"});
> byte[] CF1 = Bytes.toBytes("cf1");
> byte[] CF2 = Bytes.toBytes("cf2");
> Put put1 = new Put(Bytes.toBytes("0"));
> put1.addColumn(CF1, Bytes.toBytes("col_a"), Bytes.toBytes(0));
> table.put(put1);
> Put put2 = new Put(Bytes.toBytes("0"));
> put2.addColumn(CF2, Bytes.toBytes("col_b"), Bytes.toBytes(0));
> table.put(put2);
> FamilyFilter filterCF1 = new FamilyFilter(CompareFilter.CompareOp.EQUAL,
> new BinaryComparator(CF1));
> FamilyFilter filterCF2 = new FamilyFilter(CompareFilter.CompareOp.EQUAL,
> new BinaryComparator(CF2));
> FilterList filterList = new FilterList(FilterList.Operator.MUST_PASS_ONE);
> filterList.addFilter(filterCF1);
> filterList.addFilter(filterCF2);
> Scan scan = new Scan();
> scan.setFilter(filterList);
> ResultScanner scanner = table.getScanner(scan);
> System.out.println(filterList);
> for (Result rr = scanner.next(); rr != null; rr = scanner.next()) {
> System.out.println(rr);
> }
> }
> {code}
> {noformat:title=Output}
> FilterList OR (2/2): [FamilyFilter (EQUAL, cf1), FamilyFilter (EQUAL, cf2)]
> keyvalues={0/cf1:col_a/1499852754957/Put/vlen=4/seqid=0}
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18518) Remove jersey1* dependencies from project and jersey1* jars from lib dir
[ https://issues.apache.org/jira/browse/HBASE-18518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-18518: --- Summary: Remove jersey1* dependencies from project and jersey1* jars from lib dir (was: Remove jersey1* dependencies form project and jersey1* jars from lib dir) > Remove jersey1* dependencies from project and jersey1* jars from lib dir > > > Key: HBASE-18518 > URL: https://issues.apache.org/jira/browse/HBASE-18518 > Project: HBase > Issue Type: Task > Components: dependencies, pom, REST >Affects Versions: 3.0.0, 2.0.0-alpha-1 >Reporter: Samir Ahmic >Assignee: Samir Ahmic > Labels: cleanup > Fix For: 3.0.0 > > Attachments: HBASE-18518-master-01.patch > > > Recently i have opened https://issues.apache.org/jira/browse/HBASE-18506 and > it is clear that is caused by mixing jersey1 and jersey2 jars in classpath. > With https://issues.apache.org/jira/browse/HBASE-12894 we have introduced > jersey2 to project, and we also have bunch of transitive dependencies > (mainly from hadoop) on jersey1 which is not happiest situation since jersey1 > and jersey2 under same classpath can case runtime issues as it was case with > rest. > This task will have following steps > * Clean code and replace jersey1 constructs with jersey2 versions(there > should not be much of this) > * Add exclusions for transitive jersey1 dependencies in pom.xml > * Add exclusions in hadoop-two-compat.xml to prevent jersey1 jars in lib dir -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18426) nightly job should use independent stages to check supported jdks
[
https://issues.apache.org/jira/browse/HBASE-18426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115647#comment-16115647
]
Ted Yu commented on HBASE-18426:
lgtm
nit:
{code}
ARCHIVE_PATTERN_LIST =
'TEST-*.xml,org.apache.h*-output.txt,org.apache.h*.txt'
{code}
Wouldn't org.apache.h*.txt cover org.apache.h*-output ?
> nightly job should use independent stages to check supported jdks
> -
>
> Key: HBASE-18426
> URL: https://issues.apache.org/jira/browse/HBASE-18426
> Project: HBase
> Issue Type: Improvement
> Components: community, test
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Critical
> Attachments: HBASE-18426.0.patch
>
>
> follow on from HBASE-18147 to handle the lack of multijdk support for unit
> tests.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-16290) Dump summary of callQueue content; can help debugging
[
https://issues.apache.org/jira/browse/HBASE-16290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115586#comment-16115586
]
Hadoop QA commented on HBASE-16290:
---
| (/) *{color:green}+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: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:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
47s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
43s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
50s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
18s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
21s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
32s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
49s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
42s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
42s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
49s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
19s{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}
32m 48s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
8s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
28s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}107m
26s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
17s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}156m 52s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:bdc94b1 |
| JIRA Issue | HBASE-16290 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12880333/OldPatch-0001-Dump-Call-Queue-Summary.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux cd5fa0140751 3.13.0-119-generic #166-Ubuntu SMP Wed May 3
12:18:55 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build@2/component/dev-support/hbase-personality.sh
|
| git revision | master / 7da4750 |
| Default Java | 1.8.0_131 |
| findbugs | v3.1.0-RC3 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/7947/testReport/ |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/7947/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
This message was automatically generated.
> Dump summary of callQueue content; can help debugging
> -
>
> Key: HBASE-16290
> URL: https://issues.apache.org/jira/browse/HBASE-16290
> Project: HBase
> Issue Type: Bug
> Components: Operability
>Affects Versions: 2.0.0
>Reporter: stack
>Assignee: Sreeram Venkatasubramanian
>Priority:
[jira] [Commented] (HBASE-18142) Deletion of a cell deletes the previous versions too
[
https://issues.apache.org/jira/browse/HBASE-18142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115556#comment-16115556
]
Hadoop QA commented on HBASE-18142:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
17s{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 1 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
46s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
19s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
9s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
16s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
17s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} rubocop {color} | {color:red} 0m
12s{color} | {color:red} The patch generated 4 new + 336 unchanged - 129 fixed
= 340 total (was 465) {color} |
| {color:green}+1{color} | {color:green} ruby-lint {color} | {color:green} 0m
12s{color} | {color:green} There were no new ruby-lint issues. {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m
0s{color} | {color:red} The patch 2 line(s) with tabs. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
33m 31s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
19s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
50s{color} | {color:green} hbase-shell in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
7s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 40m 37s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:bdc94b1 |
| JIRA Issue | HBASE-18142 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12880538/HBASE-18142.master.v6.patch
|
| Optional Tests | asflicense javac javadoc unit rubocop ruby_lint |
| uname | Linux 59cf1219ae3d 3.13.0-119-generic #166-Ubuntu SMP Wed May 3
12:18:55 UTC 2017 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 / 7da4750 |
| Default Java | 1.8.0_131 |
| rubocop | v0.49.1 |
| rubocop |
https://builds.apache.org/job/PreCommit-HBASE-Build/7946/artifact/patchprocess/diff-patch-rubocop.txt
|
| ruby-lint | v2.3.1 |
| whitespace |
https://builds.apache.org/job/PreCommit-HBASE-Build/7946/artifact/patchprocess/whitespace-tabs.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/7946/testReport/ |
| modules | C: hbase-shell U: hbase-shell |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/7946/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
This message was automatically generated.
> Deletion of a cell deletes the previous versions too
>
>
> Key: HBASE-18142
> URL: https://issues.apache.org/jira/browse/HBASE-18142
> Project: HBase
> Issue Type: Bug
> Components: API, shell
>Affects Versions: 3.0.0
>Reporter: Karthick
>Assignee: ChunHao
> Labels: beginner
> Fix For: 3.0.0, 2.0.0-alpha-2
>
> Attachments: HBASE-18142.master.v0.patch,
> HBASE-18142.master.v1.patch, HBASE-18142.master.v2.patch,
> HBASE-18142.master.v3.patch, HBASE-18142.master.v4.patch,
> HBASE-18142.master.v5.patch, HBASE-18142.master.v6.patch
>
>
> When I tried to delete a cell using it's timestamp in the Hbase Shell, the
> previous versions of the same cell also got deleted. But when I tried the
> same using the Java API, then the previous versions are not deleted and I can
> retrive the previous values.
> https://github
[jira] [Commented] (HBASE-18500) Performance issue: Don't use BufferedMutator for HTable's put method
[
https://issues.apache.org/jira/browse/HBASE-18500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115550#comment-16115550
]
stack commented on HBASE-18500:
---
+1 on the removals. They have done a proper deprecation cycle. This change
should be marked incompatible though if only to have it show up in list of
possibly breaking changes when someone searches.
bq. We should check the results in order to find the failed PUTs, but the
change breaks the operational compatibility...
How you mean [~chia7712] (BTW, nice summary of benefits regards removal of BM
from HT)?
What if we created a BM in side in Puts and called its flush... then operation
would be as it was before?
Thanks.
> Performance issue: Don't use BufferedMutator for HTable's put method
>
>
> Key: HBASE-18500
> URL: https://issues.apache.org/jira/browse/HBASE-18500
> Project: HBase
> Issue Type: Improvement
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
> Attachments: HBASE-18500-v1.patch, HBASE-18500-v2.patch
>
>
> Copied the test result from HBASE-17994.
> Run start-hbase.sh in my local computer and use the default config to test
> with PE tool.
> {code}
> ./bin/hbase org.apache.hadoop.hbase.PerformanceEvaluation --rows=10
> --nomapred --autoFlush=True randomWrite 1
> ./bin/hbase org.apache.hadoop.hbase.PerformanceEvaluation --rows=10
> --nomapred --autoFlush=True asyncRandomWrite 1
> {code}
> Mean latency test result.
> || || Test1 || Test2 || Test3 || Test4 || Test5 ||
> | randomWrite | 164.39 | 161.22 | 164.78 | 140.61 | 151.69 |
> | asyncRandomWrite | 122.29 | 125.58 | 122.23 | 113.18 | 123.02 |
> 50th latency test result.
> || || Test1 || Test2 || Test3 || Test4 || Test5 ||
> | randomWrite | 130.00 | 125.00 | 123.00 | 112.00 | 121.00 |
> | asyncRandomWrite | 95.00 | 97.00 | 95.00 | 88.00 | 95.00 |
> 99th latency test result.
> || || Test1 || Test2 || Test3 || Test4 || Test5 ||
> | randomWrite | 600.00 | 600.00 | 650.00 | 404.00 | 425.00 |
> | asyncRandomWrite | 339.00 | 327.00 | 297.00 | 311.00 | 318.00 |
> In our internal 0.98 branch, the PE test result shows the async write has the
> almost same latency with the blocking write. But for master branch, the
> result shows the async write has better latency than the blocking client.
> Take a look about the code, I thought the difference is the BufferedMutator.
> For master branch, HTable don't have a write buffer and all write request
> will be flushed directly. And user can use BufferedMutator when user want to
> perform client-side buffering of writes. For the performance issue
> (autoFlush=True), I thought we can use rpc caller directly in HTable's put
> method. Thanks.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18502) Change MasterObserver to use TableDescriptor and ColumnFamilyDescriptor
[ https://issues.apache.org/jira/browse/HBASE-18502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115546#comment-16115546 ] stack commented on HBASE-18502: --- Skimmed. +1. [~anoop.hbase] and were just talking about the need to change these yesterday. Thank you [~chia7712] > Change MasterObserver to use TableDescriptor and ColumnFamilyDescriptor > --- > > Key: HBASE-18502 > URL: https://issues.apache.org/jira/browse/HBASE-18502 > Project: HBase > Issue Type: Sub-task >Reporter: Chia-Ping Tsai >Assignee: Chia-Ping Tsai >Priority: Critical > Fix For: 3.0.0, 2.0.0-alpha-2 > > Attachments: HBASE-18502.v0.patch, HBASE-18502.v1.patch, > HBASE-18502.v1.patch > > > MasterObserver is IA.COPROC so we can make some Incompatible change for 3.0 > and 2.0 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (HBASE-17312) [JDK8] Use default method for Observer Coprocessors
[
https://issues.apache.org/jira/browse/HBASE-17312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115335#comment-16115335
]
stack edited comment on HBASE-17312 at 8/5/17 11:23 PM:
Marking as incompatible change. Incompatible for CPs.
was (Author: stack):
Marking as incompatible change.
> [JDK8] Use default method for Observer Coprocessors
> ---
>
> Key: HBASE-17312
> URL: https://issues.apache.org/jira/browse/HBASE-17312
> Project: HBase
> Issue Type: Sub-task
> Components: Coprocessors
>Affects Versions: 2.0.0
>Reporter: Guanghao Zhang
>Assignee: Appy
> Labels: incompatible
> Fix For: 2.0.0
>
> Attachments: HBASE-17312.master.001.patch,
> HBASE-17312.master.001.patch, HBASE-17312.master.002.patch,
> HBASE-17312.master.003.patch, HBASE-17312.master.004.patch,
> HBASE-17312.master.005.patch, HBASE-17312.master.006.patch
>
>
> In cases where one might need to use multiple observers, say region, master
> and regionserver; and the fact that only one class can be extended, it gives
> rise to following pattern:
> {noformat}
> public class BaseMasterAndRegionObserver
> extends BaseRegionObserver
> implements MasterObserver
> class AccessController
> extends BaseMasterAndRegionObserver
> implements RegionServerObserver
> {noformat}
> were BaseMasterAndRegionObserver is full copy of BaseMasterObserver.
> There is an example of simple case too where the current design fails.
> Say only one observer is needed by the coprocessor, but the design doesn't
> permit extending even that single observer (see RSGroupAdminEndpoint), that
> leads to full copy of Base...Observer class into coprocessor class leading to
> 1000s of lines of code and this ugly mix of 5 main functions with 100 useless
> functions.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (HBASE-18518) Remove jersey1* dependencies form project and jersey1* jars from lib dir
[ https://issues.apache.org/jira/browse/HBASE-18518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115512#comment-16115512 ] Samir Ahmic edited comment on HBASE-18518 at 8/5/17 8:58 PM: - [~mdrob] bq. Also, do we need to make changes in the hbase-rest/pom.xml to specify the correct version of jersey? This is already specified in parent pom.xml in root dir. bq. Where do we need the transitive hadoop jersey available? We need it in every module when we run tests which requires starting hadoop mini cluster. Without it staring hadoop mini cluster will fail and consequently our tests will fail. Do you have any suggestions how may improve current dependency management ? was (Author: asamir): [~mdrob] bq. Also, do we need to make changes in the hbase-rest/pom.xml to specify the correct version of jersey? This is already specified in parent pom.xml in root dir. bq. Where do we need the transitive hadoop jersey available? We need it every module when we run tests which requires starting hadoop mini cluster. Without it staring hadoop mini cluster will fail and consequently our tests will fail. Do you have any suggestions how may improve current dependency management ? > Remove jersey1* dependencies form project and jersey1* jars from lib dir > > > Key: HBASE-18518 > URL: https://issues.apache.org/jira/browse/HBASE-18518 > Project: HBase > Issue Type: Task > Components: dependencies, pom, REST >Affects Versions: 3.0.0, 2.0.0-alpha-1 >Reporter: Samir Ahmic >Assignee: Samir Ahmic > Labels: cleanup > Fix For: 3.0.0 > > Attachments: HBASE-18518-master-01.patch > > > Recently i have opened https://issues.apache.org/jira/browse/HBASE-18506 and > it is clear that is caused by mixing jersey1 and jersey2 jars in classpath. > With https://issues.apache.org/jira/browse/HBASE-12894 we have introduced > jersey2 to project, and we also have bunch of transitive dependencies > (mainly from hadoop) on jersey1 which is not happiest situation since jersey1 > and jersey2 under same classpath can case runtime issues as it was case with > rest. > This task will have following steps > * Clean code and replace jersey1 constructs with jersey2 versions(there > should not be much of this) > * Add exclusions for transitive jersey1 dependencies in pom.xml > * Add exclusions in hadoop-two-compat.xml to prevent jersey1 jars in lib dir -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18518) Remove jersey1* dependencies form project and jersey1* jars from lib dir
[ https://issues.apache.org/jira/browse/HBASE-18518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115512#comment-16115512 ] Samir Ahmic commented on HBASE-18518: - [~mdrob] bq. Also, do we need to make changes in the hbase-rest/pom.xml to specify the correct version of jersey? This is already specified in parent pom.xml in root dir. bq. Where do we need the transitive hadoop jersey available? We need it every module when we run tests which requires starting hadoop mini cluster. Without it staring hadoop mini cluster will fail and consequently our tests will fail. Do you have any suggestions how may improve current dependency management ? > Remove jersey1* dependencies form project and jersey1* jars from lib dir > > > Key: HBASE-18518 > URL: https://issues.apache.org/jira/browse/HBASE-18518 > Project: HBase > Issue Type: Task > Components: dependencies, pom, REST >Affects Versions: 3.0.0, 2.0.0-alpha-1 >Reporter: Samir Ahmic >Assignee: Samir Ahmic > Labels: cleanup > Fix For: 3.0.0 > > Attachments: HBASE-18518-master-01.patch > > > Recently i have opened https://issues.apache.org/jira/browse/HBASE-18506 and > it is clear that is caused by mixing jersey1 and jersey2 jars in classpath. > With https://issues.apache.org/jira/browse/HBASE-12894 we have introduced > jersey2 to project, and we also have bunch of transitive dependencies > (mainly from hadoop) on jersey1 which is not happiest situation since jersey1 > and jersey2 under same classpath can case runtime issues as it was case with > rest. > This task will have following steps > * Clean code and replace jersey1 constructs with jersey2 versions(there > should not be much of this) > * Add exclusions for transitive jersey1 dependencies in pom.xml > * Add exclusions in hadoop-two-compat.xml to prevent jersey1 jars in lib dir -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18518) Remove jersey1* dependencies form project and jersey1* jars from lib dir
[ https://issues.apache.org/jira/browse/HBASE-18518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115504#comment-16115504 ] Mike Drob commented on HBASE-18518: --- Also, do we need to make changes in the hbase-rest/pom.xml to specify the correct version of jersey? Where do we need the transitive hadoop jersey available? > Remove jersey1* dependencies form project and jersey1* jars from lib dir > > > Key: HBASE-18518 > URL: https://issues.apache.org/jira/browse/HBASE-18518 > Project: HBase > Issue Type: Task > Components: dependencies, pom, REST >Affects Versions: 3.0.0, 2.0.0-alpha-1 >Reporter: Samir Ahmic >Assignee: Samir Ahmic > Labels: cleanup > Fix For: 3.0.0 > > Attachments: HBASE-18518-master-01.patch > > > Recently i have opened https://issues.apache.org/jira/browse/HBASE-18506 and > it is clear that is caused by mixing jersey1 and jersey2 jars in classpath. > With https://issues.apache.org/jira/browse/HBASE-12894 we have introduced > jersey2 to project, and we also have bunch of transitive dependencies > (mainly from hadoop) on jersey1 which is not happiest situation since jersey1 > and jersey2 under same classpath can case runtime issues as it was case with > rest. > This task will have following steps > * Clean code and replace jersey1 constructs with jersey2 versions(there > should not be much of this) > * Add exclusions for transitive jersey1 dependencies in pom.xml > * Add exclusions in hadoop-two-compat.xml to prevent jersey1 jars in lib dir -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18142) Deletion of a cell deletes the previous versions too
[
https://issues.apache.org/jira/browse/HBASE-18142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115499#comment-16115499
]
Mike Drob commented on HBASE-18142:
---
Not a fan of the {{rubocop:disable}} directives. We can leave those errors
present and work through them incrementally in future issues and then disable
the checks once we decide that there really is nothing to be done.
With these test changes, there's no coverage remaining on {{delete()}}, it's
all on {{deleteall()}}.
The new ruby-lint warnings look like false positives to me. The rubocop
warnings should be addressed (and I think they were addressed in v6, looks
like).
> Deletion of a cell deletes the previous versions too
>
>
> Key: HBASE-18142
> URL: https://issues.apache.org/jira/browse/HBASE-18142
> Project: HBase
> Issue Type: Bug
> Components: API, shell
>Affects Versions: 3.0.0
>Reporter: Karthick
>Assignee: ChunHao
> Labels: beginner
> Fix For: 3.0.0, 2.0.0-alpha-2
>
> Attachments: HBASE-18142.master.v0.patch,
> HBASE-18142.master.v1.patch, HBASE-18142.master.v2.patch,
> HBASE-18142.master.v3.patch, HBASE-18142.master.v4.patch,
> HBASE-18142.master.v5.patch, HBASE-18142.master.v6.patch
>
>
> When I tried to delete a cell using it's timestamp in the Hbase Shell, the
> previous versions of the same cell also got deleted. But when I tried the
> same using the Java API, then the previous versions are not deleted and I can
> retrive the previous values.
> https://github.com/apache/hbase/blob/master/hbase-client/src/main/java/org/apache/hadoop/hbase/client/Delete.java
> see this file to fix the issue. This method (public Delete addColumns(final
> byte [] family, final byte [] qualifier, final long timestamp)) only deletes
> the current version of the cell. The previous versions are not deleted.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-15511) ClusterStatus should be able to return responses by scope
[
https://issues.apache.org/jira/browse/HBASE-15511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115497#comment-16115497
]
Hadoop QA commented on HBASE-15511:
---
| (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: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:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
32s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
59s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
39s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
46s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
7s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 9m
8s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
24s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
23s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
6s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
42s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 2m
42s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m
42s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
51s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
2s{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}
42m 54s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green}
1m 52s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 9m
41s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
19s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
33s{color} | {color:green} hbase-protocol-shaded in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
23s{color} | {color:green} hbase-protocol in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
59s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 41m 24s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
42s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}132m 3s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.client.TestClientClusterStatus |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.11.2 Server=1.11.2 Image:yetus/hbase:bdc94b1 |
| JIRA Issue | HBASE-15511 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12880535/HBASE-15511.master.008.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile cc hbaseprotoc |
| uname | Linux 28f96fc50c4e 3.13.0-116-generic #
[jira] [Commented] (HBASE-18518) Remove jersey1* dependencies form project and jersey1* jars from lib dir
[ https://issues.apache.org/jira/browse/HBASE-18518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115496#comment-16115496 ] Samir Ahmic commented on HBASE-18518: - Sure thing [~mdrob]. I will revisit tests to check how change impact them. > Remove jersey1* dependencies form project and jersey1* jars from lib dir > > > Key: HBASE-18518 > URL: https://issues.apache.org/jira/browse/HBASE-18518 > Project: HBase > Issue Type: Task > Components: dependencies, pom, REST >Affects Versions: 3.0.0, 2.0.0-alpha-1 >Reporter: Samir Ahmic >Assignee: Samir Ahmic > Labels: cleanup > Fix For: 3.0.0 > > Attachments: HBASE-18518-master-01.patch > > > Recently i have opened https://issues.apache.org/jira/browse/HBASE-18506 and > it is clear that is caused by mixing jersey1 and jersey2 jars in classpath. > With https://issues.apache.org/jira/browse/HBASE-12894 we have introduced > jersey2 to project, and we also have bunch of transitive dependencies > (mainly from hadoop) on jersey1 which is not happiest situation since jersey1 > and jersey2 under same classpath can case runtime issues as it was case with > rest. > This task will have following steps > * Clean code and replace jersey1 constructs with jersey2 versions(there > should not be much of this) > * Add exclusions for transitive jersey1 dependencies in pom.xml > * Add exclusions in hadoop-two-compat.xml to prevent jersey1 jars in lib dir -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18518) Remove jersey1* dependencies form project and jersey1* jars from lib dir
[ https://issues.apache.org/jira/browse/HBASE-18518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115494#comment-16115494 ] Mike Drob commented on HBASE-18518: --- The NPE in the tests looks like it is probably related. Can you take a look [~asamir]? > Remove jersey1* dependencies form project and jersey1* jars from lib dir > > > Key: HBASE-18518 > URL: https://issues.apache.org/jira/browse/HBASE-18518 > Project: HBase > Issue Type: Task > Components: dependencies, pom, REST >Affects Versions: 3.0.0, 2.0.0-alpha-1 >Reporter: Samir Ahmic >Assignee: Samir Ahmic > Labels: cleanup > Fix For: 3.0.0 > > Attachments: HBASE-18518-master-01.patch > > > Recently i have opened https://issues.apache.org/jira/browse/HBASE-18506 and > it is clear that is caused by mixing jersey1 and jersey2 jars in classpath. > With https://issues.apache.org/jira/browse/HBASE-12894 we have introduced > jersey2 to project, and we also have bunch of transitive dependencies > (mainly from hadoop) on jersey1 which is not happiest situation since jersey1 > and jersey2 under same classpath can case runtime issues as it was case with > rest. > This task will have following steps > * Clean code and replace jersey1 constructs with jersey2 versions(there > should not be much of this) > * Add exclusions for transitive jersey1 dependencies in pom.xml > * Add exclusions in hadoop-two-compat.xml to prevent jersey1 jars in lib dir -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18142) Deletion of a cell deletes the previous versions too
[ https://issues.apache.org/jira/browse/HBASE-18142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai updated HBASE-18142: --- Fix Version/s: 2.0.0-alpha-2 > Deletion of a cell deletes the previous versions too > > > Key: HBASE-18142 > URL: https://issues.apache.org/jira/browse/HBASE-18142 > Project: HBase > Issue Type: Bug > Components: API, shell >Affects Versions: 3.0.0 >Reporter: Karthick >Assignee: ChunHao > Labels: beginner > Fix For: 3.0.0, 2.0.0-alpha-2 > > Attachments: HBASE-18142.master.v0.patch, > HBASE-18142.master.v1.patch, HBASE-18142.master.v2.patch, > HBASE-18142.master.v3.patch, HBASE-18142.master.v4.patch, > HBASE-18142.master.v5.patch, HBASE-18142.master.v6.patch > > > When I tried to delete a cell using it's timestamp in the Hbase Shell, the > previous versions of the same cell also got deleted. But when I tried the > same using the Java API, then the previous versions are not deleted and I can > retrive the previous values. > https://github.com/apache/hbase/blob/master/hbase-client/src/main/java/org/apache/hadoop/hbase/client/Delete.java > see this file to fix the issue. This method (public Delete addColumns(final > byte [] family, final byte [] qualifier, final long timestamp)) only deletes > the current version of the cell. The previous versions are not deleted. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18142) Deletion of a cell deletes the previous versions too
[ https://issues.apache.org/jira/browse/HBASE-18142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai updated HBASE-18142: --- Component/s: shell > Deletion of a cell deletes the previous versions too > > > Key: HBASE-18142 > URL: https://issues.apache.org/jira/browse/HBASE-18142 > Project: HBase > Issue Type: Bug > Components: API, shell >Affects Versions: 3.0.0 >Reporter: Karthick >Assignee: ChunHao > Labels: beginner > Fix For: 3.0.0, 2.0.0-alpha-2 > > Attachments: HBASE-18142.master.v0.patch, > HBASE-18142.master.v1.patch, HBASE-18142.master.v2.patch, > HBASE-18142.master.v3.patch, HBASE-18142.master.v4.patch, > HBASE-18142.master.v5.patch, HBASE-18142.master.v6.patch > > > When I tried to delete a cell using it's timestamp in the Hbase Shell, the > previous versions of the same cell also got deleted. But when I tried the > same using the Java API, then the previous versions are not deleted and I can > retrive the previous values. > https://github.com/apache/hbase/blob/master/hbase-client/src/main/java/org/apache/hadoop/hbase/client/Delete.java > see this file to fix the issue. This method (public Delete addColumns(final > byte [] family, final byte [] qualifier, final long timestamp)) only deletes > the current version of the cell. The previous versions are not deleted. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18142) Deletion of a cell deletes the previous versions too
[ https://issues.apache.org/jira/browse/HBASE-18142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ChunHao updated HBASE-18142: Status: Patch Available (was: Open) > Deletion of a cell deletes the previous versions too > > > Key: HBASE-18142 > URL: https://issues.apache.org/jira/browse/HBASE-18142 > Project: HBase > Issue Type: Bug > Components: API >Affects Versions: 3.0.0 >Reporter: Karthick >Assignee: ChunHao > Labels: beginner > Fix For: 3.0.0 > > Attachments: HBASE-18142.master.v0.patch, > HBASE-18142.master.v1.patch, HBASE-18142.master.v2.patch, > HBASE-18142.master.v3.patch, HBASE-18142.master.v4.patch, > HBASE-18142.master.v5.patch, HBASE-18142.master.v6.patch > > > When I tried to delete a cell using it's timestamp in the Hbase Shell, the > previous versions of the same cell also got deleted. But when I tried the > same using the Java API, then the previous versions are not deleted and I can > retrive the previous values. > https://github.com/apache/hbase/blob/master/hbase-client/src/main/java/org/apache/hadoop/hbase/client/Delete.java > see this file to fix the issue. This method (public Delete addColumns(final > byte [] family, final byte [] qualifier, final long timestamp)) only deletes > the current version of the cell. The previous versions are not deleted. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18142) Deletion of a cell deletes the previous versions too
[ https://issues.apache.org/jira/browse/HBASE-18142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ChunHao updated HBASE-18142: Status: Open (was: Patch Available) > Deletion of a cell deletes the previous versions too > > > Key: HBASE-18142 > URL: https://issues.apache.org/jira/browse/HBASE-18142 > Project: HBase > Issue Type: Bug > Components: API >Affects Versions: 3.0.0 >Reporter: Karthick >Assignee: ChunHao > Labels: beginner > Fix For: 3.0.0 > > Attachments: HBASE-18142.master.v0.patch, > HBASE-18142.master.v1.patch, HBASE-18142.master.v2.patch, > HBASE-18142.master.v3.patch, HBASE-18142.master.v4.patch, > HBASE-18142.master.v5.patch, HBASE-18142.master.v6.patch > > > When I tried to delete a cell using it's timestamp in the Hbase Shell, the > previous versions of the same cell also got deleted. But when I tried the > same using the Java API, then the previous versions are not deleted and I can > retrive the previous values. > https://github.com/apache/hbase/blob/master/hbase-client/src/main/java/org/apache/hadoop/hbase/client/Delete.java > see this file to fix the issue. This method (public Delete addColumns(final > byte [] family, final byte [] qualifier, final long timestamp)) only deletes > the current version of the cell. The previous versions are not deleted. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18142) Deletion of a cell deletes the previous versions too
[ https://issues.apache.org/jira/browse/HBASE-18142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ChunHao updated HBASE-18142: Attachment: HBASE-18142.master.v6.patch > Deletion of a cell deletes the previous versions too > > > Key: HBASE-18142 > URL: https://issues.apache.org/jira/browse/HBASE-18142 > Project: HBase > Issue Type: Bug > Components: API >Affects Versions: 3.0.0 >Reporter: Karthick >Assignee: ChunHao > Labels: beginner > Fix For: 3.0.0 > > Attachments: HBASE-18142.master.v0.patch, > HBASE-18142.master.v1.patch, HBASE-18142.master.v2.patch, > HBASE-18142.master.v3.patch, HBASE-18142.master.v4.patch, > HBASE-18142.master.v5.patch, HBASE-18142.master.v6.patch > > > When I tried to delete a cell using it's timestamp in the Hbase Shell, the > previous versions of the same cell also got deleted. But when I tried the > same using the Java API, then the previous versions are not deleted and I can > retrive the previous values. > https://github.com/apache/hbase/blob/master/hbase-client/src/main/java/org/apache/hadoop/hbase/client/Delete.java > see this file to fix the issue. This method (public Delete addColumns(final > byte [] family, final byte [] qualifier, final long timestamp)) only deletes > the current version of the cell. The previous versions are not deleted. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18518) Remove jersey1* dependencies form project and jersey1* jars from lib dir
[
https://issues.apache.org/jira/browse/HBASE-18518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115478#comment-16115478
]
Hadoop QA commented on HBASE-18518:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
17s{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: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
31s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
4s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
57s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
29s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
52s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hbase-assembly {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 0m
42s{color} | {color:red} hbase-rest in master has 3 extant Findbugs warnings.
{color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
38s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
17s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
53s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
49s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
49s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
26s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
46s{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
1s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
35m 4s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hbase-assembly {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
52s{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} 0m
18s{color} | {color:green} hbase-it in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 3m 20s{color}
| {color:red} hbase-rest in the patch failed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
17s{color} | {color:green} hbase-assembly in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
21s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 53m 4s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.rest.TestVersionResource |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.11.2 Server=1.11.2 Image:yetus/hbase:bdc94b1 |
| JIRA Issue | HBASE-18518 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12880531/HBASE-18518-master-01.patch
|
| Optional Tests | asflicense javac javadoc unit xml findbugs
hadoopcheck h
[jira] [Commented] (HBASE-16290) Dump summary of callQueue content; can help debugging
[
https://issues.apache.org/jira/browse/HBASE-16290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115474#comment-16115474
]
Chia-Ping Tsai commented on HBASE-16290:
{code}
+
+ /** Retrieves the count of default Rpc queues per Rpc method **/
+ public abstract Map getCallQueueCountsSummary();
+
+ /** Retrieves the size in bytes of default Rpc queues per Rpc method **/
+ public abstract Map getCallQueueSizeSummary();
+
+ /** Retrieves the count of Priority Rpc queues per Rpc method **/
+ public abstract Map getPriorityQueueCountsSummary();
+
+ /** Retrieves the size in bytes of priority Rpc queues per Rpc method **/
+ public abstract Map getPriorityQueueSizeSummary();
+
+ /** Retrieves the count of replication Rpc queues per Rpc method **/
+ public abstract Map getReplicationQueueCountsSummary();
+
+ /** Retrieves the size in bytes of replication Rpc queues per Rpc method **/
+ public abstract Map getReplicationQueueSizeSummary();
{code}
These methods serve only SimpleRpcScheduler. The meaning is not clear for other
schedulers. Can we introduce an new class which carries the queue information?
As I see it, we need the queue name, method name, queue size, and queue count.
Also, we need some tests.
{code}
+ private static void dumpCallQueueSummary(Map summary,
PrintWriter out) {
+for(String method: summary.keySet()){
+ out.println(method+": "+summary.getOrDefault(method, 0L));
+}
+ }
{code}
Consider using Map#entrySet
> Dump summary of callQueue content; can help debugging
> -
>
> Key: HBASE-16290
> URL: https://issues.apache.org/jira/browse/HBASE-16290
> Project: HBase
> Issue Type: Bug
> Components: Operability
>Affects Versions: 2.0.0
>Reporter: stack
>Assignee: Sreeram Venkatasubramanian
>Priority: Critical
> Labels: beginner
> Fix For: 2.0.0
>
> Attachments: 0001-Dump-call-queue-summaries.patch,
> DebugDump_screenshot.png, OldPatch-0001-Dump-Call-Queue-Summary.patch, Sample
> Summary.txt
>
>
> Being able to get a clue what is in a backedup callQueue could give insight
> on what is going on on a jacked server. Just needs to summarize count, sizes,
> call types. Useful debugging. In a servlet?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18515) Introduce Delete.add as a replacement for Delete#addDeleteMarker
[
https://issues.apache.org/jira/browse/HBASE-18515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115473#comment-16115473
]
Hadoop QA commented on HBASE-18515:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
24s{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:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
30s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
17s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
24s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
10s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
50s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
17s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
18s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
18s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
18s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
23s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
10s{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}
30m 30s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
58s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
17s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
36s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
7s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 41m 45s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.03.0-ce Server=17.03.0-ce Image:yetus/hbase:bdc94b1 |
| JIRA Issue | HBASE-18515 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12880533/HBASE-18515.master.v3.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux 1f1001858ba1 3.13.0-116-generic #163-Ubuntu SMP Fri Mar 31
14:13:22 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build@2/component/dev-support/hbase-personality.sh
|
| git revision | master / 7da4750 |
| Default Java | 1.8.0_131 |
| findbugs | v3.1.0-RC3 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/7944/testReport/ |
| modules | C: hbase-client U: hbase-client |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/7944/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
This message was automatically generated.
> Introduce Delete.add as a replacement for Delete#addDeleteMarker
> -
>
> Key: HBASE-18515
> URL: https://issues.apache.org/jira/browse/HBASE-18515
> Project: HBase
> Issue Type: Task
> Components:
[jira] [Commented] (HBASE-18142) Deletion of a cell deletes the previous versions too
[
https://issues.apache.org/jira/browse/HBASE-18142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115471#comment-16115471
]
Hadoop QA commented on HBASE-18142:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
17s{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 1 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
43s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
18s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
10s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
15s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
17s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} rubocop {color} | {color:red} 0m
12s{color} | {color:red} The patch generated 2 new + 407 unchanged - 58 fixed =
409 total (was 465) {color} |
| {color:red}-1{color} | {color:red} ruby-lint {color} | {color:red} 0m
12s{color} | {color:red} The patch generated 6 new + 489 unchanged - 20 fixed =
495 total (was 509) {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}
32m 42s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
9s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
43s{color} | {color:green} hbase-shell in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
7s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 39m 16s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:bdc94b1 |
| JIRA Issue | HBASE-18142 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12880532/HBASE-18142.master.v5.patch
|
| Optional Tests | asflicense javac javadoc unit rubocop ruby_lint |
| uname | Linux f20d3cafc26e 3.13.0-119-generic #166-Ubuntu SMP Wed May 3
12:18:55 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build@2/component/dev-support/hbase-personality.sh
|
| git revision | master / 7da4750 |
| Default Java | 1.8.0_131 |
| rubocop | v0.49.1 |
| rubocop |
https://builds.apache.org/job/PreCommit-HBASE-Build/7941/artifact/patchprocess/diff-patch-rubocop.txt
|
| ruby-lint | v2.3.1 |
| ruby-lint |
https://builds.apache.org/job/PreCommit-HBASE-Build/7941/artifact/patchprocess/diff-patch-ruby-lint.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/7941/testReport/ |
| modules | C: hbase-shell U: hbase-shell |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/7941/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
This message was automatically generated.
> Deletion of a cell deletes the previous versions too
>
>
> Key: HBASE-18142
> URL: https://issues.apache.org/jira/browse/HBASE-18142
> Project: HBase
> Issue Type: Bug
> Components: API
>Affects Versions: 3.0.0
>Reporter: Karthick
>Assignee: ChunHao
> Labels: beginner
> Fix For: 3.0.0
>
> Attachments: HBASE-18142.master.v0.patch,
> HBASE-18142.master.v1.patch, HBASE-18142.master.v2.patch,
> HBASE-18142.master.v3.patch, HBASE-18142.master.v4.patch,
> HBASE-18142.master.v5.patch
>
>
> When I tried to delete a cell using it's timestamp in the Hbase Shell, the
> previous versions of the same cell also got deleted. But when I tried the
> same using the Java API, then the previous versions are not deleted and I can
> retrive the previous values.
> https://github.
[jira] [Commented] (HBASE-18517) limit max log message width in log4j
[
https://issues.apache.org/jira/browse/HBASE-18517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115468#comment-16115468
]
Hadoop QA commented on HBASE-18517:
---
| (/) *{color:green}+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: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} 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}
33m 5s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
10s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 33m 40s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:bdc94b1 |
| JIRA Issue | HBASE-18517 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12880523/HBASE-18374.master.001.patch
|
| Optional Tests | asflicense |
| uname | Linux 78d213eb4452 3.13.0-119-generic #166-Ubuntu SMP Wed May 3
12:18:55 UTC 2017 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 / 7da4750 |
| modules | C: . U: . |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/7940/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
This message was automatically generated.
> limit max log message width in log4j
>
>
> Key: HBASE-18517
> URL: https://issues.apache.org/jira/browse/HBASE-18517
> Project: HBase
> Issue Type: Bug
>Affects Versions: 3.0.0, 1.5.0
>Reporter: Vikas Vishwakarma
>Assignee: Vikas Vishwakarma
> Fix For: 3.0.0, 1.5.0
>
> Attachments: HBASE-18374.master.001.patch,
> HBASE-18517.branch-1.001.patch
>
>
> We had two cases now in our prod / pilot setups which is leading to humongous
> log lines in RegionServer logs.
> In first case, one of the phoenix user had constructed a query with a really
> large list of Id filters (61 MB) that translated into HBase scan that was
> running slow which lead to responseTooSlow messages in the logs with the
> entire filter list being printed in the logs, example
> ipc.RpcServer - (responseTooSlow):
> {"call":"Scan(org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ScanRequest)","starttimems":1501457864417,"responsesize":11,"method":"Scan","param":"region
> { type: REGION_NAME value: .
> org.apache.hadoop.hbase.filter.FirstKeyOnlyFilter\\022\351\\200\\036\\n(org.apache.phoenix.filter.SkipScanFilter
> ... ...
> There was another case where a use case had created a table with really large
> key/region names. This was causing humongous log lines for flush and
> compaction on these regions filling up the RS logs
> These large logs usually cause issues with disk I/O load, loading the splunk
> servers, even machine perf degradations. With 61 MB log lines basic log
> processing commands like vim, scrolling the logs, wc -l , etc were getting
> stuck. High GC activity was also noted on this cluster although not 100% sure
> if it was related to above issue.
> We should consider limiting the message size in logs which can be easily done
> by adding a maximum width format modifier on the message conversion character
> in log4j.properties
> log4j.appender.console.layout.ConversionPattern=...: %m%n
> to
> log4j.appender.console.layout.ConversionPattern=...: %.1m%n
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (HBASE-15511) ClusterStatus should be able to return responses by scope
[ https://issues.apache.org/jira/browse/HBASE-15511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115454#comment-16115454 ] Reid Chan edited comment on HBASE-15511 at 8/5/17 5:06 PM: --- Re-write most of the codes, also updates it on review board, [Reviewboard|https://reviews.apache.org/r/51212/] ping [~chia7712] was (Author: reidchan): Re-write most of the codes, also updates it on review board, [Reviewboard|https://reviews.apache.org/r/51212/] > ClusterStatus should be able to return responses by scope > - > > Key: HBASE-15511 > URL: https://issues.apache.org/jira/browse/HBASE-15511 > Project: HBase > Issue Type: Improvement >Reporter: Esteban Gutierrez >Assignee: Reid Chan > Attachments: HBASE-15511.master.001.patch, > HBASE-15511.master.002.patch, HBASE-15511.master.003.patch, > HBASE-15511.master.004.patch, HBASE-15511.master.005.patch, > HBASE-15511.master.006.patch, HBASE-15511.master.007.patch, > HBASE-15511.master.008.patch > > > The current ClusterStatus response returns too much information about the > load per region and replication cluster wide. Sometimes that response can be > quite large (10s or 100s of MBs) and methods like getServerSize() or > getRegionsCount() don't really need the full response. One possibility is to > provide a scope (or filter) for the ClusterStatus requests to limit the > response back to the client. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (HBASE-15511) ClusterStatus should be able to return responses by scope
[ https://issues.apache.org/jira/browse/HBASE-15511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115454#comment-16115454 ] Reid Chan edited comment on HBASE-15511 at 8/5/17 5:03 PM: --- Re-write most of the codes, also updates it on review board, [Reviewboard|https://reviews.apache.org/r/51212/] was (Author: reidchan): Re-write most of the codes. > ClusterStatus should be able to return responses by scope > - > > Key: HBASE-15511 > URL: https://issues.apache.org/jira/browse/HBASE-15511 > Project: HBase > Issue Type: Improvement >Reporter: Esteban Gutierrez >Assignee: Reid Chan > Attachments: HBASE-15511.master.001.patch, > HBASE-15511.master.002.patch, HBASE-15511.master.003.patch, > HBASE-15511.master.004.patch, HBASE-15511.master.005.patch, > HBASE-15511.master.006.patch, HBASE-15511.master.007.patch, > HBASE-15511.master.008.patch > > > The current ClusterStatus response returns too much information about the > load per region and replication cluster wide. Sometimes that response can be > quite large (10s or 100s of MBs) and methods like getServerSize() or > getRegionsCount() don't really need the full response. One possibility is to > provide a scope (or filter) for the ClusterStatus requests to limit the > response back to the client. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-15511) ClusterStatus should be able to return responses by scope
[ https://issues.apache.org/jira/browse/HBASE-15511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Reid Chan updated HBASE-15511: -- Status: Patch Available (was: Open) > ClusterStatus should be able to return responses by scope > - > > Key: HBASE-15511 > URL: https://issues.apache.org/jira/browse/HBASE-15511 > Project: HBase > Issue Type: Improvement >Reporter: Esteban Gutierrez >Assignee: Reid Chan > Attachments: HBASE-15511.master.001.patch, > HBASE-15511.master.002.patch, HBASE-15511.master.003.patch, > HBASE-15511.master.004.patch, HBASE-15511.master.005.patch, > HBASE-15511.master.006.patch, HBASE-15511.master.007.patch, > HBASE-15511.master.008.patch > > > The current ClusterStatus response returns too much information about the > load per region and replication cluster wide. Sometimes that response can be > quite large (10s or 100s of MBs) and methods like getServerSize() or > getRegionsCount() don't really need the full response. One possibility is to > provide a scope (or filter) for the ClusterStatus requests to limit the > response back to the client. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-15511) ClusterStatus should be able to return responses by scope
[ https://issues.apache.org/jira/browse/HBASE-15511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Reid Chan updated HBASE-15511: -- Attachment: HBASE-15511.master.008.patch Re-write most of the codes. > ClusterStatus should be able to return responses by scope > - > > Key: HBASE-15511 > URL: https://issues.apache.org/jira/browse/HBASE-15511 > Project: HBase > Issue Type: Improvement >Reporter: Esteban Gutierrez >Assignee: Reid Chan > Attachments: HBASE-15511.master.001.patch, > HBASE-15511.master.002.patch, HBASE-15511.master.003.patch, > HBASE-15511.master.004.patch, HBASE-15511.master.005.patch, > HBASE-15511.master.006.patch, HBASE-15511.master.007.patch, > HBASE-15511.master.008.patch > > > The current ClusterStatus response returns too much information about the > load per region and replication cluster wide. Sometimes that response can be > quite large (10s or 100s of MBs) and methods like getServerSize() or > getRegionsCount() don't really need the full response. One possibility is to > provide a scope (or filter) for the ClusterStatus requests to limit the > response back to the client. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-15511) ClusterStatus should be able to return responses by scope
[ https://issues.apache.org/jira/browse/HBASE-15511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Reid Chan updated HBASE-15511: -- Status: Open (was: Patch Available) > ClusterStatus should be able to return responses by scope > - > > Key: HBASE-15511 > URL: https://issues.apache.org/jira/browse/HBASE-15511 > Project: HBase > Issue Type: Improvement >Reporter: Esteban Gutierrez >Assignee: Reid Chan > Attachments: HBASE-15511.master.001.patch, > HBASE-15511.master.002.patch, HBASE-15511.master.003.patch, > HBASE-15511.master.004.patch, HBASE-15511.master.005.patch, > HBASE-15511.master.006.patch, HBASE-15511.master.007.patch > > > The current ClusterStatus response returns too much information about the > load per region and replication cluster wide. Sometimes that response can be > quite large (10s or 100s of MBs) and methods like getServerSize() or > getRegionsCount() don't really need the full response. One possibility is to > provide a scope (or filter) for the ClusterStatus requests to limit the > response back to the client. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18525) TestAssignmentManager#testSocketTimeout fails in master branch
[
https://issues.apache.org/jira/browse/HBASE-18525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115452#comment-16115452
]
Hadoop QA commented on HBASE-18525:
---
| (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.4.0/precommit-patchnames for
instructions. {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:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
19s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
38s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
48s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
15s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
54s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
28s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
44s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
38s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
38s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
47s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
15s{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}
30m 8s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
54s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
28s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}107m
17s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
16s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}152m 24s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:bdc94b1 |
| JIRA Issue | HBASE-18525 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12880527/18525.v1.txt |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux fe3e948e34fb 3.13.0-119-generic #166-Ubuntu SMP Wed May 3
12:18:55 UTC 2017 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 / 7da4750 |
| Default Java | 1.8.0_131 |
| findbugs | v3.1.0-RC3 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/7939/testReport/ |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/7939/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
This message was automatically generated.
> TestAssignmentManager#testSocketTimeout fails in master branch
> -
[jira] [Commented] (HBASE-18515) Introduce Delete.add as a replacement for Delete#addDeleteMarker
[
https://issues.apache.org/jira/browse/HBASE-18515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115443#comment-16115443
]
Xie YiFan commented on HBASE-18515:
---
No. I dont't mind.
> Introduce Delete.add as a replacement for Delete#addDeleteMarker
> -
>
> Key: HBASE-18515
> URL: https://issues.apache.org/jira/browse/HBASE-18515
> Project: HBase
> Issue Type: Task
> Components: Client
>Reporter: Chia-Ping Tsai
>Assignee: Xie YiFan
> Labels: beginner
> Fix For: 3.0.0, 2.0.0-alpha-2
>
> Attachments: HBASE-18515.master.v0.patch,
> HBASE-18515.master.v1.patch, HBASE-18515.master.v2.patch,
> HBASE-18515.master.v3.patch
>
>
> {quote}
> public Delete addDeleteMarker(Cell kv) throws IOException {
> // TODO: Deprecate and rename 'add' so it matches how we add KVs to Puts.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18515) Introduce Delete.add as a replacement for Delete#addDeleteMarker
[
https://issues.apache.org/jira/browse/HBASE-18515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115440#comment-16115440
]
Chia-Ping Tsai commented on HBASE-18515:
LGTM.
Do you mind replacing the addDeleteMarker() by add() from the code base?
> Introduce Delete.add as a replacement for Delete#addDeleteMarker
> -
>
> Key: HBASE-18515
> URL: https://issues.apache.org/jira/browse/HBASE-18515
> Project: HBase
> Issue Type: Task
> Components: Client
>Reporter: Chia-Ping Tsai
>Assignee: Xie YiFan
> Labels: beginner
> Fix For: 3.0.0, 2.0.0-alpha-2
>
> Attachments: HBASE-18515.master.v0.patch,
> HBASE-18515.master.v1.patch, HBASE-18515.master.v2.patch,
> HBASE-18515.master.v3.patch
>
>
> {quote}
> public Delete addDeleteMarker(Cell kv) throws IOException {
> // TODO: Deprecate and rename 'add' so it matches how we add KVs to Puts.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18515) Introduce Delete.add as a replacement for Delete#addDeleteMarker
[
https://issues.apache.org/jira/browse/HBASE-18515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xie YiFan updated HBASE-18515:
--
Status: Patch Available (was: Open)
> Introduce Delete.add as a replacement for Delete#addDeleteMarker
> -
>
> Key: HBASE-18515
> URL: https://issues.apache.org/jira/browse/HBASE-18515
> Project: HBase
> Issue Type: Task
> Components: Client
>Reporter: Chia-Ping Tsai
>Assignee: Xie YiFan
> Labels: beginner
> Fix For: 3.0.0, 2.0.0-alpha-2
>
> Attachments: HBASE-18515.master.v0.patch,
> HBASE-18515.master.v1.patch, HBASE-18515.master.v2.patch,
> HBASE-18515.master.v3.patch
>
>
> {quote}
> public Delete addDeleteMarker(Cell kv) throws IOException {
> // TODO: Deprecate and rename 'add' so it matches how we add KVs to Puts.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18515) Introduce Delete.add as a replacement for Delete#addDeleteMarker
[
https://issues.apache.org/jira/browse/HBASE-18515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xie YiFan updated HBASE-18515:
--
Status: Open (was: Patch Available)
> Introduce Delete.add as a replacement for Delete#addDeleteMarker
> -
>
> Key: HBASE-18515
> URL: https://issues.apache.org/jira/browse/HBASE-18515
> Project: HBase
> Issue Type: Task
> Components: Client
>Reporter: Chia-Ping Tsai
>Assignee: Xie YiFan
> Labels: beginner
> Fix For: 3.0.0, 2.0.0-alpha-2
>
> Attachments: HBASE-18515.master.v0.patch,
> HBASE-18515.master.v1.patch, HBASE-18515.master.v2.patch,
> HBASE-18515.master.v3.patch
>
>
> {quote}
> public Delete addDeleteMarker(Cell kv) throws IOException {
> // TODO: Deprecate and rename 'add' so it matches how we add KVs to Puts.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18515) Introduce Delete.add as a replacement for Delete#addDeleteMarker
[
https://issues.apache.org/jira/browse/HBASE-18515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xie YiFan updated HBASE-18515:
--
Attachment: HBASE-18515.master.v3.patch
> Introduce Delete.add as a replacement for Delete#addDeleteMarker
> -
>
> Key: HBASE-18515
> URL: https://issues.apache.org/jira/browse/HBASE-18515
> Project: HBase
> Issue Type: Task
> Components: Client
>Reporter: Chia-Ping Tsai
>Assignee: Xie YiFan
> Labels: beginner
> Fix For: 3.0.0, 2.0.0-alpha-2
>
> Attachments: HBASE-18515.master.v0.patch,
> HBASE-18515.master.v1.patch, HBASE-18515.master.v2.patch,
> HBASE-18515.master.v3.patch
>
>
> {quote}
> public Delete addDeleteMarker(Cell kv) throws IOException {
> // TODO: Deprecate and rename 'add' so it matches how we add KVs to Puts.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18142) Deletion of a cell deletes the previous versions too
[ https://issues.apache.org/jira/browse/HBASE-18142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ChunHao updated HBASE-18142: Attachment: HBASE-18142.master.v5.patch > Deletion of a cell deletes the previous versions too > > > Key: HBASE-18142 > URL: https://issues.apache.org/jira/browse/HBASE-18142 > Project: HBase > Issue Type: Bug > Components: API >Affects Versions: 3.0.0 >Reporter: Karthick >Assignee: ChunHao > Labels: beginner > Fix For: 3.0.0 > > Attachments: HBASE-18142.master.v0.patch, > HBASE-18142.master.v1.patch, HBASE-18142.master.v2.patch, > HBASE-18142.master.v3.patch, HBASE-18142.master.v4.patch, > HBASE-18142.master.v5.patch > > > When I tried to delete a cell using it's timestamp in the Hbase Shell, the > previous versions of the same cell also got deleted. But when I tried the > same using the Java API, then the previous versions are not deleted and I can > retrive the previous values. > https://github.com/apache/hbase/blob/master/hbase-client/src/main/java/org/apache/hadoop/hbase/client/Delete.java > see this file to fix the issue. This method (public Delete addColumns(final > byte [] family, final byte [] qualifier, final long timestamp)) only deletes > the current version of the cell. The previous versions are not deleted. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18142) Deletion of a cell deletes the previous versions too
[ https://issues.apache.org/jira/browse/HBASE-18142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ChunHao updated HBASE-18142: Attachment: (was: HBASE-18142.master.v5.patch) > Deletion of a cell deletes the previous versions too > > > Key: HBASE-18142 > URL: https://issues.apache.org/jira/browse/HBASE-18142 > Project: HBase > Issue Type: Bug > Components: API >Affects Versions: 3.0.0 >Reporter: Karthick >Assignee: ChunHao > Labels: beginner > Fix For: 3.0.0 > > Attachments: HBASE-18142.master.v0.patch, > HBASE-18142.master.v1.patch, HBASE-18142.master.v2.patch, > HBASE-18142.master.v3.patch, HBASE-18142.master.v4.patch, > HBASE-18142.master.v5.patch > > > When I tried to delete a cell using it's timestamp in the Hbase Shell, the > previous versions of the same cell also got deleted. But when I tried the > same using the Java API, then the previous versions are not deleted and I can > retrive the previous values. > https://github.com/apache/hbase/blob/master/hbase-client/src/main/java/org/apache/hadoop/hbase/client/Delete.java > see this file to fix the issue. This method (public Delete addColumns(final > byte [] family, final byte [] qualifier, final long timestamp)) only deletes > the current version of the cell. The previous versions are not deleted. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18142) Deletion of a cell deletes the previous versions too
[ https://issues.apache.org/jira/browse/HBASE-18142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ChunHao updated HBASE-18142: Status: Patch Available (was: Open) > Deletion of a cell deletes the previous versions too > > > Key: HBASE-18142 > URL: https://issues.apache.org/jira/browse/HBASE-18142 > Project: HBase > Issue Type: Bug > Components: API >Affects Versions: 3.0.0 >Reporter: Karthick >Assignee: ChunHao > Labels: beginner > Fix For: 3.0.0 > > Attachments: HBASE-18142.master.v0.patch, > HBASE-18142.master.v1.patch, HBASE-18142.master.v2.patch, > HBASE-18142.master.v3.patch, HBASE-18142.master.v4.patch, > HBASE-18142.master.v5.patch > > > When I tried to delete a cell using it's timestamp in the Hbase Shell, the > previous versions of the same cell also got deleted. But when I tried the > same using the Java API, then the previous versions are not deleted and I can > retrive the previous values. > https://github.com/apache/hbase/blob/master/hbase-client/src/main/java/org/apache/hadoop/hbase/client/Delete.java > see this file to fix the issue. This method (public Delete addColumns(final > byte [] family, final byte [] qualifier, final long timestamp)) only deletes > the current version of the cell. The previous versions are not deleted. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18142) Deletion of a cell deletes the previous versions too
[ https://issues.apache.org/jira/browse/HBASE-18142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ChunHao updated HBASE-18142: Status: Open (was: Patch Available) > Deletion of a cell deletes the previous versions too > > > Key: HBASE-18142 > URL: https://issues.apache.org/jira/browse/HBASE-18142 > Project: HBase > Issue Type: Bug > Components: API >Affects Versions: 3.0.0 >Reporter: Karthick >Assignee: ChunHao > Labels: beginner > Fix For: 3.0.0 > > Attachments: HBASE-18142.master.v0.patch, > HBASE-18142.master.v1.patch, HBASE-18142.master.v2.patch, > HBASE-18142.master.v3.patch, HBASE-18142.master.v4.patch, > HBASE-18142.master.v5.patch > > > When I tried to delete a cell using it's timestamp in the Hbase Shell, the > previous versions of the same cell also got deleted. But when I tried the > same using the Java API, then the previous versions are not deleted and I can > retrive the previous values. > https://github.com/apache/hbase/blob/master/hbase-client/src/main/java/org/apache/hadoop/hbase/client/Delete.java > see this file to fix the issue. This method (public Delete addColumns(final > byte [] family, final byte [] qualifier, final long timestamp)) only deletes > the current version of the cell. The previous versions are not deleted. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18518) Remove jersey1* dependencies form project and jersey1* jars from lib dir
[ https://issues.apache.org/jira/browse/HBASE-18518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Samir Ahmic updated HBASE-18518: Fix Version/s: 3.0.0 Status: Patch Available (was: Open) > Remove jersey1* dependencies form project and jersey1* jars from lib dir > > > Key: HBASE-18518 > URL: https://issues.apache.org/jira/browse/HBASE-18518 > Project: HBase > Issue Type: Task > Components: dependencies, pom, REST >Affects Versions: 2.0.0-alpha-1, 3.0.0 >Reporter: Samir Ahmic >Assignee: Samir Ahmic > Labels: cleanup > Fix For: 3.0.0 > > Attachments: HBASE-18518-master-01.patch > > > Recently i have opened https://issues.apache.org/jira/browse/HBASE-18506 and > it is clear that is caused by mixing jersey1 and jersey2 jars in classpath. > With https://issues.apache.org/jira/browse/HBASE-12894 we have introduced > jersey2 to project, and we also have bunch of transitive dependencies > (mainly from hadoop) on jersey1 which is not happiest situation since jersey1 > and jersey2 under same classpath can case runtime issues as it was case with > rest. > This task will have following steps > * Clean code and replace jersey1 constructs with jersey2 versions(there > should not be much of this) > * Add exclusions for transitive jersey1 dependencies in pom.xml > * Add exclusions in hadoop-two-compat.xml to prevent jersey1 jars in lib dir -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18518) Remove jersey1* dependencies form project and jersey1* jars from lib dir
[ https://issues.apache.org/jira/browse/HBASE-18518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115419#comment-16115419 ] Samir Ahmic commented on HBASE-18518: - Here is patch fixing issue with mixed jersey1 and jersey2 classes on REST project. After some digging i have find that we were using jersey1 classes only on few places in hbase code, main source of jersey1 dependency is hadoop and can not be removed completely since we are using it during testing in HBaseTestingUtility#startMiniDFSCluster() and similar functions which requires starting hadoop processes. This patch also resolves https://issues.apache.org/jira/browse/HBASE-18506. And i will resolve it once we finish work here > Remove jersey1* dependencies form project and jersey1* jars from lib dir > > > Key: HBASE-18518 > URL: https://issues.apache.org/jira/browse/HBASE-18518 > Project: HBase > Issue Type: Task > Components: dependencies, pom, REST >Affects Versions: 3.0.0, 2.0.0-alpha-1 >Reporter: Samir Ahmic >Assignee: Samir Ahmic > Labels: cleanup > Attachments: HBASE-18518-master-01.patch > > > Recently i have opened https://issues.apache.org/jira/browse/HBASE-18506 and > it is clear that is caused by mixing jersey1 and jersey2 jars in classpath. > With https://issues.apache.org/jira/browse/HBASE-12894 we have introduced > jersey2 to project, and we also have bunch of transitive dependencies > (mainly from hadoop) on jersey1 which is not happiest situation since jersey1 > and jersey2 under same classpath can case runtime issues as it was case with > rest. > This task will have following steps > * Clean code and replace jersey1 constructs with jersey2 versions(there > should not be much of this) > * Add exclusions for transitive jersey1 dependencies in pom.xml > * Add exclusions in hadoop-two-compat.xml to prevent jersey1 jars in lib dir -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18518) Remove jersey1* dependencies form project and jersey1* jars from lib dir
[ https://issues.apache.org/jira/browse/HBASE-18518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Samir Ahmic updated HBASE-18518: Attachment: HBASE-18518-master-01.patch > Remove jersey1* dependencies form project and jersey1* jars from lib dir > > > Key: HBASE-18518 > URL: https://issues.apache.org/jira/browse/HBASE-18518 > Project: HBase > Issue Type: Task > Components: dependencies, pom, REST >Affects Versions: 3.0.0, 2.0.0-alpha-1 >Reporter: Samir Ahmic >Assignee: Samir Ahmic > Labels: cleanup > Attachments: HBASE-18518-master-01.patch > > > Recently i have opened https://issues.apache.org/jira/browse/HBASE-18506 and > it is clear that is caused by mixing jersey1 and jersey2 jars in classpath. > With https://issues.apache.org/jira/browse/HBASE-12894 we have introduced > jersey2 to project, and we also have bunch of transitive dependencies > (mainly from hadoop) on jersey1 which is not happiest situation since jersey1 > and jersey2 under same classpath can case runtime issues as it was case with > rest. > This task will have following steps > * Clean code and replace jersey1 constructs with jersey2 versions(there > should not be much of this) > * Add exclusions for transitive jersey1 dependencies in pom.xml > * Add exclusions in hadoop-two-compat.xml to prevent jersey1 jars in lib dir -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18515) Introduce Delete.add as a replacement for Delete#addDeleteMarker
[
https://issues.apache.org/jira/browse/HBASE-18515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115401#comment-16115401
]
Xie YiFan commented on HBASE-18515:
---
Ok. Thank you for you advice.
> Introduce Delete.add as a replacement for Delete#addDeleteMarker
> -
>
> Key: HBASE-18515
> URL: https://issues.apache.org/jira/browse/HBASE-18515
> Project: HBase
> Issue Type: Task
> Components: Client
>Reporter: Chia-Ping Tsai
>Assignee: Xie YiFan
> Labels: beginner
> Fix For: 3.0.0, 2.0.0-alpha-2
>
> Attachments: HBASE-18515.master.v0.patch,
> HBASE-18515.master.v1.patch, HBASE-18515.master.v2.patch
>
>
> {quote}
> public Delete addDeleteMarker(Cell kv) throws IOException {
> // TODO: Deprecate and rename 'add' so it matches how we add KVs to Puts.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18515) Introduce Delete.add as a replacement for Delete#addDeleteMarker
[
https://issues.apache.org/jira/browse/HBASE-18515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115394#comment-16115394
]
Chia-Ping Tsai commented on HBASE-18515:
# Delete#addDeleteMarker being depredcated, you should move the implementation
from Delete#addDeleteMarker to Delete#add
# Please add comments for the @deprecated. The
[Append.add|https://github.com/apache/hbase/blob/master/hbase-client/src/main/java/org/apache/hadoop/hbase/client/Append.java#L108]
is a good reference.
> Introduce Delete.add as a replacement for Delete#addDeleteMarker
> -
>
> Key: HBASE-18515
> URL: https://issues.apache.org/jira/browse/HBASE-18515
> Project: HBase
> Issue Type: Task
> Components: Client
>Reporter: Chia-Ping Tsai
>Assignee: Xie YiFan
> Labels: beginner
> Fix For: 3.0.0, 2.0.0-alpha-2
>
> Attachments: HBASE-18515.master.v0.patch,
> HBASE-18515.master.v1.patch, HBASE-18515.master.v2.patch
>
>
> {quote}
> public Delete addDeleteMarker(Cell kv) throws IOException {
> // TODO: Deprecate and rename 'add' so it matches how we add KVs to Puts.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18142) Deletion of a cell deletes the previous versions too
[ https://issues.apache.org/jira/browse/HBASE-18142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115393#comment-16115393 ] Chia-Ping Tsai commented on HBASE-18142: [~mdrob] You addressed the ruby static analysis in HBASE-18239. Would you please take a look at this patch and the warnings? > Deletion of a cell deletes the previous versions too > > > Key: HBASE-18142 > URL: https://issues.apache.org/jira/browse/HBASE-18142 > Project: HBase > Issue Type: Bug > Components: API >Affects Versions: 3.0.0 >Reporter: Karthick >Assignee: ChunHao > Labels: beginner > Fix For: 3.0.0 > > Attachments: HBASE-18142.master.v0.patch, > HBASE-18142.master.v1.patch, HBASE-18142.master.v2.patch, > HBASE-18142.master.v3.patch, HBASE-18142.master.v4.patch, > HBASE-18142.master.v5.patch > > > When I tried to delete a cell using it's timestamp in the Hbase Shell, the > previous versions of the same cell also got deleted. But when I tried the > same using the Java API, then the previous versions are not deleted and I can > retrive the previous values. > https://github.com/apache/hbase/blob/master/hbase-client/src/main/java/org/apache/hadoop/hbase/client/Delete.java > see this file to fix the issue. This method (public Delete addColumns(final > byte [] family, final byte [] qualifier, final long timestamp)) only deletes > the current version of the cell. The previous versions are not deleted. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (HBASE-18471) Deleted qualifier re-appearing after multiple puts.
[
https://issues.apache.org/jira/browse/HBASE-18471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai reassigned HBASE-18471:
--
Assignee: Chia-Ping Tsai
> Deleted qualifier re-appearing after multiple puts.
> ---
>
> Key: HBASE-18471
> URL: https://issues.apache.org/jira/browse/HBASE-18471
> Project: HBase
> Issue Type: Bug
> Components: Deletes, hbase, scan
>Affects Versions: 3.0.0, 1.3.0, 1.3.1, 2.0.0-alpha-1
>Reporter: Thomas Martens
>Assignee: Chia-Ping Tsai
>Priority: Critical
> Attachments: HBaseDmlTest.java
>
>
> The qualifier of a deleted row (with keep deleted cells true) re-appears
> after re-inserting the same row multiple times (with different timestamp)
> with an empty qualifier.
> Scenario:
> # Put row with family and qualifier (timestamp 1).
> # Delete entire row (timestamp 2).
> # Put same row again with family without qualifier (timestamp 3).
> A scan (latest version) returns the row with family without qualifier,
> version 3 (which is correct).
> # Put the same row again with family without qualifier (timestamp 4).
> A scan (latest version) returns multiple rows:
> * the row with family without qualifier, version 4 (which is correct).
> * the row with family with qualifier, version 1 (which is wrong).
> There is a test scenario attached.
> output:
> 13:42:53,952 [main] client.HBaseAdmin - Started disable of test_dml
> 13:42:55,801 [main] client.HBaseAdmin - Disabled test_dml
> 13:42:57,256 [main] client.HBaseAdmin - Deleted test_dml
> 13:42:58,592 [main] client.HBaseAdmin - Created test_dml
> Put row: 'myRow' with family: 'myFamily' with qualifier: 'myQualifier' with
> timestamp: '1'
> Scan printout =>
> Row: 'myRow', Timestamp: '1', Family: 'myFamily', Qualifier: 'myQualifier',
> Value: 'myValue'
> Delete row: 'myRow'
> Scan printout =>
> Put row: 'myRow' with family: 'myFamily' with qualifier: 'null' with
> timestamp: '3'
> Scan printout =>
> Row: 'myRow', Timestamp: '3', Family: 'myFamily', Qualifier: '', Value:
> 'myValue'
> Put row: 'myRow' with family: 'myFamily' with qualifier: 'null' with
> timestamp: '4'
> Scan printout =>
> Row: 'myRow', Timestamp: '4', Family: 'myFamily', Qualifier: '', Value:
> 'myValue'
> {color:red}Row: 'myRow', Timestamp: '1', Family: 'myFamily', Qualifier:
> 'myQualifier', Value: 'myValue'{color}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18525) TestAssignmentManager#testSocketTimeout fails in master branch
[
https://issues.apache.org/jira/browse/HBASE-18525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-18525:
---
Status: Patch Available (was: Open)
> TestAssignmentManager#testSocketTimeout fails in master branch
> --
>
> Key: HBASE-18525
> URL: https://issues.apache.org/jira/browse/HBASE-18525
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Attachments: 18525.v1.txt
>
>
> Toward the end of the test output, I saw:
> {code}
> 2017-08-05 03:30:16,591 INFO [Time-limited test]
> assignment.TestAssignmentManager(446): ExecutionException
> java.util.concurrent.ExecutionException:
> org.apache.hadoop.hbase.master.procedure.ServerCrashException:
> ServerCrashProcedure pid=3, server=localhost,103,1
> at
> org.apache.hadoop.hbase.master.procedure.ProcedureSyncWait$ProcedureFuture.get(ProcedureSyncWait.java:104)
> at
> org.apache.hadoop.hbase.master.procedure.ProcedureSyncWait$ProcedureFuture.get(ProcedureSyncWait.java:62)
> at
> org.apache.hadoop.hbase.master.assignment.TestAssignmentManager.waitOnFuture(TestAssignmentManager.java:444)
> at
> org.apache.hadoop.hbase.master.assignment.TestAssignmentManager.testSocketTimeout(TestAssignmentManager.java:255)
> 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.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at
> org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:298)
> at
> org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:292)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.hadoop.hbase.master.procedure.ServerCrashException:
> ServerCrashProcedure pid=3, server=localhost,103,1
> at
> org.apache.hadoop.hbase.master.assignment.UnassignProcedure.updateTransition(UnassignProcedure.java:169)
> at
> org.apache.hadoop.hbase.master.assignment.RegionTransitionProcedure.execute(RegionTransitionProcedure.java:274)
> at
> org.apache.hadoop.hbase.master.assignment.RegionTransitionProcedure.execute(RegionTransitionProcedure.java:57)
> at
> org.apache.hadoop.hbase.procedure2.Procedure.doExecute(Procedure.java:847)
> at
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor.execProcedure(ProcedureExecutor.java:1440)
> at
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor.executeProcedure(ProcedureExecutor.java:1209)
> at
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor.access$800(ProcedureExecutor.java:79)
> at
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor$WorkerThread.run(ProcedureExecutor.java:1719)
> {code}
> This test failure seems to happen after HBASE-18491 was checked in.
> Looking at the change in UnassignProcedure, it seems we should handle the two
> conditions differently:
> {code}
> if (serverCrashed.get() || !isServerOnline(env, regionNode)) {
> {code}
> With attached patch, TestAssignmentManager#testSocketTimeout and
> TestServerCrashProcedure#testRecoveryAndDoubleExecutionOnRsWithMeta pass.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18525) TestAssignmentManager#testSocketTimeout fails in master branch
[
https://issues.apache.org/jira/browse/HBASE-18525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-18525:
---
Attachment: 18525.v1.txt
[~uagashe]:
Can you take a look at the patch ?
> TestAssignmentManager#testSocketTimeout fails in master branch
> --
>
> Key: HBASE-18525
> URL: https://issues.apache.org/jira/browse/HBASE-18525
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Attachments: 18525.v1.txt
>
>
> Toward the end of the test output, I saw:
> {code}
> 2017-08-05 03:30:16,591 INFO [Time-limited test]
> assignment.TestAssignmentManager(446): ExecutionException
> java.util.concurrent.ExecutionException:
> org.apache.hadoop.hbase.master.procedure.ServerCrashException:
> ServerCrashProcedure pid=3, server=localhost,103,1
> at
> org.apache.hadoop.hbase.master.procedure.ProcedureSyncWait$ProcedureFuture.get(ProcedureSyncWait.java:104)
> at
> org.apache.hadoop.hbase.master.procedure.ProcedureSyncWait$ProcedureFuture.get(ProcedureSyncWait.java:62)
> at
> org.apache.hadoop.hbase.master.assignment.TestAssignmentManager.waitOnFuture(TestAssignmentManager.java:444)
> at
> org.apache.hadoop.hbase.master.assignment.TestAssignmentManager.testSocketTimeout(TestAssignmentManager.java:255)
> 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.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at
> org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:298)
> at
> org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:292)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.hadoop.hbase.master.procedure.ServerCrashException:
> ServerCrashProcedure pid=3, server=localhost,103,1
> at
> org.apache.hadoop.hbase.master.assignment.UnassignProcedure.updateTransition(UnassignProcedure.java:169)
> at
> org.apache.hadoop.hbase.master.assignment.RegionTransitionProcedure.execute(RegionTransitionProcedure.java:274)
> at
> org.apache.hadoop.hbase.master.assignment.RegionTransitionProcedure.execute(RegionTransitionProcedure.java:57)
> at
> org.apache.hadoop.hbase.procedure2.Procedure.doExecute(Procedure.java:847)
> at
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor.execProcedure(ProcedureExecutor.java:1440)
> at
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor.executeProcedure(ProcedureExecutor.java:1209)
> at
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor.access$800(ProcedureExecutor.java:79)
> at
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor$WorkerThread.run(ProcedureExecutor.java:1719)
> {code}
> This test failure seems to happen after HBASE-18491 was checked in.
> Looking at the change in UnassignProcedure, it seems we should handle the two
> conditions differently:
> {code}
> if (serverCrashed.get() || !isServerOnline(env, regionNode)) {
> {code}
> With attached patch, TestAssignmentManager#testSocketTimeout and
> TestServerCrashProcedure#testRecoveryAndDoubleExecutionOnRsWithMeta pass.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (HBASE-18525) TestAssignmentManager#testSocketTimeout fails in master branch
Ted Yu created HBASE-18525:
--
Summary: TestAssignmentManager#testSocketTimeout fails in master
branch
Key: HBASE-18525
URL: https://issues.apache.org/jira/browse/HBASE-18525
Project: HBase
Issue Type: Bug
Reporter: Ted Yu
Assignee: Ted Yu
Toward the end of the test output, I saw:
{code}
2017-08-05 03:30:16,591 INFO [Time-limited test]
assignment.TestAssignmentManager(446): ExecutionException
java.util.concurrent.ExecutionException:
org.apache.hadoop.hbase.master.procedure.ServerCrashException:
ServerCrashProcedure pid=3, server=localhost,103,1
at
org.apache.hadoop.hbase.master.procedure.ProcedureSyncWait$ProcedureFuture.get(ProcedureSyncWait.java:104)
at
org.apache.hadoop.hbase.master.procedure.ProcedureSyncWait$ProcedureFuture.get(ProcedureSyncWait.java:62)
at
org.apache.hadoop.hbase.master.assignment.TestAssignmentManager.waitOnFuture(TestAssignmentManager.java:444)
at
org.apache.hadoop.hbase.master.assignment.TestAssignmentManager.testSocketTimeout(TestAssignmentManager.java:255)
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.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at
org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:298)
at
org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:292)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.hadoop.hbase.master.procedure.ServerCrashException:
ServerCrashProcedure pid=3, server=localhost,103,1
at
org.apache.hadoop.hbase.master.assignment.UnassignProcedure.updateTransition(UnassignProcedure.java:169)
at
org.apache.hadoop.hbase.master.assignment.RegionTransitionProcedure.execute(RegionTransitionProcedure.java:274)
at
org.apache.hadoop.hbase.master.assignment.RegionTransitionProcedure.execute(RegionTransitionProcedure.java:57)
at org.apache.hadoop.hbase.procedure2.Procedure.doExecute(Procedure.java:847)
at
org.apache.hadoop.hbase.procedure2.ProcedureExecutor.execProcedure(ProcedureExecutor.java:1440)
at
org.apache.hadoop.hbase.procedure2.ProcedureExecutor.executeProcedure(ProcedureExecutor.java:1209)
at
org.apache.hadoop.hbase.procedure2.ProcedureExecutor.access$800(ProcedureExecutor.java:79)
at
org.apache.hadoop.hbase.procedure2.ProcedureExecutor$WorkerThread.run(ProcedureExecutor.java:1719)
{code}
This test failure seems to happen after HBASE-18491 was checked in.
Looking at the change in UnassignProcedure, it seems we should handle the two
conditions differently:
{code}
if (serverCrashed.get() || !isServerOnline(env, regionNode)) {
{code}
With attached patch, TestAssignmentManager#testSocketTimeout and
TestServerCrashProcedure#testRecoveryAndDoubleExecutionOnRsWithMeta pass.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Issue Comment Deleted] (HBASE-18142) Deletion of a cell deletes the previous versions too
[ https://issues.apache.org/jira/browse/HBASE-18142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ChunHao updated HBASE-18142: Comment: was deleted (was: One of the rules of current rubocop is _Class has too many lines_. [573/100], but in the past rubocop, it seems doesn't have this rule. Does the current rubocop have a wrong config?) > Deletion of a cell deletes the previous versions too > > > Key: HBASE-18142 > URL: https://issues.apache.org/jira/browse/HBASE-18142 > Project: HBase > Issue Type: Bug > Components: API >Affects Versions: 3.0.0 >Reporter: Karthick >Assignee: ChunHao > Labels: beginner > Fix For: 3.0.0 > > Attachments: HBASE-18142.master.v0.patch, > HBASE-18142.master.v1.patch, HBASE-18142.master.v2.patch, > HBASE-18142.master.v3.patch, HBASE-18142.master.v4.patch, > HBASE-18142.master.v5.patch > > > When I tried to delete a cell using it's timestamp in the Hbase Shell, the > previous versions of the same cell also got deleted. But when I tried the > same using the Java API, then the previous versions are not deleted and I can > retrive the previous values. > https://github.com/apache/hbase/blob/master/hbase-client/src/main/java/org/apache/hadoop/hbase/client/Delete.java > see this file to fix the issue. This method (public Delete addColumns(final > byte [] family, final byte [] qualifier, final long timestamp)) only deletes > the current version of the cell. The previous versions are not deleted. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18517) limit max log message width in log4j
[
https://issues.apache.org/jira/browse/HBASE-18517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115375#comment-16115375
]
Vikas Vishwakarma commented on HBASE-18517:
---
thanks [~stack] added a patch with 1k message width limit. At present we are
still investigating the issue seen in our setup, will update if we see
additional issues.
> limit max log message width in log4j
>
>
> Key: HBASE-18517
> URL: https://issues.apache.org/jira/browse/HBASE-18517
> Project: HBase
> Issue Type: Bug
>Affects Versions: 3.0.0, 1.5.0
>Reporter: Vikas Vishwakarma
>Assignee: Vikas Vishwakarma
> Fix For: 3.0.0, 1.5.0
>
> Attachments: HBASE-18374.master.001.patch,
> HBASE-18517.branch-1.001.patch
>
>
> We had two cases now in our prod / pilot setups which is leading to humongous
> log lines in RegionServer logs.
> In first case, one of the phoenix user had constructed a query with a really
> large list of Id filters (61 MB) that translated into HBase scan that was
> running slow which lead to responseTooSlow messages in the logs with the
> entire filter list being printed in the logs, example
> ipc.RpcServer - (responseTooSlow):
> {"call":"Scan(org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ScanRequest)","starttimems":1501457864417,"responsesize":11,"method":"Scan","param":"region
> { type: REGION_NAME value: .
> org.apache.hadoop.hbase.filter.FirstKeyOnlyFilter\\022\351\\200\\036\\n(org.apache.phoenix.filter.SkipScanFilter
> ... ...
> There was another case where a use case had created a table with really large
> key/region names. This was causing humongous log lines for flush and
> compaction on these regions filling up the RS logs
> These large logs usually cause issues with disk I/O load, loading the splunk
> servers, even machine perf degradations. With 61 MB log lines basic log
> processing commands like vim, scrolling the logs, wc -l , etc were getting
> stuck. High GC activity was also noted on this cluster although not 100% sure
> if it was related to above issue.
> We should consider limiting the message size in logs which can be easily done
> by adding a maximum width format modifier on the message conversion character
> in log4j.properties
> log4j.appender.console.layout.ConversionPattern=...: %m%n
> to
> log4j.appender.console.layout.ConversionPattern=...: %.1m%n
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18524) Test reenabling Master carrying regions
[ https://issues.apache.org/jira/browse/HBASE-18524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-18524: -- Priority: Blocker (was: Major) > Test reenabling Master carrying regions > --- > > Key: HBASE-18524 > URL: https://issues.apache.org/jira/browse/HBASE-18524 > Project: HBase > Issue Type: Sub-task > Components: master >Reporter: stack >Priority: Blocker > Fix For: 2.0.0 > > > This issue is to ensure that it is still possible to configure Master to > carry tables. Further, it should be possible to configure Master to carry > system tables only with Master doing short-circuit ops -- going directly to > the internal RS methods w/o going via RPC -- when accessing system tables. > We also need a mechanism for specifying that the Master can carry any region, > not just system table regions. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-18524) Test reenabling Master carrying regions
stack created HBASE-18524: - Summary: Test reenabling Master carrying regions Key: HBASE-18524 URL: https://issues.apache.org/jira/browse/HBASE-18524 Project: HBase Issue Type: Sub-task Reporter: stack This issue is to ensure that it is still possible to configure Master to carry tables. Further, it should be possible to configure Master to carry system tables only with Master doing short-circuit ops -- going directly to the internal RS methods w/o going via RPC -- when accessing system tables. We also need a mechanism for specifying that the Master can carry any region, not just system table regions. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18517) limit max log message width in log4j
[
https://issues.apache.org/jira/browse/HBASE-18517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Vishwakarma updated HBASE-18517:
--
Fix Version/s: 1.5.0
3.0.0
Affects Version/s: 1.5.0
3.0.0
Status: Patch Available (was: Open)
QA run
> limit max log message width in log4j
>
>
> Key: HBASE-18517
> URL: https://issues.apache.org/jira/browse/HBASE-18517
> Project: HBase
> Issue Type: Bug
>Affects Versions: 3.0.0, 1.5.0
>Reporter: Vikas Vishwakarma
>Assignee: Vikas Vishwakarma
> Fix For: 3.0.0, 1.5.0
>
> Attachments: HBASE-18374.master.001.patch,
> HBASE-18517.branch-1.001.patch
>
>
> We had two cases now in our prod / pilot setups which is leading to humongous
> log lines in RegionServer logs.
> In first case, one of the phoenix user had constructed a query with a really
> large list of Id filters (61 MB) that translated into HBase scan that was
> running slow which lead to responseTooSlow messages in the logs with the
> entire filter list being printed in the logs, example
> ipc.RpcServer - (responseTooSlow):
> {"call":"Scan(org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ScanRequest)","starttimems":1501457864417,"responsesize":11,"method":"Scan","param":"region
> { type: REGION_NAME value: .
> org.apache.hadoop.hbase.filter.FirstKeyOnlyFilter\\022\351\\200\\036\\n(org.apache.phoenix.filter.SkipScanFilter
> ... ...
> There was another case where a use case had created a table with really large
> key/region names. This was causing humongous log lines for flush and
> compaction on these regions filling up the RS logs
> These large logs usually cause issues with disk I/O load, loading the splunk
> servers, even machine perf degradations. With 61 MB log lines basic log
> processing commands like vim, scrolling the logs, wc -l , etc were getting
> stuck. High GC activity was also noted on this cluster although not 100% sure
> if it was related to above issue.
> We should consider limiting the message size in logs which can be easily done
> by adding a maximum width format modifier on the message conversion character
> in log4j.properties
> log4j.appender.console.layout.ConversionPattern=...: %m%n
> to
> log4j.appender.console.layout.ConversionPattern=...: %.1m%n
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18511) Default no regions on master
[ https://issues.apache.org/jira/browse/HBASE-18511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-18511: -- Description: Let this be umbrella issue for no-regions-on-master as default deploy (as it was in branch-1). Also need to make sure we can run WITH regions on master; in particular system tables with RPC short-circuit as it is now in hbase master. Background is that master branch carried a change that allowed Master carry regions. On top of this improvement on branch-1, Master defaulted to carry system tables only. No release was made with this configuration. Now we are going to cut the 2.0.0 release, the decision is that hbase-2 should have the same layout as hbase-1 so this issue implements the undoing of Master carrying system tables by default (though the capability remains). was: Let this be umbrella issue for no-regions-on-master as default deploy (as it was in branch-1). Also need to make sure we can run WITH regions on master; in particular system tables with RPC short-circuit as it is now in hbase master. > Default no regions on master > > > Key: HBASE-18511 > URL: https://issues.apache.org/jira/browse/HBASE-18511 > Project: HBase > Issue Type: Task > Components: master >Reporter: stack >Assignee: stack >Priority: Blocker > Fix For: 2.0.0 > > Attachments: HBASE-18511.master.001.patch > > > Let this be umbrella issue for no-regions-on-master as default deploy (as it > was in branch-1). > Also need to make sure we can run WITH regions on master; in particular > system tables with RPC short-circuit as it is now in hbase master. > Background is that master branch carried a change that allowed Master carry > regions. On top of this improvement on branch-1, Master defaulted to carry > system tables only. No release was made with this configuration. Now we are > going to cut the 2.0.0 release, the decision is that hbase-2 should have the > same layout as hbase-1 so this issue implements the undoing of Master > carrying system tables by default (though the capability remains). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18517) limit max log message width in log4j
[
https://issues.apache.org/jira/browse/HBASE-18517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Vishwakarma updated HBASE-18517:
--
Attachment: HBASE-18374.master.001.patch
HBASE-18517.branch-1.001.patch
> limit max log message width in log4j
>
>
> Key: HBASE-18517
> URL: https://issues.apache.org/jira/browse/HBASE-18517
> Project: HBase
> Issue Type: Bug
>Reporter: Vikas Vishwakarma
>Assignee: Vikas Vishwakarma
> Attachments: HBASE-18374.master.001.patch,
> HBASE-18517.branch-1.001.patch
>
>
> We had two cases now in our prod / pilot setups which is leading to humongous
> log lines in RegionServer logs.
> In first case, one of the phoenix user had constructed a query with a really
> large list of Id filters (61 MB) that translated into HBase scan that was
> running slow which lead to responseTooSlow messages in the logs with the
> entire filter list being printed in the logs, example
> ipc.RpcServer - (responseTooSlow):
> {"call":"Scan(org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ScanRequest)","starttimems":1501457864417,"responsesize":11,"method":"Scan","param":"region
> { type: REGION_NAME value: .
> org.apache.hadoop.hbase.filter.FirstKeyOnlyFilter\\022\351\\200\\036\\n(org.apache.phoenix.filter.SkipScanFilter
> ... ...
> There was another case where a use case had created a table with really large
> key/region names. This was causing humongous log lines for flush and
> compaction on these regions filling up the RS logs
> These large logs usually cause issues with disk I/O load, loading the splunk
> servers, even machine perf degradations. With 61 MB log lines basic log
> processing commands like vim, scrolling the logs, wc -l , etc were getting
> stuck. High GC activity was also noted on this cluster although not 100% sure
> if it was related to above issue.
> We should consider limiting the message size in logs which can be easily done
> by adding a maximum width format modifier on the message conversion character
> in log4j.properties
> log4j.appender.console.layout.ConversionPattern=...: %m%n
> to
> log4j.appender.console.layout.ConversionPattern=...: %.1m%n
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18142) Deletion of a cell deletes the previous versions too
[ https://issues.apache.org/jira/browse/HBASE-18142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ChunHao updated HBASE-18142: Status: Patch Available (was: Open) > Deletion of a cell deletes the previous versions too > > > Key: HBASE-18142 > URL: https://issues.apache.org/jira/browse/HBASE-18142 > Project: HBase > Issue Type: Bug > Components: API >Affects Versions: 3.0.0 >Reporter: Karthick >Assignee: ChunHao > Labels: beginner > Fix For: 3.0.0 > > Attachments: HBASE-18142.master.v0.patch, > HBASE-18142.master.v1.patch, HBASE-18142.master.v2.patch, > HBASE-18142.master.v3.patch, HBASE-18142.master.v4.patch, > HBASE-18142.master.v5.patch > > > When I tried to delete a cell using it's timestamp in the Hbase Shell, the > previous versions of the same cell also got deleted. But when I tried the > same using the Java API, then the previous versions are not deleted and I can > retrive the previous values. > https://github.com/apache/hbase/blob/master/hbase-client/src/main/java/org/apache/hadoop/hbase/client/Delete.java > see this file to fix the issue. This method (public Delete addColumns(final > byte [] family, final byte [] qualifier, final long timestamp)) only deletes > the current version of the cell. The previous versions are not deleted. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18142) Deletion of a cell deletes the previous versions too
[ https://issues.apache.org/jira/browse/HBASE-18142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ChunHao updated HBASE-18142: Attachment: HBASE-18142.master.v5.patch > Deletion of a cell deletes the previous versions too > > > Key: HBASE-18142 > URL: https://issues.apache.org/jira/browse/HBASE-18142 > Project: HBase > Issue Type: Bug > Components: API >Affects Versions: 3.0.0 >Reporter: Karthick >Assignee: ChunHao > Labels: beginner > Fix For: 3.0.0 > > Attachments: HBASE-18142.master.v0.patch, > HBASE-18142.master.v1.patch, HBASE-18142.master.v2.patch, > HBASE-18142.master.v3.patch, HBASE-18142.master.v4.patch, > HBASE-18142.master.v5.patch > > > When I tried to delete a cell using it's timestamp in the Hbase Shell, the > previous versions of the same cell also got deleted. But when I tried the > same using the Java API, then the previous versions are not deleted and I can > retrive the previous values. > https://github.com/apache/hbase/blob/master/hbase-client/src/main/java/org/apache/hadoop/hbase/client/Delete.java > see this file to fix the issue. This method (public Delete addColumns(final > byte [] family, final byte [] qualifier, final long timestamp)) only deletes > the current version of the cell. The previous versions are not deleted. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18142) Deletion of a cell deletes the previous versions too
[ https://issues.apache.org/jira/browse/HBASE-18142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ChunHao updated HBASE-18142: Status: Open (was: Patch Available) > Deletion of a cell deletes the previous versions too > > > Key: HBASE-18142 > URL: https://issues.apache.org/jira/browse/HBASE-18142 > Project: HBase > Issue Type: Bug > Components: API >Affects Versions: 3.0.0 >Reporter: Karthick >Assignee: ChunHao > Labels: beginner > Fix For: 3.0.0 > > Attachments: HBASE-18142.master.v0.patch, > HBASE-18142.master.v1.patch, HBASE-18142.master.v2.patch, > HBASE-18142.master.v3.patch, HBASE-18142.master.v4.patch, > HBASE-18142.master.v5.patch > > > When I tried to delete a cell using it's timestamp in the Hbase Shell, the > previous versions of the same cell also got deleted. But when I tried the > same using the Java API, then the previous versions are not deleted and I can > retrive the previous values. > https://github.com/apache/hbase/blob/master/hbase-client/src/main/java/org/apache/hadoop/hbase/client/Delete.java > see this file to fix the issue. This method (public Delete addColumns(final > byte [] family, final byte [] qualifier, final long timestamp)) only deletes > the current version of the cell. The previous versions are not deleted. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-17312) [JDK8] Use default method for Observer Coprocessors
[
https://issues.apache.org/jira/browse/HBASE-17312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-17312:
--
Hadoop Flags: Incompatible change,Reviewed
Marking as incompatible change.
> [JDK8] Use default method for Observer Coprocessors
> ---
>
> Key: HBASE-17312
> URL: https://issues.apache.org/jira/browse/HBASE-17312
> Project: HBase
> Issue Type: Sub-task
> Components: Coprocessors
>Affects Versions: 2.0.0
>Reporter: Guanghao Zhang
>Assignee: Appy
> Labels: incompatible
> Fix For: 2.0.0
>
> Attachments: HBASE-17312.master.001.patch,
> HBASE-17312.master.001.patch, HBASE-17312.master.002.patch,
> HBASE-17312.master.003.patch, HBASE-17312.master.004.patch,
> HBASE-17312.master.005.patch, HBASE-17312.master.006.patch
>
>
> In cases where one might need to use multiple observers, say region, master
> and regionserver; and the fact that only one class can be extended, it gives
> rise to following pattern:
> {noformat}
> public class BaseMasterAndRegionObserver
> extends BaseRegionObserver
> implements MasterObserver
> class AccessController
> extends BaseMasterAndRegionObserver
> implements RegionServerObserver
> {noformat}
> were BaseMasterAndRegionObserver is full copy of BaseMasterObserver.
> There is an example of simple case too where the current design fails.
> Say only one observer is needed by the coprocessor, but the design doesn't
> permit extending even that single observer (see RSGroupAdminEndpoint), that
> leads to full copy of Base...Observer class into coprocessor class leading to
> 1000s of lines of code and this ugly mix of 5 main functions with 100 useless
> functions.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18125) HBase shell disregards spaces at the end of a split key in a split file
[
https://issues.apache.org/jira/browse/HBASE-18125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115320#comment-16115320
]
Chenxi Tong commented on HBASE-18125:
-
Hi Ashu, I want to solve this issue. Could you help assign this issue to me?
Thanks a lot!
> HBase shell disregards spaces at the end of a split key in a split file
> ---
>
> Key: HBASE-18125
> URL: https://issues.apache.org/jira/browse/HBASE-18125
> Project: HBase
> Issue Type: Bug
> Components: shell
>Affects Versions: 2.0.0, 1.3.1
>Reporter: Ashu Pachauri
> Labels: beginner
>
> When converting row keys to a printable string representation, Bytes class
> considers SPACE as a printable character, so it prints it out as it is. So,
> it's quite possible that a row key has a space at the end.
> When specifying split points in a file, the row keys are not quoted and the
> shell wrapper "admin.rb" strips any whitespace off the row keys:
> {code}
> File.foreach(splits_file) do |line|
> arg[SPLITS].push(line.strip())
> end
> {code}
> The correct approach is to use "chomp()" instead of "strip()" to just strip
> off carriage returns and newlines. We should assume that the hbase user is
> either using split points printed out by hbase itself (which will not have
> tabs) or is diligent enough to not use tabs at the end of a split point.
> What's worse is that it goes undetected and will result in undesirable split
> points.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-15042) refactor so that site materials are in the Standard Maven Place
[
https://issues.apache.org/jira/browse/HBASE-15042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-15042:
--
Resolution: Fixed
Hadoop Flags: Reviewed
Status: Resolved (was: Patch Available)
Pushed to master branch. Thanks for the work [~Jan Hentschel] (and input
[~misty])
> refactor so that site materials are in the Standard Maven Place
> ---
>
> Key: HBASE-15042
> URL: https://issues.apache.org/jira/browse/HBASE-15042
> Project: HBase
> Issue Type: Task
> Components: build, website
>Reporter: Sean Busbey
>Assignee: Jan Hentschel
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-15042.master.001.patch,
> HBASE-15042.master.002.patch, HBASE-15042.master.002.patch,
> HBASE-15042.master.003.patch
>
>
> for some reason we currently have our site materials in {{src/main/site}}
> rather than the maven prescribed {{src/site}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18511) Default no regions on master
[ https://issues.apache.org/jira/browse/HBASE-18511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115312#comment-16115312 ] stack commented on HBASE-18511: --- [~zyork] Thanks for review. Let me do as you suggest. Agree this is a big one for the migration doc. > Default no regions on master > > > Key: HBASE-18511 > URL: https://issues.apache.org/jira/browse/HBASE-18511 > Project: HBase > Issue Type: Task > Components: master >Reporter: stack >Assignee: stack >Priority: Blocker > Fix For: 2.0.0 > > Attachments: HBASE-18511.master.001.patch > > > Let this be umbrella issue for no-regions-on-master as default deploy (as it > was in branch-1). > Also need to make sure we can run WITH regions on master; in particular > system tables with RPC short-circuit as it is now in hbase master. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
