voyent
Messages posted by: barmaglot  XML
Profile for barmaglot -> Messages posted by barmaglot [21] Go to Page: 1, 2 Next 
Author Message
ted.goddard,

thank you for information about IcePack, now I see how to make workaround on testing problem.

I'm not 100% agree that the discussed memory leak is similar to general JSF. At least in classic JSF we have limited number of stored views, but in case of JSF there is NO limitation of view state map size. That is why my application was crashed within a minutes on a system with more then 10Gb RAM.

I also found another case when view state is put to global map and never destroyed:

In our application there is JSF view for displaying 404 error (JSF is used for the sake of i18n), and our html output has some images like:

Code:
<img src="#{imageUrl}"/>


there was some cases when image url points to non-existing file and it was located inside WebContent of our application (for testing purposes).

I suddenly found that after browser request non-existent image - 404-page was silently rendered on server side and PUT to view state map. Obviously it was never disposed.

There was yet more funny case when wrong html code:
Code:
<img src=""/>
caused multiple rendering of root page "/" on server side.

P.S. thank you for nice session management API appeared in IceFaces 1.8.2
ted.goddard,

I've attached simple test project (eclipse 3.5 with Icefaces tools, glassfish 2.1 as application server),

to check view states map you can put two breakpoints:

1) com.icesoft.faces.context.View
line 267: "m.remove(facesContext.getViewNumber());"

2) com.icesoft.faces.application.SingleCopyStateManagerImpl
line 211: "stateMap.put( viewNumber, new Object[] { objTree, handleSaveState(state) } );"
it seems I've found the issue - I see that view is disposed only by request to .../dispose-views (that is obviously performed by javascript hook when browser leaves a page), but if we perform simple load testing with jmeter or apache ab - then only put to view state map is performed and no remove. This causes memory leak.

Unfortunately I have no ideas now on how to perform load testing of Icefaces application.

This is also seems to me a security vulnerability because it is very easy to perform DoS attack on Icefaces application.
No, our application has no bean implementing DisposableBean, we use only Seam beans and do not declare managed beans directly.

I will try 1.8.2RC1 as soon as possbile
judy.guglielmin,

yes, I do not expect Seam to destroy page scope, but I expected to do this by IceFaces. However I see that each page refresh produces one destroy (remove from session map) and 4 or more puts to ICEFACES_STATE_MAPS.

So after several seconds of load testing I see more then 500 entries in view state map of Icefaces.

After some more time this will become much more then even 15x15.

Even if we will not use PAGE scope of Seam each view state can contain 100-900 kBytes of component tree in our case. This is real memory leak I think.

Unfortunately I have no success to switch to standard JSF state manager, when I put

Code:
<state-manager>com.sun.faces.application.StateManagerImpl</state-manager>

in my faces-config.xml Icefaces still put references to rendered views in ICEFACES_STATE_MAPS

please help.
cyberoblivion,
thank you for this notice, but this way is also not safe enough. It is much more difficult to keep control on starting/ending of long-running conversation compared with page scope, especially if there are natural URLs somewhere on your pages (without propagating conversation id). Abandoned long-running conversations also cause memory leaks.

So only event scope is safe however using event scope is not sufficient workaround of this problem.
I also see the same memory leak in com.icesoft.faces.webapp.http.servlet.MainSessionBoundServlet.

It keeps references to rendered views in its "views" map, that doesn't cleanup properly as I see after debugging.

This leak appears at least when "synchronousUpdate" is true (we do not use sever push).

Can anyone from Icefaces development team check this?
Hello. Please help me figure out the problem.

We are using Icefaces 1.8.1 with Seam 2.2.0 and during load testing I found that application consumes memory inside one http session and doesn't free it until session was destroyed.

After investigation I found that memory is consumed by view states - Icefaces saves view states in Map inside a http session with key ICEFACES_STATE_MAPS ("icefaces.state.maps") declared in com.icesoft.faces.context.View.

After investigation the problem with debugger I see that this state map instantly increases its size after each single page refresh. The problem is state disposed only once per page refresh (in com.icesoft.faces.webapp.http.core.DisposeViews server) but new states are stored to this map multiple times per page refresh. In particular I see that each http worker thread puts new state into this map, but each thread even can do it multiple times.

I've also tried to use SingleCopyStateManagerImpl but the status was not changed - state map is growing.

This is very critical for our application because we actively use Seam's Page scope utilizing Faces view state.
Have you read any comment on article you referred?

"Go with Seam and release yourself from the JSF pain while still getting the benefits."

that is 1000% true
So, did anyone tested asynchronous mode with single application deployed without push-server deployed?

I think there is obvious bug preventing to run ICEFaces in asynchronous mode on without push-server deployed. Despite on documentation saying that push-sever is not mandatory I see it is not possible run app without it.

I'm not very happy ICEFaces strongly depends on push-server (buggy ICEFaces's File Uploader in synchronous mode makes me non-happy too). Perhaps push-server dependency can cause performance penalty...
so, I see that service is blocked by reading from connection to URL
http://localhost:8080/push-server/block/message

please explain what does this request perform and what can be wrong in my configuration?

deryk.sinotte wrote:
@barmaglot

Can you take a thread dump when the deadlock occurs and post the relevant pieces? 


attached are stack traces for blocking and blocked threads. I believe it is not good solution to call something like "testMessageService" inside synchronized block :)
Alexandre, what do you mean exactly? I see nothing special at page 70 for v2.

judy.guglielmin wrote:
If you are using Seam-2.1.1.GA, and you are defining your error pages in web.xml, does this mean you have disabled Seam's exception filter?
 


yes, some exceptions should be processed before seam's exception filter, otherwise glassfish will not recover properly and will stall during application redeploying (I do not know why, at least this was for version 2.0ur2). Anyway - seam exception filter still works well for other cases.


judy.guglielmin wrote:
If you are not using any of the asynchronous components or ajax-push, then you can leave the synchronous setting to true in your web.xml.
 


Unfortunately I suspect that synchronous mode is tha cause that bug ICE-4246 still not fixed despite its JIRA status ('fixed' in 1.8). I see that in Firefox 3.0.8 submitOnUpload for file upload component still has no effect. And I see log message saying that page updates are postponed due to synchronous mode. This is because I was trying async mode.

judy.guglielmin wrote:
Otherwise, you should probably attach a simple sample of your application with just the basics so we could see what the problem is. Your components.xml would be good to see. Did you use seam-gen to create your project? Did it work previously in 1.7.2.SP1? Is it definitely a stall in the server, or could it be browser limitations--which browser are you using?  


I will try to prepare simple example but this is not so simple, it is large project and it was not produced by seam-gen. All was working well in 1.7.2.SP1 where async mode was on by default. The problem appears at least in Firefox 3.0.8, IE7 and Chrome 1.0.

I also investigate the problem a bit more and really see bad thing - another thread causes deadlock at this method (SessionDispatcher.checkSession) because it is blocked inside a constructor called from 'this.newServer(...)' by reading from input http stream.

this is my web.xml:

Code:
 <?xml version="1.0" encoding="UTF-8"?>
 <web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
     xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
     version="2.5">
     <listener>
         <listener-class>org.jboss.seam.servlet.SeamListener</listener-class>
     </listener>
     <listener>
         <listener-class>
             com.icesoft.faces.util.event.servlet.ContextEventRepeater</listener-class>
     </listener>
 
 
     <filter>
         <filter-name>Seam Filter</filter-name>
         <filter-class>org.jboss.seam.servlet.SeamFilter</filter-class>
     </filter>
     <filter-mapping>
         <filter-name>Seam Filter</filter-name>
         <url-pattern>/*</url-pattern>
     </filter-mapping>
 
 <context-param>
         <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
         <param-value>server</param-value>
     </context-param>
     <context-param>
         <param-name>facelets.DEVELOPMENT</param-name>
         <param-value>true</param-value>
     </context-param>
     <context-param>
         <param-name>javax.faces.DEFAULT_SUFFIX</param-name>
         <param-value>.xhtml</param-value>
     </context-param>
     <context-param>
         <param-name>com.icesoft.faces.actionURLSuffix</param-name>
         <param-value>.seam</param-value>
     </context-param>
     <context-param>
         <param-name>com.icesoft.faces.synchronousUpdate</param-name>
         <param-value>false</param-value>
     </context-param>
     <context-param>
         <param-name>com.icesoft.faces.doJSFStateManagement</param-name>
         <param-value>true</param-value>
     </context-param>
     <context-param>
         <param-name>com.icesoft.faces.standardRequestScope</param-name>
         <param-value>true</param-value>
     </context-param>
     <!--<context-param>
         <param-name>com.sun.faces.enableRestoreView11Compatibility</param-name>
         <param-value>true</param-value>
     </context-param>
     --><context-param>
         <param-name>com.icesoft.faces.compressResources</param-name>
         <param-value>false</param-value>
     </context-param>
     <context-param>
         <param-name>com.icesoft.faces.concurrentDOMViews</param-name>
         <param-value>true</param-value>
     </context-param>
     <context-param>
         <description>512 KB of data maximum</description>
         <param-name>com.icesoft.faces.uploadMaxFileSize</param-name>
         <param-value>524288</param-value>
     </context-param>
     <context-param>
         <param-name>com.icesoft.faces.uploadDirectory</param-name>
         <param-value>upload</param-value>
     </context-param>
     <!-- file upload Servlet -->
     <servlet>
         <servlet-name>Faces Servlet</servlet-name>
         <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
         <load-on-startup>1</load-on-startup>
     </servlet>
     <servlet>
         <servlet-name>Seam Resource Servlet</servlet-name>
         <servlet-class>org.jboss.seam.servlet.ResourceServlet</servlet-class>
     </servlet>
     <servlet>
         <servlet-name>Persistent Faces Servlet</servlet-name>
         <servlet-class>
             com.icesoft.faces.webapp.xmlhttp.PersistentFacesServlet</servlet-class>
         <load-on-startup>1</load-on-startup>
     </servlet>
     <servlet>
         <servlet-name>Blocking Servlet</servlet-name>
         <servlet-class>com.icesoft.faces.webapp.xmlhttp.BlockingServlet</servlet-class>
         <load-on-startup>1</load-on-startup>
     </servlet>
     <servlet>
         <servlet-name>Upload Servlet</servlet-name>
         <servlet-class>
             com.icesoft.faces.component.inputfile.FileUploadServlet</servlet-class>
         <load-on-startup>1</load-on-startup>
     </servlet>
     <servlet-mapping>
         <servlet-name>Upload Servlet</servlet-name>
         <url-pattern>/uploadHtml</url-pattern>
     </servlet-mapping>
     <servlet-mapping>
         <servlet-name>Persistent Faces Servlet</servlet-name>
         <url-pattern>*.seam</url-pattern>
     </servlet-mapping>
     <servlet-mapping>
         <servlet-name>Persistent Faces Servlet</servlet-name>
         <url-pattern>/xmlhttp/*</url-pattern>
     </servlet-mapping>
     <servlet-mapping>
         <servlet-name>Blocking Servlet</servlet-name>
         <url-pattern>/block/*</url-pattern>
     </servlet-mapping>
     <servlet-mapping>
         <servlet-name>Seam Resource Servlet</servlet-name>
         <url-pattern>/seam/resource/*</url-pattern>
     </servlet-mapping>
     <security-constraint>
         <display-name>Restrict raw XHTML Documents</display-name>
         <web-resource-collection>
             <web-resource-name>XHTML</web-resource-name>
             <url-pattern>*.xhtml</url-pattern>
         </web-resource-collection>
         <auth-constraint />
     </security-constraint>
     <error-page>
         <error-code>404</error-code>
         <location>/404.seam</location>
     </error-page>
     <error-page>
         <exception-type>java.io.FileNotFoundException</exception-type>
         <location>/error.seam</location>
     </error-page>
     <error-page>
         <exception-type>java.lang.ClassNotFoundException</exception-type>
         <location>/debug.seam</location>
     </error-page>
     <error-page>
         <exception-type>javax.servlet.jsp.JspException</exception-type>
         <location>/debug.seam</location>
     </error-page>
     <error-page>
         <exception-type>java.lang.NullPointerException</exception-type>
         <location>/debug.seam</location>
     </error-page>
     <error-page>
         <exception-type>javax.faces.FacesException</exception-type>
         <location>/debug.seam</location>
     </error-page>
     <error-page>
         <exception-type>com.sun.facelets.tag.TagAttributeException</exception-type>
         <location>/debug.seam</location>
     </error-page>
 
     <error-page>
         <error-code>500</error-code>
         <location>/error.seam</location>
     </error-page>
 
     <session-config>
         <session-timeout>120</session-timeout>
     </session-config>
 
 </web-app>
 
 
Profile for barmaglot -> Messages posted by barmaglot [21] Go to Page: 1, 2 Next 
Go to:   
Powered by JForum 2.1.7ice © JForum Team