[ 
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: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to