Internal error in ZipFile code during compilation

Name: dk106046 Date: 08/02/2002

Platform: Solaris

Operating System Level/Version: 5.8

Specific Sun Release Information: JPSE_1.3.1_20020313

Known existing SUN Bug ID's: 4353705 and 4666704

Customer sees the following exception on the application server when accessing a JSP from their browser:

  java.lang.InternalError: jzentry == 0
      at java.util.zip.ZipFile$2.nextElement(ZipFile.java:292)
      at sun.tools.java.ClassPath.getFiles(ClassPath.java:178)
      ....etc....
   
Here are the machine details: SunOS ls0199 5.8 Generic_108528-14 sun4u sparc SUNW,Ultra-60

The problem doesn't occur on an Ultra-2 with the same setup.

Turning off the HotSpot compiler has no effect on the ZipFile exception.

JSP compilation passes when done in "batch" mode outside of the application server.

The problem is to do with the JVM's internal cache of zip
information. Before SUNBUG 4353705 was fixed, the JVM would maintain
cached zip information even when the physical file was changed. This
meant that new ZipFile objects could pick up stale zip information.
                                                                      
The fix was to check the file modification time and reload the cache when this time changed. Unfortunately, file modification time has a granularity of one second on Solaris - so the cache can still become stale if the zip file is modified twice in one second.

This is probably why we see the problem on the Ultra-60, but not on
the Ultra-2. The problem is more likely to occur on faster systems.

showrev -p, pkginfo -l, ulimit -a, env, exception trace, together with other examples of the problem are available.
======================================================================