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]
