voyent
IceFaces 1.6.1 causing OutOfMemory errors (Resolved)  XML
Forum Index -> General Help Go to Page: 1, 2 Next 
Author Message
edykory


Joined: 27/Nov/2006 00:00:00
Messages: 332
Offline


Hi there!
We have this application (containing quite a few forms, bigger and smaller) running on SLES 9.3, IBM JDK 1.5, JBoss 4.2.1 with IceFaces 1.6.0 & Facelets. Evertyhing runs OK (I mean, almost everything :) ). The JBoss would stay below 500MB of RAM always. Anyway, when I tried to switch to 1.6.1 libs, I started getting OutOfMemory errors from the JBoss after about 10 mins of application use; repeatedly, without anything complicated happening on the business side. Then I switched back to 1.6.0 and everything started to work normally as before.
Is there any known serious leak in 1.6.1, or is there something we definitely shouldn't do comparing to 1.6.0 ? There are some bugs fixed in 1.6.1 (especially the one related to PhaseListener based authentication) in which I'm very interested.

Cheers!
ted.goddard

Joined: 26/Oct/2004 00:00:00
Messages: 874
Offline


There are no known memory leaks in ICEfaces-1.6.1. Using a profiler, can you determine what type of objects are leaking?

[Email]
edykory


Joined: 27/Nov/2006 00:00:00
Messages: 332
Offline


Ok, I'll do my best to. But it could take a couple of days ...
pekus

Joined: 05/Sep/2007 00:00:00
Messages: 11
Offline


Hi,

I'm getting the same problem: any project with ICEFaces 1.6.1 causes outOfMemory errors, removing it then the project works fine. My environment: WinXP SP2, NetBeans 5.5.1, Tomcat 5.

Any idea?

Regards,

Alexandre.
philip.breau


Joined: 08/May/2006 00:00:00
Messages: 2989
Offline


Hi Alexandre,

At this time, there are no known server-side memory leaks with 1.6.1. So, I would suggest profiling your application to see where the leak might be coming from. Then we can investigate further.

Thanks,
Philip

.
edykory


Joined: 27/Nov/2006 00:00:00
Messages: 332
Offline


Hi Philip!
As you probably noticed from the first post, I'm facing the same problem. I'm not talking about out of memory errors during development, but once the application was deployed in production and it had 10-20 users using it, the problems appeared quite soon (maybe half an hour after jboss start).
This pushed me to go back to using the 1.6.0 release (and now it's in production and very happy). I really doubt it's something from our application, since with the 1.6.0 release the jboss does never go over 400Megs (we are running it with -Xmx1536m).
I would try to profile it, but this happens only at the client, and since he entered production in the real world ... it's impossible to convince him to stop activity for a day or two of testing ... maybe at a later date. Another issue related to profiling is the fact that I don't know exactly how should I do it and what exactly to profile. We are using Ibm's jdk 1.5 and once we get the out of memory signal, it starts dumping the whole memory to javacore files ... but checking an 1.5Gigs of text .... sorry, no time.
So I just hope that the next release will somehow mysteriously solve this problem for us. Otherwise ... we'll just stay at 1.6.0

Cheers!
Sn0w

Joined: 28/Apr/2007 00:00:00
Messages: 26
Offline


Hi,

we have the same problem with IceFaces 1.6.1. Out of memory occurs after 20-30 page refresh.

Icefaces 1.6.0 works fine.


No one lives forever...
ken.fyten

Joined: 26/Oct/2004 00:00:00
Messages: 1337
Offline


Hello,

Although we haven't detected any issues with increased server-side memory consumption with the 1.6.1 release ourselves, obviously some people have.

We're looking into these reports but it would helpful if any of you could provide additional advice / reproducible steps on how to recreate this.

Regards,
Ken

Ken Fyten
VP Product Development
ICEsoft Technologies, Inc.
edykory


Joined: 27/Nov/2006 00:00:00
Messages: 332
Offline


Hi Ken,
I wish I could provide more infos on this one, but ... don't know what to say. You heard the others too. There's nothing special I do to get this behavior. It's just replacing the old 1.6.0 libs with the 1.6.1 ones. After this, things start getting messy very soon (especially with more users involved). It could be because some views are cached for reusing and are never reused actually, or never expired. This would be my best guess seeing how memory consumtion grows, but it's just my impression, without any real backup.

Cheers!
ken.fyten

Joined: 26/Oct/2004 00:00:00
Messages: 1337
Offline


Can someone post their web.xml file that they are using when they see this issue?

Are you using Async vs. Synchronous mode?
Concurrent DOM views, or not?
etc.

Thx.
Ken

Ken Fyten
VP Product Development
ICEsoft Technologies, Inc.
edykory


Joined: 27/Nov/2006 00:00:00
Messages: 332
Offline


Hi there the web.xml we are using is as follows (we also have a couple of servlets deffined for sending different content to the user, but I cut them out, for the sake of simplicity):

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
<description>OTP Bank - Credite pentru nevoi personale</description>
<display-name>OTP CNP</display-name>
<context-param>
<param-name>facelets.LIBRARIES</param-name>
<param-value>/WEB-INF/tags/otpproject.taglib.xml</param-value>
</context-param>
<context-param>
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>server</param-value>
</context-param>
<context-param>
<param-name>filesend-errorurl</param-name>
<param-value>/documents/error.jsp</param-value>
</context-param>
<context-param>
<param-name>com.icesoft.faces.debugDOMUpdate</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>
<param-name>com.icesoft.faces.synchronousUpdate</param-name>
<param-value>false</param-value>
</context-param>
<context-param>
<param-name>com.icesoft.faces.uploadMaxFileSize</param-name>
<param-value>20971520</param-value>
</context-param>
<context-param>
<param-name>com.icesoft.faces.uploadDirectory</param-name>
<param-value>upload_folder</param-value>
</context-param>
<context-param>
<param-name>facelets.DEVELOPMENT</param-name>
<param-value>false</param-value>
</context-param>
<context-param>
<param-name>com.sun.faces.validateXml</param-name>
<param-value>true</param-value>
</context-param>
<context-param>
<param-name>com.sun.faces.verifyObjects</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>
<filter>
<filter-name>LoginCheckFilter</filter-name>
<filter-class>
ro.ascenta.otpproject.servlets.LoginCheckFilter
</filter-class>
</filter>
<filter-mapping>
<filter-name>LoginCheckFilter</filter-name>
<url-pattern>*.faces</url-pattern>
</filter-mapping>
<listener>
<listener-class>
com.icesoft.faces.util.event.servlet.ContextEventRepeater
</listener-class>
</listener>
<servlet>
<description>InitApplication Servlet</description>
<display-name>InitApplication Servlet</display-name>
<servlet-name>InitApplicationServlet</servlet-name>
<servlet-class>
ro.ascenta.otpproject.servlets.InitApplicationServlet
</servlet-class>
<load-on-startup>2</load-on-startup>
</servlet>
<servlet>
<servlet-name>uploadServlet</servlet-name>
<servlet-class>
com.icesoft.faces.component.inputfile.FileUploadServlet
</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<!-- Faces Servlet -->
<servlet>
<servlet-name>Faces Servlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<!-- Persistent Faces 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>
<!-- Blocking 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-mapping>
<servlet-name>Persistent Faces Servlet</servlet-name>
<url-pattern>/xmlhttp/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>Persistent Faces Servlet</servlet-name>
<url-pattern>*.faces</url-pattern>
</servlet-mapping>
<!-- Blocking Servlet Mapping -->
<servlet-mapping>
<servlet-name>Blocking Servlet</servlet-name>
<url-pattern>/block/*</url-pattern>
</servlet-mapping>

<servlet-mapping>
<servlet-name>uploadServlet</servlet-name>
<url-pattern>/uploadHtml</url-pattern>
</servlet-mapping>

<!-- Welcome File List -->
<welcome-file-list>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>
<security-constraint>
<web-resource-collection>
<web-resource-name>
Protect XHTML Templates
</web-resource-name>
<url-pattern>*.xhtml</url-pattern>
</web-resource-collection>
<auth-constraint />
</security-constraint>


<context-param>
<param-name>com.icesoft.faces.connectionTimeout</param-name>
<param-value>600000</param-value>
</context-param>

<session-config>
<session-timeout>30</session-timeout>
</session-config>

<context-param>
<param-name>com.icesoft.faces.heartbeatInterval</param-name>
<param-value>10000</param-value>
</context-param>

<context-param>
<param-name>com.icesoft.faces.heartbeatTimeout</param-name>
<param-value>8000</param-value>
</context-param>

<context-param>
<param-name>com.icesoft.faces.heartbeatRetries</param-name>
<param-value>30</param-value>
</context-param>

</web-app>
 

I remind you we are using JBoss 4.2.1 with its builtin jsf 1.2 and icefacelets, IBM's JDK 1.5 on a Suse Enterprise Linux 9.3

Hope this helps. Cheers!
edykory


Joined: 27/Nov/2006 00:00:00
Messages: 332
Offline


I don't know if this helps, but according to some IceFaces documentation, in order to use it together with jsf 1.2 we should switch jsf to some sort of 1.1 compatibility mode by using in faces-config a declaration like this:
<!DOCTYPE faces-config PUBLIC "-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.1//EN"
"http://java.sun.com/dtd/web-facesconfig_1_1.dtd">
 

Cheers!
ken.fyten

Joined: 26/Oct/2004 00:00:00
Messages: 1337
Offline


After a lot of effort we are still unable to reproduce the apparent leak that is being reported here.

It would help us out a lot if someone could either post a simple test application that illustrates the leak, or provide a larger application with the problem for us to analyze via our product support group.

If you think you may be able to help us out please contact me via private message.

Thx.
Ken

Ken Fyten
VP Product Development
ICEsoft Technologies, Inc.
ken.fyten

Joined: 26/Oct/2004 00:00:00
Messages: 1337
Offline


After a lot of effort trying to reproduce this issue we've finally identified a usage pattern that can lead to out of memory conditions on the server. It is related to the timing, and number, of new views being created when application events such as page navigation, reloads, etc. take place. This isn't so much a traditional memory leak as a susceptibility to temporarily increased memory use that in the right configuration and application circumstances can result in OutOfMemory errors.

In some of cases views can be discarded and not cleaned up on the server in a timely fashion. In all these scenarios the views will be discarded once the user session expires, unfortunately, some application or test scenarios do not permit the session to expire and can keep generating new views until the heap memory is consumed.

To address this issue we've made improvements to how and when the old views are recovered and also improved the reliability of the messaging from the browser to the server when a page is left or closed that helps the framework know when a view is no longer active. The related JIRA for this issue is ICE-2202.

This fix is included in the ICEfaces 1.7 DR#2 release. It would be very helpful if those of you that experienced problems with 1.6.1 could try your applications with DR#2 to confirm that the situation is resolved. The improvements will also be included in the upcoming 1.6.2 maintenance release but it would be beneficial if we could confirm that these changes address the issues the posters in this thread were experiencing with 1.6.1 before 1.6.2 is released.

Regards,
Ken

Ken Fyten
VP Product Development
ICEsoft Technologies, Inc.
edykory


Joined: 27/Nov/2006 00:00:00
Messages: 332
Offline


Hi there!
We have just upgraded the IceFaces version to 1.7 DR#2, so in a couple of days I will let you know if the above mentioned thing still manifests or not, and this in a real production environment (with 30-100 users)

Cheers!

 
Forum Index -> General Help Go to Page: 1, 2 Next 
Go to:   
Powered by JForum 2.1.7ice © JForum Team