[jira] [Commented] (JCLOUDS-793) make blobstore put operations report server errors via HttpResponseException

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

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

Daniel Hsueh commented on JCLOUDS-793:
--------------------------------------

Hello everyone,

I've observed HttpResponseException thrown on 503 and 416 responses from openstack-swift, suggesting the behavior I mentioned is already the existing behavior.  My observation of a no-exception GET response with missing ETag was the result of using some experimental swift code, and the result of org.jclouds.openstack.swift.v1.functions.{ParseObjectFromResponse, ETagHeader} not throwing an exception on a missing ETag (whereas others, such as org.jclouds.http.functions.ParseETagHeader throw an exception).

So the only thing that we could do is make the blobstores consistent when no ETag is found.

Sorry for the false alarm.


> make blobstore put operations report server errors via HttpResponseException
> ----------------------------------------------------------------------------
>
>                 Key: JCLOUDS-793
>                 URL: https://issues.apache.org/jira/browse/JCLOUDS-793
>             Project: jclouds
>          Issue Type: Improvement
>          Components: jclouds-blobstore
>    Affects Versions: 1.8.1
>            Reporter: Daniel Hsueh
>            Assignee: Jeremy Daggett
>              Labels: features
>
> observed with openstack-swift 1.8.1 ObjectApi.put()
> if the server responds with a 4xx/5xx response, the put() call returns null for the etag
> would it be more useful if there was an HttpResponseException were thrown, with the actual request, response, and response code available?  as of now, the null response only indicates that an etag was not found in the response, not that the whole request failed
> I observe that a failure to communicate (e.g. BackoffLimitedRetryHandler running through its retires) will result in an HttpResponseException
> there may also be an issue with consistency -- from perusing the AzureBlobClient and S3Client code it seems like an HttpException("did not receive ETag") would be thrown, and not a null etag
> I would also propose that GETs report 4xx/5xx responses via HttpResponseException as well
> I realize this is a major departure from existing behavior, perhaps this exception-reporting-on-error could be enabled via an override?
> thank you



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