[jira] [Commented] (HBASE-6992) Coprocessors semantic issues: post async operations, helper methods, ...

["Stephen Yuan Jiang (JIRA)" <ji...@apache.org>]

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

Stephen Yuan Jiang commented on HBASE-6992:
-------------------------------------------

Let us revive the discussion - in terms of naming convention, I propose that we change post RPC op to postXXXAsync for any async operation (we can keep the current postXXX for sync or rename it as postXXXSync).  note: XXX is the RPC operation name such as CreateTable.  For the real processing, we change the name from preXXXHandler/postXXXHandler to preXXXAction and postXXXSuccessAction; and if we want, add postXXXFailureAction.  

[~mbertozzi] said he was not good at naming, I am either (or worse).  More suggestion is welcomed. 

> Coprocessors semantic issues: post async operations, helper methods, ...
> ------------------------------------------------------------------------
>
>                 Key: HBASE-6992
>                 URL: https://issues.apache.org/jira/browse/HBASE-6992
>             Project: HBase
>          Issue Type: Brainstorming
>          Components: Coprocessors
>    Affects Versions: 0.92.2, 0.94.2, 0.95.2
>            Reporter: Matteo Bertozzi
>            Assignee: Matteo Bertozzi
>
> Discussion ticket around coprocessor pre/post semantic.
> For each rpc in HMaster we have a pre/post operation that allows a coprocessor
> to execute some code before and after the operation
> * preOperation()
> * my operation
> * postOperation()
> This is used for example by the AccessController to verify if the user can execute or not the operation.
> Everything is fine, unless the master operation is asynchronous (like create/delete table)
> * preOperation()
> * executor.submit(new OperationHandler())
> * postOperation()
> The pre operation is still fine, since is executed before the operation and need to throw exceptions to the client in case of failures...
> The post operation, instead, is no longer post... is just post submit. And if someone subscribe to postCreateTable() the notification can arrive before the table creation.
> To "solve" this problem, HBASE-5584 added pre/post handlers and now the situation looks like this:
> {code}
> client request              client response
>       |                           |
>       +------+-- submit op --+----+---         (HMaster)
>            pre op         post op
> (executor)                     +---- handler ----+
>                            pre handler       post handler
> {code}
> Now, we've two types of pre/post operation and the semantical correct are preOperation() and postOperationHandler()
> since the preOperation() needs to reply to the client (e.g AccessController NotAllowException) and the postOperatioHandler() is really post operation.
> postOperation() is not post... and preOperationHandler() can't communicate with the client.
> The AccessController coprocessor uses the postOperation() that is fine for the sync operation like addColumn(), deleteColumn()... but in case of failure of async operations like deleteTable() we've removed rights that we still need.
> I think that we should get back just to the single pre/post operation but with the right semantic...
> Other then the "when is executed" problem, we've also functions that can be described with other simpler functions
> for example: modifyTable() is just a helper to avoid multiple addColumn()/deleteColumn() calls
> but the problem here is that modifyTable() has its own pre/post operation() and if I've implemented the pre/post addColumn I don't get notified when I call modifyTable(). This is another problem in the access controller coprocessor
> In this case I'm not sure what the best solution can be... but in this way, adding new helper methods means breaking the coprocessors, because they don't get notified even if something is changed...
> Any idea, thoughts, ...?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)