[Apache Tomcat Web Server] Memory leak problem

[dushyant agarwal <ag...@yahoo.co.in>]

Hi,
I found an issue on the thread -https://issues.apache.org/jira/browse/MYFACES-1658
Also at-http://www.mail-archive.com/users@myfaces.apache.org/msg50352.html


The problem is that of memory leak. In my implementation I am using server side state saving until now.As well as I am implementing multi tasking by saving view roots of my pages every time any page is rendered, in a map, on the session. When a user wants to switch to another task i set that view root using the set ViewRoot () method of the FacesContext  API. After all this when I test my war for several number of times I get PermGen Space: Out Of Memory error. 

After going through the above threads I have a feeling that this saving of old searialized views may be present inside Trinidad or JSF framework, as well. And that might be the reason for the drying up of the memory
 heap so fast? Am I right?

Also I would like to know how can I save the state of a JSF/trinidad  page without submitting it. 
Would tr:navigationPane hints="tabs"  provide client side state saving?
Does client side state saving mean saving the view state without having to submit the form.?
Or does it mean that on submitting the form the state is saved on the client machine(the browser) instead of the server(it would be fetched next time from the client to restore view on postback?)?

Thanks,
Dushyant






      



      Connect with friends all over the world. Get Yahoo! India Messenger at http://in.messenger.yahoo.com/?wm=n/

Re: [Apache Tomcat Web Server] Memory leak problem

[Simon Kitching <sk...@apache.org>]

Hi,

dushyant agarwal schrieb:
>
>
>     Hi,
>     I found an issue on the thread
>     -https://issues.apache.org/jira/browse/MYFACES-1658
>     Also
>     at-http://www.mail-archive.com/users@myfaces.apache.org/msg50352.html
>
>
>     The problem is that of memory leak. In my implementation I am
>     using server side state saving until now.As well as I am
>     implementing multi tasking by saving view roots of my pages every
>     time any page is rendered, in a map, on the session. When a user
>     wants to switch to another task i set that view root using the set
>     ViewRoot () method of the FacesContext  API. After all this when I
>     test my war for several number of times I get PermGen Space: Out
>     Of Memory error.
>
>     After going through the above threads I have a feeling that this
>     saving of old searialized views may be present inside Trinidad or
>     JSF framework, as well. And that might be the reason for the
>     drying up of the memory heap so fast? Am I right?
>

I doubt that the myfaces state-saving code would cause PermGen problems.

Is this problem happening during your development work, and you have 
tomcat's "auto-redeploy" to cause it to restart automatically when you 
modify code? That's a common problem with servlet engines in general, as 
classes cannot be garbage-collected so redeploying large jars does use 
up memory.

>
>     Also I would like to know how can I save the state of a
>     JSF/trinidad  page without submitting it.
>
I don't know what you mean by that...
>
>     Would tr:navigationPane hints="tabs"  provide client side state
>     saving?
>
??
>
>     Does client side state saving mean saving the view state without
>     having to submit the form.?
>     Or does it mean that on submitting the form the state is saved on
>     the client machine(the browser) instead of the server(it would be
>     fetched next time from the client to restore view on postback?)?
>
Your second sentence is true. With client-side-state-saving the "jsf 
view tree state" is embedded as a hidden field in the form sent back to 
the browser. Just do "view source" on the page and you will see it. On 
postback that data then automatically gets sent to the server as part of 
the http port, and is used to restore the view. This avoids having an 
HttpSession object on the server, and works better with distributed 
server setups, but uses more network bandwidth.

BTW, please try to avoid posting "html email" if possible. Your email is 
very hard to read in my mail client.

Regards,
Simon