For more info:
Got same error on Tomcat 5.5.15. Using JDK 1.5.0_06.

Apparently other people have seen this bug before (but on another JVM):

http://mail-archives.apache.org/mod_mbox/tomcat-dev/200403.mbox/%3C406AADCC.7020003@ruc.dk%3E

We have the same problem. I think I managed to find out the cause: it only
happens if the JSP itself throws FileNotFoundException. So in order to
reproduce: have only one JSP in your Webapp like so:

<%!
  java.util.Random r = new java.util.Random();
%><% if(r.nextInt(10) > 0) throw new java.io.FileNotFoundException(); %>

and put some concurrent load on that JSP.

Evaluation: Jasper has a rather big catch block in JspServletWrapper.java and
will interpret any FNFE as an indication that the JSP itself has disappeared. It
will remove the JspServletWrapper which triggers a recompilation.

I'm pretty sure there is a race condition in that recompilation code that causes
two concurrent compilations for the same file. These two compilations would
fight over the generated files and lead to the observed bug. See the thread dump
below (taken after SDEInstaller hit a breakpoint in the offending line): two
compilations with different OIDs for JSPServletWrapper although the webapp has
only one JSP.


"http-16001-Processor22" daemon prio=10 tid=0x00764340 nid=0x23 waiting on
condition [0xedb7e000..0xedb7f9f0]
        at java.io.IOException.<init>(IOException.java:40)
        at java.io.FileNotFoundException.<init>(FileNotFoundException.java:46)
        at
org.apache.jasper.compiler.SmapUtil$SDEInstaller.<init>(SmapUtil.java:248)
        at
org.apache.jasper.compiler.SmapUtil$SDEInstaller.install(SmapUtil.java:236)
        at org.apache.jasper.compiler.SmapUtil.installSmap(SmapUtil.java:163)
        at org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:429)
        at org.apache.jasper.compiler.Compiler.compile(Compiler.java:472)
        at org.apache.jasper.compiler.Compiler.compile(Compiler.java:451)
        at org.apache.jasper.compiler.Compiler.compile(Compiler.java:439)
        at
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:511)
        at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:295)
        - locked <0xf1320090> (a org.apache.jasper.servlet.JspServletWrapper)


"http-16001-Processor25" daemon prio=10 tid=0x00767a50 nid=0x26 runnable
[0xed87d000..0xed87fc70]
        at java.net.URLStreamHandler.setURL(URLStreamHandler.java:505)
        at java.net.URLStreamHandler.parseURL(URLStreamHandler.java:283)
        at sun.net.www.protocol.file.Handler.parseURL(Handler.java:50)
        at java.net.URL.<init>(URL.java:596)
        at java.net.URL.<init>(URL.java:464)
        at java.net.URL.<init>(URL.java:413)
        at java.net.JarURLConnection.parseSpecs(JarURLConnection.java:161)
        at java.net.JarURLConnection.<init>(JarURLConnection.java:144)
        at
sun.net.www.protocol.jar.JarURLConnection.<init>(JarURLConnection.java:61)
        at sun.net.www.protocol.jar.Handler.openConnection(Handler.java:24)
        at java.net.URL.openConnection(URL.java:943)
        at java.net.URL.openStream(URL.java:1007)
        at
org.apache.catalina.loader.StandardClassLoader.getResourceAsStream(StandardClassLoader.java:679)
        at java.lang.Class.getResourceAsStream(Class.java:1998)
        at org.apache.tools.ant.ComponentHelper.initTypes(ComponentHelper.java:741)
        at
org.apache.tools.ant.ComponentHelper.initDefaultDefinitions(ComponentHelper.java:247)
        at org.apache.tools.ant.Project.init(Project.java:262)
        at org.apache.jasper.compiler.Compiler.getProject(Compiler.java:116)
        at org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:320)
        at org.apache.jasper.compiler.Compiler.compile(Compiler.java:472)
        at org.apache.jasper.compiler.Compiler.compile(Compiler.java:451)
        at org.apache.jasper.compiler.Compiler.compile(Compiler.java:439)
        at
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:511)
        at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:295)
        - locked <0xf0c4d448> (a org.apache.jasper.servlet.JspServletWrapper)
        at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292)

Also found this problem with Tomcat 5.5.4 on Windows 2000 Professional.

(In reply to comment #2)
> We have the same problem. I think I managed to find out the cause: it only
> happens if the JSP itself throws FileNotFoundException. So in order to
> reproduce: have only one JSP in your Webapp like so:
> 
> <%!
>   java.util.Random r = new java.util.Random();
> %><% if(r.nextInt(10) > 0) throw new java.io.FileNotFoundException(); %>
> 
> and put some concurrent load on that JSP.
> 

I have seen this problem where the jsp does NOT have any code that throws a
FileNotFoundException. I do not believe this is the source of the problem.

I've seen the problem with Tomcat 5.0.28 with j2sdk1.4.2_05.

Not that a browser refresh allows the JSP to compile correctly.

I tend to believe the race condition theory put forth by Matthias.  If one of
you wants to submit a patch for fix it, that'd be awesome.  Thanks.

I have also found this to occur in Tomcat 5.5.17 on both Windows XP and Windows
2003 Server. This causes some concern for my boss, and I'm not sure what to tell
him. Please fix this ASAP.

This bug is related to bad version of jstl.jar (for example old jstl and new
standard.jar)

This bug took a while to track down. I ended up changing the "fork" parameter to
true in the web.xml under Jasper <servlet-name>jsp</servlet-name> for Apache
Tomcat 5.5.17. My best guess is the problem must occur by sharing the JVM. When
the JVM is forked into two processes we no longer have the problem of sharing
files (ie, trying to rename a file while it's in use). I hope this helps someone
else because I stared at this for quite some time.

Thanks,
  Ron Ledwich

Thanks very much Ron Ledwich!  Your advice worked and saved me a lot of time!

Sincerely,
Java Man

(In reply to comment #8)
> This bug took a while to track down. I ended up changing the "fork" parameter to
> true in the web.xml under Jasper <servlet-name>jsp</servlet-name> for Apache
> Tomcat 5.5.17. My best guess is the problem must occur by sharing the JVM. When
> the JVM is forked into two processes we no longer have the problem of sharing
> files (ie, trying to rename a file while it's in use). I hope this helps someone
> else because I stared at this for quite some time.
> 
> Thanks,
>   Ron Ledwich

I have the same problem using tomcat bundled with JBoss 4.0.4. fork=true did not
solve the problem for me.

(In reply to comment #4)

> I have seen this problem where the jsp does NOT have any code that throws a
> FileNotFoundException. I do not believe this is the source of the problem.

It may not be obvious. Our code would include markup from a different server via
HTTPUrlConnection. A 404 on the target is translated into a
FileNotFoundException. 404s, FNF and compilation problems are clearly correlated
in our case.

I've looked at the synchronization code for JSP compilation before and a small
patch won't do, I'm afraid.

Updating version to 5.5.17, the latest reported, and severity to normal.  If
anyone can post attach a simple test WAR file to this Bugzilla page that will
let us reproduce the issue, that'd be awesome.

It happens also in 5.5.20
In our case it happens with jsp:include though I am not sure it is related.

Hi all - in XP the reason this was happening for us was because the overall file
path of the file with an extension of .classtmp was > 256 characters long and
the rename would not work. We had the problem in tomcat within jboss, so
renaming the location of the jboss server to give us a filepath of <256 fixed
the problem.

(In reply to comment #14)
> Hi all - in XP the reason this was happening for us was because the overall file
> path of the file with an extension of .classtmp was > 256 characters long and
> the rename would not work. We had the problem in tomcat within jboss, so
> renaming the location of the jboss server to give us a filepath of <256 fixed
> the problem.
> 
> 
This was the solution for me running Tomcat 5.5.12 on WinXp with java 1.4.2_09

I've seen this sporadically over the years. Most recently with 5.5.23 on Win XP.
It's not readily reproducable at will, as it seems to depend on the timing of
things. My most recent cases were when my computer was responding very
sluggishly due to having a lot of applications running sucking up lots of system
resources (and probably a bit of page thrashing). The race condition during
compiling sounds convincing to me. FWIW, here's a portion of my stacktrace:

java.io.IOException: tmpFile.renameTo(classFile) failed
	at org.apache.jasper.compiler.SmapUtil$SDEInstaller.install(SmapUtil.java:246)
	at org.apache.jasper.compiler.SmapUtil.installSmap(SmapUtil.java:165)
	at org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:450)
	at org.apache.jasper.compiler.Compiler.compile(Compiler.java:298)
	at org.apache.jasper.compiler.Compiler.compile(Compiler.java:277)
	at org.apache.jasper.compiler.Compiler.compile(Compiler.java:265)
	at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:564)
	at
org.apache.jasper.servlet.JspServletWrapper.loadTagFile(JspServletWrapper.java:204)
	at
org.apache.jasper.compiler.TagFileProcessor.loadTagFile(TagFileProcessor.java:516)
	at org.apache.jasper.compiler.TagFileProcessor.access$000(TagFileProcessor.java:49)
	at
org.apache.jasper.compiler.TagFileProcessor$TagFileLoaderVisitor.visit(TagFileProcessor.java:567)
	at org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1442)
	at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2164)
	at org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2214)
	at org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2325)
	at org.apache.jasper.compiler.Node$UninterpretedTag.accept(Node.java:1186)
	at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2164)
	at org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2214)
	at org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2325)
	at org.apache.jasper.compiler.Node$UninterpretedTag.accept(Node.java:1186)
	at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2164)
	at org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2214)
	at org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2325)
	at org.apache.jasper.compiler.Node$UninterpretedTag.accept(Node.java:1186)
	at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2164)
	at org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2214)
	at org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2325)
	at org.apache.jasper.compiler.Node$UninterpretedTag.accept(Node.java:1186)
	at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2164)
	at org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2214)
	at org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2345)
	at org.apache.jasper.compiler.Node$JspBody.accept(Node.java:1896)
	at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2164)
	at org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2214)
	at
org.apache.jasper.compiler.TagFileProcessor$TagFileLoaderVisitor.visit(TagFileProcessor.java:571)
	at org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1442)
	at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2164)
	at org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2214)
	at org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2225)
	at org.apache.jasper.compiler.Node$JspRoot.accept(Node.java:526)
	at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2164)
	at org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2214)
	at org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2220)
	at org.apache.jasper.compiler.Node$Root.accept(Node.java:457)
	at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2164)
	at
org.apache.jasper.compiler.TagFileProcessor.loadTagFiles(TagFileProcessor.java:585)
	at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:179)
	at org.apache.jasper.compiler.Compiler.compile(Compiler.java:296)
	at org.apache.jasper.compiler.Compiler.compile(Compiler.java:277)
	at org.apache.jasper.compiler.Compiler.compile(Compiler.java:265)
	at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:564)
	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:299)
	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:315)
	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:265)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)

See http://issues.apache.org/bugzilla/show_bug.cgi?id=2500. 
Does the fixing of bug 2500 make this problem go away?

Hi,
We are getting the same error in our Web app which runs on sun one 7.0 web 
server.

In our case, we have a jsp file that has a <%@include file= .. > to another 
jsp file.

We can see the .classtmp file for this jsp in the web server. 
None of the solutions given in this post have worked for us so far.

Has anyone faced a similar situation with sun one before? Please suggest a way 
forward.

We are running on Windows but had the same scenario: a jsp file that has a
<%@include file= .. > to another jsp file.

It seemed that one possibility was the JSPs being compiled in the wrong order.
So we created an ANT task that we run when we deploy the web app to the server.
The ANT task compiles all the .jsp files, except those included ones.

For the included files, we renamed them to a different extension .jspinc and
these are not precompiled individually, but they do get compiled inline with the
files that include them.

Hi Brian,
Thanks for replying.
As far as I can understand, you are precompiling the jsps before deploying. 
But we depend on the server to compile them at run time. 
Also, while looking into this issue, we found that when ever this error 
occurs, a file with an extension .classtmp exists in the work folder. 

And we have also found that when ever the size of the compiled servlet is 
below a particualr limit which is around 32KBs it is fine. But when the size 
exceeds this limit, we get the error.

Is there any such limit to the sizes of the class files? if so, how can we 
remove this constraint? or is there any other way out? Will <%jsp:include> tag 
help?

(In reply to comment #19)
> We are running on Windows but had the same scenario: a jsp file that has a
> <%@include file= .. > to another jsp file.
> It seemed that one possibility was the JSPs being compiled in the wrong 
order.
> So we created an ANT task that we run when we deploy the web app to the 
server.
> The ANT task compiles all the .jsp files, except those included ones.
> For the included files, we renamed them to a different extension .jspinc and
> these are not precompiled individually, but they do get compiled inline with 
the
> files that include them.

Using the test case provided by Matthias Ernst in comment#2 I can reproduce this on 5.5.23 in about 5 seconds using JMeter configured with 20 threads.

With the latest 5.5.x code I can't reproduce this even if I hammer the test JSP with with 250 threads for several minutes.

As Jonathan Leech suggests in comment#17 it looks very much like the fix for bug2500 also fixed this issue. That fix is in 5.5.25 onwards.