[
https://issues.apache.org/jira/browse/ZOOKEEPER-706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14583846#comment-14583846
]
Hadoop QA commented on ZOOKEEPER-706:
-------------------------------------
-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12739232/ZOOKEEPER-706.patch
against trunk revision 1684956.
+1 @author. The patch does not contain any @author tags.
-1 tests included. The patch doesn't appear to include any new or modified
tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
-1 patch. The patch command could not apply the patch.
Console output:
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2765//console
This message is automatically generated.
> 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)
