JSF app extremely slow - too many ActionListeners?
I'm working on my first JSF app; my assignment is to prepare the next version of an existing app. Currently my testers are complaining that the app is *extremely* slow. I have observed that page loading takes a *very* long time; although it isn't nearly so sluggish on my local box (which of course gets bounced more frequently).
The env is JSF RI 1.1.0 (or 1.1_01, we tried both) running in Sun JES 8.2. Stepping through the debugger I have noticed that the LifecyleImpl maintains a list of ActionListeners. It seems that when the pages, which indirectly extend FacesBean, and have request scope, are constructed they are added to this list, and in the RenderResponsePhase are removed (in the FacesBean afterPhase() method).
However I am seeing this list growing very large (several hundred listeners), with multiple instances of the same classes. Is this normal/to be expected? It seems that this could be causing a performance drain with the number of times this list is iterated over. What could be causing the removePhaseListener() call to be skipped? What potential harm could be caused if I were to replace the LifecycleImpl with one that in removePhaseListener() removed all listeners of the specified class (rather than just the specified instance).
I appreciate any clues to what is happening, and how to properly correct it.
[1362 byte] By [
dderry650a] at [2007-11-26 16:16:11]
# 2
> Are you using creator to build your application?
No I'm not, but the original team did. So we are dependent on the jsfcl jar.
Actually, further investigation has revealed at least a part of the problem. And I have to (shamefacedly) admit that I am guilty of poor class structure. The application has a base page class that derives from FacesBean, and provides access to a number of things used throughout the app. I have a utility class that as a convenience extends the base page class in order to take advantage of those objects. But now that I have (at least a rudimentary) grasp on how the PhaseListeners get registered and deregistered, i see that this class will get registered every time one is constructed for use by an actual page. But since it is not itself a real page, it will not get deregistered.
My task for today is to refactor that class the way it should have been done in the first place. Then I'll connect to the app to see what other objects are hanging around in the listener list and see if they are also using improper inheritance.
Thanks
# 3
Well I've found something else, and it has me concerned.
The page, which is a PhaseListener, gets registered with Lifecycle when it is created for a request. But if there is an exception thrown before the RENDER_RESPONSE phase it in not deregistered, and remains in the Lifecycle listener list.
With a long running app (isn't that really *all* production web apps?) this listener list could grow quite large.
