-
Bug
-
Resolution: Fixed
-
Major
A thread dump showed many HTTP threads doing something like this:
"Handling POST /job/.../ajaxExecutors : ... java.lang.Thread.State: RUNNABLE at java.io.UnixFileSystem.getBooleanAttributes0(Native Method) at java.io.UnixFileSystem.getBooleanAttributes(UnixFileSystem.java:242) at java.io.File.exists(File.java:772) at org.apache.naming.resources.FileDirContext.file(FileDirContext.java:785) at org.apache.naming.resources.FileDirContext.lookup(FileDirContext.java:206) at org.apache.naming.resources.ProxyDirContext.lookup(ProxyDirContext.java:299) at org.apache.catalina.core.ApplicationContext.getResource(ApplicationContext.java:495) at org.apache.catalina.core.ApplicationContextFacade.getResource(ApplicationContextFacade.java:176) at org.kohsuke.stapler.Stapler.openResourcePathByLocale(Stapler.java:207) at org.kohsuke.stapler.Stapler.service(Stapler.java:147) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
If the container's implementation of ServletContext.getResource is slow to return a negative result, as it seems Tomcat's is, we waste a considerable amount of time (and disk I/O) looking for files which clearly do not exist before serving a request from the Stapler model. Probably if this method once returns null it is safe to assume it will continue to do so for the rest of the session.