[
https://issues.apache.org/jira/browse/CXF-6454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15246578#comment-15246578
]
ASF GitHub Bot commented on CXF-6454:
-------------------------------------
GitHub user vikash32504 opened a pull request:
https://github.com/apache/cxf/pull/132
3.1.x fixes - CXF-6454
CXF-6454 - Orphaned JMS connections created in endless loop
Changing the code to limit the number of retries to a pre-defined value. It
can be configured as maxNoOfRetries in JMS Enpoint.
Adding another property to make the sleep time configurable. We were seeing
high CPU consumption because of low sleep interval time.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/vikash32504/cxf 3.1.x-fixes
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/cxf/pull/132.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #132
----
commit 9b2e894a04fd40ab0178c9f752a760a1dca0fec4
Author: Vikash Kumar <vikash32...@users.noreply.github.com>
Date: 2016-04-18T21:17:23Z
Update JMSEndpoint.java
commit c3b98d5602db868e713762279e5c460e18f582c5
Author: Vikash Kumar <vikash32...@users.noreply.github.com>
Date: 2016-04-18T21:21:06Z
Update JMSDestination.java
commit 9a2e9e14e758a18b079cca75807e3dd754df6c21
Author: Vikash Kumar <vikash32...@users.noreply.github.com>
Date: 2016-04-18T21:22:53Z
Update JMSConfiguration.java
commit 744c4a1d995338fd8703f5baea7002c469035411
Author: Vikash Kumar <vikash32...@users.noreply.github.com>
Date: 2016-04-18T21:24:28Z
Update JMSConfigFactory.java
----
> Orphaned JMS connections created in endless loop
> ------------------------------------------------
>
> Key: CXF-6454
> URL: https://issues.apache.org/jira/browse/CXF-6454
> Project: CXF
> Issue Type: Bug
> Components: JMS, Transports
> Affects Versions: 3.0.5
> Reporter: Waldemar Szostak
> Priority: Critical
>
> h3. Problem description
> In JMSFactory.createConnection(JMSConfiguration):
> {code}public static Connection createConnection(JMSConfiguration jmsConfig)
> throws JMSException {
> String username = jmsConfig.getUserName();
> ConnectionFactory cf = jmsConfig.getConnectionFactory();
> Connection connection = username != null
> ? cf.createConnection(username, jmsConfig.getPassword())
> : cf.createConnection();
> if (jmsConfig.getDurableSubscriptionClientId() != null) {
>
> connection.setClientID(jmsConfig.getDurableSubscriptionClientId());
> }
> return connection;
> }{code}
> there is no exception handling if the clientID fails to be set. Such an
> exception would exit this method without passing the reference to the
> just-opened JMS connection to exception handling code
> (JMSDestination.createTargetDestinationListener()).
> Moreover, JMSDestination.restartConnection() keeps on starting new
> connections (there is no max attempt restriction!) until it creates one
> without an exception thrown in the process.
> Now, if the clientID is already connected to the ESB, this creation of new
> connection will last until server resources are no longer available to the
> JVM.
> h3. Possible solution
> # Close the connection if it's not possible to set the specified clientID at
> the time:
> {code}public static Connection createConnection(JMSConfiguration jmsConfig)
> throws JMSException {
> String username = jmsConfig.getUserName();
> ConnectionFactory cf = jmsConfig.getConnectionFactory();
> Connection connection = username != null
> ? cf.createConnection(username,
> jmsConfig.getPassword())
> : cf.createConnection();
> if (jmsConfig.getDurableSubscriptionClientId() != null) {
> try {
> connection.setClientID(jmsConfig.getDurableSubscriptionClientId());
> } catch (InvalidClientIDException e) {
> connection.close();
> throw e;
> }
> }
> return connection;
> }{code}
> # Add a setting to restrict the maximum attempts to restart the connection in
> JMSDestination.restartConnection() A configurable value would be best, but
> even a hardcoded.. anything but the practically endless loop ;-)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
