[
https://issues.apache.org/jira/browse/LIBCLOUD-378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13756691#comment-13756691
]
ASF subversion and git services commented on LIBCLOUD-378:
----------------------------------------------------------
Commit 326e81f09902514a290f5aeb292426b56e2e95b7 in branch refs/heads/trunk from
[~mahi1216]
[ https://git-wip-us.apache.org/repos/asf?p=libcloud.git;h=326e81f ]
Fix s3 multipart test cases broken by LIBCLOUD-378
The breakage was caused by an overzealous check.
Also added test cases for checking small and big uploads via
S3 multipart upload API
> S3 uploads fail on small iterators
> ----------------------------------
>
> Key: LIBCLOUD-378
> URL: https://issues.apache.org/jira/browse/LIBCLOUD-378
> Project: Libcloud
> Issue Type: Bug
> Components: Storage
> Reporter: John Carr
> Assignee: Mahendra M
> Attachments: LIBCLOUD-378.diff
>
>
> I wrote a small script that uploaded the output of a buildbot job and then
> updated an XML file. The large binary blob worked fine. However the XML file
> failed.
> I was using the
> driver.upload_object_via_stream(iterator=StringIO.StringIO(somexml)) style as
> in the docs.
> Looking at the LIBCLOUD_DEBUG output the driver was using the S3 multi-part
> upload API and making a new "part" for each line - so every 7 bytes or so -
> but the minimum size for a part upload was 5mb.
> (I don't know if the first part is allowed to be less than 5mb if the entire
> upload is less than 5mb).
> I am working around this by forcing multi-part uploads off.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
