hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Yu <yuzhih...@gmail.com>
Subject Re: Error Handling within endpoint coprocessors -- best practices?
Date Sat, 14 Nov 2015 19:08:30 GMT
As far as I can tell, the hybrid approach is amenable to better exception
handling on client side,

Cheers

On Fri, Nov 13, 2015 at 8:24 PM, Andrew Mains <andrew.mains@upsight.com>
wrote:

> Hi all,
>
> I'm developing an endpoint coprocessor at the moment for one of our
> applications, and I'm trying to figure out the best means to handle errors
> within the coprocessor. A couple of requirements:
>
> 1. I don't want the coprocessor to ever be unloaded on an error (my
> assumption is that errors will generally be independent across queries, and
> that the coprocessor should attempt to serve other queries even if one
> fails).
> 2. I'd like to be able to recognize and handle certain application
> exception classes on the client side (BAD_REQUEST type cases, primarily)
>
> For this, it seems like I have a couple of options:
>
> 1. Handle exceptions in the coprocessor using
> org.apache.hadoop.hbase.protobuf.ResponseConverter#setControllerException.
> This seems to be the method used by the example coprocessors in the
> codebase, and it has the nice property of not requiring me to represent the
> errors explicitly in my response type. On the other hand, docs for
> com.google.protobuf.RpcController#setFailed mention that it shouldn't be
> used for machine readable exceptions, which should instead be represented
> in the response type; this makes it difficult to extract the exception type
> on the client side.
>
> 2. Represent exceptions in the response type proto (e.g. message
> MyResponse { optional Return, optional Error }). This is a little bit less
> transparent than the previous approach, but allows me to handle the
> exceptions more flexibly.
>
> 3. A hybrid approach--use an explicit response in my response type proto
> for exceptions I care about, and setControllerException for everything else.
>
> Any suggestions on the best practice here? As I said, the example
> coprocessors seem to prefer method 1, but they also don't allow for
> differentiating exception types on the client side, so I'm a bit unclear on
> the best way to do this.
>
> Thank you very much for your time!
>
> Andrew
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message