[jira] Assigned: (CXF-1742) JMS Conduit Pooled Session Recycling

["Ulhas Bhole (JIRA)" <ji...@apache.org>]

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

Ulhas Bhole reassigned CXF-1742:
--------------------------------

    Assignee: Ulhas Bhole

> JMS Conduit Pooled Session Recycling
> ------------------------------------
>
>                 Key: CXF-1742
>                 URL: https://issues.apache.org/jira/browse/CXF-1742
>             Project: CXF
>          Issue Type: Bug
>          Components: Transports
>    Affects Versions: 2.1.1
>         Environment: N/A
>            Reporter: Chris Nelson
>            Assignee: Ulhas Bhole
>             Fix For: 2.1.2, 2.0.9
>
>
> I  believe the doClose method of JMSOutputStream should have the pooled session recycle call within a finally block. As it is now, if the handleResponse call fails due to a timeout an IOException will be thrown by handleResponse. If that happens the recycle call will not happen. We had a large number of timeouts that occurred during a load test. This eventually killed our JMS server due to the number of consumers created.
> The change below seems to have fixed our issue, but please let me know if this is incorrect.
>         protected void doClose() throws IOException {            
>             try {
>                 isOneWay = outMessage.getExchange().isOneWay();
>                 commitOutputMessage();
>                 if (!isOneWay) {
>                     handleResponse();
>                 }                
>             } catch (JMSException jmsex) {
>                 getLogger().log(Level.WARNING, "JMS connect failed with JMSException : ", jmsex);            
>                 throw new IOException(jmsex.toString());
>             } finally {
>             	base.sessionFactory.recycle(pooledSession);
>             }
>         }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.