[
https://issues.apache.org/jira/browse/JCR-4126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Csaba Varga updated JCR-4126:
-----------------------------
Attachment: concurrent-datastore-fix.diff
I'm attaching a patch that should fix the issue, and also contains a test case
for future verification. Given that the issue involves concurrency, reliable
reproduction is not guaranteed, but on my local computer (Core i5 @ 3.33GHz,
Windows 7 Enterprise 64 bit) I could get the test case to fail every time I've
tried running it.
The fix consists of re-checking the existence of the file after a failed rename
operation. If the file exists afterwards, we assume that some other process won
the race and keep going.
> Shared FileDataStore throws exception if two processes try to add the same
> file concurrently
> --------------------------------------------------------------------------------------------
>
> Key: JCR-4126
> URL: https://issues.apache.org/jira/browse/JCR-4126
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-data
> Affects Versions: 2.15.1
> Reporter: Csaba Varga
> Priority: Minor
> Attachments: concurrent-datastore-fix.diff
>
>
> The FileDataStore implementation can throw an IOException if multiple
> repositories share the same data store and multiple repositories try to add
> the same record at the same time. This can happen easily when you set up
> multiple AEM publisher instances to share the same data store to save disk
> space. (AEM uses Oak, but the Oak file blobstore implementation ends up using
> the Jackrabbit FileDataStore implementation, so at the end of the day the bug
> affects the latest Oak and latest AEM as well.)
> We have noticed this issue via log analysis. When we publish the same asset
> to all of our publisher instances, we are seeing a recurring IOException in
> the log. The author instance eventually retries the publish operation and by
> that time, there is no race condition and the operation succeeds, but the
> situation is still not ideal.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
