cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CXF-6454) Orphaned JMS connections created in endless loop
Date Fri, 22 Apr 2016 09:20:12 GMT

    [ https://issues.apache.org/jira/browse/CXF-6454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15253599#comment-15253599
] 

ASF GitHub Bot commented on CXF-6454:
-------------------------------------

Github user cschneider commented on the pull request:

    https://github.com/apache/cxf/pull/132#issuecomment-213348723
  
    I do not yet see a good case for limiting the number of retries as the cxf endpoint or
client would be unusable at this point. Can you elaborate how the max retries would help in
practice? Especially what would happen after the retries are stopped. Btw. This might be something
we could discuss on IRC. I am always in the [channel #apache-cxf](https://cxf.apache.org/mailing-lists.html).
    
    1. Not sure I understand this case. Can you elaborate the steps that would happen?
    2. I think the retry thread should run as long as the CXF endpoint is active. My intention
is that you can simply call shutdown on the Destination which ends the retry thread. Interrupting
a thread is not such a good idea to achieve this.
    3. I agree to have the sleep there. I wrongly thought that this code would also be run
on the first connect.



> 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
>            Assignee: Christian Schneider
>            Priority: Critical
>             Fix For: 3.0.7, 3.1.7, 3.2.0
>
>
> 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)

Mime
View raw message