本文整理汇总了Python中awscli.customizations.s3.tasks.MultipartUploadContext.announce_total_parts方法的典型用法代码示例。如果您正苦于以下问题：Python MultipartUploadContext.announce_total_parts方法的具体用法？Python MultipartUploadContext.announce_total_parts怎么用？Python MultipartUploadContext.announce_total_parts使用的例子？那么恭喜您, 这里精选的方法代码示例或许可以为您提供帮助。您也可以进一步了解该方法所在类awscli.customizations.s3.tasks.MultipartUploadContext的用法示例。
在下文中一共展示了MultipartUploadContext.announce_total_parts方法的1个代码示例，这些例子默认根据受欢迎程度排序。您可以为喜欢或者感觉有用的代码点赞，您的评价将有助于系统推荐出更棒的Python代码示例。
示例1: TestMultipartUploadContext
# 需要导入模块: from awscli.customizations.s3.tasks import MultipartUploadContext [as 别名]
# 或者: from awscli.customizations.s3.tasks.MultipartUploadContext import announce_total_parts [as 别名]
#.........这里部分代码省略.........
self.assertEqual(
self.calls[2][1:],
('my_upload_id', [{'ETag': 'etag1', 'PartNumber': 1}]))
def test_streaming_threaded_parts(self):
# This is similar to the basic threaded parts test but instead
# the thread has to wait to know exactly how many parts are
# expected from the stream. This is indicated when the expected
# parts of the context changes from ... to an integer.
self.context = MultipartUploadContext(expected_parts='...')
upload_part_thread = threading.Thread(target=self.upload_part,
args=(1,))
# Once this thread starts it will immediately block.
self.start_thread(upload_part_thread)
# Also, let's start the thread that will do the complete
# multipart upload. It will also block because it needs all
# the parts so it's blocked up the upload_part_thread. It also
# needs the upload_id so it's blocked on that as well.
complete_upload_thread = threading.Thread(target=self.complete_upload)
self.start_thread(complete_upload_thread)
# Then finally the CreateMultipartUpload completes and we
# announce the upload id.
self.create_upload('my_upload_id')
# The complete upload thread should still be waiting for an expect
# parts number.
with self.call_lock:
was_completed = (len(self.calls) > 2)
# The upload_part thread can now proceed as well as the complete
# multipart upload thread.
self.context.announce_total_parts(1)
self.join_threads()
self.assertIsNone(self.caught_exception)
# Make sure that the completed task was never called since it was
# waiting to announce the parts.
self.assertFalse(was_completed)
# We can verify that the invariants still hold.
self.assertEqual(len(self.calls), 3)
# First there should be three calls, create, upload, complete.
self.assertEqual(self.calls[0][0], 'create_multipart_upload')
self.assertEqual(self.calls[1][0], 'upload_part')
self.assertEqual(self.calls[2][0], 'complete_upload')
# Verify the correct args were used.
self.assertEqual(self.calls[0][1], 'my_upload_id')
self.assertEqual(self.calls[1][1:], (1, 'my_upload_id'))
self.assertEqual(
self.calls[2][1:],
('my_upload_id', [{'ETag': 'etag1', 'PartNumber': 1}]))
def test_randomized_stress_test(self):
# Now given that we've verified the functionality from
# the two tests above, we randomize the threading to ensure
# that the order doesn't actually matter. The invariant that
# the CreateMultipartUpload is called first, then UploadPart
# operations are called with the appropriate upload_id, then
# CompleteMultipartUpload with the appropriate upload_id and
# parts list should hold true regardless of how the threads
# are ordered.