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] [Commented] (HBASE-14674) Rpc handler / task monitoring seems to be broken after 0.98
Date Thu, 22 Oct 2015 16:55:27 GMT

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

Heng Chen commented on HBASE-14674:

What is the difference between reader and handler? It seems to be same. 
Shall we rename class reader to be readerHandler, or just set read thread name to be something
like "RpcServer.handler" ?

Sorry, i get the point.  "the handler" you mean is RpcExecutor handler,  Right? 

> Rpc handler / task monitoring seems to be broken after 0.98
> -----------------------------------------------------------
>                 Key: HBASE-14674
>                 URL: https://issues.apache.org/jira/browse/HBASE-14674
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Enis Soztutar
>             Fix For: 1.3.0, 1.2.1, 1.0.3, 1.1.4, 0.98.17
> In 0.96, we have the RPC handlers listed as tasks and show them in the web UI as well:

> {code}
> Tasks:
> ===========================================================
> Task: RpcServer.handler=0,port=64231
> Status: WAITING:Waiting for a call
> Running for 932s
> Task: RpcServer.handler=1,port=64231
> Status: WAITING:Waiting for a call
> Running for 932s
> Task: RpcServer.handler=2,port=64231
> Status: WAITING:Waiting for a call
> Running for 932s
> {code}
> After pluggable RPC scheduler, the way the tasks work for the handlers got changed. We
no longer list idle RPC handlers in the tasks, but we register them dynamically to {{TaskMonitor}}
through {{CallRunner}}. However, the IPC readers are still registered the old way (meaning
that idle readers are listed as tasks, but not idle handlers). 
> From the javadoc of {{MonitoredRPCHandlerImpl}}, it seems that we are NOT optimizing
the allocation for the MonitoredTask anymore, but instead allocate one for every RPC call
breaking the pattern (See CallRunner.getStatus()). 
> {code}
> /**
>  * A MonitoredTask implementation designed for use with RPC Handlers 
>  * handling frequent, short duration tasks. String concatenations and object 
>  * allocations are avoided in methods that will be hit by every RPC call.
>  */
> @InterfaceAudience.Private
> public class MonitoredRPCHandlerImpl extends MonitoredTaskImpl
> {code}
> There is also one more side affect that, since the CallRunner is a per-RPC object and
created in the RPC listener thread, the created task ends up having a name "listener" although
the actual processing happens in a handler thread. This is obviously very confusing during

This message was sent by Atlassian JIRA

View raw message