[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] [Updated] (HBASE-12510) Remove the dependency on HRegionInfo from 0.89-fb
[ https://issues.apache.org/jira/browse/HBASE-12510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Menghani updated HBASE-12510: Summary: Remove the dependency on HRegionInfo from 0.89-fb (was: Remove the dependency on 0.89-fb branch for HydraBase) Remove the dependency on HRegionInfo from 0.89-fb - Key: HBASE-12510 URL: https://issues.apache.org/jira/browse/HBASE-12510 Project: HBase Issue Type: Sub-task Components: wal Reporter: Rishit Shroff Assignee: Gaurav Menghani Priority: Minor Attachments: 0001-HBASE-12510-Make-hbase-consensus-independent-of-HReg.patch, 0002-HBASE-12510-Make-hbase-consensus-independent-of-HReg.patch The current RAFT protocol implementation depends on few classes (8) which were present in 0.89-fb branch. The latest HBase branch may have other equivalents of it and we need to cleanup/refactor to code to use them. Filing this JIRA to track this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (HBASE-12510) Remove the dependency on HRegionInfo from 0.89-fb
[ https://issues.apache.org/jira/browse/HBASE-12510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Menghani resolved HBASE-12510. - Resolution: Fixed Remove the dependency on HRegionInfo from 0.89-fb - Key: HBASE-12510 URL: https://issues.apache.org/jira/browse/HBASE-12510 Project: HBase Issue Type: Sub-task Components: wal Reporter: Rishit Shroff Assignee: Gaurav Menghani Priority: Minor Attachments: 0001-HBASE-12510-Make-hbase-consensus-independent-of-HReg.patch, 0002-HBASE-12510-Make-hbase-consensus-independent-of-HReg.patch The current RAFT protocol implementation depends on few classes (8) which were present in 0.89-fb branch. The latest HBase branch may have other equivalents of it and we need to cleanup/refactor to code to use them. Filing this JIRA to track this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12510) Remove the dependency on 0.89-fb branch for HydraBase
[ https://issues.apache.org/jira/browse/HBASE-12510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14237166#comment-14237166 ] Gaurav Menghani commented on HBASE-12510: - Ok, so I am going to rename this JIRA to indicate that this was only for HRegionInfo. We will file separate JIRAs for the remaining work. Remove the dependency on 0.89-fb branch for HydraBase - Key: HBASE-12510 URL: https://issues.apache.org/jira/browse/HBASE-12510 Project: HBase Issue Type: Sub-task Components: wal Reporter: Rishit Shroff Assignee: Gaurav Menghani Priority: Minor Attachments: 0001-HBASE-12510-Make-hbase-consensus-independent-of-HReg.patch, 0002-HBASE-12510-Make-hbase-consensus-independent-of-HReg.patch The current RAFT protocol implementation depends on few classes (8) which were present in 0.89-fb branch. The latest HBase branch may have other equivalents of it and we need to cleanup/refactor to code to use them. Filing this JIRA to track this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12510) Remove the dependency on 0.89-fb branch for HydraBase
[ https://issues.apache.org/jira/browse/HBASE-12510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Menghani updated HBASE-12510: Attachment: 0002-HBASE-12510-Make-hbase-consensus-independent-of-HReg.patch Attached second patch after addressing Ted's comments. Remove the dependency on 0.89-fb branch for HydraBase - Key: HBASE-12510 URL: https://issues.apache.org/jira/browse/HBASE-12510 Project: HBase Issue Type: Sub-task Components: wal Reporter: Rishit Shroff Assignee: Gaurav Menghani Priority: Minor Attachments: 0001-HBASE-12510-Make-hbase-consensus-independent-of-HReg.patch, 0002-HBASE-12510-Make-hbase-consensus-independent-of-HReg.patch The current RAFT protocol implementation depends on few classes (8) which were present in 0.89-fb branch. The latest HBase branch may have other equivalents of it and we need to cleanup/refactor to code to use them. Filing this JIRA to track this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-12650) Move ServerName to hbase-common
Gaurav Menghani created HBASE-12650: --- Summary: Move ServerName to hbase-common Key: HBASE-12650 URL: https://issues.apache.org/jira/browse/HBASE-12650 Project: HBase Issue Type: Improvement Reporter: Gaurav Menghani Assignee: Gaurav Menghani Priority: Blocker -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12650) Move ServerName to hbase-common
[ https://issues.apache.org/jira/browse/HBASE-12650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Menghani updated HBASE-12650: Description: 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. Move ServerName to hbase-common --- Key: HBASE-12650 URL: https://issues.apache.org/jira/browse/HBASE-12650 Project: HBase Issue Type: Improvement Reporter: Gaurav Menghani Assignee: Gaurav Menghani Priority: Blocker 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-12650) Move ServerName to hbase-common
[ https://issues.apache.org/jira/browse/HBASE-12650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Menghani updated HBASE-12650: Affects Version/s: 2.0.0 Move ServerName to hbase-common --- 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: Gaurav Menghani Priority: Blocker 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-12650) Move ServerName to hbase-common
[ https://issues.apache.org/jira/browse/HBASE-12650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Menghani updated HBASE-12650: Fix Version/s: 2.0.0 Move ServerName to hbase-common --- 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: Gaurav Menghani Priority: Blocker Fix For: 2.0.0 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
[ https://issues.apache.org/jira/browse/HBASE-12650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14236821#comment-14236821 ] Gaurav Menghani commented on HBASE-12650: - I will make this change only for trunk and branch-2, and the hydrabase feature branch, if everyone is okay with it. Move ServerName to hbase-common --- 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: Gaurav Menghani Priority: Blocker Fix For: 2.0.0 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
[ https://issues.apache.org/jira/browse/HBASE-12650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14236853#comment-14236853 ] Gaurav Menghani commented on HBASE-12650: - Is there is a branch for 2.0.0 (where hydrabase will land, I presume)? If yes, that's what I meant. Otherwise, I will just land it on trunk and the hydrabase feature branch. Move ServerName to hbase-common --- 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: Gaurav Menghani Priority: Blocker Fix For: 2.0.0 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
[ https://issues.apache.org/jira/browse/HBASE-12650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14236883#comment-14236883 ] Gaurav Menghani commented on HBASE-12650: - [~stack] Yes, you are right. ServerName.parseFrom(byte[]) has at least hbase-client dependencies. So this is a non-trivial-ish refactor. If anyone is taking this up, that would be great. It is not exactly blocking us completely, but we need to get this done as a part of HBASE-12510 some time in the future. Thanks :) Move ServerName to hbase-common --- 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: Gaurav Menghani Priority: Blocker Fix For: 2.0.0 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-12510) Remove the dependency on 0.89-fb branch for HydraBase
[ https://issues.apache.org/jira/browse/HBASE-12510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14236890#comment-14236890 ] Gaurav Menghani commented on HBASE-12510: - Sure, [~stack]! Yes, awaiting either of them to commit this patch. We would be posting patches. This JIRA might have multiple patches, since this has multiple parts. We can discuss the integration of master with QuorumInfo this once we land HBASE-12499 and HBASE-12500. Remove the dependency on 0.89-fb branch for HydraBase - Key: HBASE-12510 URL: https://issues.apache.org/jira/browse/HBASE-12510 Project: HBase Issue Type: Sub-task Components: wal Reporter: Rishit Shroff Assignee: Gaurav Menghani Priority: Minor Attachments: 0001-HBASE-12510-Make-hbase-consensus-independent-of-HReg.patch, 0002-HBASE-12510-Make-hbase-consensus-independent-of-HReg.patch The current RAFT protocol implementation depends on few classes (8) which were present in 0.89-fb branch. The latest HBase branch may have other equivalents of it and we need to cleanup/refactor to code to use them. Filing this JIRA to track this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12510) Remove the dependency on 0.89-fb branch for HydraBase
[ https://issues.apache.org/jira/browse/HBASE-12510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14237033#comment-14237033 ] Gaurav Menghani commented on HBASE-12510: - Awesome! Thanks Elliott! This is a somewhat bigger 'task' with multiple parts, but JIRA doesn't let me create subtask for this, since this is already a subtask of HBASE-12259. Do you suggest we file separate JIRAs, or just keep adding multiple patches here and we can commit with the same JIRA number? Remove the dependency on 0.89-fb branch for HydraBase - Key: HBASE-12510 URL: https://issues.apache.org/jira/browse/HBASE-12510 Project: HBase Issue Type: Sub-task Components: wal Reporter: Rishit Shroff Assignee: Gaurav Menghani Priority: Minor Attachments: 0001-HBASE-12510-Make-hbase-consensus-independent-of-HReg.patch, 0002-HBASE-12510-Make-hbase-consensus-independent-of-HReg.patch The current RAFT protocol implementation depends on few classes (8) which were present in 0.89-fb branch. The latest HBase branch may have other equivalents of it and we need to cleanup/refactor to code to use them. Filing this JIRA to track this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12476) HydraBase Consensus Protocol
[
https://issues.apache.org/jira/browse/HBASE-12476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14236597#comment-14236597
]
Gaurav Menghani commented on HBASE-12476:
-
{quote}
Favored nodes is 'there' in apache hdfs, just not used/tested. The last bit is
still to be hooked up in apache hbase. It has been a TODO for a long while.
{quote}
Cool, we should mark this as a TODO in HydraBase integration as well.
{quote}
What I mean by package-doc is something like this
http://hbase.apache.org/apidocs/org/apache/hadoop/hbase/client/package-summary.html#package_description
(yes, javadoc but at package level giving overview... I think this might be
all that is needed in FSM case since it is 'easy' to read at the method/class
level... its just the high-level story that needs a bit of filling in).
{quote}
Sure.
{quote}
I understand why you've not done splits for messages but you think it will be
possible out in apache hbase atop what you have here? Can be later... just
asking.
{quote}
I think it will be slightly involved because essentially we are stoping the
parent quorum and starting two daughter quorums. This could be done as a
configuration change, and we can do this in the next HydraBase version.
{quote}
On swift, yeah, the annotations are nice but it'd be a headache having thrift
for one communication channel and pb/hbase-rpc for another. We can help w/ the
conversion here since we have a bit of experience, np. Its fine as swift for
now.
{quote}
Yes, I understand the concern. Let's follow up on this later then.
Thanks.
HydraBase Consensus Protocol
Key: HBASE-12476
URL: https://issues.apache.org/jira/browse/HBASE-12476
Project: HBase
Issue Type: Sub-task
Components: Consensus, wal
Reporter: Gaurav Menghani
Assignee: Gaurav Menghani
Fix For: HBASE-12259
Attachments: 0001-HydraBase-consensus-protocol.patch,
0002-HydraBase-consensus-protocol.patch
This is the first patch for the HydraBase consensus protocol implemented
according to the Raft consensus protocol
(https://ramcloud.stanford.edu/raft.pdf), as advertised in (HBASE-12259)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12476) HydraBase Consensus Protocol
[
https://issues.apache.org/jira/browse/HBASE-12476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14236598#comment-14236598
]
Gaurav Menghani commented on HBASE-12476:
-
{quote}
This could be done as a configuration change, and we can do this in the next
HydraBase version.
{quote}
I meant a quorum configuration change, to be clear.
HydraBase Consensus Protocol
Key: HBASE-12476
URL: https://issues.apache.org/jira/browse/HBASE-12476
Project: HBase
Issue Type: Sub-task
Components: Consensus, wal
Reporter: Gaurav Menghani
Assignee: Gaurav Menghani
Fix For: HBASE-12259
Attachments: 0001-HydraBase-consensus-protocol.patch,
0002-HydraBase-consensus-protocol.patch
This is the first patch for the HydraBase consensus protocol implemented
according to the Raft consensus protocol
(https://ramcloud.stanford.edu/raft.pdf), as advertised in (HBASE-12259)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12510) Remove the dependency on 0.89-fb branch for HydraBase
[ https://issues.apache.org/jira/browse/HBASE-12510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14233628#comment-14233628 ] Gaurav Menghani commented on HBASE-12510: - First diff out on Phabricator: https://reviews.facebook.net/D29685 Remove the dependency on 0.89-fb branch for HydraBase - Key: HBASE-12510 URL: https://issues.apache.org/jira/browse/HBASE-12510 Project: HBase Issue Type: Sub-task Components: wal Reporter: Rishit Shroff Assignee: Gaurav Menghani Priority: Minor The current RAFT protocol implementation depends on few classes (8) which were present in 0.89-fb branch. The latest HBase branch may have other equivalents of it and we need to cleanup/refactor to code to use them. Filing this JIRA to track this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12476) HydraBase Consensus Protocol
[
https://issues.apache.org/jira/browse/HBASE-12476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14233680#comment-14233680
]
Gaurav Menghani commented on HBASE-12476:
-
Stack, sorry about this. Didn't see your comment during the holidays.
{quote}
Purge versions from sub-poms if the dependency is common with other modules.
Inherit from parent where you can. I found this in the consensus pom:
version2.15/version
and
version4.1/version
... for what I believe are common dependencies (Its fine to have dependencies
in modules with versions if the dependency only used by the submodule)
{quote}
Sure, will do.
{quote}
In the consensus module, there is an hbase-default.xml also? How does it relate
to the one over in hbase-common?
You can purge hadoop-1 references (unless that is how you refer to your hdfs.)
We don't support it in hbase 1.0.
Others have already remarked on undoing the local copies of HColumnDescriptor,
etc. You had them in here so this module could 'work' without dependency? (Kill
HServerAddress!) Do we need to move stuff around in hbase so you can have
minimal dependencies? All the classes you have copied local here, should we
move them back up and into hbase-common module if not there already?
{quote}
I didn't find hbase-default.xml in the consensus package. Yes, we are cleaning
up all that dependency cruft in HBASE-12510.
{quote}
Run the rat tool on your feature branch. Some of these files are still missing
licenses.
{quote}
Yes, we didn't add licenses to mostly any of the code. Will do this.
{quote}
Nice. You have already ported over ConfigurationObserver. Good.
{quote}
Hehe, I wrote the original ConfigurationObserver in 0.89-fb :D
{quote}
We'll have to redo FetchTask, etc., as protobuf? (the swifty annotations look
very nice)
In FetchTask I see in the run that it has this:
// TODO in part 2: fetch log files from the peer!
Does that mean this facility of raft – catchup I presume – is yet to be
implemented or is it rather that this class gets subclassed later?
If the former, is there more to do to have full implementation?
{quote}
As per Rishit, the FetchTask is for advanced offline log recovery. We aren't
using that part yet. We can add more comments to highlight that.
{quote}
Each regionserver stands up an instance of a QuorumClient per region?
{quote}
Yes, a QuorumClient is used to replicate edits. It is the most clear usage of
the protocol inside RS.
{quote}
A quorum name is different from region name?
{quote}
It need not be. Because the consensus module is intended to be independent of
WAL, and even HBase (which it is not right now, with all the dependencies). So
today the quorum is being done on the WAL, so the quorum name is the same as
region name. Tomorrow, we can do a quorum on something else, in which case
quorum name would be something else. It is just a unique identifier for the
quorum.
{quote}
We'd have to move all of the quorum communication up on to hbase rpc and pb?
What you lot think? Keep swift?
{quote}
I would prefer swift, because we don't have to write IDL specs for the service
and data-structs. That said, if it doesn't play well with the bigger project,
we should discuss this in detail.
{quote}
The FSM stuff could do w/ a bit of package doc on how it works. That said, it
is easy to read. (Maybe we could use these primitives elsewhere in hbase)
{quote}
What do you mean by a package doc? Is it synonymous to Javadocs?
{quote}
Region splits handled?
{quote}
Hydrabase cannot handle region splits as of now.
{quote}
We'd have to figure how to do the RMap stuff in master? And bootstrapping the
cluster?
{quote}
Regarding Bootstrapping, we can share some ideas. There are some basic tools to
bootstrap the RMap. I am moving the RMap part to hbase-server in HBASE-12510,
since this is part of the integration of HBase + Protocol. Regarding the master
part, there is a diff coming out soon. We worked on something known as
HydrabaseMaster which is a thin HMaster which alters the RMap as nodes die and
join the quorum.
{quote}
A regionserver would have to do consensuservice?
{quote}
That's correct. Coming up soon.
{quote}
WHen you say 'favored_nodes' in the rmap, does that imply we need 'favored
nodes' working out in apache hbase or is this just how you describe quorum
members for a region?
{quote}
Actually favored_nodes is used for hinting the DFS where to replicate the
blocks. I believe we don't have that ability in open source HDFS right? In the
next diff, we are just ignoring the favored nodes part.
{quote}
Is the read-side, reading from the quorum, a patch as big as this one (smile)?
Nice one.
{quote}
Not quite, I think the patch sizes would go down exponentially from here. This
probably was the largest chunk of code.
HydraBase Consensus Protocol
Key: HBASE-12476
URL:
[jira] [Work started] (HBASE-12510) Remove the dependency on 0.89-fb branch for HydraBase
[ https://issues.apache.org/jira/browse/HBASE-12510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HBASE-12510 started by Gaurav Menghani. --- Remove the dependency on 0.89-fb branch for HydraBase - Key: HBASE-12510 URL: https://issues.apache.org/jira/browse/HBASE-12510 Project: HBase Issue Type: Sub-task Components: wal Reporter: Rishit Shroff Assignee: Gaurav Menghani Priority: Minor The current RAFT protocol implementation depends on few classes (8) which were present in 0.89-fb branch. The latest HBase branch may have other equivalents of it and we need to cleanup/refactor to code to use them. Filing this JIRA to track this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12483) Refactor WAL recovery to abstract away filesystem
[ https://issues.apache.org/jira/browse/HBASE-12483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14233759#comment-14233759 ] Gaurav Menghani commented on HBASE-12483: - [~busbey] Are there any updates w.r.t this JIRA? Thanks. Refactor WAL recovery to abstract away filesystem - Key: HBASE-12483 URL: https://issues.apache.org/jira/browse/HBASE-12483 Project: HBase Issue Type: Improvement Components: wal Reporter: Sean Busbey Assignee: Sean Busbey HBASE-10378 hides the filesystem from the write-to-the-wal path, but leaves in place the original recovery code. Refactor to remove this leak. * Master should have means to say regions from these servers need recovery * Splitting work should be phrased in terms of region groups and regions from a server instead of files. * RegionServers doing recovery should be able to say please replay the edits from this region * Similarly Replication should be asking for replay of edits as data is aged out of the wal rather than looking specifically at file archiving. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12510) Remove the dependency on 0.89-fb branch for HydraBase
[ https://issues.apache.org/jira/browse/HBASE-12510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Menghani updated HBASE-12510: Attachment: 0001-HBASE-12510-Make-hbase-consensus-independent-of-HReg.patch Everyone seems okay with this first patch. We still need to do more work on this JIRA to completely remove 0.89-fb dependencies. This one would get us unblocked w.r.t work being done in other JIRAs. Remove the dependency on 0.89-fb branch for HydraBase - Key: HBASE-12510 URL: https://issues.apache.org/jira/browse/HBASE-12510 Project: HBase Issue Type: Sub-task Components: wal Reporter: Rishit Shroff Assignee: Gaurav Menghani Priority: Minor Attachments: 0001-HBASE-12510-Make-hbase-consensus-independent-of-HReg.patch The current RAFT protocol implementation depends on few classes (8) which were present in 0.89-fb branch. The latest HBase branch may have other equivalents of it and we need to cleanup/refactor to code to use them. Filing this JIRA to track this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12476) HydraBase Consensus Protocol
[ https://issues.apache.org/jira/browse/HBASE-12476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Menghani updated HBASE-12476: Attachment: 0002-HydraBase-consensus-protocol.patch Final patch of the squashed commits after addressing Ted's comments. HydraBase Consensus Protocol Key: HBASE-12476 URL: https://issues.apache.org/jira/browse/HBASE-12476 Project: HBase Issue Type: Sub-task Components: Consensus, wal Reporter: Gaurav Menghani Assignee: Gaurav Menghani Attachments: 0001-HydraBase-consensus-protocol.patch, 0002-HydraBase-consensus-protocol.patch This is the first patch for the HydraBase consensus protocol implemented according to the Raft consensus protocol (https://ramcloud.stanford.edu/raft.pdf), as advertised in (HBASE-12259) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12522) Backport WAL refactoring to branch-1
[ https://issues.apache.org/jira/browse/HBASE-12522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14221234#comment-14221234 ] Gaurav Menghani commented on HBASE-12522: - Will this be backported to trunk anytime soon? We are woking on getting the Quorum WAL implementation out for review which will require a lot of refactoring in the WAL side of things (basically, making the HRegionServer agnostic of the HLog implementation). So if this is coming any time soon (3-4 days), we can decide accordingly. (cc [~rshroff] [~zelaine] [~eclark]). Backport WAL refactoring to branch-1 Key: HBASE-12522 URL: https://issues.apache.org/jira/browse/HBASE-12522 Project: HBase Issue Type: Task Components: wal Reporter: Sean Busbey Assignee: Sean Busbey Fix For: 0.99.2 backport HBASE-10378 to branch-1. This will let us remove the Deprecated stuff in master, allow some baking time within the 1.x line, and will give us the option of pulling back follow on performance improvements. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12522) Backport WAL refactoring to branch-1
[ https://issues.apache.org/jira/browse/HBASE-12522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14221277#comment-14221277 ] Gaurav Menghani commented on HBASE-12522: - That's perfect. I didn't know 'branch-1' was 1.0. Clarified with [~eclark] offline. Thanks! Backport WAL refactoring to branch-1 Key: HBASE-12522 URL: https://issues.apache.org/jira/browse/HBASE-12522 Project: HBase Issue Type: Task Components: wal Reporter: Sean Busbey Assignee: Sean Busbey Fix For: 0.99.2 backport HBASE-10378 to branch-1. This will let us remove the Deprecated stuff in master, allow some baking time within the 1.x line, and will give us the option of pulling back follow on performance improvements. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12499) Integrate the RAFT Protocol into WAL
[ https://issues.apache.org/jira/browse/HBASE-12499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14221319#comment-14221319 ] Gaurav Menghani commented on HBASE-12499: - The first step towards this would be to make sure we can have different WAL implementations. I started with the work on having an 'HLogManager', but [~busbey] recently landed his refactoring of WAL into master (WALFactory / WALProvider) etc. Will work on top of that. Integrate the RAFT Protocol into WAL Key: HBASE-12499 URL: https://issues.apache.org/jira/browse/HBASE-12499 Project: HBase Issue Type: Sub-task Components: wal Reporter: Rishit Shroff Assignee: Rishit Shroff Add a RAFT protocol based implementation of the WAL in HBase. I will post the design details here soon. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-12476) HydraBase Consensus Protocol
Gaurav Menghani created HBASE-12476: --- Summary: HydraBase Consensus Protocol Key: HBASE-12476 URL: https://issues.apache.org/jira/browse/HBASE-12476 Project: HBase Issue Type: New Feature Components: Consensus, wal Reporter: Gaurav Menghani Assignee: Gaurav Menghani This is the first patch for the HydraBase consensus protocol implemented according to the Raft consensus protocol (https://ramcloud.stanford.edu/raft.pdf). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12476) HydraBase Consensus Protocol
[ https://issues.apache.org/jira/browse/HBASE-12476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Menghani updated HBASE-12476: Attachment: 0001-HydraBase-consensus-protocol.patch This patch applies cleanly on top of commit bbd681541428d3983a9c4e114b1ee479ab22f020 Author: Misty Stanley-Jones mstanleyjo...@cloudera.com Date: Mon Nov 3 14:28:31 2014 +1000 HBASE-12409 Add actual tunable parameters to regions per RS calculations HydraBase Consensus Protocol Key: HBASE-12476 URL: https://issues.apache.org/jira/browse/HBASE-12476 Project: HBase Issue Type: New Feature Components: Consensus, wal Reporter: Gaurav Menghani Assignee: Gaurav Menghani Attachments: 0001-HydraBase-consensus-protocol.patch This is the first patch for the HydraBase consensus protocol implemented according to the Raft consensus protocol (https://ramcloud.stanford.edu/raft.pdf). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12259) Bring quorum based write ahead log into HBase
[ https://issues.apache.org/jira/browse/HBASE-12259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14212634#comment-14212634 ] Gaurav Menghani commented on HBASE-12259: - Created the first patch for the consensus protocol in (HBASE-12476). Bring quorum based write ahead log into HBase - Key: HBASE-12259 URL: https://issues.apache.org/jira/browse/HBASE-12259 Project: HBase Issue Type: Improvement Components: wal Affects Versions: 2.0.0 Reporter: Elliott Clark HydraBase ( https://code.facebook.com/posts/32638043166/hydrabase-the-evolution-of-hbase-facebook/ ) Facebook's implementation of HBase with Raft for consensus will be going open source shortly. We should pull in the parts of that fb-0.89 based implementation, and offer it as a feature in whatever next major release is next up. Right now the Hydrabase code base isn't ready to be released into the wild; it should be ready soon ( for some definition of soon). Since Hydrabase is based upon 0.89 most of the code is not directly applicable. So lots of work will probably need to be done in a feature branch before a merge vote. Is this something that's wanted? Is there anything clean up that needs to be done before the log implementation is able to be replaced like this? What's our story with upgrading to this? Are we ok with requiring down time ? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12476) HydraBase Consensus Protocol
[ https://issues.apache.org/jira/browse/HBASE-12476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Menghani updated HBASE-12476: Description: This is the first patch for the HydraBase consensus protocol implemented according to the Raft consensus protocol (https://ramcloud.stanford.edu/raft.pdf), as advertised in (HBASE-12259) was: This is the first patch for the HydraBase consensus protocol implemented according to the Raft consensus protocol (https://ramcloud.stanford.edu/raft.pdf). HydraBase Consensus Protocol Key: HBASE-12476 URL: https://issues.apache.org/jira/browse/HBASE-12476 Project: HBase Issue Type: New Feature Components: Consensus, wal Reporter: Gaurav Menghani Assignee: Gaurav Menghani Attachments: 0001-HydraBase-consensus-protocol.patch This is the first patch for the HydraBase consensus protocol implemented according to the Raft consensus protocol (https://ramcloud.stanford.edu/raft.pdf), as advertised in (HBASE-12259) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12476) HydraBase Consensus Protocol
[ https://issues.apache.org/jira/browse/HBASE-12476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14212683#comment-14212683 ] Gaurav Menghani commented on HBASE-12476: - Here it is: https://reviews.facebook.net/D28941 HydraBase Consensus Protocol Key: HBASE-12476 URL: https://issues.apache.org/jira/browse/HBASE-12476 Project: HBase Issue Type: New Feature Components: Consensus, wal Reporter: Gaurav Menghani Assignee: Gaurav Menghani Attachments: 0001-HydraBase-consensus-protocol.patch This is the first patch for the HydraBase consensus protocol implemented according to the Raft consensus protocol (https://ramcloud.stanford.edu/raft.pdf), as advertised in (HBASE-12259) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12476) HydraBase Consensus Protocol
[ https://issues.apache.org/jira/browse/HBASE-12476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14212946#comment-14212946 ] Gaurav Menghani commented on HBASE-12476: - [~enis] I assume the client level code you are referring to is, QuorumThriftClient etc. That code is required for the protocol to work, otherwise the Leader node would not receive edits. What is the code duplication you are referring to? HydraBase Consensus Protocol Key: HBASE-12476 URL: https://issues.apache.org/jira/browse/HBASE-12476 Project: HBase Issue Type: New Feature Components: Consensus, wal Reporter: Gaurav Menghani Assignee: Gaurav Menghani Attachments: 0001-HydraBase-consensus-protocol.patch This is the first patch for the HydraBase consensus protocol implemented according to the Raft consensus protocol (https://ramcloud.stanford.edu/raft.pdf), as advertised in (HBASE-12259) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12476) HydraBase Consensus Protocol
[ https://issues.apache.org/jira/browse/HBASE-12476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14213068#comment-14213068 ] Gaurav Menghani commented on HBASE-12476: - Since we moved the code from the HydraBase branch based off 0.89-fb, we had to copy a couple of classes (about 8) to avoid the code from breaking when we copy to trunk. These will be removed in the very new future (after we spend time refactoring), so feel free to ignore them. HydraBase Consensus Protocol Key: HBASE-12476 URL: https://issues.apache.org/jira/browse/HBASE-12476 Project: HBase Issue Type: New Feature Components: Consensus, wal Reporter: Gaurav Menghani Assignee: Gaurav Menghani Attachments: 0001-HydraBase-consensus-protocol.patch This is the first patch for the HydraBase consensus protocol implemented according to the Raft consensus protocol (https://ramcloud.stanford.edu/raft.pdf), as advertised in (HBASE-12259) -- 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=14190804#comment-14190804 ] Gaurav Menghani commented on HBASE-10201: - [~Apache9] Great work porting this patch! Glad to see this getting ported from 0.89-fb to trunk :) Please let me know if you need any help. 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 Priority: Critical Fix For: 2.0.0, 0.99.2 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_2.patch, HBASE-10201_3.patch 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-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=14191015#comment-14191015 ] Gaurav Menghani commented on HBASE-10201: - [~stack] From my design, in this case, 1 and 4 are flushed, but 2 and 3 are retained in the memory. But we can only mark 1 as safe. 2, 3 and 4 will all be replayed if the server crashes. I am not sure, if this has changed in the patch. The Per-CF change is not running in prod right now. I didn't see any big difference deploying it out of the box with the biggest customer where we have a lot of CFs (probably also high-lighted by the small difference in WAF). But I can try running it internally on a shadow cluster again. Let me know if there are some interesting metrics you want me to look at. 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 Priority: Critical Fix For: 2.0.0, 0.99.2 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_2.patch, HBASE-10201_3.patch 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-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=14179387#comment-14179387 ] Gaurav Menghani commented on HBASE-10201: - [~Apache9] Sure. Let me know how can I help. Also, can you show how you calculate WAF? 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 Reporter: Ted Yu Attachments: 3149-trunk-v1.txt, HBASE-10201-0.98.patch, HBASE-10201-0.98_1.patch, HBASE-10201-0.98_2.patch 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-8805) [89-fb] Allow compaction related configurations to be reloaded on-the-fly
[ https://issues.apache.org/jira/browse/HBASE-8805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14155487#comment-14155487 ] Gaurav Menghani commented on HBASE-8805: Okay with me. Go ahead :) [89-fb] Allow compaction related configurations to be reloaded on-the-fly - Key: HBASE-8805 URL: https://issues.apache.org/jira/browse/HBASE-8805 Project: HBase Issue Type: Improvement Affects Versions: 0.89-fb Reporter: Gaurav Menghani Assignee: Gaurav Menghani Fix For: 0.89-fb Attachments: HBASE-8805.patch We already have the infrastructure to reload the configurations on-the-fly for RegionServers (through HBASE-8544 and HBASE-8576). This change allows us to change compaction related configurations by using that infrastructure. This is already done, and should appear in the 89-fb branch soon. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-12105) [0.89-fb] Optimizing exists() to use FirstKeyOnlyFilter for the existence check
Gaurav Menghani created HBASE-12105: --- Summary: [0.89-fb] Optimizing exists() to use FirstKeyOnlyFilter for the existence check Key: HBASE-12105 URL: https://issues.apache.org/jira/browse/HBASE-12105 Project: HBase Issue Type: Improvement Affects Versions: 0.89-fb Reporter: Gaurav Menghani Priority: Minor Fix For: 0.89-fb Exists does a proper Get, it does not need to get all the KVs for a row to do an existence check. The first KV itself is a good enough indicator. This will speed up exists(). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-11592) [0.89-fb] Make the number of SplitLogWorkers online configurable
Gaurav Menghani created HBASE-11592: --- Summary: [0.89-fb] Make the number of SplitLogWorkers online configurable Key: HBASE-11592 URL: https://issues.apache.org/jira/browse/HBASE-11592 Project: HBase Issue Type: Improvement Affects Versions: 0.89-fb Reporter: Gaurav Menghani Assignee: Gaurav Menghani Fix For: 0.89-fb We would like to make the number of SplitLogWorkers online configurable with this JIRA. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-10236) Avoid creating extra Invoker objects when locating a region
[ https://issues.apache.org/jira/browse/HBASE-10236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14056740#comment-14056740 ] Gaurav Menghani commented on HBASE-10236: - Yes, closing this. Avoid creating extra Invoker objects when locating a region --- Key: HBASE-10236 URL: https://issues.apache.org/jira/browse/HBASE-10236 Project: HBase Issue Type: Improvement Components: Client Affects Versions: 0.89-fb Reporter: Gaurav Menghani Assignee: Gaurav Menghani Priority: Trivial Fix For: 0.89-fb While working on the HBase Swift client, I noticed that a lot of connections were being created during locateRegionInMeta, which were never used. A similar case exists in trunk (0.89-fb), but it creates an Invoker object, not an actual client till the call is made on the client. This is a trivial optimization, but can be helpful. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (HBASE-10236) Avoid creating extra Invoker objects when locating a region
[ https://issues.apache.org/jira/browse/HBASE-10236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Menghani resolved HBASE-10236. - Resolution: Fixed Avoid creating extra Invoker objects when locating a region --- Key: HBASE-10236 URL: https://issues.apache.org/jira/browse/HBASE-10236 Project: HBase Issue Type: Improvement Components: Client Affects Versions: 0.89-fb Reporter: Gaurav Menghani Assignee: Gaurav Menghani Priority: Trivial Fix For: 0.89-fb While working on the HBase Swift client, I noticed that a lot of connections were being created during locateRegionInMeta, which were never used. A similar case exists in trunk (0.89-fb), but it creates an Invoker object, not an actual client till the call is made on the client. This is a trivial optimization, but can be helpful. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (HBASE-10698) Update the HBase.thrift file to work with the Thift2 C++ Client
[ https://issues.apache.org/jira/browse/HBASE-10698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Menghani resolved HBASE-10698. - Resolution: Fixed Release Note: This was done. Update the HBase.thrift file to work with the Thift2 C++ Client --- Key: HBASE-10698 URL: https://issues.apache.org/jira/browse/HBASE-10698 Project: HBase Issue Type: Improvement Affects Versions: 0.89-fb Reporter: Gaurav Menghani Assignee: Gaurav Menghani Fix For: 0.89-fb Updating the HBase.thrift file to work with the Thrift2 C++ client. Changes: (1) Renamed put to processPut and get to processGet, since the generated code was confusing the put method with the put object, and so on. (2) Other changes like Histogram bucket annotation are reflected. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (HBASE-10695) Fix test failures related to Swift's merge with HBase
[ https://issues.apache.org/jira/browse/HBASE-10695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Menghani resolved HBASE-10695. - Resolution: Fixed Release Note: This was done. Fix test failures related to Swift's merge with HBase - Key: HBASE-10695 URL: https://issues.apache.org/jira/browse/HBASE-10695 Project: HBase Issue Type: Sub-task Components: IPC/RPC Affects Versions: 0.89-fb Reporter: Gaurav Menghani Assignee: Gaurav Menghani Fix For: 0.89-fb -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (HBASE-9944) Create an HBase C++ Thrift Client
[ https://issues.apache.org/jira/browse/HBASE-9944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Menghani resolved HBASE-9944. Resolution: Fixed Release Note: This is done. Will be released to open source, as and when it is appropriate to do so. Create an HBase C++ Thrift Client - Key: HBASE-9944 URL: https://issues.apache.org/jira/browse/HBASE-9944 Project: HBase Issue Type: Sub-task Affects Versions: 0.89-fb Reporter: Gaurav Menghani Assignee: Gaurav Menghani Fix For: 0.89-fb This is a task to create a native thrift C++ client for HBase when we change the RPC stack to Thrift in HBASE-9930. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (HBASE-11257) [0.89-fb] Remove the timestamp from the annotation of Put
[ https://issues.apache.org/jira/browse/HBASE-11257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Menghani resolved HBASE-11257. - Resolution: Fixed Release Note: This was completed. [0.89-fb] Remove the timestamp from the annotation of Put - Key: HBASE-11257 URL: https://issues.apache.org/jira/browse/HBASE-11257 Project: HBase Issue Type: Improvement Reporter: Gaurav Menghani Assignee: Gaurav Menghani Priority: Minor David and I, recently found out, when discussing the C++ client with @csliu from the Search Team, that we have an extraneous timestamp field in the Put. Actually, that field is used when we create a Put object like: Put p = new Put(row, ts); And then, if you do: p.add(cf, qualifier, value); it would use ts as a timestamp for the KeyValue for the cf, qualifier. If you did not specify it, it will use HConstants.LATEST_TIMESTAMP. One can also do this, where you explicitly state the timestamp to be used: p.add(cf, qualifier, ts, value) In either case, when the add() method is called, the KeyValue is constructed, and it has the proper timestamp. Therefore, once you have created the family map with all these KeyValues, you don't need to send the ts field provided during the construction. All the KVs will have the correct timestamp embedded by the time it will be sent across. This diff removes the timestamp field from the Put object. This will save us some network bandwidth, hopefully :) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (HBASE-6404) Collect p50, p75 and p95 stats
[ https://issues.apache.org/jira/browse/HBASE-6404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Menghani resolved HBASE-6404. Resolution: Fixed Release Note: This was also done last year. Collect p50, p75 and p95 stats -- Key: HBASE-6404 URL: https://issues.apache.org/jira/browse/HBASE-6404 Project: HBase Issue Type: Improvement Components: monitoring Reporter: Arjen Roodselaar Assignee: Gaurav Menghani Stats in current versions of HBase are currently exposed as avg, min and max. This gives a skewed view of performance as the outliers are usually the indicators of problems. Please revise the stats collection framework to use true buckets and expose the p50, p75 and p95 values of these buckets through JMX. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (HBASE-10905) [0.89-fb] Be able to query a region location through the (Thrift)HRegionInterface
[ https://issues.apache.org/jira/browse/HBASE-10905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Menghani resolved HBASE-10905. - Resolution: Fixed Release Note: This was completed. [0.89-fb] Be able to query a region location through the (Thrift)HRegionInterface - Key: HBASE-10905 URL: https://issues.apache.org/jira/browse/HBASE-10905 Project: HBase Issue Type: New Feature Affects Versions: 0.89-fb Reporter: Gaurav Menghani Assignee: Gaurav Menghani Fix For: 0.89-fb In order to write a simplistic non-Java client (PHP in our case), where we don't want to push the region locating code to the client side, we can let the Region Server do it for us. The client can pick up an Region Server in the regionservers tier, and get the location for any row in the table. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (HBASE-10747) Fix the Online Config reload script to work with Swift
[ https://issues.apache.org/jira/browse/HBASE-10747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Menghani resolved HBASE-10747. - Resolution: Fixed Release Note: This was done. Fix the Online Config reload script to work with Swift -- Key: HBASE-10747 URL: https://issues.apache.org/jira/browse/HBASE-10747 Project: HBase Issue Type: Bug Affects Versions: 0.89-fb Reporter: Gaurav Menghani Assignee: Gaurav Menghani Priority: Minor Fix For: 0.89-fb Adela discovered that the Online Config reloading script was broken. I traced the problem to the script using the Hadoop RPC port. Fixing it in this task. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (HBASE-11257) [0.89-fb] Remove the timestamp from the annotation of Put
Gaurav Menghani created HBASE-11257: --- Summary: [0.89-fb] Remove the timestamp from the annotation of Put Key: HBASE-11257 URL: https://issues.apache.org/jira/browse/HBASE-11257 Project: HBase Issue Type: Improvement Reporter: Gaurav Menghani Assignee: Gaurav Menghani Priority: Minor David and I, recently found out, when discussing the C++ client with @csliu from the Search Team, that we have an extraneous timestamp field in the Put. Actually, that field is used when we create a Put object like: Put p = new Put(row, ts); And then, if you do: p.add(cf, qualifier, value); it would use ts as a timestamp for the KeyValue for the cf, qualifier. If you did not specify it, it will use HConstants.LATEST_TIMESTAMP. One can also do this, where you explicitly state the timestamp to be used: p.add(cf, qualifier, ts, value) In either case, when the add() method is called, the KeyValue is constructed, and it has the proper timestamp. Therefore, once you have created the family map with all these KeyValues, you don't need to send the ts field provided during the construction. All the KVs will have the correct timestamp embedded by the time it will be sent across. This diff removes the timestamp field from the Put object. This will save us some network bandwidth, hopefully :) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (HBASE-11138) [0.89-fb] Check for an empty split key before creating a table
Gaurav Menghani created HBASE-11138: --- Summary: [0.89-fb] Check for an empty split key before creating a table Key: HBASE-11138 URL: https://issues.apache.org/jira/browse/HBASE-11138 Project: HBase Issue Type: Bug Affects Versions: 0.89-fb Reporter: Gaurav Menghani Assignee: Gaurav Menghani Priority: Minor Fix For: 0.89-fb HBaseAdmin#checkSplitKeys() doesn't check for empty split keys, which can cause multiple regions with the same start key (i.e., ). This diff fixes that. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (HBASE-10945) [0.89-fb] Retry getting a ZK instance in case of UnknownHostExceptions
Gaurav Menghani created HBASE-10945: --- Summary: [0.89-fb] Retry getting a ZK instance in case of UnknownHostExceptions Key: HBASE-10945 URL: https://issues.apache.org/jira/browse/HBASE-10945 Project: HBase Issue Type: Improvement Affects Versions: 0.89-fb Reporter: Gaurav Menghani Assignee: Gaurav Menghani Fix For: 0.89-fb In case of DNS errors on the machine, locating a ZK quorum might throw UnknownHostException-s, but this might be a temporary issue in most cases. Retrying a couple of times, might resolve this problem. We already retry while getting ZK node data, it only makes sense to do the same while creating the connection. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (HBASE-10905) [0.89-fb] Be able to query a region location through the (Thrift)HRegionInterface
Gaurav Menghani created HBASE-10905: --- Summary: [0.89-fb] Be able to query a region location through the (Thrift)HRegionInterface Key: HBASE-10905 URL: https://issues.apache.org/jira/browse/HBASE-10905 Project: HBase Issue Type: New Feature Affects Versions: 0.89-fb Reporter: Gaurav Menghani Assignee: Gaurav Menghani Fix For: 0.89-fb In order to write a simplistic non-Java client (PHP in our case), where we don't want to push the region locating code to the client side, we can let the Region Server do it for us. The client can pick up an Region Server in the regionservers tier, and get the location for any row in the table. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-9143) make the number of flush thread be updated in an online fashion (hbase.regionserver.flusher.count)
[ https://issues.apache.org/jira/browse/HBASE-9143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Menghani updated HBASE-9143: --- Affects Version/s: 0.89-fb Fix Version/s: 0.89-fb make the number of flush thread be updated in an online fashion (hbase.regionserver.flusher.count) -- Key: HBASE-9143 URL: https://issues.apache.org/jira/browse/HBASE-9143 Project: HBase Issue Type: Improvement Affects Versions: 0.89-fb Reporter: Maksim Khadkevich Priority: Minor Fix For: 0.89-fb In order to achieve online configurable, some of key HBase configuration knobs needed to be updated on the fly. Currently, HBase can be configured to flush multiple Region's memstore in parallel. And this task is to make the number of flush thread be updated in an online fashion (hbase.regionserver.flusher.count). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-9143) make the number of flush thread be updated in an online fashion (hbase.regionserver.flusher.count)
[ https://issues.apache.org/jira/browse/HBASE-9143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13959489#comment-13959489 ] Gaurav Menghani commented on HBASE-9143: This JIRA is for the 0.89-fb branch, sorry it wasn't clear earlier. make the number of flush thread be updated in an online fashion (hbase.regionserver.flusher.count) -- Key: HBASE-9143 URL: https://issues.apache.org/jira/browse/HBASE-9143 Project: HBase Issue Type: Improvement Affects Versions: 0.89-fb Reporter: Maksim Khadkevich Priority: Minor Fix For: 0.89-fb In order to achieve online configurable, some of key HBase configuration knobs needed to be updated on the fly. Currently, HBase can be configured to flush multiple Region's memstore in parallel. And this task is to make the number of flush thread be updated in an online fashion (hbase.regionserver.flusher.count). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (HBASE-10747) Fix the Online Config reload script to work with Swift
Gaurav Menghani created HBASE-10747: --- Summary: Fix the Online Config reload script to work with Swift Key: HBASE-10747 URL: https://issues.apache.org/jira/browse/HBASE-10747 Project: HBase Issue Type: Bug Affects Versions: 0.89-fb Reporter: Gaurav Menghani Assignee: Gaurav Menghani Priority: Minor Fix For: 0.89-fb Adela discovered that the Online Config reloading script was broken. I traced the problem to the script using the Hadoop RPC port. Fixing it in this task. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-10496) Add MurmurHash3 to 0.89-fb
[ https://issues.apache.org/jira/browse/HBASE-10496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Menghani updated HBASE-10496: Description: Use MurmurHash3 in 0.89-fb. Add MurmurHash3 to 0.89-fb -- Key: HBASE-10496 URL: https://issues.apache.org/jira/browse/HBASE-10496 Project: HBase Issue Type: New Feature Affects Versions: 0.89-fb Reporter: Gaurav Menghani Assignee: Gaurav Menghani Fix For: 0.89-fb Use MurmurHash3 in 0.89-fb. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (HBASE-6404) Collect p50, p75 and p95 stats
[ https://issues.apache.org/jira/browse/HBASE-6404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Menghani reassigned HBASE-6404: -- Assignee: Gaurav Menghani (was: Liyin Tang) Collect p50, p75 and p95 stats -- Key: HBASE-6404 URL: https://issues.apache.org/jira/browse/HBASE-6404 Project: HBase Issue Type: Improvement Components: monitoring Reporter: Arjen Roodselaar Assignee: Gaurav Menghani Stats in current versions of HBase are currently exposed as avg, min and max. This gives a skewed view of performance as the outliers are usually the indicators of problems. Please revise the stats collection framework to use true buckets and expose the p50, p75 and p95 values of these buckets through JMX. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (HBASE-10695) Fix test failures related to Swift's merge with HBase
Gaurav Menghani created HBASE-10695: --- Summary: Fix test failures related to Swift's merge with HBase Key: HBASE-10695 URL: https://issues.apache.org/jira/browse/HBASE-10695 Project: HBase Issue Type: Sub-task Affects Versions: 0.89-fb Reporter: Gaurav Menghani Assignee: Gaurav Menghani Fix For: 0.89-fb -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (HBASE-10698) Update the HBase.thrift file to work with the Thift2 C++ Client
Gaurav Menghani created HBASE-10698: --- Summary: Update the HBase.thrift file to work with the Thift2 C++ Client Key: HBASE-10698 URL: https://issues.apache.org/jira/browse/HBASE-10698 Project: HBase Issue Type: Improvement Affects Versions: 0.89-fb Reporter: Gaurav Menghani Assignee: Gaurav Menghani Fix For: 0.89-fb -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-10698) Update the HBase.thrift file to work with the Thift2 C++ Client
[ https://issues.apache.org/jira/browse/HBASE-10698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Menghani updated HBASE-10698: Description: Updating the HBase.thrift file to work with the Thrift2 C++ client. Changes: (1) Renamed put to processPut and get to processGet, since the generated code was confusing the put method with the put object, and so on. (2) Other changes like Histogram bucket annotation are reflected. Update the HBase.thrift file to work with the Thift2 C++ Client --- Key: HBASE-10698 URL: https://issues.apache.org/jira/browse/HBASE-10698 Project: HBase Issue Type: Improvement Affects Versions: 0.89-fb Reporter: Gaurav Menghani Assignee: Gaurav Menghani Fix For: 0.89-fb Updating the HBase.thrift file to work with the Thrift2 C++ client. Changes: (1) Renamed put to processPut and get to processGet, since the generated code was confusing the put method with the put object, and so on. (2) Other changes like Histogram bucket annotation are reflected. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (HBASE-10684) Fixing the TestSimpleOperations' delete tests
Gaurav Menghani created HBASE-10684: --- Summary: Fixing the TestSimpleOperations' delete tests Key: HBASE-10684 URL: https://issues.apache.org/jira/browse/HBASE-10684 Project: HBase Issue Type: Bug Affects Versions: 0.89-fb Reporter: Gaurav Menghani Fix For: 0.89-fb -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (HBASE-10496) Add MurmurHash3 to 0.89-fb
[ https://issues.apache.org/jira/browse/HBASE-10496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Menghani reassigned HBASE-10496: --- Assignee: Gaurav Menghani Add MurmurHash3 to 0.89-fb -- Key: HBASE-10496 URL: https://issues.apache.org/jira/browse/HBASE-10496 Project: HBase Issue Type: New Feature Affects Versions: 0.89-fb Reporter: Gaurav Menghani Assignee: Gaurav Menghani Fix For: 0.89-fb -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (HBASE-10496) Add MurmurHash3 to 0.89-fb
Gaurav Menghani created HBASE-10496: --- Summary: Add MurmurHash3 to 0.89-fb Key: HBASE-10496 URL: https://issues.apache.org/jira/browse/HBASE-10496 Project: HBase Issue Type: New Feature Affects Versions: 0.89-fb Reporter: Gaurav Menghani Fix For: 0.89-fb -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-9631) add murmur3 hash
[ https://issues.apache.org/jira/browse/HBASE-9631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13895821#comment-13895821 ] Gaurav Menghani commented on HBASE-9631: [~apurtell] I don't think that was an *increase*. That seems to be the probability of the BloomFilter being correct when it returns true. The false positive rate should be (1 - 0.99...). I would be surprised if the Bloom Filter is wrong with a probability of 0.99.. or more. Please correct me if I am wrong. add murmur3 hash Key: HBASE-9631 URL: https://issues.apache.org/jira/browse/HBASE-9631 Project: HBase Issue Type: New Feature Components: util Affects Versions: 0.98.0 Reporter: Liang Xie Assignee: Liang Xie Fix For: 0.98.0 Attachments: HBase-9631-v2.txt, HBase-9631.txt MurmurHash3 is the successor to MurmurHash2. It comes in 3 variants - a 32-bit version that targets low latency for hash table use and two 128-bit versions for generating unique identifiers for large blocks of data, one each for x86 and x64 platforms. several open source projects have added murmur3 already, like cassandra, mahout, etc. I just port the murmur3 from MAHOUT-862. due to compatibility, let's keep the default Hash algo(murmur2) without changing. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10236) Avoid creating extra Invoker objects when locating a region
[ https://issues.apache.org/jira/browse/HBASE-10236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Menghani updated HBASE-10236: Description: While working on the HBase Swift client, I noticed that a lot of connections were being created during locateRegionInMeta, which were never used. A similar case exists in trunk (0.89-fb), but it creates an Invoker object, not an actual client till the call is made on the client. This is a trivial optimization, but can be helpful. (was: While working on the HBase Swift client, I noticed that a lot of connections were being created during locateRegionInMeta, which were never used. A similar case exists in trunk (0.89-fb). This is a trivial optimization, but can be helpful.) Avoid creating extra Invoker objects when locating a region --- Key: HBASE-10236 URL: https://issues.apache.org/jira/browse/HBASE-10236 Project: HBase Issue Type: Improvement Components: Client Affects Versions: 0.89-fb Reporter: Gaurav Menghani Assignee: Gaurav Menghani Priority: Trivial Fix For: 0.89-fb While working on the HBase Swift client, I noticed that a lot of connections were being created during locateRegionInMeta, which were never used. A similar case exists in trunk (0.89-fb), but it creates an Invoker object, not an actual client till the call is made on the client. This is a trivial optimization, but can be helpful. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10236) Avoid creating extra Invoker objects when locating a region
[ https://issues.apache.org/jira/browse/HBASE-10236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13857676#comment-13857676 ] Gaurav Menghani commented on HBASE-10236: - Updated the description after Liyin pointed out that only a new Invoker object would be created, this still saves extra object creation on every locateRegionInMeta() call. :) Avoid creating extra Invoker objects when locating a region --- Key: HBASE-10236 URL: https://issues.apache.org/jira/browse/HBASE-10236 Project: HBase Issue Type: Improvement Components: Client Affects Versions: 0.89-fb Reporter: Gaurav Menghani Assignee: Gaurav Menghani Priority: Trivial Fix For: 0.89-fb While working on the HBase Swift client, I noticed that a lot of connections were being created during locateRegionInMeta, which were never used. A similar case exists in trunk (0.89-fb), but it creates an Invoker object, not an actual client till the call is made on the client. This is a trivial optimization, but can be helpful. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10236) Avoid creating extra Invoker objects when locating a region
[ https://issues.apache.org/jira/browse/HBASE-10236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Menghani updated HBASE-10236: Summary: Avoid creating extra Invoker objects when locating a region (was: Avoid creating extra connection when locating a region) Avoid creating extra Invoker objects when locating a region --- Key: HBASE-10236 URL: https://issues.apache.org/jira/browse/HBASE-10236 Project: HBase Issue Type: Improvement Components: Client Affects Versions: 0.89-fb Reporter: Gaurav Menghani Assignee: Gaurav Menghani Priority: Trivial Fix For: 0.89-fb While working on the HBase Swift client, I noticed that a lot of connections were being created during locateRegionInMeta, which were never used. A similar case exists in trunk (0.89-fb). This is a trivial optimization, but can be helpful. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10236) Avoid creating extra connection when locating a region
[ https://issues.apache.org/jira/browse/HBASE-10236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13856652#comment-13856652 ] Gaurav Menghani commented on HBASE-10236: - Lars, I was talking trunk as in, about the 0.89-fb branch, so it is likely that this problem isn't in the HBase trunk. Avoid creating extra connection when locating a region -- Key: HBASE-10236 URL: https://issues.apache.org/jira/browse/HBASE-10236 Project: HBase Issue Type: Improvement Components: Client Affects Versions: 0.89-fb Reporter: Gaurav Menghani Assignee: Gaurav Menghani Priority: Trivial Fix For: 0.89-fb While working on the HBase Swift client, I noticed that a lot of connections were being created during locateRegionInMeta, which were never used. A similar case exists in trunk. This is a trivial optimization, but can be helpful. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10236) Avoid creating extra connection when locating a region
[ https://issues.apache.org/jira/browse/HBASE-10236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Menghani updated HBASE-10236: Description: While working on the HBase Swift client, I noticed that a lot of connections were being created during locateRegionInMeta, which were never used. A similar case exists in trunk (0.89-fb). This is a trivial optimization, but can be helpful. (was: While working on the HBase Swift client, I noticed that a lot of connections were being created during locateRegionInMeta, which were never used. A similar case exists in trunk. This is a trivial optimization, but can be helpful.) Avoid creating extra connection when locating a region -- Key: HBASE-10236 URL: https://issues.apache.org/jira/browse/HBASE-10236 Project: HBase Issue Type: Improvement Components: Client Affects Versions: 0.89-fb Reporter: Gaurav Menghani Assignee: Gaurav Menghani Priority: Trivial Fix For: 0.89-fb While working on the HBase Swift client, I noticed that a lot of connections were being created during locateRegionInMeta, which were never used. A similar case exists in trunk (0.89-fb). This is a trivial optimization, but can be helpful. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (HBASE-10236) Avoid creating extra connection when locating a region
Gaurav Menghani created HBASE-10236: --- Summary: Avoid creating extra connection when locating a region Key: HBASE-10236 URL: https://issues.apache.org/jira/browse/HBASE-10236 Project: HBase Issue Type: Improvement Components: Client Affects Versions: 0.89-fb Reporter: Gaurav Menghani Assignee: Gaurav Menghani Priority: Trivial Fix For: 0.89-fb While working on the HBase Swift client, I noticed that a lot of connections were being created during locateRegionInMeta, which were never used. A similar case exists in trunk. This is a trivial optimization, but can be helpful. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-3149) Make flush decisions per column family
[ https://issues.apache.org/jira/browse/HBASE-3149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13854725#comment-13854725 ] Gaurav Menghani commented on HBASE-3149: [~saint@gmail.com] Yes, we have deployed this, with selective flushing disabled for now, since we didn't see any aggregate benefits yet. The heuristics that I was thinking about were around, which column families to flush when there are no column families above the threshold for flushing families. Eg. if the memstore limit is 128 MB, and the flushing threshold for a CF is 32 MB, there might be a case, where there are like 7-8 CFs, and none of them are above 32 MB. In that case, there are a couple of heuristics you can choose. Like: flush the top N column families, flush only as few column families to free up 1/4 th of the memstore, etc. The main benefit I see is the time spent while compacting the smaller CFs will be much lesser, since the number of files created would be much lesser. This is compensated against bigger column families being flushed earlier than before, and having smaller files than without this change, but with the right heuristics we can find a good balance. Make flush decisions per column family -- Key: HBASE-3149 URL: https://issues.apache.org/jira/browse/HBASE-3149 Project: HBase Issue Type: Improvement Components: regionserver Reporter: Karthik Ranganathan Assignee: Gaurav Menghani Priority: Critical Fix For: 0.89-fb Attachments: 3149-trunk-v1.txt, Per-CF-Memstore-Flush.diff Today, 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.1.4#6159)
[jira] [Commented] (HBASE-3149) Make flush decisions per column family
[ https://issues.apache.org/jira/browse/HBASE-3149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13852025#comment-13852025 ] Gaurav Menghani commented on HBASE-3149: Ted has volunteered to port this to trunk in a separate JIRA. I will be working on different heuristics to see the benefits that we get. Make flush decisions per column family -- Key: HBASE-3149 URL: https://issues.apache.org/jira/browse/HBASE-3149 Project: HBase Issue Type: Improvement Components: regionserver Reporter: Karthik Ranganathan Assignee: Gaurav Menghani Priority: Critical Fix For: 0.89-fb Attachments: 3149-trunk-v1.txt, Per-CF-Memstore-Flush.diff Today, 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.1.4#6159)
[jira] [Created] (HBASE-10177) Fix the netty dependency issue
Gaurav Menghani created HBASE-10177: --- Summary: Fix the netty dependency issue Key: HBASE-10177 URL: https://issues.apache.org/jira/browse/HBASE-10177 Project: HBase Issue Type: Bug Affects Versions: 0.89-fb Reporter: Gaurav Menghani Fix For: 0.89-fb The netty developers changed their group id from org.jboss.netty to io.netty. As a result, the zookeeper and hadoop dependencies pull in the older netty (3.2.2) and swift related dependencies pull in the newer netty (3.7.0). As a result we get ClassNotFoundExceptions, when the older 3.2.2 jar is picked up in place of 3.7.0. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Created] (HBASE-10042) Updating the libthrift, zookeeper and other jars, and adding a maven rule for transitive dependencies.
Gaurav Menghani created HBASE-10042: --- Summary: Updating the libthrift, zookeeper and other jars, and adding a maven rule for transitive dependencies. Key: HBASE-10042 URL: https://issues.apache.org/jira/browse/HBASE-10042 Project: HBase Issue Type: Improvement Affects Versions: 0.89-fb Reporter: Gaurav Menghani Fix For: 0.89-fb Updating the libthrift, zookeeper, mockito, log4j and slf4j jars, since one of the customers is running into problems with the old jars that HBase pulls in. Also added the requireUpperBoundDeps as a rule during the building process. This will force us to specify the correct version of a dependency, if it is required transitively by multiple dependencies. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (HBASE-9972) Make HBase export metrics to JMX by default, instead of to NullContext
Gaurav Menghani created HBASE-9972: -- Summary: Make HBase export metrics to JMX by default, instead of to NullContext Key: HBASE-9972 URL: https://issues.apache.org/jira/browse/HBASE-9972 Project: HBase Issue Type: Improvement Components: metrics Affects Versions: 0.89-fb Reporter: Gaurav Menghani Fix For: 0.89-fb I was debugging something in the swift branch, and found that HBase doesn't export to JMX by default. The JMX server is being spun-up anyways in single node setup, we might as well export the metrics to it. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (HBASE-9972) Make HBase export metrics to JMX by default, instead of to NullContext
[ https://issues.apache.org/jira/browse/HBASE-9972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Menghani reassigned HBASE-9972: -- Assignee: Gaurav Menghani Make HBase export metrics to JMX by default, instead of to NullContext -- Key: HBASE-9972 URL: https://issues.apache.org/jira/browse/HBASE-9972 Project: HBase Issue Type: Improvement Components: metrics Affects Versions: 0.89-fb Reporter: Gaurav Menghani Assignee: Gaurav Menghani Fix For: 0.89-fb I was debugging something in the swift branch, and found that HBase doesn't export to JMX by default. The JMX server is being spun-up anyways in single node setup, we might as well export the metrics to it. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (HBASE-9972) Make HBase export metrics to JMX by default, instead of to NullContext
[ https://issues.apache.org/jira/browse/HBASE-9972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13823039#comment-13823039 ] Gaurav Menghani commented on HBASE-9972: My reasoning was that HBase should be usable out-of-the-box when setting up a single-node instance. Moreover, silencing HBase stats is something which is an exception, rather than the norm. Make HBase export metrics to JMX by default, instead of to NullContext -- Key: HBASE-9972 URL: https://issues.apache.org/jira/browse/HBASE-9972 Project: HBase Issue Type: Improvement Components: metrics Affects Versions: 0.89-fb Reporter: Gaurav Menghani Assignee: Gaurav Menghani Fix For: 0.89-fb I was debugging something in the swift branch, and found that HBase doesn't export to JMX by default. The JMX server is being spun-up anyways in single node setup, we might as well export the metrics to it. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (HBASE-9944) Create a HBase C++ Thrift Client
[ https://issues.apache.org/jira/browse/HBASE-9944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Menghani reassigned HBASE-9944: -- Assignee: Gaurav Menghani Create a HBase C++ Thrift Client Key: HBASE-9944 URL: https://issues.apache.org/jira/browse/HBASE-9944 Project: HBase Issue Type: New Feature Affects Versions: 0.89-fb Reporter: Gaurav Menghani Assignee: Gaurav Menghani Fix For: 0.89-fb -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (HBASE-9944) Create a HBase C++ Thrift Client
Gaurav Menghani created HBASE-9944: -- Summary: Create a HBase C++ Thrift Client Key: HBASE-9944 URL: https://issues.apache.org/jira/browse/HBASE-9944 Project: HBase Issue Type: New Feature Affects Versions: 0.89-fb Reporter: Gaurav Menghani Fix For: 0.89-fb -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (HBASE-9944) Create a HBase C++ Thrift Client
[ https://issues.apache.org/jira/browse/HBASE-9944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Menghani updated HBASE-9944: --- Description: This is a task to create a native thrift C++ client for HBase when we change the RPC stack to Thrift in HBASE-9930. Create a HBase C++ Thrift Client Key: HBASE-9944 URL: https://issues.apache.org/jira/browse/HBASE-9944 Project: HBase Issue Type: New Feature Affects Versions: 0.89-fb Reporter: Gaurav Menghani Assignee: Gaurav Menghani Fix For: 0.89-fb This is a task to create a native thrift C++ client for HBase when we change the RPC stack to Thrift in HBASE-9930. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (HBASE-9930) Change the RPC stack to Thrift
[ https://issues.apache.org/jira/browse/HBASE-9930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13819323#comment-13819323 ] Gaurav Menghani commented on HBASE-9930: Created the C++ client JIRA - HBASE-9944. Change the RPC stack to Thrift -- Key: HBASE-9930 URL: https://issues.apache.org/jira/browse/HBASE-9930 Project: HBase Issue Type: Umbrella Components: IPC/RPC Affects Versions: 0.89-fb Reporter: Manukranth Kolloju Assignee: Manukranth Kolloju Fix For: 0.89-fb This umbrella task is to talk about the effort to change the RPC stack in 0.89-fb to Thrift instead of using HadoopRPC. We are using Swift(https://github.com/facebook/swift) which is a fast and easy-to-use, annotation-based Java library for creating Thrift serializable types and services. The idea is to annotate the Data Structures that need to be transported across the wire and services interfaces that produce and consume these data structures. This will enable us to move away from the Proxy based Thrift server implementation and adopt the Native thrift server interface. This also allows us to write C++ and PHP clients which directly talk to the actual regionserver demons rather than proxy demons which introduce additional hops, memory and CPU overhead. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (HBASE-9946) Create a HBase C++ Thrift Client
Gaurav Menghani created HBASE-9946: -- Summary: Create a HBase C++ Thrift Client Key: HBASE-9946 URL: https://issues.apache.org/jira/browse/HBASE-9946 Project: HBase Issue Type: Sub-task Affects Versions: 0.89-fb Reporter: Gaurav Menghani Assignee: Gaurav Menghani Fix For: 0.89-fb This is a task to create a native thrift C++ client for HBase when we change the RPC stack to Thrift in HBASE-9930. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Work stopped] (HBASE-9944) Create a HBase C++ Thrift Client
[ https://issues.apache.org/jira/browse/HBASE-9944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HBASE-9944 stopped by Gaurav Menghani. Create a HBase C++ Thrift Client Key: HBASE-9944 URL: https://issues.apache.org/jira/browse/HBASE-9944 Project: HBase Issue Type: New Feature Affects Versions: 0.89-fb Reporter: Gaurav Menghani Assignee: Gaurav Menghani Fix For: 0.89-fb This is a task to create a native thrift C++ client for HBase when we change the RPC stack to Thrift in HBASE-9930. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Work started] (HBASE-9944) Create a HBase C++ Thrift Client
[ https://issues.apache.org/jira/browse/HBASE-9944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HBASE-9944 started by Gaurav Menghani. Create a HBase C++ Thrift Client Key: HBASE-9944 URL: https://issues.apache.org/jira/browse/HBASE-9944 Project: HBase Issue Type: New Feature Affects Versions: 0.89-fb Reporter: Gaurav Menghani Assignee: Gaurav Menghani Fix For: 0.89-fb This is a task to create a native thrift C++ client for HBase when we change the RPC stack to Thrift in HBASE-9930. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (HBASE-9944) Create a HBase C++ Thrift Client
[ https://issues.apache.org/jira/browse/HBASE-9944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Menghani updated HBASE-9944: --- Issue Type: Sub-task (was: New Feature) Parent: HBASE-9930 Create a HBase C++ Thrift Client Key: HBASE-9944 URL: https://issues.apache.org/jira/browse/HBASE-9944 Project: HBase Issue Type: Sub-task Affects Versions: 0.89-fb Reporter: Gaurav Menghani Assignee: Gaurav Menghani Fix For: 0.89-fb This is a task to create a native thrift C++ client for HBase when we change the RPC stack to Thrift in HBASE-9930. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (HBASE-9946) Create a HBase C++ Thrift Client
[ https://issues.apache.org/jira/browse/HBASE-9946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Menghani resolved HBASE-9946. Resolution: Duplicate Create a HBase C++ Thrift Client Key: HBASE-9946 URL: https://issues.apache.org/jira/browse/HBASE-9946 Project: HBase Issue Type: Sub-task Components: IPC/RPC Affects Versions: 0.89-fb Reporter: Gaurav Menghani Assignee: Gaurav Menghani Fix For: 0.89-fb This is a task to create a native thrift C++ client for HBase when we change the RPC stack to Thrift in HBASE-9930. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (HBASE-9891) Add more counters to HTableMultiplexer
Gaurav Menghani created HBASE-9891: -- Summary: Add more counters to HTableMultiplexer Key: HBASE-9891 URL: https://issues.apache.org/jira/browse/HBASE-9891 Project: HBase Issue Type: Improvement Affects Versions: 0.89-fb Reporter: Gaurav Menghani Assignee: Gaurav Menghani Fix For: 0.89-fb Add counters for retried puts, and succeeded puts in HTableMultiplexer. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (HBASE-3149) Make flush decisions per column family
[ https://issues.apache.org/jira/browse/HBASE-3149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Menghani updated HBASE-3149: --- Fix Version/s: 0.89-fb Status: Patch Available (was: Open) Patch for the 0.89-fb version. Make flush decisions per column family -- Key: HBASE-3149 URL: https://issues.apache.org/jira/browse/HBASE-3149 Project: HBase Issue Type: Improvement Components: regionserver Reporter: Karthik Ranganathan Assignee: Gaurav Menghani Priority: Critical Fix For: 0.89-fb Today, 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.1#6144)
[jira] [Updated] (HBASE-3149) Make flush decisions per column family
[ https://issues.apache.org/jira/browse/HBASE-3149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Menghani updated HBASE-3149: --- Attachment: Per-CF-Memstore-Flush.diff This diff is only for the 0.89-fb branch, I will port this to master soon. Make flush decisions per column family -- Key: HBASE-3149 URL: https://issues.apache.org/jira/browse/HBASE-3149 Project: HBase Issue Type: Improvement Components: regionserver Reporter: Karthik Ranganathan Assignee: Gaurav Menghani Priority: Critical Fix For: 0.89-fb Attachments: Per-CF-Memstore-Flush.diff Today, 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.1#6144)
[jira] [Commented] (HBASE-3149) Make flush decisions per column family
[ https://issues.apache.org/jira/browse/HBASE-3149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13804537#comment-13804537 ] Gaurav Menghani commented on HBASE-3149: The basic idea is to be able to maintain the smallest LSN amongst the edits present in a particular memstore for a column family. When we decide to flush a set of memstores, we find the smallest LSN id amongst the memstores that we are not flushing, say X, and say that we can remove the logs for any edits with LSN less than X. We choose a particular memstore to be flushed, if it occupies more than 't' bytes, when the global memstore size threshold is 'T' (and t/T = 1/4 for our configuration). If there is no memstore with = t bytes but the total size of all the memstores is above T, we flush all the memstores. Make flush decisions per column family -- Key: HBASE-3149 URL: https://issues.apache.org/jira/browse/HBASE-3149 Project: HBase Issue Type: Improvement Components: regionserver Reporter: Karthik Ranganathan Assignee: Gaurav Menghani Priority: Critical Fix For: 0.89-fb Attachments: Per-CF-Memstore-Flush.diff Today, 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.1#6144)
[jira] [Created] (HBASE-9833) Be able to block on HTableMultiplexer puts when the buffer is full
Gaurav Menghani created HBASE-9833: -- Summary: Be able to block on HTableMultiplexer puts when the buffer is full Key: HBASE-9833 URL: https://issues.apache.org/jira/browse/HBASE-9833 Project: HBase Issue Type: Improvement Affects Versions: 0.89-fb Reporter: Gaurav Menghani Priority: Minor Fix For: 0.89-fb So far, when we try to insert to HTableMultiplexer, it returns false if the buffer is full. This forces one to write wrapper code to retry inserting into the buffer. If someone is okay with the put getting blocked while the buffer is flushed, we should block. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (HBASE-3149) Make flush decisions per column family
[ https://issues.apache.org/jira/browse/HBASE-3149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Menghani reassigned HBASE-3149: -- Assignee: Gaurav Menghani Assigning this to myself, since I have committed this change in the 0.89-fb branch. Will upload the patch shortly. Make flush decisions per column family -- Key: HBASE-3149 URL: https://issues.apache.org/jira/browse/HBASE-3149 Project: HBase Issue Type: Improvement Components: regionserver Reporter: Karthik Ranganathan Assignee: Gaurav Menghani Priority: Critical Today, 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.1#6144)
[jira] [Assigned] (HBASE-8805) [89-fb] Allow compaction related configurations to be reloaded on-the-fly
[ https://issues.apache.org/jira/browse/HBASE-8805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Menghani reassigned HBASE-8805: -- Assignee: Gaurav Menghani [89-fb] Allow compaction related configurations to be reloaded on-the-fly - Key: HBASE-8805 URL: https://issues.apache.org/jira/browse/HBASE-8805 Project: HBase Issue Type: Improvement Affects Versions: 0.89-fb Reporter: Gaurav Menghani Assignee: Gaurav Menghani Fix For: 0.89-fb We already have the infrastructure to reload the configurations on-the-fly for RegionServers (through HBASE-8544 and HBASE-8576). This change allows us to change compaction related configurations by using that infrastructure. This is already done, and should appear in the 89-fb branch soon. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8805) [89-fb] Allow compaction related configurations to be reloaded on-the-fly
[ https://issues.apache.org/jira/browse/HBASE-8805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Menghani updated HBASE-8805: --- Attachment: HBASE-8805.patch The patch that was committed. [89-fb] Allow compaction related configurations to be reloaded on-the-fly - Key: HBASE-8805 URL: https://issues.apache.org/jira/browse/HBASE-8805 Project: HBase Issue Type: Improvement Affects Versions: 0.89-fb Reporter: Gaurav Menghani Assignee: Gaurav Menghani Fix For: 0.89-fb Attachments: HBASE-8805.patch We already have the infrastructure to reload the configurations on-the-fly for RegionServers (through HBASE-8544 and HBASE-8576). This change allows us to change compaction related configurations by using that infrastructure. This is already done, and should appear in the 89-fb branch soon. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Work started] (HBASE-8805) [89-fb] Allow compaction related configurations to be reloaded on-the-fly
[ https://issues.apache.org/jira/browse/HBASE-8805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HBASE-8805 started by Gaurav Menghani. [89-fb] Allow compaction related configurations to be reloaded on-the-fly - Key: HBASE-8805 URL: https://issues.apache.org/jira/browse/HBASE-8805 Project: HBase Issue Type: Improvement Affects Versions: 0.89-fb Reporter: Gaurav Menghani Assignee: Gaurav Menghani Fix For: 0.89-fb Attachments: HBASE-8805.patch We already have the infrastructure to reload the configurations on-the-fly for RegionServers (through HBASE-8544 and HBASE-8576). This change allows us to change compaction related configurations by using that infrastructure. This is already done, and should appear in the 89-fb branch soon. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8805) [89-fb] Allow compaction related configurations to be reloaded on-the-fly
[ https://issues.apache.org/jira/browse/HBASE-8805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Menghani updated HBASE-8805: --- Status: Patch Available (was: In Progress) [89-fb] Allow compaction related configurations to be reloaded on-the-fly - Key: HBASE-8805 URL: https://issues.apache.org/jira/browse/HBASE-8805 Project: HBase Issue Type: Improvement Affects Versions: 0.89-fb Reporter: Gaurav Menghani Assignee: Gaurav Menghani Fix For: 0.89-fb Attachments: HBASE-8805.patch We already have the infrastructure to reload the configurations on-the-fly for RegionServers (through HBASE-8544 and HBASE-8576). This change allows us to change compaction related configurations by using that infrastructure. This is already done, and should appear in the 89-fb branch soon. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8805) [89-fb] Allow compaction related configurations to be reloaded on-the-fly
[ https://issues.apache.org/jira/browse/HBASE-8805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Menghani updated HBASE-8805: --- Resolution: Fixed Status: Resolved (was: Patch Available) [89-fb] Allow compaction related configurations to be reloaded on-the-fly - Key: HBASE-8805 URL: https://issues.apache.org/jira/browse/HBASE-8805 Project: HBase Issue Type: Improvement Affects Versions: 0.89-fb Reporter: Gaurav Menghani Assignee: Gaurav Menghani Fix For: 0.89-fb Attachments: HBASE-8805.patch We already have the infrastructure to reload the configurations on-the-fly for RegionServers (through HBASE-8544 and HBASE-8576). This change allows us to change compaction related configurations by using that infrastructure. This is already done, and should appear in the 89-fb branch soon. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (HBASE-8544) Add a utility to reload configurations in Region Server
[ https://issues.apache.org/jira/browse/HBASE-8544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Menghani reassigned HBASE-8544: -- Assignee: Gaurav Menghani Add a utility to reload configurations in Region Server --- Key: HBASE-8544 URL: https://issues.apache.org/jira/browse/HBASE-8544 Project: HBase Issue Type: New Feature Affects Versions: 0.89-fb Reporter: Gaurav Menghani Assignee: Gaurav Menghani Create a utility that can talk to the Region Servers and make them reload configurations on disk. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (HBASE-8576) [89-fb] Allow individual classes to get notified when Configuration is reloaded
[ https://issues.apache.org/jira/browse/HBASE-8576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Menghani reassigned HBASE-8576: -- Assignee: Gaurav Menghani [89-fb] Allow individual classes to get notified when Configuration is reloaded --- Key: HBASE-8576 URL: https://issues.apache.org/jira/browse/HBASE-8576 Project: HBase Issue Type: New Feature Affects Versions: 0.89-fb Reporter: Gaurav Menghani Assignee: Gaurav Menghani The purpose of this feature is to let individual classes who are interested in observing online configuration changes, to be notified when the Conf is reloaded from disk. This is the second part of the Online Configuration Upgrade feature (the first being HBASE-8544). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8576) [89-fb] Allow individual classes to get notified when Configuration is reloaded
[ https://issues.apache.org/jira/browse/HBASE-8576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Menghani updated HBASE-8576: --- Fix Version/s: 0.89-fb Status: Patch Available (was: Open) [89-fb] Allow individual classes to get notified when Configuration is reloaded --- Key: HBASE-8576 URL: https://issues.apache.org/jira/browse/HBASE-8576 Project: HBase Issue Type: New Feature Affects Versions: 0.89-fb Reporter: Gaurav Menghani Assignee: Gaurav Menghani Fix For: 0.89-fb Attachments: HBASE-8576.patch The purpose of this feature is to let individual classes who are interested in observing online configuration changes, to be notified when the Conf is reloaded from disk. This is the second part of the Online Configuration Upgrade feature (the first being HBASE-8544). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8576) [89-fb] Allow individual classes to get notified when Configuration is reloaded
[ https://issues.apache.org/jira/browse/HBASE-8576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Menghani updated HBASE-8576: --- Attachment: HBASE-8576.patch [89-fb] Allow individual classes to get notified when Configuration is reloaded --- Key: HBASE-8576 URL: https://issues.apache.org/jira/browse/HBASE-8576 Project: HBase Issue Type: New Feature Affects Versions: 0.89-fb Reporter: Gaurav Menghani Assignee: Gaurav Menghani Fix For: 0.89-fb Attachments: HBASE-8576.patch The purpose of this feature is to let individual classes who are interested in observing online configuration changes, to be notified when the Conf is reloaded from disk. This is the second part of the Online Configuration Upgrade feature (the first being HBASE-8544). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
