I heartily agree. We should provide all of the necessary infrastructure to handle interruption but should not include the application level mechanism for using it. The application level could be provided as contributed code or perhaps as an example in the site documentation.
Mike
On Friday, July 4, 2003, at 05:39 AM, Kalnichevski, Oleg wrote:
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
