删除后,存储桶名称似乎仍在使用中

时间:2017-03-26 11:32:06

标签: amazon-web-services amazon-s3 ibm-cloud object-storage

使用Java S3 SDK,我可以创建存储桶并在其中放置对象并列出内容和删除存储桶。我唯一不能做的就是删除后再次创建相同的存储桶。

在下面显示的堆栈跟踪中,我之前创建了一个名为 gormanm-0709-r-o-o-t 的存储桶,使用它,然后通过s3.deleteBucket("gormanm-0709-r-o-o-t")将其删除。然后我尝试通过s3.createBucket("gormanm-0709-r-o-o-t", "us-standard")重新创建它,但得到如下所示的错误。



com.amazonaws.services.s3.model.AmazonS3Exception: Container gormanm-0709-r-o-o-t exists (Service: Amazon S3; Status Code: 409; Error Code: BucketAlreadyExists; Request ID: 1be8b569-3db4-4eff-bf1e-c4b8dac20272), S3 Extended Request ID: null
	at com.amazonaws.http.AmazonHttpClient$RequestExecutor.handleErrorResponse(AmazonHttpClient.java:1588)
	at com.amazonaws.http.AmazonHttpClient$RequestExecutor.executeOneRequest(AmazonHttpClient.java:1258)
	at com.amazonaws.http.AmazonHttpClient$RequestExecutor.executeHelper(AmazonHttpClient.java:1030)
	at com.amazonaws.http.AmazonHttpClient$RequestExecutor.doExecute(AmazonHttpClient.java:742)
	at com.amazonaws.http.AmazonHttpClient$RequestExecutor.executeWithTimer(AmazonHttpClient.java:716)
	at com.amazonaws.http.AmazonHttpClient$RequestExecutor.execute(AmazonHttpClient.java:699)
	at com.amazonaws.http.AmazonHttpClient$RequestExecutor.access$500(AmazonHttpClient.java:667)
	at com.amazonaws.http.AmazonHttpClient$RequestExecutionBuilderImpl.execute(AmazonHttpClient.java:649)
	at com.amazonaws.http.AmazonHttpClient.execute(AmazonHttpClient.java:513)
	at com.amazonaws.services.s3.AmazonS3Client.invoke(AmazonS3Client.java:4187)
	at com.amazonaws.services.s3.AmazonS3Client.invoke(AmazonS3Client.java:4134)
	at com.amazonaws.services.s3.AmazonS3Client.createBucket(AmazonS3Client.java:1021)
	at com.amazonaws.services.s3.AmazonS3Client.createBucket(AmazonS3Client.java:973)
	at com.ibm.saas.file.cos.CosFile.createBucket(CosFile.java:794)
	at com.ibm.saas.file.cos.CosFile.ensureBucketExists(CosFile.java:781)
	at com.ibm.saas.file.cos.CosFile.mkdirs(CosFile.java:665)
	at com.ibm.saas.file.cos.CosFileServiceTest.testDir(CosFileServiceTest.java:148)
	at com.ibm.saas.file.cos.CosFileServiceTest.testRootOperations(CosFileServiceTest.java:82)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)




我肯定知道我删除了它(因为代码没有抛出任何异常而且我没有看到出现在Bluemix / Softlayer控制台中的桶)而且我确定没有其他人"跳过上"我的桶名,因为我一遍又一遍地做了这个测试。

我的猜测是,在桶名称可以再次使用之前有一段时间,但我只是在猜测,即使这是真的,也应该有一些文档在某处解释规则。

说到文档,Getting Help页面会显示问题(https://developer.ibm.com/answers/smartspace/public-cloud-object-storage/),但该页面不存在。

2 个答案:

答案 0 :(得分:3)

在IBM COS中,删除存储桶后有10分钟的时间,其中保留了名称。此延迟可防止命令可能写入已删除存储桶时可能出现的缓存问题。这种可能性很小,我们可能会缩小这个窗口,但一般来说,删除和重新创建存储桶并不是一个好习惯。您是否需要在工作流程中执行此操作?

是的,正如@jarmod在顶级评论中所提到的,这种行为是由于大量分布式逻辑设备控制着对象的切片和重组。存储桶删除仍然主要立即一致,因为收到204响应后无法进行写入和列表,但可以更好地记录此行为。

虽然迈克尔的答案涉及AWS S3,但我们的实施信息或多或少都是准确的。

答案 1 :(得分:2)

来自S3开发人员指南:

  

铲斗所有权不可转让;但是,如果存储桶为空,则可以将其删除。删除存储桶后,该名称可供重用,但由于各种原因,您可能无法使用该名称。例如,某些其他帐户可以创建具有该名称的存储桶。 请注意,可能需要一些时间才能重复使用该名称。因此,如果您想使用相同的存储桶名称,请不要删除存储桶。 [强调添加]

     

http://docs.aws.amazon.com/AmazonS3/latest/dev/BucketRestrictions.html

有关于预期延迟的文档和奖金块:你真的不应该删除并重新创建存储桶。由于存储区命名空间是全局的,因此在任何给定时间只能存在给定名称的一个存储桶,并且它当然只能位于一个区域中。只有在您再也不需要它们时才会删除存储桶 - 否则,清空存储桶,但保留存储桶。有人可能会把这个名字搞定,如果它特别不明显的话。另外:

  

Amazon S3的高可用性工程专注于获取,放置,列表和删除操作。由于存储区操作针对集中式全局资源空间,因此不适合在应用程序的高可用性代码路径上创建或删除存储桶。最好在不常运行的单独初始化或设置例程中创建或删除存储桶。

     

http://docs.aws.amazon.com/AmazonS3/latest/dev/BucketRestrictions.html

虽然细节不公开,但所有S3区域在某种意义上都知道所有存储桶。如果您将S3请求发送到错误的区域,则该错误的区域确实知道正确的区域,并将返回包含(显然未记录的)x-amz-bucket-region: response header的错误。

因此,在创建存储桶时 - 无论区域如何 - 创建存储桶时都必须与S3全局数据库进行一些内部通信。这里的中断可能会阻止在任何地区创建一个桶,即使该区域正常运行。

请注意 - 在撰写本文时,文档的另一部分“S3入门指南”提供的信息基本相同;但是,至少到2015年底,提供的信息是不同的。

  

删除存储桶时,可能会在存储桶名称可用于新区域或新存储桶拥有者之前最多延迟一小时。如果您在同一区域或相同的存储桶拥有者重新创建存储桶,则没有延迟。

     

https://web.archive.org/web/20150905132716/http://docs.aws.amazon.com/AmazonS3/latest/gsg/DeletingAnObjectandBucket.html

直观地说,我怀疑S3的持续增长可能会使这些信息在删除之前已经过时,并且在此之前从2015年开始。