[jira] [Commented] (HBASE-17174) Refactor the AsyncProcess
[
https://issues.apache.org/jira/browse/HBASE-17174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15756688#comment-15756688
]
Hadoop QA commented on HBASE-17174:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 7s
{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 7 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 18s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
47s {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
47s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
26s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
53s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 51s
{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 12s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
11s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 2s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 2s
{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
23s {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}
27m 40s {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-alpha1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
44s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 49s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 6s
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 97m 42s
{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
28s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 143m 50s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.11.2 Server=1.11.2 Image:yetus/hbase:8d52d23 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12843703/HBASE-17174.v11.patch
|
| JIRA Issue | HBASE-17174 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux acb8fc0b250c 3.13.0-105-generic #152-Ubuntu SMP Fri Dec 2
15:37:11 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / da35606 |
| Default Java | 1.8.0_111 |
| findbugs | v3.0.0 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/4961/testReport/ |
| modules | C: hbase-client hbase-server U: . |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/4961/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> Refactor the AsyncProcess
> ---
[jira] [Commented] (HBASE-11392) add/remove peer requests should be routed through master
[
https://issues.apache.org/jira/browse/HBASE-11392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15756722#comment-15756722
]
Hadoop QA commented on HBASE-11392:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 13s
{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 9 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 22s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
3s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 16s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 10m
36s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
31s {color} | {color:green} master passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 1m 54s
{color} | {color:red} hbase-protocol-shaded in master has 24 extant Findbugs
warnings. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 48s
{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 11s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
24s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 16s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 1m 16s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 16s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 10m
20s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
28s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m 0s
{color} | {color:red} The patch has 15 line(s) that end in whitespace. Use git
apply --whitespace=fix. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
25m 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-alpha1. {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green} 0m
59s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
59s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 48s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 26s
{color} | {color:green} hbase-protocol-shaded in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 56s
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 90m 7s {color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
38s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 159m 52s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.regionserver.TestAtomicOperation |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.11.2 Server=1.11.2 Image:yetus/hbase:8d52d23 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12843704/HBASE-11392-v4.patch |
| JIRA Issue | HBASE-11392 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile cc hbaseprotoc |
| uname | Linux 407438f007a3 3.13.0-103-generic #150-Ubuntu SMP Thu Nov 24
10:34:17 UTC 2016 x86_64 x86_64 x86_64 GNU/Lin
[jira] [Updated] (HBASE-17174) Refactor the AsyncProcess, BufferedMutatorImpl, and HTable
[ https://issues.apache.org/jira/browse/HBASE-17174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ChiaPing Tsai updated HBASE-17174: -- Description: The following are reasons of refactoring. # A update-heavy application, for example, loader, creates many BufferedMutator for batch updates. But these BufferedMutators can’t share a large threadpool because the shutdown() method will be called when closing any BufferedMutator. This patch adds a flag into BufferedMutatorParams for preventing calling the shutdown() method in BufferedMutatorImpl#close # The AsyncProcess has the powerful traffic control, but the control is against the single table currently. We should allow alternate traffic control implementation for advanced user who want more control. All suggestions are welcome. was: The following are reasons of refactoring the AP. # A update-heavy application, for example, loader, creates many BufferedMutator for batch updates. But these BufferedMutators can’t share a large threadpool because the shutdown() method will be called when closing any BufferedMutator. This patch adds a flag into BufferedMutatorParams for preventing calling the shutdown() method in BufferedMutatorImpl#close # The AsyncProcess has the powerful traffic control, but the control is against the single table currently. We should allow alternate traffic control implementation for advanced user who want more control. All suggestions are welcome. > Refactor the AsyncProcess, BufferedMutatorImpl, and HTable > -- > > Key: HBASE-17174 > URL: https://issues.apache.org/jira/browse/HBASE-17174 > Project: HBase > Issue Type: New Feature >Affects Versions: 2.0.0 >Reporter: ChiaPing Tsai >Assignee: ChiaPing Tsai >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-17174.v0.patch, HBASE-17174.v1.patch, > HBASE-17174.v10.patch, HBASE-17174.v11.patch, HBASE-17174.v11.patch, > HBASE-17174.v11.patch, HBASE-17174.v2.patch, HBASE-17174.v3.patch, > HBASE-17174.v4.patch, HBASE-17174.v5.patch, HBASE-17174.v6.patch, > HBASE-17174.v7.patch, HBASE-17174.v8.patch, HBASE-17174.v9.patch > > > The following are reasons of refactoring. > # A update-heavy application, for example, loader, creates many > BufferedMutator for batch updates. But these BufferedMutators can’t share a > large threadpool because the shutdown() method will be called when closing > any BufferedMutator. This patch adds a flag into BufferedMutatorParams for > preventing calling the shutdown() method in BufferedMutatorImpl#close > # The AsyncProcess has the powerful traffic control, but the control is > against the single table currently. We should allow alternate traffic control > implementation for advanced user who want more control. > All suggestions are welcome. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-17174) Refactor the AsyncProcess, BufferedMutatorImpl, and HTable
[ https://issues.apache.org/jira/browse/HBASE-17174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ChiaPing Tsai updated HBASE-17174: -- Summary: Refactor the AsyncProcess, BufferedMutatorImpl, and HTable (was: Refactor the AsyncProcess) > Refactor the AsyncProcess, BufferedMutatorImpl, and HTable > -- > > Key: HBASE-17174 > URL: https://issues.apache.org/jira/browse/HBASE-17174 > Project: HBase > Issue Type: New Feature >Affects Versions: 2.0.0 >Reporter: ChiaPing Tsai >Assignee: ChiaPing Tsai >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-17174.v0.patch, HBASE-17174.v1.patch, > HBASE-17174.v10.patch, HBASE-17174.v11.patch, HBASE-17174.v11.patch, > HBASE-17174.v11.patch, HBASE-17174.v2.patch, HBASE-17174.v3.patch, > HBASE-17174.v4.patch, HBASE-17174.v5.patch, HBASE-17174.v6.patch, > HBASE-17174.v7.patch, HBASE-17174.v8.patch, HBASE-17174.v9.patch > > > The following are reasons of refactoring the AP. > # A update-heavy application, for example, loader, creates many > BufferedMutator for batch updates. But these BufferedMutators can’t share a > large threadpool because the shutdown() method will be called when closing > any BufferedMutator. This patch adds a flag into BufferedMutatorParams for > preventing calling the shutdown() method in BufferedMutatorImpl#close > # The AsyncProcess has the powerful traffic control, but the control is > against the single table currently. We should allow alternate traffic control > implementation for advanced user who want more control. > All suggestions are welcome. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-17174) Refactor the AsyncProcess, BufferedMutatorImpl, and HTable
[ https://issues.apache.org/jira/browse/HBASE-17174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15756727#comment-15756727 ] ChiaPing Tsai commented on HBASE-17174: --- [~Apache9] Would you please review the v11 patch if you are available. > Refactor the AsyncProcess, BufferedMutatorImpl, and HTable > -- > > Key: HBASE-17174 > URL: https://issues.apache.org/jira/browse/HBASE-17174 > Project: HBase > Issue Type: New Feature >Affects Versions: 2.0.0 >Reporter: ChiaPing Tsai >Assignee: ChiaPing Tsai >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-17174.v0.patch, HBASE-17174.v1.patch, > HBASE-17174.v10.patch, HBASE-17174.v11.patch, HBASE-17174.v11.patch, > HBASE-17174.v11.patch, HBASE-17174.v2.patch, HBASE-17174.v3.patch, > HBASE-17174.v4.patch, HBASE-17174.v5.patch, HBASE-17174.v6.patch, > HBASE-17174.v7.patch, HBASE-17174.v8.patch, HBASE-17174.v9.patch > > > The following are reasons of refactoring. > # A update-heavy application, for example, loader, creates many > BufferedMutator for batch updates. But these BufferedMutators can’t share a > large threadpool because the shutdown() method will be called when closing > any BufferedMutator. This patch adds a flag into BufferedMutatorParams for > preventing calling the shutdown() method in BufferedMutatorImpl#close > # The AsyncProcess has the powerful traffic control, but the control is > against the single table currently. We should allow alternate traffic control > implementation for advanced user who want more control. > All suggestions are welcome. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-17330) SnapshotFileCache will always refresh the file cache
Jianwei Cui created HBASE-17330:
---
Summary: SnapshotFileCache will always refresh the file cache
Key: HBASE-17330
URL: https://issues.apache.org/jira/browse/HBASE-17330
Project: HBase
Issue Type: Bug
Components: snapshots
Affects Versions: 0.98.23, 2.0.0, 1.3.1
Reporter: Jianwei Cui
Priority: Minor
In {{SnapshotFileCache#refreshCache}}, the {{hasChanges}} will be judged as:
{code}
try {
FileStatus dirStatus = fs.getFileStatus(snapshotDir);
lastTimestamp = dirStatus.getModificationTime();
hasChanges |= (lastTimestamp >= lastModifiedTime); // >= will make
hasChanges always be true
{code}
The {{(lastTimestamp >= lastModifiedTime)}} will make {{hasChanges}} always be
true because {{lastTimestamp}} will be updated as:
{code}
this.lastModifiedTime = lastTimestamp;
{code}
So, SnapshotFileCache will always refresh the file cache.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-17330) SnapshotFileCache will always refresh the file cache
[
https://issues.apache.org/jira/browse/HBASE-17330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jianwei Cui updated HBASE-17330:
Attachment: HBASE-17330-v1.patch
> SnapshotFileCache will always refresh the file cache
>
>
> Key: HBASE-17330
> URL: https://issues.apache.org/jira/browse/HBASE-17330
> Project: HBase
> Issue Type: Bug
> Components: snapshots
>Affects Versions: 2.0.0, 1.3.1, 0.98.23
>Reporter: Jianwei Cui
>Priority: Minor
> Attachments: HBASE-17330-v1.patch
>
>
> In {{SnapshotFileCache#refreshCache}}, the {{hasChanges}} will be judged as:
> {code}
> try {
> FileStatus dirStatus = fs.getFileStatus(snapshotDir);
> lastTimestamp = dirStatus.getModificationTime();
> hasChanges |= (lastTimestamp >= lastModifiedTime); // >= will make
> hasChanges always be true
> {code}
> The {{(lastTimestamp >= lastModifiedTime)}} will make {{hasChanges}} always
> be true because {{lastTimestamp}} will be updated as:
> {code}
> this.lastModifiedTime = lastTimestamp;
> {code}
> So, SnapshotFileCache will always refresh the file cache.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-17330) SnapshotFileCache will always refresh the file cache
[
https://issues.apache.org/jira/browse/HBASE-17330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15756766#comment-15756766
]
Jianwei Cui commented on HBASE-17330:
-
In {{SnapshotFileCache#refreshCache}}, the modify time of snapshot tmp
directory will also be considered as:
{code}
// get the status of the snapshots temporary directory and check if it has
changes
// The top-level directory timestamp is not updated, so we have to check
the inner-level.
try {
Path snapshotTmpDir = new Path(snapshotDir,
SnapshotDescriptionUtils.SNAPSHOT_TMP_DIR_NAME);
FileStatus tempDirStatus = fs.getFileStatus(snapshotTmpDir);
lastTimestamp = Math.min(lastTimestamp,
tempDirStatus.getModificationTime());
hasChanges |= (lastTimestamp >= lastModifiedTime);
...
} catch (FileNotFoundException e) {
// Nothing todo, if the tmp dir is empty
}
{code}
It seems the in-progress snapshots under tmp directory won't be loaded in
{{SnapshotFileCache#refreshCache}} after
[HBASE-12627|https://issues.apache.org/jira/browse/HBASE-12627], so do not need
to consider modify time of tmp directory in {{SnapshotFileCache#refreshCache}}?
> SnapshotFileCache will always refresh the file cache
>
>
> Key: HBASE-17330
> URL: https://issues.apache.org/jira/browse/HBASE-17330
> Project: HBase
> Issue Type: Bug
> Components: snapshots
>Affects Versions: 2.0.0, 1.3.1, 0.98.23
>Reporter: Jianwei Cui
>Priority: Minor
> Attachments: HBASE-17330-v1.patch
>
>
> In {{SnapshotFileCache#refreshCache}}, the {{hasChanges}} will be judged as:
> {code}
> try {
> FileStatus dirStatus = fs.getFileStatus(snapshotDir);
> lastTimestamp = dirStatus.getModificationTime();
> hasChanges |= (lastTimestamp >= lastModifiedTime); // >= will make
> hasChanges always be true
> {code}
> The {{(lastTimestamp >= lastModifiedTime)}} will make {{hasChanges}} always
> be true because {{lastTimestamp}} will be updated as:
> {code}
> this.lastModifiedTime = lastTimestamp;
> {code}
> So, SnapshotFileCache will always refresh the file cache.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-17018) Spooling BufferedMutator
[
https://issues.apache.org/jira/browse/HBASE-17018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15756773#comment-15756773
]
Ted Yu commented on HBASE-17018:
For SpoolingBufferedMutatorImpl :
{code}
this.maxKeyValueSize =
params.getMaxKeyValueSize() != BufferedMutatorParams.UNSET
? params.getMaxKeyValueSize() : Integer.MAX_VALUE;
{code}
We already have hbase.client.keyvalue.maxsize
Should use the config value in place of Integer.MAX_VALUE
{code}
if ((currentBufferSize.get() > writeBufferSize)
&& (previousBufferSize < writeBufferSize)) {
{code}
Should the first line above be:
{code}
if ((currentBufferSize.get() >= writeBufferSize)
{code}
For close(), why is the call to flush(true) outside of the try block ?
{code}
if (!processES.awaitTermination(operationTimeout, TimeUnit.MILLISECONDS))
{
{code}
Should we obtain timestamp (now) at the beginning of the method and wait for
what remains w.r.t. operationTimeout ?
{code}
} catch (ExecutionException ee) {
LOG.error("ExecutionException while waiting for shutdown.", ee);
{code}
Should some IOException be thrown in case of ExecutionException ?
{code}
} catch (ExecutionException e) {
// TODO Auto-generated catch block
e.printStackTrace();
{code}
Convert the above to LOG.error().
Both setRpcTimeout() and setOperationTimeout() call
wrapped.setOperationTimeout(timeout), do we need both methods ?
Please put patch on review board - it is getting bigger.
Thanks
> Spooling BufferedMutator
>
>
> Key: HBASE-17018
> URL: https://issues.apache.org/jira/browse/HBASE-17018
> Project: HBase
> Issue Type: New Feature
>Reporter: Joep Rottinghuis
> Attachments: HBASE-17018.master.001.patch,
> HBASE-17018.master.002.patch, HBASE-17018.master.003.patch,
> HBASE-17018SpoolingBufferedMutatorDesign-v1.pdf, YARN-4061 HBase requirements
> for fault tolerant writer.pdf
>
>
> For Yarn Timeline Service v2 we use HBase as a backing store.
> A big concern we would like to address is what to do if HBase is
> (temporarily) down, for example in case of an HBase upgrade.
> Most of the high volume writes will be mostly on a best-effort basis, but
> occasionally we do a flush. Mainly during application lifecycle events,
> clients will call a flush on the timeline service API. In order to handle the
> volume of writes we use a BufferedMutator. When flush gets called on our API,
> we in turn call flush on the BufferedMutator.
> We would like our interface to HBase be able to spool the mutations to a
> filesystems in case of HBase errors. If we use the Hadoop filesystem
> interface, this can then be HDFS, gcs, s3, or any other distributed storage.
> The mutations can then later be re-played, for example through a MapReduce
> job.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-17330) SnapshotFileCache will always refresh the file cache
[
https://issues.apache.org/jira/browse/HBASE-17330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15756778#comment-15756778
]
Ted Yu commented on HBASE-17330:
Interesting.
I guess adding a unit test would be difficult.
> SnapshotFileCache will always refresh the file cache
>
>
> Key: HBASE-17330
> URL: https://issues.apache.org/jira/browse/HBASE-17330
> Project: HBase
> Issue Type: Bug
> Components: snapshots
>Affects Versions: 2.0.0, 1.3.1, 0.98.23
>Reporter: Jianwei Cui
>Priority: Minor
> Attachments: HBASE-17330-v1.patch
>
>
> In {{SnapshotFileCache#refreshCache}}, the {{hasChanges}} will be judged as:
> {code}
> try {
> FileStatus dirStatus = fs.getFileStatus(snapshotDir);
> lastTimestamp = dirStatus.getModificationTime();
> hasChanges |= (lastTimestamp >= lastModifiedTime); // >= will make
> hasChanges always be true
> {code}
> The {{(lastTimestamp >= lastModifiedTime)}} will make {{hasChanges}} always
> be true because {{lastTimestamp}} will be updated as:
> {code}
> this.lastModifiedTime = lastTimestamp;
> {code}
> So, SnapshotFileCache will always refresh the file cache.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-11392) add/remove peer requests should be routed through master
[ https://issues.apache.org/jira/browse/HBASE-11392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15756795#comment-15756795 ] Guanghao Zhang commented on HBASE-11392: The failed ut passed locally. And the whitespaces are generated by protobuf. Thanks. > add/remove peer requests should be routed through master > > > Key: HBASE-11392 > URL: https://issues.apache.org/jira/browse/HBASE-11392 > Project: HBase > Issue Type: Sub-task >Reporter: Enis Soztutar >Assignee: Guanghao Zhang >Priority: Critical > Fix For: 2.0.0 > > Attachments: HBASE-11392-v1.patch, HBASE-11392-v2.patch, > HBASE-11392-v3.patch, HBASE-11392-v4.patch > > > ReplicationAdmin directly operates over the zookeeper data for replication > setup. We should move these operations to be routed through master for two > reasons: > - Replication implementation details are exposed to client. We should move > most of the replication related classes to hbase-server package. > - Routing the requests through master is the standard practice for all other > operations. It allows for decoupling implementation details from the client > and code. > Review board: https://reviews.apache.org/r/54730/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-17149) Procedure v2 - Fix nonce submission
[ https://issues.apache.org/jira/browse/HBASE-17149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15756880#comment-15756880 ] Hudson commented on HBASE-17149: SUCCESS: Integrated in Jenkins build HBase-Trunk_matrix #2147 (See [https://builds.apache.org/job/HBase-Trunk_matrix/2147/]) HBASE-17149 Procedure v2 - Fix nonce submission (stack: rev da356069f244d4a3d35ccf34badda39bc15cf8d7) * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/procedure/TestModifyTableProcedure.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/TableNamespaceManager.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/procedure/TestDeleteTableProcedure.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/procedure/TestTruncateTableProcedure.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/procedure/TestEnableTableProcedure.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/snapshot/SnapshotManager.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/procedure/TestDeleteNamespaceProcedure.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/procedure/TestCloneSnapshotProcedure.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/procedure/TestAddColumnFamilyProcedure.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/MasterRpcServices.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/procedure/TestMasterProcedureEvents.java * (edit) hbase-procedure/src/main/java/org/apache/hadoop/hbase/procedure2/ProcedureExecutor.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/procedure/TestModifyColumnFamilyProcedure.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestCoprocessorWhitelistMasterObserver.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/ClusterSchemaServiceImpl.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/procedure/TestCreateTableProcedure.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/procedure/TestDisableTableProcedure.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/procedure/TestCreateNamespaceProcedure.java * (edit) hbase-procedure/src/test/java/org/apache/hadoop/hbase/procedure2/TestProcedureRecovery.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/HMaster.java * (edit) hbase-procedure/src/test/java/org/apache/hadoop/hbase/procedure2/ProcedureTestingUtility.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/procedure/TestProcedureAdmin.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/procedure/TestModifyNamespaceProcedure.java * (add) hbase-procedure/src/test/java/org/apache/hadoop/hbase/procedure2/TestProcedureNonce.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/procedure/TestDeleteColumnFamilyProcedure.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/ClusterSchema.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/procedure/TestMergeTableRegionsProcedure.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/procedure/TestSplitTableRegionProcedure.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/procedure/TestRestoreSnapshotProcedure.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/procedure/MasterProcedureUtil.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/procedure/TestDispatchMergingRegionsProcedure.java > Procedure v2 - Fix nonce submission > --- > > Key: HBASE-17149 > URL: https://issues.apache.org/jira/browse/HBASE-17149 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Affects Versions: 2.0.0, 1.3.0, 1.4.0, 1.1.7, 1.2.4 >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi > Fix For: 2.0.0 > > Attachments: HBASE-17149.master.001.patch, > HBASE-17149.master.002.patch, HBASE-17149.master.002.patch, > HBASE-17149.master.002.patch, HBASE-17149.master.003.patch, nonce.patch > > > instead of having all the logic in submitProcedure(), split in > registerNonce() + submitProcedure(). > In this case we can avoid calling the coprocessor twice and having a clean > submit logic knowing that there will only be one submission. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-17326) Fix findbugs warning in BufferedMutatorParams
[ https://issues.apache.org/jira/browse/HBASE-17326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15756879#comment-15756879 ] Hudson commented on HBASE-17326: SUCCESS: Integrated in Jenkins build HBase-Trunk_matrix #2147 (See [https://builds.apache.org/job/HBase-Trunk_matrix/2147/]) HBASE-17326 Fix findbugs warning in BufferedMutatorParams Fix above and (stack: rev a5ee36d937e9b1ca551d0733f7b74d19b9bc07b8) * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/BufferedMutatorParams.java > Fix findbugs warning in BufferedMutatorParams > - > > Key: HBASE-17326 > URL: https://issues.apache.org/jira/browse/HBASE-17326 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0 >Reporter: Guanghao Zhang >Assignee: stack > Fix For: 2.0.0 > > Attachments: HBASE-17326.master.001.patch > > > https://builds.apache.org/job/PreCommit-HBASE-Build/4947/artifact/patchprocess/branch-findbugs-hbase-client-warnings.html > org.apache.hadoop.hbase.client.BufferedMutatorParams defines clone() but > doesn't implement Cloneable -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-17331) Avoid busy waiting in ThrottledInputStream
ChiaPing Tsai created HBASE-17331:
-
Summary: Avoid busy waiting in ThrottledInputStream
Key: HBASE-17331
URL: https://issues.apache.org/jira/browse/HBASE-17331
Project: HBase
Issue Type: Improvement
Reporter: ChiaPing Tsai
Priority: Minor
{code:title=ThrottledInputStream.java|borderStyle=solid}
// We can calculate the precise sleep time instead of busy waiting
private void throttle() throws IOException {
while (getBytesPerSec() > maxBytesPerSec) {
try {
Thread.sleep(SLEEP_DURATION_MS);
totalSleepTime += SLEEP_DURATION_MS;
} catch (InterruptedException e) {
throw new IOException("Thread aborted", e);
}
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-17331) Avoid busy waiting in ThrottledInputStream
[
https://issues.apache.org/jira/browse/HBASE-17331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ChiaPing Tsai updated HBASE-17331:
--
Assignee: ChiaPing Tsai
Fix Version/s: 2.0.0
Affects Version/s: 2.0.0
Status: Patch Available (was: Open)
> Avoid busy waiting in ThrottledInputStream
> --
>
> Key: HBASE-17331
> URL: https://issues.apache.org/jira/browse/HBASE-17331
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 2.0.0
>Reporter: ChiaPing Tsai
>Assignee: ChiaPing Tsai
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-17331.v0.patch
>
>
> {code:title=ThrottledInputStream.java|borderStyle=solid}
> // We can calculate the precise sleep time instead of busy waiting
> private void throttle() throws IOException {
> while (getBytesPerSec() > maxBytesPerSec) {
> try {
> Thread.sleep(SLEEP_DURATION_MS);
> totalSleepTime += SLEEP_DURATION_MS;
> } catch (InterruptedException e) {
> throw new IOException("Thread aborted", e);
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-17331) Avoid busy waiting in ThrottledInputStream
[
https://issues.apache.org/jira/browse/HBASE-17331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ChiaPing Tsai updated HBASE-17331:
--
Attachment: HBASE-17331.v0.patch
> Avoid busy waiting in ThrottledInputStream
> --
>
> Key: HBASE-17331
> URL: https://issues.apache.org/jira/browse/HBASE-17331
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 2.0.0
>Reporter: ChiaPing Tsai
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-17331.v0.patch
>
>
> {code:title=ThrottledInputStream.java|borderStyle=solid}
> // We can calculate the precise sleep time instead of busy waiting
> private void throttle() throws IOException {
> while (getBytesPerSec() > maxBytesPerSec) {
> try {
> Thread.sleep(SLEEP_DURATION_MS);
> totalSleepTime += SLEEP_DURATION_MS;
> } catch (InterruptedException e) {
> throw new IOException("Thread aborted", e);
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-17282) Reduce the redundant requests to meta table
[ https://issues.apache.org/jira/browse/HBASE-17282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-17282: -- Attachment: HBASE-17282-v2.patch Add comments. > Reduce the redundant requests to meta table > --- > > Key: HBASE-17282 > URL: https://issues.apache.org/jira/browse/HBASE-17282 > Project: HBase > Issue Type: Sub-task > Components: Client >Affects Versions: 2.0.0 >Reporter: Duo Zhang >Assignee: Duo Zhang > Fix For: 2.0.0 > > Attachments: HBASE-17282-v1.patch, HBASE-17282-v2.patch, > HBASE-17282.patch > > > This usually happens at startup when the meta cache is empty. There will be a > lot of locating requests, but most of will have same results. Things become > worse if we do batch operations with AsyncTable as we will send a locating > request for each operation concurrently. > We need to reduce the redundant requests to meta table. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-17331) Avoid busy waiting in ThrottledInputStream
[
https://issues.apache.org/jira/browse/HBASE-17331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15757004#comment-15757004
]
Hadoop QA commented on HBASE-17331:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 11s
{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} 2m
45s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 14s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
20s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
8s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
32s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 14s
{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} compile {color} | {color:green} 0m 14s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 14s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
19s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
9s {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}
25m 19s {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-alpha1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
39s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 14s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 40s
{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
6s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 33m 38s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:8d52d23 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12843713/HBASE-17331.v0.patch |
| JIRA Issue | HBASE-17331 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux be516ee602ca 3.13.0-95-generic #142-Ubuntu SMP Fri Aug 12
17:00:09 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / da35606 |
| Default Java | 1.8.0_111 |
| findbugs | v3.0.0 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/4963/testReport/ |
| modules | C: hbase-common U: hbase-common |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/4963/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> Avoid busy waiting in ThrottledInputStream
> --
>
> Key: HBASE-17331
> URL: https://issues.apache.org/jira/browse/HBASE-17331
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 2.0.0
>Reporter: ChiaPing Tsai
>Assignee: ChiaPing Tsai
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-17331.v0.patch
>
>
> {c
[jira] [Updated] (HBASE-17331) Avoid busy waiting in ThrottledInputStream
[
https://issues.apache.org/jira/browse/HBASE-17331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ChiaPing Tsai updated HBASE-17331:
--
Status: Open (was: Patch Available)
> Avoid busy waiting in ThrottledInputStream
> --
>
> Key: HBASE-17331
> URL: https://issues.apache.org/jira/browse/HBASE-17331
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 2.0.0
>Reporter: ChiaPing Tsai
>Assignee: ChiaPing Tsai
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-17331.v0.patch, HBASE-17331.v1.patch
>
>
> {code:title=ThrottledInputStream.java|borderStyle=solid}
> // We can calculate the precise sleep time instead of busy waiting
> private void throttle() throws IOException {
> while (getBytesPerSec() > maxBytesPerSec) {
> try {
> Thread.sleep(SLEEP_DURATION_MS);
> totalSleepTime += SLEEP_DURATION_MS;
> } catch (InterruptedException e) {
> throw new IOException("Thread aborted", e);
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-17331) Avoid busy waiting in ThrottledInputStream
[
https://issues.apache.org/jira/browse/HBASE-17331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ChiaPing Tsai updated HBASE-17331:
--
Status: Patch Available (was: Open)
> Avoid busy waiting in ThrottledInputStream
> --
>
> Key: HBASE-17331
> URL: https://issues.apache.org/jira/browse/HBASE-17331
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 2.0.0
>Reporter: ChiaPing Tsai
>Assignee: ChiaPing Tsai
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-17331.v0.patch, HBASE-17331.v1.patch
>
>
> {code:title=ThrottledInputStream.java|borderStyle=solid}
> // We can calculate the precise sleep time instead of busy waiting
> private void throttle() throws IOException {
> while (getBytesPerSec() > maxBytesPerSec) {
> try {
> Thread.sleep(SLEEP_DURATION_MS);
> totalSleepTime += SLEEP_DURATION_MS;
> } catch (InterruptedException e) {
> throw new IOException("Thread aborted", e);
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-17331) Avoid busy waiting in ThrottledInputStream
[
https://issues.apache.org/jira/browse/HBASE-17331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ChiaPing Tsai updated HBASE-17331:
--
Attachment: HBASE-17331.v1.patch
v1 patch add a trivial change in server module
> Avoid busy waiting in ThrottledInputStream
> --
>
> Key: HBASE-17331
> URL: https://issues.apache.org/jira/browse/HBASE-17331
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 2.0.0
>Reporter: ChiaPing Tsai
>Assignee: ChiaPing Tsai
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-17331.v0.patch, HBASE-17331.v1.patch
>
>
> {code:title=ThrottledInputStream.java|borderStyle=solid}
> // We can calculate the precise sleep time instead of busy waiting
> private void throttle() throws IOException {
> while (getBytesPerSec() > maxBytesPerSec) {
> try {
> Thread.sleep(SLEEP_DURATION_MS);
> totalSleepTime += SLEEP_DURATION_MS;
> } catch (InterruptedException e) {
> throw new IOException("Thread aborted", e);
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-17330) SnapshotFileCache will always refresh the file cache
[
https://issues.apache.org/jira/browse/HBASE-17330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15757119#comment-15757119
]
Jianwei Cui commented on HBASE-17330:
-
Thanks for the review [~tedyu]. As mentioned above, it seems not need to
consider modify time of tmp directory in {{SnapshotFileCache#refreshCache}}?
Then, the {{hasChange}} could be easily judged by
{{fs.getFileStatus(snapshotDir).getModificationTime() > lastModifiedTime}}.
> SnapshotFileCache will always refresh the file cache
>
>
> Key: HBASE-17330
> URL: https://issues.apache.org/jira/browse/HBASE-17330
> Project: HBase
> Issue Type: Bug
> Components: snapshots
>Affects Versions: 2.0.0, 1.3.1, 0.98.23
>Reporter: Jianwei Cui
>Priority: Minor
> Attachments: HBASE-17330-v1.patch
>
>
> In {{SnapshotFileCache#refreshCache}}, the {{hasChanges}} will be judged as:
> {code}
> try {
> FileStatus dirStatus = fs.getFileStatus(snapshotDir);
> lastTimestamp = dirStatus.getModificationTime();
> hasChanges |= (lastTimestamp >= lastModifiedTime); // >= will make
> hasChanges always be true
> {code}
> The {{(lastTimestamp >= lastModifiedTime)}} will make {{hasChanges}} always
> be true because {{lastTimestamp}} will be updated as:
> {code}
> this.lastModifiedTime = lastTimestamp;
> {code}
> So, SnapshotFileCache will always refresh the file cache.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-17323) TestAsyncGetMultiThread fails in master
[
https://issues.apache.org/jira/browse/HBASE-17323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15757152#comment-15757152
]
Duo Zhang commented on HBASE-17323:
---
I can get the same result with [~tedyu]. If I update to the version before
HBASE-17081
{noformat}
commit 401e83cee383508a2ccdf5b92e7c77a0be2e566a
Author: tedyu
Date: Thu Dec 15 07:06:37 2016 -0800
HBASE-17318 Increment does not add new column if the increment amount is
zero at first time writing (Guangxu Cheng)
{noformat}
TestAsyncGetMultiThread have passed all the 10 runs.
If I update to HBASE-17081
{noformat}
commit a2a7618d261bfe121f05821d89242d770cd7b7ec
Author: Ramkrishna
Date: Thu Dec 15 22:02:05 2016 +0530
HBASE-17081 Flush the entire CompactingMemStore content to disk (Anastasia
Braginsky)
{noformat}
It failed 7 times out of 10 runs.
So I think the problem is HBASE-17081.
> TestAsyncGetMultiThread fails in master
> ---
>
> Key: HBASE-17323
> URL: https://issues.apache.org/jira/browse/HBASE-17323
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
> Attachments: 17323.hack.txt, testAsyncGetMultiThread-output.gz
>
>
> From
> https://builds.apache.org/job/HBase-Trunk_matrix/2137/jdk=JDK%201.8%20(latest),label=Hadoop/testReport/junit/org.apache.hadoop.hbase.client/TestAsyncGetMultiThread/test/
> :
> {code}
> java.util.concurrent.ExecutionException: java.lang.NullPointerException
> at org.apache.hadoop.hbase.util.Bytes.toInt(Bytes.java:1003)
> at org.apache.hadoop.hbase.util.Bytes.toInt(Bytes.java:980)
> at
> org.apache.hadoop.hbase.client.TestAsyncGetMultiThread.run(TestAsyncGetMultiThread.java:108)
> at
> org.apache.hadoop.hbase.client.TestAsyncGetMultiThread.lambda$null$1(TestAsyncGetMultiThread.java:122)
> {code}
> This can be reproduced locally.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-17330) SnapshotFileCache will always refresh the file cache
[
https://issues.apache.org/jira/browse/HBASE-17330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-17330:
---
Status: Patch Available (was: Open)
> SnapshotFileCache will always refresh the file cache
>
>
> Key: HBASE-17330
> URL: https://issues.apache.org/jira/browse/HBASE-17330
> Project: HBase
> Issue Type: Bug
> Components: snapshots
>Affects Versions: 0.98.23, 2.0.0, 1.3.1
>Reporter: Jianwei Cui
>Priority: Minor
> Attachments: HBASE-17330-v1.patch
>
>
> In {{SnapshotFileCache#refreshCache}}, the {{hasChanges}} will be judged as:
> {code}
> try {
> FileStatus dirStatus = fs.getFileStatus(snapshotDir);
> lastTimestamp = dirStatus.getModificationTime();
> hasChanges |= (lastTimestamp >= lastModifiedTime); // >= will make
> hasChanges always be true
> {code}
> The {{(lastTimestamp >= lastModifiedTime)}} will make {{hasChanges}} always
> be true because {{lastTimestamp}} will be updated as:
> {code}
> this.lastModifiedTime = lastTimestamp;
> {code}
> So, SnapshotFileCache will always refresh the file cache.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-17331) Avoid busy waiting in ThrottledInputStream
[
https://issues.apache.org/jira/browse/HBASE-17331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15757190#comment-15757190
]
Ted Yu commented on HBASE-17331:
{code}
149 } catch (InterruptedException e) {
150 throw new IOException("Thread aborted", e);
{code}
Please throw InterruptedIOException
> Avoid busy waiting in ThrottledInputStream
> --
>
> Key: HBASE-17331
> URL: https://issues.apache.org/jira/browse/HBASE-17331
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 2.0.0
>Reporter: ChiaPing Tsai
>Assignee: ChiaPing Tsai
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-17331.v0.patch, HBASE-17331.v1.patch
>
>
> {code:title=ThrottledInputStream.java|borderStyle=solid}
> // We can calculate the precise sleep time instead of busy waiting
> private void throttle() throws IOException {
> while (getBytesPerSec() > maxBytesPerSec) {
> try {
> Thread.sleep(SLEEP_DURATION_MS);
> totalSleepTime += SLEEP_DURATION_MS;
> } catch (InterruptedException e) {
> throw new IOException("Thread aborted", e);
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-17282) Reduce the redundant requests to meta table
[
https://issues.apache.org/jira/browse/HBASE-17282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15757201#comment-15757201
]
Hadoop QA commented on HBASE-17282:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 8s
{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 7 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 11s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
9s {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
49s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
23s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
49s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 51s
{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 13s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
9s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 4s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 4s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
50s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
26s {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}
27m 44s {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-alpha1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
48s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 46s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 7s
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 98m 5s {color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
26s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 144m 30s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.11.2 Server=1.11.2 Image:yetus/hbase:8d52d23 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12843714/HBASE-17282-v2.patch |
| JIRA Issue | HBASE-17282 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux 014f95eeff35 3.13.0-105-generic #152-Ubuntu SMP Fri Dec 2
15:37:11 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / da35606 |
| Default Java | 1.8.0_111 |
| findbugs | v3.0.0 |
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/4964/artifact/patchprocess/patch-unit-hbase-server.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/4964/testReport/ |
| modules | C: hbase-client hbase-server U: . |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/4964/console |
| Powered by | Apache Yetus 0.3.0 http:
[jira] [Commented] (HBASE-17018) Spooling BufferedMutator
[ https://issues.apache.org/jira/browse/HBASE-17018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15757654#comment-15757654 ] Joep Rottinghuis commented on HBASE-17018: -- Thanks for the feedback [~tedyu] I'll go through and apply your suggestions. I do plan to resolve all the TODOs as well before I declare this patch as ready. > Spooling BufferedMutator > > > Key: HBASE-17018 > URL: https://issues.apache.org/jira/browse/HBASE-17018 > Project: HBase > Issue Type: New Feature >Reporter: Joep Rottinghuis > Attachments: HBASE-17018.master.001.patch, > HBASE-17018.master.002.patch, HBASE-17018.master.003.patch, > HBASE-17018SpoolingBufferedMutatorDesign-v1.pdf, YARN-4061 HBase requirements > for fault tolerant writer.pdf > > > For Yarn Timeline Service v2 we use HBase as a backing store. > A big concern we would like to address is what to do if HBase is > (temporarily) down, for example in case of an HBase upgrade. > Most of the high volume writes will be mostly on a best-effort basis, but > occasionally we do a flush. Mainly during application lifecycle events, > clients will call a flush on the timeline service API. In order to handle the > volume of writes we use a BufferedMutator. When flush gets called on our API, > we in turn call flush on the BufferedMutator. > We would like our interface to HBase be able to spool the mutations to a > filesystems in case of HBase errors. If we use the Hadoop filesystem > interface, this can then be HDFS, gcs, s3, or any other distributed storage. > The mutations can then later be re-played, for example through a MapReduce > job. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-17081) Flush the entire CompactingMemStore content to disk
[ https://issues.apache.org/jira/browse/HBASE-17081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15757905#comment-15757905 ] Duo Zhang commented on HBASE-17081: --- Any progress on the regression? In HBASE-17323 we found that the failure of TestAsyncGetMultiThread relates to the patch here. Thanks. > Flush the entire CompactingMemStore content to disk > --- > > Key: HBASE-17081 > URL: https://issues.apache.org/jira/browse/HBASE-17081 > Project: HBase > Issue Type: Sub-task >Reporter: Anastasia Braginsky >Assignee: Anastasia Braginsky > Attachments: HBASE-15787_8.patch, HBASE-17081-V01.patch, > HBASE-17081-V02.patch, HBASE-17081-V03.patch, HBASE-17081-V04.patch, > HBASE-17081-V05.patch, HBASE-17081-V06.patch, HBASE-17081-V06.patch, > HBASE-17081-V07.patch, HBaseMeetupDecember2016-V02.pptx, > Pipelinememstore_fortrunk_3.patch > > > Part of CompactingMemStore's memory is held by an active segment, and another > part is divided between immutable segments in the compacting pipeline. Upon > flush-to-disk request we want to flush all of it to disk, in contrast to > flushing only tail of the compacting pipeline. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-17282) Reduce the redundant requests to meta table
[ https://issues.apache.org/jira/browse/HBASE-17282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15757907#comment-15757907 ] Duo Zhang commented on HBASE-17282: --- The failed test is TestAsyncGetMultiThread which will be addressed in HBASE-17323. Let me commit. > Reduce the redundant requests to meta table > --- > > Key: HBASE-17282 > URL: https://issues.apache.org/jira/browse/HBASE-17282 > Project: HBase > Issue Type: Sub-task > Components: Client >Affects Versions: 2.0.0 >Reporter: Duo Zhang >Assignee: Duo Zhang > Fix For: 2.0.0 > > Attachments: HBASE-17282-v1.patch, HBASE-17282-v2.patch, > HBASE-17282.patch > > > This usually happens at startup when the meta cache is empty. There will be a > lot of locating requests, but most of will have same results. Things become > worse if we do batch operations with AsyncTable as we will send a locating > request for each operation concurrently. > We need to reduce the redundant requests to meta table. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-17282) Reduce the redundant requests to meta table
[ https://issues.apache.org/jira/browse/HBASE-17282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-17282: -- Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Pushed to master. Thanks [~stack] for reviewing. > Reduce the redundant requests to meta table > --- > > Key: HBASE-17282 > URL: https://issues.apache.org/jira/browse/HBASE-17282 > Project: HBase > Issue Type: Sub-task > Components: Client >Affects Versions: 2.0.0 >Reporter: Duo Zhang >Assignee: Duo Zhang > Fix For: 2.0.0 > > Attachments: HBASE-17282-v1.patch, HBASE-17282-v2.patch, > HBASE-17282.patch > > > This usually happens at startup when the meta cache is empty. There will be a > lot of locating requests, but most of will have same results. Things become > worse if we do batch operations with AsyncTable as we will send a locating > request for each operation concurrently. > We need to reduce the redundant requests to meta table. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-17325) Add batch delete capability to ImportTsv
[ https://issues.apache.org/jira/browse/HBASE-17325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15757914#comment-15757914 ] Ted Yu commented on HBASE-17325: Do you use this in your cluster ? Can you share your experience ? Thanks > Add batch delete capability to ImportTsv > - > > Key: HBASE-17325 > URL: https://issues.apache.org/jira/browse/HBASE-17325 > Project: HBase > Issue Type: New Feature > Components: tooling >Reporter: zhangshibin > Labels: patch > Attachments: > 0001-HBASE-17325-Add-batch-delete-capability-to-ImportTsv.patch > > > Considering to batch delete data in table which we load from external > files,this feature add a switch key to enable batch delete. > First,using the file we load to table and the bulkoutput function of > ImportTsv to generate hfiles in hdfs which contain the keyvalue of > 'DeleteFamily' marker .Then the tool of > org.apache.hadoop.hbase.mapreduce.LoadIncrementalHFiles is used to load > hfiles into table intending to cover the data of whole family we need to > delete. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-17081) Flush the entire CompactingMemStore content to disk
[ https://issues.apache.org/jira/browse/HBASE-17081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15757921#comment-15757921 ] Duo Zhang commented on HBASE-17081: --- Busy these days so I do not have much time to help debugging the bugs directly. In TestAsyncGetMultiThread, we will put 1000 rows to a table with 9 regions. And then use several background threads to get the values and do some split and move works. The failure is NPE when getting from a Result object which means the row is missing so I think the problem maybe the flush when splitting or moving. Hope this could help. Thanks. > Flush the entire CompactingMemStore content to disk > --- > > Key: HBASE-17081 > URL: https://issues.apache.org/jira/browse/HBASE-17081 > Project: HBase > Issue Type: Sub-task >Reporter: Anastasia Braginsky >Assignee: Anastasia Braginsky > Attachments: HBASE-15787_8.patch, HBASE-17081-V01.patch, > HBASE-17081-V02.patch, HBASE-17081-V03.patch, HBASE-17081-V04.patch, > HBASE-17081-V05.patch, HBASE-17081-V06.patch, HBASE-17081-V06.patch, > HBASE-17081-V07.patch, HBaseMeetupDecember2016-V02.pptx, > Pipelinememstore_fortrunk_3.patch > > > Part of CompactingMemStore's memory is held by an active segment, and another > part is divided between immutable segments in the compacting pipeline. Upon > flush-to-disk request we want to flush all of it to disk, in contrast to > flushing only tail of the compacting pipeline. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13094) Consider Filters that are evaluated before deletes and see delete markers
[ https://issues.apache.org/jira/browse/HBASE-13094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15757926#comment-15757926 ] Lars Hofhansl commented on HBASE-13094: --- Wait. Isn't this all doable with just a raw-scan? [~jongray], [~jamestaylor], [~ghelmling]? I was just about to make a patch against trunk and found that this would lead to behavior as a raw scan. A raw scan can be handed a filter and that filter would always see all Cells (deleted and all columns as well). > Consider Filters that are evaluated before deletes and see delete markers > - > > Key: HBASE-13094 > URL: https://issues.apache.org/jira/browse/HBASE-13094 > Project: HBase > Issue Type: Brainstorming > Components: regionserver, Scanners >Reporter: Lars Hofhansl >Assignee: Lars Hofhansl > Attachments: 13094-0.98.txt > > > That would be good for full control filtering of all cells, such as needed > for some transaction implementations. > [~ghelmling] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (HBASE-13094) Consider Filters that are evaluated before deletes and see delete markers
[ https://issues.apache.org/jira/browse/HBASE-13094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15757926#comment-15757926 ] Lars Hofhansl edited comment on HBASE-13094 at 12/18/16 1:05 AM: - Wait. Isn't this all doable with just a raw-scan? [~jongray], [~jamestaylor], [~ghelmling], [~apurtell]? I was just about to make a patch against trunk and found that this would lead to behavior as a raw scan. A raw scan can be handed a filter and that filter would always see all Cells (deleted and all columns as well). was (Author: lhofhansl): Wait. Isn't this all doable with just a raw-scan? [~jongray], [~jamestaylor], [~ghelmling]? I was just about to make a patch against trunk and found that this would lead to behavior as a raw scan. A raw scan can be handed a filter and that filter would always see all Cells (deleted and all columns as well). > Consider Filters that are evaluated before deletes and see delete markers > - > > Key: HBASE-13094 > URL: https://issues.apache.org/jira/browse/HBASE-13094 > Project: HBase > Issue Type: Brainstorming > Components: regionserver, Scanners >Reporter: Lars Hofhansl >Assignee: Lars Hofhansl > Attachments: 13094-0.98.txt > > > That would be good for full control filtering of all cells, such as needed > for some transaction implementations. > [~ghelmling] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13094) Consider Filters that are evaluated before deletes and see delete markers
[ https://issues.apache.org/jira/browse/HBASE-13094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15757947#comment-15757947 ] Lars Hofhansl commented on HBASE-13094: --- So the trick is to make a scan raw and then filter the KVs you do not want. Unfortunately you'd have to deal with column filtering as well, that'd the only thing that this could do. > Consider Filters that are evaluated before deletes and see delete markers > - > > Key: HBASE-13094 > URL: https://issues.apache.org/jira/browse/HBASE-13094 > Project: HBase > Issue Type: Brainstorming > Components: regionserver, Scanners >Reporter: Lars Hofhansl >Assignee: Lars Hofhansl > Attachments: 13094-0.98.txt > > > That would be good for full control filtering of all cells, such as needed > for some transaction implementations. > [~ghelmling] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-17282) Reduce the redundant requests to meta table
[ https://issues.apache.org/jira/browse/HBASE-17282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15758118#comment-15758118 ] Hudson commented on HBASE-17282: SUCCESS: Integrated in Jenkins build HBase-Trunk_matrix #2151 (See [https://builds.apache.org/job/HBase-Trunk_matrix/2151/]) HBASE-17282 Reduce the redundant requests to meta table (zhangduo: rev f041306cdae701e91b314234b413af98fd1f6b18) * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/AsyncConnectionImpl.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestAsyncRegionLocatorTimeout.java * (add) hbase-client/src/main/java/org/apache/hadoop/hbase/client/AsyncMetaRegionLocator.java * (add) hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestAsyncNonMetaRegionLocator.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestAsyncTable.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestAsyncGetMultiThread.java * (delete) hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestAsyncRegionLocator.java * (add) hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestAsyncNonMetaRegionLocatorConcurrenyLimit.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestAsyncTableNoncedRetry.java * (add) hbase-client/src/main/java/org/apache/hadoop/hbase/client/AsyncNonMetaRegionLocator.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/AsyncRegionLocator.java > Reduce the redundant requests to meta table > --- > > Key: HBASE-17282 > URL: https://issues.apache.org/jira/browse/HBASE-17282 > Project: HBase > Issue Type: Sub-task > Components: Client >Affects Versions: 2.0.0 >Reporter: Duo Zhang >Assignee: Duo Zhang > Fix For: 2.0.0 > > Attachments: HBASE-17282-v1.patch, HBASE-17282-v2.patch, > HBASE-17282.patch > > > This usually happens at startup when the meta cache is empty. There will be a > lot of locating requests, but most of will have same results. Things become > worse if we do batch operations with AsyncTable as we will send a locating > request for each operation concurrently. > We need to reduce the redundant requests to meta table. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-17330) SnapshotFileCache will always refresh the file cache
[
https://issues.apache.org/jira/browse/HBASE-17330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jianwei Cui updated HBASE-17330:
Attachment: HBASE-17330-v2.patch
> SnapshotFileCache will always refresh the file cache
>
>
> Key: HBASE-17330
> URL: https://issues.apache.org/jira/browse/HBASE-17330
> Project: HBase
> Issue Type: Bug
> Components: snapshots
>Affects Versions: 2.0.0, 1.3.1, 0.98.23
>Reporter: Jianwei Cui
>Priority: Minor
> Attachments: HBASE-17330-v1.patch, HBASE-17330-v2.patch
>
>
> In {{SnapshotFileCache#refreshCache}}, the {{hasChanges}} will be judged as:
> {code}
> try {
> FileStatus dirStatus = fs.getFileStatus(snapshotDir);
> lastTimestamp = dirStatus.getModificationTime();
> hasChanges |= (lastTimestamp >= lastModifiedTime); // >= will make
> hasChanges always be true
> {code}
> The {{(lastTimestamp >= lastModifiedTime)}} will make {{hasChanges}} always
> be true because {{lastTimestamp}} will be updated as:
> {code}
> this.lastModifiedTime = lastTimestamp;
> {code}
> So, SnapshotFileCache will always refresh the file cache.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (HBASE-17330) SnapshotFileCache will always refresh the file cache
[
https://issues.apache.org/jira/browse/HBASE-17330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jianwei Cui reassigned HBASE-17330:
---
Assignee: Jianwei Cui
> SnapshotFileCache will always refresh the file cache
>
>
> Key: HBASE-17330
> URL: https://issues.apache.org/jira/browse/HBASE-17330
> Project: HBase
> Issue Type: Bug
> Components: snapshots
>Affects Versions: 2.0.0, 1.3.1, 0.98.23
>Reporter: Jianwei Cui
>Assignee: Jianwei Cui
>Priority: Minor
> Attachments: HBASE-17330-v1.patch, HBASE-17330-v2.patch
>
>
> In {{SnapshotFileCache#refreshCache}}, the {{hasChanges}} will be judged as:
> {code}
> try {
> FileStatus dirStatus = fs.getFileStatus(snapshotDir);
> lastTimestamp = dirStatus.getModificationTime();
> hasChanges |= (lastTimestamp >= lastModifiedTime); // >= will make
> hasChanges always be true
> {code}
> The {{(lastTimestamp >= lastModifiedTime)}} will make {{hasChanges}} always
> be true because {{lastTimestamp}} will be updated as:
> {code}
> this.lastModifiedTime = lastTimestamp;
> {code}
> So, SnapshotFileCache will always refresh the file cache.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-17331) Avoid busy waiting in ThrottledInputStream
[
https://issues.apache.org/jira/browse/HBASE-17331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ChiaPing Tsai updated HBASE-17331:
--
Status: Open (was: Patch Available)
> Avoid busy waiting in ThrottledInputStream
> --
>
> Key: HBASE-17331
> URL: https://issues.apache.org/jira/browse/HBASE-17331
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 2.0.0
>Reporter: ChiaPing Tsai
>Assignee: ChiaPing Tsai
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-17331.v0.patch, HBASE-17331.v1.patch
>
>
> {code:title=ThrottledInputStream.java|borderStyle=solid}
> // We can calculate the precise sleep time instead of busy waiting
> private void throttle() throws IOException {
> while (getBytesPerSec() > maxBytesPerSec) {
> try {
> Thread.sleep(SLEEP_DURATION_MS);
> totalSleepTime += SLEEP_DURATION_MS;
> } catch (InterruptedException e) {
> throw new IOException("Thread aborted", e);
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (HBASE-17331) Avoid busy waiting in ThrottledInputStream
[
https://issues.apache.org/jira/browse/HBASE-17331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15758271#comment-15758271
]
ChiaPing Tsai edited comment on HBASE-17331 at 12/18/16 5:47 AM:
-
v2 takes the suggestion from [~yuzhih...@gmail.com]
was (Author: chia7712):
v1 takes the suggestion from [~yuzhih...@gmail.com]
> Avoid busy waiting in ThrottledInputStream
> --
>
> Key: HBASE-17331
> URL: https://issues.apache.org/jira/browse/HBASE-17331
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 2.0.0
>Reporter: ChiaPing Tsai
>Assignee: ChiaPing Tsai
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-17331.v0.patch, HBASE-17331.v1.patch,
> HBASE-17331.v2.patch
>
>
> {code:title=ThrottledInputStream.java|borderStyle=solid}
> // We can calculate the precise sleep time instead of busy waiting
> private void throttle() throws IOException {
> while (getBytesPerSec() > maxBytesPerSec) {
> try {
> Thread.sleep(SLEEP_DURATION_MS);
> totalSleepTime += SLEEP_DURATION_MS;
> } catch (InterruptedException e) {
> throw new IOException("Thread aborted", e);
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-17331) Avoid busy waiting in ThrottledInputStream
[
https://issues.apache.org/jira/browse/HBASE-17331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ChiaPing Tsai updated HBASE-17331:
--
Attachment: HBASE-17331.v2.patch
v1 takes the suggestion from [~yuzhih...@gmail.com]
> Avoid busy waiting in ThrottledInputStream
> --
>
> Key: HBASE-17331
> URL: https://issues.apache.org/jira/browse/HBASE-17331
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 2.0.0
>Reporter: ChiaPing Tsai
>Assignee: ChiaPing Tsai
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-17331.v0.patch, HBASE-17331.v1.patch,
> HBASE-17331.v2.patch
>
>
> {code:title=ThrottledInputStream.java|borderStyle=solid}
> // We can calculate the precise sleep time instead of busy waiting
> private void throttle() throws IOException {
> while (getBytesPerSec() > maxBytesPerSec) {
> try {
> Thread.sleep(SLEEP_DURATION_MS);
> totalSleepTime += SLEEP_DURATION_MS;
> } catch (InterruptedException e) {
> throw new IOException("Thread aborted", e);
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-17331) Avoid busy waiting in ThrottledInputStream
[
https://issues.apache.org/jira/browse/HBASE-17331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ChiaPing Tsai updated HBASE-17331:
--
Status: Patch Available (was: Open)
> Avoid busy waiting in ThrottledInputStream
> --
>
> Key: HBASE-17331
> URL: https://issues.apache.org/jira/browse/HBASE-17331
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 2.0.0
>Reporter: ChiaPing Tsai
>Assignee: ChiaPing Tsai
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-17331.v0.patch, HBASE-17331.v1.patch,
> HBASE-17331.v2.patch
>
>
> {code:title=ThrottledInputStream.java|borderStyle=solid}
> // We can calculate the precise sleep time instead of busy waiting
> private void throttle() throws IOException {
> while (getBytesPerSec() > maxBytesPerSec) {
> try {
> Thread.sleep(SLEEP_DURATION_MS);
> totalSleepTime += SLEEP_DURATION_MS;
> } catch (InterruptedException e) {
> throw new IOException("Thread aborted", e);
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-17328) Properly dispose of looped replication peers
[
https://issues.apache.org/jira/browse/HBASE-17328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Poon updated HBASE-17328:
-
Attachment: HBASE-17328-master.v2.patch
> Properly dispose of looped replication peers
>
>
> Key: HBASE-17328
> URL: https://issues.apache.org/jira/browse/HBASE-17328
> Project: HBase
> Issue Type: Bug
> Components: Replication
>Affects Versions: 2.0.0, 1.4.0, 0.98.23
>Reporter: Vincent Poon
>Assignee: Vincent Poon
>Priority: Critical
> Fix For: 2.0.0, 1.3.0, 1.4.0, 1.2.5, 0.98.24, 1.1.9
>
> Attachments: HBASE-17328-1.1.v1.patch, HBASE-17328-master.v1.patch,
> HBASE-17328-master.v2.patch
>
>
> When adding a looped replication peer (clusterId == peerClusterId), the
> following code terminates the replication source thread, but since the source
> manager still holds a reference, WALs continue to get enqueued, and never get
> cleaned because they're stuck in the queue, leading to an unsustainable
> buildup. Furthermore, the replication statistics thread will continue to
> print statistics for the terminated source.
> {code}
> if (clusterId.equals(peerClusterId) &&
> !replicationEndpoint.canReplicateToSameCluster()) {
> this.terminate("ClusterId " + clusterId + " is replicating to itself:
> peerClusterId "
> + peerClusterId + " which is not allowed by ReplicationEndpoint:"
> + replicationEndpoint.getClass().getName(), null, false);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-17328) Properly dispose of looped replication peers
[
https://issues.apache.org/jira/browse/HBASE-17328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15758308#comment-15758308
]
Vincent Poon commented on HBASE-17328:
--
[~yuzhih...@gmail.com] The replication source's job is to read WALs from the
queue and ship them. I was thinking we should terminate that before we remove
the queue, otherwise you might delete the queue during reading, and get some
kind of Exception.
> Properly dispose of looped replication peers
>
>
> Key: HBASE-17328
> URL: https://issues.apache.org/jira/browse/HBASE-17328
> Project: HBase
> Issue Type: Bug
> Components: Replication
>Affects Versions: 2.0.0, 1.4.0, 0.98.23
>Reporter: Vincent Poon
>Assignee: Vincent Poon
>Priority: Critical
> Fix For: 2.0.0, 1.3.0, 1.4.0, 1.2.5, 0.98.24, 1.1.9
>
> Attachments: HBASE-17328-1.1.v1.patch, HBASE-17328-master.v1.patch,
> HBASE-17328-master.v2.patch
>
>
> When adding a looped replication peer (clusterId == peerClusterId), the
> following code terminates the replication source thread, but since the source
> manager still holds a reference, WALs continue to get enqueued, and never get
> cleaned because they're stuck in the queue, leading to an unsustainable
> buildup. Furthermore, the replication statistics thread will continue to
> print statistics for the terminated source.
> {code}
> if (clusterId.equals(peerClusterId) &&
> !replicationEndpoint.canReplicateToSameCluster()) {
> this.terminate("ClusterId " + clusterId + " is replicating to itself:
> peerClusterId "
> + peerClusterId + " which is not allowed by ReplicationEndpoint:"
> + replicationEndpoint.getClass().getName(), null, false);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-17328) Properly dispose of looped replication peers
[
https://issues.apache.org/jira/browse/HBASE-17328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15758310#comment-15758310
]
Vincent Poon commented on HBASE-17328:
--
Thanks [~zghaobac], attached a v2 patch with your suggestion. Also added a
test.
> Properly dispose of looped replication peers
>
>
> Key: HBASE-17328
> URL: https://issues.apache.org/jira/browse/HBASE-17328
> Project: HBase
> Issue Type: Bug
> Components: Replication
>Affects Versions: 2.0.0, 1.4.0, 0.98.23
>Reporter: Vincent Poon
>Assignee: Vincent Poon
>Priority: Critical
> Fix For: 2.0.0, 1.3.0, 1.4.0, 1.2.5, 0.98.24, 1.1.9
>
> Attachments: HBASE-17328-1.1.v1.patch, HBASE-17328-master.v1.patch,
> HBASE-17328-master.v2.patch
>
>
> When adding a looped replication peer (clusterId == peerClusterId), the
> following code terminates the replication source thread, but since the source
> manager still holds a reference, WALs continue to get enqueued, and never get
> cleaned because they're stuck in the queue, leading to an unsustainable
> buildup. Furthermore, the replication statistics thread will continue to
> print statistics for the terminated source.
> {code}
> if (clusterId.equals(peerClusterId) &&
> !replicationEndpoint.canReplicateToSameCluster()) {
> this.terminate("ClusterId " + clusterId + " is replicating to itself:
> peerClusterId "
> + peerClusterId + " which is not allowed by ReplicationEndpoint:"
> + replicationEndpoint.getClass().getName(), null, false);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-17328) Properly dispose of looped replication peers
[
https://issues.apache.org/jira/browse/HBASE-17328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Poon updated HBASE-17328:
-
Attachment: HBASE-17328.branch-1.1.v2.patch
> Properly dispose of looped replication peers
>
>
> Key: HBASE-17328
> URL: https://issues.apache.org/jira/browse/HBASE-17328
> Project: HBase
> Issue Type: Bug
> Components: Replication
>Affects Versions: 2.0.0, 1.4.0, 0.98.23
>Reporter: Vincent Poon
>Assignee: Vincent Poon
>Priority: Critical
> Fix For: 2.0.0, 1.3.0, 1.4.0, 1.2.5, 0.98.24, 1.1.9
>
> Attachments: HBASE-17328-1.1.v1.patch, HBASE-17328-master.v1.patch,
> HBASE-17328-master.v2.patch, HBASE-17328.branch-1.1.v2.patch
>
>
> When adding a looped replication peer (clusterId == peerClusterId), the
> following code terminates the replication source thread, but since the source
> manager still holds a reference, WALs continue to get enqueued, and never get
> cleaned because they're stuck in the queue, leading to an unsustainable
> buildup. Furthermore, the replication statistics thread will continue to
> print statistics for the terminated source.
> {code}
> if (clusterId.equals(peerClusterId) &&
> !replicationEndpoint.canReplicateToSameCluster()) {
> this.terminate("ClusterId " + clusterId + " is replicating to itself:
> peerClusterId "
> + peerClusterId + " which is not allowed by ReplicationEndpoint:"
> + replicationEndpoint.getClass().getName(), null, false);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-17328) Properly dispose of looped replication peers
[
https://issues.apache.org/jira/browse/HBASE-17328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Poon updated HBASE-17328:
-
Attachment: HBASE-17328.master.v3.patch
> Properly dispose of looped replication peers
>
>
> Key: HBASE-17328
> URL: https://issues.apache.org/jira/browse/HBASE-17328
> Project: HBase
> Issue Type: Bug
> Components: Replication
>Affects Versions: 2.0.0, 1.4.0, 0.98.23
>Reporter: Vincent Poon
>Assignee: Vincent Poon
>Priority: Critical
> Fix For: 2.0.0, 1.3.0, 1.4.0, 1.2.5, 0.98.24, 1.1.9
>
> Attachments: HBASE-17328-1.1.v1.patch, HBASE-17328-master.v1.patch,
> HBASE-17328-master.v2.patch, HBASE-17328.branch-1.1.v2.patch,
> HBASE-17328.master.v3.patch
>
>
> When adding a looped replication peer (clusterId == peerClusterId), the
> following code terminates the replication source thread, but since the source
> manager still holds a reference, WALs continue to get enqueued, and never get
> cleaned because they're stuck in the queue, leading to an unsustainable
> buildup. Furthermore, the replication statistics thread will continue to
> print statistics for the terminated source.
> {code}
> if (clusterId.equals(peerClusterId) &&
> !replicationEndpoint.canReplicateToSameCluster()) {
> this.terminate("ClusterId " + clusterId + " is replicating to itself:
> peerClusterId "
> + peerClusterId + " which is not allowed by ReplicationEndpoint:"
> + replicationEndpoint.getClass().getName(), null, false);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-17330) SnapshotFileCache will always refresh the file cache
[
https://issues.apache.org/jira/browse/HBASE-17330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15758387#comment-15758387
]
Hadoop QA commented on HBASE-17330:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 13s
{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} 2m
57s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 36s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
44s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
14s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
46s {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
43s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 37s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 37s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
46s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
14s {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}
26m 24s {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-alpha1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
54s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 27s
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 94m 29s {color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
14s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 133m 6s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.client.TestAsyncGetMultiThread |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:8d52d23 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12843735/HBASE-17330-v2.patch |
| JIRA Issue | HBASE-17330 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux e3ac85c666c1 3.13.0-93-generic #140-Ubuntu SMP Mon Jul 18
21:21:05 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / f041306 |
| Default Java | 1.8.0_111 |
| findbugs | v3.0.0 |
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/4967/artifact/patchprocess/patch-unit-hbase-server.txt
|
| unit test logs |
https://builds.apache.org/job/PreCommit-HBASE-Build/4967/artifact/patchprocess/patch-unit-hbase-server.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/4967/testReport/ |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/4967/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> Snapsho
