Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 350927 - ZooKeeperLock sets too many watches
Summary: ZooKeeperLock sets too many watches
Status: RESOLVED FIXED
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: gyrex (show other bugs)
Version: unspecified   Edit
Hardware: All All
: P3 critical (vote)
Target Milestone: ---   Edit
Assignee: Gunnar Wagenknecht CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-07-01 08:23 EDT by Gunnar Wagenknecht CLA
Modified: 2018-03-19 11:59 EDT (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Gunnar Wagenknecht CLA 2011-07-01 08:23:44 EDT 
ZooKeeper does not support disposing/removing of watches. This leads to many, many (millions) WaitForDeletionMonitor watches recoreded in a HashMap within ZooKeeper. The memory analyzer says ~70% of heap.

Our usage patter might be wrong, though. We set an exists watch in order to wait for the previous lock owner node to be deleted within a certain timeout. The watch contains a CountDownLatch which allows to sleep until the watch triggers or the timeout triggers. In the latter case we really need to remove the watch from ZooKeeper but this is not possible (ZOOKEEPER-442).

The current implementation also leaves the watch in place even if exists returns false (ZOOKEEPER-442).

A workaround would be to not set a watch at all and just sleep for a while and check in a loop. However, that would increase the read traffic to ZooKeeper dramatically.

(https://issues.apache.org/jira/browse/ZOOKEEPER-442)
Comment 1 Gunnar Wagenknecht CLA 2011-07-01 09:50:52 EDT 
We now no longer create WaitForDeletionMonitor watches but "pool" ZooKeeper regularly. Scalability is a concern, though. We need to revisit once ZOOKEEPER-442 lands.