[
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 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.
was:
Related to this is the fact that frameworks such as Spring often install a
exception listener that responds to all exceptions by stopping/closing the
connection. With the changes in 0.32, the attempted close
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 will fail to complete
> normally (and log 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 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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
