memory leak in PopupViewImpl #823
Comments
|
Just curious... why not configure popupPresenters as singletons? |
gerrit-ovirt-org
pushed a commit
to oVirt/ovirt-engine
that referenced
this issue
Jun 14, 2017
We encountered a fairly large memory leak in the latest
version of GWT-P. All GWT-P popups have a resize handler
attached to them, but this handler lives at window scope
and never lets go. Therefore, every popup is completely
leaked when closed.
However, luckily, the method in GWT-P that sets up this
handler has a hook/template method for disabling the addition
of the handler:
if (repositionOnWindowResize()) {
Window.addResizeHandler(new ResizeHandler() ...
We simply overload repositionOnWindowResize() to always
return false and the leak is worked around.
See: ArcBees/GWTP#823
Change-Id: I4e6d4da68e3f50f5863f4e33e62581b97e36dd2d
Signed-off-by: Greg Sheremeta <gshereme@redhat.com>
gerrit-ovirt-org
pushed a commit
to oVirt/ovirt-engine
that referenced
this issue
Jul 4, 2017
Change-Id: Ic12c323f2b4e9428e090b50a9b5030389bbbdb76 Related-To: ArcBees/GWTP#823 Signed-off-by: Vojtech Szocs <vszocs@redhat.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi,
GWTP/gwtp-core/gwtp-mvp-client/src/main/java/com/gwtplatform/mvp/client/PopupViewImpl.java
Line 70 in 8620f6b
We have some very large non-singleton popups in our application, and when we upgraded GWT-P and pulled in this code, the application started leaking a ton of memory and slowing down. Window lives forever, and popups never get GC'd.
Overloading repositionOnWindowResize to return false prevents the addition of the resize handler, which works us around the issue.
The text was updated successfully, but these errors were encountered: