0

I have an embedded Jetty application where Jetty is providing 2 things:

  • Serving some HTML/JS files
  • Exposing a REST API that my Java Servlet is supporting

The JS files are making REST calls to the servlet. Everything works beautifully.

What I've noticed is that after about a week of running, the API still functions, but if I try to get an HTML file I get the following:

<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8"/>
<title>Error 404 Not Found</title>
</head>
<body><h2>HTTP ERROR 404</h2>
<p>Problem accessing /web/. Reason:
<pre>    Not Found</pre></p><hr><a href="http://eclipse.org/jetty">Powered by Jetty:// 9.4.4.v20170414</a><hr/>

</body>
</html>

What could be going wrong here?

Not sure if this is meaningful, but I'm deploying this in an Amazon AWS EC2 instance. I can't imagine that EC2 is doing somethig to make the /web directory disappear.

Sander Smith
  • 1,371
  • 4
  • 20
  • 30

1 Answers1

4

I assume that your XML-fragment setting up the web application looks something like this:

<Call name="addHandler">
    <Arg>
        <New class="org.eclipse.jetty.webapp.WebAppContext">
            <Set name="contextPath">/</Set>
            <Set name="war">./path/to/webapp.war</Set>
            <Set name="extractWAR">True</Set>
            <Set name="copyWebInf">True</Set>
        </New>
    </Arg>
</Call>

What happens is that the content of the war is extracted into a directory in the temporary directory specified by the System Property java.io.tmpDir. Without setting this directory yourself, this is the operating system's temporary directory, e.g. /tmp on Linux. This is done once during startup and assumed that the directory exists during the whole time the process is running.

On Linux systems you often have a cron job that is deleting old entries in /tmp "taking care" of these still important directories needed by Jetty leading to these errors. The servlets are still accessible since they are java classes loaded by the class loader, so the removal of the jars where they were originally loaded from, doesn't matter (except of course you try to access a servlet that hasn't been accessed before).

A solution for this is specifying java.io.tmpDir yourself, pointing to a directory under your own control.

Lothar
  • 5,323
  • 1
  • 11
  • 27
  • No XML code, but I programmatically do exactly the same things to set it up. What you suggest makes perfect sense. Unfortunately, this application is going to be deployed to lots of environments (Windows, RaspPi Linux, Amazon EC2 Linux, etc.) each with their own quirks. Is there something I can set the temp dir to that will work everywhere? Thanks so much for your help. (and quick!) – Sander Smith Sep 04 '17 at 16:35
  • 1
    @Sander We use Jetty in our application so we have control of the installation and set `java.io.tmpDir` accordingly to make sure that problem no longer happens. A short Google search came up with https://stackoverflow.com/questions/19232182/jetty-starts-in-c-temp/19232771#19232771 Maybe that helps fo your – Lothar Sep 04 '17 at 19:05
  • @SanderSmith Alternatively you can try to set `extractWAR` to `false` (keep `copyWebInf` to `true` otherwise your servlets will most likely not work anymore if Jetty hasn't fixed that, yet). This should keep the static stuff out of the file system. But I haven't tried that in practice so this is just a guess. – Lothar Sep 04 '17 at 19:10