[
https://issues.apache.org/jira/browse/FELIX-6515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17616288#comment-17616288
]
Sascha Vogt commented on FELIX-6515:
------------------------------------
Unfortunately our hacky solution has introduced another race condition :( The
rename (on Windows) is not an atomic operation and will first delete the old
then rename the file. So it can happen that fileinstall polls the directory -
sees the file is missing and also creates a config update event removing the
config file (after it has been renamed). This is even worse if the watchservice
is used, because it'll "queue" the delete event. We did another workaround to
check if a file is not existing if it also does not exist after a few hundered
ms:
https://github.com/seeburger-ag/felix-dev/commit/aefb552b391f463625ae309bf35939ae74b3fc8d
We figured that if a file is missing it does not matter if we delay that info
for half a second...
> File install race condition leads to empty config files
> -------------------------------------------------------
>
> Key: FELIX-6515
> URL: https://issues.apache.org/jira/browse/FELIX-6515
> Project: Felix
> Issue Type: Bug
> Components: File Install
> Affects Versions: fileinstall-3.7.4
> Reporter: Sascha Vogt
> Assignee: Jean-Baptiste Onofré
> Priority: Major
> Fix For: fileinstall-3.7.5
>
> Attachments: felix-fileinstall-empty-config.patch
>
>
> We discovered an ugly race condition within Felix Fileinstall together with
> the Config Admin.
> ConfigInstaller opens the existing config file in a new writer, basically
> emptying out the file on disk
> (https://github.com/apache/felix-dev/blob/master/fileinstall/src/main/java/org/apache/felix/fileinstall/internal/ConfigInstaller.java#L285)
> - If at the same time file install reads the file during it's regular poll
> interval, it will read an empty file. That leads to a new config admin
> "update" event where the config is empty. Now the first update finishes
> writing the config to disk and then the second event gets processed in the
> ConfigInstaller, which then detects all keys need to be removed.
> This then leads to configs which are empty besides the first comment header
> in the existing file (because only keys afterwards are emptied).
> We have a patch ready which we are currently testing internally which writes
> to a temp file and do a rename afterwards + skipping to write fully empty
> configs (that part might not make sense in the official version, but for us,
> we're never going to "empty" out config files through code, instead we would
> delete the whole file...). That seems to solve the issue for us, yet still a
> bit hacky.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
