This topic describes the causes and solutions for common errors you may encounter when you use the OSS SDK for Python.
Failed to upload parts by using the OSS SDK for Python.
Failed to upload data to OSS by using the multipart upload function provided by the OSS SDK for Python, and a large number of parts are generated.
- First, determine whether the object is directly uploaded to OSS or uploaded to OSS through other proxies such as CDN. If the object is uploaded to OSS through CDN, the ETag of the object must be exposed and the following items must be configured for OSS: HTTP header, Access-Control-Allow-Origin, Access-Control-Allow-Mehtods, and Access-Control-Allow-Headers. For more information, see PutBucketCORS.
- If the upload failed because of timeout, we recommend that you use resumable upload to upload the object. By using resumable upload, you can upload object parts concurrently and customize the part size. When the OSS SDK returns an exception, view and analyze the exception information in detail.
- Delete the parts generated by the failed upload task and upload the object again.
- The requestID in the exception returned by the OSS SDK.
- The packets captured by running the following tcpdump command when you upload the
tcpdump -i <Outbound port name> -s0 host <OSS endpoint> -w faild.pcap
The upload and download transmission speed of ossutil is far better than the OSS SDK for Python.
ossutil is developed in Go and provides better performance in concurrent upload scenarios. If the download speed of the OSS SDK for Python is far slower than that of ossutil, it may because that crcmod is not properly installed. For more information about crcmod, see Installation. If the problem persists, click here to submit a ticket.
The multipart upload function provided by the OSS SDK for Python can be called in CentOS systems. However, a 403 error is returned when the multipart upload function is called on Ubuntu systems.
- Use tcpdump to capture packets on the client. Analyze the packets to determine whether
the calculated signature is different from that on the OSS server because of incorrect
header information in the request.
POST /ttsservice%2Fpasswd? uploadId=D468E486D1D94D90A1AB8885A4E32AE0 HTTP/1.1 Host: rokid.oss-cn-hangzhou.aliyuncs.com Accept-Encoding: identity Accept: */* Content-Length: 137 date: Sat, 29 Dec 2018 07:32:34 GMT authorization: OSS LTAIknFr:r2KPR0y4E0G5tnU/MYdcvXHPQQ4= Content-Type: application/x-www-form-urlencoded User-Agent: aliyun-sdk-python/2.6.0(Linux/4.4.0-31-generic/x86_64;3.4.3) <CompleteMultipartUpload><Part><PartNumber>1</PartNumber><ETag>"3195544E19D99658706D51EF5"</ETag></Part></CompleteMultipartUpload>HTTP/1.1 403 Forbidden Server: AliyunOSS Date: Sat, 29 Dec 2018 07:33:43 GMT Content-Type: application/xml Content-Length: 1122 Connection: keep-alive x-oss-request-id: 5C2723573183A12D x-oss-server-time: 0 <? xml version="1.0" encoding="UTF-8"? > <Error> <Code>SignatureDoesNotMatch</Code> <Message>The request signature we calculated does not match the signature you provided. Check your key and signing method. </Message> <RequestId> 5C2723573183A12D </RequestId> <HostId>rokid.oss-cn-hangzhou.aliyuncs.com</HostId> <OSSAccessKeyId> LTAXXX </OSSAccessKeyId> <SignatureProvided>r2KPR0y4E0G5tnU/MYdcvXHPQQ4=</SignatureProvided> <StringToSign>POST application/x-www-form-urlencoded Sat, 29 Dec 2018 07:32:34 GMT /rokid/ttsservice/passwd? uploadId=D468E486D1D94D90A1AB8885A4E32AE0</StringToSign> <StringToSignBytes>50 4F 53 54 0A 0A 61 70 70 6C 69 63 61 74 69 6F 6E 2F 78 2D 77 77 77 2D 66 6F 72 6D 2D 75 72 6C 65 6E 63 6F 64 65 64 0A 53 61 74 2C 20 32 39 20 44 65 63 20 32 30 31 38 20 30 37 3A 33 32 3A 33 34 20 47 4D 54 0A 2F 72 6F 6B 69 64 2D 6F 70 73 2D 6D 6F 64 65 6C 2F 74 74 73 73 65 72 76 69 63 65 2F 70 61 73 73 77 64 3F 75 70 6C 6F 61 64 49 64 3D 44 34 36 38 45 34 38 36 44 31 44 39 34 44 39 30 41 31 41 42 38 38 38 35 41 34 45 33 32 41 45 30 </StringToSignBytes> </Error>The preceding code is the packets captured by tcpdump on the client. Use the captured header information in the following script to caculate the signature, and check whether the calculated signature is consistent with the signature in the captured packets.
import base64 import hmac import sha mac = hmac.new("<Secretkey>","POST\n\napplication/x-www-form-urlencoded\nSat, 29 Dec 2018 07:32:34 GMT\n/rokid/ttsservice/passwd? uploadId=D468E486D1D94D90A1AB8885A4E32AE0", sha) Signature = base64.b64encode(mac.digest()) print(Signature)
- If the signatures are consistent, the signature in the request generated by the SDK is correct. If the calculated signature is inconsistent with the signature in the captured packets, it may because that the MD5 hash calculated based on the signature is different in Ubuntu systems due to compatibility issues.
- If the signature received by the server and that calculated on the client are inconsistent, the content in the request has been modified. We recommend that you upload the object through HTTPS.
When you use the OSS SDK for Python in MacOS systems to start multiple threads and perform operations on OSS resources in a subthread, an error occurs if you import tensorflow. No error occurs if you do not import tensorflow. In addition, if you do not start multiple threads, tensorflow can be imported without errors.
objc: +[__NSPlaceholderDate initialize] may have been in progress in another thread when fork() was called. objc: +[__NSPlaceholderDate initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES, as shown in the following figure:
For more information, visit Workarounds for compatibility.
For more information about the errors that occur during the installation of the OSS SDK for Python, see Installation.