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
