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

Gary Helmling commented on HBASE-16752:
---------------------------------------

Please add javadoc for RequestTooBigException.

It occurs to me that we also need to do something with the remaining request 
data (the body) that is sitting in the socket channel.  Either we'll need to 
read it off into something like a garbage buffer and throw it away, or else 
maybe we should actually close the connection.  If we do close the connection, 
then does this change still buy us something?

> Upgrading from 1.2 to 1.3 can lead to replication failures due to difference 
> in RPC size limit
> ----------------------------------------------------------------------------------------------
>
>                 Key: HBASE-16752
>                 URL: https://issues.apache.org/jira/browse/HBASE-16752
>             Project: HBase
>          Issue Type: Bug
>          Components: Replication, rpc
>    Affects Versions: 2.0.0, 1.3.0
>            Reporter: Ashu Pachauri
>            Assignee: Ashu Pachauri
>         Attachments: HBASE-16752.V1.patch
>
>
> In HBase 1.2, we don't limit size of a single RPC but in 1.3 we limit it by 
> default to 256 MB.  This means that during upgrade scenarios (or when source 
> is 1.2 peer is already on 1.3), it's possible to encounter a situation where 
> we try to send an rpc with size greater than 256 MB because we never unroll a 
> WALEdit while sending replication traffic.
> RpcServer throws the underlying exception locally, but closes the connection 
> with returning the underlying error to the client, and client only sees a 
> "Broken pipe" error.
> I am not sure what is the proper fix here (or if one is needed) to make sure 
> this does not happen, but we should return the underlying exception to the 
> RpcClient, because without it, it can be difficult to diagnose the problem, 
> especially for someone new to HBase.



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

Reply via email to