4 Replies Latest reply on Jul 25, 2006 5:57 PM by Guy Rouillier

    Bug Report 1074790: Interpretation of thread interruption

    Adrian Brock Master

      This thread is so we can define the rules for the issue(s) raised in the
      following bug report:
      https://sourceforge.net/tracker/index.php?func=detail&aid=1074970&group_id=22866&atid=376685

        • 1. Re: Bug Report 1074790: Interpretation of thread interruptio
          Tim McCune Novice

          So let me clarify my workaround. My code thats starts the nested transaction looked like this:

          TransactionManager mgr = getManager();
          mgr.suspend();
          mgr.begin();
          ... (do stuff in new transaction)
          ... (commit or rollback)
          mgr.resume();

          where the "stuff" in the new transaction is requesting a new JDBC connection, which is triggering the "Interrupted while requesting permit" exception because the suspended transaction caused the thread to get interrupted (e.g. due to a tx timeout.) My code with the workaround is now:

          TransactionManager mgr = getManager();
          Thread.interrupted();
          mgr.suspend();
          mgr.begin();
          ... (do stuff in new transaction)
          ... (commit or rollback)
          mgr.resume();

          so that the interrupted status is cleared from the thread. It seems like TransactionManager.begin() should be responsible for resetting the interrupted status, and (as a separate issue) that InternalManagedConnectionPool should be clearing the interrupted status before calling permits.attempt(), which is what is throwing the InterruptedException. See http://www.jboss.org/index.html?module=bb&op=viewtopic&t=52329 for more details.

          • 2. Re: Bug Report 1074790: Interpretation of thread interruptio
            Adrian Brock Master

            The purpose of the thread interruption is to avoid the thread getting
            stuck in long running processes which it never recovers from.

            e.g. waiting in db i/o, or attempting to wait on a lock

            The interruption is a one-time operation (at transaction timeout)
            so if somebody else eats it there will be nothing to stop the problems
            mentioned above.

            Whatever does check for interruption should also restore the state
            on exit, i.e. your example code should be:

            TransactionManager mgr = getManager();
            boolean interrupted = Thread.interrupted();
            try
            {
            mgr.suspend();
            mgr.begin();
            ... (do stuff in new transaction)
            ... (commit or rollback)
            mgr.resume();
            finally
            {
            if (interrupted)
            Thread.currentThread().interrupt();
            }

            • 3. Re: Bug Report 1074790: Interpretation of thread interruptio
              Adrian Brock Master

              This code does not belong in the managed connection pool.
              The pool is protected by a lock (the permits semaphore).

              If the thread comes in a interrupted it can be assumed it should not
              be attempting to use more resources.

              Your bug report shows where the thread's interrupted status is not what
              you expected. It has been interrupted because the suspended transaction
              (on the same thread) timed out.

              IMHO, the exception should be thrown if the transaction is trying to get
              access to managed resources after a transaction timeout.
              The issue is what todo about other contexts on the thread not associated
              with the timed out transaction, i.e. the equivalent of RequiresNew or NotSupported
              ejb invocations.

              • 4. Re: Bug Report 1074790: Interpretation of thread interruptio
                Guy Rouillier Newbie

                Sorry to be resurrecting a very old issue, but we are encountering this same problem with 3.2.7. We have a long running process. This used to work fine, but I guess the execution time has grown as our database has grown. I see the job starting at 21:28:31, then getting this "Interrupted while requesting permit!" at 21:38:32. So I suppose some timeout is happening at 10 minutes = 600 seconds.

                I'm not really following the discussion here or in the bug report. Is this happening because the job overlaps the 30-minute database connection timeout, and hence the connection is getting yanked out from underneath it? I would think not, because that should produce some error reflecting loss of connection.