[
https://issues.apache.org/jira/browse/CXF-1742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ulhas Bhole resolved CXF-1742.
------------------------------
Resolution: Fixed
Fix Version/s: 2.0.9
2.1.2
Fixed now and will be available in next release.
> 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.
