On Fri, Aug 17, 2018 at 10:04:29PM -0000, john.calc...@gmail.com wrote: > I'm calling putBlob to put a blob to an S3 ninja server. The server is > returning a ridiculous 500 server error response page - it contains a ton of > javascript and the jclouds SAX parser is choking on the content of a <script> > tag (not surprising). The parser exception is properly caught in > AWSUtils.parseAWSErrorFromContent, where it logs the issue and returns null > for the AWSError. Tracing it up the stack a bit, we get to > BaseHttpCommandExecutorService.shouldContinue, where it properly interprets > false from the retryHandler.shouldRetryRequest method as "nope" and (again > properly) calls errorHandler.handleError(command, response). > > However, errorHandler.handleError isn't actually doing anything visible from > my perspective as the guy who calls putBlob. The return value of putBlob is > supposed to be the etag for services that provide an etag in the response or > null otherwise. So there's no way I can tell I got an error from looking at > the return value (is there)? > > I would have assumed that errorHandler (which ends up being > serverErrorHandler via DelegatingErrorHandler) .handleError would end up > throwing an exception that I could catch in my code.
I agree with your assumptions; I expect to see putBlob throw HttpResponseException in this situation. Returning null from AWSUtils.parseAWSErrorFromContent seems reasonable albeit not documented. Could you add some logging to ParseAWSErrorFromXmlContent.handleError to see where it swallows the error code? Also could you open an issue in Jira so we can track this defect? -- Andrew Gaul http://gaul.org/
