Stopping a blocked Thread

Question

I need to stop a Thread, or interrupt a blocked I/O.
I'm making a call to a library that I do not own and cannot change. The library makes a HTTP connection to a service and waits for a response. As far as I know, the library uses BufferedReader to read the service response. If the service is down, then no response is ever returned, and the BufferedReader read simply blocks.
I cannot change the library to be intelligent, of course, and don't have very good luck getting the service support to fix their stuff. But I have to use the library. How can I interrupt the blocked I/O read?
What I've tried is as follows, but I'm not convinced it's the right way. My application is a long-running application that does not exit very often, so I'm concerned also about gc not properly recycling the resources due to still having the blocked thread still there (and this has impacted subsequent executions, even though I use local variables where I can).
        // Create a new Thread to wait on the submission
        Thread t = new Thread() {
            public void run() {
                response = event.submit();
        t.setDaemon(true);
        t.start();
        try {
            t.join(timeOut);
            msg = "Attempt to connect to ESM Server timed out";
        catch (InterruptedException e) {
            msg = e.getMessage();
        }The other option I was thinking of, was coding my call to ESM server in a separate Class with a main, and invoking it via Runtime.exec. That way, at least I'm 100% sure that the code exits, and I can use System.out/err to receive the "output".
Given that Thread.stop() is deprecated, and that you theoretically cannot interrupt blocked I/O, how have others solved this problem?
Thanks,
Matt

Answer 1

...you theoretically cannot interrupt blocked I/O, how have others solved this problem?I've done it your way. Each thread does an access. If it takes too long, then it may never respond and I ignore it. I also log the error condition and try to notify and administrator.
Threads probably take up about a megabyte of memory so I may run out of memory it the problem doesn't get fixed by manual intervention.
Your idea of using Runtime means that you create a new JVM for each ESM. If a thread takes up a megabyte, the new JVM takes up many, many megabytes. Instead of running out of memory in the JVM, you may run out of memory in the Box.
Every situation is different. My thread approach works for my application. What works best for you is your call.