On 01/06/16 19:25, A. Soroka wrote:
It's Mac. I took a look at the issue you mentioned, just to be sure, and checked the test
code there-- Mac doesn't seem to have the "can't let go of mmapped files"
problem, at least.
I'll start digging deeper.
Is this with -Pdev or full build? jena-jdbc-driver-tdb is not in -Pdev,
jena-tdb is.
In jena-tdb, the setup is via ConfigTest and System.getProperty("os.name")
In "jena-tdb/target/tdb-testing" is there one directory "DB" or many "D-..."
Andy
---
A. Soroka
The University of Virginia Library
On Jun 1, 2016, at 2:07 PM, Andy Seaborne <[email protected]> wrote:
On 01/06/16 18:32, A. Soroka wrote:
In this thread, which is about the testing for release of 3.1.0
https://lists.apache.org/thread.html/Z4t2lfn3qxqi571
a couple of people (myself, Osma) reported problems building on non-Linux
platforms centered on problems with the enormous amount of space some tests
seem to be taking on some systems. I'm still having that problem, and I'm
wondering if anyone else has seen it or has any ideas about how to avoid it. It
seems to pass through BlockMgrMapped.segmentAllocate, if that rings any bells
for anyone.
---
A. Soroka
The University of Virginia Library
MS Windows?
On Windows, memory mapped files do not actually get deleted until the JVM,
exits [1].
So the test suite can't reuse a database by deleting it complete and reusing
the directory.
A new, unique database is created each time (jena-tdb tests,
jena-jdbc-driver-tdb tests).
Which means a lot of space.
Maybe we ought to run the tests in "direct" mode on Windows. Thats' normal
old-fashioned file I/O, not this new fangled mapped stuff.
If Mac, then I don't know.
Andy
http://bugs.java.com/view_bug.do?bug_id=4715154
