Please help. How can I kill a blocking java thread???

[bm]

Is there a way to kill a java thread that is blocking on a call?

Interrupt, Stop etc. signals sent to a blocking thread are ignored.

Most texts recommends setting up some flag on the thread to indicate
that it should kill itself, but obviously this wont work if the thread
is blocking on a call and can't check the flag.

Thanks for your help.

 

[Shripathi Kamath]

Is there a way to kill a java thread that is blocking on a call?

Interrupt, Stop etc. signals sent to a blocking thread are ignored.

Most texts recommends setting up some flag on the thread to indicate
that it should kill itself, but obviously this wont work if the thread
is blocking on a call and can't check the flag.

Thanks for your help.

Is it blocking on an I/O call, or a wait()/join() call or something else?
It is not clear from your description that it is. If it is, interrupt()
should and does work.

If your blocking occurs on a CPU bound call, then inside your call, you need
to check for thread interruption.

Maybe if you posted snippets of that code?

 

[Tony Dahlman]

Is it blocking on an I/O call, or a wait()/join() call or something else?
It is not clear from your description that it is. If it is, interrupt()
should and does work.

If your blocking occurs on a CPU bound call, then inside your call, you need
to check for thread interruption.

Maybe if you posted snippets of that code?

Right but the API does not say that interrupt() will wake up a thread
that is blocked. Perhaps, the OP's thread blocks on a call to a
synchronized method in the monitor, one containing a wait(). He could
then use notify() to wake it up.

 

[bm]

Right but the API does not say that interrupt() will wake up a thread
that is blocked. Perhaps, the OP's thread blocks on a call to a
synchronized method in the monitor, one containing a wait(). He could
then use notify() to wake it up.

Thread is blocking on an i/o call or waiting for a remote ejb call to
return. Interrupt or even stop does not kill such a thread.
-bm

 

[nos]

how can i know what thread will wake up with notify()?
should i not use notifyAll()?

 

[fred]

Simple answer -- never let the thread block. use available() to see if
there is data available before reading. If there isn't you can put the
threat to sleep for a bit (sleep can be interrupted, but I still
wouldn't do it that way). Wake up, check your status variable, then
exit or loop back to check available.

 

[Ben_]

Yes, but using available was suggested in previous similar threads and it
was argued that it made difficult to detect the end of stream.

How do you solve this ?

 

[Tony Dahlman]

Thread is blocking on an i/o call or waiting for a remote ejb call to
return. Interrupt or even stop does not kill such a thread.
-bm

Certainly a thread waiting on local user i/o will abort if you call
interrupt() on the thread. So it must be that if you have called
[name_of_inputstream].readLine() in a Thread t, that wait state will
abort if you call t.interrupt().

Maybe you do need to post at least some of your code that doesn't
seem to work.

Regards, Tony Dahlman

 

[noone]

how can i know what thread will wake up with notify()?

IIRC .... you don't. The JVM ( or the OS? ) will decide which thread
will receive the notify().

 

[Tony Dahlman]

how can i know what thread will wake up with notify()?
should i not use notifyAll()?

Well, notify() usually does exactly the same thing as notifyAll(), in my
limited experience. Maybe if there are several blocked threads, some of which
have higher priorities than others, and if your JVM/OS/machine implements thread
priorities as Sun intended, notifyAll() will tend to wake up high priority
threads before others.

Still, if you don't know which thread will wake up, you have given up control
of your program to chance, haven't you? In other words, why not handle the
issue of which thread should have priority in your own code?

Perhaps I should have searched for previous threads on the subject of notify()
vs. notifyAll(), so forgive me for not doing so, and let me know where to look
for that if you know....

Regards, Tony Dahlman

 

[Kin C. Wong]

I had the same problem where the thread was blocking on a
getMessages() which reads from a messageBuffer. What I did was just
set my flag to stop the thread, then sent a dummy message to the
messageBuffer so the getMessages() executes and then the thread stops.

 

[fred]

I'm sorry, I thought available() would throw an exception in EOF is
reached -- IE the input stream is closed.

Alternately you can use DataInputStream.readByte():

readByte

public final byte readByte()
throws IOException

See the general contract of the readByte method of DataInput.

Bytes for this operation are read from the contained input stream.

Specified by:
readByte in interface DataInput

Returns:
the next byte of this input stream as a signed 8-bit byte.
Throws:IOException - if an I/O error occurs.