ATOMIC_MOVE fails under high frequency conditions on Windows
Uwe Schindler
uschindler at apache.org
Mon Feb 27 17:02:36 UTC 2023
I also added a comment to the Maven issue:
https://issues.apache.org/jira/browse/MRESOLVER-325?focusedCommentId=17694090&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17694090
In fact, for correct transactional behaviour you should fsync the file
before renaming. The delayed rename is caused by the fact that Windows
sees still sees dirty blocks.
But I agree that atomic-move in Java should *additionally* be
implemented to not be async and only return whan all is done.
Uwe
Am 27.02.2023 um 17:56 schrieb Robert Muir:
> On Sun, Feb 26, 2023 at 3:37 PM Michael Osipov <michaelo at apache.org> wrote:
>> The MoveFileEx does not properly block until the operation completes and
>> some Windows-internal locking fails the operation. Even the
>> While investigating the problem, it seems to be very common on Windows
>> with Jenkins, Kafka, etc. but also Python folks discussed the issue
>> (https://github.com/python/cpython/issues/53074).
>> Now, if I apply the following patch:
>>> - Files.move( tempFile, file, StandardCopyOption.ATOMIC_MOVE );
>>> + Kernel32.INSTANCE.MoveFileEx( tempFile.toAbsolutePath().toString(), file.toAbsolutePath().toString(),
>>> + new DWORD( WinBase.MOVEFILE_REPLACE_EXISTING | WinBase.MOVEFILE_WRITE_THROUGH ) );
>> It just works. MOVEFILE_WRITE_THROUGH guarantees the operaton to block
>> until it is completed.
> Hi, we rely on this as well in apache lucene, and have some gnarly
> tests around it, but we haven't seen this specific issue.
> Maybe we dodge it because we always fsync() files before renaming
> them? I don't see any synchronization to disk in your sample code. It
> could be a possible workaround for your problem, and generally IMO
> should be done anyway rather than relying upon hacks like
> auto_da_alloc to do it for us:
> https://docs.kernel.org/admin-guide/ext4.html
--
Uwe Schindler
uschindler at apache.org
ASF Member, Member of PMC and Committer of Apache Lucene and Apache Solr
Bremen, Germany
https://lucene.apache.org/
https://solr.apache.org/
More information about the nio-dev
mailing list