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=12216>. 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=12216 WebServiceProxy error handling ------- Additional Comments From [EMAIL PROTECTED] 2002-11-28 22:21 ------- I've been working with HttpMultiClient a lot recently and Aurélien Pernoud notified me of this bug so I thought I'd point you guys in the direction of the fix. Please see my comments on bug 14005 (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14005). In essence the problem is that there is no side-effect free way in Java to determine if a socket is open or closed, so if the server side times out HttpClient is left thinking the connection is still open. Two steps are required to fix this: 1. When any exception is thrown HttpClient should close the connection with the server so that it returns to a known state. 2. The user of HttpClient needs to catch the IO exception and retry the connection. There are 3 exceptions that HttpClient throws under correct usage: 1. HttpRecoverableException: User should retry the connection, it is expected to succeed. 2. HttpException: User should not retry the connection, it will almost definitely fail again. 3. IOException: User should retry the connection, it may or may not succeed. Note that without fixing HttpClient to close the connection when an exception is thrown, any retry of the connection will fail with the same IOException because the same (unknowingly closed) connection will be reused. The patch for this is expected to be checked into CVS soonish, but is currently waiting on the merge between HttpClient and HttpMultiClient. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
