[jira] [Commented] (HBASE-12332) [mob] use filelink instad of retry when resolving an hfilelink.
[ https://issues.apache.org/jira/browse/HBASE-12332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14243847#comment-14243847 ] Jingcheng Du commented on HBASE-12332: -- Hi Jon [~jmhsieh]. We've added the test case in the patch of HBASE-12673, and make sure the current implementation could work well with this above case. Please help review and comment. Thanks. The mob ref cell in the HBase only contains the mob file name (not the HFileLink pattern), it's hard to know whether the mob file is a HFileLink in the read path. Instead reading the file via the value of the ref cell in HBase (which is a mob file name, not a HFileLink pattern) through the read paths(two possible locations) is much easier. How do you think about this? Thanks. [mob] use filelink instad of retry when resolving an hfilelink. --- Key: HBASE-12332 URL: https://issues.apache.org/jira/browse/HBASE-12332 Project: HBase Issue Type: Sub-task Components: mob Affects Versions: hbase-11339 Reporter: Jonathan Hsieh Fix For: hbase-11339 Attachments: HBASE-12332-V1.diff in the snapshot code, hmobstore was modified to traverse an hfile link to a mob. Ideally this should use the transparent filelink code to read the data. Also there will likely be some issues with the mob file cache with these links. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12673) Add a UT to read mob file when the mob hfile moving from the mob dir to the archive dir
[ https://issues.apache.org/jira/browse/HBASE-12673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14243851#comment-14243851 ] Jingcheng Du commented on HBASE-12673: -- Hi Jon [~jmhsieh], do you want to look at this patch? Thanks. Add a UT to read mob file when the mob hfile moving from the mob dir to the archive dir --- Key: HBASE-12673 URL: https://issues.apache.org/jira/browse/HBASE-12673 Project: HBase Issue Type: Sub-task Components: regionserver, Scanners Affects Versions: hbase-11339 Reporter: Jiajia Li Assignee: Jiajia Li Fix For: hbase-11339 Attachments: HBASE-12673.patch 1) create a table with mobs, 2) snapshot it, 3) clone/restore it as a a different table 4) have a read workload on the snapshot 5) delete the original table -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12673) Add a UT to read mob file when the mob hfile moving from the mob dir to the archive dir
[ https://issues.apache.org/jira/browse/HBASE-12673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiajia Li updated HBASE-12673: -- Description: add a unit test to scan the cloned table when deleting the original table, and the steps as following: 1) create a table with mobs, 2) snapshot it, 3) clone it as a a different table 4) have a read workload on the snapshot 5) delete the original table was: 1) create a table with mobs, 2) snapshot it, 3) clone/restore it as a a different table 4) have a read workload on the snapshot 5) delete the original table Add a UT to read mob file when the mob hfile moving from the mob dir to the archive dir --- Key: HBASE-12673 URL: https://issues.apache.org/jira/browse/HBASE-12673 Project: HBase Issue Type: Sub-task Components: regionserver, Scanners Affects Versions: hbase-11339 Reporter: Jiajia Li Assignee: Jiajia Li Fix For: hbase-11339 Attachments: HBASE-12673.patch add a unit test to scan the cloned table when deleting the original table, and the steps as following: 1) create a table with mobs, 2) snapshot it, 3) clone it as a a different table 4) have a read workload on the snapshot 5) delete the original table -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12672) Support optionally replicating a table synchronously
[ https://issues.apache.org/jira/browse/HBASE-12672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14243865#comment-14243865 ] Lars Hofhansl commented on HBASE-12672: --- You mean an ordering between tables or events. Hmm, also tricky as they might be hosted by different machines. We should do some brainstorming. Support optionally replicating a table synchronously Key: HBASE-12672 URL: https://issues.apache.org/jira/browse/HBASE-12672 Project: HBase Issue Type: Improvement Reporter: James Taylor Priority: Minor Sometimes a table may contain state in which it's crucial to know that replication occurred before continuing with the update. Though this would mean that you'd block updates to this table if your secondary cluster was unavailable, that might be a tradeoff that a user would be willing to make. An example would be in support of SQL sequences. See this thread (http://s.apache.org/fTP) and PHOENIX-1422 for more discussion and context. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12673) Add a UT to read mob file when the mob hfile moving from the mob dir to the archive dir
[
https://issues.apache.org/jira/browse/HBASE-12673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14243872#comment-14243872
]
Hadoop QA commented on HBASE-12673:
---
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12686779/HBASE-12673.patch
against master branch at commit f72c3ef34d755dc0a1fef6cf744b8add931e166a.
ATTACHMENT ID: 12686779
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 2 new
or modified tests.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 checkstyle{color}. The applied patch does not increase the
total number of checkstyle errors
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/12057//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12057//artifact/patchprocess/newPatchFindbugsWarningshbase-rest.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12057//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12057//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12057//artifact/patchprocess/newPatchFindbugsWarningshbase-annotations.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12057//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12057//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12057//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12057//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12057//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12057//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12057//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/12057//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/12057//console
This message is automatically generated.
Add a UT to read mob file when the mob hfile moving from the mob dir to the
archive dir
---
Key: HBASE-12673
URL: https://issues.apache.org/jira/browse/HBASE-12673
Project: HBase
Issue Type: Sub-task
Components: regionserver, Scanners
Affects Versions: hbase-11339
Reporter: Jiajia Li
Assignee: Jiajia Li
Fix For: hbase-11339
Attachments: HBASE-12673.patch
add a unit test to scan the cloned table when deleting the original table,
and the steps as following:
1) create a table with mobs,
2) snapshot it,
3) clone it as a a different table
4) have a read workload on the snapshot
5) delete the original table
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12672) Support optionally replicating a table synchronously
[ https://issues.apache.org/jira/browse/HBASE-12672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14243882#comment-14243882 ] James Taylor commented on HBASE-12672: -- No, I mean it could still be asynchronously applied on the secondary cluster, but it wouldn't return back to the client until it made it to the point of submitting the change to the secondary cluster in a durable queue (but before the change is actually applied). That way, the secondary cluster would necessarily have to be up (i.e. it wouldn't be a second point of failure). Only the queue would have to be writable to. What's the protocol now? Support optionally replicating a table synchronously Key: HBASE-12672 URL: https://issues.apache.org/jira/browse/HBASE-12672 Project: HBase Issue Type: Improvement Reporter: James Taylor Priority: Minor Sometimes a table may contain state in which it's crucial to know that replication occurred before continuing with the update. Though this would mean that you'd block updates to this table if your secondary cluster was unavailable, that might be a tradeoff that a user would be willing to make. An example would be in support of SQL sequences. See this thread (http://s.apache.org/fTP) and PHOENIX-1422 for more discussion and context. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12645) HBaseTestingUtility is using ${$HOME} for rootDir
[
https://issues.apache.org/jira/browse/HBASE-12645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Varun Saxena updated HBASE-12645:
-
Status: Open (was: Patch Available)
HBaseTestingUtility is using ${$HOME} for rootDir
-
Key: HBASE-12645
URL: https://issues.apache.org/jira/browse/HBASE-12645
Project: HBase
Issue Type: Test
Components: test
Affects Versions: 1.0.0
Reporter: Nick Dimiduk
Assignee: Varun Saxena
Priority: Critical
Fix For: 1.0.0, 2.0.0
Attachments: HBASE-12645.002.patch, HBASE-12645.003.patch,
HBASE-12645.004.patch, HBASE-12645.patch
I noticed this while running tests on branch-1
{noformat}
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.009 sec
FAILURE! - in
org.apache.hadoop.hbase.regionserver.wal.TestReadOldRootAndMetaEdits
org.apache.hadoop.hbase.regionserver.wal.TestReadOldRootAndMetaEdits Time
elapsed: 0.009 sec ERROR!
java.io.FileNotFoundException: Destination exists and is not a directory:
/homes/hortonnd/hbase
at
org.apache.hadoop.fs.RawLocalFileSystem.mkdirs(RawLocalFileSystem.java:423)
at
org.apache.hadoop.fs.ChecksumFileSystem.mkdirs(ChecksumFileSystem.java:588)
at
org.apache.hadoop.hbase.HBaseTestingUtility.createRootDir(HBaseTestingUtility.java:1053)
at
org.apache.hadoop.hbase.regionserver.wal.TestReadOldRootAndMetaEdits.setupBeforeClass(TestReadOldRootAndMetaEdits.java:70)
{noformat}
Either the testing utility has a regression or there's a config regression in
this test.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12678) HBCK should print command line arguments
[ https://issues.apache.org/jira/browse/HBASE-12678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14243887#comment-14243887 ] stack commented on HBASE-12678: --- Go for it. HBCK should print command line arguments Key: HBASE-12678 URL: https://issues.apache.org/jira/browse/HBASE-12678 Project: HBase Issue Type: Improvement Reporter: Enis Soztutar Assignee: Enis Soztutar Fix For: 1.0.0, 2.0.0, 0.98.10 Attachments: hbase-12678_v1.patch While looking at the output from an HBCK run, I've noticed that it does not list the arguments it is running with. We should add it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12668) Adapt PayloadCarryingRpcController so it can also be used in async way
[ https://issues.apache.org/jira/browse/HBASE-12668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14243907#comment-14243907 ] Jurriaan Mous commented on HBASE-12668: --- Now that HadoopQA checks out is there anything that holds back this patch? It is the last piece I need for a replacement async RpcClient implementation. :) Adapt PayloadCarryingRpcController so it can also be used in async way -- Key: HBASE-12668 URL: https://issues.apache.org/jira/browse/HBASE-12668 Project: HBase Issue Type: Improvement Components: Client Reporter: Jurriaan Mous Assignee: Jurriaan Mous Attachments: HBASE-12668-V1.patch, HBASE-12668-V1.patch, HBASE-12668.patch With the changes in HBASE-12597 it is possible to create a new RPC client. But in all places the BlockingRpcChannel is called with a PayloadCarryingRpcController. This controller is not usable in Async context because some methods are not supported at the moment. (See TimeLimitedRpcController for the methods that throw UnsupportedOperationException) This issue is about implementing these methods so PayloadCarryingRpcController can also be used in an async context and work the same in a sync context. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12645) HBaseTestingUtility is using ${$HOME} for rootDir
[
https://issues.apache.org/jira/browse/HBASE-12645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Varun Saxena updated HBASE-12645:
-
Status: Patch Available (was: Open)
HBaseTestingUtility is using ${$HOME} for rootDir
-
Key: HBASE-12645
URL: https://issues.apache.org/jira/browse/HBASE-12645
Project: HBase
Issue Type: Test
Components: test
Affects Versions: 1.0.0
Reporter: Nick Dimiduk
Assignee: Varun Saxena
Priority: Critical
Fix For: 1.0.0, 2.0.0
Attachments: HBASE-12645.002.patch, HBASE-12645.003.patch,
HBASE-12645.004.patch, HBASE-12645.patch
I noticed this while running tests on branch-1
{noformat}
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.009 sec
FAILURE! - in
org.apache.hadoop.hbase.regionserver.wal.TestReadOldRootAndMetaEdits
org.apache.hadoop.hbase.regionserver.wal.TestReadOldRootAndMetaEdits Time
elapsed: 0.009 sec ERROR!
java.io.FileNotFoundException: Destination exists and is not a directory:
/homes/hortonnd/hbase
at
org.apache.hadoop.fs.RawLocalFileSystem.mkdirs(RawLocalFileSystem.java:423)
at
org.apache.hadoop.fs.ChecksumFileSystem.mkdirs(ChecksumFileSystem.java:588)
at
org.apache.hadoop.hbase.HBaseTestingUtility.createRootDir(HBaseTestingUtility.java:1053)
at
org.apache.hadoop.hbase.regionserver.wal.TestReadOldRootAndMetaEdits.setupBeforeClass(TestReadOldRootAndMetaEdits.java:70)
{noformat}
Either the testing utility has a regression or there's a config regression in
this test.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-11290) Unlock RegionStates
[ https://issues.apache.org/jira/browse/HBASE-11290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Virag Kothari updated HBASE-11290: -- Attachment: HBASE-11290-0.98_v2.patch Updated patch for review Unlock RegionStates --- Key: HBASE-11290 URL: https://issues.apache.org/jira/browse/HBASE-11290 Project: HBase Issue Type: Sub-task Reporter: Francis Liu Assignee: Virag Kothari Attachments: HBASE-11290-0.98.patch, HBASE-11290-0.98_v2.patch, HBASE-11290.draft.patch Even though RegionStates is a highly accessed data structure in HMaster. Most of it's methods are synchronized. Which limits concurrency. Even simply making some of the getters non-synchronized by using concurrent data structures has helped with region assignments. We can go as simple as this approach or create locks per region or a bucket lock per region bucket. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-11290) Unlock RegionStates
[ https://issues.apache.org/jira/browse/HBASE-11290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Virag Kothari updated HBASE-11290: -- Fix Version/s: 0.98.10 2.0.0 1.0.0 Unlock RegionStates --- Key: HBASE-11290 URL: https://issues.apache.org/jira/browse/HBASE-11290 Project: HBase Issue Type: Sub-task Reporter: Francis Liu Assignee: Virag Kothari Fix For: 1.0.0, 2.0.0, 0.98.10 Attachments: HBASE-11290-0.98.patch, HBASE-11290-0.98_v2.patch, HBASE-11290.draft.patch Even though RegionStates is a highly accessed data structure in HMaster. Most of it's methods are synchronized. Which limits concurrency. Even simply making some of the getters non-synchronized by using concurrent data structures has helped with region assignments. We can go as simple as this approach or create locks per region or a bucket lock per region bucket. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12650) Move ServerName to hbase-common module
[ https://issues.apache.org/jira/browse/HBASE-12650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14244056#comment-14244056 ] Gaurav Menghani commented on HBASE-12650: - [~tedyu] Awesome! Can you please apply this on the feature branch as well? Move ServerName to hbase-common module -- Key: HBASE-12650 URL: https://issues.apache.org/jira/browse/HBASE-12650 Project: HBase Issue Type: Improvement Affects Versions: 2.0.0 Reporter: Gaurav Menghani Assignee: Ted Yu Priority: Blocker Fix For: 2.0.0 Attachments: 12650-v1.txt, 12650-v2.txt, 12650-v3.txt, 12650-v4.txt The idea is to move ServerName to hbase-common, so that other modules like hbase-consensus which (would) depend on ServerName, but can't depend on hbase-client, since hbase-client would depend on them. Moreover, it looks logical that ServerName not be a part of the client module. It is a shared class between multiple modules, so it should be in hbase-common. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12650) Move ServerName to hbase-common module
[ https://issues.apache.org/jira/browse/HBASE-12650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14244160#comment-14244160 ] Ted Yu commented on HBASE-12650: Am in Beijing now where access to internet is slow. Let me try. Move ServerName to hbase-common module -- Key: HBASE-12650 URL: https://issues.apache.org/jira/browse/HBASE-12650 Project: HBase Issue Type: Improvement Affects Versions: 2.0.0 Reporter: Gaurav Menghani Assignee: Ted Yu Priority: Blocker Fix For: 2.0.0 Attachments: 12650-v1.txt, 12650-v2.txt, 12650-v3.txt, 12650-v4.txt The idea is to move ServerName to hbase-common, so that other modules like hbase-consensus which (would) depend on ServerName, but can't depend on hbase-client, since hbase-client would depend on them. Moreover, it looks logical that ServerName not be a part of the client module. It is a shared class between multiple modules, so it should be in hbase-common. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12668) Adapt PayloadCarryingRpcController so it can also be used in async way
[ https://issues.apache.org/jira/browse/HBASE-12668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-12668: -- Resolution: Fixed Fix Version/s: 2.0.0 1.0.0 Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Pushed to branch-1+ Thanks for the patch [~jurmous] Adapt PayloadCarryingRpcController so it can also be used in async way -- Key: HBASE-12668 URL: https://issues.apache.org/jira/browse/HBASE-12668 Project: HBase Issue Type: Improvement Components: Client Reporter: Jurriaan Mous Assignee: Jurriaan Mous Fix For: 1.0.0, 2.0.0 Attachments: HBASE-12668-V1.patch, HBASE-12668-V1.patch, HBASE-12668.patch With the changes in HBASE-12597 it is possible to create a new RPC client. But in all places the BlockingRpcChannel is called with a PayloadCarryingRpcController. This controller is not usable in Async context because some methods are not supported at the moment. (See TimeLimitedRpcController for the methods that throw UnsupportedOperationException) This issue is about implementing these methods so PayloadCarryingRpcController can also be used in an async context and work the same in a sync context. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-10554) Please delete old releases from mirroring system
[ https://issues.apache.org/jira/browse/HBASE-10554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14244387#comment-14244387 ] Sebb commented on HBASE-10554: -- The page https://dist.apache.org/repos/dist/release/hbase/HEADER.html says: bq. The 0.98.x series is the current stable release, it supercedes 0.94.x and 0.96.x. My reading of this is that users of 0.94.x should upgrade to 0.98.x, i.e. that 0.94.x is no longer in active development. If that is an incorrect reading, please clarify the README. In any case, there should be at most one release of 0.94 and 0.98. Also 0.96 should not be present at all as it is EOL Please delete old releases from mirroring system Key: HBASE-10554 URL: https://issues.apache.org/jira/browse/HBASE-10554 Project: HBase Issue Type: Task Affects Versions: 0.96.0, 0.96.1, 0.94.14, 0.94.15 Reporter: Sebb To reduce the load on the ASF mirrors, projects are required to delete old releases [1] Please can you remove all non-current releases? Thanks! [1] http://www.apache.org/dev/release.html#when-to-archive -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12668) Adapt PayloadCarryingRpcController so it can also be used in async way
[ https://issues.apache.org/jira/browse/HBASE-12668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14244462#comment-14244462 ] Hudson commented on HBASE-12668: FAILURE: Integrated in HBase-TRUNK #5914 (See [https://builds.apache.org/job/HBase-TRUNK/5914/]) HBASE-12668 Adapt PayloadCarryingRpcController so it can also be used in an async way (stack: rev 3275b964c1c1fbb20ffe646b37317496b265660b) * hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/PayloadCarryingRpcController.java * hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/TimeLimitedRpcController.java * hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestClientTimeouts.java * hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/RpcClientImpl.java * hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/AbstractRpcClient.java Adapt PayloadCarryingRpcController so it can also be used in async way -- Key: HBASE-12668 URL: https://issues.apache.org/jira/browse/HBASE-12668 Project: HBase Issue Type: Improvement Components: Client Reporter: Jurriaan Mous Assignee: Jurriaan Mous Fix For: 1.0.0, 2.0.0 Attachments: HBASE-12668-V1.patch, HBASE-12668-V1.patch, HBASE-12668.patch With the changes in HBASE-12597 it is possible to create a new RPC client. But in all places the BlockingRpcChannel is called with a PayloadCarryingRpcController. This controller is not usable in Async context because some methods are not supported at the moment. (See TimeLimitedRpcController for the methods that throw UnsupportedOperationException) This issue is about implementing these methods so PayloadCarryingRpcController can also be used in an async context and work the same in a sync context. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12678) HBCK should print command line arguments
[ https://issues.apache.org/jira/browse/HBASE-12678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14244463#comment-14244463 ] Jonathan Hsieh commented on HBASE-12678: +1 HBCK should print command line arguments Key: HBASE-12678 URL: https://issues.apache.org/jira/browse/HBASE-12678 Project: HBase Issue Type: Improvement Reporter: Enis Soztutar Assignee: Enis Soztutar Fix For: 1.0.0, 2.0.0, 0.98.10 Attachments: hbase-12678_v1.patch While looking at the output from an HBCK run, I've noticed that it does not list the arguments it is running with. We should add it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12677) Update replication docs to clarify terminology
[ https://issues.apache.org/jira/browse/HBASE-12677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14244472#comment-14244472 ] Nick Dimiduk commented on HBASE-12677: -- Gave it a read through, left some comments on RB. Nice improvement [~misty]. Update replication docs to clarify terminology -- Key: HBASE-12677 URL: https://issues.apache.org/jira/browse/HBASE-12677 Project: HBase Issue Type: Bug Components: documentation Reporter: Misty Stanley-Jones Assignee: Misty Stanley-Jones Attachments: HBASE-12677.patch Remove use of master-master and cyclical replication and just talk about topologies -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (HBASE-12672) Support optionally replicating a table synchronously
[ https://issues.apache.org/jira/browse/HBASE-12672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14244524#comment-14244524 ] Lars Hofhansl edited comment on HBASE-12672 at 12/12/14 5:58 PM: - That how it works now: The queue is the WAL. Once the edit is in the WAL it will be made visible to reader and it will eventually be shipped to the secondary. Is what you mean: # put it in the queue (but it's *not* visible to any readers) # only once the edit is applied on the secondary we make it visible in the primary ? was (Author: lhofhansl): That how it works now: The queue is the WAL. Once the edit is in the WAL it will be made visible to reader and it will eventually be shipped to the secondary. Is what you mean is: # put it in the queue (but it's *not* visible to any readers) # only once the edit is applied on the secondary we make it visible in the primary ? Support optionally replicating a table synchronously Key: HBASE-12672 URL: https://issues.apache.org/jira/browse/HBASE-12672 Project: HBase Issue Type: Improvement Reporter: James Taylor Priority: Minor Sometimes a table may contain state in which it's crucial to know that replication occurred before continuing with the update. Though this would mean that you'd block updates to this table if your secondary cluster was unavailable, that might be a tradeoff that a user would be willing to make. An example would be in support of SQL sequences. See this thread (http://s.apache.org/fTP) and PHOENIX-1422 for more discussion and context. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12672) Support optionally replicating a table synchronously
[ https://issues.apache.org/jira/browse/HBASE-12672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14244524#comment-14244524 ] Lars Hofhansl commented on HBASE-12672: --- That how it works now: The queue is the WAL. Once the edit is in the WAL it will be made visible to reader and it will eventually be shipped to the secondary. Is what you mean is: # put it in the queue (but it's *not* visible to any readers) # only once the edit is applied on the secondary we make it visible in the primary ? Support optionally replicating a table synchronously Key: HBASE-12672 URL: https://issues.apache.org/jira/browse/HBASE-12672 Project: HBase Issue Type: Improvement Reporter: James Taylor Priority: Minor Sometimes a table may contain state in which it's crucial to know that replication occurred before continuing with the update. Though this would mean that you'd block updates to this table if your secondary cluster was unavailable, that might be a tradeoff that a user would be willing to make. An example would be in support of SQL sequences. See this thread (http://s.apache.org/fTP) and PHOENIX-1422 for more discussion and context. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12668) Adapt PayloadCarryingRpcController so it can also be used in async way
[ https://issues.apache.org/jira/browse/HBASE-12668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14244531#comment-14244531 ] Hudson commented on HBASE-12668: SUCCESS: Integrated in HBase-1.0 #577 (See [https://builds.apache.org/job/HBase-1.0/577/]) HBASE-12668 Adapt PayloadCarryingRpcController so it can also be used in an async way (stack: rev 54381aab11961ce876b3b56f75172b3f8fddb46d) * hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/RpcClientImpl.java * hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/TimeLimitedRpcController.java * hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestClientTimeouts.java * hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/AbstractRpcClient.java * hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/PayloadCarryingRpcController.java Adapt PayloadCarryingRpcController so it can also be used in async way -- Key: HBASE-12668 URL: https://issues.apache.org/jira/browse/HBASE-12668 Project: HBase Issue Type: Improvement Components: Client Reporter: Jurriaan Mous Assignee: Jurriaan Mous Fix For: 1.0.0, 2.0.0 Attachments: HBASE-12668-V1.patch, HBASE-12668-V1.patch, HBASE-12668.patch With the changes in HBASE-12597 it is possible to create a new RPC client. But in all places the BlockingRpcChannel is called with a PayloadCarryingRpcController. This controller is not usable in Async context because some methods are not supported at the moment. (See TimeLimitedRpcController for the methods that throw UnsupportedOperationException) This issue is about implementing these methods so PayloadCarryingRpcController can also be used in an async context and work the same in a sync context. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12373) Provide a command to list visibility labels
[ https://issues.apache.org/jira/browse/HBASE-12373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jerry He updated HBASE-12373: - Attachment: HBASE-12373-0.98-v6.patch Provide a command to list visibility labels --- Key: HBASE-12373 URL: https://issues.apache.org/jira/browse/HBASE-12373 Project: HBase Issue Type: Improvement Affects Versions: 0.98.7, 0.99.1 Reporter: Jerry He Assignee: Jerry He Priority: Minor Fix For: 1.0.0, 2.0.0 Attachments: HBASE-12373-0.98-v6.patch, HBASE-12373-master-v2.patch, HBASE-12373-master-v3.patch, HBASE-12373-master-v4.patch, HBASE-12373-master-v5.patch, HBASE-12373-master-v6.patch, HBASE-12373-master.patch A command to list visibility labels that are in place would be handy. This is also in line with many of the other hbase list commands. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12373) Provide a command to list visibility labels
[
https://issues.apache.org/jira/browse/HBASE-12373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14244621#comment-14244621
]
Jerry He commented on HBASE-12373:
--
Hi, [~stack]
Attached a 0.98-v6 patch.
Ran UT locally:
{code}
[INFO] Reactor Summary:
[INFO]
[INFO] HBase . SUCCESS [ 2.241 s]
[INFO] HBase - Checkstyle SUCCESS [ 0.527 s]
[INFO] HBase - Annotations ... SUCCESS [ 0.098 s]
[INFO] HBase - Common SUCCESS [ 43.570 s]
[INFO] HBase - Protocol .. SUCCESS [ 0.067 s]
[INFO] HBase - Client SUCCESS [ 46.881 s]
[INFO] HBase - Hadoop Compatibility .. SUCCESS [ 8.226 s]
[INFO] HBase - Hadoop Two Compatibility .. SUCCESS [ 6.066 s]
[INFO] HBase - Prefix Tree ... SUCCESS [ 9.009 s]
[INFO] HBase - Server SUCCESS [45:18 min]
[INFO] HBase - Testing Util .. SUCCESS [ 0.885 s]
[INFO] HBase - Thrift SUCCESS [01:54 min]
[INFO] HBase - Rest .. SUCCESS [05:54 min]
[INFO] HBase - Shell . SUCCESS [ 1.672 s]
[INFO] HBase - Integration Tests . SUCCESS [ 0.507 s]
[INFO] HBase - Examples .. SUCCESS [ 1.927 s]
[INFO] HBase - Assembly .. SUCCESS [ 0.862 s]
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 55:10 min
[INFO] Finished at: 2014-12-11T23:10:20-08:00
[INFO] Final Memory: 49M/242M
{code}
Manual 'list_labels' testing works as expected as well.
Thanks.
Provide a command to list visibility labels
---
Key: HBASE-12373
URL: https://issues.apache.org/jira/browse/HBASE-12373
Project: HBase
Issue Type: Improvement
Affects Versions: 0.98.7, 0.99.1
Reporter: Jerry He
Assignee: Jerry He
Priority: Minor
Fix For: 1.0.0, 2.0.0
Attachments: HBASE-12373-0.98-v6.patch, HBASE-12373-master-v2.patch,
HBASE-12373-master-v3.patch, HBASE-12373-master-v4.patch,
HBASE-12373-master-v5.patch, HBASE-12373-master-v6.patch,
HBASE-12373-master.patch
A command to list visibility labels that are in place would be handy.
This is also in line with many of the other hbase list commands.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12672) Support optionally replicating a table synchronously
[ https://issues.apache.org/jira/browse/HBASE-12672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14244650#comment-14244650 ] James Taylor commented on HBASE-12672: -- That's not what I meant, but it's a good idea. I was looking for a stronger guarantee of replication (only for these special tables) in that once the server returns to the client, the client knows that the secondary cluster will have that change (regardless of what happens to the primary cluster). In other words, if the primary cluster were to get hit by a meteor right after the client received the newly increment value, it'd be guaranteed that the secondary cluster would *eventually* see the value. And by *eventually*, I don't mean when the primary cluster comes back up, but *eventually* as in if the secondary cluster was switched over to we could drain any durable queues containing replicated values before starting to take traffic. It's not as strong a contract as synchronous replication, as we wouldn't need it to be synchronous. We just would need a guarantee that it'll be applied to the secondary cluster before the primary cluster returns back to the client. Support optionally replicating a table synchronously Key: HBASE-12672 URL: https://issues.apache.org/jira/browse/HBASE-12672 Project: HBase Issue Type: Improvement Reporter: James Taylor Priority: Minor Sometimes a table may contain state in which it's crucial to know that replication occurred before continuing with the update. Though this would mean that you'd block updates to this table if your secondary cluster was unavailable, that might be a tradeoff that a user would be willing to make. An example would be in support of SQL sequences. See this thread (http://s.apache.org/fTP) and PHOENIX-1422 for more discussion and context. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12672) Support optionally replicating a table synchronously
[ https://issues.apache.org/jira/browse/HBASE-12672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14244668#comment-14244668 ] Andrew Purtell commented on HBASE-12672: bq. only once the edit is applied on the secondary we make it visible in the primary How does that work when HBase clients, upon returning from a write, do and should expect to read their own writes immediately? Support optionally replicating a table synchronously Key: HBASE-12672 URL: https://issues.apache.org/jira/browse/HBASE-12672 Project: HBase Issue Type: Improvement Reporter: James Taylor Priority: Minor Sometimes a table may contain state in which it's crucial to know that replication occurred before continuing with the update. Though this would mean that you'd block updates to this table if your secondary cluster was unavailable, that might be a tradeoff that a user would be willing to make. An example would be in support of SQL sequences. See this thread (http://s.apache.org/fTP) and PHOENIX-1422 for more discussion and context. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12672) Support optionally replicating a table synchronously
[ https://issues.apache.org/jira/browse/HBASE-12672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14244674#comment-14244674 ] Andrew Purtell commented on HBASE-12672: bq. eventually as in if the secondary cluster was switched over to we could drain any durable queues containing replicated values before starting to take traffic. This is an interesting idea and it would reasonably handle the case where source to sink communication over the WAN is reliable and relatively low latency but maybe the queue of edits for application at the sink site is backed up due to local issues. What it won't handle is (IMO, a quite common case) where the WAN link is not reliable and not low latency. Support optionally replicating a table synchronously Key: HBASE-12672 URL: https://issues.apache.org/jira/browse/HBASE-12672 Project: HBase Issue Type: Improvement Reporter: James Taylor Priority: Minor Sometimes a table may contain state in which it's crucial to know that replication occurred before continuing with the update. Though this would mean that you'd block updates to this table if your secondary cluster was unavailable, that might be a tradeoff that a user would be willing to make. An example would be in support of SQL sequences. See this thread (http://s.apache.org/fTP) and PHOENIX-1422 for more discussion and context. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (HBASE-12672) Support optionally replicating a table synchronously
[ https://issues.apache.org/jira/browse/HBASE-12672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14244674#comment-14244674 ] Andrew Purtell edited comment on HBASE-12672 at 12/12/14 7:43 PM: -- bq. eventually as in if the secondary cluster was switched over to we could drain any durable queues containing replicated values before starting to take traffic. This is an interesting idea and it would reasonably handle the case where source to sink communication over the WAN is reliable and relatively low latency but maybe the queue of edits for application at the sink site is backed up due to local issues. What it won't handle well is (IMO, a quite common case) where the WAN link is not reliable and not low latency, so service we can provide to clients of the special tables - and any activity that depends on the special table update - is bounded by the characteristics of the WAN link not the local in-datacenter networks. was (Author: apurtell): bq. eventually as in if the secondary cluster was switched over to we could drain any durable queues containing replicated values before starting to take traffic. This is an interesting idea and it would reasonably handle the case where source to sink communication over the WAN is reliable and relatively low latency but maybe the queue of edits for application at the sink site is backed up due to local issues. What it won't handle well is (IMO, a quite common case) where the WAN link is not reliable and not low latency, so service we can provide to clients of the special tables - and any activity that depends on the special able update - is bounded by the characteristics of the WAN link not the local in-datacenter networks. Support optionally replicating a table synchronously Key: HBASE-12672 URL: https://issues.apache.org/jira/browse/HBASE-12672 Project: HBase Issue Type: Improvement Reporter: James Taylor Priority: Minor Sometimes a table may contain state in which it's crucial to know that replication occurred before continuing with the update. Though this would mean that you'd block updates to this table if your secondary cluster was unavailable, that might be a tradeoff that a user would be willing to make. An example would be in support of SQL sequences. See this thread (http://s.apache.org/fTP) and PHOENIX-1422 for more discussion and context. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (HBASE-12672) Support optionally replicating a table synchronously
[ https://issues.apache.org/jira/browse/HBASE-12672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14244674#comment-14244674 ] Andrew Purtell edited comment on HBASE-12672 at 12/12/14 7:42 PM: -- bq. eventually as in if the secondary cluster was switched over to we could drain any durable queues containing replicated values before starting to take traffic. This is an interesting idea and it would reasonably handle the case where source to sink communication over the WAN is reliable and relatively low latency but maybe the queue of edits for application at the sink site is backed up due to local issues. What it won't handle well is (IMO, a quite common case) where the WAN link is not reliable and not low latency, so service we can provide to clients of the special tables - and any activity that depends on the special able update - is bounded by the characteristics of the WAN link not the local in-datacenter networks. was (Author: apurtell): bq. eventually as in if the secondary cluster was switched over to we could drain any durable queues containing replicated values before starting to take traffic. This is an interesting idea and it would reasonably handle the case where source to sink communication over the WAN is reliable and relatively low latency but maybe the queue of edits for application at the sink site is backed up due to local issues. What it won't handle is (IMO, a quite common case) where the WAN link is not reliable and not low latency. Support optionally replicating a table synchronously Key: HBASE-12672 URL: https://issues.apache.org/jira/browse/HBASE-12672 Project: HBase Issue Type: Improvement Reporter: James Taylor Priority: Minor Sometimes a table may contain state in which it's crucial to know that replication occurred before continuing with the update. Though this would mean that you'd block updates to this table if your secondary cluster was unavailable, that might be a tradeoff that a user would be willing to make. An example would be in support of SQL sequences. See this thread (http://s.apache.org/fTP) and PHOENIX-1422 for more discussion and context. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12672) Support optionally replicating a table synchronously
[ https://issues.apache.org/jira/browse/HBASE-12672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14244681#comment-14244681 ] James Taylor commented on HBASE-12672: -- bq. any activity that depends on the special table update - is bounded by the characteristics of the WAN link not the local in-datacenter networks. Yes, that'd be the tradeoff, so you'd only want to do it in special circumstances for tables that need this behavior. In particular, it may be ok for sequences because it's incremented once for a configurable batch size, so the cost is amortized over the batch size. Support optionally replicating a table synchronously Key: HBASE-12672 URL: https://issues.apache.org/jira/browse/HBASE-12672 Project: HBase Issue Type: Improvement Reporter: James Taylor Priority: Minor Sometimes a table may contain state in which it's crucial to know that replication occurred before continuing with the update. Though this would mean that you'd block updates to this table if your secondary cluster was unavailable, that might be a tradeoff that a user would be willing to make. An example would be in support of SQL sequences. See this thread (http://s.apache.org/fTP) and PHOENIX-1422 for more discussion and context. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-5162) Basic client pushback mechanism
[ https://issues.apache.org/jira/browse/HBASE-5162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesse Yates updated HBASE-5162: --- Status: Open (was: Patch Available) Basic client pushback mechanism --- Key: HBASE-5162 URL: https://issues.apache.org/jira/browse/HBASE-5162 Project: HBase Issue Type: New Feature Affects Versions: 0.92.0 Reporter: Jean-Daniel Cryans Assignee: Jesse Yates Fix For: 1.0.0 Attachments: hbase-5162-trunk-v0.patch, hbase-5162-trunk-v1.patch, hbase-5162-trunk-v2.patch, hbase-5162-trunk-v3.patch, hbase-5162-trunk-v4.patch, hbase-5162-trunk-v5.patch, hbase-5162-trunk-v6.patch, hbase-5162-trunk-v7.patch, hbase-5162-trunk-v8.patch, java_HBASE-5162.patch The current blocking we do when we are close to some limits (memstores over the multiplier factor, too many store files, global memstore memory) is bad, too coarse and confusing. After hitting HBASE-5161, it really becomes obvious that we need something better. I did a little brainstorm with Stack, we came up quickly with two solutions: - Send some exception to the client, like OverloadedException, that's thrown when some situation happens like getting past the low memory barrier. It would be thrown when the client gets a handler and does some check while putting or deleting. The client would treat this a retryable exception but ideally wouldn't check .META. for a new location. It could be fancy and have multiple levels of pushback, like send the exception to 25% of the clients, and then go up if the situation persists. Should be easy to implement but we'll be using a lot more IO to send the payload over and over again (but at least it wouldn't sit in the RS's memory). - Send a message alongside a successful put or delete to tell the client to slow down a little, this way we don't have to do back and forth with the payload between the client and the server. It's a cleaner (I think) but more involved solution. In every case the RS should do very obvious things to notify the operators of this situation, through logs, web UI, metrics, etc. Other ideas? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-5162) Basic client pushback mechanism
[ https://issues.apache.org/jira/browse/HBASE-5162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesse Yates updated HBASE-5162: --- Status: Patch Available (was: Open) Basic client pushback mechanism --- Key: HBASE-5162 URL: https://issues.apache.org/jira/browse/HBASE-5162 Project: HBase Issue Type: New Feature Affects Versions: 0.92.0 Reporter: Jean-Daniel Cryans Assignee: Jesse Yates Fix For: 1.0.0 Attachments: hbase-5162-trunk-v0.patch, hbase-5162-trunk-v1.patch, hbase-5162-trunk-v10.patch, hbase-5162-trunk-v2.patch, hbase-5162-trunk-v3.patch, hbase-5162-trunk-v4.patch, hbase-5162-trunk-v5.patch, hbase-5162-trunk-v6.patch, hbase-5162-trunk-v7.patch, hbase-5162-trunk-v8.patch, java_HBASE-5162.patch The current blocking we do when we are close to some limits (memstores over the multiplier factor, too many store files, global memstore memory) is bad, too coarse and confusing. After hitting HBASE-5161, it really becomes obvious that we need something better. I did a little brainstorm with Stack, we came up quickly with two solutions: - Send some exception to the client, like OverloadedException, that's thrown when some situation happens like getting past the low memory barrier. It would be thrown when the client gets a handler and does some check while putting or deleting. The client would treat this a retryable exception but ideally wouldn't check .META. for a new location. It could be fancy and have multiple levels of pushback, like send the exception to 25% of the clients, and then go up if the situation persists. Should be easy to implement but we'll be using a lot more IO to send the payload over and over again (but at least it wouldn't sit in the RS's memory). - Send a message alongside a successful put or delete to tell the client to slow down a little, this way we don't have to do back and forth with the payload between the client and the server. It's a cleaner (I think) but more involved solution. In every case the RS should do very obvious things to notify the operators of this situation, through logs, web UI, metrics, etc. Other ideas? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-5162) Basic client pushback mechanism
[ https://issues.apache.org/jira/browse/HBASE-5162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesse Yates updated HBASE-5162: --- Attachment: hbase-5162-trunk-v10.patch Updating patch as per Andy's comments and rebased on current master Basic client pushback mechanism --- Key: HBASE-5162 URL: https://issues.apache.org/jira/browse/HBASE-5162 Project: HBase Issue Type: New Feature Affects Versions: 0.92.0 Reporter: Jean-Daniel Cryans Assignee: Jesse Yates Fix For: 1.0.0 Attachments: hbase-5162-trunk-v0.patch, hbase-5162-trunk-v1.patch, hbase-5162-trunk-v10.patch, hbase-5162-trunk-v2.patch, hbase-5162-trunk-v3.patch, hbase-5162-trunk-v4.patch, hbase-5162-trunk-v5.patch, hbase-5162-trunk-v6.patch, hbase-5162-trunk-v7.patch, hbase-5162-trunk-v8.patch, java_HBASE-5162.patch The current blocking we do when we are close to some limits (memstores over the multiplier factor, too many store files, global memstore memory) is bad, too coarse and confusing. After hitting HBASE-5161, it really becomes obvious that we need something better. I did a little brainstorm with Stack, we came up quickly with two solutions: - Send some exception to the client, like OverloadedException, that's thrown when some situation happens like getting past the low memory barrier. It would be thrown when the client gets a handler and does some check while putting or deleting. The client would treat this a retryable exception but ideally wouldn't check .META. for a new location. It could be fancy and have multiple levels of pushback, like send the exception to 25% of the clients, and then go up if the situation persists. Should be easy to implement but we'll be using a lot more IO to send the payload over and over again (but at least it wouldn't sit in the RS's memory). - Send a message alongside a successful put or delete to tell the client to slow down a little, this way we don't have to do back and forth with the payload between the client and the server. It's a cleaner (I think) but more involved solution. In every case the RS should do very obvious things to notify the operators of this situation, through logs, web UI, metrics, etc. Other ideas? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-5162) Basic client pushback mechanism
[
https://issues.apache.org/jira/browse/HBASE-5162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14244753#comment-14244753
]
Hadoop QA commented on HBASE-5162:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12686931/hbase-5162-trunk-v10.patch
against master branch at commit 3275b964c1c1fbb20ffe646b37317496b265660b.
ATTACHMENT ID: 12686931
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 19 new
or modified tests.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 checkstyle{color}. The applied patch does not increase the
total number of checkstyle errors
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:red}-1 core tests{color}. The patch failed these unit tests:
org.apache.hadoop.hbase.TestInterfaceAudienceAnnotations
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/12058//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12058//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12058//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12058//artifact/patchprocess/newPatchFindbugsWarningshbase-annotations.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12058//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12058//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12058//artifact/patchprocess/newPatchFindbugsWarningshbase-rest.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12058//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12058//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12058//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12058//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12058//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/12058//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/12058//console
This message is automatically generated.
Basic client pushback mechanism
---
Key: HBASE-5162
URL: https://issues.apache.org/jira/browse/HBASE-5162
Project: HBase
Issue Type: New Feature
Affects Versions: 0.92.0
Reporter: Jean-Daniel Cryans
Assignee: Jesse Yates
Fix For: 1.0.0
Attachments: hbase-5162-trunk-v0.patch, hbase-5162-trunk-v1.patch,
hbase-5162-trunk-v10.patch, hbase-5162-trunk-v2.patch,
hbase-5162-trunk-v3.patch, hbase-5162-trunk-v4.patch,
hbase-5162-trunk-v5.patch, hbase-5162-trunk-v6.patch,
hbase-5162-trunk-v7.patch, hbase-5162-trunk-v8.patch, java_HBASE-5162.patch
The current blocking we do when we are close to some limits (memstores over
the multiplier factor, too many store files, global memstore memory) is bad,
too coarse and confusing. After hitting HBASE-5161, it really becomes obvious
that we need something better.
I did a little brainstorm with Stack, we came up quickly with two solutions:
- Send some exception to the client, like OverloadedException, that's thrown
when some situation happens like getting past the low memory barrier. It
would be thrown when the client gets a handler and does some check while
putting or deleting. The client would treat this a retryable
[jira] [Commented] (HBASE-12672) Support optionally replicating a table synchronously
[
https://issues.apache.org/jira/browse/HBASE-12672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14244781#comment-14244781
]
Andrew Purtell commented on HBASE-12672:
Thinking on this a bit more:
{quote}
bq. only once the edit is applied on the secondary we make it visible in the
primary
How does that work when HBase clients, upon returning from a write, do and
should expect to read their own writes immediately?
{quote}
It would be strange, but we could make clients aware of the special aspect of
the table, thus advising them the nature of reality has changed, and let them
(i.e. the HBase client library) build synchronous semantics on top: write
something, then spin until the last written edit becomes visible, then return
control back to the application. We'd need to ensure the sink reliably acks
edits and checks that the source acked the ack, and retransmit acks if not, for
reliable signal delivery for making pending edits visible.
Support optionally replicating a table synchronously
Key: HBASE-12672
URL: https://issues.apache.org/jira/browse/HBASE-12672
Project: HBase
Issue Type: Improvement
Reporter: James Taylor
Priority: Minor
Sometimes a table may contain state in which it's crucial to know that
replication occurred before continuing with the update. Though this would
mean that you'd block updates to this table if your secondary cluster was
unavailable, that might be a tradeoff that a user would be willing to make.
An example would be in support of SQL sequences. See this thread
(http://s.apache.org/fTP) and PHOENIX-1422 for more discussion and context.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-5162) Basic client pushback mechanism
[ https://issues.apache.org/jira/browse/HBASE-5162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-5162: -- Fix Version/s: 2.0.0 bq. TestInterfaceAudienceAnnotations Looks like minor issues with annotation and coverage checking needs attention, then I'm +1 for this change. Basic client pushback mechanism --- Key: HBASE-5162 URL: https://issues.apache.org/jira/browse/HBASE-5162 Project: HBase Issue Type: New Feature Affects Versions: 0.92.0 Reporter: Jean-Daniel Cryans Assignee: Jesse Yates Fix For: 1.0.0, 2.0.0 Attachments: hbase-5162-trunk-v0.patch, hbase-5162-trunk-v1.patch, hbase-5162-trunk-v10.patch, hbase-5162-trunk-v2.patch, hbase-5162-trunk-v3.patch, hbase-5162-trunk-v4.patch, hbase-5162-trunk-v5.patch, hbase-5162-trunk-v6.patch, hbase-5162-trunk-v7.patch, hbase-5162-trunk-v8.patch, java_HBASE-5162.patch The current blocking we do when we are close to some limits (memstores over the multiplier factor, too many store files, global memstore memory) is bad, too coarse and confusing. After hitting HBASE-5161, it really becomes obvious that we need something better. I did a little brainstorm with Stack, we came up quickly with two solutions: - Send some exception to the client, like OverloadedException, that's thrown when some situation happens like getting past the low memory barrier. It would be thrown when the client gets a handler and does some check while putting or deleting. The client would treat this a retryable exception but ideally wouldn't check .META. for a new location. It could be fancy and have multiple levels of pushback, like send the exception to 25% of the clients, and then go up if the situation persists. Should be easy to implement but we'll be using a lot more IO to send the payload over and over again (but at least it wouldn't sit in the RS's memory). - Send a message alongside a successful put or delete to tell the client to slow down a little, this way we don't have to do back and forth with the payload between the client and the server. It's a cleaner (I think) but more involved solution. In every case the RS should do very obvious things to notify the operators of this situation, through logs, web UI, metrics, etc. Other ideas? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-5162) Basic client pushback mechanism
[ https://issues.apache.org/jira/browse/HBASE-5162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14244805#comment-14244805 ] Jesse Yates commented on HBASE-5162: I'm just running it through the test suite locally now to make sure I didn't do any more silly stuff. Basic client pushback mechanism --- Key: HBASE-5162 URL: https://issues.apache.org/jira/browse/HBASE-5162 Project: HBase Issue Type: New Feature Affects Versions: 0.92.0 Reporter: Jean-Daniel Cryans Assignee: Jesse Yates Fix For: 1.0.0, 2.0.0 Attachments: hbase-5162-trunk-v0.patch, hbase-5162-trunk-v1.patch, hbase-5162-trunk-v10.patch, hbase-5162-trunk-v2.patch, hbase-5162-trunk-v3.patch, hbase-5162-trunk-v4.patch, hbase-5162-trunk-v5.patch, hbase-5162-trunk-v6.patch, hbase-5162-trunk-v7.patch, hbase-5162-trunk-v8.patch, java_HBASE-5162.patch The current blocking we do when we are close to some limits (memstores over the multiplier factor, too many store files, global memstore memory) is bad, too coarse and confusing. After hitting HBASE-5161, it really becomes obvious that we need something better. I did a little brainstorm with Stack, we came up quickly with two solutions: - Send some exception to the client, like OverloadedException, that's thrown when some situation happens like getting past the low memory barrier. It would be thrown when the client gets a handler and does some check while putting or deleting. The client would treat this a retryable exception but ideally wouldn't check .META. for a new location. It could be fancy and have multiple levels of pushback, like send the exception to 25% of the clients, and then go up if the situation persists. Should be easy to implement but we'll be using a lot more IO to send the payload over and over again (but at least it wouldn't sit in the RS's memory). - Send a message alongside a successful put or delete to tell the client to slow down a little, this way we don't have to do back and forth with the payload between the client and the server. It's a cleaner (I think) but more involved solution. In every case the RS should do very obvious things to notify the operators of this situation, through logs, web UI, metrics, etc. Other ideas? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12678) HBCK should print command line arguments
[ https://issues.apache.org/jira/browse/HBASE-12678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated HBASE-12678: -- Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Pushed to 0.98+. Thanks for reviews. HBCK should print command line arguments Key: HBASE-12678 URL: https://issues.apache.org/jira/browse/HBASE-12678 Project: HBase Issue Type: Improvement Reporter: Enis Soztutar Assignee: Enis Soztutar Fix For: 1.0.0, 2.0.0, 0.98.10 Attachments: hbase-12678_v1.patch While looking at the output from an HBCK run, I've noticed that it does not list the arguments it is running with. We should add it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12493) User class should provide a way to re-use existing token
[ https://issues.apache.org/jira/browse/HBASE-12493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14244806#comment-14244806 ] Andrew Purtell commented on HBASE-12493: Any concerns about the 0.98 version of the patch [~ghelmling]? User class should provide a way to re-use existing token Key: HBASE-12493 URL: https://issues.apache.org/jira/browse/HBASE-12493 Project: HBase Issue Type: Task Reporter: Brock Noland Assignee: Gary Helmling Fix For: 1.0.0, 2.0.0, 0.98.10 Attachments: HBASE-12493-0.98.patch, HBASE-12493-v2-addendum.patch, HBASE-12493-v2.patch, HBASE-12493.patch In HIVE-8874 we had to re-use HBase classes market private to re-use using tokens. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-10554) Please delete old releases from mirroring system
[ https://issues.apache.org/jira/browse/HBASE-10554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14244823#comment-14244823 ] Andrew Purtell commented on HBASE-10554: bq. My reading of this is that users of 0.94.x should upgrade to 0.98.x, i.e. that 0.94.x is no longer in active development. Agreed, the README should be better worded. Active development != unsupported and must upgrade. A check of our JIRA will demonstrate that we make approximately monthly releases of 0.94 containing bug fixes. bq.Also 0.96 should not be present at all as it is EOL That's fair. [~stack] what do you think? Please delete old releases from mirroring system Key: HBASE-10554 URL: https://issues.apache.org/jira/browse/HBASE-10554 Project: HBase Issue Type: Task Affects Versions: 0.96.0, 0.96.1, 0.94.14, 0.94.15 Reporter: Sebb To reduce the load on the ASF mirrors, projects are required to delete old releases [1] Please can you remove all non-current releases? Thanks! [1] http://www.apache.org/dev/release.html#when-to-archive -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-5162) Basic client pushback mechanism
[ https://issues.apache.org/jira/browse/HBASE-5162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesse Yates updated HBASE-5162: --- Status: Patch Available (was: Open) Basic client pushback mechanism --- Key: HBASE-5162 URL: https://issues.apache.org/jira/browse/HBASE-5162 Project: HBase Issue Type: New Feature Affects Versions: 0.92.0 Reporter: Jean-Daniel Cryans Assignee: Jesse Yates Fix For: 1.0.0, 2.0.0 Attachments: hbase-5162-trunk-v0.patch, hbase-5162-trunk-v1.patch, hbase-5162-trunk-v10.patch, hbase-5162-trunk-v11.patch, hbase-5162-trunk-v2.patch, hbase-5162-trunk-v3.patch, hbase-5162-trunk-v4.patch, hbase-5162-trunk-v5.patch, hbase-5162-trunk-v6.patch, hbase-5162-trunk-v7.patch, hbase-5162-trunk-v8.patch, java_HBASE-5162.patch The current blocking we do when we are close to some limits (memstores over the multiplier factor, too many store files, global memstore memory) is bad, too coarse and confusing. After hitting HBASE-5161, it really becomes obvious that we need something better. I did a little brainstorm with Stack, we came up quickly with two solutions: - Send some exception to the client, like OverloadedException, that's thrown when some situation happens like getting past the low memory barrier. It would be thrown when the client gets a handler and does some check while putting or deleting. The client would treat this a retryable exception but ideally wouldn't check .META. for a new location. It could be fancy and have multiple levels of pushback, like send the exception to 25% of the clients, and then go up if the situation persists. Should be easy to implement but we'll be using a lot more IO to send the payload over and over again (but at least it wouldn't sit in the RS's memory). - Send a message alongside a successful put or delete to tell the client to slow down a little, this way we don't have to do back and forth with the payload between the client and the server. It's a cleaner (I think) but more involved solution. In every case the RS should do very obvious things to notify the operators of this situation, through logs, web UI, metrics, etc. Other ideas? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-5162) Basic client pushback mechanism
[ https://issues.apache.org/jira/browse/HBASE-5162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesse Yates updated HBASE-5162: --- Attachment: hbase-5162-trunk-v11.patch Updating to fix annotations. Basic client pushback mechanism --- Key: HBASE-5162 URL: https://issues.apache.org/jira/browse/HBASE-5162 Project: HBase Issue Type: New Feature Affects Versions: 0.92.0 Reporter: Jean-Daniel Cryans Assignee: Jesse Yates Fix For: 1.0.0, 2.0.0 Attachments: hbase-5162-trunk-v0.patch, hbase-5162-trunk-v1.patch, hbase-5162-trunk-v10.patch, hbase-5162-trunk-v11.patch, hbase-5162-trunk-v2.patch, hbase-5162-trunk-v3.patch, hbase-5162-trunk-v4.patch, hbase-5162-trunk-v5.patch, hbase-5162-trunk-v6.patch, hbase-5162-trunk-v7.patch, hbase-5162-trunk-v8.patch, java_HBASE-5162.patch The current blocking we do when we are close to some limits (memstores over the multiplier factor, too many store files, global memstore memory) is bad, too coarse and confusing. After hitting HBASE-5161, it really becomes obvious that we need something better. I did a little brainstorm with Stack, we came up quickly with two solutions: - Send some exception to the client, like OverloadedException, that's thrown when some situation happens like getting past the low memory barrier. It would be thrown when the client gets a handler and does some check while putting or deleting. The client would treat this a retryable exception but ideally wouldn't check .META. for a new location. It could be fancy and have multiple levels of pushback, like send the exception to 25% of the clients, and then go up if the situation persists. Should be easy to implement but we'll be using a lot more IO to send the payload over and over again (but at least it wouldn't sit in the RS's memory). - Send a message alongside a successful put or delete to tell the client to slow down a little, this way we don't have to do back and forth with the payload between the client and the server. It's a cleaner (I think) but more involved solution. In every case the RS should do very obvious things to notify the operators of this situation, through logs, web UI, metrics, etc. Other ideas? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-5162) Basic client pushback mechanism
[ https://issues.apache.org/jira/browse/HBASE-5162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesse Yates updated HBASE-5162: --- Status: Open (was: Patch Available) Basic client pushback mechanism --- Key: HBASE-5162 URL: https://issues.apache.org/jira/browse/HBASE-5162 Project: HBase Issue Type: New Feature Affects Versions: 0.92.0 Reporter: Jean-Daniel Cryans Assignee: Jesse Yates Fix For: 1.0.0, 2.0.0 Attachments: hbase-5162-trunk-v0.patch, hbase-5162-trunk-v1.patch, hbase-5162-trunk-v10.patch, hbase-5162-trunk-v11.patch, hbase-5162-trunk-v2.patch, hbase-5162-trunk-v3.patch, hbase-5162-trunk-v4.patch, hbase-5162-trunk-v5.patch, hbase-5162-trunk-v6.patch, hbase-5162-trunk-v7.patch, hbase-5162-trunk-v8.patch, java_HBASE-5162.patch The current blocking we do when we are close to some limits (memstores over the multiplier factor, too many store files, global memstore memory) is bad, too coarse and confusing. After hitting HBASE-5161, it really becomes obvious that we need something better. I did a little brainstorm with Stack, we came up quickly with two solutions: - Send some exception to the client, like OverloadedException, that's thrown when some situation happens like getting past the low memory barrier. It would be thrown when the client gets a handler and does some check while putting or deleting. The client would treat this a retryable exception but ideally wouldn't check .META. for a new location. It could be fancy and have multiple levels of pushback, like send the exception to 25% of the clients, and then go up if the situation persists. Should be easy to implement but we'll be using a lot more IO to send the payload over and over again (but at least it wouldn't sit in the RS's memory). - Send a message alongside a successful put or delete to tell the client to slow down a little, this way we don't have to do back and forth with the payload between the client and the server. It's a cleaner (I think) but more involved solution. In every case the RS should do very obvious things to notify the operators of this situation, through logs, web UI, metrics, etc. Other ideas? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-12680) Refactor base ClusterManager in HBase to not have the notion of sending a signal.
Yi Deng created HBASE-12680: --- Summary: Refactor base ClusterManager in HBase to not have the notion of sending a signal. Key: HBASE-12680 URL: https://issues.apache.org/jira/browse/HBASE-12680 Project: HBase Issue Type: Improvement Components: integration tests Affects Versions: 0.98.7, 1.0.0, 2.0.0 Reporter: Yi Deng Assignee: Yi Deng Priority: Minor Fix For: 1.0.0, 2.0.0, 0.98.7 In some situation, we need to run the integration test under some system not using ssh commands. Move the ssh/signal related parts out of ClusterManager and make them as part of the implementation details of HBaseClusterManager. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12680) Refactor base ClusterManager in HBase to not have the notion of sending a signal.
[ https://issues.apache.org/jira/browse/HBASE-12680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yi Deng updated HBASE-12680: Attachment: 2.0-0001-Move-signal-related-code-from-ClusterManager.patch Refactor base ClusterManager in HBase to not have the notion of sending a signal. - Key: HBASE-12680 URL: https://issues.apache.org/jira/browse/HBASE-12680 Project: HBase Issue Type: Improvement Components: integration tests Affects Versions: 1.0.0, 2.0.0, 0.98.7 Reporter: Yi Deng Assignee: Yi Deng Priority: Minor Labels: integration-test Fix For: 1.0.0, 2.0.0, 0.98.7 Attachments: 2.0-0001-Move-signal-related-code-from-ClusterManager.patch In some situation, we need to run the integration test under some system not using ssh commands. Move the ssh/signal related parts out of ClusterManager and make them as part of the implementation details of HBaseClusterManager. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12680) Refactor base ClusterManager in HBase to not have the notion of sending a signal.
[ https://issues.apache.org/jira/browse/HBASE-12680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yi Deng updated HBASE-12680: Status: Patch Available (was: Open) Refactor base ClusterManager in HBase to not have the notion of sending a signal. - Key: HBASE-12680 URL: https://issues.apache.org/jira/browse/HBASE-12680 Project: HBase Issue Type: Improvement Components: integration tests Affects Versions: 0.98.7, 1.0.0, 2.0.0 Reporter: Yi Deng Assignee: Yi Deng Priority: Minor Labels: integration-test Fix For: 1.0.0, 2.0.0, 0.98.7 Attachments: 2.0-0001-Move-signal-related-code-from-ClusterManager.patch In some situation, we need to run the integration test under some system not using ssh commands. Move the ssh/signal related parts out of ClusterManager and make them as part of the implementation details of HBaseClusterManager. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12680) Refactor base ClusterManager in HBase to not have the notion of sending a signal.
[ https://issues.apache.org/jira/browse/HBASE-12680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14244891#comment-14244891 ] Yi Deng commented on HBASE-12680: - Diff: https://reviews.facebook.net/D30201 Refactor base ClusterManager in HBase to not have the notion of sending a signal. - Key: HBASE-12680 URL: https://issues.apache.org/jira/browse/HBASE-12680 Project: HBase Issue Type: Improvement Components: integration tests Affects Versions: 1.0.0, 2.0.0, 0.98.7 Reporter: Yi Deng Assignee: Yi Deng Priority: Minor Labels: integration-test Fix For: 1.0.0, 2.0.0, 0.98.7 Attachments: 2.0-0001-Move-signal-related-code-from-ClusterManager.patch In some situation, we need to run the integration test under some system not using ssh commands. Move the ssh/signal related parts out of ClusterManager and make them as part of the implementation details of HBaseClusterManager. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12680) Refactor base ClusterManager in HBase to not have the notion of sending a signal.
[ https://issues.apache.org/jira/browse/HBASE-12680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yi Deng updated HBASE-12680: Attachment: 2.0-0002-Move-signal-related-code-from-ClusterManager.patch Remove some unnecessary change. Refactor base ClusterManager in HBase to not have the notion of sending a signal. - Key: HBASE-12680 URL: https://issues.apache.org/jira/browse/HBASE-12680 Project: HBase Issue Type: Improvement Components: integration tests Affects Versions: 1.0.0, 2.0.0, 0.98.7 Reporter: Yi Deng Assignee: Yi Deng Priority: Minor Labels: integration-test Fix For: 1.0.0, 2.0.0, 0.98.7 Attachments: 2.0-0001-Move-signal-related-code-from-ClusterManager.patch, 2.0-0002-Move-signal-related-code-from-ClusterManager.patch In some situation, we need to run the integration test under some system not using ssh commands. Move the ssh/signal related parts out of ClusterManager and make them as part of the implementation details of HBaseClusterManager. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12678) HBCK should print command line arguments
[ https://issues.apache.org/jira/browse/HBASE-12678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14244939#comment-14244939 ] Hudson commented on HBASE-12678: SUCCESS: Integrated in HBase-1.0 #578 (See [https://builds.apache.org/job/HBase-1.0/578/]) HBASE-12678 HBCK should print command line arguments (enis: rev 778f443b061e92f2e0c9bade07fa43c3ec05fb0e) * hbase-server/src/main/java/org/apache/hadoop/hbase/util/hbck/OfflineMetaRepair.java * hbase-server/src/main/java/org/apache/hadoop/hbase/util/HBaseFsck.java HBCK should print command line arguments Key: HBASE-12678 URL: https://issues.apache.org/jira/browse/HBASE-12678 Project: HBase Issue Type: Improvement Reporter: Enis Soztutar Assignee: Enis Soztutar Fix For: 1.0.0, 2.0.0, 0.98.10 Attachments: hbase-12678_v1.patch While looking at the output from an HBCK run, I've noticed that it does not list the arguments it is running with. We should add it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12678) HBCK should print command line arguments
[ https://issues.apache.org/jira/browse/HBASE-12678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14244952#comment-14244952 ] Hudson commented on HBASE-12678: FAILURE: Integrated in HBase-0.98 #737 (See [https://builds.apache.org/job/HBase-0.98/737/]) HBASE-12678 HBCK should print command line arguments (enis: rev 71e6b2b22992b2db97171465ad453c3461e1af96) * hbase-server/src/main/java/org/apache/hadoop/hbase/util/HBaseFsck.java * hbase-server/src/main/java/org/apache/hadoop/hbase/util/hbck/OfflineMetaRepair.java HBCK should print command line arguments Key: HBASE-12678 URL: https://issues.apache.org/jira/browse/HBASE-12678 Project: HBase Issue Type: Improvement Reporter: Enis Soztutar Assignee: Enis Soztutar Fix For: 1.0.0, 2.0.0, 0.98.10 Attachments: hbase-12678_v1.patch While looking at the output from an HBCK run, I've noticed that it does not list the arguments it is running with. We should add it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12678) HBCK should print command line arguments
[ https://issues.apache.org/jira/browse/HBASE-12678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14244968#comment-14244968 ] Hudson commented on HBASE-12678: SUCCESS: Integrated in HBase-TRUNK #5915 (See [https://builds.apache.org/job/HBase-TRUNK/5915/]) HBASE-12678 HBCK should print command line arguments (enis: rev a0e473730e2cd819e7442dbd2b332d7833755ba2) * hbase-server/src/main/java/org/apache/hadoop/hbase/util/hbck/OfflineMetaRepair.java * hbase-server/src/main/java/org/apache/hadoop/hbase/util/HBaseFsck.java HBCK should print command line arguments Key: HBASE-12678 URL: https://issues.apache.org/jira/browse/HBASE-12678 Project: HBase Issue Type: Improvement Reporter: Enis Soztutar Assignee: Enis Soztutar Fix For: 1.0.0, 2.0.0, 0.98.10 Attachments: hbase-12678_v1.patch While looking at the output from an HBCK run, I've noticed that it does not list the arguments it is running with. We should add it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-10554) Please delete old releases from mirroring system
[ https://issues.apache.org/jira/browse/HBASE-10554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14244995#comment-14244995 ] stack commented on HBASE-10554: --- I removed 0.96. While in there, removed all but the latest on each major branch (0.94, 0.98, and 0.99). Did edit of HEADER to say 0.94 still seeing bug fix releases every month or so for those not yet able to upgrade. Also pointed at apache archive if folks are looking for old versions. Please delete old releases from mirroring system Key: HBASE-10554 URL: https://issues.apache.org/jira/browse/HBASE-10554 Project: HBase Issue Type: Task Affects Versions: 0.96.0, 0.96.1, 0.94.14, 0.94.15 Reporter: Sebb To reduce the load on the ASF mirrors, projects are required to delete old releases [1] Please can you remove all non-current releases? Thanks! [1] http://www.apache.org/dev/release.html#when-to-archive -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12373) Provide a command to list visibility labels
[ https://issues.apache.org/jira/browse/HBASE-12373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14245001#comment-14245001 ] stack commented on HBASE-12373: --- Applied to 0.98. Thanks for the patch [~jerryhe] Provide a command to list visibility labels --- Key: HBASE-12373 URL: https://issues.apache.org/jira/browse/HBASE-12373 Project: HBase Issue Type: Improvement Affects Versions: 0.98.7, 0.99.1 Reporter: Jerry He Assignee: Jerry He Priority: Minor Fix For: 1.0.0, 2.0.0, 0.98.10 Attachments: HBASE-12373-0.98-v6.patch, HBASE-12373-master-v2.patch, HBASE-12373-master-v3.patch, HBASE-12373-master-v4.patch, HBASE-12373-master-v5.patch, HBASE-12373-master-v6.patch, HBASE-12373-master.patch A command to list visibility labels that are in place would be handy. This is also in line with many of the other hbase list commands. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12373) Provide a command to list visibility labels
[ https://issues.apache.org/jira/browse/HBASE-12373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-12373: -- Fix Version/s: 0.98.10 Provide a command to list visibility labels --- Key: HBASE-12373 URL: https://issues.apache.org/jira/browse/HBASE-12373 Project: HBase Issue Type: Improvement Affects Versions: 0.98.7, 0.99.1 Reporter: Jerry He Assignee: Jerry He Priority: Minor Fix For: 1.0.0, 2.0.0, 0.98.10 Attachments: HBASE-12373-0.98-v6.patch, HBASE-12373-master-v2.patch, HBASE-12373-master-v3.patch, HBASE-12373-master-v4.patch, HBASE-12373-master-v5.patch, HBASE-12373-master-v6.patch, HBASE-12373-master.patch A command to list visibility labels that are in place would be handy. This is also in line with many of the other hbase list commands. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-10554) Please delete old releases from mirroring system
[ https://issues.apache.org/jira/browse/HBASE-10554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14245003#comment-14245003 ] Sebb commented on HBASE-10554: -- Thanks, that looks much better. BTW, just noticed a minor trademarks issue in the README - the first instance of HBase should really be Apache HBase Please delete old releases from mirroring system Key: HBASE-10554 URL: https://issues.apache.org/jira/browse/HBASE-10554 Project: HBase Issue Type: Task Affects Versions: 0.96.0, 0.96.1, 0.94.14, 0.94.15 Reporter: Sebb To reduce the load on the ASF mirrors, projects are required to delete old releases [1] Please can you remove all non-current releases? Thanks! [1] http://www.apache.org/dev/release.html#when-to-archive -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-5162) Basic client pushback mechanism
[
https://issues.apache.org/jira/browse/HBASE-5162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14245006#comment-14245006
]
Hadoop QA commented on HBASE-5162:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12686957/hbase-5162-trunk-v11.patch
against master branch at commit a0e473730e2cd819e7442dbd2b332d7833755ba2.
ATTACHMENT ID: 12686957
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 19 new
or modified tests.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:red}-1 checkstyle{color}. The applied patch generated
2090 checkstyle errors (more than the master's current 2089 errors).
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/12059//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12059//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12059//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12059//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12059//artifact/patchprocess/newPatchFindbugsWarningshbase-annotations.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12059//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12059//artifact/patchprocess/newPatchFindbugsWarningshbase-rest.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12059//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12059//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12059//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12059//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12059//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/12059//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/12059//console
This message is automatically generated.
Basic client pushback mechanism
---
Key: HBASE-5162
URL: https://issues.apache.org/jira/browse/HBASE-5162
Project: HBase
Issue Type: New Feature
Affects Versions: 0.92.0
Reporter: Jean-Daniel Cryans
Assignee: Jesse Yates
Fix For: 1.0.0, 2.0.0
Attachments: hbase-5162-trunk-v0.patch, hbase-5162-trunk-v1.patch,
hbase-5162-trunk-v10.patch, hbase-5162-trunk-v11.patch,
hbase-5162-trunk-v2.patch, hbase-5162-trunk-v3.patch,
hbase-5162-trunk-v4.patch, hbase-5162-trunk-v5.patch,
hbase-5162-trunk-v6.patch, hbase-5162-trunk-v7.patch,
hbase-5162-trunk-v8.patch, java_HBASE-5162.patch
The current blocking we do when we are close to some limits (memstores over
the multiplier factor, too many store files, global memstore memory) is bad,
too coarse and confusing. After hitting HBASE-5161, it really becomes obvious
that we need something better.
I did a little brainstorm with Stack, we came up quickly with two solutions:
- Send some exception to the client, like OverloadedException, that's thrown
when some situation happens like getting past the low memory barrier. It
would be thrown when the client gets a handler and does some check while
putting or deleting. The client would treat this a retryable
[jira] [Commented] (HBASE-12680) Refactor base ClusterManager in HBase to not have the notion of sending a signal.
[
https://issues.apache.org/jira/browse/HBASE-12680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14245011#comment-14245011
]
Hadoop QA commented on HBASE-12680:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12686962/2.0-0001-Move-signal-related-code-from-ClusterManager.patch
against master branch at commit a0e473730e2cd819e7442dbd2b332d7833755ba2.
ATTACHMENT ID: 12686962
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 6 new
or modified tests.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 checkstyle{color}. The applied patch does not increase the
total number of checkstyle errors
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:red}-1 core tests{color}. The patch failed these unit tests:
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/12060//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12060//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12060//artifact/patchprocess/newPatchFindbugsWarningshbase-annotations.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12060//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12060//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12060//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12060//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12060//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12060//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12060//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12060//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12060//artifact/patchprocess/newPatchFindbugsWarningshbase-rest.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/12060//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/12060//console
This message is automatically generated.
Refactor base ClusterManager in HBase to not have the notion of sending a
signal.
-
Key: HBASE-12680
URL: https://issues.apache.org/jira/browse/HBASE-12680
Project: HBase
Issue Type: Improvement
Components: integration tests
Affects Versions: 1.0.0, 2.0.0, 0.98.7
Reporter: Yi Deng
Assignee: Yi Deng
Priority: Minor
Labels: integration-test
Fix For: 1.0.0, 2.0.0, 0.98.7
Attachments:
2.0-0001-Move-signal-related-code-from-ClusterManager.patch,
2.0-0002-Move-signal-related-code-from-ClusterManager.patch
In some situation, we need to run the integration test under some system not
using ssh commands. Move the ssh/signal related parts out of ClusterManager
and make them as part of the implementation details of HBaseClusterManager.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-12680) Refactor base ClusterManager in HBase to not have the notion of sending a signal.
[ https://issues.apache.org/jira/browse/HBASE-12680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yi Deng updated HBASE-12680: Attachment: 2.0-0003-Move-signal-related-code-from-ClusterManager.patch Remove signal in ClusterManager Refactor base ClusterManager in HBase to not have the notion of sending a signal. - Key: HBASE-12680 URL: https://issues.apache.org/jira/browse/HBASE-12680 Project: HBase Issue Type: Improvement Components: integration tests Affects Versions: 1.0.0, 2.0.0, 0.98.7 Reporter: Yi Deng Assignee: Yi Deng Priority: Minor Labels: integration-test Fix For: 1.0.0, 2.0.0, 0.98.7 Attachments: 2.0-0001-Move-signal-related-code-from-ClusterManager.patch, 2.0-0002-Move-signal-related-code-from-ClusterManager.patch, 2.0-0003-Move-signal-related-code-from-ClusterManager.patch In some situation, we need to run the integration test under some system not using ssh commands. Move the ssh/signal related parts out of ClusterManager and make them as part of the implementation details of HBaseClusterManager. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12680) Refactor base ClusterManager in HBase to not have the notion of sending a signal.
[
https://issues.apache.org/jira/browse/HBASE-12680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14245047#comment-14245047
]
Hadoop QA commented on HBASE-12680:
---
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12686965/2.0-0002-Move-signal-related-code-from-ClusterManager.patch
against master branch at commit a0e473730e2cd819e7442dbd2b332d7833755ba2.
ATTACHMENT ID: 12686965
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 6 new
or modified tests.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 checkstyle{color}. The applied patch does not increase the
total number of checkstyle errors
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/12061//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12061//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12061//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12061//artifact/patchprocess/newPatchFindbugsWarningshbase-annotations.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12061//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12061//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12061//artifact/patchprocess/newPatchFindbugsWarningshbase-rest.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12061//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12061//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12061//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12061//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12061//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/12061//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/12061//console
This message is automatically generated.
Refactor base ClusterManager in HBase to not have the notion of sending a
signal.
-
Key: HBASE-12680
URL: https://issues.apache.org/jira/browse/HBASE-12680
Project: HBase
Issue Type: Improvement
Components: integration tests
Affects Versions: 1.0.0, 2.0.0, 0.98.7
Reporter: Yi Deng
Assignee: Yi Deng
Priority: Minor
Labels: integration-test
Fix For: 1.0.0, 2.0.0, 0.98.7
Attachments:
2.0-0001-Move-signal-related-code-from-ClusterManager.patch,
2.0-0002-Move-signal-related-code-from-ClusterManager.patch,
2.0-0003-Move-signal-related-code-from-ClusterManager.patch
In some situation, we need to run the integration test under some system not
using ssh commands. Move the ssh/signal related parts out of ClusterManager
and make them as part of the implementation details of HBaseClusterManager.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12680) Refactor base ClusterManager in HBase to not have the notion of sending a signal.
[ https://issues.apache.org/jira/browse/HBASE-12680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14245054#comment-14245054 ] Elliott Clark commented on HBASE-12680: --- +1 looks good to me. Refactor base ClusterManager in HBase to not have the notion of sending a signal. - Key: HBASE-12680 URL: https://issues.apache.org/jira/browse/HBASE-12680 Project: HBase Issue Type: Improvement Components: integration tests Affects Versions: 1.0.0, 2.0.0, 0.98.7 Reporter: Yi Deng Assignee: Yi Deng Priority: Minor Labels: integration-test Fix For: 1.0.0, 2.0.0, 0.98.7 Attachments: 2.0-0001-Move-signal-related-code-from-ClusterManager.patch, 2.0-0002-Move-signal-related-code-from-ClusterManager.patch, 2.0-0003-Move-signal-related-code-from-ClusterManager.patch In some situation, we need to run the integration test under some system not using ssh commands. Move the ssh/signal related parts out of ClusterManager and make them as part of the implementation details of HBaseClusterManager. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12678) HBCK should print command line arguments
[ https://issues.apache.org/jira/browse/HBASE-12678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14245057#comment-14245057 ] Hudson commented on HBASE-12678: FAILURE: Integrated in HBase-0.98-on-Hadoop-1.1 #704 (See [https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/704/]) HBASE-12678 HBCK should print command line arguments (enis: rev 71e6b2b22992b2db97171465ad453c3461e1af96) * hbase-server/src/main/java/org/apache/hadoop/hbase/util/hbck/OfflineMetaRepair.java * hbase-server/src/main/java/org/apache/hadoop/hbase/util/HBaseFsck.java HBCK should print command line arguments Key: HBASE-12678 URL: https://issues.apache.org/jira/browse/HBASE-12678 Project: HBase Issue Type: Improvement Reporter: Enis Soztutar Assignee: Enis Soztutar Fix For: 1.0.0, 2.0.0, 0.98.10 Attachments: hbase-12678_v1.patch While looking at the output from an HBCK run, I've noticed that it does not list the arguments it is running with. We should add it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12644) Visibility Labels: issue with storing super users in labels table
[ https://issues.apache.org/jira/browse/HBASE-12644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jerry He updated HBASE-12644: - Attachment: HBASE-12644-master-v3.patch Visibility Labels: issue with storing super users in labels table - Key: HBASE-12644 URL: https://issues.apache.org/jira/browse/HBASE-12644 Project: HBase Issue Type: Bug Components: security Affects Versions: 0.98.8, 0.99.2 Reporter: Jerry He Assignee: Jerry He Fix For: 1.0.0, 0.98.10 Attachments: HBASE-12644-master-v2.patch, HBASE-12644-master-v3.patch, HBASE-12644-master.patch Super users have all the permissions for ACL and Visibility labels. They are defined in hbase-site.xml. Currently in VisibilityController, we persist super user with their system permission in hbase:labels. This makes change in super user difficult. There are two issues: In the current DefaultVisibilityLabelServiceImpl.addSystemLabel, we only add super user when we initially create the 'system' label. No additional update after that even if super user changed. See code for details. Additionally, there is no mechanism to remove any super user from the labels table. We probably should not persist super users in the labels table. They are in hbase-site.xml and can just stay in labelsCache and used from labelsCache after retrieval by Visibility Controller. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12644) Visibility Labels: issue with storing super users in labels table
[ https://issues.apache.org/jira/browse/HBASE-12644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14245105#comment-14245105 ] Jerry He commented on HBASE-12644: -- Attached v3 patch. This patch removed the call to this.labelsCache.refreshLabelsCache(serialized) updateZk(). It also puts the creation of the zk nodes in init()--ZKVisibilityLabelWatcher.start(). Separate the creation of the zk nodes event from data update would practically reduce the race condition mentioned in the previous comment. In theory, clients can call addLabel or setAuths from mutiple threads and trigger zk data update events. But it much less likely to cause problem because each involves a sequence of intermediate steps. With the patch. testing with org.apache.hadoop.hbase.security.visibility.* pass everytime I ran. [~anoop.hbase] Comment please. Are you ok with patch? Visibility Labels: issue with storing super users in labels table - Key: HBASE-12644 URL: https://issues.apache.org/jira/browse/HBASE-12644 Project: HBase Issue Type: Bug Components: security Affects Versions: 0.98.8, 0.99.2 Reporter: Jerry He Assignee: Jerry He Fix For: 1.0.0, 0.98.10 Attachments: HBASE-12644-master-v2.patch, HBASE-12644-master-v3.patch, HBASE-12644-master.patch Super users have all the permissions for ACL and Visibility labels. They are defined in hbase-site.xml. Currently in VisibilityController, we persist super user with their system permission in hbase:labels. This makes change in super user difficult. There are two issues: In the current DefaultVisibilityLabelServiceImpl.addSystemLabel, we only add super user when we initially create the 'system' label. No additional update after that even if super user changed. See code for details. Additionally, there is no mechanism to remove any super user from the labels table. We probably should not persist super users in the labels table. They are in hbase-site.xml and can just stay in labelsCache and used from labelsCache after retrieval by Visibility Controller. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12373) Provide a command to list visibility labels
[ https://issues.apache.org/jira/browse/HBASE-12373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14245108#comment-14245108 ] Hudson commented on HBASE-12373: FAILURE: Integrated in HBase-0.98 #738 (See [https://builds.apache.org/job/HBase-0.98/738/]) HBASE-12373 Provide a command to list visibility labels (Jerry He) (stack: rev 3cb0f659048da89bd10f3cf87c09917d32878198) * hbase-protocol/src/main/java/org/apache/hadoop/hbase/protobuf/generated/VisibilityLabelsProtos.java * hbase-server/src/main/java/org/apache/hadoop/hbase/security/visibility/DefaultVisibilityLabelServiceImpl.java * hbase-server/src/main/java/org/apache/hadoop/hbase/security/visibility/VisibilityLabelService.java * hbase-client/src/main/java/org/apache/hadoop/hbase/security/visibility/VisibilityClient.java * hbase-server/src/test/java/org/apache/hadoop/hbase/security/visibility/TestVisibilityLabelsWithDefaultVisLabelService.java * hbase-server/src/main/java/org/apache/hadoop/hbase/security/visibility/VisibilityController.java * hbase-shell/src/main/ruby/shell.rb * hbase-shell/src/main/ruby/shell/commands/list_labels.rb * hbase-server/src/test/java/org/apache/hadoop/hbase/security/visibility/ExpAsStringVisibilityLabelServiceImpl.java * hbase-protocol/src/main/protobuf/VisibilityLabels.proto * hbase-shell/src/main/ruby/hbase/visibility_labels.rb Provide a command to list visibility labels --- Key: HBASE-12373 URL: https://issues.apache.org/jira/browse/HBASE-12373 Project: HBase Issue Type: Improvement Affects Versions: 0.98.7, 0.99.1 Reporter: Jerry He Assignee: Jerry He Priority: Minor Fix For: 1.0.0, 2.0.0, 0.98.10 Attachments: HBASE-12373-0.98-v6.patch, HBASE-12373-master-v2.patch, HBASE-12373-master-v3.patch, HBASE-12373-master-v4.patch, HBASE-12373-master-v5.patch, HBASE-12373-master-v6.patch, HBASE-12373-master.patch A command to list visibility labels that are in place would be handy. This is also in line with many of the other hbase list commands. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12680) Refactor base ClusterManager in HBase to not have the notion of sending a signal.
[
https://issues.apache.org/jira/browse/HBASE-12680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14245118#comment-14245118
]
Hadoop QA commented on HBASE-12680:
---
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12686983/2.0-0003-Move-signal-related-code-from-ClusterManager.patch
against master branch at commit a0e473730e2cd819e7442dbd2b332d7833755ba2.
ATTACHMENT ID: 12686983
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 6 new
or modified tests.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 checkstyle{color}. The applied patch does not increase the
total number of checkstyle errors
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/12062//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12062//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12062//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12062//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12062//artifact/patchprocess/newPatchFindbugsWarningshbase-annotations.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12062//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12062//artifact/patchprocess/newPatchFindbugsWarningshbase-rest.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12062//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12062//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12062//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12062//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12062//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/12062//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/12062//console
This message is automatically generated.
Refactor base ClusterManager in HBase to not have the notion of sending a
signal.
-
Key: HBASE-12680
URL: https://issues.apache.org/jira/browse/HBASE-12680
Project: HBase
Issue Type: Improvement
Components: integration tests
Affects Versions: 1.0.0, 2.0.0, 0.98.7
Reporter: Yi Deng
Assignee: Yi Deng
Priority: Minor
Labels: integration-test
Fix For: 1.0.0, 2.0.0, 0.98.7
Attachments:
2.0-0001-Move-signal-related-code-from-ClusterManager.patch,
2.0-0002-Move-signal-related-code-from-ClusterManager.patch,
2.0-0003-Move-signal-related-code-from-ClusterManager.patch
In some situation, we need to run the integration test under some system not
using ssh commands. Move the ssh/signal related parts out of ClusterManager
and make them as part of the implementation details of HBaseClusterManager.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-10201) Port 'Make flush decisions per column family' to trunk
[ https://issues.apache.org/jira/browse/HBASE-10201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] zhangduo updated HBASE-10201: - Attachment: HBASE-10201_19.patch Addressed the issue on rb Port 'Make flush decisions per column family' to trunk -- Key: HBASE-10201 URL: https://issues.apache.org/jira/browse/HBASE-10201 Project: HBase Issue Type: Improvement Components: wal Reporter: Ted Yu Assignee: zhangduo Fix For: 1.0.0, 2.0.0 Attachments: 3149-trunk-v1.txt, HBASE-10201-0.98.patch, HBASE-10201-0.98_1.patch, HBASE-10201-0.98_2.patch, HBASE-10201-0.99.patch, HBASE-10201.patch, HBASE-10201_1.patch, HBASE-10201_10.patch, HBASE-10201_11.patch, HBASE-10201_12.patch, HBASE-10201_13.patch, HBASE-10201_13.patch, HBASE-10201_14.patch, HBASE-10201_15.patch, HBASE-10201_16.patch, HBASE-10201_17.patch, HBASE-10201_18.patch, HBASE-10201_19.patch, HBASE-10201_2.patch, HBASE-10201_3.patch, HBASE-10201_4.patch, HBASE-10201_5.patch, HBASE-10201_6.patch, HBASE-10201_7.patch, HBASE-10201_8.patch, HBASE-10201_9.patch, compactions.png, count.png, io.png, memstore.png Currently the flush decision is made using the aggregate size of all column families. When large and small column families co-exist, this causes many small flushes of the smaller CF. We need to make per-CF flush decisions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12373) Provide a command to list visibility labels
[ https://issues.apache.org/jira/browse/HBASE-12373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14245143#comment-14245143 ] Hudson commented on HBASE-12373: SUCCESS: Integrated in HBase-0.98-on-Hadoop-1.1 #705 (See [https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/705/]) HBASE-12373 Provide a command to list visibility labels (Jerry He) (stack: rev 3cb0f659048da89bd10f3cf87c09917d32878198) * hbase-client/src/main/java/org/apache/hadoop/hbase/security/visibility/VisibilityClient.java * hbase-server/src/main/java/org/apache/hadoop/hbase/security/visibility/VisibilityLabelService.java * hbase-protocol/src/main/java/org/apache/hadoop/hbase/protobuf/generated/VisibilityLabelsProtos.java * hbase-server/src/test/java/org/apache/hadoop/hbase/security/visibility/TestVisibilityLabelsWithDefaultVisLabelService.java * hbase-shell/src/main/ruby/shell/commands/list_labels.rb * hbase-shell/src/main/ruby/shell.rb * hbase-protocol/src/main/protobuf/VisibilityLabels.proto * hbase-shell/src/main/ruby/hbase/visibility_labels.rb * hbase-server/src/test/java/org/apache/hadoop/hbase/security/visibility/ExpAsStringVisibilityLabelServiceImpl.java * hbase-server/src/main/java/org/apache/hadoop/hbase/security/visibility/VisibilityController.java * hbase-server/src/main/java/org/apache/hadoop/hbase/security/visibility/DefaultVisibilityLabelServiceImpl.java Provide a command to list visibility labels --- Key: HBASE-12373 URL: https://issues.apache.org/jira/browse/HBASE-12373 Project: HBase Issue Type: Improvement Affects Versions: 0.98.7, 0.99.1 Reporter: Jerry He Assignee: Jerry He Priority: Minor Fix For: 1.0.0, 2.0.0, 0.98.10 Attachments: HBASE-12373-0.98-v6.patch, HBASE-12373-master-v2.patch, HBASE-12373-master-v3.patch, HBASE-12373-master-v4.patch, HBASE-12373-master-v5.patch, HBASE-12373-master-v6.patch, HBASE-12373-master.patch A command to list visibility labels that are in place would be handy. This is also in line with many of the other hbase list commands. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-10201) Port 'Make flush decisions per column family' to trunk
[
https://issues.apache.org/jira/browse/HBASE-10201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14245187#comment-14245187
]
Hadoop QA commented on HBASE-10201:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12687009/HBASE-10201_19.patch
against master branch at commit a0e473730e2cd819e7442dbd2b332d7833755ba2.
ATTACHMENT ID: 12687009
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 32 new
or modified tests.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:red}-1 javadoc{color}. The javadoc tool appears to have generated 1
warning messages.
{color:green}+1 checkstyle{color}. The applied patch does not increase the
total number of checkstyle errors
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/12064//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12064//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12064//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12064//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12064//artifact/patchprocess/newPatchFindbugsWarningshbase-annotations.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12064//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12064//artifact/patchprocess/newPatchFindbugsWarningshbase-rest.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12064//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12064//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12064//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12064//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12064//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/12064//artifact/patchprocess/checkstyle-aggregate.html
Javadoc warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12064//artifact/patchprocess/patchJavadocWarnings.txt
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/12064//console
This message is automatically generated.
Port 'Make flush decisions per column family' to trunk
--
Key: HBASE-10201
URL: https://issues.apache.org/jira/browse/HBASE-10201
Project: HBase
Issue Type: Improvement
Components: wal
Reporter: Ted Yu
Assignee: zhangduo
Fix For: 1.0.0, 2.0.0
Attachments: 3149-trunk-v1.txt, HBASE-10201-0.98.patch,
HBASE-10201-0.98_1.patch, HBASE-10201-0.98_2.patch, HBASE-10201-0.99.patch,
HBASE-10201.patch, HBASE-10201_1.patch, HBASE-10201_10.patch,
HBASE-10201_11.patch, HBASE-10201_12.patch, HBASE-10201_13.patch,
HBASE-10201_13.patch, HBASE-10201_14.patch, HBASE-10201_15.patch,
HBASE-10201_16.patch, HBASE-10201_17.patch, HBASE-10201_18.patch,
HBASE-10201_19.patch, HBASE-10201_2.patch, HBASE-10201_3.patch,
HBASE-10201_4.patch, HBASE-10201_5.patch, HBASE-10201_6.patch,
HBASE-10201_7.patch, HBASE-10201_8.patch, HBASE-10201_9.patch,
compactions.png, count.png, io.png, memstore.png
Currently the flush decision is made using the aggregate size of all column
families. When large and small column families co-exist, this causes many
small flushes of the smaller CF. We need to make per-CF flush decisions.
[jira] [Updated] (HBASE-10201) Port 'Make flush decisions per column family' to trunk
[ https://issues.apache.org/jira/browse/HBASE-10201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] zhangduo updated HBASE-10201: - Attachment: (was: HBASE-10201_19.patch) Port 'Make flush decisions per column family' to trunk -- Key: HBASE-10201 URL: https://issues.apache.org/jira/browse/HBASE-10201 Project: HBase Issue Type: Improvement Components: wal Reporter: Ted Yu Assignee: zhangduo Fix For: 1.0.0, 2.0.0 Attachments: 3149-trunk-v1.txt, HBASE-10201-0.98.patch, HBASE-10201-0.98_1.patch, HBASE-10201-0.98_2.patch, HBASE-10201-0.99.patch, HBASE-10201.patch, HBASE-10201_1.patch, HBASE-10201_10.patch, HBASE-10201_11.patch, HBASE-10201_12.patch, HBASE-10201_13.patch, HBASE-10201_13.patch, HBASE-10201_14.patch, HBASE-10201_15.patch, HBASE-10201_16.patch, HBASE-10201_17.patch, HBASE-10201_18.patch, HBASE-10201_2.patch, HBASE-10201_3.patch, HBASE-10201_4.patch, HBASE-10201_5.patch, HBASE-10201_6.patch, HBASE-10201_7.patch, HBASE-10201_8.patch, HBASE-10201_9.patch, compactions.png, count.png, io.png, memstore.png Currently the flush decision is made using the aggregate size of all column families. When large and small column families co-exist, this causes many small flushes of the smaller CF. We need to make per-CF flush decisions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-10201) Port 'Make flush decisions per column family' to trunk
[ https://issues.apache.org/jira/browse/HBASE-10201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] zhangduo updated HBASE-10201: - Attachment: HBASE-10201_19.patch Port 'Make flush decisions per column family' to trunk -- Key: HBASE-10201 URL: https://issues.apache.org/jira/browse/HBASE-10201 Project: HBase Issue Type: Improvement Components: wal Reporter: Ted Yu Assignee: zhangduo Fix For: 1.0.0, 2.0.0 Attachments: 3149-trunk-v1.txt, HBASE-10201-0.98.patch, HBASE-10201-0.98_1.patch, HBASE-10201-0.98_2.patch, HBASE-10201-0.99.patch, HBASE-10201.patch, HBASE-10201_1.patch, HBASE-10201_10.patch, HBASE-10201_11.patch, HBASE-10201_12.patch, HBASE-10201_13.patch, HBASE-10201_13.patch, HBASE-10201_14.patch, HBASE-10201_15.patch, HBASE-10201_16.patch, HBASE-10201_17.patch, HBASE-10201_18.patch, HBASE-10201_19.patch, HBASE-10201_2.patch, HBASE-10201_3.patch, HBASE-10201_4.patch, HBASE-10201_5.patch, HBASE-10201_6.patch, HBASE-10201_7.patch, HBASE-10201_8.patch, HBASE-10201_9.patch, compactions.png, count.png, io.png, memstore.png Currently the flush decision is made using the aggregate size of all column families. When large and small column families co-exist, this causes many small flushes of the smaller CF. We need to make per-CF flush decisions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
