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]
> > > >
> > > >
> > >
> >
>
