[
https://issues.apache.org/jira/browse/QPID-6460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371219#comment-14371219
]
ASF subversion and git services commented on QPID-6460:
-------------------------------------------------------
Commit 1668000 from [~k-wall] in branch 'qpid/trunk'
[ https://svn.apache.org/r1668000 ]
QPID-6460, QPID-6460: [Java Client] Make task pool used for exception
reporting duties exactly one thread to serialise the callbacks
Also,
* name the task pool thread (for diagnostic purposes)
* no longer forcedily shutdown the pool on close as an unexpected
InterruptedException may corrupt an application's state
> JMS ExceptionListener potentially invoked concurrently
> -------------------------------------------------------
>
> Key: QPID-6460
> URL: https://issues.apache.org/jira/browse/QPID-6460
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
> Affects Versions: 0.32
> Reporter: Keith Wall
> Assignee: Keith Wall
>
> 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]
