hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Antonov (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-11747) ClusterStatus is too bulky
Date Wed, 01 Jul 2015 23:18:04 GMT

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

Mikhail Antonov commented on HBASE-11747:
-----------------------------------------

bq. JMX. Idea is to help shrink ClusterStatus by moving metrics out.
Hmm. JMX isn't a transport for messages, is it? I think I'm missing something here.. I thought
only of RPC messaging overhaul here. Could you describe JMX approach?

bq. Rather than have a protocol that cuts in only when we are too big, could we not slim ClusterStatus
so vitals only and always require client use a separate call for detail (or go to metrics
system if it is counts, etc., that it is interested in). I like your suggestion of adding
a new call for doing new "protocol" That'd be best.

So you think, just modify ClusterStatus proto server side wiring, so we just never include
load info in the message (we can avoid completely removing this field to maintain wire compatibility?),
and add new rpc method? That's what i'm thinking now too. Question - how would this new RPC
overlap with metrics functionality? 

Let me walk thru users of ClusterStatus and see which of them actually use load info and for
what (balancer, what else).

bq. Yes. Pardon my conflation. Will restrain myself in future.
Oh, I just meant, is there more aspects of this problem than what I see now, which should
be considered while deciding of what approach to take.





> ClusterStatus is too bulky 
> ---------------------------
>
>                 Key: HBASE-11747
>                 URL: https://issues.apache.org/jira/browse/HBASE-11747
>             Project: HBase
>          Issue Type: Sub-task
>            Reporter: Virag Kothari
>         Attachments: exceptiontrace
>
>
> Following exception on 0.98 with 1M regions on cluster with 160 region servers
> {code}
> Caused by: java.io.IOException: Call to regionserverhost:port failed on local exception:
com.google.protobuf.InvalidProtocolBufferException: Protocol message was too large.  May be
malicious.  Use CodedInputStream.setSizeLimit() to increase the size limit.
> 	at org.apache.hadoop.hbase.ipc.RpcClient.wrapException(RpcClient.java:1482)
> 	at org.apache.hadoop.hbase.ipc.RpcClient.call(RpcClient.java:1454)
> 	at org.apache.hadoop.hbase.ipc.RpcClient.callBlockingMethod(RpcClient.java:1654)
> 	at org.apache.hadoop.hbase.ipc.RpcClient$BlockingRpcChannelImplementation.callBlockingMethod(RpcClient.java:1712)
> 	at org.apache.hadoop.hbase.protobuf.generated.MasterProtos$MasterService$BlockingStub.getClusterStatus(MasterProtos.java:42555)
> 	at org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation$5.getClusterStatus(HConnectionManager.java:2132)
> 	at org.apache.hadoop.hbase.client.HBaseAdmin$16.call(HBaseAdmin.java:2166)
> 	at org.apache.hadoop.hbase.client.HBaseAdmin$16.call(HBaseAdmin.java:2162)
> 	at org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithRetries(RpcRetryingCaller.java:114)
> 	... 43 more
> Caused by: com.google.protobuf.InvalidProtocolBufferException: Protocol message was too
large.  May be malicious.  Use CodedInputStream.setSizeLimit() to increase the size limit.
> 	at com.google.protobuf.InvalidProtocolBufferException.sizeLimitExceeded(InvalidProtocolBufferException.java:110)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message