10

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)
Thomas Broyer
  • 64,353
  • 7
  • 91
  • 164
FrozZerrer
  • 292
  • 1
  • 5
  • 16

6 Answers6

8

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>
Joakim Erdfelt
  • 46,896
  • 7
  • 86
  • 136
  • How can I know witch JAR file is problematic? – FrozZerrer Oct 01 '13 at 21:26
  • I think it may be gwttime-alpha.jar founded here http://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 Oct 01 '13 at 21:33
  • I've also added the poi-3.9-20121203.jar lib. – FrozZerrer Oct 02 '13 at 14:22
  • 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. – ddekany Nov 26 '14 at 22:34
  • Had it happened in Jetty9.3, Fixed it with settings cache false for all connections. – Ducaz035 Jan 15 '16 at 10:07
  • Will it affect the performance If we turn the defaultUseCaches off? – Bharat Darakh Apr 20 '20 at 13:44
  • 1
    If you have a project that uses the classloader heavily, it can have a negative impact. (but that's not a common scenario) – Joakim Erdfelt Apr 20 '20 at 14:36
1

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

1

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.

Yusuf K.
  • 4,195
  • 1
  • 33
  • 69
bashizip
  • 562
  • 5
  • 14
1

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

Nick
  • 2,735
  • 1
  • 29
  • 36
0

I was having the same issue because of the actual WAR being corrupt. Try rerunning mvn clean install and redeploy.

ACV
  • 9,964
  • 5
  • 76
  • 81
0

I had the same problem, after deleting all .jar files and build the path to all .jar file once again. Now it's working properly

Zoe
  • 27,060
  • 21
  • 118
  • 148