[
https://issues.apache.org/jira/browse/HBASE-7305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13529572#comment-13529572
]
Enis Soztutar commented on HBASE-7305:
--------------------------------------
bq. Can you say more. This is interesting.
Most of the client -> master operations are async. On the RPC code path, the
Handler objects are created, and some basic checks are performed in the c.tor.
Then the rpc returns without waiting for the operation to finish. But we don't
expose any generic mechanism to the client so that it can check the status or
the request (like whether it finished/succeeded/exception). The client can only
check the side effects of the request (if enable table, whether the table is
enabled yet, HBaseAdmin.createTable(), etc).
If we do HBASE-5487, or keep request id's around in the handlers, we can fix
that by exposing some submit task / query status / get exception API from the
master to the client. I think we need to start working on that after this.
In this patch though, we do not acquire the table lock in the rpc path, but
only on EventHandler.process(). The client rpc never waits for the table lock.
But now thinking about it, I think I will change it so that the table lock is
acquired in the RPC handler, and released from the table event handler.
> ZK based Read/Write locks for table operations
> ----------------------------------------------
>
> Key: HBASE-7305
> URL: https://issues.apache.org/jira/browse/HBASE-7305
> Project: HBase
> Issue Type: Bug
> Components: Client, master, Zookeeper
> Reporter: Enis Soztutar
> Assignee: Enis Soztutar
> Fix For: 0.96.0
>
> Attachments: hbase-7305_v0.patch
>
>
> This has started as forward porting of HBASE-5494 and HBASE-5991 from the
> 89-fb branch to trunk, but diverged enough to have it's own issue.
> The idea is to implement a zk based read/write lock per table. Master
> initiated operations should get the write lock, and region operations (region
> split, moving, balance?, etc) acquire a shared read lock.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
