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 <[email protected]> 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 <[email protected]>: >> 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 <[email protected]>: >>> 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 <[email protected]>: >>>> 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 >>>> [email protected] >>>> 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 > [email protected] > http://lists.ops4j.org/mailman/listinfo/general _______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
