DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25370>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25370 exception during writeRequest leaves the connection un-released ------- Additional Comments From [EMAIL PROTECTED] 2003-12-10 19:18 ------- This is an interesting discussion and I really appreciate the attention, time and effort that goes into answering this. Let me answer the questions first: > any idea under what circumstances the reported problem occurs? The problem has not (yet?) occured in running code. It was detected during "exception testing". By "exception testing" I mean I put a line of code that says: if (CAUSE_RANDOM_ERROR) if (Math.random() > ERROR_RATE) throw new IOException("Random error, for testing only!"); anywhere an IO operation can occur. You'd be amazed the kinds of issue that come to light when you do this. Essentially, it is a decent way to test all the error handling code that people write but only execute under rare circumstances. > Do you happen to know if CVS HEAD also exhibits the problem? This is against RC2. The CVS codepath is quite different, but from reading the source, I'm don't think the problem is fixed. Essentially, the connection is only released if the response body is consumed. If the write failed, there is no body to consume and therefore, the release won't occur. > Feel free to examine the source code and double-check. There is one situation I > know of, when I/O exceptions would not be rethrown as HttpRecoverableException, > that is, the connection is not known to have successfully completed a write > operation at least once. In all other cases, I/O exceptions are rethrown as > HttpRecoverableException (derived from IOException). >From reading the code, it seems the outputstream is wrapped inside WrappedOutputStream which rethrows any exceptions *inside its methods* as recoverable. There are two problems with this approach. 1) IOExceptions can (and do) occur outside the methods wrapped by WrappedOutputStream. 2 examples: a) FilePart.java line 258 is reading a file. That can throw an IOException. No amount of wrapping of the OutputStream will catch this. b) A custom method that further wraps the stream (e.g. with an ObjectOutputStream) may throw errors without ever touching the underlying stream (e.g. NotSerializableException). 2) RuntimeExceptions have the same effect. > HttpClient never automatically re-executes requests on a read operation failure. > Auto-recovery MAY takes place (if enabled) on a write operation (that is, the > request body never makes it to the server in its entirety). That guarantees that > there's at least one, but not more that one, successful request for a given > resource. Feel free to correct me if I am missing something. Besides, > auto-recovery can be customized through the use of MethodRetryHandler interface Thanks for the clarification. You still have to be extremely careful if you enable auto recovery on write. Just because the write failed somewhere, doesn't mean the server didn't do anything. Take the simple case of a multi-part mime message consisting of several files (to be saved on the server). If the last file being sent dies with an IOException (e.g. the network drive it was on went to lala land), the server very likely already received and processed all the files prior to that. Resending those files can cause major issues (for example, the server may refuse to overwrite an existing file, a batch process waiting for a file may rerun some transactions, etc). How about this fix: add catch (IOException e) { releaseConnection = true; throw e; } catch (RuntimeException e) { releaseConnection = true; throw e; } to the last try clause in HttpMethodDirector#executeWithRetry ? Thanks Moh --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
