You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Keith Wall (JIRA)" <ji...@apache.org> on 2015/03/19 13:56:39 UTC
[jira] [Updated] (QPID-6461) Closing a connection in a JMS
ExceptionListener will fail and log InterruptedException
[ https://issues.apache.org/jira/browse/QPID-6461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Keith Wall updated QPID-6461:
-----------------------------
Description:
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.
was:
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 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
>
> 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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org