| commit | 5bf8cf1a7782b04e540e18188bd499f21bf90562 | [log] [tgz] |
|---|---|---|
| author | Alexander A. Strelets <streletsaa@gmail.com> | Mon Jul 08 17:22:15 2019 -0700 |
| committer | Michael Han <hanm@apache.org> | Mon Jul 08 17:22:15 2019 -0700 |
| tree | 4e3d4cdcc9329e79af66de244983d38c0d30cb10 | |
| parent | 4a5d596105d621ed805d75dd352a382db8d8a57a [diff] |
ZOOKEEPER-2894: Memory and completions leak on zookeeper_close If I call `zookeeper_close()` when the call-stack does not pass through any of zookeeper mechanics (for example, some of completion handler called back by zookeeper) the following happens: 1. If there are requests waiting for responses in `zh.sent_requests` queue, they all are removed from this queue and each of them is "completed" with personal fake response having status `ZCLOSING`. Such fake responses are put into `zh.completions_to_process` queue. It's Ok 2. But then, `zh.completions_to_process` queue is left unhandled. **Neither completion callbacks are called, nor dynamic memory allocated for fake responses is freed** 3. Different structures within `zh` are dismissed and finally `zh` is freed Consequently we have a tiny **memory leak** and, which is much more important, **completions leak**. I.e. completions are not called at all. This is not the case if I call `zookeeper_close()` when the call-stack does pass through some of zookeeper mechanics. Here, zookeeper client handles completions properly. Proposed changes remove this defects. For more details see: https://issues.apache.org/jira/browse/ZOOKEEPER-2894 Author: Alexander A. Strelets <streletsaa@gmail.com> Reviewers: Enrico Olivelli <eolivelli@gmail.com>, Michael Han <hanm@apache.org> Closes #1000 from xoiss/ZOOKEEPER-2894
For the latest information about ZooKeeper, please visit our website at:
and our wiki, at:
https://cwiki.apache.org/confluence/display/ZOOKEEPER
Full documentation for this release can also be found in docs/index.html
Packaging/release artifacts - Maven
A buildable tarball is located under zookeeper/target/ directory The artifacts for the modules are uploaded to maven central.
Packaging/release artifacts - Ant
The release artifact contains the following jar file at the toplevel:
zookeeper-.jar - legacy jar file which contains all classes and source files. Prior to version 3.3.0 this was the only jar file available. It has the benefit of having the source included (for debugging purposes) however is also larger as a result
The release artifact contains the following jar files in “dist-maven” directory:
zookeeper-.jar - bin (binary) jar - contains only class (.class) files zookeeper--sources.jar - contains only src (.java) files zookeeper--javadoc.jar - contains only javadoc files
These bin/src/javadoc jars were added specifically to support Maven/Ivy which have the ability to pull these down automatically as part of your build process. The content of the legacy jar and the bin+sources jar are the same.
As of version 3.3.0 bin/sources/javadoc jars contained in dist-maven directory are deployed to the Apache Maven repository after the release has been accepted by Apache: http://people.apache.org/repo/m2-ibiblio-rsync-repository/