You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Ulhas Bhole (JIRA)" <ji...@apache.org> on 2008/08/12 09:26:44 UTC
[jira] Resolved: (CXF-1742) JMS Conduit Pooled Session Recycling
[ 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.