Hi. I use a ThreadPoolExecutor that executes some runnable on 10 threads. the code that has been executed is read some information from a socket server.
At some times I want a specific thread to be terminated so I use Thread.interrupt and it work in 90% of the cases. I know because afterExecute(Runnable run, Throwable t) method from the ThreadPoolExecutor is executed.
However in 10% of the cases the thread is not interrupted. I know because the method afterExecute is never executed and because ThreadPoolExecutor.getActiveCount() returns 1 thread ( the one that it supposed to be interupted).
I have to mention that I read information from a socket server and the connection is tunneled via a proxy(not sure if this is the problem)
I would just post about that the interrupt method actually doesn't interrupt. =)
One part of the documenation says that: If this thread is blocked in an invocation of the wait(), wait(long), or wait(long, int) methods of the Object class, or of the join(), join(long), join(long, int), sleep(long), or sleep(long, int), methods of this class, then its interrupt status will be cleared and it will receive an InterruptedException.
That's what I don't understand, because these methods (join, sleep) throw InterruptedException, so to run them you need to catch the exception (or propagate), hence the thread is not interrupted, and continue execution.
For instance, try the code below:
Uncomment the catch block and it will work.
I'm just learning threads, but I think this is not a correct behavior. The interrupt method should kill the thread, but this is not the case.
Is there some method to kill a thread?
Joined: Sep 24, 2009
hi Leandro. Thanks for your reply. Yes you are right , but this is not my problem. I already have a Thread.sleep(milliseconds) in my runnable and it doesn't throw anything.
here is some part of the code in my runnable
when I execute Thread.interrupt() it show me that the thread is interrupted ( returns to the console "thread interrupted on thread: Thread-1"). but the "sleep interrupted on thread: Thread-1" is not shown.
I think it has to do with the socket. I already set
At the time its interrupt() method is called, has the thread reached the sleep() statement yet?
Ping & DNS - updated with new look and Ping home screen widget
Joined: Sep 24, 2009
Ulf Dittmer wrote:At the time its interrupt() method is called, has the thread reached the sleep() statement yet?
no. it's reading from the socket. if it reach the sleep than the interruption will work fine.
Also the socket is closed when the interrupt method is called on 90% of the cases. but there is a 10% cases which don't close the socket
Joined: Mar 04, 2009
Doua Beri wrote:here is some part of the code in my runnable
So it doesn't print: sleep interrupted on thread..., right?
It sounds like your having problems with interrupting blocked IO and this is a well written on subject (google away ;-) ). I think the exact behaviour you get is OS dependent , Windows I believe is particularly unfriendly. I've seen written though can't confirm that you might be better closing the underlying socket to interrupt the thread or I believe you should use the newer non blocking api .
"Eagles may soar but weasels don't get sucked into jet engines" SCJP 1.6, SCWCD 1.4, SCJD 1.5,SCBCD 5
Joined: Sep 24, 2009
Chris Hurst wrote:It sounds like your having problems with interrupting blocked IO and this is a well written on subject (google away ;-) ). I think the exact behaviour you get is OS dependent , Windows I believe is particularly unfriendly. I've seen written though can't confirm that you might be better closing the underlying socket to interrupt the thread or I believe you should use the newer non blocking api .
I think I managed to solve the problem. yes I thin you're right. That was my thought. I tested on linux with no problems. yes windows has some problems with closing sockets.
however I tried to close the socket and is working fine. however Thread.interrupt doesn't do the same thing?
"If this thread is blocked in an I/O operation upon an interruptible channel then the channel will be closed, the thread's interrupt status will be set, and the thread will receive a ClosedByInterruptException."
Also what do you mean by newer non blocking api ???
thanks. that is something I missed. good info. but my problem actually was solved by closing the socket. Using this new method will not block my thread but still will not close the connection on windows OS and still some resource are being used.
But this is a good information. it helped me much.