Jetty - java.lang.IllegalStateException: zip file closed

Question

I'm getting some error with some connection to our web server.

I saw that a bug causing this was solved in Jetty 7.6. Yes we get this error on our application running under Jetty 7.5.4 but we also get this with another apps running on a newer version 9.

Do you have any idea what this can be?

We are getting this error randomly:

java.lang.IllegalStateException: zip file closed
    at java.util.zip.ZipFile.ensureOpen(ZipFile.java:632)
    at java.util.zip.ZipFile.access$200(ZipFile.java:56)
    at java.util.zip.ZipFile$1.hasMoreElements(ZipFile.java:485)
    at java.util.jar.JarFile$1.hasMoreElements(JarFile.java:239)
    at org.eclipse.jetty.util.resource.JarFileResource.exists(JarFileResource.java:163)
    at org.eclipse.jetty.webapp.WebAppContext$Context.getResource(WebAppContext.java:1223)
    at org.eclipse.jetty.servlet.DefaultServlet.getResource(DefaultServlet.java:366)
    at org.eclipse.jetty.server.ResourceCache.lookup(ResourceCache.java:188)
    at org.eclipse.jetty.servlet.DefaultServlet.doGet(DefaultServlet.java:445)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
    at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:547)
    at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:480)
    at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
    at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:483)
    at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:227)
    at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:941)
    at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:409)
    at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:186)
    at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:875)
    at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
    at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:219)
    at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149)
    at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:110)
    at org.eclipse.jetty.server.Server.handle(Server.java:345)
    at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:441)
    at org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:919)
    at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:582)
    at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:218)
    at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:51)
    at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:586)
    at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:44)
    at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:598)
    at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:533)
    at java.lang.Thread.run(Thread.java:722)

Solution 1

There are 2 main causes for this.

1. A bad/corrupt JAR file in your classpath.
2. The JVM built-in URL caching getting in the way.

For a bad/corrupt JAR file, you'll have to isolate that on your own, figure out which one it is. Maybe by just unjaring all of them one by one till you find the problematic one.

As for the JVM URL caching, this seems to cause problems with dynamic classloaders like OSGi or hot-deploy scenarios the most.

For this scenario, you can tell jetty to set the URLConnection.setUseCaches(boolean) for each URLConnection attempt of its own.

To disable the JVM caches, add the following snippet of XML to your etc/jetty.xml

<Set class="org.eclipse.jetty.util.resource.Resource"
     name="defaultUseCaches">false</Set>

Solution 2

This issue can also occur if you are doing any of your own reflection in that code path.

Solution 3

I had the same problem after deploying jenkins war; all I had to do was to restart the server after the deploy. Hope it helps.

Solution 4

You don't need to test all files to ensure the correctness of them. Just put a break point at java.util.zip.ZipFile.ensureOpen(ZipFile.java:632) and check the name field in ZipFile class: private final String name

View more solutions

Comments

[FrozZerrer]

How can I know witch JAR file is problematic?

[FrozZerrer]

I think it may be gwttime-alpha.jar founded here code.google.com/p/gwt-time. Since it's the last one added in common between my two projects. It's new on my project running under Jetty7 but was seeing this problem for a while for the one running under Jetty9.

[FrozZerrer]

I've also added the poi-3.9-20121203.jar lib.

[ddekany]

Had the same error on Sun Java 5 and embedded Jetty 7, when Jasper tried to read from the JSTL 1.2 jar. The problem wasn't present on Java 7 and 8, only on 5. But calling org.eclipse.jetty.util.resource.Resource.setDefaultUseCaches‌​(false); has made it gone.

[Ducaz035]

Had it happened in Jetty9.3, Fixed it with settings cache false for all connections.

[Bharat Darakh]

Will it affect the performance If we turn the defaultUseCaches off?

[Joakim Erdfelt]

If you have a project that uses the classloader heavily, it can have a negative impact. (but that's not a common scenario)