Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Wed, 27 Jun 2012 00:11:44 +0000 (UTC)
From: "Andrew Purtell (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <1318731605.59262.1340755904579.JavaMail.jiratomcat@issues-vm>
In-Reply-To: 
 <1832482585.4272.1334800360979.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (HBASE-5827) [Coprocessors] Observer
 notifications on exceptions
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HBASE-5827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13401820#comment-13401820 ] 

Andrew Purtell commented on HBASE-5827:
---------------------------------------

bq. I'll have to take some time to see if a bigger redesign is warranted. 

In the abstract I'd be all for a "coprocessors v2" if the result is more elegant. We are still pre Singularity. (But that does imply a time horizon.) The current framework design is the familiar upcall model, akin to kernel extensions, or a VFS interface. It counts simplicity and familiarity as pluses. But it is by no means the last word I'd say.

bq. TL;DR +1 on an onXXXXFailure method + a deprecated postXXX with error in context for compatibility

Ack.
                
> [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