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 <[email protected]> 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" <[email protected]> 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 <[email protected]> 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
>>>>
>>
>
>
>
>
