Matt Ryan created OAK-8519:
------------------------------
Summary: [Direct Binary Access] Clearly explain causes of missing
binaries for getting download URI
Key: OAK-8519
URL: https://issues.apache.org/jira/browse/OAK-8519
Project: Jackrabbit Oak
Issue Type: Improvement
Components: blob-cloud, blob-cloud-azure, blob-plugins
Reporter: Matt Ryan
Assignee: Matt Ryan
OAK-7998 was a good improvement for direct binary access to avoid returning a
direct download URI for a binary that does not exist in cloud storage.
However, the implementation is now somewhat ambiguous and does not help the
client determine what was wrong.
There are a few cases:
* If direct binary download is not available (e.g. unsupported in the data
store implementation or not enabled via configuration) then requesting a direct
download URI for a binary returns null.
* If a binary is added via traditional upload (i.e. not via direct binary
upload) and then a download URI is requested, it is possible that the binary is
still in local cache and not in the cloud yet, and thus a direct download URI
is not yet available. Null is currently returned in this case. (This is the
use case for OAK-7998)
* If a binary is somehow permanently missing from cloud storage, null is
returned. This is a use case that shouldn't happen in normal operation but of
course is possible.
Returning null for each case makes it ambiguous to a client and hard to
determine why the null URI was returned.
I propose an improvement to direct download generation as follows:
* For the case where the direct binary download feature is not available,
continue to return null as is currently being done and as is described in the
documentation already.
* For the case where the binary does not exist, the implementation should
check to see if the binary is in the data store cache. This should be possible
via the {{AbstractSharedCachingDataStore.getCache()}} method.
** If the binary is in the cache throw an exception along the lines of
"BinaryTemporarilyUnavailableException" indicating that the binary is not yet
available for direct download but should be soon.
** If not in the cache, instead throw a different exception along the lines of
"BinaryNotFoundException" which is a more severe type of error.
The exceptions can be instances of {{RepositoryException}} or subclasses of it,
which would not require an API change and therefore would allow this fix to be
backported to 1.10.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
