Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 350927

Summary:	ZooKeeperLock sets too many watches
Product:	z_Archived	Reporter:	Gunnar Wagenknecht <gunnar>
Component:	gyrex	Assignee:	Gunnar Wagenknecht <gunnar>
Status:	RESOLVED FIXED	QA Contact:
Severity:	critical
Priority:	P3	CC:	andreas.mihm
Version:	unspecified
Target Milestone:	---
Hardware:	All
OS:	All
Whiteboard:

Description Gunnar Wagenknecht

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

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.