Memory leak with ICEFaces 1.7  XML
Forum Index -> General Help
Author Message

Joined: 19/Sep/2007 00:00:00
Messages: 46


The problem described is with the last 1.7 releace, "just-ice" version with facelets,
both Tomcat 6.0 and IBM WAS 6.1 enviroments, Firefox 2.0 browser.
We don't use "standard request scope". We do use server push.

We are facing a memory leak problem.
The JSF component tree does not get garbage collected after page is closed.

Initially, we had "com.icesoft.faces.concurrentDOMViews" set to true.
Every click on the browser "refresh" button caused increased memory consumption.
We have made some investigation with JProfiler and found, that every time
a new component tree was created, but the old one was not garbage collected.

Then we switched "com.icesoft.faces.concurrentDOMViews" to false.
After that, "refresh" does not cause problems, only one component tree is maintained.
However, this one does not get garbage collected when the user leaves the page
(also request-scopeed beans are, and dispose() methods are invoked for DisposableBean-s).
It is garbage-collected first when the session times out.

I would appreciate your help!

Boris Maizel

Joined: 19/Sep/2007 00:00:00
Messages: 46

I have made some more investigation. The central object where
a lot of data structures hangs on, is com.icesoft.faces.context.View.
I have browsed the source code to see when a View is discarded.
It seams, that this only happens when a session is closed.
With concurrentDOMViews enabled, View-s and all belonging data
can accumulate for a long time, consuming significant memory.

Q1: It seams to me, that View-s could be discarded immediately
after non-standard request is finished, since a new view
will be created for a new request anyway. Am I right?

Q2: I have not found a way to discard a View explicitly.
I was looking for a public method returning the views map
and dis not found it either. Can you give me a hint?

Thanks a lot!
Boris Maizel


Joined: 04/Jun/2007 00:00:00
Messages: 704

Hi Boris,

there is currently a memory leak issue in concurrent Dom view applications which should be fixed in the upcoming ICEfaces 1.7.1 release.

Best regards,

Joined: 26/Oct/2004 00:00:00
Messages: 85

There's a JIRA opened up for this memory leak here:


There were ThreadLocal references to instances of the BridgeFacesContext and PersistentFacesState classes being held by Threads from the Servlet container. These objects have references to instances of View. A further ThreadLocal reference to the PersistentFacesState object was being held in the executor threads performing server push.

While not unbound leaks, they can accumulate a set of objects for each Thread used by the Servlet container.

Some observations:

The Views are disposed when the browser requests it from the onBeforeUnload handler. This is not under server side application control.

First, it's possible to hit reload on a page fast enough so the page never properly loads, and therefore never fires onBeforeUnload. Yet, the initial request will arrive and a new View created. This is a use case which should be avoided.

Secondly, any automated load testing scripts should be written to submit this dispose-views request ( ${app}/block/dispose-views ) being sure to submit the ice.view id of the view to be disposed. Otherwise the View object and associated UIComponent tree will not be discarded and will persist until the end of the session.


Joined: 16/Nov/2006 00:00:00
Messages: 32

Just to reply that we also hit the same issue with Icefaces 1.7.0. It only took about 30-40 seconds to cause OOM (-Xmx1400m) with a simple refresh a single Liferay portlet page with Icefaces portlet in it.

The real problem is that upgrading from Icefaces 1.7.0 to 1.7.2SP1 causes "User Session Expired" to appear on the browser.

Below is first few lines from jhat. Notice there're no HttpSessions active so most of the instances are orphaned and should be GCed.

Heap Histogram

All Classes (excluding platform)
Class Instance Count Total Size
class [C 1130072 550039092
class [B 68132 219803888
class [Ljava.lang.Object; 507200 58445944
class [Ljava.util.HashMap$Entry; 294410 48488192
class java.lang.String 1204677 24093540
class java.util.HashMap$Entry 655629 23602644
class org.apache.xerces.dom.ElementImpl 230341 17045234
class org.apache.xerces.dom.AttrImpl 477604 16238536
class java.lang.reflect.Method 115127 14851383
class java.util.HashMap 235000 13160000
class [I 64812 9824784
class com.icesoft.faces.component.ext.HtmlPanelGrid 23498 8764754
class java.util.LinkedHashMap$Entry 117924 6132048
class [Ljava.lang.String; 97062 4652608
class com.icesoft.faces.component.ext.HtmlOutputText 14951 4619859
class java.util.concurrent.ConcurrentHashMap$Segment 141572 4530304
class javax.servlet.jsp.tagext.TagAttributeInfo 96064 4322880
class java.util.Vector 212176 4243520
class org.apache.xerces.dom.AttributeMap 230089 4141602
class [Ljava.util.concurrent.ConcurrentHashMap$HashEntry; 141572 3971720
class java.util.concurrent.locks.ReentrantLock$NonfairSync 141772 3969616
class java.lang.ref.WeakReference 122127 3908064
class java.lang.ref.SoftReference 97609 3904360
class java.beans.MethodDescriptor 43430 3257250
class java.util.LinkedHashMap 48453 3149445
class java.lang.Class 21630 3114720
class [<other> 31769 2990816
class java.lang.reflect.Field 28371 2978955
class java.util.ArrayList 150678 2410848
class org.springframework.beans.GenericTypeAwarePropertyDescriptor 14178 2112522
class [S 25999 2052142
class com.liferay.portal.model.impl.LayoutImpl 10719 1811511
Forum Index -> General Help
Go to:   
Powered by JForum 2.1.7ice © JForum Team