You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by "A. Soroka" <aj...@virginia.edu> on 2016/06/01 17:32:27 UTC
out-of-space problems with build
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
Re: out-of-space problems with build
Posted by "A. Soroka" <aj...@virginia.edu>.
This is in full build and the problems come up in jena-jdbc-driver-tdb. It's pretty much the same as previously reported. It's all bubbling up through BlockAccessMapped.allocSegment.
I don't really know much about TDB, so I think this is just a sign from fate that I need to dig in and start learning that code! {grin}
---
A. Soroka
The University of Virginia Library
> On Jun 1, 2016, at 3:43 PM, Andy Seaborne <an...@apache.org> wrote:
>
> 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 <an...@apache.org> 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
>>
>
Re: out-of-space problems with build
Posted by "A. Soroka" <aj...@virginia.edu>.
I've never seen it before, but it seems more and more likely that that's simply because my disk is filling up with stuff! {grin}
I will start taking a look at subclassing JUnit's TemporaryFolder and inserting a block in the "after-test" portion to wait until the files are really gone. That might or might not work, but it's pretty easy to try.
---
A. Soroka
The University of Virginia Library
> On Jun 6, 2016, at 5:03 AM, Rob Vesse <rv...@dotnetrdf.org> wrote:
>
> I’ve always seen this issue running on mac , these days it is not an issue for me because I got a new machine with more disk space
>
> It did always seem like there was a delay between the test deleting folder and the disk space actually being freed up. I did on one occasion try inserting a sleep before each test which made things better but drastically increased the time to run the tests.
>
> On 05/06/2016 16:58, "Andy Seaborne" <an...@apache.org> wrote:
>
>> jena-jdbc-driver-tdb has 99 disk tests in TestTdbDiskConnection and 221
>> TestTdbDiskResultSets - so that's what I have looked.
>>
>> The test work by:
>>
>> @Rule
>> public TemporaryFolder tempDir = new TemporaryFolder();
>>
>> and
>>
>> @After
>> public void cleanupTest() {
>> ...
>> StoreConnection.expel(...) ;
>> }
>>
>> The @After happens before the @Rule cleanup (tick) so it really should
>> be that nothign is folding on to the space.
>>
>> The temporary folder is of the form in (Eclipse) /tmp/junitNNNNNNNN or
>> (maven) target/junitNNNNNNNN.
>>
>> Idea (no evidence; no Mac) - even if unlinked, maybe the file space is
>> not immediately freed up.
>>
>> We have the same with TCP ports - the tests used to saturate a machine
>> and it ran out of ports because they were not being recycled - the OS
>> didn't seem to get time to run the final part of TCP clearing up
>> immediately.
>>
>> And one other thing - we know Mac OS reports very large empty databases.
>> I has assumed this was an accounting thing - they are sparse files so
>> while they have a length of 8M, they are in fact 8K of used space.
>> Maybe on OS/X a real 8M of disk space is allocated or at least reserved
>> (which would be so mainframe-y!)
>>
>> Andy
>>
>>
>>
>> On 03/06/16 18:22, A. Soroka wrote:
>>> Just a further note: I've started sticking in logging statements and this turns out to be rooted in "java.io.IOException: No space left on device" exceptions getting thrown up at BlockAccessMapped::allocSegment line 223. This is with builds starting with about 25GB free on disk. And I am sometimes (but not always) seeing messages from the OS about disks being nearly full during the build.
>>>
>>> So maybe there _is_ something weird about Mac OS X and memory mapping in Java? I suppose I have to start tracking resources.
>>>
>>> Is anyone else out there using Mac OS X (10.10.5)? Are you seeing the same problem? I really hope I'm not the only one! {grin}
>>>
>>> ---
>>> A. Soroka
>>> The University of Virginia Library
>>>
>>>> On Jun 1, 2016, at 3:43 PM, Andy Seaborne <an...@apache.org> wrote:
>>>>
>>>> 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
>>>>
>>
>
>
>
>
Re: out-of-space problems with build
Posted by "A. Soroka" <aj...@virginia.edu>.
No, no encryption in this case. Given that Rob Vesse has also seen it and that people on Windows have expressed concern about the enormous amount of data the tests create, I think it's worth trying to "clean as we go". Since Macs don't suffer from the problems deleting mapped files that Windows machines do, it should be doable. {famous last words}
---
A. Soroka
The University of Virginia Library
> On Jun 6, 2016, at 6:31 AM, Stian Soiland-Reyes <st...@apache.org> wrote:
>
> On 6 June 2016 at 10:03, Rob Vesse <rv...@dotnetrdf.org> wrote:
>> I’ve always seen this issue running on mac , these days it is not an issue for me because I got a new machine with more disk space
>>
>> It did always seem like there was a delay between the test deleting folder and the disk space actually being freed up. I did on one occasion try inserting a sleep before each test which made things better but drastically increased the time to run the tests.
>
> Could this be related to encryption of home directory? In my
> experience that could add a noticeable delay before disk space is
> freed up.
>
> Is it possible to safely re-use a previously malloc-ed test-file, or
> would that introduce lots of other issues? (It sounds non-ideal, each
> tests should run independently from a clean state). What about
> truncating the file before it's deleted?
>
>
>
> --
> Stian Soiland-Reyes
> Apache Taverna (incubating), Apache Commons
> http://orcid.org/0000-0001-9842-9718
Re: out-of-space problems with build
Posted by Stian Soiland-Reyes <st...@apache.org>.
On 6 June 2016 at 10:03, Rob Vesse <rv...@dotnetrdf.org> wrote:
> I’ve always seen this issue running on mac , these days it is not an issue for me because I got a new machine with more disk space
>
> It did always seem like there was a delay between the test deleting folder and the disk space actually being freed up. I did on one occasion try inserting a sleep before each test which made things better but drastically increased the time to run the tests.
Could this be related to encryption of home directory? In my
experience that could add a noticeable delay before disk space is
freed up.
Is it possible to safely re-use a previously malloc-ed test-file, or
would that introduce lots of other issues? (It sounds non-ideal, each
tests should run independently from a clean state). What about
truncating the file before it's deleted?
--
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons
http://orcid.org/0000-0001-9842-9718
Re: out-of-space problems with build
Posted by Rob Vesse <rv...@dotnetrdf.org>.
I’ve always seen this issue running on mac , these days it is not an issue for me because I got a new machine with more disk space
It did always seem like there was a delay between the test deleting folder and the disk space actually being freed up. I did on one occasion try inserting a sleep before each test which made things better but drastically increased the time to run the tests.
On 05/06/2016 16:58, "Andy Seaborne" <an...@apache.org> wrote:
>jena-jdbc-driver-tdb has 99 disk tests in TestTdbDiskConnection and 221
>TestTdbDiskResultSets - so that's what I have looked.
>
>The test work by:
>
>@Rule
> public TemporaryFolder tempDir = new TemporaryFolder();
>
>and
>
> @After
> public void cleanupTest() {
> ...
> StoreConnection.expel(...) ;
> }
>
>The @After happens before the @Rule cleanup (tick) so it really should
>be that nothign is folding on to the space.
>
>The temporary folder is of the form in (Eclipse) /tmp/junitNNNNNNNN or
>(maven) target/junitNNNNNNNN.
>
>Idea (no evidence; no Mac) - even if unlinked, maybe the file space is
>not immediately freed up.
>
>We have the same with TCP ports - the tests used to saturate a machine
>and it ran out of ports because they were not being recycled - the OS
>didn't seem to get time to run the final part of TCP clearing up
>immediately.
>
>And one other thing - we know Mac OS reports very large empty databases.
> I has assumed this was an accounting thing - they are sparse files so
>while they have a length of 8M, they are in fact 8K of used space.
>Maybe on OS/X a real 8M of disk space is allocated or at least reserved
>(which would be so mainframe-y!)
>
> Andy
>
>
>
>On 03/06/16 18:22, A. Soroka wrote:
>> Just a further note: I've started sticking in logging statements and this turns out to be rooted in "java.io.IOException: No space left on device" exceptions getting thrown up at BlockAccessMapped::allocSegment line 223. This is with builds starting with about 25GB free on disk. And I am sometimes (but not always) seeing messages from the OS about disks being nearly full during the build.
>>
>> So maybe there _is_ something weird about Mac OS X and memory mapping in Java? I suppose I have to start tracking resources.
>>
>> Is anyone else out there using Mac OS X (10.10.5)? Are you seeing the same problem? I really hope I'm not the only one! {grin}
>>
>> ---
>> A. Soroka
>> The University of Virginia Library
>>
>>> On Jun 1, 2016, at 3:43 PM, Andy Seaborne <an...@apache.org> wrote:
>>>
>>> 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
>>>
>
Re: out-of-space problems with build
Posted by "A. Soroka" <aj...@virginia.edu>.
Andy, I think this is the problem. Replacing the on-disk dataset with TDB's in-memory for-tests-only-dataset makes the problem go away. I'm not sure that that's a real fix that we could go forward with, but at least it nails things down.
---
A. Soroka
The University of Virginia Library
> On Jun 5, 2016, at 11:58 AM, Andy Seaborne <an...@apache.org> wrote:
>
> jena-jdbc-driver-tdb has 99 disk tests in TestTdbDiskConnection and 221 TestTdbDiskResultSets - so that's what I have looked.
>
> The test work by:
>
> @Rule
> public TemporaryFolder tempDir = new TemporaryFolder();
>
> and
>
> @After
> public void cleanupTest() {
> ...
> StoreConnection.expel(...) ;
> }
>
> The @After happens before the @Rule cleanup (tick) so it really should be that nothign is folding on to the space.
>
> The temporary folder is of the form in (Eclipse) /tmp/junitNNNNNNNN or (maven) target/junitNNNNNNNN.
>
> Idea (no evidence; no Mac) - even if unlinked, maybe the file space is not immediately freed up.
>
> We have the same with TCP ports - the tests used to saturate a machine and it ran out of ports because they were not being recycled - the OS didn't seem to get time to run the final part of TCP clearing up immediately.
>
> And one other thing - we know Mac OS reports very large empty databases. I has assumed this was an accounting thing - they are sparse files so while they have a length of 8M, they are in fact 8K of used space. Maybe on OS/X a real 8M of disk space is allocated or at least reserved (which would be so mainframe-y!)
>
> Andy
>
>
>
> On 03/06/16 18:22, A. Soroka wrote:
>> Just a further note: I've started sticking in logging statements and this turns out to be rooted in "java.io.IOException: No space left on device" exceptions getting thrown up at BlockAccessMapped::allocSegment line 223. This is with builds starting with about 25GB free on disk. And I am sometimes (but not always) seeing messages from the OS about disks being nearly full during the build.
>>
>> So maybe there _is_ something weird about Mac OS X and memory mapping in Java? I suppose I have to start tracking resources.
>>
>> Is anyone else out there using Mac OS X (10.10.5)? Are you seeing the same problem? I really hope I'm not the only one! {grin}
>>
>> ---
>> A. Soroka
>> The University of Virginia Library
>>
>>> On Jun 1, 2016, at 3:43 PM, Andy Seaborne <an...@apache.org> wrote:
>>>
>>> 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
>>>
>
Re: out-of-space problems with build
Posted by Andy Seaborne <an...@apache.org>.
jena-jdbc-driver-tdb has 99 disk tests in TestTdbDiskConnection and 221
TestTdbDiskResultSets - so that's what I have looked.
The test work by:
@Rule
public TemporaryFolder tempDir = new TemporaryFolder();
and
@After
public void cleanupTest() {
...
StoreConnection.expel(...) ;
}
The @After happens before the @Rule cleanup (tick) so it really should
be that nothign is folding on to the space.
The temporary folder is of the form in (Eclipse) /tmp/junitNNNNNNNN or
(maven) target/junitNNNNNNNN.
Idea (no evidence; no Mac) - even if unlinked, maybe the file space is
not immediately freed up.
We have the same with TCP ports - the tests used to saturate a machine
and it ran out of ports because they were not being recycled - the OS
didn't seem to get time to run the final part of TCP clearing up
immediately.
And one other thing - we know Mac OS reports very large empty databases.
I has assumed this was an accounting thing - they are sparse files so
while they have a length of 8M, they are in fact 8K of used space.
Maybe on OS/X a real 8M of disk space is allocated or at least reserved
(which would be so mainframe-y!)
Andy
On 03/06/16 18:22, A. Soroka wrote:
> Just a further note: I've started sticking in logging statements and this turns out to be rooted in "java.io.IOException: No space left on device" exceptions getting thrown up at BlockAccessMapped::allocSegment line 223. This is with builds starting with about 25GB free on disk. And I am sometimes (but not always) seeing messages from the OS about disks being nearly full during the build.
>
> So maybe there _is_ something weird about Mac OS X and memory mapping in Java? I suppose I have to start tracking resources.
>
> Is anyone else out there using Mac OS X (10.10.5)? Are you seeing the same problem? I really hope I'm not the only one! {grin}
>
> ---
> A. Soroka
> The University of Virginia Library
>
>> On Jun 1, 2016, at 3:43 PM, Andy Seaborne <an...@apache.org> wrote:
>>
>> 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
>>
Re: out-of-space problems with build
Posted by "A. Soroka" <aj...@virginia.edu>.
Just a further note: I've started sticking in logging statements and this turns out to be rooted in "java.io.IOException: No space left on device" exceptions getting thrown up at BlockAccessMapped::allocSegment line 223. This is with builds starting with about 25GB free on disk. And I am sometimes (but not always) seeing messages from the OS about disks being nearly full during the build.
So maybe there _is_ something weird about Mac OS X and memory mapping in Java? I suppose I have to start tracking resources.
Is anyone else out there using Mac OS X (10.10.5)? Are you seeing the same problem? I really hope I'm not the only one! {grin}
---
A. Soroka
The University of Virginia Library
> On Jun 1, 2016, at 3:43 PM, Andy Seaborne <an...@apache.org> wrote:
>
> 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 <an...@apache.org> 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
>>
>
Re: out-of-space problems with build
Posted by Andy Seaborne <an...@apache.org>.
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 <an...@apache.org> 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
>
Re: out-of-space problems with build
Posted by "A. Soroka" <aj...@virginia.edu>.
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.
---
A. Soroka
The University of Virginia Library
> On Jun 1, 2016, at 2:07 PM, Andy Seaborne <an...@apache.org> 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
Re: out-of-space problems with build
Posted by Andy Seaborne <an...@apache.org>.
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