OK, this [1] should do it. WDYT? Out with it?

Kind regards,
Andreas

[1] 
https://github.com/ops4j/org.ops4j.pax.wicket/commit/a2a103355e6c480864dcf1bd748b197fe695b0db

On Tue, Oct 23, 2012 at 7:16 PM, Bram Pouwelse <b...@pouwelse.com> wrote:
> Hi Andreas,
>
> The fix seems to work, the only concern I have is that this may cause
> exceptions in a case where a custom property is set on the application
> in the application factory. This property would not be set by Pax
> Wicket when the "enhanced" version of the application is created.  But
> even without the fix this would cause some unexpected behaviour.
>
> Thanks!
>
> Kind regards,
> Bram
>
>
> 2012/10/23 Andreas Pieber <anpie...@gmail.com>:
>> 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 <bcanh...@googlemail.com> 
>> 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 <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
>>
>> _______________________________________________
>> 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

Reply via email to