I had better luck by hacking up the FileInputStream/FileDescriptor to
track where a handle was closed and resued in a read. One example of a
read attempt on a closed handled shows its the VirtualFile finalizer
closing its streams causing the problem. Since a VirtualFile is not the
required path to an input stream, we can't be closing its streams just
because its garbage collected. If this is the only path to ensuring
streams are closed, we'll have to add reference counting logic to
prevent closure of in use streams. Not sure why this seems to be much
more prevalent on win32.
06:29:10,515 ERROR [STDERR] java.io.FileInputStream@ba8af9 failed,
fd=java.io.Fi
leDescriptor@13c339f[fd=-1,handle=-1,prevHandle=4652], isValid=false,
java.io.IO
Exception: Read error
06:29:10,515 ERROR [STDERR] java.io.FileInputStream@ba8af9, fd=4652
already closed at:
06:29:10,515 ERROR [STDERR] java.lang.Thread.dumpThreads(Native Method)
06:29:10,515 ERROR [STDERR] java.lang.Thread.getStackTrace(Thread.java:1383)
06:29:10,515 ERROR [STDERR]
java.io.FileInputStream.close(FileInputStream.java:279)
06:29:10,515 ERROR [STDERR]
org.jboss.virtual.VirtualFile.closeStreams(VirtualFile.java:210)
06:29:10,515 ERROR [STDERR]
org.jboss.virtual.VirtualFile.close(VirtualFile.java:227)
06:29:10,515 ERROR [STDERR]
org.jboss.virtual.VirtualFile.finalize(VirtualFile.java:390)
06:29:10,515 ERROR [STDERR]
java.lang.ref.Finalizer.invokeFinalizeMethod(NativeMethod)
06:29:10,515 ERROR [STDERR]
java.lang.ref.Finalizer.runFinalizer(Finalizer.java:83)
06:29:10,515 ERROR [STDERR]
java.lang.ref.Finalizer.access$100(Finalizer.java:14)
06:29:10,515 ERROR [STDERR]
java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:160)