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

Keith Wall updated QPID-6461:
-----------------------------
    Fix Version/s: 6.0 [Java]

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

Reply via email to