You are viewing a plain text version of this content. The canonical link for it is here.

Posted to issues@hbase.apache.org by "Lars Hofhansl (JIRA)" <ji...@apache.org> on 2012/08/02 21:56:02 UTC

[jira] [Updated] (HBASE-6496) Example ZK based scan policy

     [ https://issues.apache.org/jira/browse/HBASE-6496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lars Hofhansl updated HBASE-6496:
---------------------------------

    Attachment: 6496.txt

Here's a work in progress.
It wasn't actually as straightforward as I thought, as there is no place within a RegionServer that would allow coprocessors to share some state.

Furthermore I could not use the RegionServer's ZooKeeperWatcher as there is no way to unregister a Listener, hence as RegionObservers come and go their listeners would pile up firing uselessly and preventing the RegionObserver implementation from the being GC'd.

So instead the RegionObserver itself is a watcher, which on other hand now leads to a Watcher per region.

I could use some advice here, will such use of ZK scale?
If it doesn't I could
# add a removeListenere method to ZooKeeperWatcher (would still need to work out how avoid many watches for the same node) or
# Have a way for RegionCoprocessorEnvironment to host some shared state for RegionObserver to coordinate in case such as this one. (could just be a Map that is accessible to all RegionObservers).

                
> Example ZK based scan policy
> ----------------------------
>
>                 Key: HBASE-6496
>                 URL: https://issues.apache.org/jira/browse/HBASE-6496
>             Project: HBase
>          Issue Type: Sub-task
>            Reporter: Lars Hofhansl
>            Assignee: Lars Hofhansl
>             Fix For: 0.96.0, 0.94.2
>
>         Attachments: 6496.txt
>
>
> Provide an example of a RegionServer that listens to a ZK node to learn about what set of KVs can safely be deleted during a compaction.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira