Hi Guys, I changed it according to the idea of Bram, and tested it with my application that was consuming far to much memory (reproducable). It's now stable below 300 MB of Heap.
@Bram thanks for pointing to this, this really safed my day :-D regards, Achim 2012/10/23 Achim Nierbeck <bcanh...@googlemail.com>: > Hi Andreas, > > I did change this locally and I'm testing it right now. > Will give feedback later ... > > regards, Achim > > 2012/10/23 Andreas Pieber <anpie...@gmail.com>: >> Well, I can commit your proposed changes, but you would still have to build >> pax wicket locally and use the snapshots. When you confirm that the problem >> I really fixed I can push a release to Central within a Max of 8 hours... >> >> Let me know of I can help you in any way. >> >> Kind regards, Andreas >> >> On Oct 22, 2012 6:23 PM, "Bram Pouwelse" <b...@pouwelse.com> wrote: >>> >>> Hi Andreas, >>> >>> I've looked at the PropertyResolver at line 1447 a key is determined >>> to use in a ConcurrentHashMap [1]. This key is the application >>> returned by getApplication() after some testing I found out that >>> equals on application doesn't work by putting >>> getApplication().equals(getApplication()) in a sample application. >>> >>> If I remove the special case for equals, hashCode and toString from >>> the intercept method [2] getApplication().equals(getApplication()) >>> returns true as I would expect. I've created a similar HashMap in my >>> test application and a map with Application as a key seems to work >>> after the change. Didn't have a chance to do any real world test with >>> this. >>> >>> Thanks >>> >>> Bram >>> >>> [1] >>> https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/core/util/lang/PropertyResolver.java#L1447 >>> [2] >>> https://github.com/ops4j/org.ops4j.pax.wicket/blob/master/service/src/main/java/org/ops4j/pax/wicket/internal/PaxWicketApplicationFactory.java#L115 >>> >>> 2012/10/22 Andreas Pieber <anpie...@gmail.com>: >>> > well, it's quite possible that the CG lib does some quircks here. Has >>> > anyone already tried to set breakpoints into the PropertyResolver [1] >>> > checking what's exactly the problem? I'll start tomorrow morning by >>> > doing exactly this... >>> > >>> > If getApplication().equals(getApplication()) is really the problem >>> > (where did you find that code btw?) I might find a workaround for that >>> > case... let's see to nail down the problem first. >>> > >>> > Kind regards, >>> > Andreas >>> > >>> > [1] >>> > https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/core/util/lang/PropertyResolver.java >>> > >>> > On Mon, Oct 22, 2012 at 5:07 PM, Achim Nierbeck >>> > <bcanh...@googlemail.com> wrote: >>> >> Oh, one more, >>> >> >>> >> after running a Component Report i got the following info about it: >>> >> >>> >> >>> >> >>> >> Empty Collections >>> >> >>> >> >>> >> Detected the following empty collections: >>> >> •6.482.518 instances of java.util.concurrent.ConcurrentHashMap$Segment >>> >> retain >= 829.762.448 bytes. >>> >> >>> >> >>> >> Collection Fill Ratios >>> >> >>> >> >>> >> Detected the following collections with fill ratios below 20%: >>> >> •432.156 instances of java.util.concurrent.ConcurrentHashMap retain >= >>> >> 1.018.329.768 bytes. >>> >> >>> >> Map Collision Ratios >>> >> >>> >> >>> >> Detected the following maps with collision ratios above 80%: >>> >> •1 instances of java.util.concurrent.ConcurrentHashMap retain >>> >> 1.038.046.920 bytes. >>> >> •1 instances of java.util.concurrent.ConcurrentHashMap$Segment retain >>> >> 296 bytes. >>> >> >>> >> I haven't found the root cause of it, but somehow I have the >>> >> impression this might be an issue of Pax-Wicket? >>> >> >>> >> btw. I'm using Pax-Wicket in Version 1.0.2 >>> >> >>> >> regards, Achim >>> >> >>> >> >>> >> 2012/10/22 Achim Nierbeck <bcanh...@googlemail.com>: >>> >>> Here a little update to this, cause today my application did run into >>> >>> an OOM due to this (with 1GB Heap) >>> >>> The current HeapDump shows me >>> >>> >>> >>> That the wicket PropertyResolver uses about 1GB Ram, from those are >>> >>> about 62MB for >>> >>> >>> >>> >>> >>> ------------------------------------------------------------------------------------------------------------------ >>> >>> ref >>> >>> |CGLIB$CALLBACK_0|org.ops4j.pax.wicket.internal.PaxWicketApplicationFactory$WebApplicationWrapper >>> >>> @ 0xf2b693d0 >>> >>> >>> >>> ------------------------------------------------------------------------------------------------------------------ >>> >>> >>> >>> I guess those are basically the session, looks OK right now. >>> >>> But the rest is consumed by about 260000 ConcurrentHashMap Entries. >>> >>> >>> >>> For example: >>> >>> >>> >>> Type|Name |Value >>> >>> >>> >>> ------------------------------------------------------------------------------------------------------------------ >>> >>> ref >>> >>> |CGLIB$CALLBACK_0|org.ops4j.pax.wicket.internal.PaxWicketApplicationFactory$WebApplicationWrapper >>> >>> @ 0xc1fa0250 >>> >>> >>> >>> ------------------------------------------------------------------------------------------------------------------ >>> >>> >>> >>> I don't know how to say this, but it seems awfully wrong right now ... >>> >>> >>> >>> regards, Achim >>> >>> >>> >>> 2012/10/22 Achim Nierbeck <bcanh...@googlemail.com>: >>> >>>> Hi, >>> >>>> >>> >>>> I've seen the exact thing but didn't have the time (yet) to get a >>> >>>> hold of it. >>> >>>> But since it's mostly Wicket classes involved I had the impression >>> >>>> it's wicket itself >>> >>>> that does this. >>> >>>> To prove something like it, I wanted to create an example which would >>> >>>> work >>> >>>> in both world (pax-wicket and wicket) but due to lack of time I >>> >>>> wasn't able to >>> >>>> get to it. >>> >>>> >>> >>>> But since I'm not the only one I'd guess this is something worthy to >>> >>>> investigate :) >>> >>>> My next test would have been to switch to Wicket 6 (pax-wicket 2.0) >>> >>>> >>> >>>> regards, Achim >>> >>>> >>> >>>> 2012/10/22 Bram Pouwelse <b...@pouwelse.com>: >>> >>>>> Hi, >>> >>>>> >>> >>>>> I'm working on an application that's using Pax Wicket (version >>> >>>>> 1.1.0). >>> >>>>> Because the application is using more memory than expected I'm >>> >>>>> running >>> >>>>> some tests and analysing heap dumps for a few days now. >>> >>>>> >>> >>>>> While analysing the heap of my "weekend test" I've found this at the >>> >>>>> top of the Pax Wicket bundle class loader at the top of the >>> >>>>> dominator >>> >>>>> tree, seems to me that the PropertyResolver is creating new >>> >>>>> DefaultClassCache instances all the time but I don't understand why. >>> >>>>> >>> >>>>> Below I've pasted a few selections from Eclipse Memory Analyzer: >>> >>>>> >>> >>>>> >>> >>>>> Dominator tree: >>> >>>>> >>> >>>>> Class Name >>> >>>>> | Shallow Heap | Retained Heap | >>> >>>>> Percentage >>> >>>>> >>> >>>>> ----------------------------------------------------------------------------------------------------------------------------------------------------- >>> >>>>> org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5 @ >>> >>>>> 0xc123ee58 | 88 | 643,602,288 | >>> >>>>> 89.39% >>> >>>>> |- java.util.Vector @ 0xc1252208 >>> >>>>> | 32 | 643,566,800 | >>> >>>>> 89.38% >>> >>>>> | '- java.lang.Object[1280] @ 0xc2445ee8 >>> >>>>> | 5,136 | 643,566,768 | >>> >>>>> 89.38% >>> >>>>> | |- class org.apache.wicket.util.lang.PropertyResolver @ >>> >>>>> 0xb9b5d330 | 32 | >>> >>>>> 643,420,472 | 89.36% * >>> >>>>> | | '- java.util.concurrent.ConcurrentHashMap @ 0xc2962bf8 >>> >>>>> | 48 | 643,420,440 | >>> >>>>> 89.36% >>> >>>>> | | '- java.util.concurrent.ConcurrentHashMap$Segment[16] @ >>> >>>>> 0xc2962c28 | 80 | 643,420,392 >>> >>>>> | >>> >>>>> 89.36% >>> >>>>> | | |- java.util.concurrent.ConcurrentHashMap$Segment @ >>> >>>>> 0xc2963098 | 40 | 643,418,872 >>> >>>>> | >>> >>>>> 89.36% ** >>> >>>>> | | | |- >>> >>>>> java.util.concurrent.ConcurrentHashMap$HashEntry[262144] @ >>> >>>>> 0xd8674190 >>> >>>>> | 1,048,592 | 643,418,768 | 89.36% >>> >>>>> | | | | '- >>> >>>>> java.util.concurrent.ConcurrentHashMap$HashEntry @ 0xea9687a8 >>> >>>>> | 32 | 642,370,176 | 89.22% >>> >>>>> | | | | |- >>> >>>>> java.util.concurrent.ConcurrentHashMap$HashEntry @ 0xea967a28 >>> >>>>> | 32 | 642,366,720 | 89.22% >>> >>>>> | | | | | |- >>> >>>>> java.util.concurrent.ConcurrentHashMap$HashEntry @ 0xea966ca8 >>> >>>>> | 32 | 642,363,264 | 89.22% *** >>> >>>>> | | | | | |- >>> >>>>> org.apache.wicket.util.lang.PropertyResolver$DefaultClassCache @ >>> >>>>> 0xea967398| 16 | 3,424 | 0.00% >>> >>>>> | | | | | '- Total: 2 entries >>> >>>>> | | | >>> >>>>> | | | | |- >>> >>>>> org.apache.wicket.util.lang.PropertyResolver$DefaultClassCache @ >>> >>>>> 0xea968118 | 16 | 3,424 | 0.00% >>> >>>>> | | | | '- Total: 2 entries >>> >>>>> | | | >>> >>>>> >>> >>>>> ----------------------------------------------------------------------------------------------------------------------------------------------------- >>> >>>>> >>> >>>>> * class org.apache.wicket.util.lang.PropertyResolver @ 0xb9b5d330 >>> >>>>> [statics]: >>> >>>>> Type|Name |Value >>> >>>>> >>> >>>>> --------------------------------------------------------------------------------------------- >>> >>>>> ref |SET |set >>> >>>>> ref |IS |is >>> >>>>> ref |GET |get >>> >>>>> ref >>> >>>>> |applicationToClassesToGetAndSetters|java.util.concurrent.ConcurrentHashMap >>> >>>>> @ 0xc2962bf8 >>> >>>>> int |RESOLVE_CLASS |2 >>> >>>>> int |CREATE_NEW_VALUE |1 >>> >>>>> int |RETURN_NULL |0 >>> >>>>> ref |log >>> >>>>> |org.ops4j.pax.logging.slf4j.Slf4jLogger @ 0xc2972ba0 >>> >>>>> >>> >>>>> --------------------------------------------------------------------------------------------- >>> >>>>> >>> >>>>> ** java.util.concurrent.ConcurrentHashMap$HashEntry[262144] @ >>> >>>>> 0xd8674190 [attributes] >>> >>>>> Type |Name |Value >>> >>>>> >>> >>>>> -------------------------------------------------------------------------------------- >>> >>>>> float|loadFactor|0.75 >>> >>>>> ref |table >>> >>>>> |java.util.concurrent.ConcurrentHashMap$HashEntry[262144] @ >>> >>>>> 0xd8674190 >>> >>>>> int |threshold |196608 >>> >>>>> int |modCount |185871 >>> >>>>> int |count |185871 >>> >>>>> ref |sync >>> >>>>> |java.util.concurrent.locks.ReentrantLock$NonfairSync >>> >>>>> @ 0xc29630c0 >>> >>>>> >>> >>>>> -------------------------------------------------------------------------------------- >>> >>>>> >>> >>>>> >>> >>>>> *** java.util.concurrent.ConcurrentHashMap$HashEntry @ 0xea966ca8 >>> >>>>> [attributes] >>> >>>>> Type|Name |Value >>> >>>>> >>> >>>>> --------------------------------------------------------------------------------------------------- >>> >>>>> ref |next |java.util.concurrent.ConcurrentHashMap$HashEntry @ >>> >>>>> 0xea965f28 >>> >>>>> ref >>> >>>>> |value|org.apache.wicket.util.lang.PropertyResolver$DefaultClassCache >>> >>>>> @ 0xea966618 >>> >>>>> int |hash |1234246985 >>> >>>>> ref |key >>> >>>>> |nl.ditp.fabuland.core.internal.WicketApplication$$EnhancerByCGLIB$$4188d86a >>> >>>>> @ 0xc22bcc88 >>> >>>>> >>> >>>>> --------------------------------------------------------------------------------------------------- >>> >>>>> >>> >>>>> >>> >>>>> Is this caused by a coding error in the application or a bug in >>> >>>>> Wicket >>> >>>>> / Pax Wicket? >>> >>>>> >>> >>>>> Thanks, >>> >>>>> >>> >>>>> Bram Pouwelse >>> >>>>> >>> >>>>> _______________________________________________ >>> >>>>> general mailing list >>> >>>>> general@lists.ops4j.org >>> >>>>> http://lists.ops4j.org/mailman/listinfo/general >>> >>>> >>> >>>> >>> >>>> >>> >>>> -- >>> >>>> >>> >>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC >>> >>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> >>> >>>> Committer & Project Lead >>> >>>> OPS4J Pax for Vaadin >>> >>>> <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & >>> >>>> Project >>> >>>> Lead >>> >>>> blog <http://notizblog.nierbeck.de/> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> >>> >>> >>> Apache Karaf <http://karaf.apache.org/> Committer & PMC >>> >>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> >>> >>> Committer & Project Lead >>> >>> OPS4J Pax for Vaadin >>> >>> <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project >>> >>> Lead >>> >>> blog <http://notizblog.nierbeck.de/> >>> >> >>> >> >>> >> >>> >> -- >>> >> >>> >> Apache Karaf <http://karaf.apache.org/> Committer & PMC >>> >> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> >>> >> Committer & Project Lead >>> >> OPS4J Pax for Vaadin >>> >> <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project >>> >> Lead >>> >> blog <http://notizblog.nierbeck.de/> >>> >> >>> >> _______________________________________________ >>> >> general mailing list >>> >> general@lists.ops4j.org >>> >> http://lists.ops4j.org/mailman/listinfo/general >>> > >>> > _______________________________________________ >>> > general mailing list >>> > general@lists.ops4j.org >>> > http://lists.ops4j.org/mailman/listinfo/general >>> >>> _______________________________________________ >>> general mailing list >>> general@lists.ops4j.org >>> http://lists.ops4j.org/mailman/listinfo/general >> >> >> _______________________________________________ >> general mailing list >> general@lists.ops4j.org >> http://lists.ops4j.org/mailman/listinfo/general >> > > > > -- > > Apache Karaf <http://karaf.apache.org/> Committer & PMC > OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> > Committer & Project Lead > OPS4J Pax for Vaadin > <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project > Lead > blog <http://notizblog.nierbeck.de/> -- Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead OPS4J Pax for Vaadin <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project Lead blog <http://notizblog.nierbeck.de/> _______________________________________________ general mailing list general@lists.ops4j.org http://lists.ops4j.org/mailman/listinfo/general
