Karan Mehta created ZOOKEEPER-3129:
--------------------------------------
Summary: 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
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)
