Memory Leak in WebSphere Portal Relating to Portal URIs

Question

I've got an application leaking out java heap at a decent rate (400 users leaves 25% free after 2hours...after logoff all memory is restored) and we've identified the items causing the memory leak as Strings placed in session that appear to be generated by Portal itself. The values are the encoded Portal URIs (very long endcoded strings ... usually sized around 19kb), and the keys seem to be seven (7) randomly generated characters prefixed by RES# (for example, RES#NhhEY37).

We've stepped through the application using session tracing and snapping off heapdumps which has resulted in determining that there is one of these objects created and added to session on almost every page ... in fact, it seems like it is on each page that submits data (which is most pages). So, it's either 1:1 with pages in general, or 1:1 with forms.

Has anyone encountered a similar problem as this? We are opening a ticket with IBM, but wanted to ask this community as well. Thanks in advance!

Answer 1

Can it be the portlet cache? You could have servlet caching activated and declare a long portlet expiry time. Quoting from techjournal:

Portlets can advertise their ability to be cached in the fragment cache by setting their expiry time in their portlet.xml descriptor (see Portlet descriptor example)

<!-Expiration value is in seconds, -1 = no time limit, 0 = deactivated-->
    <expiration-cache>3600</expiration-cache> <!- 1 Hour cache -->

To use the fragment caching functions, servlet caching needs to be activated in the Web Container section of WebSphere Application Server administrative console (see Portlet descriptor example). WebSphere Application Server also provides also a cache monitor enterprise application (CacheMonitor.ear), which is very useful for visualizing the contents of the fragment cache.

Update

Do you have portlets that set EXPIRATION_CACHE? Quote:

Modifying the local cache at runtime For standard portlets, the portlet window can modify the expiration time at runtime by setting the EXPIRATION_CACHE property in the RenderResponse, as follows:

RenderResponse.setProperty(
    PortletResponse.EXPIRATION_CACHE,
    (new Integer(3000)).toString() );

Note that for me the value is a bit counter-intuitive, -1 means never expire, 0 means don't cache.

Answer 2

Is your Websphere Portal Server having latest fix pack installed?

http://www-01.ibm.com/support/docview.wss?uid=swg24024380&rs=0&cs=utf-8&context=SSHRKX&dc=D420&loc=en_US&lang=en&cc=US

Also you may be interested in following discussion

http://www.ibm.com/developerworks/forums/thread.jspa?messageID=14427700&tstart=0

Update:

Just throwing some blind folded darts.

• "RES#" to me sounds like resource.
• From the forum stack trace, "DefaultActionResultManager.storeDocument" indicates it is storing the document.

Hence looks like your resources(generated portal pages) are being cached. Check if there is some paramater that can lmit cache size of resource.

Also in another test set cache expiration to 5 minutes instead of an hour.

Answer 3

The actual issue turned out to be a working feature within Portal. Specifically, Portal's action protection which prevents the same action from being submitted twice, while keeping the navigational ability of the portal. There is a cache that retains the actions results for every successful action and uses them to compare and reject duplicates.

The issue for us was the fact that we required "longer than normal" user sessions (60+ minutes) and with 1,000+ concurrent users, we leaked out on this protection mechanism after just a couple hours.

IBM recommended that we just shut off the cache entirely using the following portlet.xml configuration entry:

wps.multiple.action.execution = true

This allows double submits, which may or may not harm business functionality. However, our internal Portal framework already contained a mechanism to prevent double submits, so this was not an issue for us.

At our request, IBM did come back with a patch for this issue which makes the cache customizeable, that is, let's you configure the number of action results that you store in cache for each user and thus you can leverage Portal's mechanism again, at a reduced session overhead. Those portal configuration settings were:

wps.multiple.action.cache.bound.enabled = true
wps.multiple.action.cache.key.maxsize = 40
wps.multiple.action.cache.value.maxsize = 10

You'll need to contact IBM about this patch as it is not currently in a released fixpack.