hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Heng Chen (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (HBASE-15071) Cleanup bypass semantic in MasterCoprocessorHost
Date Wed, 06 Jan 2016 09:27:39 GMT

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

Heng Chen edited comment on HBASE-15071 at 1/6/16 9:27 AM:
-----------------------------------------------------------

{quote}
The point of bypass is to skip further core code processing. The coprocessor says it has taken
care of everything, time to return back to the client taking no further action. What you propose
directly contravenes this semantic in place everywhere a coprocessor can call bypass()
{quote}
Hmm...  Sounds reasonable...   
So we should make all "pre" actions respect bypass returned (e.g.  preDeleteTable did not
return bypass, we should return it and respect it ), right?  

There are some special case, e.g. preGetNamespaceDescriptor, currently it return nothing,
but as bypass logic,  it should return one {{NamespaceDescriptor}} instance and the caller
will use bypass to decide whether we should return it to client or not, but if so, it will
be incompatible with old observer.  

Or we can just comment the interface "it can't bypass  the default action" just like preListSnapshot
did now.  And i notice except {{preBalanceSwitch}}, all interfaces in MasterObserver return
nothing, is it means we just bypass the default action and return something arbitrary is fine?
 If so, maybe we should modify the semantic of bypass..... 

Thanks [~apurtell] for your reply.


was (Author: chenheng):
{quote}
The point of bypass is to skip further core code processing. The coprocessor says it has taken
care of everything, time to return back to the client taking no further action. What you propose
directly contravenes this semantic in place everywhere a coprocessor can call bypass()
{quote}
Hmm...  Sounds reasonable...   
So we should make all "pre" actions respect bypass returned (e.g.  preDeleteTable did not
return bypass, we should return it and respect it ), right?  
There are some special case, e.g. preGetNamespaceDescriptor, currently it return nothing,
but as bypass logic,  it should return one {{NamespaceDescriptor}} instance and the caller
will use bypass to decide whether we should return it to client.  Or we can comment the interface
it can't bypass  the default action just like preListSnapshot did now. 

Thanks [~apurtell] for your reply.

> Cleanup bypass semantic in MasterCoprocessorHost
> ------------------------------------------------
>
>                 Key: HBASE-15071
>                 URL: https://issues.apache.org/jira/browse/HBASE-15071
>             Project: HBase
>          Issue Type: Task
>          Components: Coprocessors
>    Affects Versions: 2.0.0
>            Reporter: stack
>            Priority: Blocker
>
> Lets decide on this one before we release 2.0.0.
> A bunch of methods in MasterCoprocessorHost on the 'pre' step allow returning true which
indicates the method invocation is not to proceed.
> Not all 'pre' steps do this. Just some.
> Seems a little arbitrary.
> How we skip out if we are not proceed with the invocation is also a little arbitrary.
> When a deleteColumn call is supposed to skip out, it returns a -1, a non-procId. If we
are to skip a balance call, we log that CP said skip and then return false to indicate the
balancer did not run (why?). Elsewhere we just exit silently. In createNamespace we used to
exit silently but HBASE-14888 just changed it so we throw a BypassCoprocessorException instead...

> Lets make them all work the same way.
> (This issue comes of chat w/ Matteo)



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

Mime
View raw message