qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Keith Wall (JIRA)" <j...@apache.org>
Subject [jira] [Closed] (QPID-6461) Closing a connection in a JMS ExceptionListener logs an InterruptedException
Date Sun, 31 May 2015 22:04:17 GMT

     [ https://issues.apache.org/jira/browse/QPID-6461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Keith Wall closed QPID-6461.
----------------------------

> 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
>            Priority: Minor
>             Fix For: 6.0 [Java]
>
>
> 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 succeed in closing the sessions, then will 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).
> At very least the code needs to guard the case where it is the exception listener listener
itself trying to close the connection and thus avoid waiting the task executor shutdown/delegate
the waiting to another thread.  However, it seems questionable whether the forcible shutdown
of the task executor is the right thing to do.  This could leave an application in an inconstant
state.  The JMS spec says nothing about awaiting for in flight exception listener before returning
from Connection#close().



--
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


Mime
View raw message