Home/ Questions/Q 724581
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-14T06:14:19+00:00

I’ve got an application leaking out java heap at a decent rate (400 users

  • 0

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!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0