[
https://issues.apache.org/jira/browse/HBASE-15071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15085980#comment-15085980
]
Matteo Bertozzi commented on HBASE-15071:
-----------------------------------------
I don't think the problem is procedure.
the client is able to interpret a missing procId, and fallback to a waiting
logic.
for example, waiting when the table is available on create. or checking if the
table does not exist anymore on delete.
if you don't implement that fallback logic on the client you assume the server
did everything synchronously and when you get back the response you are done
and there are no error. the client with the proc code is already able to do
that without any changes.
the problem here is. what bypass mean for things that are not returning values
who is creating a table or adding a column? does that make sense or at least
play well with all the assumptions we have around the code base? if someone
does the operation for us and call bypass, that must be synchronous otherwise
we can just guess on what to wait for
> 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)
