Created attachment 32176 [details] complete console output After updating Tomcat from version 7.0.54 to 7.0.56 the following exception occurs during startup: --------------------------------------- ... Okt 30, 2014 2:00:45 PM org.apache.catalina.startup.ContextConfig processAnnotationsJar SEVERE: Unable to process Jar entry [com/ctc/wstx/api/ReaderConfig.class] from Jar [jar:jndi:/localhost/ssms-gui/WEB-INF/lib/woodstox-core-asl-4.1.2.jar!/] for annotations java.io.EOFException at org.apache.tomcat.util.bcel.classfile.FastDataInputStream.readUnsignedShort(FastDataInputStream.java:120) at org.apache.tomcat.util.bcel.classfile.Utility.swallowFieldOrMethod(Utility.java:75) at org.apache.tomcat.util.bcel.classfile.ClassParser.readMethods(ClassParser.java:235) at org.apache.tomcat.util.bcel.classfile.ClassParser.parse(ClassParser.java:92) at org.apache.catalina.startup.ContextConfig.processAnnotationsStream(ContextConfig.java:2071) at org.apache.catalina.startup.ContextConfig.processAnnotationsJar(ContextConfig.java:1947) at org.apache.catalina.startup.ContextConfig.processAnnotationsUrl(ContextConfig.java:1913) at org.apache.catalina.startup.ContextConfig.processAnnotations(ContextConfig.java:1898) at org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1330) at org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:889) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:386) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117) at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5380) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:649) at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:1083) at org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1879) at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) ... --------------------------------------- This exception occurs for several JAR files and did not happen with tomcat 7.0.54. Complete console output attached.
1. Is this issue reproducible or just happened once? 2. Please verify that your copy of woodstox-core-asl-4.1.2.jar is a correct one, not truncated or otherwise tampered with. I am unable to reproduce any issues with my copy of the library. It has size 478 935 bytes, md5 ba7562cc58d6652e7d8e6095ad6e2940, sha1 b8df430ddc4947bc7b68af5ed09b8c1c5b527553. (There is a testcase org.apache.tomcat.util.bcel.TesterPerformance that performs parsing of all classes in a Jar. I also tried to put the library into a web application.) 3. A library can be excluded from annotation scanning. See https://wiki.apache.org/tomcat/HowTo/FasterStartUp
What is the version of Java runtime that you are using? (So that one could actually reproduce the issue) Thoughts: 1) FastDataInputStream.fillNew() shall check that this.in.read() is not -1. 2) FastDataInputStream.readUnsignedShort() expects that fillNew() call will read at least 2 bytes, but read() can actually return after reading 1 byte (I think it may depend on internal implementation of zip inflater thus my question on the version of Java that OP is using), so some looping is needed like in FastDataInputStream.readFully(..)/skipBytes(). There is also a question of whether FastDataInputStream with such changes remains faster than the original DataInputStream.
To your questions: > 1. Is this issue reproducible or just happened once? It is reproducible with every startup of tomcat. > 2. Please verify that your copy of woodstox-core-asl-4.1.2.jar is a correct one, not truncated or otherwise tampered with. > I am unable to reproduce any issues with my copy of the library. > It has size 478 935 bytes, md5 ba7562cc58d6652e7d8e6095ad6e2940, sha1 b8df430ddc4947bc7b68af5ed09b8c1c5b527553. > (There is a testcase org.apache.tomcat.util.bcel.TesterPerformance that performs parsing of all classes in a Jar. I also tried to put the library into a web application.) I double checked the file. It is the correct one. Attached you can find a copy of my JAR (zipped). > 3. A library can be excluded from annotation scanning. See > https://wiki.apache.org/tomcat/HowTo/FasterStartUp Thank you, but I was aware of that. It would be OK for the "woodstox" library, but not for the "trinidad-impl-2.1.1-ks1.jar" which is also failing. > What is the version of Java runtime that you are using? > (So that one could actually reproduce the issue) We are currently using a rather old JVM: java version "1.7.0_25" Java(TM) SE Runtime Environment (build 1.7.0_25-b17) Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode) Is there any difference, if I would use a newer one?
Created attachment 32181 [details] woodstox JAR of my installation
I tried with a newer JVM, but got the same exceptions: ----- java version "1.7.0_72" Java(TM) SE Runtime Environment (build 1.7.0_72-b14) Java HotSpot(TM) 64-Bit Server VM (build 24.72-b04, mixed mode)
I can reproduce the issue: SEVERE: Unable to process Jar entry [ch/qos/logback/core/status/Status.class] from Jar [jar:jndi:/localhost/no-manifest/WEB-INF/lib/com.springsource.ch.qos.logback.core-0.9.18.jar!/] for annotations java.io.EOFException at org.apache.tomcat.util.bcel.classfile.FastDataInputStream.readInt(FastDataInputStream.java:145) at org.apache.tomcat.util.bcel.classfile.ClassParser.readID(ClassParser.java:200) Setup: - tomcat 7.0.56 with default settings - only unpackWARs is set to false <Host name="localhost" appBase="webapps" unpackWARs="false" autoDeploy="true"> If unpackWARs is set to true there are no problems. The problem does not appear in 7.0.55 and appear in 7.0.56 and tc7.0.x.
In my installation unpackWARs is also set to false: <Host appBase="webapps" autoDeploy="false" name="localhost" unpackWARs="false">
In our Tomcat-7.0.56 installation we're experiencing the same annotations-check problem. I've tried to set unpackWar to true but that doesn't seem to be the problem in our case. Although we're getting these exceptions our applications don't seem to have any trouble with it.
Created attachment 32195 [details] 2014-11-08_tc8_57173_test_v1.patch Modification of TesterPerformance test that uses an InputStream that reads only one byte at each read() call.
Created attachment 32196 [details] 2014-11-08_tc8_57173_test_v2.patch Modification of TesterPerformance test that uses an InputStream that reads a random count of bytes on each read() call. The count of bytes ranges from 1 up to requested length.
Steps to run the tests: 1. Apply patch (attachment 32195 [details] or attachment 32196 [details]) 2. Put some jars into /tmp/jira-libs 3. Run org.apache.tomcat.util.bcel.TesterPerformance test With patch 1 the test fails in readInt() call when reading the signature of the class file. With patch 2 the test fails randomly in some read[Int,UnsignedInt] etc. method. Thus FastDataInputStream is broken.
Fixed in trunk by r1637501. I disabled mark() method, as I see that the current implementation of fillNew() method is not compatible with it. It does not take into account the marker position. In my test with trunk and JDK 8u25 the "FastDataInputStream" is faster by 2%. That is not much of a difference. Reverting r1625504 is an option.
*** Bug 57251 has been marked as a duplicate of this bug. ***
*** Bug 57260 has been marked as a duplicate of this bug. ***
We are seeing lots of these regressions. I am going to revert r1625504.
The performance improvement that triggered this regression has been reverted from from trunk, 8.0.x (for 8.0.16 onwards) and 7.0.x (for 7.0.58 onwards) and will not be reapplied.
Thanks for the fast response!