[
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
