OK some updates. I compiled this afternoon off of the tomcat 8.5.x branch
and made changes to SmapUtil.java around line 206 give or take.
The changes were basically
if (!tmpFile.renameTo(...)) {
Files.move(tmpFile.toPath(), classFile.toPath(),
StandardCopyOption.REPLACE_EXISTING);
}
Variables:
- Environmental, there was a reboot in between test scenarios
- Moving from 8.5.40 to head
Result:
At first it was promising that i thought it may have been fixed, however I
did run into another exception with the Files.move call, exception was
file exists already. Previously, it was maybe 1/100 jsps, now it's closer
to 1 of 400. Definitely better, but is it because of the update to the
newer
code base or is it due to the code change i made. I'll do some more
experiments tomorrow to try and narrow it down
On Mon, Jun 10, 2019 at 3:32 PM Alex O'Ree <alexo...@apache.org> wrote:
> > Anything unusual about that file system?
>
> Nope, just a standard NTFS windows 7 setup. I've seen in a development
> environment (no special file permissions) and in more of a production
> environment on win10 and server 2016 whereby the file system is locked down
> in a similar fashion to how it's done on linux.
>
> > How much load (users, req/s) is the system under?
>
> In terms of the jsp error, this particular app is typically just a single
> user hitting it. There's lots of other non-jsp traffic to the server
> though. I've also seen this error a lot in my dev setup.
>
> > Any changes from default JSP Servlet (Jasper) settings?
>
> none
>
> > Does the access log indicate concurrent access for the problematic
> resources?
>
> Well. It's happening pretty frequently during a controlled set of selenium
> unit tests. It's a single browser session doing http get's to all the jsp
> pages one at a time, primarily just to ensure that they compile correctly.
> Shouldn't be an concurrent sessions on this context.
>
> > Alex, are you able to edit the code and replace the File.renameTo call
> with an equivalent Files.move and see if it's either (a) more reliable
> or (b) gives you better error information?
>
> Yes I can give it a try.
>
> > One more idea. Virus scanner locking files?
>
> I've seen it on systems with and without a/v. On the system with it, I was
> able to temporarily disable it but still got on the tmp.rename error.
>
>
> On Mon, Jun 10, 2019 at 2:48 PM Mark Thomas <ma...@apache.org> wrote:
>
>> On 10/06/2019 12:08, Alex O'Ree wrote:
>> > I am on windows 7. Same partition as the os.
>>
>> Hmm. That is odd. A few random (ish) questions:
>>
>> Anything unusual about that file system?
>>
>> How much load (users, req/s) is the system under?
>>
>> Any changes from default JSP Servlet (Jasper) settings?
>>
>> Does the access log indicate concurrent access for the problematic
>> resources?
>>
>> Mark
>>
>>
>> >
>> > On Mon, Jun 10, 2019, 3:20 AM Mark Thomas <ma...@apache.org> wrote:
>> >
>> >> On 07/06/2019 15:35, Alex O'Ree wrote:
>> >>> HTTP Status 500 – Internal Server Error
>> >>> Type Exception Report
>> >>>
>> >>> Message Unable to compile class for JSP
>> >>>
>> >>> Description The server encountered an unexpected condition that
>> >>> prevented it from fulfilling the request.
>> >>
>> >> Not as helpful as I had hoped.
>> >>
>> >> Given that the issue is random and that immediately retrying usually
>> >> works that tends to rule out permission issues.
>> >>
>> >> Where is the work directory located? If it is anywhere other than local
>> >> disk that might be the source of the problem.
>> >>
>> >> I'll look into improving those error messages a little (at least
>> provide
>> >> source and destination file names).
>> >>
>> >> Mark
>> >>
>> >>
>> >>>
>> >>> Exception
>> >>>
>> >>> org.apache.jasper.JasperException: Unable to compile class for JSP
>> >>>
>> >>
>> org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:610)
>> >>>
>> >>
>> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:399)
>> >>>
>> >>
>> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:386)
>> >>>
>> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:330)
>> >>> javax.servlet.http.HttpServlet.service(HttpServlet.java:742)
>> >>>
>> >> org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
>> >>>
>> >>
>> org.apache.logging.log4j.web.Log4jServletFilter.doFilter(Log4jServletFilter.java:71)
>> >>> Root Cause
>> >>>
>> >>> java.io.IOException: tmpFile.renameTo(classFile) failed
>> >>>
>> >>
>> org.apache.jasper.compiler.SmapUtil$SDEInstaller.install(SmapUtil.java:204)
>> >>>
>> org.apache.jasper.compiler.SmapUtil.installSmap(SmapUtil.java:163)
>> >>>
>> >>
>> org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:564)
>> >>> org.apache.jasper.compiler.Compiler.compile(Compiler.java:378)
>> >>> org.apache.jasper.compiler.Compiler.compile(Compiler.java:350)
>> >>> org.apache.jasper.compiler.Compiler.compile(Compiler.java:334)
>> >>>
>> >>
>> org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:595)
>> >>>
>> >>
>> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:399)
>> >>>
>> >>
>> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:386)
>> >>>
>> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:330)
>> >>> javax.servlet.http.HttpServlet.service(HttpServlet.java:742)
>> >>>
>> >> org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
>> >>>
>> >>
>> org.apache.logging.log4j.web.Log4jServletFilter.doFilter(Log4jServletFilter.java:71)
>> >>> Note The full stack trace of the root cause is available in the server
>> >> logs.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> On Fri, Jun 7, 2019 at 4:58 AM Mark Thomas <ma...@apache.org> wrote:
>> >>>
>> >>>> On 06/06/2019 20:38, Alex O'Ree wrote:
>> >>>>> I've upgraded from .34 to .40 somewhat recently (on windows) and
>> have
>> >>>> been
>> >>>>> getting random errors rendering jsp pages recently. The trace is
>> always
>> >>>>> related to jasper failing to rename a file. I'm not really sure what
>> >> the
>> >>>>> issue is. Has anyone seen this or something similar?
>> >>>>>
>> >>>>> Usually retrying the request resolves the issue immediately but
>> >> something
>> >>>>> seems fishy. This worked fine on previous versions.
>> >>>>
>> >>>> Can you provide a stack trace please.
>> >>>>
>> >>>> Thanks,
>> >>>>
>> >>>> Mark
>> >>>>
>> >>>> ---------------------------------------------------------------------
>> >>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> >>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>> >>>>
>> >>>>
>> >>>
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> >> For additional commands, e-mail: users-h...@tomcat.apache.org
>> >>
>> >>
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
