In regards to the empty pool vs. blocking policy race condition... I think my solution solves the deadlock. Since the blocking occurs on the offer() rather than reject(), ThreadPoolExecutor has code in place to handle this problem (they need to handle it anyway - even if offer() works in the normal nonblocking fashion, the condition may still occur where the task is added to the queue but no threads remain to handle it). Namely, after successfully adding an element to the queue, it checks to verify that there is at least one thread around to handle the task, and if not, it starts one. I'm in the process now of figuring out a test case that artificially creates this scenario... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4193891#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...