perfect! I just want to get a second feedback from Bram. If he also
confirms the trick working I'll commit and release PaxWicket 1.1.1
tonight.

Thank you very much for discovering and testing this one!

Kind regards,
Andreas

On Tue, Oct 23, 2012 at 5:03 PM, Achim Nierbeck <[email protected]> wrote:
> 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 <[email protected]>:
>> 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 <[email protected]>:
>>> 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" <[email protected]> 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 <[email protected]>:
>>>> > 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
>>>>
>>>> _______________________________________________
>>>> general mailing list
>>>> [email protected]
>>>> http://lists.ops4j.org/mailman/listinfo/general
>>>
>>>
>>> _______________________________________________
>>> 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/>
>
> _______________________________________________
> general mailing list
> [email protected]
> http://lists.ops4j.org/mailman/listinfo/general

_______________________________________________
general mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/general

Reply via email to