[
https://issues.apache.org/jira/browse/CONNECTORS-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14250394#comment-14250394
]
Karl Wright commented on CONNECTORS-1123:
-----------------------------------------
r1646317 (trunk)
r1646318 (release-2.0-branch)
r1646323 (dev_1x)
r1646324 (release-1.8-branch)
> ZK node leak
> ------------
>
> Key: CONNECTORS-1123
> URL: https://issues.apache.org/jira/browse/CONNECTORS-1123
> Project: ManifoldCF
> Issue Type: Bug
> Components: Framework core
> Affects Versions: ManifoldCF 1.8
> Environment: 4-node manifold cluster, 3-node ZK ensemble for
> coordination and configuration management
> Reporter: Aeham Abushwashi
> Assignee: Karl Wright
> Fix For: ManifoldCF 1.8, ManifoldCF 2.0
>
>
> Looking at the stats of the zookeeper cluster, I was struck by the very high
> node count reported by the ZK stat command which shows there being just over
> 3.84 MILLION nodes. The number keeps rising as long as the manifold nodes are
> running. Stopping manifold does NOT reduce the number significantly, nor does
> restarting the ZK ensemble.
> The ZK ensemble was initialised around 20 days ago. Manifold has been running
> on and off on this cluster since that time.
> The flat nature of the manifold node structure in ZK (at least in the dev_1x
> branch) makes it difficult to identify node names but after tweaking the
> jute.maxbuffer parameter on the client, I was able to get a list of all
> nodes. There's a huge number of nodes with the name pattern
> org.apache.manifoldcf.locks-<Output Connection>:<Hash>.
> I could see using this node name pattern used in
> IncrementalIngester#documentDeleteMultiple and
> IncrementalIngester#documentRemoveMultiple. However, I'm not expecting any
> deletions in the tests I've been running recently - perhaps this is part of
> the duplicate deletion logic which came up in an email thread earlier today?
> or maybe there's another code path I missed entirely and which creates nodes
> with names like the above.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
