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 "Matt Ryan (Jira)" <ji...@apache.org> on 2019/12/04 04:27:00 UTC
[jira] [Commented] (OAK-8280) [Direct Binary Access] Allow client
to veto use of CDN URI
[ https://issues.apache.org/jira/browse/OAK-8280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16987512#comment-16987512 ]
Matt Ryan commented on OAK-8280:
--------------------------------
The proposed changes can be reviewed here: https://github.com/apache/jackrabbit-oak/pull/162
This adds the ability for a client to specify to ignore the domain override when generating direct access upload or download URIs. The use case (mentioned as something needed before) is that sometimes a client may have enough knowledge to know that certain requested URIs will result in faster throughput if the domain override is not used. An example is a third-party VM running as a service in the same cloud region as where the blob storage is, which based on my testing (at least with Azure) gives many times faster access time if going direct to storage using the default domain rather than using a CDN domain (which would be faster for clients not within the Azure region). With this change the client can request signed URIs that do not apply any domain override, if one is configured.
> [Direct Binary Access] Allow client to veto use of CDN URI
> ----------------------------------------------------------
>
> Key: OAK-8280
> URL: https://issues.apache.org/jira/browse/OAK-8280
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: blob-cloud, blob-cloud-azure
> Reporter: Matt Ryan
> Priority: Major
>
> As we learned in OAK-7702, using signed CDN URIs usually offers improved throughput, but not always. Implementing this issue would mean that we extend the API to allow a client to indicate that they do not want the CDN URI, even if a CDN is configured, because the client somehow knows that the non-CDN URI will be better.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)