[richfaces-issues] [JBoss JIRA] Commented: (RF-5383) memory leakage issues during the load testing on rich faces version 3.2

[ https://jira.jboss.org/jira/browse/RF-5383?page=com.atlassian.jira.plugin... ] Alexander Smirnov commented on RF-5383: --------------------------------------- I've tested your application under profiler, and other as well. There is no memory leak, but common JSF state saving problem. My tests designed to use clean JSF implementation and RichFaces environment, thus I able to compare memory consumption for a both cases. RichFaces takes about 10% more for a state, but total trend is same as for a clean environment. There are few suggestions for a performance tuning: 1) JSF components tree state takes big enough memory. In the server-side state saving ( default JSF behavior ) these objects are stored in the session. For a many concurrent user connections every user gets own session object. Possible solution - switch to the client-side state saving. <context-param> <param-name>javax.faces.STATE_SAVING_METHOD</param-name> <param-value>client</param-value> </context-param> Other possible solution is Facelets behavior that allows to build view before request processing instead of state saving, but that solution has sometimes unpredictable side effects. Use web.xml init parameter together with the <f:view transient="true" > attribute. <context-param> <param-name>facelets.BUILD_BEFORE_RESTORE</param-name> <param-value>true</param-value> </context-param> As an intermediate solution, it is makes sense to create custom FaceletsViewHandler subclass with special state processing for a some pages like menus which does not depends for a saved state. That custom handler could call buildView method instead of real restoreView procedure for a such pages. 2) Facelets library in the "debug" mode stores information about components and beans up to 5 times for an every user. To disable this mode: <context-param> <param-name>facelets.DEVELOPMENT</param-name> <param-value>false</param-value> </context-param> 3) Most filters use buffering for request processing. According to the profile information, these buffers took big enough memory in the application. I see a buffer-related parameter in the RichFaces Ajax filter: <init-param> <param-name>maxRequestSize</param-name> <param-value>100000</param-value> </init-param> For a production server, it makes sense to reduce value to a real page size or remove that parameter at all. 4) TIDY xml filter is DOM-based, thus it requires a lot of memory. It would be better to use more optimized "NONE" or "NEKO" one : <context-param> <param-name>org.ajax4jsf.xmlparser.ORDER</param-name> <param-value>NONE</param-value> </context-param> Of course, production deployment have to disable all except "FATAL" log messages, profiling utilities etc... P.S This is not a memory leak problem, but can prevent http session swap or replication in a claster : Non serializable classes for a some session beans, for example: com.emirates.jfoundation.client.core.contracts.SessionProperty. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira