JSF: Mojarra vs. OmniFaces @ViewScoped: @PreDestroy called but bean can't be garbage collected

Question

This question is specific to the OmniFaces @ViewScoped bean (however of interest to wider discussion about memory leakage and resource disposal with JSF @ViewScoped). It is based on the results of this NetBeans8.1 test web app available on GitHub:

Investigation of undesirable holding of references to various forms of JSF @ViewScoped beans by navigation type

https://github.com/webelcomau/JSFviewScopedNav

That test web app has a comprehensive README with complete instructions, as well as annotated test web pages comparing obsolete JSF2.0-style @ManagedBean @ViewScoped, JSF2.2-style CDI-friendly @Named @ViewScoped, and OmniFaces @Named @ViewScoped beans.

The results using JVisualVM for diagnosis are summarised in a downloadable spreadsheet (see also screenshot below), and indicate that while the OmniFaces-2.5.1 @ViewScoped bean invokes @PreDestroy methods under GET-based navigation cases when leaving a view (giving the opportunity to release most resources), it does not seem to permit garbage collection of the actual bean (at least not with the current context parameter settings).

In web.xml the application is set to use:

com.sun.faces.numberOfViewsInSession 4

com.sun.faces.numberOfLogicalViews 4

By default this OmniFaces-specific parameter is commented out:

org.omnifaces.VIEW_SCOPE_MANAGER_MAX_ACTIVE_VIEW_SCOPES

The javax.faces.STATE_SAVING_METHOD defaults to 'server'.

---

The main question is:

Q1: Is it correct that these OmniFaces @ViewScoped beans can't by design be garbage collected "live" (meaning through say provocation using a Profiler's garbage collectiong action, not waiting until a session is over) ?

Q2: If this is so, how can (should) one best force release of them on navigating away from pages (especially under GET navigations) ?

Q3: If not so (if my results are incorrect because of some other setting) why aren't I witnessing provoked garbage collection of them, and what can I do to ensure they are indeed automatically released ?

Since the test web app is downloadable, well documented and hopefully self-explanatory, I won't give code here, but simply the comparitive results so far, as well as screenshots of the test web app pages in action:

Photocomposition

Partially related (only, NOT duplicates): My own more general question (not specific to OmniFaces) How detect and remove (during a session) unused @ViewScoped beans that can't be garbage collected. And Memory implications of OmniFaces ViewScoped bean?, but does not seem to distinguish between @PreDestroy and garbage collection. – Photocomposition

Answer 1

The cause of this problem seems to be due to strange behaviour JVisualVM when attached to Glassfish/Payara.

The test case used for this question is still extremely useful, however the conclusions concerning Garbage Collection in the original post (and images) were based on JVisualVM, and I have since found they are not valid.

Use the NetBeans Profiler instead !

I am now getting completely consistent results for OmniFaces ViewScoped with the test app on forcing GC from within the NetBeans Profiler (with 1 omnifaces view scoped bean left per open tab).

When using JVisualVM attached to GlassFish/Payara I am getting references still held (even after @PreDestroy called) by field sessionListeners of type com.sun.web.server.WebContainerListener within ContainerBase$ContainerBackgroundProcessor, and they won't GC.

The image shows a screenshot of JVisualVM attached to Payara with only 1 tab open but still 9 OmniViewBean instances held, no matter how often GC is forced.

---

Updated results table using Mojarra-2.3.0 vs OmniFaces-2.6.6 in NetBeans IDE 8.2 Profiler

Updated test app sequence:

---

---

---

---

Photocomposition