zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "sujay paranjape (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ZOOKEEPER-706) large numbers of watches can cause session re-establishment to fail
Date Wed, 22 Aug 2018 14:56:00 GMT

    [ https://issues.apache.org/jira/browse/ZOOKEEPER-706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16588973#comment-16588973
] 

sujay paranjape commented on ZOOKEEPER-706:
-------------------------------------------

Looks like patch has fix only for JAVA client. This has not been fixed for C client. I would
like to submit a fix for C client. Please confirm. 

> 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
>            Assignee: Chris Thunes
>            Priority: Critical
>             Fix For: 3.4.7, 3.5.2, 3.6.0
>
>         Attachments: ZOOKEEPER-706-branch-34.patch, ZOOKEEPER-706-branch-34.patch, ZOOKEEPER-706.patch,
ZOOKEEPER-706.patch, 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
(v7.6.3#76005)

Mime
View raw message