hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Becke <be...@u.washington.edu>
Subject Re: How to interrupt connexion ?
Date Fri, 04 Jul 2003 15:15:00 GMT
Oleg,

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:laura@lwerner.org]
> 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: 
> commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: 
> commons-httpclient-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: 
> commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: 
> commons-httpclient-dev-help@jakarta.apache.org
>


Mime
View raw message