curator-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [1/3] curator git commit: Add note to explain why service providers should be cached/reused
Date Mon, 08 Feb 2016 18:21:54 GMT
Repository: curator
Updated Branches:
  refs/heads/CURATOR-3.0 0ed6f662c -> 4c92edbc1

Add note to explain why service providers should be cached/reused

Since NamespaceWatchers cannot be removed in Zookeeper 3.4.x, anyone
using the service discovery recipe in Curator 2.x should cache each
service provider they create and reuse it for subsequent calls to that


Branch: refs/heads/CURATOR-3.0
Commit: 0823ce67791ffeb49e2d63a02e467bd3b72cda05
Parents: 45332f3
Author: Joe Littlejohn <>
Authored: Tue Jan 12 13:23:20 2016 +0000
Committer: Joe Littlejohn <>
Committed: Tue Jan 12 13:23:20 2016 +0000

 curator-x-discovery/src/site/confluence/index.confluence | 4 ++++
 1 file changed, 4 insertions(+)
diff --git a/curator-x-discovery/src/site/confluence/index.confluence b/curator-x-discovery/src/site/confluence/index.confluence
index 2a92782..22a8875 100644
--- a/curator-x-discovery/src/site/confluence/index.confluence
+++ b/curator-x-discovery/src/site/confluence/index.confluence
@@ -55,6 +55,10 @@ Returns:
 the instance to use
+*Note:* When using Curator 2.x (Zookeeper 3.4.x) it's essential that service provider objects
are cached by your application and reused.
+Since the internal NamespaceWatcher objects added by the service provider cannot be removed
in Zookeeper 3.4.x, creating a fresh service
+provider for each call to the same service will eventually exhaust the memory of the JVM.
 h3. ServiceDiscovery
 In order to allocate a ServiceProvider, you must have a ServiceDiscovery. It is created by
a {{ServiceDiscoveryBuilder}}.

View raw message