SQLiteQueue responds to InterruptedException

[GoogleCodeExporter]

In the sqlite4java v282, the SQLiteQueue responds to InterruptedException by 
simply logging it and then ignore it through reincarnating a new SQLiteQueue 
thread.

The following is the code:

  private void runQueue() {
    try {
      queueFunction();
    } catch (InterruptedException e) {
      Thread.currentThread().interrupt();
      Internal.logWarn(this + " interrupted", e);
    } catch (Throwable e) {
      Internal.log(Level.SEVERE, this, "error running job queue", e);
      if (e instanceof ThreadDeath)
        throw (ThreadDeath)e;
    } finally {
      threadStopped();
    }

And from the above code, we can see that a queue thread only exits when a 
ThreadDeath error is catched. However, AFAIK the normal way to throw such an 
error is through thread.stop() which is deprecated.

I suggest treating the InterruptedException as the same as ThreadDeath, because 
I feel it's more common in practice that an InterruptedException is treated as 
a request of terminating yourself.

Original issue reported on code.google.com by s...@cs.washington.edu on 2 Mar 2014 at 5:20

[GoogleCodeExporter]

Thanks for your observations. In fact, the queue thread is reincarnated in all 
cases, even if ThreadDeath is caught. 

This is an intentional design decision. Thread.interrupt() is performed on a 
specific thread - and it is processed correctly, by terminating the interrupted 
thread. 

However, sending interrupt to the queue thread does not mean that the queue 
must stop. ("Queue Thread" does not equal "SQLiteQueue".) In fact, this would 
be a bad behavior because any code in your JVM can interrupt any thread (and is 
allowed to do so), thus compromising the consistency of the queue behavior. 
That's why the queue thread gets reincarnated after a while to continue serving 
the queue.

If you need to stop the queue and terminate the thread, you need to use 
SQLiteQueue.stop().

Original comment by ser...@gmail.com on 6 Mar 2014 at 10:32

[GoogleCodeExporter]

Original comment by ser...@almworks.com on 21 Sep 2014 at 6:28

• Changed state: WontFix