A while back I ran into this problem while using Xagents, these are pseudo Lotus Notes Web Agents that are created by changing the <xp:view> tag’s rendered attribute to false and writing to the outputstream directly. I had an application that had a view where an end user could select several rows in a table and then perform an action on each of the selected items. Each item’s id was sent to an XAgent and then processed. In most cases it would work fine but occasionally I would run into this issue where after performing the action on some of the items, the xpage would stop working in some places, some of the partial refreshes would stop working and data that had been entered on the page would disappear. It took a while to track down, but what was happening made sense once I figured it out. The page stored several variables in viewScope and used the component tree extensively. Every time the xagent was being triggered a new tree was getting generated and the state would get saved to memory, XPages has a limit on how many of these trees it will keep in memory or on disk, these settings are found in the xsp.properties. The default limit for memory is 4 trees and 16 trees for disk per user session. This was a problem, It was very easy for an end user to take up all of the memory allotted for component tree state. This would override the original xpage that the user is looking at in memory and then xpages would have to rebuild it from scratch when its requested so anything loaded into the viewScope or into the component tree after the initialization would be lost.
There are a few solutions to this problem.
1. Up the limit in the xsp.properties file. This will increase the amount of ram/disk that your end users use and still might not solve the problem if they stay on the page continually performing the offensive action.
2. Change the xagent to some other type of component where state isn’t a problem such as a json-rpc control or an extension library custom rest control (since 8.5.3), or Domino Servlet
3. Write a Custom State Manager to override exactly when state is serialized and when its not, this was the road that I went down at first, one I plan on expounding upon later in my series on the XSP Starter Kit library.
4. The fourth option is the one that is the easiest and I have to thank my colleague Troy Reimer for pointing out the “viewState” attribute on the <xp:view> tag, if you set this attribute to “nostate” the xpage will be transient and its state will not be kept and the xagent will be rebuilt every time you load the page. This is exactly what I needed as I wasn’t storing anything in viewScope or using the component tree in this xagent, so turning off the state made perfect sense.
This is a fairly easy problem to solve and probably not one that comes up too often but when it does it come up if you don’t know what’s happening it might take a while to figure it out. I hope this post keeps someone in the future from dealing with the erratic behavior I was seeing in this app. The moral of the story is when you are writing an xagent or really any xpage related object think about state and the trees that could be loaded into memory.