> Can you expand on the problem this solves?

Upon failed requests (response code > 3xx), the 
[BaseHttpCommandExecutorService](https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/http/internal/BaseHttpCommandExecutorService.java#L134-L146)
 decides if the request should be retried or not by asking the configured retry 
handler. If the retry handler says no, then the request is considered failed 
and passed to the error handler so a proper exception is propagated. Otherwise, 
a new request with the same data is issued.

Before [this 
commit](https://github.com/jclouds/jclouds/commit/ec63b55a04afdd5a970d8b05674deb4c3802c59c),
 error handlers and retry handlers were responsible of closing the payload, 
which was not good, as both implementations needed to be aware of each other. 
That commit just makes the caller release the payload when needed, so in 
general retry and error handlers no longer need to release it. The 
`shouldContinue` method in the `BaseHttpCommandExecutorService` will always 
release the payload when needed.

The only thing to take into account is that retry handlers that need to read 
the payload to determine if the request should be retried *need* to buffer the 
payload or do whatever it takes (if the payload is not replayable) to make sure 
the error handler will be able to read the payload again from the beginning, in 
case the response is considered failed.

The problem this issue fixes is that in some circumstances, the error handler 
got a closed stream, since the retry handler closed it (this only appeared when 
the jclouds wire logs were disabled, since payloads are saved when using wire 
logs).

In summary, retry and error handlers should not release the payload. If retry 
handlers need to read it, they need to make sure the response is updated with a 
payload that can be read again from the beginning.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1027#issuecomment-256451963

Reply via email to