[
https://issues.apache.org/jira/browse/HBASE-6496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13427634#comment-13427634
]
Lars Hofhansl commented on HBASE-6496:
--------------------------------------
bq. Extend above facility for shared watchers, one watcher per RS for a given
CP, perhaps again keyed on class name.
I like this one. In this case the hooks implemented by the region observer are
in a critical path (at least preStoreScannerOpen is), so I do not want to call
zk.getData(...) in that hook, and hence the need for a watcher to be
asynchronously notified of changes.
Each RegionObserver instance would need to be notified about this, and if I
understand the code right there is always exactly one instance per Region for
which the observer is loaded. So sharing a single watcher with a listener for
each CP would be ideal.
bq. We could bring that back as a map like you suggest but shared across all
Observers in a RS, perhaps one map for every class that asks for it
That seems generally useful, and maybe even better suited for the problem
mentioned above. A CP would check whether a watcher has been created (an object
in that shared map), create one if not, and then add a listener. The watcher
would need to support removing listeners.
With that CPs would be able to coordinate among themselves. It's not hard to
make a ZK watcher, so the generality of this might be better.
We have found need for this in other projects, but so far have worked around it.
How would that shared be exposed to a RegionObserver? Via the
RegionCoprocessorEnvironment, or the CoprocessorContext?
> 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
