• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Session Bloat in Faces Portlet

 
Vito Andolini
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have created a JSR-168 Faces Portlet using RSA 7.0.0.5 for WebSphere Portal 6.0.1.3. The portlet runs as designed, but we noticed a problem in performance testing. It appears that every time we do a POST from the faces portlet, it adds data to wps.war's session. We could see that wps.war's session size was growing as high as 6 MB, and a heap dump showed that there were faces classes (UIViewRoot, and everything it contains) from our application in wps.war's httpsession.

Furthermore, I was able to isolate this to the faces portlet framework itself - actually to POSTs using the faces portlet framework. I created a generic basic JSR 168 portlet and ran it. I changed the theme to print out everything in session (since the theme runs in wps.war, it will print out everything in wps.war's session). Running GETs and POSTs on the basic portlet did not add any data to wps.war's session. I then created a very simple JSR-168 Faces portlet. All it had was an input field and a submit button in a form - although it did absolutely nothing with the data submitted. I noticed that if I just rendered the faces portlet, no data was added to wps.war's session. However, everytime I POSTed the form, it added about 5 KB to session.

Has anyone run into this problem before, or does anyone have any thoughts/suggestions? I hate to be that guy who makes a post like "EMERGENCY - NEED HELP NOW!!", but we're in Performance testing and this is a huge risk to our implementation date. Any help would be appreciated immensely.

Thanks!
 
Tony Schultz
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Have/Did you ever find a way to avoid this? I am in a similar environment Rational 7.0.0.6 and Portal 6.0.1.3. Have a simple JSF that does nothing with info entered in a field. Using a session db and receiving messages due to the session exceeding 2MB and not having multi-row support in. Basically, you need multi-row support to handle more than 2MB. Since this isn't doing anything, it shouldn't be getting to 2MB. Usually takes 280-285 submits to cause this.

Thanks!
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic