The bug 🐛
We recently discovered a Session Pollution (Memory Leak) bug in HTML Dialogs. The bug (XIVY-6302) caused user sessions on the Axon Ivy Engine to consume more memory than necessary. After destroying a user session all allocated memory, including the superfluous one, got completely freed. This means the Engine was not using more and more memory over time. But it needed more memory than necessary to serve the current user sessions. The more user session the more memory was used needlessly.
We fixed this issue in Axon Ivy Engine 9.3, 8.0.17 and 7.0.24. However, also Ivy projects can have code that has a similar effect. We also had to fix the Portal (IVYPORTAL-12401). To eliminate session pollution you need to upgrade to one of the mentioned versions above and also to the corresponding Portal version.
Moreover, you should also check your own code in your Ivy projects:
Search for usages of the
binding property in JSF tags in all of your
*.xhtml files. Do not bind binding properties to HTML Dialog data class attributes nor JSF managed beans that are not request scoped (view, session, application scoped beans).
If you really need access to a UI component you should bind it to a request scoped bean instead a data class attribute or view, session or application scoped bean.
Search for usages of the
event variable in HTML Dialog Logic processes in all your *.mod files. Do not store the
event variable in HTML Dialog data class attributes nor JSF managed beans that are not request scoped (view, session, application scoped beans).
out.uploadEvent = event on a HTML Dialog event or method start process element
If you really need access to a JSF event use the
event variable directly, without storing it in a HTML Dialog data class attribute, or in a request scoped JSF managed bean.
How can you analyze that you fixed all session pollution problems 🧐
To test if you have fixed all session pollution problems in your projects, deploy your projects to an Axon Ivy Engine. Run all your tests on the engine (manually or automatically). Then stop all requests on the engine and use Visual VM to take a Histo Dump. Check if there are instances of the class
javax.faces.component.UIViewRoot in the Histo Dump. Note that instances of classes with the name
javax.faces.component.UIViewRoot$... are OK and can be ignored. If there are still instances of
javax.faces.component.UIViewRoot, run a garabage collection and take another Histo Dump. If no such instances are available anymore, you have fixed the problem. If instances are available, you are still suffering from session pollution. Take a Heap Dump and analyze, which of your classes still reference the
For more information about Histo Dump, Heap Dump and how to analyze them have a look at:
Troubleshoot Memory Problems