[
https://issues.apache.org/jira/browse/ZOOKEEPER-1162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13091906#comment-13091906
]
Todd Lipcon commented on ZOOKEEPER-1162:
----------------------------------------
Does ZK use any checksums/magic numbers in its wire protocol? Typically I see
limits like this on packet framing lengths so that, if you connect and send
garbage to the IPC port, it won't try to allocate 4GB and crash. Adding a magic
number before the length or a simple checksum would prevent the "garbage being
interpreted as a length" issue, while still allowing large responses.
> consistent handling of jute.maxbuffer when attempting to read large zk
> "directories"
> ------------------------------------------------------------------------------------
>
> Key: ZOOKEEPER-1162
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1162
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
> Affects Versions: 3.3.3
> Reporter: Jonathan Hsieh
> Priority: Critical
> Fix For: 3.5.0
>
>
> Recently we encountered a sitaution where a zk directory got sucessfully
> populated with 250k elements. When our system attempted to read the znode
> dir, it failed because the contents of the dir exceeded the default 1mb
> jute.maxbuffer limit. There were a few odd things
> 1) It seems odd that we could populate to be very large but could not read
> the listing
> 2) The workaround was bumping up jute.maxbuffer on the client side setting.
> Would it make more sense to have it reject adding new znodes if it exceeds
> jute.maxbuffer?
> Alternately, would it make sense to have zk dir listing ignore the
> jute.maxbuffer setting?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
