Win a copy of Testing JavaScript Applications this week in the HTML Pages with CSS and JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Carey Brown

InterruptedException

 
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
 
(instanceof Sidekick)
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)
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)
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
 
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
 
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.
 
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)
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.
 
author
Posts: 23879
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux 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)
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.
 
Consider Paul's rocket mass heater.
    Bookmark Topic Watch Topic
  • New Topic