> @@ -52,7 +53,7 @@ > @Consumes(MediaType.APPLICATION_JSON) > @Endpoint(CDN.class) > @RequestFilters(AuthenticateRequest.class) > - @Fallback(FalseOn500or503.class) > + @Fallback(PoppyFallbacks.FalseOn500or503orIOE.class)
I've investigated a bit, and the issue you are facing is [JCLOUDS-532](https://issues.apache.org/jira/browse/JCLOUDS-532). With the Java default driver does not fail, but it seems to fail with the Apache HC driver (the one used in the reported issue) and OkHttp. Both seem to use custom `InputStreams` that throw an `IOException` when you call `read`, while he default implementation seems to just return -1. That read happens later in the error handler when trying to build the exception to propagate. I'd like to investigate this a bit more, as there is a [explicit test to verify that the InputStream is closed](https://github.com/jclouds/jclouds/blob/master/core/src/test/java/org/jclouds/http/handlers/BackoffLimitedRetryHandlerTest.java#L119-L160), so we need more background to determine if we can relax that and don't close the stream there. I've assigned the issue to me and I expect to have a look at it this week, but in any case, I think we should revert the fallback to the previous one. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs-openstack/pull/179/files#r26009050
