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