This may be an ignorant question, but here it goes: Couldn't you have an interrupt method that calls close() on the underlying streams, then calls close() on the socket itself? If I recall correctly, calling close() on a socket causes any thread that is blocked on that socket to throw a SocketException. But it should work if you shut down the associated streams first, right?
--Nathan McMinn ----- Original Message ----- From: "Laura Werner" <[EMAIL PROTECTED]> To: "Commons HttpClient Project" <[EMAIL PROTECTED]> Sent: Thursday, July 03, 2003 3:12 PM Subject: Re: How to interrupt connexion ? > Oleg Kalnichevski wrote: > > >Sadly enough, there's (there will be) no reliable way to interrupt a > >request in the release 2.0. It is an unfortunate oversight on our part. > >This feature is planned for the 2.1 release: > > > > > This is a hard problem, because almost all of the calls in the old > java.io library are non-interruptible. There's no good way to, for > example, have a background thread whose job is to interrupt requests > that have taken too long. In our current code, we fake interruptible > threads by using (pooled) background threads to execute the requests. > When the timeout interval expires, we give up on waiting for the > background thread to finish the fetch and just throw a timeout > exception. But I haven't found a way to make the background thread > actually stop the fetch, so it just sits there until the socket timeout > (if any) triggers an IOException. At that point we can recycle the > thread back into the pool. This is very error-prone, though; I'm > currently trying to track down a nasty synchronization bug in the threading. > > To make this feature work, we'd probably have to do something like this: > > - Add a timeout property to HttpMethod or HttpMethodBase > - Just before executing a method, set an internal "endTime" property > - Every time we're about to do a socket operation, e.g. in > AutoCloseInputStream.read(), compare the current time and endTime. If > we're past endTime, though an exception. If not, adjust the socket > timeout so that the read operation can't go past endTime. > - Do similar things while waiting on the connection pool, opening > sockets, etc. > > Yuck. I keep thinking there *must* be a simpler way, but I haven't > found it yet. > > -- 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]