hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yu Li (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HBASE-16033) Add more details in logging of responseTooSlow/TooLarge
Date Wed, 15 Jun 2016 15:38:09 GMT

     [ https://issues.apache.org/jira/browse/HBASE-16033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Yu Li updated HBASE-16033:
    Attachment: HBASE-16033.patch

A straight-forward patch. Log after patch would look like:
2016-06-15 13:43:33,763 WARN  [B.defaultRpcServer.handler=4,queue=4,port=16020] ipc.RpcServer:
(responseTooSlow): {"processingtimems":10776,"call":"Multi(org.apache.hadoop.hbase.protobuf.generated.ClientProtos$MultiRequest)",
"client":"","param":"region= msgtable,0535:,1465226523303.930e1623ba37566bd44dfca3bfcdd43e.,
 for 1 actions and 1st row key=0535:20160615134322:533698458535","starttimems":1465969402987,"queuetimems":0,

> Add more details in logging of responseTooSlow/TooLarge
> -------------------------------------------------------
>                 Key: HBASE-16033
>                 URL: https://issues.apache.org/jira/browse/HBASE-16033
>             Project: HBase
>          Issue Type: Bug
>    Affects Versions: 1.2.1
>            Reporter: Yu Li
>            Assignee: Yu Li
>         Attachments: HBASE-16033.patch
> Currently the log message when responseTooSlow/TooLarge is like:
> {noformat}
> 2016-06-08 12:18:04,363 WARN  [B.defaultRpcServer.handler=127,queue=10,port=16020]
> ipc.RpcServer: (responseTooSlow): {"processingtimems":13125,"call":"Multi(org.apache.hadoop.hbase.protobuf.generated.ClientProtos$MultiRequest)",
> "client":"","starttimems":1465359471238,"queuetimems":1540116,
> "class":"HRegionServer","responsesize":17,"method":"Multi"}
> {noformat}
> which is kind of helpless for debugging since we don't know on which table/region/row
the request is against.
> What's more, we could see some if-else check in the {{RpcServer#logResponse}} method
which trying to do sth different when the {{param}} includes instance of {{Operation}}, but
there's only one place invoking {{logResponse}} and the {{param}} is always an instance of
{{Message}}. Checking the change history, I believe this is a left-over cleanup in work of
> We will address the above issues, do some cleanup and improve the log just like {{RpcServer$Call#toString}}
does to include table/region/row information of the request

This message was sent by Atlassian JIRA

View raw message