Temporary folder not fully cleanup after stop

Jeff,

What settings did you configure for the WebAppContext regarding the tmp directory and unpacking the war? For example, do you call any of the following:
+ setExtractWar(true)
+ setCopyWebDir(true)
+ setTempDirectory(String)

When jetty creates the tmp directory (ie it does not already exist) then that directory is entirely removed when jetty stops. If the tmp directory already exists, or it is a dir called "work" then we don't delete the dir or its contents. I've checked this behaviour for jetty-6.1.14 on linux, but I don't have access to a windows machine to verify. I don't think anything has changed with this area of the software for a while. Can you double check that if you let jetty use the default system tmp dir (not sure what java.io.tmpdir is on windows) that the dir and all contents are removed?

cheers
Jan

I did not used any of the setExtractWar, setCopyWebDir or setTempDirectory methods so the defaults are applied.
I think this is a windows issue because the directory is cleaned-up but not the JAR files from the WEB-INF/lib (because they have been loaded)

Jeff,

Odd that the jsp classfiles would be removed but the jar files wouldn't be.

I've tested again on linux with jetty invoked programmatically rather than from the command line, and the whole tmp dir for the webapp gets deleted.
The source code for that simple test program is here:
http://jetty.mortbay.org/jetty/jetty-6/xref/org/mortbay/jetty/example/OneWebApp.html

I modified it to try two things, one is stopping the server and one is just stopping the webapp. In both cases the tmp dir is deleted. Here's the way I modified the code. Can you try this, but point it at your webapp instead of the test webapp, and see what happens in each case?

public class OneWebApp
{
public static void main(String[] args)
throws Exception
{
String jetty_default=new java.io.File("./start.jar").exists()?".":"../../..";;
String jetty_home = System.getProperty("jetty.home",jetty_default);

Server server = new Server();

Connector connector=new SelectChannelConnector();
connector.setPort(Integer.getInteger("jetty.port",8080).intValue());
server.setConnectors(new Connector[]

);

WebAppContext webapp = new WebAppContext();
webapp.setContextPath("/");
webapp.setWar(jetty_home+"/webapps/test.war");
webapp.setDefaultsDescriptor(jetty_home+"/etc/webdefault.xml");

server.setHandler(webapp);

server.start();

System.err.println("Started, sleeping");
Thread.currentThread().sleep(10000);

//option 1 - stop the server
//System.err.println("Stopping server");
//server.stop();

//option 2 - stop just the webapp
//System.err.println("Stopping webapp");
//webapp.stop();

System.err.println("Sleeping");
Thread.currentThread().sleep(10000);
System.err.println("Terminating");
//server.join();
}
}

regards
Jan

I'm having the same issue with 6.1.14, also on WIndows (Vista). If I put breakpoint before JVM exits, Process Explorer shows that java.exe is using all those undeleted jar files, even though Jetty Server is fully stopped (isStopped == true).

After JVM exits, I can manually remove those remaining jars.

Yuri,

what jvm are you using?

thanks
Jan

java version "1.6.0_11"
Java(TM) SE Runtime Environment (build 1.6.0_11-b03)
Java HotSpot(TM) Client VM (build 11.0-b16, mixed mode, sharing)

On 32 bit Vista SP1.

Hi dyu,

Could you try running jetty-6 under jdk1.6 (same version as reported in this issue) on Windows and see what happens with the tmp dir (I might have already asked you to do this, but if so, I've forgotten what you said, so it would be good to document it here).

thanks
Jan

$ java -version
java version "1.6.0_11"
Java(TM) SE Runtime Environment (build 1.6.0_11-b03)
Java HotSpot(TM) Client VM (build 11.0-b16, mixed mode, sharing)

Tested under jetty6 latest snapshot.
The only time that the temp dir does not get deleted is when:
1. The temp dir was set via WebAppContext.setTempDirectory(dir) .. where dir is already exists
2. The server's shutdown hook did not get called, w/c prevents cleanup of the webapp via WebAppContext.stop()

If the server is shut down gracefully (e.g server.stop() getting called), the cleanup is successful as long as its not #1.

Likely these guys are experiencing #2 where they have pressed ctrl+c or the jvm exited abnormally to prevent graceful shutdown.
The solution is simply to configure the server with:
<Set name="stopAtShutdown">true</Set>

P.S
Jan, if I start the server programmatically through eclipse IDE, the shutdown hook does not get called. (Eclipse 3.4.1 and windows xp sp2)
The server was definitely configured to stop at shutdown.
But if I run it via java -jar, the shutdown hook gets called ... which in turn deletes the tmp dir successfully every time.
Its either a bug or done intentionally by eclipse.

Jeff et al,

Can you confirm that if you configure with server.setStopAtShutdown(true), that the temp dir will be cleaned up?
There could be other issues in your environment where another program is accessing the webapp files during the shutdown,
which prevents it from getting deleted .. (e.g FileMappedBuffer)

Cheers

Tested server.setStopAtShutdown(true) on 6.1.14 on Windows. No, even with shutdown hooks etc, the jars remain.

Thanks. It indeed does leave the jars.
I did not get the same behavior before as the jetty test-webapp did not have any jars in its WEB-INF/lib, ... and so I tested with another webapp
that has em.

If you look at http://bugs.sun.com/view_bug.do?bug_id=4950148 , Its a 5 year old windows bug that has not been fixed by sun.

The behavior is that you can the jars can only be deleted when the jvm that oaded/used it is already terminated.

There are workarounds for this ... e.g like launching a separate process (right after the jvm stops) which cleans up the jars.

I'll think of a better solution and get back to u.

Thanks

Dyu,

Good detective work. That certainly looks like the problem.

Can you try just one more thing - try calling Resource.setDefaultUseCaches(false) early in the jetty.xml file or embedded setup. This controls whether the UrlConnection class will cache the jar contents. I'm wondering if the caches are off, if that might help the garbage collector. Probably not, but maybe worth trying?

cheers
Jan

Jan, the jars still aren't deleted even with Resource.setDefaultUseCaches(false)

A workaround would be having a sweeper (daemon) check temp dirs that are no longer used (marked by WebAppContext) and deletes them.
This component will be placed in jetty-contrib for those who are interested.

Cheers

http://svn.codehaus.org/jetty-contrib/branches/jetty-6.1.x/contrib/sweeper/

Since this is a jvm bug (on windows), the Sweeper (daemon) will serve as a workaround