[ https://issues.apache.org/jira/browse/ZOOKEEPER-706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14583867#comment-14583867 ]
Chris Thunes commented on ZOOKEEPER-706: ---------------------------------------- Sure, let me see if I can put something together. It looks like org.apache.zookeeper.test.DisconnectedWatcherTest would an appropriate place for one. Does that seem correct? > large numbers of watches can cause session re-establishment to fail > ------------------------------------------------------------------- > > Key: ZOOKEEPER-706 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-706 > Project: ZooKeeper > Issue Type: Bug > Components: c client, java client > Affects Versions: 3.1.2, 3.2.2, 3.3.0 > Reporter: Patrick Hunt > Priority: Critical > Fix For: 3.4.7, 3.5.2, 3.6.0 > > Attachments: ZOOKEEPER-706.patch > > > If a client sets a large number of watches the "set watches" operation during > session re-establishment can fail. > for example: > WARN [NIOServerCxn.Factory:22801:NIOServerCnxn@417] - Exception causing > close of session 0xe727001201a4ee7c due to java.io.IOException: Len error > 4348380 > in this case the client was a web monitoring app and had set both data and > child watches on > 32k znodes. > there are two issues I see here we need to fix: > 1) handle this case properly (split up the set watches into multiple calls I > guess...) > 2) the session should have expired after the "timeout". however we seem to > consider any message from the client as re-setting the expiration on the > server side. Probably we should only consider messages from the client that > are sent during an established session, otherwise we can see this situation > where the session is not established however the session is not expired > either. Perhaps we should create another JIRA for this particular issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)