• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

InterruptedException

 
Sameer Amte
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
On start up of my Java Application, I create a Thread Pool and also initialise a proprietary API that makes socket connections intialises it's own Thread Pool etc.
I noticed that the Worker Threads in my Thread Pool were all interrupted by the JVM on start up. In the worker thread, I check if the task queue is empty and if it is empty the worker threads go into waiting state (i.e., I call wait()). My assumption has been that InterruptedException is an abnormal scenario and hence I was terminating my worker threads on receiving InterruptedException.
Does anyone know of other possible scenarios where an InterruptedException might be raised, apart from calling interrupt(), expiry of timeout of sleep/wait.
What are the best ways to handle InterruptedExceptions?

Thanks
Sameer
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Did you implement your own thread pool? Show us what the code looks like where you set it up. There may be something in there to explain the situation.
 
Sameer Amte
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
Below is the code for my Thread Pool class:


Here is the main class that initialises the Worker Threads

In the start() method above, putting a Thread.sleep(1000) bfore initialisation of the Thread Pool solved the problem of interrupted exception. If the sleep statement is removed then the problem is occurs again.

Thanks
Sameer
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
When you add an item to queue you notifyAll() that something has arrived. That will cause an InterruptedException in *all* of your worker threads.

The loop you have here is a common structure:

except that the exception is not fatal. If you ignore the exception we'll loop back to the if-empty test. If this is the first thread to be awakened the newly added item is in the queue and we exit the wait loop, get the item, etc. If another thread already pulled the queue item and the queue is empty, we wait again.

Imlementing your own is a great exercise, but if you prefer well-tested code this stuff is in JDK5, the ApacheCommons thread pool or the Doug Lea concurrent package.
 
Sameer Amte
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Stan,
Thanks for the input. I have found the source of the InterruptedExceptions.
It is coming from some test code within my Application. Some of the proprietary API that we use was not terminating threads currently, and we had used Thread.activeCount and Thread.enumerate to get the list of running thread and try to interrupt them to check if this terminated them.
This was causing the InterruptedException. This is in line with my expectations as I was hoping that the JVM wont interrupt my working threads in some unknown way.

I am using the InterruptedException within my code to terminate my threads, so that if they get hung for some reason, I can call interrupt() and this will hopefully terminate them. Is this a valid use of the InterruptedException?

Thanks
Sameer
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think that queue.wait() is going to get an exception every time you do notifyAll() ... every time you put something new in the queue. Try it and see!
 
Sameer Amte
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Stan,
I have tested it and does not give an exception when notifyAll is called. One of the waiting threads will just move from waiting to runnable state when notifyAll is called. I dont understand why you expect an exception to be raised.

Thanks
Sameer
 
Monmohan Singh
Ranch Hand
Posts: 82
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thread.join throws an interrupted exception?
I can't think of a way to handle it. Now the reason a join is called is because i don't want the parent thread to start execution till the child has finished execution. so what do i do in case the join method throws exception
 
Timmy Marks
Ranch Hand
Posts: 226
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Don't know what the experts would say, but what about:



So done will be true if and only if no InterruptedException was thrown.
 
Olaf Kummer
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Stan James:
When you add an item to queue you notifyAll() that something has arrived. That will cause an InterruptedException in *all* of your worker threads.


No. Object#notifyAll() will wake up all threads that might happen to be in an Object#wait(), but it will never send an InterruptedException and it will not get you out of a sleep call or the like..

Regards, Olaf
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yup, I was wrong on that one. Sorry for any confusion caused.

I just spent the morning reading some wicked code that communicates between threads. The application thread puts a command where the worker thread can find it, calls notify() on the worker thread object, calls wait() on the command. The worker thread wakes up from a wait(), executes the command and calls notify() on it. The application thread wakes up from wait() and gets the results from the command. I haven't decided if it's slick or perverted.

I'm not sure yet who is waiting for the notify() in line 05.
 
Henry Wong
author
Marshal
Pie
Posts: 21420
84
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I haven't decided if it's slick or perverted.


I don't see the purpose for this. The only reason that I can think of, for doing this, is to make sure that all commands are executed in serial. This can be accomplished by declaring a global lock, synchronizing on it, and executing the command directly.

Henry
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It looks overly complex to me, too. It executes commands serially on another thread and makes the runCommand method synchronous. I'm pretty sure this originated in sample code from a terminal emulator program. The commands do JNI calls to the emulator DLL.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic