[
https://issues.apache.org/jira/browse/ZOOKEEPER-1644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13576854#comment-13576854
]
Edward Ribeiro commented on ZOOKEEPER-1644:
-------------------------------------------
Very cool feature to have.
By the way, the description (1st paragraph) is basically
https://issues.apache.org/jira/browse/ZOOKEEPER-706 So, what about adding a
"relates to" link to that issue, or vice-versa?
> Add support for compressed SetWatches packet
> --------------------------------------------
>
> Key: ZOOKEEPER-1644
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1644
> Project: ZooKeeper
> Issue Type: Improvement
> Components: c client, java client, server
> Reporter: Thawan Kooburat
>
> On reconnect with a server to restore its session, a client have to send all
> watched paths via SetWatches packet to the server. This can be potentially
> large and exceeded server-side buffer (jute.maxbuffer) causing the session to
> fail. We have 2 concerns.
> 1. We can increase jute.maxbuffer to arbitrarily size as a simple workaround,
> but, in our use case, the number of watch is going to keep growing
> 2. If a large number of clients get disconnected at once, the server may
> receive a large amount data over network because of the flood of SetWatches
> packet.
> In our case, the watch paths should by highly compressible. So our current
> plan is to add a new type of request which is a compressed set watch request.
> It should be possible to support multiple compression schemes. We are
> probably going to use snappy compression but may add support for gzip as a
> default to minimize external dependency requirement.
> Feel free to comment if you have any suggestion.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
