When the user opens the "Ajax Push" portlet page, two portletProxySessions are created, and those are associated with an HttpSession from the user. When the user logs out, he/she is logging out from the Portal Web application. The HttpSession is invalidated, but the SessionDispatcher is not informed via callback, and therefore the ICEfaces core never disposes of the Session.

When a user application logs out, and that's done entirely from within an ICEfaces servlet, the incoming HttpServlet is wrapped in an InterceptingServletSession, which overrides invalidate() and uses this to notify the SessionDispatcher. In the Portlet example, the request to log out is handled by the Portal application, outside the ICEfaces servlet path which is why this mechanism is subverted.

The ContextEventRepeater gets notified of the SessionDestroyed event, but the SessionDispatcher is not a client of the repeater. It may be possible to make the Dispatcher an event listener but care must be taken and difficult to verify differences in timing may occur, since the ContextEventRepeater is downstream of the events generated by the SessionDispatcher.

I attached a patch for this issue. SessionDispatcher is now notified when the session is invalidated by the portal. It is using the same session shutdown sequence as the one used when session is invalidated internally.

I found the patch to work fine for the issue of the IllegalStateExceptions. The Views are disposed by the SessionDispatcher who also removes the Session from its SessionMap.

But the application now had a slightly different problem. There were instances of PersistentFacesState still being rendered when the user interacted with the application in the above way. These were detected by seeing FatalRenderingExceptions in a code branch that tested whether the PFState object was already disposed on entering the execute and render methods.

It turns out that the threadLocal variable in the PersistentFacesState objects can be set 'entering' the execute and render methods. This is a bit unexpected from the work in 1.7 where we checked threadLocal variable status on exiting the MainServlet and exiting the RunnableRender.run() method. Anyway, if the ThreadLocal is non-null on entry, it's not going to be cleared because an exception is thrown, and the cycle would continue the next time someone interacted with the application.

I've checked in a couple of lines that clears the PersistentFacesState thread local in this code path.

Tested with 1.7 branch.

I'm still having issues with long gone http sessions related data keeping in the memory.
After some load testing the JVM's CMS Old gen is filled to the max and "[com.icesoft.util.MonitorRunner] Failed to run monitor: null" is printed to log.

Also in a heapdump generated by jmap ( no activity on the server, all users logged out) there are still instances of IceFaces components (and some others too);

Object Histogram:

num #instances #bytes Class description
--------------------------------------------------------------------------
1: 1128218 562200216 char[]
2: 66617 220418688 byte[]
3: 506870 62469240 java.lang.Object[]
4: 294296 50821464 java.util.HashMap$Entry[]
5: 1203744 48149760 java.lang.String
6: 655296 36696576 java.util.HashMap$Entry
7: 259976 36408944 * ConstMethodKlass
8: 259976 31209920 * MethodKlass
9: 477604 26745824 org.apache.xerces.dom.AttrImpl
10: 20310 24144616 * ConstantPoolKlass
11: 230341 22112736 org.apache.xerces.dom.ElementImpl
12: 115115 17497480 java.lang.reflect.Method
13: 234893 16912296 java.util.HashMap
14: 20310 16597248 * InstanceKlassKlass
15: 265972 14311280 * SymbolKlass
16: 16999 13846848 * ConstantPoolCacheKlass
17: 64748 10392800 int[]
18: 23498 9399200 com.icesoft.faces.component.ext.HtmlPanelGrid
19: 230089 9203560 org.apache.xerces.dom.AttributeMap
20: 117920 8490240 java.util.LinkedHashMap$Entry
21: 212176 8487040 java.util.Vector
22: 141765 6804720 java.util.concurrent.locks.ReentrantLock$NonfairSync
23: 141572 6795456 java.util.concurrent.ConcurrentHashMap$Segment
24: 96064 6148096 javax.servlet.jsp.tagext.TagAttributeInfo
25: 150502 6020080 java.util.ArrayList
26: 122127 5862096 java.lang.ref.WeakReference
27: 97606 5465936 java.lang.ref.SoftReference
28: 96999 5423528 java.lang.String[]
29: 141572 5104296 java.util.concurrent.ConcurrentHashMap$HashEntry[]
30: 14951 5023536 com.icesoft.faces.component.ext.HtmlOutputText
31: 61876 4455072 com.icesoft.faces.context.DOMContext
32: 48453 4263864 java.util.LinkedHashMap
33: 7173 4231696 * MethodDataKlass
34: 43430 4169280 java.beans.MethodDescriptor
35: 21642 3982128 java.lang.Class
36: 28371 3631488 java.lang.reflect.Field
37: 31769 3244968 * System ObjArray
38: 4271 3143456 com.icesoft.faces.component.selectinputtext.SelectInputText
39: 64053 3074544 javax.faces.component.UIComponentBase$ChildrenList
40: 74762 2990480 javax.faces.component.UIComponentBase$AttributesMap
41: 14178 2495328 org.springframework.beans.GenericTypeAwarePropertyDescriptor
42: 57954 2318160 com.liferay.portlet.Preference
43: 25960 2294552 short[]
44: 16706 2138368 java.beans.PropertyDescriptor
45: 23432 2062016 java.util.TreeMap$Node
46: 10719 2058048 com.liferay.portal.model.impl.LayoutImpl

I'll create another issue to track this issue.