On Thu, May 17, 2012 at 5:30 PM, Andy Seaborne <[email protected]> wrote: > Paul, > > Do you have a pointer to the Mulgara code? It would be great to fix this. > > It's not truncation nor access after closing though: it's deletion of the > files that's the issue. close(), no use whatsoever then file delete does > not delete the file. The files are held by the JVM until exit. > > http://bugs.sun.com/view_bug.do?bug_id=4724038
The reason that close() won't help is because it's perfectly legal to map a file and then close the file handle used to create the mapping. It's the mapping that has to be released. We don't often delete files that have been mapped, so I can't claim unequivocally that it will work, but it ought to. I believe we've deleted files, just not often. Since the problem with truncation and with deletion is similar (due to open objects), then I'd expect the solution to work again. > Works just fine on Linux, does not work on MS Windows. maybe it's because > open files count to the reference count in Linux but not on MS windows. There's a standard practice on Linux/Unix systems of opening a file and deleting it while keeping it open. This file is fully visible through it's handle, but the inode has been released on disk and no other process can see it any more. It's been a while, but I don't think this works on Windows. What we found was that Linux and Solaris behaved themselves quite well when we tried to release a mapping. Run the GC, and the mapping has probably been released. If not, then run it again the mapping has *definitely* been released. This seemed to work in general, until we had a problem with Windows where it wasn't released on the second GC. So we called the GC a third time. About a month later we had an occasion where that failed too ... so we increased it more. Then 6 months later it failed again (it had worked thousands of times in between). Finally we took the approach of counting down from about 10 and re-attempting the truncation after a GC on each iteration. This appeared to fix the problem, and we never saw it go over 4 attempts in the log (though we don't log the number of attempts any more). At some point, someone (I think David) discovered the "clean" method, and this gets called on objects in Windows. You'll see it gets pulled out via reflection. We recently pulled most of this code out and put it into a single file. http://mulgara.org/svn/mulgara/trunk/src/jar/util/java/org/mulgara/util/io/MappingUtil.java Hopefully it's clear enough, but ask questions if there's anything too obtuse. Paul
