Never seems to release bound objects, even after they have been rendered.

          [JENKINS-16341] Memory leak in createJavaScriptProxy

          Code changed in jenkins
          User: Jesse Glick
          Path:
          test/src/main/java/org/jvnet/hudson/test/MemoryAssert.java
          test/src/test/java/lib/layout/RenderOnDemandTest.java
          http://jenkins-ci.org/commit/jenkins/f178f0cef4bf86c5fb4cf4a2c40afce4c2b43410
          Log:
          JENKINS-16341 INSANE testing shows that a RenderOnDemandClosure binding adds about 380k, with or wothout 08efdf5.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: test/src/main/java/org/jvnet/hudson/test/MemoryAssert.java test/src/test/java/lib/layout/RenderOnDemandTest.java http://jenkins-ci.org/commit/jenkins/f178f0cef4bf86c5fb4cf4a2c40afce4c2b43410 Log: JENKINS-16341 INSANE testing shows that a RenderOnDemandClosure binding adds about 380k, with or wothout 08efdf5.

          dogfood added a comment -

          Integrated in jenkins_main_trunk #2193
          JENKINS-16341 INSANE testing shows that a RenderOnDemandClosure binding adds about 380k, with or wothout 08efdf5. (Revision f178f0cef4bf86c5fb4cf4a2c40afce4c2b43410)

          Result = SUCCESS
          Jesse Glick : f178f0cef4bf86c5fb4cf4a2c40afce4c2b43410
          Files :

          • test/src/test/java/lib/layout/RenderOnDemandTest.java
          • test/src/main/java/org/jvnet/hudson/test/MemoryAssert.java

          dogfood added a comment - Integrated in jenkins_main_trunk #2193 JENKINS-16341 INSANE testing shows that a RenderOnDemandClosure binding adds about 380k, with or wothout 08efdf5. (Revision f178f0cef4bf86c5fb4cf4a2c40afce4c2b43410) Result = SUCCESS Jesse Glick : f178f0cef4bf86c5fb4cf4a2c40afce4c2b43410 Files : test/src/test/java/lib/layout/RenderOnDemandTest.java test/src/main/java/org/jvnet/hudson/test/MemoryAssert.java

          The other thing that helps is to make proxies have well-known URLs. If the fragment rendered on-demand do not depend on the request context (or if it can be recreated from future requests), then there won't be any need to keep session-scoped objects.

          Some of the core tags might very well fit with this, since they explicitly lists variables that get captured.

          But otherwise I agree that ping is the only way I can think of.

          Kohsuke Kawaguchi added a comment - The other thing that helps is to make proxies have well-known URLs. If the fragment rendered on-demand do not depend on the request context (or if it can be recreated from future requests), then there won't be any need to keep session-scoped objects. Some of the core tags might very well fit with this, since they explicitly lists variables that get captured. But otherwise I agree that ping is the only way I can think of.

          Jesse Glick added a comment -

          RenderOnDemandClosure cannot be done this way AFAICT, since its variables are of unrestricted type. Nor can other uses of @JavaScriptMethod, unless we can somehow establish that the receiver object is a singleton.

          Jesse Glick added a comment - RenderOnDemandClosure cannot be done this way AFAICT, since its variables are of unrestricted type. Nor can other uses of @JavaScriptMethod , unless we can somehow establish that the receiver object is a singleton.

          Jesse Glick added a comment -

          @kohsuke points out that WithWellKnownURL may be used for singleton objects with a @JavaScriptMethod to avoid this bug. That is no help for <l:renderOnDemand>.

          Jesse Glick added a comment - @kohsuke points out that WithWellKnownURL may be used for singleton objects with a @JavaScriptMethod to avoid this bug. That is no help for <l:renderOnDemand> .

          Jesse Glick added a comment -

          Also users of ProgressiveRendering would be affected. Though this class implements its own ping-based timeout, returning "canceled" from news(), that does not also call Bound.release. The only fix for that, other than a general fix of this issue, would be to make ProgressiveRendering implement WithWellKnownURL, adding ongoing renders to a map keyed by random UUID and deleting them after sending back a cancel status.

          Jesse Glick added a comment - Also users of ProgressiveRendering would be affected. Though this class implements its own ping-based timeout, returning "canceled" from news() , that does not also call Bound.release . The only fix for that, other than a general fix of this issue, would be to make ProgressiveRendering implement WithWellKnownURL , adding ongoing renders to a map keyed by random UUID and deleting them after sending back a cancel status.

          Code changed in jenkins
          User: Jesse Glick
          Path:
          changelog.html
          core/src/main/java/hudson/widgets/RenderOnDemandClosure.java
          http://jenkins-ci.org/commit/jenkins/47d6811666d5eb20bc491ea6ad4bda8f54f83be4
          Log:
          JENKINS-16341 Amelioration of memory leak by at least interning some heavily redundant strings.
          (cherry picked from commit 08efdf5d3ab962cfd4c4c489266592fe1db7df8e)

          Conflicts:
          changelog.html
          core/src/main/java/hudson/widgets/RenderOnDemandClosure.java

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: changelog.html core/src/main/java/hudson/widgets/RenderOnDemandClosure.java http://jenkins-ci.org/commit/jenkins/47d6811666d5eb20bc491ea6ad4bda8f54f83be4 Log: JENKINS-16341 Amelioration of memory leak by at least interning some heavily redundant strings. (cherry picked from commit 08efdf5d3ab962cfd4c4c489266592fe1db7df8e) Conflicts: changelog.html core/src/main/java/hudson/widgets/RenderOnDemandClosure.java

          Code changed in jenkins
          User: Jesse Glick
          Path:
          test/src/main/java/org/jvnet/hudson/test/MemoryAssert.java
          test/src/test/java/lib/layout/RenderOnDemandTest.java
          http://jenkins-ci.org/commit/jenkins/5fe628076b6ee03f57bfa0767c6d0775aeafac1e
          Log:
          JENKINS-16341 INSANE testing shows that a RenderOnDemandClosure binding adds about 380k, with or wothout 08efdf5.(cherry picked from commit f178f0cef4bf86c5fb4cf4a2c40afce4c2b43410)

          Conflicts:
          test/src/main/java/org/jvnet/hudson/test/MemoryAssert.java
          test/src/test/java/lib/layout/RenderOnDemandTest.java

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: test/src/main/java/org/jvnet/hudson/test/MemoryAssert.java test/src/test/java/lib/layout/RenderOnDemandTest.java http://jenkins-ci.org/commit/jenkins/5fe628076b6ee03f57bfa0767c6d0775aeafac1e Log: JENKINS-16341 INSANE testing shows that a RenderOnDemandClosure binding adds about 380k, with or wothout 08efdf5.(cherry picked from commit f178f0cef4bf86c5fb4cf4a2c40afce4c2b43410) Conflicts: test/src/main/java/org/jvnet/hudson/test/MemoryAssert.java test/src/test/java/lib/layout/RenderOnDemandTest.java

          Jesse Glick added a comment -

          There is BoundObjectTable.releaseMe but it does not seem to be called by anything. Nor does its implementation make sense: you would expect it to be static and actually use the BoundObjectTable instance found in the Ancestor.

          Jesse Glick added a comment - There is BoundObjectTable.releaseMe but it does not seem to be called by anything. Nor does its implementation make sense: you would expect it to be static and actually use the BoundObjectTable instance found in the Ancestor .

          Code changed in jenkins
          User: Jesse Glick
          Path:
          test/src/main/java/org/jvnet/hudson/test/MemoryAssert.java
          http://jenkins-ci.org/commit/jenkins-test-harness/5eaf5f7459cf0bda87d9023f4c3f6080a073cbf6
          Log:
          JENKINS-16341 INSANE testing shows that a RenderOnDemandClosure binding adds about 380k, with or wothout 08efdf5.
          Originally-Committed-As: f178f0cef4bf86c5fb4cf4a2c40afce4c2b43410

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: test/src/main/java/org/jvnet/hudson/test/MemoryAssert.java http://jenkins-ci.org/commit/jenkins-test-harness/5eaf5f7459cf0bda87d9023f4c3f6080a073cbf6 Log: JENKINS-16341 INSANE testing shows that a RenderOnDemandClosure binding adds about 380k, with or wothout 08efdf5. Originally-Committed-As: f178f0cef4bf86c5fb4cf4a2c40afce4c2b43410

            jglick Jesse Glick
            jglick Jesse Glick
            Votes:
            0 Vote for this issue
            Watchers:
            12 Start watching this issue

              Created:
              Updated: