On 12/05/2015 19:59, Uwe Schindler wrote:
Hallo Alan,
I just wanted to come back to this issue, because there was no further communication
recently regarding the behavior of Java 9 with opening a FileChannel on a directory to
fsync the directory metadata. Unfortunately, this would break the improved data safety
after commits to Apache Lucene indexes. This would affect many applications like Apache
Solr and Elasticsearch that rely on fsyncing the metadata on UNIX systems (Linux,
Solaris, MacOSX). Recently Elasticsearch also started to use the same approach for its
transaction log! Because we (Apache Lucene) use atomic rename functionality to
"publish" commits, losing the directory metadata after a power failure loses
all data in the commit done before the failure. With Java 7 and Java 8 we already did
extensive tests with remote controlled power plugs switching a test machine on and off
and validating that index was intact. This is no longer working with Java 9 because of
the change.
Our question now: The discussion was, to allow maybe another OpenOption to do
such special stuff, that is important for other databases, too (I assume,
Apache Derby, HSQLDB or other databases written in Java would like to do
similar things). Is there anything we can do to make a proposal for a new API,
like starting a JEP, opening a bug report,... I would take the opportunity to
get involved into the OpenJDK project to help and bring this forward.
Maybe instead of complex open options, we should simply add a new method to the
Files class: Files.force/fsync(Path fileOrDir, boolean metadata) that does the
right thing depending on the file / operating system?
I've been too busy with other JDK 9 work to spend on time on this issue
recently. I do think we should introduce some support for this use-case
as it's clearly important.
The issue with adding a method to Files is that it requires rev'ing the
service provider interface so this is why I brought up the possibility
of have it work as an OpenOption.
We should start by creating a bug on. Brian Burkhalter may have created
one already.
-Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
