Laura, I would prefer to keep the observer thread out of HttpClient code. My concern is that request interrupt logic may be too application specific. This is hardly a problem that can have 'one size fits all' solution. I would rather leave it up to HttpClient consumers to implement. Our job would be to provide sufficient low level infrastructure:
- reliable HttpConnection#outputShutdown & HttpConnection#inputShutdown methods capable of clean input/output shutdown when running on JDK 1.3.x or above (using reflection). - HttpClient#abort method callable from an observer thread. That may require a revision of synchronization logic in HttpClient class Besides, a prerequisite for this fix is, in my opinion, a better exception handling framework. Things have gotten a bit messy there. I bet you would like to differentiate between recoverable i/o exceptions and those caused by interrupted request. I'll write a separate proposal on exception handling overhaul later today. Cheers Oleg -----Original Message----- From: Laura Werner [mailto:[EMAIL PROTECTED] Sent: Friday, July 04, 2003 07:21 To: Commons HttpClient Project Subject: Re: How to interrupt connexion ? I wrote (in response to Oleg): > Good idea! We could implement this in HttpClient by having one > "master" observer thread whose job was to close a connection's socket > whenever a Method using that connection has timed out. I messed with this today and got it more or less working. Since I didn't want to make any modifications to the HttpClient classes, at least for now, my timeout observer thread is just calling HttpConnection.close. It does indeed make anyone trying to read or write on the connection throw a SocketException, which turns into an HttpRecoverableException. My client code can then check to see if the timeout has elapsed and turn this into the VXML "error.badfetch.timeout" event if necessary. Just calling HttpConnection.close() probably isn't strictly correct. For one thing, it closes the streams before it closes the socket. If the foreground is actually doing something with the stream at the same time, this might cause an error when the stream gets closed out from under it. I think the proper sequence is to shut down the streams with Socket.shutdownInput and Socket.shutdownOutput if possible (in JDK 1.3 or later as Oleg said), then close the socket, then close the streams. To do this we'd have to add a new method to HttpConnection, maybe called abort() or some such, since there's no way to get at the socket and streams directly right now. I'll put together a patch for this and attach it to the bug when I have a chance. -- Laura --------------------------------------------------------------------- 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]
