[
https://issues.apache.org/jira/browse/HBASE-3899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13040024#comment-13040024
]
Gary Helmling commented on HBASE-3899:
--------------------------------------
I know this is already committed, but I have some questions about the static
methods that were sprinkled in to HBaseServer, and I'd like to better
understand what direction we're headed in. In general, the static methods, if
invoked outside the RPC layer, break the {{RpcEngine}} and {{RpcServer}}
abstractions that were added to allow loadable RPC engines. There doesn't seem
to be anything calling the static methods yet, so pardon if my assumptions are
wrong. I assume that's slated for a follow up instead.
{code}
public static void startDelay(Object o) {
Call call = (Call) o;
if (call != null) {
call.startDelay();
}
}
public static void endDelay(Object o) throws IOException {
Call call = (Call) o;
if (call != null) {
call.endDelay();
}
}
{code}
Since these only invoke the corresponding methods in Call, which are public,
why not just invoke those directly?
{code}
public static Object getCall() {
return CurCall.get();
}
{code}
This will not be valid if an alternate engine/RPC server is loaded. Should we
instead have {{RpcServer.getCall()}}? Or some other RPC request context?
{code}
static public void processRpcResponse(Object callobj, Writable value,
String error, String errorClass) throws IOException {
{code}
I'm not sure I understand why this one is static, unless it will be invoked
throughout other areas of the HBase code? The contents of this method also
seem to duplicate what's contained in {{Handler.run()}}, so I'm not sure why we
have the conditional check in {{HBaseServer.Handler.run()}}:
{code}
if (!(value instanceof WritableDelayed)) {
processRpcResponse(call, value, error, errorClass);
}
{code}
It looks to me like both code paths that would be followed are the same? Am I
missing something?
In particular, I rely on the {{RpcEngine}} and {{RpcServer}} interfaces to be
able to load a secure RPC engine transparently. Having HBase code directly
using {{HBaseServer}} will break that. Can the functionality of these static
methods be accommodated instead using instance methods called on a reference to
the loaded {{RpcServer}} instance?
I can open a new JIRA to address changes, just wanted to get clarification here
first.
> enhance HBase RPC to support free-ing up server handler threads even if
> response is not ready
> ---------------------------------------------------------------------------------------------
>
> Key: HBASE-3899
> URL: https://issues.apache.org/jira/browse/HBASE-3899
> Project: HBase
> Issue Type: Improvement
> Components: ipc
> Reporter: dhruba borthakur
> Assignee: dhruba borthakur
> Fix For: 0.92.0
>
> Attachments: asyncRpc.txt, asyncRpc.txt
>
>
> In the current implementation, the server handler thread picks up an item
> from the incoming callqueue, processes it and then wraps the response as a
> Writable and sends it back to the IPC server module. This wastes
> thread-resources when the thread is blocked for disk IO (transaction logging,
> read into block cache, etc).
> It would be nice if we can make the RPC Server Handler threads pick up a call
> from the IPC queue, hand it over to the application (e.g. HRegion), the
> application can queue it to be processed asynchronously and send a response
> back to the IPC server module saying that the response is not ready. The RPC
> Server Handler thread is now ready to pick up another request from the
> incoming callqueue. When the queued call is processed by the application, it
> indicates to the IPC module that the response is now ready to be sent back to
> the client.
> The RPC client continues to experience the same behaviour as before. A RPC
> client is synchronous and blocks till the response arrives.
> This RPC enhancement allows us to do very powerful things with the
> RegionServer. In future, we can make enhance the RegionServer's threading
> model to a message-passing model for better performance. We will not be
> limited by the number of threads in the RegionServer.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
