[jira] [Issue Comment Deleted] (JCLOUDS-1028) Retries upon Glacier's Complete Multipart Upload request broken

["TerDale (JIRA)" <ji...@apache.org>]

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

TerDale updated JCLOUDS-1028:
-----------------------------
    Comment: was deleted

(was: Hi,
I see that "Fix Version/s" field is not set yet for this bug, any chance it could be included in the bug list for jclouds 2.0.0? 
Would be great for us, as this bug breaks our application, and we have to stick to jclouds 1.8.1 until it is fixed.
Thanks in advance.)

> 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
>              Labels: glacier
>
> 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 Multipart 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 implementing 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)