[
https://issues.apache.org/jira/browse/JCLOUDS-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790059#comment-13790059
]
Diwaker Gupta commented on JCLOUDS-334:
---------------------------------------
[~gaul] sure, I'm taking a look though I'm still trying to understand AWS's
behavior. Per the documentation
(http://docs.aws.amazon.com/AmazonS3/latest/API/ErrorResponses.html), S3 should
return 409 with code BucketAlreadyOwnedByYou on a repeated request to create a
bucket you had previously created. The code seems to do the right thing in
FalseIfBucketAlreadyOwnedByYouOrOperationAbortedWhenBucketExists. However, when
I look at the wire trace for repeated create container requests, I only see
200s:
{noformat}
2013-10-08 22:32:28,525 DEBUG
[org.jclouds.rest.internal.InvokeSyncToAsyncHttpMethod] (pool-3-thread-1) >>
invoking CreateBucket
2013-10-08 22:32:28,526 DEBUG
[org.jclouds.http.internal.JavaUrlHttpCommandExecutorService] (pool-3-thread-1)
Sending request 1450683716: PUT https://s3.amazonaws.com/diwaker-blobstore0
HTTP/1.1
2013-10-08 22:32:29,011 DEBUG
[org.jclouds.http.internal.JavaUrlHttpCommandExecutorService] (pool-3-thread-1)
Receiving response 1450683716: HTTP/1.1 200 OK
2013-10-08 22:32:30,022 DEBUG
[org.jclouds.rest.internal.InvokeSyncToAsyncHttpMethod] (pool-3-thread-1) >>
invoking GetBucketLocation
2013-10-08 22:32:30,024 DEBUG
[org.jclouds.http.internal.JavaUrlHttpCommandExecutorService] (pool-3-thread-1)
Sending request -1224342207: GET
https://s3.amazonaws.com/diwaker-blobstore0?location HTTP/1.1
2013-10-08 22:32:30,338 DEBUG
[org.jclouds.http.internal.JavaUrlHttpCommandExecutorService] (pool-3-thread-1)
Receiving response -1224342207: HTTP/1.1 200 OK
2013-10-08 22:32:30,343 DEBUG
[org.jclouds.rest.internal.InvokeSyncToAsyncHttpMethod] (pool-3-thread-1) >>
invoking ListBucket
2013-10-08 22:32:30,345 DEBUG
[org.jclouds.http.internal.JavaUrlHttpCommandExecutorService] (pool-3-thread-1)
Sending request 31068127: GET https://s3.amazonaws.com/diwaker-blobstore0
HTTP/1.1
2013-10-08 22:32:30,573 DEBUG
[org.jclouds.http.internal.JavaUrlHttpCommandExecutorService] (pool-3-thread-1)
Receiving response 31068127: HTTP/1.1 200 OK
2013-10-08 22:32:30,578 DEBUG
[org.jclouds.rest.internal.InvokeSyncToAsyncHttpMethod] (pool-3-thread-1) >>
invoking CreateBucket
2013-10-08 22:32:30,579 DEBUG
[org.jclouds.http.internal.JavaUrlHttpCommandExecutorService] (pool-3-thread-1)
Sending request 1450683716: PUT https://s3.amazonaws.com/diwaker-blobstore0
HTTP/1.1
2013-10-08 22:32:31,304 DEBUG
[org.jclouds.http.internal.JavaUrlHttpCommandExecutorService] (pool-3-thread-1)
Receiving response 1450683716: HTTP/1.1 200 OK
{noformat}
Unless jclouds is doing some kind of translation or masking the 409 somehow, it
seems that the AWS documentation is incorrect. I see somewhat similar behavior
with boto. I'm trying to get a wireshark trace to eliminate any
application-specific anomalies to ascertain the responses sent by S3. Will
update as I find more.
> createContainerInLocation returns true even if container exists
> ---------------------------------------------------------------
>
> Key: JCLOUDS-334
> URL: https://issues.apache.org/jira/browse/JCLOUDS-334
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
> Affects Versions: 1.6.2
> Reporter: Diwaker Gupta
> Assignee: Andrew Gaul
>
> Javadocs for `createContainerInLocation` state (from
> http://javadocs.jclouds.cloudbees.net/org/jclouds/blobstore/BlobStore.html):
> "Returns: true if the container was created, false if it already existed."
> The following simple test snippet verifies this:
> ```
> assertThat(blobStore.createContainerInLocation(
> /*location=*/ null, name)).isTrue();
> assertTrue(blobStore.containerExists(name));
> assertThat(blobStore.createContainerInLocation(
> /*location=*/ null, name)).isFalse();
> ```
> I ran the test above for a variety of blobstores, and the test fails for
> pretty much everyblobstore including aws-s3, cloudfiles, hpcloud, azureblob,
> atmos etc. In my tests, it does pass when using generic S3 endpoints like
> with Google cloud storage.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
