afs commented on issue #2127: URL: https://github.com/apache/jena/issues/2127#issuecomment-2010731129
In the stacktrace, it appears there is another process active in some way. Deleting disk space is attempted for Windows; On Windows, the space is only reclaimed (released to the file system) when the JVM exits. This "on exit", or sometimes earlier, but still delayed, is the long standing java issue. The situation around compaction is different for Jena 5.0.0 if a previous JVM had a problem in compaction. In 4.x partial, broken compaction could get left around causing a subsequent JVM to encounter problems. That might be what is occurring in the stacktrace (it isn't conclusive though). 5.0.0 has compaction robustness - issue #2254. PR #2304 added robustness by compacting to a temporary directory, moving it into place using filesystem atomic rename within the same directory. This is the commit step. Then it deletes the old directory before the compacted database is available to the application. (There is a period of vulnerability to external effects, not java factors, between rename and finishing the filesystem delete.) #2315 reported that the storage directory can't be renamed into place on MS Windows. The atomic rename above does not work if the directory has memory mapped files. #2321 changes MS Windows to write the new database storage into the correct place. It has different compaction robustness by a different clean-up. A control file is written which lists the directory to be cleared up the next time this database is opened/connected to. Compaction writes the name of the new database storage directory (the `Data-(N+1)` directory) to the clean up file. If compaction runs smoothly, the old directory, `Data-N`, is deleted; the space is only truly released by the OS when the JVM exits; this is unavoidable. But the system is using `Data-(N+1)`, `Data-(N+2)`, ... as compactions happen successfully. If the compaction does go wrong, there is highest `Data-N` directory that can not be used. Its name is in the control file. The Windows compaction code deletes the control file when the compaction has finished and before the switchover to the new compacted storage and before it is available to the application. Cleaning up the control file is the commit step. There is an equivalent period of vulnerability to external effects. Code runs once per JVM per database before using a database for the first time in the JVM. That code understands both Windows-style and Linux-style compactions and so the database folder can still be moved between systems. Please try Jena 5.0.0. After running many Windows github actions and not seeing an occurrence of failure of one of the tests in Jena 4.x that would occasionally fail, I hope this is robust. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
