After looking at the code, I've asked the client to turn on an appropriate logger to see what is going on in his case. The symptom is a "non-resettable stream" exception being thrown. The concern now is that, for input which includes a non-resettable stream, there is a non-error code path that causes this exception, perhaps erroneously. I'll provide further details, and if warranted a ticket and a fix, when I have them.
Karl On Fri, Mar 8, 2013 at 7:13 AM, Oleg Kalnichevski <[email protected]> wrote: > On Thu, 2013-03-07 at 08:39 -0500, Karl Wright wrote: >> Hi all, >> >> We have code that creates a DefaultHttpClient instance for use with >> Solr. The HttpEntity that is created when sending data is not >> reusable, so we've disabled retries (we thought) using the following >> code: >> >> DefaultHttpClient localClient = new >> DefaultHttpClient(connectionManager,params); >> >> // No retries >> localClient.setHttpRequestRetryHandler(new HttpRequestRetryHandler() >> { >> public boolean retryRequest( >> IOException exception, >> int executionCount, >> HttpContext context) >> { >> return false; >> } >> >> }); >> >> >> Unfortunately it does not seem to have actually worked; we are still >> seeing "non-reusable stream" retry errors in some cases. Has anybody >> seen this before, and what >> are we doing wrong? >> >> Karl >> > > Karl > > Requests can also be retried automatically in case of an authentication > challenge and in rate cases due to a redirect. I/O errors is the most > common but not the only possible cause of automatic retries. > > Oleg > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
