[
https://issues.apache.org/jira/browse/QPID-6461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-6461:
-----------------------------
Description:
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().
was:
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 close
the sessions, then 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).
> Closing a connection in a JMS ExceptionListener logs an InterruptedException
> ----------------------------------------------------------------------------
>
> Key: QPID-6461
> URL: https://issues.apache.org/jira/browse/QPID-6461
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
> Affects Versions: 0.32
> Reporter: Keith Wall
> Assignee: Keith Wall
> Priority: Minor
>
> 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().
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
