[jira] [Created] (HBASE-20687) Implement security policy save and restore tool
Alex Araujo created HBASE-20687: --- Summary: Implement security policy save and restore tool Key: HBASE-20687 URL: https://issues.apache.org/jira/browse/HBASE-20687 Project: HBase Issue Type: Improvement Reporter: Alex Araujo Assignee: Alex Araujo Extract ACL (accesscontroller) and label (visibilitycontroller) metadata, persist it, allow for restore by namespace or by table (or globally, of course). That would be a big level up for operability of the security features. Kudos to [~apurtell] for this idea. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-17721) Provide streaming APIs with SSL/TLS
[ https://issues.apache.org/jira/browse/HBASE-17721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16070752#comment-16070752 ] Alex Araujo commented on HBASE-17721: - Looks promising. I spot checked the hbase-thirdparty poms and jsr305 is excluded there but not banned as with HBASE-17721. As long as it remains that way we shouldn't see the same issue. Will rebase and resume the grpc experiment soon. > Provide streaming APIs with SSL/TLS > --- > > Key: HBASE-17721 > URL: https://issues.apache.org/jira/browse/HBASE-17721 > Project: HBase > Issue Type: Umbrella > Components: rpc, security >Reporter: Alex Araujo >Assignee: Alex Araujo > Fix For: 2.0.0 > > Attachments: 0001-Initial-add-of-grpc.patch > > > Umbrella to add optional client/server streaming capabilities to HBase. > This would allow bandwidth to be used more efficiently for certain > operations, and allow clients to use SSL/TLS for authentication and > encryption. > Desired client/server scaffolding: > - HTTP/2 support > - Protocol negotiation (blocking vs streaming, auth, encryption, etc.) > - TLS/SSL support > - Streaming RPC support > Possibilities (and their tradeoffs): > - gRPC: Some initial work and discussion on HBASE-13467 (Prototype using GRPC > as IPC mechanism) > -- Has most or all of the desired scaffolding > -- Adds additional g* dependencies. Compat story for g* dependencies not > always ideal > - Custom HTTP/2 based client/server APIs > -- More control over compat story > -- Non-trivial to build scaffolding; might reinvent wheels along the way > - Others? > Related Jiras that might be rolled in as sub-tasks (or closed/replaced with > new ones): > HBASE-17708 (Expose config to set two-way auth over TLS in HttpServer and add > a test) > HBASE-8691 (High-Throughput Streaming Scan API) > HBASE-14899 (Create custom Streaming ReplicationEndpoint) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (HBASE-17721) Provide streaming APIs with SSL/TLS
[ https://issues.apache.org/jira/browse/HBASE-17721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16070752#comment-16070752 ] Alex Araujo edited comment on HBASE-17721 at 6/30/17 9:29 PM: -- Looks promising. I spot checked the hbase-thirdparty poms and jsr305 is excluded there but not banned as with HBASE-16321. As long as it remains that way we shouldn't see the same issue. Will rebase and resume the grpc experiment soon. was (Author: alexaraujo): Looks promising. I spot checked the hbase-thirdparty poms and jsr305 is excluded there but not banned as with HBASE-17721. As long as it remains that way we shouldn't see the same issue. Will rebase and resume the grpc experiment soon. > Provide streaming APIs with SSL/TLS > --- > > Key: HBASE-17721 > URL: https://issues.apache.org/jira/browse/HBASE-17721 > Project: HBase > Issue Type: Umbrella > Components: rpc, security >Reporter: Alex Araujo >Assignee: Alex Araujo > Fix For: 2.0.0 > > Attachments: 0001-Initial-add-of-grpc.patch > > > Umbrella to add optional client/server streaming capabilities to HBase. > This would allow bandwidth to be used more efficiently for certain > operations, and allow clients to use SSL/TLS for authentication and > encryption. > Desired client/server scaffolding: > - HTTP/2 support > - Protocol negotiation (blocking vs streaming, auth, encryption, etc.) > - TLS/SSL support > - Streaming RPC support > Possibilities (and their tradeoffs): > - gRPC: Some initial work and discussion on HBASE-13467 (Prototype using GRPC > as IPC mechanism) > -- Has most or all of the desired scaffolding > -- Adds additional g* dependencies. Compat story for g* dependencies not > always ideal > - Custom HTTP/2 based client/server APIs > -- More control over compat story > -- Non-trivial to build scaffolding; might reinvent wheels along the way > - Others? > Related Jiras that might be rolled in as sub-tasks (or closed/replaced with > new ones): > HBASE-17708 (Expose config to set two-way auth over TLS in HttpServer and add > a test) > HBASE-8691 (High-Throughput Streaming Scan API) > HBASE-14899 (Create custom Streaming ReplicationEndpoint) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-17721) Provide streaming APIs with SSL/TLS
[ https://issues.apache.org/jira/browse/HBASE-17721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16070519#comment-16070519 ] Alex Araujo commented on HBASE-17721: - Not required at runtime if grpc-core only pulls in annotations from jsr305. That might be the case. > Provide streaming APIs with SSL/TLS > --- > > Key: HBASE-17721 > URL: https://issues.apache.org/jira/browse/HBASE-17721 > Project: HBase > Issue Type: Umbrella > Components: rpc, security >Reporter: Alex Araujo >Assignee: Alex Araujo > Fix For: 2.0.0 > > > Umbrella to add optional client/server streaming capabilities to HBase. > This would allow bandwidth to be used more efficiently for certain > operations, and allow clients to use SSL/TLS for authentication and > encryption. > Desired client/server scaffolding: > - HTTP/2 support > - Protocol negotiation (blocking vs streaming, auth, encryption, etc.) > - TLS/SSL support > - Streaming RPC support > Possibilities (and their tradeoffs): > - gRPC: Some initial work and discussion on HBASE-13467 (Prototype using GRPC > as IPC mechanism) > -- Has most or all of the desired scaffolding > -- Adds additional g* dependencies. Compat story for g* dependencies not > always ideal > - Custom HTTP/2 based client/server APIs > -- More control over compat story > -- Non-trivial to build scaffolding; might reinvent wheels along the way > - Others? > Related Jiras that might be rolled in as sub-tasks (or closed/replaced with > new ones): > HBASE-17708 (Expose config to set two-way auth over TLS in HttpServer and add > a test) > HBASE-8691 (High-Throughput Streaming Scan API) > HBASE-14899 (Create custom Streaming ReplicationEndpoint) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-17721) Provide streaming APIs with SSL/TLS
[ https://issues.apache.org/jira/browse/HBASE-17721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16070169#comment-16070169 ] Alex Araujo commented on HBASE-17721: - Looks like it is required for runtime: https://mvnrepository.com/artifact/io.grpc/grpc-core/1.4.0 > Provide streaming APIs with SSL/TLS > --- > > Key: HBASE-17721 > URL: https://issues.apache.org/jira/browse/HBASE-17721 > Project: HBase > Issue Type: Umbrella > Components: rpc, security >Reporter: Alex Araujo >Assignee: Alex Araujo > Fix For: 2.0.0 > > > Umbrella to add optional client/server streaming capabilities to HBase. > This would allow bandwidth to be used more efficiently for certain > operations, and allow clients to use SSL/TLS for authentication and > encryption. > Desired client/server scaffolding: > - HTTP/2 support > - Protocol negotiation (blocking vs streaming, auth, encryption, etc.) > - TLS/SSL support > - Streaming RPC support > Possibilities (and their tradeoffs): > - gRPC: Some initial work and discussion on HBASE-13467 (Prototype using GRPC > as IPC mechanism) > -- Has most or all of the desired scaffolding > -- Adds additional g* dependencies. Compat story for g* dependencies not > always ideal > - Custom HTTP/2 based client/server APIs > -- More control over compat story > -- Non-trivial to build scaffolding; might reinvent wheels along the way > - Others? > Related Jiras that might be rolled in as sub-tasks (or closed/replaced with > new ones): > HBASE-17708 (Expose config to set two-way auth over TLS in HttpServer and add > a test) > HBASE-8691 (High-Throughput Streaming Scan API) > HBASE-14899 (Create custom Streaming ReplicationEndpoint) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-17721) Provide streaming APIs with SSL/TLS
[ https://issues.apache.org/jira/browse/HBASE-17721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16069297#comment-16069297 ] Alex Araujo commented on HBASE-17721: - I've been following HBASE-18240. Last time I tried to shade grpc, com.google.code.findbugs:jsr305 was pulled in transitively and the build failed due to the HBASE-16321 restriction. I'll take another look soon. Assuming it's still a transitive dep, would we allow jsr305 transitively in hbase-thirdparty? [~busbey] might be able to tell us. > Provide streaming APIs with SSL/TLS > --- > > Key: HBASE-17721 > URL: https://issues.apache.org/jira/browse/HBASE-17721 > Project: HBase > Issue Type: Umbrella > Components: rpc, security >Reporter: Alex Araujo >Assignee: Alex Araujo > Fix For: 2.0.0 > > > Umbrella to add optional client/server streaming capabilities to HBase. > This would allow bandwidth to be used more efficiently for certain > operations, and allow clients to use SSL/TLS for authentication and > encryption. > Desired client/server scaffolding: > - HTTP/2 support > - Protocol negotiation (blocking vs streaming, auth, encryption, etc.) > - TLS/SSL support > - Streaming RPC support > Possibilities (and their tradeoffs): > - gRPC: Some initial work and discussion on HBASE-13467 (Prototype using GRPC > as IPC mechanism) > -- Has most or all of the desired scaffolding > -- Adds additional g* dependencies. Compat story for g* dependencies not > always ideal > - Custom HTTP/2 based client/server APIs > -- More control over compat story > -- Non-trivial to build scaffolding; might reinvent wheels along the way > - Others? > Related Jiras that might be rolled in as sub-tasks (or closed/replaced with > new ones): > HBASE-17708 (Expose config to set two-way auth over TLS in HttpServer and add > a test) > HBASE-8691 (High-Throughput Streaming Scan API) > HBASE-14899 (Create custom Streaming ReplicationEndpoint) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18184) Add hbase-hadoop2-compat jar as MapReduce job dependency
[ https://issues.apache.org/jira/browse/HBASE-18184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16041572#comment-16041572 ] Alex Araujo commented on HBASE-18184: - Thanks for the review. The patch applies to branch-1 as well. > Add hbase-hadoop2-compat jar as MapReduce job dependency > > > Key: HBASE-18184 > URL: https://issues.apache.org/jira/browse/HBASE-18184 > Project: HBase > Issue Type: Bug > Components: mapreduce >Affects Versions: 2.0.0, 1.4.0 >Reporter: Alex Araujo >Assignee: Alex Araujo >Priority: Minor > Fix For: 2.0.0, 1.4.0 > > Attachments: HBASE-18184.patch > > > HBASE-17448 added a dependency on hbase-hadoop2-compat for MapReduce jobs. > Explicitly add this jar dependency in TableMapReduceUtil. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-18184) Add hbase-hadoop2-compat jar as MapReduce job dependency
[ https://issues.apache.org/jira/browse/HBASE-18184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Araujo updated HBASE-18184: Attachment: HBASE-18184.patch Patch for master. FYI [~apurtell]. Will attach branch-1 patch shortly. > Add hbase-hadoop2-compat jar as MapReduce job dependency > > > Key: HBASE-18184 > URL: https://issues.apache.org/jira/browse/HBASE-18184 > Project: HBase > Issue Type: Bug > Components: mapreduce >Affects Versions: 2.0.0, 1.4.0 >Reporter: Alex Araujo >Assignee: Alex Araujo >Priority: Minor > Fix For: 2.0.0, 1.4.0 > > Attachments: HBASE-18184.patch > > > HBASE-17448 added a dependency on hbase-hadoop2-compat for MapReduce jobs. > Explicitly add this jar dependency in TableMapReduceUtil. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (HBASE-18184) Add hbase-hadoop2-compat jar as MapReduce job dependency
Alex Araujo created HBASE-18184: --- Summary: Add hbase-hadoop2-compat jar as MapReduce job dependency Key: HBASE-18184 URL: https://issues.apache.org/jira/browse/HBASE-18184 Project: HBase Issue Type: Bug Components: mapreduce Affects Versions: 2.0.0, 1.4.0 Reporter: Alex Araujo Assignee: Alex Araujo Priority: Minor Fix For: 2.0.0, 1.4.0 HBASE-17448 added a dependency on hbase-hadoop2-compat for MapReduce jobs. Explicitly add this jar dependency in TableMapReduceUtil. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17721) Provide streaming APIs with SSL/TLS
[ https://issues.apache.org/jira/browse/HBASE-17721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15955797#comment-15955797 ] Alex Araujo commented on HBASE-17721: - I was able to compile existing protos and grpc protos within hbase-protocol-shaded using grpc 1.1.2 and protobuf 3.1.0. I got hung up on shading grpc and its dependencies (grpc-core depends on com.google.code.findbugs:jsr305, which HBase does not allow). [~apurtell] suggested building a grpc-shaded module outside of HBase and pulling it in as a dependency rather than building it. I was planning on trying that or punting on shading grpc for the time being to get some benchmarks for HBASE-13467. Given other priorities, I'll likely get to that in a couple of weeks. > Provide streaming APIs with SSL/TLS > --- > > Key: HBASE-17721 > URL: https://issues.apache.org/jira/browse/HBASE-17721 > Project: HBase > Issue Type: Umbrella > Components: rpc, security >Reporter: Alex Araujo >Assignee: Alex Araujo > Fix For: 2.0.0 > > > Umbrella to add optional client/server streaming capabilities to HBase. > This would allow bandwidth to be used more efficiently for certain > operations, and allow clients to use SSL/TLS for authentication and > encryption. > Desired client/server scaffolding: > - HTTP/2 support > - Protocol negotiation (blocking vs streaming, auth, encryption, etc.) > - TLS/SSL support > - Streaming RPC support > Possibilities (and their tradeoffs): > - gRPC: Some initial work and discussion on HBASE-13467 (Prototype using GRPC > as IPC mechanism) > -- Has most or all of the desired scaffolding > -- Adds additional g* dependencies. Compat story for g* dependencies not > always ideal > - Custom HTTP/2 based client/server APIs > -- More control over compat story > -- Non-trivial to build scaffolding; might reinvent wheels along the way > - Others? > Related Jiras that might be rolled in as sub-tasks (or closed/replaced with > new ones): > HBASE-17708 (Expose config to set two-way auth over TLS in HttpServer and add > a test) > HBASE-8691 (High-Throughput Streaming Scan API) > HBASE-14899 (Create custom Streaming ReplicationEndpoint) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17721) Provide streaming APIs with SSL/TLS
[ https://issues.apache.org/jira/browse/HBASE-17721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15893192#comment-15893192 ] Alex Araujo commented on HBASE-17721: - gRPC has come along way since HBASE-13467 was last touched, and 2.x seems to have the right dependency versions now besides Guava. Perhaps a good starting point would be to provide a new patch there. Good call on avoiding an additional port if possible. > Provide streaming APIs with SSL/TLS > --- > > Key: HBASE-17721 > URL: https://issues.apache.org/jira/browse/HBASE-17721 > Project: HBase > Issue Type: Umbrella >Reporter: Alex Araujo >Assignee: Alex Araujo > Fix For: 2.0.0 > > > Umbrella to add optional client/server streaming capabilities to HBase. > This would allow bandwidth to be used more efficiently for certain > operations, and allow clients to use SSL/TLS for authentication and > encryption. > Desired client/server scaffolding: > - HTTP/2 support > - Protocol negotiation (blocking vs streaming, auth, encryption, etc.) > - TLS/SSL support > - Streaming RPC support > Possibilities (and their tradeoffs): > - gRPC: Some initial work and discussion on HBASE-13467 (Prototype using GRPC > as IPC mechanism) > -- Has most or all of the desired scaffolding > -- Adds additional g* dependencies. Compat story for g* dependencies not > always ideal > - Custom HTTP/2 based client/server APIs > -- More control over compat story > -- Non-trivial to build scaffolding; might reinvent wheels along the way > - Others? > Related Jiras that might be rolled in as sub-tasks (or closed/replaced with > new ones): > HBASE-17708 (Expose config to set two-way auth over TLS in HttpServer and add > a test) > HBASE-8691 (High-Throughput Streaming Scan API) > HBASE-14899 (Create custom Streaming ReplicationEndpoint) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (HBASE-17721) Provide streaming APIs with SSL/TLS
Alex Araujo created HBASE-17721: --- Summary: Provide streaming APIs with SSL/TLS Key: HBASE-17721 URL: https://issues.apache.org/jira/browse/HBASE-17721 Project: HBase Issue Type: Umbrella Reporter: Alex Araujo Assignee: Alex Araujo Fix For: 2.0.0 Umbrella to add optional client/server streaming capabilities to HBase. This would allow bandwidth to be used more efficiently for certain operations, and allow clients to use SSL/TLS for authentication and encryption. Desired client/server scaffolding: - HTTP/2 support - Protocol negotiation (blocking vs streaming, auth, encryption, etc.) - TLS/SSL support - Streaming RPC support Possibilities (and their tradeoffs): - gRPC: Some initial work and discussion on HBASE-13467 (Prototype using GRPC as IPC mechanism) -- Has most or all of the desired scaffolding -- Adds additional g* dependencies. Compat story for g* dependencies not always ideal - Custom HTTP/2 based client/server APIs -- More control over compat story -- Non-trivial to build scaffolding; might reinvent wheels along the way - Others? Related Jiras that might be rolled in as sub-tasks (or closed/replaced with new ones): HBASE-17708 (Expose config to set two-way auth over TLS in HttpServer and add a test) HBASE-8691 (High-Throughput Streaming Scan API) HBASE-14899 (Create custom Streaming ReplicationEndpoint) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-14791) Batch Deletes in MapReduce jobs (0.98)
[ https://issues.apache.org/jira/browse/HBASE-14791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15014141#comment-15014141 ] Alex Araujo commented on HBASE-14791: - [~apurtell], [~vik.karma] ran a CopyTable with this patch and the job finished significantly faster: 7.5 minutes vs 8.5 hours without the patch. > Batch Deletes in MapReduce jobs (0.98) > -- > > Key: HBASE-14791 > URL: https://issues.apache.org/jira/browse/HBASE-14791 > Project: HBase > Issue Type: Bug >Affects Versions: 0.98.16 >Reporter: Lars Hofhansl >Assignee: Alex Araujo > Labels: mapreduce > Fix For: 0.98.17 > > Attachments: HBASE-14791-0.98-v1.patch, HBASE-14791-0.98-v2.patch, > HBASE-14791-0.98.patch > > > We found that some of our copy table job run for many hours, even when there > isn't that much data to copy. > [~vik.karma] did his magic and found that the issue is with copying delete > markers (we use raw mode to also move deletes across). > Looking at the code in 0.98 it's immediately obvious that deletes (unlike > puts) are not batched and hence sent to the other side one by one, causing a > network RTT for each delete marker. > Looks like in trunk it's doing the right thing (using BufferedMutators for > all mutations in TableOutputFormat). So likely only a 0.98 (and 1.0, 1.1, > 1.2?) issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14791) Batch Deletes in MapReduce jobs (0.98)
[
https://issues.apache.org/jira/browse/HBASE-14791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15011123#comment-15011123
]
Alex Araujo commented on HBASE-14791:
-
Those build failures look unrelated. HBase-0.98-on-Hadoop-1.1 has been failing
with a compilation error since
#[1132|https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/1132/]:
{noformat}
[ERROR]
/home/jenkins/jenkins-slave/workspace/HBase-0.98-on-Hadoop-1.1/hbase-common/src/main/java/org/apache/hadoop/hbase/security/UserProvider.java:[70,49]
error: cannot find symbol
{noformat}
HBase-0.98-matrix appears to have unrelated test failures. Most of the failures
have been around since
#[258|https://builds.apache.org/job/HBase-0.98-matrix/258/]. These are new, but
unrelated:
*jdk=latest1.7,label=Hadoop*
java.lang.ExceptionInInitializerError: null
at
org.apache.hadoop.hbase.HBaseConfiguration.checkDefaultsVersion(HBaseConfiguration.java:73)
hbase-default.xml file seems to be for and old version of HBase (0.98.16), this
version is 0.98.17-SNAPSHOT
java.lang.ExceptionInInitializerError: null
at
org.apache.hadoop.hbase.HBaseConfiguration.checkDefaultsVersion(HBaseConfiguration.java:73)
at
org.apache.hadoop.hbase.HBaseConfiguration.addHbaseResources(HBaseConfiguration.java:105)
at
org.apache.hadoop.hbase.HBaseConfiguration.create(HBaseConfiguration.java:120)
at
org.apache.hadoop.hbase.HBaseCommonTestingUtility.(HBaseCommonTestingUtility.java:46)
at
org.apache.hadoop.hbase.TestClassFinder.(TestClassFinder.java:57)
Could not initialize class org.apache.hadoop.hbase.TestClassFinder
java.lang.NoClassDefFoundError: Could not initialize class
org.apache.hadoop.hbase.TestClassFinder
Could not initialize class
org.apache.hadoop.hbase.util.TestCoprocessorClassLoader
java.lang.NoClassDefFoundError: Could not initialize class
org.apache.hadoop.hbase.util.TestCoprocessorClassLoader
Could not initialize class org.apache.hadoop.hbase.util.TestDynamicClassLoader
java.lang.NoClassDefFoundError: Could not initialize class
org.apache.hadoop.hbase.util.TestDynamicClassLoader
*jdk=latest1.6,label=Hadoop*
java.lang.NoSuchFieldError: in
at
org.apache.hadoop.hbase.codec.CellCodecWithTags$CellDecoder.parseCell(CellCodecWithTags.java:86)
at
org.apache.hadoop.hbase.codec.BaseDecoder.advance(BaseDecoder.java:67)
at
org.apache.hadoop.hbase.codec.TestCellCodecWithTags.testCellWithTag(TestCellCodecWithTags.java:76)
java.lang.NoSuchFieldError: in
at
org.apache.hadoop.hbase.codec.KeyValueCodec$KeyValueDecoder.parseCell(KeyValueCodec.java:70)
at
org.apache.hadoop.hbase.codec.BaseDecoder.advance(BaseDecoder.java:67)
at
org.apache.hadoop.hbase.codec.TestKeyValueCodec.testOne(TestKeyValueCodec.java:80)
> Batch Deletes in MapReduce jobs (0.98)
> --
>
> Key: HBASE-14791
> URL: https://issues.apache.org/jira/browse/HBASE-14791
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.98.16
>Reporter: Lars Hofhansl
>Assignee: Alex Araujo
> Labels: mapreduce
> Fix For: 0.98.17
>
> Attachments: HBASE-14791-0.98-v1.patch, HBASE-14791-0.98-v2.patch,
> HBASE-14791-0.98.patch
>
>
> We found that some of our copy table job run for many hours, even when there
> isn't that much data to copy.
> [~vik.karma] did his magic and found that the issue is with copying delete
> markers (we use raw mode to also move deletes across).
> Looking at the code in 0.98 it's immediately obvious that deletes (unlike
> puts) are not batched and hence sent to the other side one by one, causing a
> network RTT for each delete marker.
> Looks like in trunk it's doing the right thing (using BufferedMutators for
> all mutations in TableOutputFormat). So likely only a 0.98 (and 1.0, 1.1,
> 1.2?) issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14791) Batch Deletes in MapReduce jobs (0.98)
[ https://issues.apache.org/jira/browse/HBASE-14791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15009765#comment-15009765 ] Alex Araujo commented on HBASE-14791: - Based on [~vik.karma]'s perf analysis, this should fix the reported issue. We'll deploy the patch and verify. > Batch Deletes in MapReduce jobs (0.98) > -- > > Key: HBASE-14791 > URL: https://issues.apache.org/jira/browse/HBASE-14791 > Project: HBase > Issue Type: Bug >Affects Versions: 0.98.16 >Reporter: Lars Hofhansl >Assignee: Alex Araujo > Labels: mapreduce > Fix For: 0.98.17 > > Attachments: HBASE-14791-0.98-v1.patch, HBASE-14791-0.98-v2.patch, > HBASE-14791-0.98.patch > > > We found that some of our copy table job run for many hours, even when there > isn't that much data to copy. > [~vik.karma] did his magic and found that the issue is with copying delete > markers (we use raw mode to also move deletes across). > Looking at the code in 0.98 it's immediately obvious that deletes (unlike > puts) are not batched and hence sent to the other side one by one, causing a > network RTT for each delete marker. > Looks like in trunk it's doing the right thing (using BufferedMutators for > all mutations in TableOutputFormat). So likely only a 0.98 (and 1.0, 1.1, > 1.2?) issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14791) Batch Deletes in MapReduce jobs (0.98)
[ https://issues.apache.org/jira/browse/HBASE-14791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15010034#comment-15010034 ] Alex Araujo commented on HBASE-14791: - Thanks for reviewing and committing! > Batch Deletes in MapReduce jobs (0.98) > -- > > Key: HBASE-14791 > URL: https://issues.apache.org/jira/browse/HBASE-14791 > Project: HBase > Issue Type: Bug >Affects Versions: 0.98.16 >Reporter: Lars Hofhansl >Assignee: Alex Araujo > Labels: mapreduce > Fix For: 0.98.17 > > Attachments: HBASE-14791-0.98-v1.patch, HBASE-14791-0.98-v2.patch, > HBASE-14791-0.98.patch > > > We found that some of our copy table job run for many hours, even when there > isn't that much data to copy. > [~vik.karma] did his magic and found that the issue is with copying delete > markers (we use raw mode to also move deletes across). > Looking at the code in 0.98 it's immediately obvious that deletes (unlike > puts) are not batched and hence sent to the other side one by one, causing a > network RTT for each delete marker. > Looks like in trunk it's doing the right thing (using BufferedMutators for > all mutations in TableOutputFormat). So likely only a 0.98 (and 1.0, 1.1, > 1.2?) issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14791) [0.98] CopyTable is extremely slow when moving delete markers
[ https://issues.apache.org/jira/browse/HBASE-14791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Araujo updated HBASE-14791: Attachment: HBASE-14791-0.98.patch > [0.98] CopyTable is extremely slow when moving delete markers > - > > Key: HBASE-14791 > URL: https://issues.apache.org/jira/browse/HBASE-14791 > Project: HBase > Issue Type: Bug >Affects Versions: 0.98.16 >Reporter: Lars Hofhansl >Assignee: Alex Araujo > Attachments: HBASE-14791-0.98-v1.patch, HBASE-14791-0.98-v2.patch, > HBASE-14791-0.98.patch > > > We found that some of our copy table job run for many hours, even when there > isn't that much data to copy. > [~vik.karma] did his magic and found that the issue is with copying delete > markers (we use raw mode to also move deletes across). > Looking at the code in 0.98 it's immediately obvious that deletes (unlike > puts) are not batched and hence sent to the other side one by one, causing a > network RTT for each delete marker. > Looks like in trunk it's doing the right thing (using BufferedMutators for > all mutations in TableOutputFormat). So likely only a 0.98 (and 1.0, 1.1, > 1.2?) issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14791) [0.98] CopyTable is extremely slow when moving delete markers
[ https://issues.apache.org/jira/browse/HBASE-14791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15009558#comment-15009558 ] Alex Araujo commented on HBASE-14791: - Annotated BufferedHTable as Private and removed option to disable delete buffering in latest patch. Also dropped version number from patch name, to see if build bot runs it through tests this time. > [0.98] CopyTable is extremely slow when moving delete markers > - > > Key: HBASE-14791 > URL: https://issues.apache.org/jira/browse/HBASE-14791 > Project: HBase > Issue Type: Bug >Affects Versions: 0.98.16 >Reporter: Lars Hofhansl >Assignee: Alex Araujo > Attachments: HBASE-14791-0.98-v1.patch, HBASE-14791-0.98-v2.patch, > HBASE-14791-0.98.patch > > > We found that some of our copy table job run for many hours, even when there > isn't that much data to copy. > [~vik.karma] did his magic and found that the issue is with copying delete > markers (we use raw mode to also move deletes across). > Looking at the code in 0.98 it's immediately obvious that deletes (unlike > puts) are not batched and hence sent to the other side one by one, causing a > network RTT for each delete marker. > Looks like in trunk it's doing the right thing (using BufferedMutators for > all mutations in TableOutputFormat). So likely only a 0.98 (and 1.0, 1.1, > 1.2?) issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14791) [0.98] CopyTable is extremely slow when moving delete markers
[ https://issues.apache.org/jira/browse/HBASE-14791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Araujo updated HBASE-14791: Labels: mapreduce (was: ) Fix Version/s: 0.98.17 Status: Patch Available (was: Open) > [0.98] CopyTable is extremely slow when moving delete markers > - > > Key: HBASE-14791 > URL: https://issues.apache.org/jira/browse/HBASE-14791 > Project: HBase > Issue Type: Bug >Affects Versions: 0.98.16 >Reporter: Lars Hofhansl >Assignee: Alex Araujo > Labels: mapreduce > Fix For: 0.98.17 > > Attachments: HBASE-14791-0.98-v1.patch, HBASE-14791-0.98-v2.patch, > HBASE-14791-0.98.patch > > > We found that some of our copy table job run for many hours, even when there > isn't that much data to copy. > [~vik.karma] did his magic and found that the issue is with copying delete > markers (we use raw mode to also move deletes across). > Looking at the code in 0.98 it's immediately obvious that deletes (unlike > puts) are not batched and hence sent to the other side one by one, causing a > network RTT for each delete marker. > Looks like in trunk it's doing the right thing (using BufferedMutators for > all mutations in TableOutputFormat). So likely only a 0.98 (and 1.0, 1.1, > 1.2?) issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14791) [0.98] CopyTable is extremely slow when moving delete markers
[ https://issues.apache.org/jira/browse/HBASE-14791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15007698#comment-15007698 ] Alex Araujo commented on HBASE-14791: - [~lhofhansl], v2 attached > [0.98] CopyTable is extremely slow when moving delete markers > - > > Key: HBASE-14791 > URL: https://issues.apache.org/jira/browse/HBASE-14791 > Project: HBase > Issue Type: Bug >Affects Versions: 0.98.16 >Reporter: Lars Hofhansl >Assignee: Alex Araujo > Attachments: HBASE-14791-0.98-v1.patch, HBASE-14791-0.98-v2.patch > > > We found that some of our copy table job run for many hours, even when there > isn't that much data to copy. > [~vik.karma] did his magic and found that the issue is with copying delete > markers (we use raw mode to also move deletes across). > Looking at the code in 0.98 it's immediately obvious that deletes (unlike > puts) are not batched and hence sent to the other side one by one, causing a > network RTT for each delete marker. > Looks like in trunk it's doing the right thing (using BufferedMutators for > all mutations in TableOutputFormat). So likely only a 0.98 (and 1.0, 1.1, > 1.2?) issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14791) [0.98] CopyTable is extremely slow when moving delete markers
[ https://issues.apache.org/jira/browse/HBASE-14791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Araujo updated HBASE-14791: Attachment: HBASE-14791-0.98-v2.patch > [0.98] CopyTable is extremely slow when moving delete markers > - > > Key: HBASE-14791 > URL: https://issues.apache.org/jira/browse/HBASE-14791 > Project: HBase > Issue Type: Bug >Affects Versions: 0.98.16 >Reporter: Lars Hofhansl >Assignee: Alex Araujo > Attachments: HBASE-14791-0.98-v1.patch, HBASE-14791-0.98-v2.patch > > > We found that some of our copy table job run for many hours, even when there > isn't that much data to copy. > [~vik.karma] did his magic and found that the issue is with copying delete > markers (we use raw mode to also move deletes across). > Looking at the code in 0.98 it's immediately obvious that deletes (unlike > puts) are not batched and hence sent to the other side one by one, causing a > network RTT for each delete marker. > Looks like in trunk it's doing the right thing (using BufferedMutators for > all mutations in TableOutputFormat). So likely only a 0.98 (and 1.0, 1.1, > 1.2?) issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14791) [0.98] CopyTable is extremely slow when moving delete markers
[ https://issues.apache.org/jira/browse/HBASE-14791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15004957#comment-15004957 ] Alex Araujo commented on HBASE-14791: - Thanks for reviewing [~lhofhansl]]! Changing HTable to HTableInterface does not break compatibility for subclasses of TableOutputFormat because HTable is private. Subclassing HTable instead of using delegation would save a fair amount of boilerplate in BufferedHTable, and allow both Mutation types to share the same buffer (addresses the ordering issue). I'll upload a v2 that subclasses HTable and preserves ordering. > [0.98] CopyTable is extremely slow when moving delete markers > - > > Key: HBASE-14791 > URL: https://issues.apache.org/jira/browse/HBASE-14791 > Project: HBase > Issue Type: Bug >Affects Versions: 0.98.16 >Reporter: Lars Hofhansl >Assignee: Alex Araujo > Attachments: HBASE-14791-0.98-v1.patch > > > We found that some of our copy table job run for many hours, even when there > isn't that much data to copy. > [~vik.karma] did his magic and found that the issue is with copying delete > markers (we use raw mode to also move deletes across). > Looking at the code in 0.98 it's immediately obvious that deletes (unlike > puts) are not batched and hence sent to the other side one by one, causing a > network RTT for each delete marker. > Looks like in trunk it's doing the right thing (using BufferedMutators for > all mutations in TableOutputFormat). So likely only a 0.98 (and 1.0, 1.1, > 1.2?) issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14791) [0.98] CopyTable is extremely slow when moving delete markers
[ https://issues.apache.org/jira/browse/HBASE-14791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Araujo updated HBASE-14791: Attachment: HBASE-14791-0.98-v1.patch > [0.98] CopyTable is extremely slow when moving delete markers > - > > Key: HBASE-14791 > URL: https://issues.apache.org/jira/browse/HBASE-14791 > Project: HBase > Issue Type: Bug >Affects Versions: 0.98.16 >Reporter: Lars Hofhansl >Assignee: Alex Araujo > Attachments: HBASE-14791-0.98-v1.patch > > > We found that some of our copy table job run for many hours, even when there > isn't that much data to copy. > [~vik.karma] did his magic and found that the issue is with copying delete > markers (we use raw mode to also move deletes across). > Looking at the code in 0.98 it's immediately obvious that deletes (unlike > puts) are not batched and hence sent to the other side one by one, causing a > network RTT for each delete marker. > Looks like in trunk it's doing the right thing (using BufferedMutators for > all mutations in TableOutputFormat). So likely only a 0.98 (and 1.0, 1.1, > 1.2?) issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14791) [0.98] CopyTable is extremely slow when moving delete markers
[ https://issues.apache.org/jira/browse/HBASE-14791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15001464#comment-15001464 ] Alex Araujo commented on HBASE-14791: - Attached a v1 that does size based buffering for Deletes, similar to how Puts are buffered. It does not change 0.98 HTable semantics, and is disabled by default as [~apurtell] suggested. I agree that two buffering mechanisms is not ideal. If correctness is an issue and/or we want to avoid separate buffers, we could try to use the Put buffering in HTable for both and disable it for Deletes by default. That would align 0.98 buffering more closely with BufferedMutator in 1.0+, but would also be more invasive. > [0.98] CopyTable is extremely slow when moving delete markers > - > > Key: HBASE-14791 > URL: https://issues.apache.org/jira/browse/HBASE-14791 > Project: HBase > Issue Type: Bug >Affects Versions: 0.98.16 >Reporter: Lars Hofhansl >Assignee: Alex Araujo > Attachments: HBASE-14791-0.98-v1.patch > > > We found that some of our copy table job run for many hours, even when there > isn't that much data to copy. > [~vik.karma] did his magic and found that the issue is with copying delete > markers (we use raw mode to also move deletes across). > Looking at the code in 0.98 it's immediately obvious that deletes (unlike > puts) are not batched and hence sent to the other side one by one, causing a > network RTT for each delete marker. > Looks like in trunk it's doing the right thing (using BufferedMutators for > all mutations in TableOutputFormat). So likely only a 0.98 (and 1.0, 1.1, > 1.2?) issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (HBASE-14791) [0.98] CopyTable is extremely slow when moving delete markers
[ https://issues.apache.org/jira/browse/HBASE-14791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Araujo reassigned HBASE-14791: --- Assignee: Alex Araujo [~lhofhansl] I can take this > [0.98] CopyTable is extremely slow when moving delete markers > - > > Key: HBASE-14791 > URL: https://issues.apache.org/jira/browse/HBASE-14791 > Project: HBase > Issue Type: Bug >Affects Versions: 0.98.16 >Reporter: Lars Hofhansl >Assignee: Alex Araujo > > We found that some of our copy table job run for many hours, even when there > isn't that much data to copy. > [~vik.karma] did his magic and found that the issue with copying delete > markers (we use raw mode to also move deletes across). > Looking at the code in 0.98 it's immediately obvious that deletes (unlike > puts) are not batched and hence sent to the other side one by one, cause a > network RTT for each delete marker. > Looks like in trunk it's doing the right thing (using BufferedMutators for > all mutations in TableOutputFormat). So likely only a 0.98 (and 1.0, 1.1, > 1.2?) issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14791) [0.98] CopyTable is extremely slow when moving delete markers
[ https://issues.apache.org/jira/browse/HBASE-14791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14999243#comment-14999243 ] Alex Araujo commented on HBASE-14791: - The patch for HBASE-12728 moved buffering of Puts from HTable into BufferedMutator for 1.0+. Since BufferedMutator is not Put specific, it also made TableOutputFormat and MultiTableOutputFormat use BufferedMutator for all Mutation types. In 0.98 there is no buffering of Deletes in HTable or elsewhere as far as I can tell. Essentially, we'd need to implement a basic BufferedMutator and use it for both OutputFormat types. The downside is that we would be duplicating some of the buffering code in HTable. > [0.98] CopyTable is extremely slow when moving delete markers > - > > Key: HBASE-14791 > URL: https://issues.apache.org/jira/browse/HBASE-14791 > Project: HBase > Issue Type: Bug >Affects Versions: 0.98.16 >Reporter: Lars Hofhansl >Assignee: Alex Araujo > > We found that some of our copy table job run for many hours, even when there > isn't that much data to copy. > [~vik.karma] did his magic and found that the issue is with copying delete > markers (we use raw mode to also move deletes across). > Looking at the code in 0.98 it's immediately obvious that deletes (unlike > puts) are not batched and hence sent to the other side one by one, causing a > network RTT for each delete marker. > Looks like in trunk it's doing the right thing (using BufferedMutators for > all mutations in TableOutputFormat). So likely only a 0.98 (and 1.0, 1.1, > 1.2?) issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13183) Make ZK tickTime configurable in standalone HBase
[ https://issues.apache.org/jira/browse/HBASE-13183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14354893#comment-14354893 ] Alex Araujo commented on HBASE-13183: - Thanks for committing [~apurtell]. I looked at the build and test failures above and they appear to be unrelated to this change. Make ZK tickTime configurable in standalone HBase - Key: HBASE-13183 URL: https://issues.apache.org/jira/browse/HBASE-13183 Project: HBase Issue Type: Improvement Components: master Affects Versions: 0.98.10.1 Reporter: Alex Araujo Assignee: Alex Araujo Priority: Minor Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.12 Attachments: HBASE-13183-0.98.patch, HBASE-13183.patch Standalone HBase does not allow the ZooKeeper tickTime to be configured for the MiniZooKeeperCluster. The default tickTime for MiniZooKeeperCluster is 2000 ms, which is too low for some use cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13183) Make ZK tickTime configurable in standalone HBase
[ https://issues.apache.org/jira/browse/HBASE-13183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Araujo updated HBASE-13183: Attachment: HBASE-13183-0.98.patch Attaching 0.98 patch Make ZK tickTime configurable in standalone HBase - Key: HBASE-13183 URL: https://issues.apache.org/jira/browse/HBASE-13183 Project: HBase Issue Type: Improvement Components: master Affects Versions: 0.98.10.1 Reporter: Alex Araujo Assignee: Alex Araujo Priority: Minor Attachments: HBASE-13183-0.98.patch Standalone HBase does not allow the ZooKeeper tickTime to be configured for the MiniZooKeeperCluster. The default tickTime for MiniZooKeeperCluster is 2000 ms, which is too low for some use cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-13183) Make ZK tickTime configurable in standalone HBase
Alex Araujo created HBASE-13183: --- Summary: Make ZK tickTime configurable in standalone HBase Key: HBASE-13183 URL: https://issues.apache.org/jira/browse/HBASE-13183 Project: HBase Issue Type: Improvement Components: master Affects Versions: 0.98.10.1 Reporter: Alex Araujo Assignee: Alex Araujo Priority: Minor Standalone HBase does not allow the ZooKeeper tickTime to be configured for the MiniZooKeeperCluster. The default tickTime for MiniZooKeeperCluster is 2000 ms, which is too low for some use cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-13104) ZooKeeper session timeout cannot be changed for standalone HBase
Alex Araujo created HBASE-13104: --- Summary: ZooKeeper session timeout cannot be changed for standalone HBase Key: HBASE-13104 URL: https://issues.apache.org/jira/browse/HBASE-13104 Project: HBase Issue Type: Bug Components: master Affects Versions: 0.98.10.1 Reporter: Alex Araujo It's not possible to increase the ZooKeeper session timeout in standalone HBase due to a hardcoded 10s timeout in HMasterCommandLine: https://github.com/apache/hbase/blob/0.98/hbase-server/src/main/java/org/apache/hadoop/hbase/master/HMasterCommandLine.java#L176 In trunk you can append .localHBaseCluster to the ZK session timeout property name to change the timeout: https://github.com/apache/hbase/blob/master/hbase-server/src/main/java/org/apache/hadoop/hbase/master/HMasterCommandLine.java#L169-171 We should allow changing the timeout in 0.98 and other versions where it's not possible to do so. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13104) ZooKeeper session timeout cannot be changed for standalone HBase
[ https://issues.apache.org/jira/browse/HBASE-13104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Araujo updated HBASE-13104: Attachment: HBASE-13104-0.98.patch ZooKeeper session timeout cannot be changed for standalone HBase Key: HBASE-13104 URL: https://issues.apache.org/jira/browse/HBASE-13104 Project: HBase Issue Type: Bug Components: master Affects Versions: 0.98.10.1 Reporter: Alex Araujo Assignee: Alex Araujo Fix For: 0.98.11 Attachments: HBASE-13104-0.98.patch It's not possible to increase the ZooKeeper session timeout in standalone HBase due to a hardcoded 10s timeout in HMasterCommandLine: https://github.com/apache/hbase/blob/0.98/hbase-server/src/main/java/org/apache/hadoop/hbase/master/HMasterCommandLine.java#L176 In trunk you can append .localHBaseCluster to the ZK session timeout property name to change the timeout: https://github.com/apache/hbase/blob/master/hbase-server/src/main/java/org/apache/hadoop/hbase/master/HMasterCommandLine.java#L169-171 We should allow changing the timeout in 0.98 and other versions where it's not possible to do so. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13104) ZooKeeper session timeout cannot be changed for standalone HBase
[ https://issues.apache.org/jira/browse/HBASE-13104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Araujo updated HBASE-13104: Status: Patch Available (was: Open) 0.94 does not appear to set the ZK session timeout in HMasterCommandLine. Attaching a patch for 0.98. ZooKeeper session timeout cannot be changed for standalone HBase Key: HBASE-13104 URL: https://issues.apache.org/jira/browse/HBASE-13104 Project: HBase Issue Type: Bug Components: master Affects Versions: 0.98.10.1 Reporter: Alex Araujo Assignee: Alex Araujo Fix For: 0.98.11 Attachments: HBASE-13104-0.98.patch It's not possible to increase the ZooKeeper session timeout in standalone HBase due to a hardcoded 10s timeout in HMasterCommandLine: https://github.com/apache/hbase/blob/0.98/hbase-server/src/main/java/org/apache/hadoop/hbase/master/HMasterCommandLine.java#L176 In trunk you can append .localHBaseCluster to the ZK session timeout property name to change the timeout: https://github.com/apache/hbase/blob/master/hbase-server/src/main/java/org/apache/hadoop/hbase/master/HMasterCommandLine.java#L169-171 We should allow changing the timeout in 0.98 and other versions where it's not possible to do so. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-8740) Generate unique table names in TestAccessController
Alex Araujo created HBASE-8740: -- Summary: Generate unique table names in TestAccessController Key: HBASE-8740 URL: https://issues.apache.org/jira/browse/HBASE-8740 Project: HBase Issue Type: Improvement Reporter: Alex Araujo Priority: Minor This test class creates/drops a table named 'testtable' for 30+ tests. Having tables named after each test method may help diagnose test failures. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8740) Generate unique table names in TestAccessController
[ https://issues.apache.org/jira/browse/HBASE-8740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Araujo updated HBASE-8740: --- Attachment: HBASE-8740.patch Generate unique table names in TestAccessController --- Key: HBASE-8740 URL: https://issues.apache.org/jira/browse/HBASE-8740 Project: HBase Issue Type: Improvement Reporter: Alex Araujo Priority: Minor Attachments: HBASE-8740.patch This test class creates/drops a table named 'testtable' for 30+ tests. Having tables named after each test method may help diagnose test failures. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8740) Generate unique table names in TestAccessController
[ https://issues.apache.org/jira/browse/HBASE-8740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Araujo updated HBASE-8740: --- Status: Patch Available (was: Open) Added unique table names to TestAccessController via a JUnit Rule Generate unique table names in TestAccessController --- Key: HBASE-8740 URL: https://issues.apache.org/jira/browse/HBASE-8740 Project: HBase Issue Type: Improvement Reporter: Alex Araujo Priority: Minor Attachments: HBASE-8740.patch This test class creates/drops a table named 'testtable' for 30+ tests. Having tables named after each test method may help diagnose test failures. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8740) Generate unique table names in TestAccessController
[ https://issues.apache.org/jira/browse/HBASE-8740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Araujo updated HBASE-8740: --- Attachment: HBASE-8740v2.patch Moved TEST_TABLE Rule up Generate unique table names in TestAccessController --- Key: HBASE-8740 URL: https://issues.apache.org/jira/browse/HBASE-8740 Project: HBase Issue Type: Improvement Reporter: Alex Araujo Priority: Minor Attachments: HBASE-8740.patch, HBASE-8740v2.patch This test class creates/drops a table named 'testtable' for 30+ tests. Having tables named after each test method may help diagnose test failures. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
