i remove the code "cursor.getId()" from Localizer.getCacheKey and deploy it
to the server.
No more memory leak detected. the server runs well for several days.
Great thanks to Johan.
2008/5/15 Quan Zhou <[EMAIL PROTECTED]>:
> Maybe you're right.
> Yesterday I deployed the application in a high load with a little fewer
> heapsize than the usual setting to see whether the same thing happened
> again,
> and now the heapsize usage increase little by little. the Full GC interval
> becomes shorter. I'm sure that several hours later.
> I deeply explore the cache key and value; as you said, some thing with same
> value but different key's store in the cache.
> like:
>
> first :
> woodPr_lab-com.wedomo.webgame.fbm3guo.wicket.reuse.ResourcePanel:resourcepanel-com.wedomo.webgame.fbm3guo.wicket.pages.map.MapSmall:4-zh_CN-null
> 产量：
> ironPr_lab-com.wedomo.webgame.fbm3guo.wicket.reuse.ResourcePanel:resourcepanel-com.wedomo.webgame.fbm3guo.wicket.pages.map.MapSmall:4-zh_CN-null
> 产量：
> cropPr_lab-com.wedomo.webgame.fbm3guo.wicket.reuse.ResourcePanel:resourcepanel-com.wedomo.webgame.fbm3guo.wicket.pages.map.MapSmall:4-zh_CN-null
> 产量：
>
> later:
> woodPr_lab-com.wedomo.webgame.fbm3guo.wicket.reuse.ResourcePanel:resourcepanel-com.wedomo.webgame.fbm3guo.wicket.pages.map.MapSmall:6-zh_CN-null
> 产量：
> ironPr_lab-com.wedomo.webgame.fbm3guo.wicket.reuse.ResourcePanel:resourcepanel-com.wedomo.webgame.fbm3guo.wicket.pages.map.MapSmall:6-zh_CN-null
> 产量：
> cropPr_lab-com.wedomo.webgame.fbm3guo.wicket.reuse.ResourcePanel:resourcepanel-com.wedomo.webgame.fbm3guo.wicket.pages.map.MapSmall:6-zh_CN-null
> 产量：
>
> the only difference is PageId . the source code of Locailzer.getCacheKey
> tells
> //
> for(Component cursor = component; cursor != null; cursor =
> cursor.getParent())
> {
> buffer.append("-").append(cursor.getClass().getName());
> buffer.append(":").append(cursor.getId());
> }
>
> so is the cursor.getId() useful when it represents a repeater? and whether
> i can remove it when it represents the page class?
> that would really reduce the cacheKey number I think.
>
> Johan, could you show me the code you fix with this problem please?
>
> Thanks for your great help!
>
>
>
>
>
> 2008/5/14 Johan Compagner <[EMAIL PROTECTED]>:
>
>> i fixed something in the localizer that it doesnt add the page id to the
>> cachekey string
>> that was your problem
>> everypage that was created also creates an localizer entry that is just
>> plain wrong.
>>
>> So the pageid is not in the path anymore.. i think this is what really
>> caused your constant growing cache
>>
>>
>> On Wed, May 14, 2008 at 5:04 PM, Quan Zhou <[EMAIL PROTECTED]> wrote:
>>
>> > Yes , it would be a bit slower. I'm going to make more test to see what
>> > havn't store in cache.
>> > Maybe i can caculate how many percents it effect my application
>> performance
>> > after i deploy it in a high load circumstance.
>> >
>> > I'm not sure about what you said about your fix for not including page.
>> > can you make it some clear? thanks very much.
>> >
>> >
>> > 2008/5/14 Johan Compagner <[EMAIL PROTECTED]>:
>> >
>> > > ok so you dont store the tested cacheKey 's that returned null..
>> > > so that could result in a bit slower access because it is tried to
>> > resolve
>> > > everytime
>> > >
>> > > I do think that my fix for not including the page is solving your real
>> > mem
>> > > leak problem
>> > >
>> > > johan
>> > >
>> > >
>> > > On Wed, May 14, 2008 at 2:03 PM, Quan Zhou <[EMAIL PROTECTED]>
>> wrote:
>> > >
>> > > > getResourceSettings().setLocalizer(new Localizer() {
>> > > > @Override
>> > > > public void putIntoCache(final String cacheKey,final
>> String
>> > > > string) {
>> > > > if (string != null && cacheKey!=null)
>> > > > super.putIntoCache(cacheKey, string);
>> > > > }
>> > > > });
>> > > >
>> > > >
>> > > >
>> > > > 2008/5/14 Johan Compagner <[EMAIL PROTECTED]>:
>> > > >
>> > > > > but what did you do there in that method?
>> > > > > nothing? you dont cache anything anymore?
>> > > > >
>> > > > > On Wed, May 14, 2008 at 10:29 AM, Quan Zhou <[EMAIL PROTECTED]
>> >
>> > > > wrote:
>> > > > >
>> > > > > > Hello everyone.
>> > > > > >
>> > > > > > I override Localizer.putIntoCache method. and it really reduce
>> the
>> > > > > > heapsize
>> > > > > > usage of Localizer.
>> > > > > >
>> > > > > > The application is more stable now although the key remains
>> large.
>> > > > > >
>> > > > > > Hope we can find a way to shorter the key length.
>> > > > > >
>> > > > > > thanks everyone.
>> > > > > >
>> > > > > > 2008/5/13 Eirik Rude <[EMAIL PROTECTED]>:
>> > > > > >
>> > > > > > >
>> > > > > > > A soft reference is very common for this type of thing. I
>> know
>> > > some
>> > > > of
>> > > > > > > ICU's
>> > > > > > > resources are stored this way.
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > Jonathan Locke wrote:
>> > > > > > > >
>> > > > > > > >
>> > > > > > > > maybe localizer should limit its size or use a soft
>> reference
>> > > > cache?
>> > > > > > > >
>> > > > > > > >
>> > > > > > > > Johan Compagner wrote:
>> > > > > > > >>
>> > > > > > > >> Can you really see what it holds?
>> > > > > > > >> Almost 2G in memory in localizer is extreme... Thats really
>> a
>> > > lot
>> > > > of
>> > > > > > > >> strings..
>> > > > > > > >> You could try to read that dump with yourkit if your
>> current
>> > one
>> > > > > > > >> doesnt show enough.
>> > > > > > > >>
>> > > > > > > >> On 5/9/08, Quan Zhou <[EMAIL PROTECTED]> wrote:
>> > > > > > > >>> Hello everyone.
>> > > > > > > >>>
>> > > > > > > >>> I recently develop my App use Wicket1.3.3. It's my first
>> time
>> > > to
>> > > > > use
>> > > > > > > >>> this
>> > > > > > > >>> framework and I feel it's really really a perfect
>> framework
>> > for
>> > > > me.
>> > > > > > > >>> My app support both Simplified Chinese , Traditional
>> Chinese,
>> > I
>> > > > > > > >>> implement
>> > > > > > > >>> this with Wicket i18n feature.
>> > > > > > > >>> With the load increasing these days, I found my app would
>> > > become
>> > > > > > very
>> > > > > > > >>> lag
>> > > > > > > >>> abount every 24 hours ,so that i would only restart it
>> > > > > > > >>> without any choice.
>> > > > > > > >>> when I found the lag, My log records many Exceptions like
>> :
>> > > > > > > >>> "after 1 minute the Pagemap null is still locked by:
>> > > > > > > >>> Thread[http-8080-321,5,main], giving
>> > > > > > > >>> up trying to get the page for path xxx"
>> > > > > > > >>>
>> > > > > > > >>> I check the JVM status with jstat -gc , It tells that the
>> > > > Heapsize
>> > > > > > is
>> > > > > > > >>> full
>> > > > > > > >>> even after full GC.
>> > > > > > > >>> My VM paraemter is "-Xms2000m -Xmx2000m
>> -XX:MaxNewSize=250m
>> > > > > > > >>> -XX:MaxPermSize=250m"
>> > > > > > > >>> My deploy server has 2*CPU and 4G memory, Redhat AS4 OS +
>> > > tomcat
>> > > > > > 6.0.
>> > > > > > > >>> There're 2000 sessions on the day while the timeout
>> threshold
>> > > is
>> > > > 15
>> > > > > > > >>> minutes.
>> > > > > > > >>> So i dump the whole heapsize with the command " jmap
>> > > > > > > >>> -dump:live,format=b,file=3.dump.hprof processid"
>> > > > > > > >>> and i truely get a 2G size dump files. I use SAP Memory
>> > Analyer
>> > > > to
>> > > > > > see
>> > > > > > > >>> what're stored in HeapMemory.
>> > > > > > > >>> and I found a strange number of Retained Heap usage:
>> > > > > > > >>> Classname
>> > > > > > > >>> ShallowHeap
>> > > > > > RetainHeap
>> > > > > > > >>> RetainedHeap%
>> > > > > > > >>> [EMAIL PROTECTED]
>> > > > > > > >>> 16
>> > > > > > > >>> 1,755,070,352 87.64%
>> > > > > > > >>>
>> [EMAIL PROTECTED]
>> > ..
>> > > > > > > >>> 48 1,755,070,336
>> > > > > > 87.69%
>> > > > > > > >>>
>> > > > [EMAIL PROTECTED]
>> > > > > ...
>> > > > > > > >>> 33,554,448
>> > > > > > > >>> 1,755,069,632
>> > 87.69%
>> > > > > > > >>> -
>> > > > > [EMAIL PROTECTED]
>> > > > > > > ...
>> > > > > > > >>> 24 3928
>> > > > > > > >>> 0.00%
>> > > > > > > >>> -
>> > > > > [EMAIL PROTECTED]
>> > > > > > > ...
>> > > > > > > >>> 24 3928
>> > > > > > > >>> 0.00%
>> > > > > > > >>> -
>> > > > > [EMAIL PROTECTED]
>> > > > > > > ...
>> > > > > > > >>> 24 3928
>> > > > > > > >>> 0.00%
>> > > > > > > >>> -
>> > > > > [EMAIL PROTECTED]
>> > > > > > > ...
>> > > > > > > >>> 24 3928
>> > > > > > > >>> 0.00%
>> > > > > > > >>> -
>> > > > > [EMAIL PROTECTED]
>> > > > > > > ...
>> > > > > > > >>> 24 3928
>> > > > > > > >>> 0.00%
>> > > > > > > >>> -
>> > > > > [EMAIL PROTECTED]
>> > > > > > > ...
>> > > > > > > >>> 24 3928
>> > > > > > > >>> 0.00%
>> > > > > > > >>> + 2,863,659 more...
>> > > > > > > >>>
>> > > > > > > >>> Is that means that the Localizer Object used most of the
>> heap
>> > > > size?
>> > > > > > > >>> or Is this number normal for Wicket App?
>> > > > > > > >>>
>> > > > > > > >>> I wonder whether I forget to release the memory by my
>> > mis-using
>> > > > of
>> > > > > > > i18n
>> > > > > > > >>> feature?
>> > > > > > > >>> Is there any attentions I must pay to when dealing with
>> > > > Localizer?
>> > > > > > > >>>
>> > > > > > > >>> This problem annoys me more the 2 weeks. I really need
>> some
>> > > > help.
>> > > > > > > Thanks
>> > > > > > > >>> .
>> > > > > > > >>>
>> > > > > > > >>
>> > > > > > > >>
>> > > > >
>> ---------------------------------------------------------------------
>> > > > > > > >> To unsubscribe, e-mail:
>> [EMAIL PROTECTED]
>> > > > > > > >> For additional commands, e-mail:
>> [EMAIL PROTECTED]
>> > > > > > > >>
>> > > > > > > >>
>> > > > > > > >>
>> > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > > > --
>> > > > > > > View this message in context:
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> http://www.nabble.com/Why-Localizer-Retained-so-many-heapsize--tp17142582p17199950.html
>> > > > > > > Sent from the Wicket - User mailing list archive at
>> Nabble.com.
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > >
>> ---------------------------------------------------------------------
>> > > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > > > > > > For additional commands, e-mail: [EMAIL PROTECTED]
>> > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
>
