hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Helmling <ghelml...@gmail.com>
Subject Re: coprocessor & table operations
Date Sat, 27 Aug 2011 07:08:35 GMT
On Fri, Aug 26, 2011 at 5:19 PM, Ma, Ming <mingma@ebay.com> wrote:

> Thanks, Gray, Ted. I will open a jira and provide the fix later.
> About where to call such post methods for table operations, after request
> is queued to executor or after EventHandler.process has finished:
> 1. It applies to EnableTableHandler and other table operations as well.
> Currently post methods are called after request is queued to executor. So
> whatever way to go, we will apply to all methods.

I don't feel strongly whether the post method invocations are prior to
completion of the underlying operation or wait to invoke after completion,
as long as we are consistent in similar cases.  When the operations are
async from the client perspective, I'm not sure it matters.  Though when we
have sync and async versions of the operation from a client perspective, how
should this apply?  Maybe it _would_ be better to defer the post method
invocation to completion in those cases?

> 2. Thread model for coprocessor. For a given operation, pre and post
> methods are currently called on the same thread. That seems to be the case
> for all hooks in hbase. Calling post methods from executor thread pool means
> pre and post methods could be called on different threads. Perhaps calling
> on the same thread just happens to be the implementation; there is no such
> assumption in coprocessor design. If we want to change such behavior, at
> least we can clarify in javadoc so that coprocessors developers know about
> it.
I don't think we've expressed any guarantee that pre and post methods will
run in the same thread, but it seems like a natural expectation (right or
not) for coprocessor implementors.  If we need to deviate from this
anywhere, I agree we should clearly document that behavior.

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