Mailing-List: contact dev-help@clerezza.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@clerezza.apache.org
Received-SPF: pass (nike.apache.org: domain of andy.seaborne.apache@gmail.com
 designates 209.85.215.176 as permitted sender)
Sender: Andy Seaborne <andy.seaborne.apache@gmail.com>
Message-ID: <514316B0.3060103@apache.org>
Date: Fri, 15 Mar 2013 12:40:16 +0000
From: Andy Seaborne <andy@apache.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20130308 Thunderbird/17.0.4
MIME-Version: 1.0
To: dev@clerezza.apache.org
Subject: Re: Test failures on fresh build
References: <5142E069.3090205@xup.nl> <5142E71B.6080504@apache.org>
 <5142EEDC.6000302@xup.nl>
In-Reply-To: <5142EEDC.6000302@xup.nl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 15/03/13 09:50, Minto van der Sluis wrote:
> Thanks Andy for your explanation. Seems indeed like I am hitting that
> know bug :-(
>
> Now I have to go through the hassle to build and test  my modifications
> on some other OS.

:-( indeed.

TDB testing islittered with e.g.

   final String DIR = SystemTDB.isWindows
        ? ConfigTest.getTestingDirUnique()
        : ConfigTest.getTestingDirDB() ;


>
> Regards,
>
> Minto
>
>
> Op 15-3-2013 10:17, Andy Seaborne schreef:
>> On 15/03/13 08:48, Minto van der Sluis wrote:
>>> Zooming in on rdf.jena.tdb.storage I see behaviour I noticed before. At
>>> least on Windows TdbTcProvider.delete(..) does not properly clean up the
>>> given directory. Instead of abusing TdbTcProvider in test cases for
>>> doing the clean up I used Apache Common IO. However using Common IO
>>> FileUtils.forceDelete(..) results in an exception. It seems like
>>> something still keeps holding on to (some of) the files.
>>
>> I guess you are running with a 64bit JVM. [1]
>>
>> A "feature" of MS Windows is that you can't delete a memory mapped
>> file while the JVM is running even if you detach all the mapped
>> segments. "nuisance" would be too polite.
>>
>> There are workarounds rumoured but the only one I know of that might
>> be reliable, and not tricks calling GC() twice in quick succession, is
>> to call Sun-JVM specific operations.
>>
>> TDBs own test suite has to specifically create fresh directories for
>> each test on Windows.
>>
>>      Andy
>>
>> [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4724038
>> and several others.  Once there was a popularity list of bugs and
>> features and this was steadily in the top 25.
>>
>> One of the bug reports was a collecting point for attempts to
>> workaround this - but user comments thread does not seem to have
>> survived the transitions to the current trackers; at least, I can't
>> find them again.
>>
>>
>>
>
>