gwt memory leak ?

[khiem nguyen]

hi
i have an webapp, using request-factory with eclipse-link jpa &  ValueProxy,
EntitiyManagers are  created & closed at request level  ( manually)
after a while  i get OutOfMemoryException, testing with over a hundred of clients ( browser refresh to query a webpage, whic invoke jpa to get db from database), i can reproduce the issue. with jconsole & jhat i get this output:


409522 instances of class com.google.gwt.core.client.impl.WeakMapping$IdentityWeakReference
250932 instances of class com.google.gwt.autobean.server.ProxyAutoBean
250932 instances of class com.google.gwt.autobean.server.ShimHandler
103770 instances of class com.google.gwt.autobean.shared.impl.LazySplittable
92359 instances of class com.google.gwt.autobean.server.SimpleBeanHandler

is it normal in a scenario of < 10 users, < 10 entities involves & there're < 10000 db-rows ( for all entities) ?
there are also 6 EntityManagers so i think they are handled correctly.

any hints for this ?
thanx alot
khiem

[Thomas Broyer]

Yes: http://code.google.com/p/google-web-toolkit/issues/detail?id=6193

At the moment, because I haven't upgraded or GWT libraries for a while, we're having a copy of WeakMapping (from the first patchset in the proposed fix) in our sources, that happen to override GWT's one thanks to the order they appear in the classpath. The issue hasn't appeared again yet, but we're still only in the testing phase of our very first milestone.

That'd be great if you could test the proposed fix (to AutoBean rather than WeakMapping) and comment back with your feedback, as I cannot upgrade GWT for the time being.

[khiem nguyen]

hi Thomas
thanx for the quick answer.
sorry for being a noop here but i i dont seem to be able to apply the patch n2 & 4, since the package-structure of the source ( from

http://google-web-toolkit.googlecode.com/svn/trunk/ ) 

is not  the same as in release version. just replace the built gwt-user.jar gave me exception (requestfactory not found), it's also at different package compare to the released version.

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[khiem nguyen]

i checked out version 2.3 & patched it  manually (n1 & 2), recompile gwt & redeploy.

got this exception:

May 11, 2011 3:49:21 PM com.google.web.bindery.requestfactory.server.RequestFactoryServlet doPost
SEVERE: Unexpected error
java.lang.ClassCastException: java.lang.ref.WeakReference cannot be cast to com.google.web.bindery.autobean.shared.AutoBean
        at com.google.web.bindery.autobean.shared.AutoBeanUtils.getAutoBean(AutoBeanUtils.java:218)
        at com.google.web.bindery.autobean.shared.impl.AutoBeanCodexImpl.tryExtractSplittable(AutoBeanCodexImpl.java:600)
        at com.google.web.bindery.autobean.shared.impl.AutoBeanCodexImpl$CollectionCoder.extractSplittable(AutoBeanCodexImpl.java:173)
        at com.google.web.bindery.autobean.shared.impl.AbstractAutoBean.setProperty(AbstractAutoBean.java:277)
        at com.google.web.bindery.autobean.vm.impl.ProxyAutoBean.setProperty(ProxyAutoBean.java:226)
        at com.google.web.bindery.autobean.vm.impl.BeanMethod$3.invoke(BeanMethod.java:103)
        at com.google.web.bindery.autobean.vm.impl.SimpleBeanHandler.invoke(SimpleBeanHandler.java:46)
        at $Proxy7.setInvocationResults(Unknown Source)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at com.google.web.bindery.autobean.vm.impl.ShimHandler.invoke(ShimHandler.java:86)
        at $Proxy7.setInvocationResults(Unknown Source)
        at com.google.web.bindery.requestfactory.server.SimpleRequestProcessor.process(SimpleRequestProcessor.java:229)
        at com.google.web.bindery.requestfactory.server.SimpleRequestProcessor.process(SimpleRequestProcessor.java:125)
        at com.google.web.bindery.requestfactory.server.RequestFactoryServlet.doPost(RequestFactoryServlet.java:118)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)


what did i miss ?

thanx

[khiem nguyen]

i patched the released version 2.3.0 with the second patchset ( not the first one for WeakMap), refactored the code to use the new requestfactory package (which is now in gwt.web.bindary...), i dont get OutOfMemoryException anymore but the load test leads to jvm-crashed (with 100%cpu load).

anaylyse the dump:

412286 instances of class com.google.web.bindery.autobean.vm.impl.ProxyAutoBean
412286 instances of class com.google.web.bindery.autobean.vm.impl.ShimHandler
343638 instances of class com.google.gwt.core.client.impl.WeakMapping$IdentityWeakReference
279948 instances of class com.google.web.bindery.autobean.vm.impl.JsonSplittable
143060 instances of class $Proxy9
112000 instances of class org.json.JSONObject
106798 instances of class $Proxy8
86704 instances of class $Proxy25
78455 instances of class org.json.JSONArray
68648 instances of class com.google.web.bindery.autobean.vm.impl.SimpleBeanHandler
55446 instances of class org.eclipse.persistence.indirection.IndirectList
50428 instances of class $Proxy27
43352 instances of class $Proxy26
35434 instances of class com.google.web.bindery.autobean.shared.impl.AutoBeanCodexImpl$EncodeState
35433 instances of class com.google.web.bindery.autobean.shared.impl.SplittableList
29575 instances of class org.eclipse.persistence.internal.identitymaps.UnitOfWorkCacheKey


any hints ?

if i cannot manage to resolve this issue i may need to reimplement it with traditional rpc with dto

thanx

[khiem nguyen]

the patch just seem to slow down the leak but dont eliminate it, i make vm-dumps & observe the numbers of ProxyAutoBean, ShimHandler increases (thou slowlier than before the patch) & cannot be GCed. testing long enough will eat up the memory anyway.

it's strange that no one get this problem yet , how could that be ?

& will this issue will be resolved soon ?

thanx

[craftycoder]

I have this problem as well. In my case it's an Android project, so
with only 24MB to work with my app runs for about 5 minutes before it
explodes. RequestFactory is totally unusable for me at the moment. I'm
setting everything I can think of to null and still every bit of JSON
of the wire resides in WeakMapping HastMaps. Sad story. :(

[Thomas Broyer]

The fix has been committed, and is really, really simple so you should be able to use it without waiting for a new release. See bug report for the link to the commit (and diff).

[khiem nguyen]

grrrrrr, if the fix had come a bit earlier

have spent the last week to move the project back to rpc instead of rf after the test-patch doesnt work as expected
but i think i'll use RF again in the future, rpc & dto make me write much more code.


thanx

On Sun, May 22, 2011 at 3:49 AM, Thomas Broyer <t.br...@gmail.com> wrote:

The fix has been committed, and is really, really simple so you should be able to use it without waiting for a new release. See bug report for the link to the commit (and diff).

--

[Thomas Broyer]

On Sunday, May 22, 2011 12:29:51 PM UTC+2, khiem nguyen wrote:

grrrrrr, if the fix had come a bit earlier

have spent the last week to move the project back to rpc instead of rf after the test-patch doesnt work as expected
but i think i'll use RF again in the future, rpc & dto make me write much more code.

Too bad you didn't apply the "WeakMapping fix", even if not the proper fix for the issue (because it breaks the WeakMapping contract) it's a working temporary workaround, pending a (the) actual fix.

Hopefully you use a VCS and can simply/easily revert your recent changes.

[khiem nguyen]

in fact i did the WeakMapping fix & got  the class-cast exception (in previous post)

--