yeah the current impl just generates the full path
This could be a problem if you have a lot of components in a repeater that
also hit the localizer..

the problem is that a key for a component X can return a different thing
then that same key for component Y..

So how to make those keys unique enough?

getParent().getClass().getName() + getParent().getId() +
getClass().getName() + getId() + getLocale() + getStyle() ??

Would that be unique enough?
The problem is that combination could be added to 2 different panels that
have there own properties
and then it that panel is the unique part...

But i just found a bit of leak, that is causing the problem of the first
email
The page was as far as i can see also added... Thats really wrong..
Then it would really grow and grow, but everybody should see this.. Weird..


johan


On Mon, May 12, 2008 at 11:44 AM, Iman Rahmatizadeh <
[EMAIL PROTECTED]> wrote:

> Is there any way to make getCacheKey() return smaller keys ? Those huge
> keys
> are consuming a lot of memory and also the equals/hashcode check on the
> key
> will take resources.
>
> On Mon, May 12, 2008 at 12:33 PM, Johan Compagner <[EMAIL PROTECTED]>
> wrote:
>
> > i guess you have a loads of null values somehow
> > Dont know why in your situation you have soo many of those.
> >
> > What you could do is this in the init of your application:
> >
> > Localizer localizer = new Localizer()
> > {
> > protected void putIntoCache(final String cacheKey, final String string)
> > {
> >  if (string != null) super.putIntoCache(cacheKey,string);
> > }
> > };
> > getResourceSettings().setLocalizer(localizer);
> >
> > this way you dont cache null values at all, only your real values.
> > If null values are asked a lot this could be slower ofcourse..
> >
> >
> > I will also open up Localizer api a bit more so that you can override
> the
> > cache that is used:
> >
> > /**
> >     * Create a new cache, override this method if you want a different
> map
> > to store the cache keys,
> >     * for example a map that hold only the last X number of elements..
> >     *
> >     * By default it uses the [EMAIL PROTECTED] ConcurrentHashMap}
> >     *
> >     * @return cache
> >     */
> >    protected Map newCache()
> >    {
> >        return new ConcurrentHashMap();
> >    }
> >
> > You could return there a map that evicts on the least recently used
>  then.
> >
> > johan
> >
> >
> >
> > On Mon, May 12, 2008 at 9:41 AM, Quan Zhou <[EMAIL PROTECTED]> wrote:
> >
> > > Thanks iman.
> > >
> > > I explore many CocurrentHashMap$Entry to check its key/value.
> > > I truly found two things:
> > > 1. some key is large , its length would be more than 300 if the
> > component
> > > has deep hierachy.That must be one of the reasons why Localizer is so
> > big.
> > > 2. the number of this object is large too. there're 2,863,559 entrys.
> I
> > > couldn't check the whole objects one by one.but i was wondering
> > >   why there're too many Entrys. There are about 2000 java files at
> most
> > in
> > > my app, and no more than 500 wicket page/components with 2
> > >    properties files , 1 html files in average.  It means there are not
> > > huge
> > > properties or name that needs to retain in heapze ,so what things
> > >     would those 2,863,559 entries supposed to contain?
> > >
> > > Is there any settings can control the limit of Entry size?or some
> > strategy
> > > can reduce the key name of the entry?
> > >
> > >
> > > 2008/5/12 Iman Rahmatizadeh <[EMAIL PROTECTED]>:
> > >
> > > > Well actually I haven't :-) My localizer gets quite large, but it
> > hasnt
> > > > made
> > > > any problems, yet .
> > > > You see when the localizer wants to find the resource value for a
> > > specific
> > > > key, it caches the result into the localizer. Now if your component
> > has
> > > a
> > > > deep hierarchy, the generated key will be quite large. In yourkit ,
> > use
> > > > the
> > > > object explorer to explore the ConcurrentHashMap entries and see why
> > are
> > > > they so large, as I think the number of entries in the cache is
> > limited,
> > > > So
> > > > the only explanation would be to see why are the key/values taking
> so
> > > much
> > > > space. If you can give a dump of one of the bigger key/values we can
> > > help
> > > > more.
> > > > Also the DiskPageStore doesnt hold on to anything in memory, so it
> > wont
> > > > consume any memory, nothing strange about it.
> > > >
> > > > Iman
> > > >
> > > > On Mon, May 12, 2008 at 9:31 AM, Quan Zhou <[EMAIL PROTECTED]>
> > wrote:
> > > >
> > > > > Thanks for your all replys.
> > > > >
> > > > > I review the dump file with both SAP MemoryAnalyzer and YourKit
> > > > > They all show the same hierachy as follows:
> > > > >
> > > > > -org.apache.wicket.settings.Settings
> > > > >  - org.apache.wicket.Localizer
> > > > >  - org.apache.wicket.util.concurrent.ConcurrentHashMap
> > > > >   - org.apache.wicket.util.concurrent.ConcurrentHashMap$Entry
> > > > >
> > > > > Localizer Object retaind 87.84% HeapSize. while the DiskPageStore
> > only
> > > > > retained 0.71%
> > > > > That's weird,isn't it?
> > > > >
> > > > > I decrease the max heapsize settings to 50M, and make a load test
> > then
> > > > > monitor the memory allocation.
> > > > > It indeed allocated more and more char[] objects time by time.
> > > > >
> > > > > Iman,how do you solve your problem at last?
> > > > > could you share some experience with me ? Thank you very much.
> > > > >
> > > > > 2008/5/10 Iman Rahmatizadeh <[EMAIL PROTECTED]>:
> > > > >
> > > > > > I've seen this before, altough it wasnt 2GB, but in a small 70MB
> > > heap
> > > > > dump
> > > > > > the cache size was around 25MB. The ConcurrentHashMap caches a
> lot
> > > of
> > > > > > unneeded string keys, where the keys are quite large, maybe
> > strings
> > > of
> > > > > size
> > > > > > 1k characters, like  key :
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> "org.apache.wicket.extensions.markup.html.repeater.data.table.DataTable$1:rows-ir.co.meraat.avicenna.web.components.AvicennaDataTable$InnerDataTable:inner-table-ir.co.meraat.avicenna.web.components.AvicennaDataTable$1:filter-form-ir.co.meraat.avicenna.web.components.AvicennaDataTable:table-ir.co.meraat.avicenna.vita.GradesManagementPanel$1:studentSearch-ir.co.meraat.avicenna.vita.GradesManagementPanel:componentId-ir.co.meraat.avicenna.web.CompositePage:5-fa_IR-nullg.apache.wicket.markup.repeater.OddEvenItem:29-...."
> > > > > >
> > > > > > As you see the component hierarchy is dumped into the string,
> > making
> > > > it
> > > > > > very
> > > > > > large. I guess we're both localizing a lot of strings, so our
> > > problem
> > > > > could
> > > > > > be the same.
> > > > > >
> > > > > > Iman
> > > > > >
> > > > > > On Sat, May 10, 2008 at 9:38 AM, Johan Compagner <
> > > [EMAIL PROTECTED]
> > > > >
> > > > > > 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]
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Reply via email to