jclouds-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "TerDale (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (JCLOUDS-1028) Retries upon Glacier's Complete Multipart Upload request broken
Date Tue, 27 Oct 2015 15:01:27 GMT

     [ https://issues.apache.org/jira/browse/JCLOUDS-1028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

TerDale updated JCLOUDS-1028:
-----------------------------
    Description: 
Commit [d4fa1159ac555212f5b978f6140b56b0ebdd49b4|https://github.com/jclouds/jclouds/commit/d4fa1159ac555212f5b978f6140b56b0ebdd49b4]
added idempotency as a criteria for determining if retries must be done.

While, this change makes full sense, it breaks retrying Glacier's Complete Muktipart Upload
request. Indeed, Amazon did choose to specify this request as [idempotent|http://docs.aws.amazon.com/amazonglacier/latest/dev/api-multipart-complete-upload.html],
while immplementing it with POST, which is not.

As a workaround, nacx proposed: 
{quote} We could move the idempotent logic to the default ioRetryHandler implementation, and
let the Glacier API configure a custom one that did not take into account the method. {quote}
cf. [discussion here|https://github.com/jclouds/jclouds/commit/d4fa1159ac555212f5b978f6140b56b0ebdd49b4#diff-8d47280811e6027bc348f6d397e6dccaR114]

  was:
Commit d4fa1159ac555212f5b978f6140b56b0ebdd49b4 added idempotency as a criteria for determining
if retries must be done.

While, this change makes full sense, it breaks retrying Glacier's Complete Muktipart Upload
request. Indeed, Amazon did choose to specify this request as [idempotent|http://docs.aws.amazon.com/amazonglacier/latest/dev/api-multipart-complete-upload.html],
while immplementing it with POST, which is not.

As a workaround, nacx proposed: 
{quote} We could move the idempotent logic to the default ioRetryHandler implementation, and
let the Glacier API configure a custom one that did not take into account the method. {quote}
cf. [discussion here|https://github.com/jclouds/jclouds/commit/d4fa1159ac555212f5b978f6140b56b0ebdd49b4#diff-8d47280811e6027bc348f6d397e6dccaR114]


> Retries upon Glacier's Complete Multipart Upload request broken
> ---------------------------------------------------------------
>
>                 Key: JCLOUDS-1028
>                 URL: https://issues.apache.org/jira/browse/JCLOUDS-1028
>             Project: jclouds
>          Issue Type: Bug
>          Components: jclouds-core
>    Affects Versions: 1.9.1
>            Reporter: TerDale
>
> Commit [d4fa1159ac555212f5b978f6140b56b0ebdd49b4|https://github.com/jclouds/jclouds/commit/d4fa1159ac555212f5b978f6140b56b0ebdd49b4]
added idempotency as a criteria for determining if retries must be done.
> While, this change makes full sense, it breaks retrying Glacier's Complete Muktipart
Upload request. Indeed, Amazon did choose to specify this request as [idempotent|http://docs.aws.amazon.com/amazonglacier/latest/dev/api-multipart-complete-upload.html],
while immplementing it with POST, which is not.
> As a workaround, nacx proposed: 
> {quote} We could move the idempotent logic to the default ioRetryHandler implementation,
and let the Glacier API configure a custom one that did not take into account the method.
{quote}
> cf. [discussion here|https://github.com/jclouds/jclouds/commit/d4fa1159ac555212f5b978f6140b56b0ebdd49b4#diff-8d47280811e6027bc348f6d397e6dccaR114]



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

Mime
View raw message