Antoine Pitrou

@wps132230 @sdavtaker @KaibaLopez

I'll also note that the docstring, while stating the problem, is unhelpful as to how to solve it: > Processing of a Complete Multipart Upload request could take several minutes...

Our own [workaround](https://github.com/apache/arrow/pull/11594/files) is to intercept XML error response using a DataReceivedHandler. Unfortunately, we can't really test it (those errors seem quite sporadic), but it should theoretically work.

As a sidenote, the original fix seems costly if it blindly parses any HTTP response (even a huge binary payload) as XML.

So, here is an example of how this could be fixed in the AWS SDK, IMHO: - add a method `virtual bool HasEmbeddedError(Aws::IOStream& body, Aws::Client::AWSError* error)` in `AmazonWebServiceRequest`; default implementation...

Your `setenv` function is using `_putenv_s`, so it modifies the CRT's copy of the environment. In our use case, we're using the Windows API [`SetEnvironmentVariable`](https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-setenvironmentvariable). Here is another similar issue...

Here is our workaround, which is a bit clumsy and probably does not support all authentication options correctly: https://github.com/apache/arrow/blob/778b1772fd20766e52b2bdccbd37668726f67e0c/cpp/src/arrow/filesystem/s3fs.cc#L540-L578

@xhochy

Update: this error has been reported on Ubuntu and CentOS as well: https://issues.apache.org/jira/browse/ARROW-15141

Do you have a real-world workload where this is affecting you? We try to release resources when we can, but I wouldn't be surprised if we don't release all memory...