Need to create test case and investigate.

Isn't this a potentially large memory leak?

Checked in a test case that indicates that the leak is not serious: only one extra object remains after
garbage collection and this may be due to the fact that ICEfaces maintains a request at all times.

svn commit . -m "test case for request scope beans not being garbage collected (ICE-556)"
Sending iraptor-webapp/conf/faces-config.xml
Adding iraptor-webapp/src/bug560
Adding iraptor-webapp/src/bug560/GarbageBean.java
Sending iraptor-webapp/src/bug560/TestBean.java
Adding iraptor-webapp/web/bug560.jsp
Transmitting file data ....
Committed revision 8698.

The way this test case works is with two beans, an application scope bean that counts instances and a
request scope bean that gets counted. The request scope bean increments the application scope bean
when it is initialized and decrements the application scope bean when it is finalized. After garbage
collection, only 1 instance of the request scope bean remains.

Does this test case capture the correct circumstance? Perhaps the original incident had a memory leak
within the application itself.

Deryk, please comment on whether this test case is missing some aspect of the original reported
configuration.

Deryk has created a test case to match his original observation. After some investigation, it appears that
"concurrentDOMViews" is the culprit (changing this to false eliminates the leak). Further investigation is
required to determine if the leak can be eliminated given the current implementation of
concurrentDOMViews.

ICEfaces maintains the request map as a "conversation" scope. With concurrentDOMViews it is not
possible to distinguish between multiple browser windows open and reloads in the current window;
hence multiple requests must be kept alive (potentially multiple conversations).

We should investigate the following:

• can a message be sent to the server upon page unload (even if this is unreliable, it would reduce the
  memory leak)
• can unused views (remaining from reloaded windows not multiple windows) be detected through the
  fact that their connection over Ajax is stale? (missing heartbeats)

Neither of these are simple memory leak fixes, however, so the safest action at this time may be to
defer this bug fix to a later release.

We'll have to document this in the KNOWN ISSUES for v1.0.1.

Basically, when using concurrentDOMViews, reloading the page or opening the app.
with more than one browser window will leave references to all request-scoped
beans, which will prevent their being garbage collected until the session expires.

Is this accurate? Also, is concurrentDOMViews enabled by default, and if so,
should it be given this leak?

concurrentDOMViews is not enabled by default.

Each open browser window and each reload of the current browser page results in a new persistent
request stored in the servlet session. Request-scope objects in these requests will not be garbage
collected until the session expires.

Ted,

This was left over from 1.0.1, any change for 1.1? Can we / did we fix it?

As far as I know, this has not been fixed.

Testing with ICE-556 and ICEfaces 1.5.2 shows that the requestMap under ICEfaces is behaving
according to design:

With concurrentDOMViews true, "world" instances increase in number when the page is reloaded. This
is due to the ICEfaces persistent request that remains due to the difficulty in distinguishing between
newly opened windows and reloaded windows (we will be able to develop techniques to address this,
but it is not a simple bug fix).

With concurrentDOMViews false, a single "world" instance is created for each reload and persists,
allowing the counter to be incremented even though the instance is in request scope.

With standardRequestScope true, the counter cannot be incremented because a new "world" instance is
created with each new request (as produced by clicking on the increment button).

There are at least two ways of improving the situation regarding this bug:

• use a conversation scope (from, say, Seam)
• detect browser window closing at the server and clean out requests corresponding to closed windows

As a first step we should look at how to propagate window closing events to the server. If window closing cannot be reliably propagated over the network at the moment of window closing, we may want to accumulate viewNumbers of closed windows in a cookie to propagate the closing event on the next exchange. (This may also present complications, however, as the browser will allow the user to close many windows simultaneously, and it may be difficult to update the cookie coherently.)

Ultimately, viewNumbers with unretrieved updates should be garbage collected.

Detect when browser windows are closed and disposed included views. Also, invoke listener to give a chance to applications to free up resources (such as connection, threads...).

This bug has been marked as fixed in 1.6DR#4. Can you please provide more information on the fix? I believe the issue still exists with 1.6DR#5. Does it require any specific configuration?

look like this is still hapening in the portlet version, request scope beans acts like session scope beans