[
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 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).
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 close after
The JMS Specification (4.3.8) states that:
bq. A Connection serializes execution of its ExceptionListener.
Currently, as the client uses an unbounded executor task pool, many invocations
of the application's exception listener may be in flight concurrently. This
behaviour may break an application.
This is a partly a long standing issue (the message bounces in 0-8..0-91 were
potentially returned via the exception listener concurrently) and partly as a
result of a more recent change (QPID-6374 in 0.32). Here we started to use the
task pool for redelivery of all asynchronous exceptions.
> 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
>
> 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).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
