JSF Tuning

JSF is a useful technology, but you can certainly hang yourself with it.

It sounds like, either you're inflating the size of the view state (by setting large values on components) or you're leaking references to components into other session state (which would be bad). Another potential culprit would be an excessively large view (I've seen the ease with which people can build UI trees lead to very big control graphs with data tables everywhere). I know that IBM provides rich text and spreadsheet controls - I can't comment on what effect the use of these will have on state size.

The low hanging fruit is to check the managed beans configured for session scope in faces-config.xml.

JSF saves two things between requests:

• the view (all the controls on the page)
• the view state (the state of the controls)

These are separated because some controls, such as children of a data table, can have multiple states (one for each row). State can be saved to either a hidden field on the form (which, if unencrypted, can be a big security hazard) or in the session. In order to accommodate multiple browser windows sharing the same session (and, in some implementations, back button support), multiple views are stored.

• There should be a configuration option to set the number of view states the app will keep in the session for a given user at any given time.
• You can measure the size of view state by providing a StateManager that measures the size of the saved view/state (configure a StateManager in faces-config.xml with a public constructor that takes a StateManager - see the JSF spec PDFs for more details; the state is serializable and you can check its size by dumping it to a strea

JSF stores the views in session to support it's rich component based architecture (need to maintain its view state) and may fill the heap if not used properly. If you do not have big work flows, always go with small no of views per session. Also avoid keeping backingbeans in session as much as possible. Use custom tag to make the data object just for the next request cycle. We can also use Spring Web Flow with JSF, which introduces view scope and flow scope if we have long workflows in application to reduce the no of views configured in session. JSF can be used for making rich user interface easily, that helps to build Webapplication similar to desktop application. Allot a specific heap to JSF framework to do its work. But use the memory efficiently in the application side and make sure that there is no memory leakage. All memory leaks need to be investigated and corrected during the development itself. Aways use a profiler to find memory leaks and performance bottlenecks that exists in the application.

Mat.

If you are using MyFaces < 1.1.6 there is a huge memory leak in the way it caches old serialized views in the session effectively never letting them release so that they can be garbage collected. I had a serious problem with that and had 50Mb sessions as well. A quick upgrade of MyFaces rectified the problem without any problems.