On 12/03/15 11:38, Claude Warren wrote:
First let me start with a disclaimer: I do not run windows, I have not
attempted to run the windows TDB tests, I have only followed the
conversation tangentially.
I don't any more either. I had a windows setup but as it only got used
every once in a while, the first thing it did was a large update, often
a reboot.. some more updates, before I could get any work done. Hence,
it rotted.
My understanding of the testing issue is that Windows does not release the
disk space associated with memory mapped files until after the JVM exits.
There are multiple modules involved : jena-tdb and jena-jdbc-driver-tdb.
Running -Pdev, the profile for a subset of the modules, only runs
jena-tdb. How much does that on it's own use?
-------
That's the issue - there is also code to work around it. The tests in
TDB on Windows generate a new name for a database location. Some of the
tests could be converted to reuse a database.
Q: Is it not possible to add a configuration option to Maven that causes
those tests to be run in a different JVM. When the test finishes the JVM
should clean up the files. Not sure if that makes sense but a discussion
of how to configure Maven to do the new JVM per test is found here:
http://stackoverflow.com/questions/6813373/how-to-tell-maven2-to-execute-junit-tests-one-by-one-each-in-new-jvm-instance
Don't know - someone want to try?
We could even split the tests in two parts to run normally (no on disk
DB issues) and run in separate JVMs.
There are in-memory versions for all the disk storage in TDB and that's
used for speed and lack of disk. Maybe some more can reasonably be test
that way.
I haven't looked at jena-jdbc-driver-tdb - can some/all of that be done
with in-memory datasets and still have honest tests?
Andy
Claude
Andy