[
https://issues.apache.org/jira/browse/HBASE-5827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13401764#comment-13401764
]
Andrew Purtell edited comment on HBASE-5827 at 6/26/12 11:07 PM:
-----------------------------------------------------------------
I'd like to revisit the API changes under consideration here.
Do we want a new failXXX for every operation, or should we alter the postXXX
methods?
If the latter, then do we:
provide backwards compatible postXXX methods that put the Throwable into the
Context and provide a new Context method for getting the caught Throwable, or
null if nothing was caught;
or pass the caught Throwable to new postXXX methods as a new parameter, still
provide backwards compatible postXXX methods that put the Throwable into the
Context, but also deprecate the backwards compatible postXXX methods.
Edit: To clarify a bit, with the alternatives above involving postXXX, we would
move code between preXXX and postXXX hooks into a try block, and in the catch
handler call postXXX. The choice presented is basically between introducing a
new failXXX method for every hook point or extending postXXX semantics to cover
the exception path.
was (Author: apurtell):
I'd like to revisit the API changes under consideration here.
Do we want a new failXXX for every operation, or should we alter the postXXX
methods?
If the latter, then do we:
provide backwards compatible postXXX methods that put the Throwable into the
Context and provide a new Context method for getting the caught Throwable, or
null if nothing was caught;
or pass the caught Throwable to new postXXX methods as a new parameter, still
provide backwards compatible postXXX methods that put the Throwable into the
Context, but also deprecate the backwards compatible postXXX methods.
> [Coprocessors] Observer notifications on exceptions
> ---------------------------------------------------
>
> Key: HBASE-5827
> URL: https://issues.apache.org/jira/browse/HBASE-5827
> Project: HBase
> Issue Type: Improvement
> Components: coprocessors
> Reporter: Andrew Purtell
> Assignee: Andrew Purtell
>
> Benjamin Busjaeger wrote on dev@:
> {quote}
> Is there a reason that RegionObservers are not notified when a get/put/delete
> fails? Suppose I maintain some (transient) state in my Coprocessor that is
> created during preGet and discarded during postGet. If the get fails, postGet
> is not invoked, so I cannot remove the state.
> If there is a good reason, is there any other way to achieve the same thing?
> If not, would it be possible to add something the snippet below to the code
> base?
> {code}
> // pre-get CP hook
> if (withCoprocessor && (coprocessorHost != null)) {
> if (coprocessorHost.preGet(get, results)) {
> return results;
> }
> }
> + try{
> ...
> + } catch (Throwable t) {
> + // failed-get CP hook
> + if (withCoprocessor && (coprocessorHost != null)) {
> + coprocessorHost.failedGet(get, results);
> + }
> + rethrow t;
> + }
> // post-get CP hook
> if (withCoprocessor && (coprocessorHost != null)) {
> coprocessorHost.postGet(get, results);
> }
> {code}
> {quote}
--
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
