[
https://issues.apache.org/jira/browse/FELIX-6515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18040293#comment-18040293
]
Felix Marx commented on FELIX-6515:
-----------------------------------
I have added a PR that tries to tackle this problem from another approach by
making sure correct locks are in place.
It would be great if the provided solution could be validated.
> 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)
