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