1. When we need to update the cache index file for the new expiration date, instead of always writing out the full index file, we should just update the expiration date field. This will significantly reduces the amount of time needed to update the index file, and hence reduce the collision chances.
2. If we are running with Java 1.4 or above, use the NIO FileChannel API to lock the file before reading/writing.
This is a bug in the Java Web Start code in JDK 6. Problem is two
> different threads is trying to read/write the cache idx file, causing
> the StreamCorruptedExpcetion sometimes.
> In JDK 6 Java Web Start, when we do a update check on the jnlp
> application resource, if the server return a new expiration date header,
> we will update the corresponding cache index file with the new
> expiration date value.
> We do the update check in a separate thread. By default, if the update
> check does not complete in 1.5 seconds, we will continue and just run
> from cache, and let the update check continue in another thread.
> When the bug happens, the update check did not complete in 1.5s, so it
> keep running in the update check thread. While the main thread continue
> to run, it will need to read the JAR manifests in the cache index file.
> So it happens that during the reading of the manifests, the update check
> thread complete and found a new expiration date, and write that to the
> cache index. Therefore the stream got corrutped when the main thread is
> reading the manifests from the index.
> In the meantime, if you need to use JDK 6, you can try adding this to
> the jnlp file:
> <update check="always"/>
> (update element is a new sub-element of the jnlp element in JDK 6)
> This will force the update check to complete before the application can
> be started, which can workaround this problem. But the application
> might take longer to start, depending on the server availability.
> Or you can use a webserver that does not return the expiration date
> value upon a if-modified-since GET request.