Very slow JSP initialisation

[keithhb]

I am using JBoss 2.4.4 with embedded Tomcat 4.0.1, on a Win2K machine (PIII 866MHz with 512MB RAM).

My web app is running fine, except for one thing: each time you request any JSP, it takes between 3 and 5 seconds to load! This is the time between the STRUTS Action servlet forwarding to a JSP and the

web.catalina.EmbeddedCatalinaServiceSX - jsp: init

log message appearing, so I assume that this time is spent in Tomcat loading the page. From the log I can see that the servlet processing prior to this point (including EJB use and JavaSpace access), and the JSP processing afterwards (including tags) take a few ms only.

All servlets and JSPs are set to load on startup, and I can also see from the log that this is happening.

I have set the JVM options for JBoss to use a minimum of 128MB and a maximum of 256MB (-Xms128m -Xmx256m).

If anyone has any ideas what could be causing this I would be very grateful indeed.

Best wishes
Keith

[wchao]

I think that Struts has to compile each file upon request, so even though you have turned on the option to load all servlets and JSPs on startup, it may not include everything when you use something like Struts or Tiles. You should probably manually make a first request on all the important pages. Either that, or write a script that does it for you.

[keithhb]

Thanks very much for the suggestion. The load on startup was working, though, since I could see from the log that the init method in each JSP had run during JBoss startup. Presumably this means that they had compiled.

I have been plugging away at it, and found in the end that the problem was caused by having an RMI Security Manager set in the VM.

I have changed the code to set the security manager just before it is needed for loading classes, and unset it afterwards - now all the JSPs load instantly.

I do not really understand why this works, though. I think it is something to do with JspServlet, which loads various classes in its init method if a security manager is set. However, the section in its init method which does this should record a "first time" flag and not load the classes again after that point.

Beyond me. Works now, anyway.

[mister_fab]

Hi,

I hae the same problem and I would like to try your
workaround. Could you be more specific on the modifications
you have done ?

thank you.

f.

[lasterra]

The same for me.

Please post yout solution.

Regards, Enrique.

[keithhb]

My apologies for not replying sooner - I haven't checked this forum for a long time. Someone emailed me today to ask about it, though.

I did not modify Tomcat or JBoss at all. All I did, was to change my own code. This dynamically loads classes in various places, particularly when acting as an RMI client. When doing dynamic class loading, you should have a security manager set in the JVM.

It is not actually the responsibility of the application developer to ensure this, but of the deployer. However, RMI invocation in particular may not work unless you have a security manager set. So I check in the code that a security manager is set, with a statement such as:

if (System.getSecurityManager() == null) {
System.setSecurityManager(new RMISecurityManager());
}

This was causing the JSP problem, for some reason. Tomcat seems not to behave very sensibly if you have a security manager set. I think the reason that not many people come across this, is because most people have abandoned RMI for EJBs, and use J2EE security rather than standard Java 2 security (although they have quite different purposes).

Anyway, my initial solution to the problem was to unset the security manager after loading any classes, with a statement like:

System.setSecurityManager(null);

Then Tomcat behaves properly again, since the security manager is not in existence when the JSPs are loaded.

However, this is NOT a correct approach, and I have abandoned it. You should not really set and unset a security manager from within your code at all - as I said above, it is up to the deployer to set the security manager.

So I have switched to JBoss 3 and use the Jetty servlet container rather than Tomcat, which does not seem to suffer from the same problem. Now, all I have to do with regard to a security manager, is to do a single check on application initialisation, of the same form as above:

if (System.getSecurityManager() == null) {
System.setSecurityManager(new RMISecurityManager());
}

It may be that Tomcat 4.1 has fixed the problem, but I don't know.

Hope this helps.