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

Patrick Hunt commented on ZOOKEEPER-442:
----------------------------------------

I'm afraid something is not quite right. I created a very simple sanity check 
which seems to be failing. :-( Please check my logic/code (note: I have some 
time this week and I'd like to keep the momentum going on this one.)

In the first case the code I created will create a watch by calling exists on a 
non-existent node (call it "pre-removewatches"). It does this in a loop. I 
expect the memory to become exhausted on the client. In the second case I 
immediately call "removewatch" on the just-set-watch. In the second case I 
expect that client to run forever (essentially). However in both cases the 
clients crash. I am using the latest patch applied to trunk codebase for this 
testing. (notice the second case does run a bit longer than the first, but 
still, based on the code I have it should run ess. forever):

first case:
{noformat}
USE_REMOVE_CALL:false
maxIter:100000
maxLoops:10000
Available free mem is 14614744
j:0
Available free mem is 12184072
j:1
Available free mem is 8827120
j:2
Available free mem is 6141912
j:3
Available free mem is 2600160
j:4
<OOMException>
{noformat}

second case:
{noformat}
USE_REMOVE_CALL:true
maxIter:100000
maxLoops:10000
Available free mem is 14613488
j:0
Available free mem is 12497584
j:1
Available free mem is 9470512
j:2
Available free mem is 7167880
j:3
Available free mem is 3841616
j:4
Available free mem is 854728
j:5
<OOMException>
{noformat}

I've posted my code to github, it's pretty simple. see:
https://github.com/phunt/zookeeper-removewatch-ex/blob/master/src/test/java/org/phunt/zookeeper/removewatchexample/ExerciseRemoveWatchTest.java

Notice the boolean USE_REMOVE_CALL at the top of the class. You can replicate 
the two output scenarios above by setting this to false (no remove) and true 
(call remove). Then running the test via "mvn test" at the toplevel. (note you 
need to install the 3.5.0-SNAPSHOT artifacts in your local maven cache, you can 
do this by running "ant package" in ZK and copying the resulting artifacts from 
the build subdir dist-maven directory into your .m2 repository)

Does my code make sense? It seems to me that given we're calling exists (on 
non-existent node), setting a watch, then immediately removing the watch, that 
the code should run w/o running out of memory.

I suspect the issue is that we are setting up some data structures to hold the 
watch information, but not fully clearing that data when removing the watch

any ideas? 

> need a way to remove watches that are no longer of interest
> -----------------------------------------------------------
>
>                 Key: ZOOKEEPER-442
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-442
>             Project: ZooKeeper
>          Issue Type: Sub-task
>          Components: java client, server
>            Reporter: Benjamin Reed
>            Assignee: Rakesh R
>            Priority: Critical
>             Fix For: 3.5.0
>
>         Attachments: Remove Watch API.pdf, ZOOKEEPER-442.patch, 
> ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, 
> ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, 
> ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, 
> ZOOKEEPER-442.patch, ZOOKEEPER-442.patch
>
>
> currently the only way a watch cleared is to trigger it. we need a way to 
> enumerate the outstanding watch objects, find watch events the objects are 
> watching for, and remove interests in an event.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Reply via email to