Uploaded image for project: 'Qpid'
  1. Qpid
  2. QPID-6461

Closing a connection in a JMS ExceptionListener logs an InterruptedException

Attach filesAttach ScreenshotVotersWatch issueWatchersCreate sub-taskLinkCloneUpdate Comment AuthorReplace String in CommentUpdate Comment VisibilityDelete Comments


    • Type: Bug
    • Status: Closed
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: 0.32
    • Fix Version/s: qpid-java-6.0
    • Component/s: JMS AMQP 0-x
    • Labels:


      Frameworks such as Spring install a exception listener that responds to all exceptions by stopping/closing the connection. With the changes in 0.32 (QPID-6374), the task executor is now used for the invocation of the exception listener. If the exception listener calls Connection#close(), it will succeed in closing the sessions, then will hang for two seconds awaiting shutdown of the task pool hence awaiting its own termination. This naturally times-out, so the TaskExecutor interrupts the task (interrupting the #doClose method just after the sessions are closed). Fortunately, the connection itself is closed in a finally, so the connection is closed (albeit after a two second delay).

      At very least the code needs to guard the case where it is the exception listener listener itself trying to close the connection and thus avoid waiting the task executor shutdown/delegate the waiting to another thread. However, it seems questionable whether the forcible shutdown of the task executor is the right thing to do. This could leave an application in an inconstant state. The JMS spec says nothing about awaiting for in flight exception listener before returning from Connection#close().


        Issue Links



            • Assignee:
              kwall Keith Wall
              kwall Keith Wall


              • Created:

                Issue deployment