zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Han (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ZOOKEEPER-3129) Improve ZK Client resiliency by throwing a jute.maxbuffer size exception before sending a request to server
Date Tue, 28 Aug 2018 06:15:00 GMT

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

Michael Han commented on ZOOKEEPER-3129:
----------------------------------------

We already have jute.maxbuffer property for client side (and server side). Would this property
fit the needs here?

> Improve ZK Client resiliency by throwing a jute.maxbuffer size exception before sending
a request to server
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: ZOOKEEPER-3129
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3129
>             Project: ZooKeeper
>          Issue Type: Improvement
>            Reporter: Karan Mehta
>            Priority: Major
>
> Zookeeper is mostly operated in controlled environments and the client/server properties
are usually known. With this Jira, I would like to propose a new property on client side that
represents the max jute buffer size server is going to accept.
> On the ZKClient, in case of multi Op, the request is serialized and hence we know the
size of complete packet that will be sent. We can use this new property to determine if the
we are exceeding the limit and throw some form of KeeperException. This would be fail fast
mechanism and the application can potentially retry by chunking up the request or serializing.
> Since the same properties are now present in two locations, over time, two possibilities
can happen.
> -- Server jutebuffer accepts value is more than what is specified on client side
> The application might end up serializing it or zkclient can be made configurable to retry
even when it gets this exception
> -- Server jutebuffer accepts value is lower than what is specified on client side
> That would have failed previously as well, so there is no change in behavior
> This would help silent failures like HBASE-18549 getting avoided. 
> Thoughts [~apurtell] [~xucang] [~anmolnar] [~hanm]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message