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 Sat, 23 Apr 2016 04:50:12 GMT

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

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

Github user dhpatel27 commented on the pull request:

    https://github.com/apache/cxf/pull/132#issuecomment-213663398
  
    @cschneider The use case for point-1 mentioned by me above is when the application wants
the flexibility to stop the retries after certain number of attempts if the Connection couldnt
be established to JMS queue managers or JMS Destinations itself. The client may not like to
continue the retry infinite times due to the CPU Spikes that they can experience unnecessarily
after every completion of thread.sleep. Also, this situation becomes worst if a single JVM
has >50 JMS Destination Listeners defined and a single physical host has multiple such
JVMs. In such scenario, client would still see high CPU when it continues to do infinite retries.
Thus it makes sense to give flexibility to client in terms of exposing both retries and retryinterval.
    
    Also for point 2, I was trying to avoid need for client to put custom solution to call
explicitly shutdown on JMSDestination as well. ALso, if you note, shutdown variable is proned
to race condition since its not defined volatile. If you call shutdown from another Thread,
and the retry thread is still looping in another thread, the change in the value of shutdown
variable may not be instantaenously visible to other thread.
    Thanks!


> 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