[concurrency-interest] Advice on tracking down the caller of Thread.interrupt()?

Bryan Thompson bryan at systap.com
Tue Mar 27 14:33:53 EDT 2012

Thanks to everyone who wrote back on this.  One other suggestion (off list) was that Thread.interrupt() is not final.   You can specialize the thread pool factory and override Thread.interrupt to report the Thread which triggered the interrupt.

Thanks again,

> -----Original Message-----
> From: concurrency-interest-bounces at cs.oswego.edu 
> [mailto:concurrency-interest-bounces at cs.oswego.edu] On Behalf 
> Of Rémi Forax
> Sent: Wednesday, March 21, 2012 4:01 PM
> To: concurrency-interest at cs.oswego.edu
> Subject: Re: [concurrency-interest] Advice on tracking down 
> the caller of Thread.interrupt()?
> On 03/21/2012 08:25 PM, Bryan Thompson wrote:
> > Hello,
> >
> > I am curious if there are any tricks for tracking down the 
> source of an interrupt. That is, the Thread which actually 
> invoked Thread.interrupt() on some thread.
> >
> > We use a disk IO in a database with concurrent readers on a 
> shared file. IO, of course, can be interrupted.  And when it 
> is interrupted the backing channel is closed, so we have to 
> jump through hoops to ensure that the channel is reopened for 
> those threads which see the AsynchronousCloseException (or 
> ClosedChannelException), while ensuring that the thread which 
> sees the ClosedByInterruptException terminates its activity.
> >
> > Normally I can spot the source of an interrupt by looking 
> at the context in which the interrupt occurs and work 
> backward through the logic of the application to figure out 
> why the Thread might have been interrupted.  However, this is 
> difficult when our code is embedded into other applications 
> when we have little to know idea what else might be going on. 
>  In particular, I am looking at an issue now where I think 
> that the interrupt might be coming from some other component. 
>  For example, by holding onto a Thread reference beyond the 
> life of a worker task and then interrupting that thread.
> >
> > Is it possible to somehow instrument the JVM to track and 
> report the caller of Thread.interrupt()?  Are there profilers 
> which can do this?  Can this be done somehow by registering a 
> SecurityManager to log stack fames in Thread.checkAccess()?
> >
> > Thanks in advance,
> > Bryan
> You can do it by yourself, it's not hard :)
>  From the directory that contains all JDK files, find the 
> src.zip, which is roughly a zip of the source of the public 
> classes of the JDK.
> Extract java/lang/Thread.java
> Now, as you can see Thread::interrupt() is written in Java, 
> so you can add all the instructions you want :) To get the 
> caller class, use sun.reflect.reflection.getCallerClass(2)
> (see [1]),
> because you are in a trusted class, you can call it.
> Compile your class and prepend it in front of the 
> bootclasspath, so your classwill be loaded instead of the one 
> from rt.jar (see java -X and java -Xbootclasspath/p )
> cheers,
> Rémi
> [1]
> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/tip/src/share/cl
> asses/sun/reflect/Reflection.java
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

More information about the Concurrency-interest mailing list