You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Chetan Mehrotra (JIRA)" <ji...@apache.org> on 2016/06/08 08:42:20 UTC

[jira] [Commented] (OAK-4440) Async upload in S3DataStore can lead to intermittent binary missing exception in cluster

    [ https://issues.apache.org/jira/browse/OAK-4440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15320247#comment-15320247 ] 

Chetan Mehrotra commented on OAK-4440:
--------------------------------------

One way to mitigate the problem would be to enable a wait for read call in S3DataStore if the binary is not found in S3 and async upload is enabled. 

In normal scenarios (unless due to a bug in Oak) a read call for any binary should always work as by design binary cannot get removed before node gets removed. So if a binary is missing then it should be only due to async upload feature and doing a implicit retry should be fine

> Async upload in S3DataStore can lead to intermittent binary missing exception in cluster
> ----------------------------------------------------------------------------------------
>
>                 Key: OAK-4440
>                 URL: https://issues.apache.org/jira/browse/OAK-4440
>             Project: Jackrabbit Oak
>          Issue Type: Bug
>          Components: blob
>            Reporter: Chetan Mehrotra
>             Fix For: 1.6
>
>
> {{S3DataStore}} supports async upload of binaries. This feature was added to speedup performance for cases where S3 is remote (i.e. Oak/JR2 app was running on premise) (JCR-3733)
> This feature would cause issue in cluster deployment where binaries get uploaded from any cluster node because its possible that binary is not uploaded to S3 (present in local cache of one of the cluster node) and some code in other cluster node tries to read the binary.
> This feature also poses problem in backup and restore where we would need backup the local S3 cache on all the cluster nodes



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)