[jira] [Created] (HBASE-11766) Backdoor CoprocessorHConnection is no longer being used for local writes

James Taylor created HBASE-11766: Summary: Backdoor CoprocessorHConnection is no longer being used for local writes Key: HBASE-11766 URL: https://issues.apache.org/jira/browse/HBASE-11766 Project: HBa

[jira] [Created] (HBASE-11765) ReplicationSink should merge the Put/Delete of the same row into one Action even if they are from different hlog entry.

Tianying Chang created HBASE-11765: -- Summary: ReplicationSink should merge the Put/Delete of the same row into one Action even if they are from different hlog entry. Key: HBASE-11765 URL: https://issues.apache.or

Re: Failed testcase is running locally fine.

> I ran the same test case locally, it ran successfully. Even the testcase is ​ not relevant to the commits that I made. ​​ This happens occasionally. Precommit builds rely on a stable trunk and stable text executors for providing clean results. Yet both trunk and the health of our Jenkins test en

[jira] [Created] (HBASE-11763) Move TTL handling into ScanQueryMatcher

Andrew Purtell created HBASE-11763: -- Summary: Move TTL handling into ScanQueryMatcher Key: HBASE-11763 URL: https://issues.apache.org/jira/browse/HBASE-11763 Project: HBase Issue Type: Sub-t

[jira] [Created] (HBASE-11764) Support per cell TTLs

Andrew Purtell created HBASE-11764: -- Summary: Support per cell TTLs Key: HBASE-11764 URL: https://issues.apache.org/jira/browse/HBASE-11764 Project: HBase Issue Type: Sub-task Re

Failed testcase is running locally fine.

I got a failed test case from jenkins https://issues.apache.org/jira/browse/ HBASE -11699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14099036#comment-14099036 I ran the same test case locally, it ran successfully. Even the testcase is not relevant to the

[jira] [Created] (HBASE-11762) Record the class name of Codec in WAL header

Ted Yu created HBASE-11762: -- Summary: Record the class name of Codec in WAL header Key: HBASE-11762 URL: https://issues.apache.org/jira/browse/HBASE-11762 Project: HBase Issue Type: Task

[jira] [Created] (HBASE-11761) Add a FAQ item for updating a maven-managed application from 0.94 -> 0.96+

Sean Busbey created HBASE-11761: --- Summary: Add a FAQ item for updating a maven-managed application from 0.94 -> 0.96+ Key: HBASE-11761 URL: https://issues.apache.org/jira/browse/HBASE-11761 Project: HBa

Re: A better way to migrate the whole cluster?

Bryan: Thanks for sharing your valuable experience. bq. the diff function should be changed to inspect the actual HFiles Inspecting / comparing metadata for actual HFiles should help. On Fri, Aug 15, 2014 at 11:27 AM, Bryan Beaudreault < bbeaudrea...@hubspot.com> wrote: > The reason it swallow

[jira] [Created] (HBASE-11760) Tighten up region state transition

Jimmy Xiang created HBASE-11760: --- Summary: Tighten up region state transition Key: HBASE-11760 URL: https://issues.apache.org/jira/browse/HBASE-11760 Project: HBase Issue Type: Improvement

[jira] [Created] (HBASE-11759) TableZnode should be cached

Virag Kothari created HBASE-11759: - Summary: TableZnode should be cached Key: HBASE-11759 URL: https://issues.apache.org/jira/browse/HBASE-11759 Project: HBase Issue Type: Bug Rep

Re: A better way to migrate the whole cluster?

The reason it swallows exceptions is because the idea is that you first run a diff, then use the output of that diff as the input of the Backup job. So if a HFile fails to copy, the job will still finish, copying most of the HFiles. Then you run the diff again, and it will see that an HFile was m

[jira] [Created] (HBASE-11758) Meta region location should be cached

Virag Kothari created HBASE-11758: - Summary: Meta region location should be cached Key: HBASE-11758 URL: https://issues.apache.org/jira/browse/HBASE-11758 Project: HBase Issue Type: Bug

Re: Decrypting Hadoop QA response

Fro #1, see https://builds.apache.org/job/PreCommit-HBASE-Build/10458/artifact/patchprocess/patchJavadocWarnings.txt for details on the javadoc warning. For #2, the long lines seem to come from hbase-protocol/src/main/java/org/apache/hadoop/hbase/protobuf/generated/MasterProtos.java You don't need

Decrypting Hadoop QA response

I got the automated message from Hadoop QA https://issues.apache.org/jira/browse/HBASE-11699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14098769#comment-14098769 I have few questions on this, your help would be appreciated 1) it says -1 for javadoc warn

Re: A better way to migrate the whole cluster?

Well, 1.8TB in 24h is 1.8/24/3600TB/s ~ 22KB/s. That seems pretty slow to me. :) My bet is still on scanner caching set to 1 by default in 0.94 (and hence each mapper does an RPC for every single row, making this is a local latency problem not a bandwidth problem). As stated in other email, try

Re: A better way to migrate the whole cluster?

Try to add these: -Dhbase.client.scanner.caching=100 -Dmapred.map.tasks.speculative.execution=false Also, as others pointed out, what's the bandwidth between the two clusters? From: tobe To: dev@hbase.apache.org; lars hofhansl Sent: Thursday, August 14,

Re: A better way to migrate the whole cluster?

Bryan: >From javadoc of Backup.java: bq. it favors swallowing exceptions and incrementing counters as opposed to failing Can you share some experience how you handled the errors reported by Backup ? Thanks On Fri, Aug 15, 2014 at 10:38 AM, Bryan Beaudreault < bbeaudrea...@hubspot.com> wrote: >

Re: A better way to migrate the whole cluster?

I agree it would be nice if this was provided by HBase, but it's already possible to work straight with the HFiles. All you need is a custom hadoop job. A good starting point is https://github.com/mozilla-metrics/akela/blob/master/src/main/java/com/mozilla/hadoop/Backup.java and modify it to your

[jira] [Created] (HBASE-11757) Provide a common default abstract class for both RegionObserver and MasterObserver

Andrew Purtell created HBASE-11757: -- Summary: Provide a common default abstract class for both RegionObserver and MasterObserver Key: HBASE-11757 URL: https://issues.apache.org/jira/browse/HBASE-11757

Re: A better way to migrate the whole cluster?

1.8TB in a day is not terrible slow if that number comes from the CopyTable counters and you are moving data across data centers using public networks, that should be about 20MB/sec. Also, CopyTable won't compress anything on the wire so the network overhead should be a lot. If you use anything lik

[jira] [Created] (HBASE-11756) Some assignment notifications are not triggered

Jimmy Xiang created HBASE-11756: --- Summary: Some assignment notifications are not triggered Key: HBASE-11756 URL: https://issues.apache.org/jira/browse/HBASE-11756 Project: HBase Issue Type: Bug

Re: Updated the patch, but Hadoop QA has not triggered yet.

I went through recent QA runs and found this attempt for HBASE-11699 : https://builds.apache.org/job/PreCommit-HBASE-Build/10452/console Building remotely on ubuntu3 (Ubuntu ubuntu) in workspace /home

Updated the patch, but Hadoop QA has not triggered yet.

Updated the patch at https://issues.apache.org/jira/browse/HBASE-11699, but Hadoop QA has not triggered yet. Did I make any mistake? Thanks & Regards,

Re: Permission about table snapshot operations

I'm +1 to change preSnapshot() to allow global admin and table admin. but unless you add a "owner" to the SnapshotDescriptor, only a global admin can perform restore, clone or delete. Matteo On Fri, Aug 15, 2014 at 10:02 AM, liushaohui wrote: > hi all: > > In current codebase, the table snaps

[jira] [Created] (HBASE-11755) VisibilityController returns the wrong value for preBalanceSwitch()

Matteo Bertozzi created HBASE-11755: --- Summary: VisibilityController returns the wrong value for preBalanceSwitch() Key: HBASE-11755 URL: https://issues.apache.org/jira/browse/HBASE-11755 Project: HB

Permission about table snapshot operations

hi all: In current codebase, the table snapshot operations only can be done by the global admin , not by the table admin. Please see:AccessController.java# 1175. Is there any special purposes to limit the table admin to do snapshot operations? Here is our scenario: There is a big share hb