We initially ran MyFaces with Client side state saving. And we encountered this problem. Then we turned to profile the problem. When we profiled the application, we were using Server side state saving -- we set View in Session to be one, Serialization in Session is false, and Compression to be false. The behavior is same as what we saw in Client mode. But the stats is taken under server state saving mode. From GC path and Class Tree, I have the feeling the state saving mode doesn't matter. And Behavior under both scenario is same.
I will certainly go back to run this as Client State saving mode. And then I will post the results Thanks FaceKiller Dennis Byrne wrote: > > Hello FaceKiller, > > Can you run these metrics for both client and server side state saving? > Which of these are you using now? > > Dennis Byrne > >>-----Original Message----- >>From: FaceKiller [mailto:[EMAIL PROTECTED] >>Sent: Friday, January 5, 2007 03:24 PM >>To: [email protected] >>Subject: Memory footprint of MyFaces >> >> >>We observe some memory issue when loading large JSF tables (>1000 rows). With >>some profiling tool, we found that MyFaces seems to keep some big chunnk of >>char[] in memory and is not able to GC it. >> >>Here is our test scenario: we have a non-face request come in to render a >>facelet. We repeat the above request multiple times. After each request, we >>use profiling tool to see what new objects are allocated and how big they >>are. We found something consistent -- after each request, there will always >>be one char[] allocated (size depends on how big the table is). The GC path >>is as of following: >> >>Char[] >> -- org.apache.jasper.runtime.BodyContentImpl >> -- Objects are retained by instances of several classes >> -- org.apache.myfaces.taglib.core.ViewTag >> >>one such char[] is created for every request to facelet. And that portion of >>memory is not released. Class Tree for the above is as of following: >>char[] >> -- cb of org.apache.jasper.runtime.BodyContentImpl >> -- [0] of org.apache.jasper.runtime.BodyContentImpl[7] >> -- outs of org.apache.jasper.runtime.PageContextImpl >> -- [3] of java.lang.Object[101] >> -- pool of org.apache.jasper.util.SimplePool >> -- pool of org.apache.jasper.runtime.JspFactoryImpl >> -- deflt of javax.servket.jsp.JspFactory >> -- [72] of java.lang.Object[321] >> -- elementData of java.util.Vector >> classes of >>org.apache.catalina.loader.StandardClassLoader >> >>So after many requests, memory is built up and could not be freed by GC. >>Does anyone have insight on this behavior? Thanks a lot. >> >>Regards >> >> >> >> >>Class >>-- >>View this message in context: http://www.nabble.com/Memory-footprint-of-MyFaces-tf2927779.html#a8185213 >>Sent from the MyFaces - Users mailing list archive at Nabble.com. >> >> > > > > -- View this message in context: http://www.nabble.com/Memory-footprint-of-MyFaces-tf2927779.html#a8196747 Sent from the MyFaces - Users mailing list archive at Nabble.com.
